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

81–90 of 209 posts

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

#81

Post by EvanAnderson »

bhdlr wrote: post #77
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…

Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit

The sheer volume of legacy software prevents this from being realistic. Microsoft's commitment to backwards compatibility has reaped rewards for them. Any restrictions would have a user-controllable toggle.

If APIs prevent programmers from stupid shit the devs would encourage the end users to blame Windows and, more than likely, turn off the restrictions. (Case in point: User Account Control and making users non-Administrator by default. I've dealt with so much shitty software that opens its install instructions up w/ "Disable UAC and make sure the user has admin rights.")

There has to be a point you draw the line and say "Dev, grow up and learn about the platform you're using." An app that required users to be root on a Linux machine wouldn't survive community outrage. Windows doesn't have that kind of community. (Try arguing with a vendor about idiot practices in their app and watch their sales gerbil attempt to end-run you to your manager...)

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

#82

Post by hattmall »

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…

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?

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

#83

Post by nulld3v »

bhdlr wrote: post #77
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…

Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit

I don't think this is fair. Linux and Mac used to operate in generally the same fashion. Only recently have they started sandboxing stuff.

Windows doesn't have the same privileges because they are forced to maintain backwards compatibility.

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

#84

Post by EvanAnderson »

at_a_remove wrote: post #74
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…

I'm not so sure I completely agree with you about .ini files. I rather miss them. Some people have regarded the registry as a mistake, or at least an over-reach. I like the ability to edit .ini files and make them understandable. Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.

Please don't use INI files. The registry is infinitely more manageable for sysadmins than INI files. I hate it when your app makes me write scripts to manage settings versus just using the built-in tooling in Group Policy for dealing with the registry. (Yes, yes-- there is tooling in Group Policy Preferences for dealing with INI files. It fails spectacularly on malformed INI files. It has never been reliable in my experience.)

The idea of a centralized grammatically-accessible configuration store was a good idea (albeit this isn't want the registry was "for" originally-- it was just a file-type registry originally). GConf was a similar idea.

Devs misusing the registry to store opaque binary values (especially gigantic ones), accessing it with too high a velocity, and having a less-than-stellar file format have hurt it, for sure. Having few good schema rules or APIs that limited arbitrary developer access didn't help either.

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

#85

Post by at_a_remove »

EvanAnderson wrote: post #84
at_a_remove wrote: post #74

Earlier quoted context omitted.

I'm not so sure I completely agree with you about .ini files. I rather miss them. Some people have regarded the registry as a mistake, or at least an over-reach. I like the ability to edit .ini files and make them understandable. Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.

Please don't use INI files. The registry is infinitely more manageable for sysadmins than INI files. I hate it when your app makes me write scripts to manage settings versus just using the built-in tooling in Group Policy for dealing with the registry. (Yes, yes-- there is tooling in Group Policy Preferences for dealing with INI files. It fails spectacularly on malformed INI files. It has never been reliable in my ex…

Okay, so that's the sysadmin perspective. Tell me about the user perspective.

Then, we should talk about, when they are in conflict, which one comes first.

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

#86

Post by adontz »

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…

I believe the following is the solution. https://learn.microsoft.com/en-us/windows/win32/secauthz/app... No?

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

#87

Post by EvanAnderson »

at_a_remove wrote: post #85
EvanAnderson wrote: post #84

Earlier quoted context omitted.

Please don't use INI files. The registry is infinitely more manageable for sysadmins than INI files. I hate it when your app makes me write scripts to manage settings versus just using the built-in tooling in Group Policy for dealing with the registry. (Yes, yes-- there is tooling in Group Policy Preferences for dealing with INI files. It fails spectacularly on malformed INI files. It has never been reliable in my ex…

Okay, so that's the sysadmin perspective. Tell me about the user perspective. Then, we should talk about, when they are in conflict, which one comes first.

A dev is going to include UI to manage the settings if non-technical users are expected to modify them. Whether those settings go in an INI or the registry doesn't matter at all for that UI.

Having said, that level of technical skill req'd to edit an INI or the registry is about the same. Either way you're talking about a non-technical user descending thru a hierarchy of strange-to-them named containers to get to an arcane-looking location where settings are saved.

The user is going to call me when they have problems. It's easier for everybody if I can just administer the software centrally so they don't have problems to begin with.

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

#88

Post by semolino »

mrguyorama wrote: post #65
AlienRobot wrote: post #58

Earlier quoted context omitted.

>if you run code on your computer, it can run code on your computer For the love of God will someone please just make a web browser that isn't a web browser and it's just a cross platform multimedia sandbox with a couple of APIs in it, and you can run programs written in rust or something on it, and it doesn't let the programs touch your file system unless it has explicit permission? That would solve 99% of the appli…

It's called iOS. Browsers are also NOT safe. You know what was safe? Not letting random endpoints ship you code to run. HTML was safe, though implementations at the time likely had security flaws. You cannot make a turing complete language that JIT compiles into machine code and verify it as "safe". Machine code is not safe, so anything that lets you generate arbitrary machine code cannot be proven to be safe. If you…

On a related note, I appreciate the ability to specifically disable JavaScript JIT in GrapheneOS' browser, Vanadium. Theoretically, it's a nice balance of maintaining site compatibility (as opposed to disabling JS entirely) and reducing one's attack surface.

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

#89

Post by Wowfunhappy »

EvanAnderson wrote: post #81
bhdlr wrote: post #77

Earlier quoted context omitted.

Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit

The sheer volume of legacy software prevents this from being realistic. Microsoft's commitment to backwards compatibility has reaped rewards for them. Any restrictions would have a user-controllable toggle. If APIs prevent programmers from stupid shit the devs would encourage the end users to blame Windows and, more than likely, turn off the restrictions. (Case in point: User Account Control and making users non-Admi…

What if Microsoft limited these APIs to programs with "Compatibility Mode" enabled? (And—this may already be the case, I'm not sure—made it impossible to enable compatibility mode programmatically?)

I feel like this would create a strong incentive for modern software to do things "properly", while still allowing legacy software to run (albeit with a couple of extra clicks).

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

#90

Post by withinboredom »

nulld3v wrote: post #83
bhdlr wrote: post #77

Earlier quoted context omitted.

Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit

I don't think this is fair. Linux and Mac used to operate in generally the same fashion. Only recently have they started sandboxing stuff. Windows doesn't have the same privileges because they are forced to maintain backwards compatibility.

It's just as bad there with everyone randomly shoving dot-files in my home directory instead of using ~/.config, ~/.local, ~/.cache, and friends.

Just to name a few in my home dir ... aws, cargo, dotnet, yarn, vscode...

All of these narcissistic tools are pretty annoying.

Post reply on HN