Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden Heist – How to break into password vaults without using passwords

blog.redteam-pentesting.de

Post reply on HN
Print view View original

141–150 of 209 posts

Re: Bitwarden Heist – How to break into password vaults without using passwords

#141

Post by callalex »

zelon88 wrote: post #49
walki wrote: post #35

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few d…

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…

You are speaking orthogonally to the topic you replied to. The parent wants sandboxing between different programs so that one cannot read another’s data without explicit configuration and consent.

Re: Bitwarden Heist – How to break into password vaults without using passwords

#142

Post by sneak »

trympet wrote: post #97
devwastaken wrote: post #94

Earlier quoted context omitted.

"programmers won't use our poorly designed system therefore the programmers are wrong" Windows registry is in itself insecure. Applications can't own perms to their own entries. Look at what people are using and optimize for that. Clearly the intended system is wrong, and ego death is necessary to create real fixes. The easy and expected fix being that applications get perms for their own folder, rejecting 3rd party…

> Windows registry is in itself insecure. Applications can't own perms to their own entries. I think registry entries support DACLs, and permissions can be restricted to SIDs or user accounts. I have no first-hand experience with this though; YMMV. > The easy and expected fix being that applications get perms for their own folder, rejecting 3rd party by default. Back in Windows 8, they launched an app model called UW…

Restricting to user accounts is useless. Malware runs as your user.

https://xkcd.com/1200/

Re: Bitwarden Heist – How to break into password vaults without using passwords

#143

Post by southernplaces7 »

I've always thought the trust placed in password managers was deeply misplaced. Like any company, it's only a question of time and circumstance until one of them is massively breached, but right here on HN, a whole bunch of people who should know better recommending them as if they were flowers from heaven. Because of course hey, "it's just convenient".

Re: Bitwarden Heist – How to break into password vaults without using passwords

#144

Post by JackeJR »

thereddaikon wrote: post #105
zelon88 wrote: post #49

Earlier quoted context omitted.

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…

Microsoft themselves don't understand that. Teams installs itself to appdata in its entirety. One full install of teams for each user profile. Keeping it updated across one machine is impossible. How can we expect anyone else to do it right when Microsoft allows its own employees to abuse it?

Teams was kept in appdata like Chrome so that these programs can update themselves without admin privileges and I suppose that is how they keep users on a recent version.

Re: Bitwarden Heist – How to break into password vaults without using passwords

#145

Post by hervem »

shortsunblack wrote: post #100
walki wrote: post #35

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few d…

Microsoft is trying to do that with msix and a new filesystem driver that transparently restricts file system access to app. Should land into Windows 11 this year. See https://youtu.be/8T6ClX-y2AE for the functionality explaination.

And AppStore distributed application which are by default isolated, removing some feature too. (custom shortcut for example).

Re: Bitwarden Heist – How to break into password vaults without using passwords

#146

Post by JackeJR »

hattmall wrote: post #82
zelon88 wrote: post #49

Earlier quoted context omitted.

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…

So what category does stored browser passwords fall? Because it sounds like " user specific application data " which is in AppData, which is the issue. But if that's not correct which of those locations is?

They belong to encrypted user credentials. https://support.microsoft.com/en-us/windows/accessing-creden....

Re: Bitwarden Heist – How to break into password vaults without using passwords

#147

Post by dangus »

raggi wrote: post #140
calamari4065 wrote: post #130

Earlier quoted context omitted.

Agreed. The windows registry needs to be killed with fire. There's no appreciable difference between the registry and a directory of config files except that instead of an INI parser you have to use the much, much worse WIN32 API. Editing config files is fairly safe and user-intuitive. Sure you can break something by writing the wrong config file, but you do not risk breaking everything . But clumsy use of regedit do…

There are real integration challenges with the "simple file approach": - File locking and concurrency - Atomic writes / moves - Realtime change observations > clumsy use of regedit does have a chance of totally borking the entire system. So does a clumsy rm -rf, which shows up in stories here far more often than stories of people breaking their registry. Can you provide a recent reference to someone bricking their sy…

I think you could even make the argument that nobody breaks their registry because nobody wants to mess with something so user-unfriendly. Even the developers making applications tend stick all their config in .ini files because files are easier for everyone to work with.

Re: Bitwarden Heist – How to break into password vaults without using passwords

#148

Post by sigzero »

EvanAnderson wrote: post #117
pi-e-sigma wrote: post #110

Earlier quoted context omitted.

How is the registry going to make that administration any easier? The registry is its own micro cosmos, doesn't matter if some setting is in an INI file somewhere on the filesystem or somewhere in the registry

Sysadmins have great tooling to deal with the registry (Group Policy, Local Group Policy for non-domain machines). The tooling for INI files isn't very good.

I don't know one sysadmin that likes how the registry does things. INI files for configuration are vastly easier to understand and edit. Use the registry for permissions and keep your tooling.

Re: Bitwarden Heist – How to break into password vaults without using passwords

#149

Post by voidfunc »

hinkley wrote: post #80
zelon88 wrote: post #49

Earlier quoted context omitted.

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…

> "AppData" is where user specific application data is supposed to be stored. > "ProgramData" is where application specific data is supposed to be stored. Simple maybe. Coherent, no.

It's not really any worse than *Nix mess of /bin, /usr, /usr/bin, /usr/local/bin and /opt ... and probably a couple others I missed.

Re: Bitwarden Heist – How to break into password vaults without using passwords

#150

Post by Pesthuf »

walki wrote: post #35

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few d…

Is there even a way to opt in to having a secret be accessible only for your process? Like, a way to maybe sign your executable and then use a windows api that then gets "oh. This process is made by the same vendor that created this secret, so it’ll be allowed access".

It’s just ridiculous that the most trivial, unprivileged process can just steal any file and any secret accessible by the user it’s run as. Unless that secret is protected with a key derived from a separate password the user has to put in.

Post reply on HN