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

201–209 of 209 posts

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

#201

Post by rkagerer »

jabroni_salad wrote: post #125
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…

You forgot about "my documents", which is of course a great catch-all location for all four types of data you mentioned.

I actively avoid that dumpster fire. None of my actual documents live in any portion of My Documents.

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

#202

Post by rkagerer »

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…

They absolutely support DACL's. For the longest time I prohibited my own user account from modifying a certain registry key to prevent Dropbox from constantly reinstalling unwanted green checkmark overlays.

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

#203

Post by dvngnt_ »

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…

No way is that simple.

your rules would state "application specific data" would not reside in appdata even though those exact terms are there. it's the opposite of self-documenting

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

#204

Post by dvngnt_ »

gruez wrote: post #195
lxgr wrote: post #192

Earlier quoted context omitted.

Malware targeting unlocked local password managers would be one option.

In that case aren't you already hosed because the same malware can steal all your login sessions?

no because I'm not logged into all of my accounts at once but if they can open the PW database they can

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

#205

Post by lxgr »

briHass wrote: post #197
lxgr wrote: post #166

Earlier quoted context omitted.

Have you looked into how (whether?) Windows Hello actually checks which app is asking it to perform a private key operation? On Android, this is tied to the app UID, and on iOS/macOS it's tied (I believe) to the developer team identifier. Hopefully there's a similar mechanism on Windows...?

It doesn't, or at least it doesn't for traditional applications. UWP (store apps) might, but I've never seen it. To be fair, identifying an app when not delivered through some locked down store mechanism is actually problematic. DPAPI is tied to the user/machine account along with additional entropy provided by the application itself. It would be nice if MS added an option for DPAPI to use a hash of the name blessed…

Self-signed code signing certificates would seem to be a good compromise (like e.g. Android does it).

Even a hash over the executable (+loaded DLLs) would work in a pinch. Breaks app binary updates, but for a “stay logged in and unlock via biometrics“ feature (as opposed to “store this credential forever”), that might be acceptable.

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

#206

Post by hiatus »

Pesthuf wrote: post #153
hiatus wrote: post #79

Interestingly, the latest versions of bitwarden for mac that are available for download from github no longer work with biometric authentication, requiring the user to download the app from the app store in order to use that functionality.

I wonder why that is. Do App Store Applications get extra privileges? Why isn’t being signed enough for an application to store secrets only it can access in the keychain?

I too wonder. The App Store version did ask for keychain access for the biometric data, while the non-app store version did not (and never asked for that, to my knowledge).

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

#208

Post by rdl »

lxgr wrote: post #172
dannyw wrote: post #160

Earlier quoted context omitted.

I'm not convinced crypto is inherently less secure; I'd argue it's more secure on average. Data breaches happen every day; whether in financial services or not. The difference is that a breach is catastrophic for crypto; but just bad for most businesses.

Have any of these catastrophic failures happened due to client/wallet-side user confusion, though? I'm not a big fan of many things in crypto, but what I've seen in terms of "what you see is what you sign", clear user interfaces, secure user verification and confirmation etc. in some popular wallets is something that many existing banks could take a lesson from.

A lot of them -- the whole "phishing" thing happens to crypto users with regularity, and often for surprisingly large amounts. Usually not the single-victim/cause $100mm+ hacks, but lots of $1-5mm losses. The "new" fun thing is creating spoofed addresses where first 4 and last 4 characters match a target, but are controlled by attacker, but variations on getting users to initiate transfers to the wrong address are pretty common.

Crypto gets a few things really right, and can do some things which can't be done by tradfi, but has a huge number of problems which need to be solved (some are "open problems" which don't really have solutions yet; some are taking what the top 0.1% of people or what people do some amount less than 100% of the time and making it universal, which is mostly what I am doing now as CSO at a crypto insurance company.)

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

#209

Post by coffeeling »

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…

UWP wasn't just lack of back compat, it enforced things like apps sleeping on minimize which is nuts. This was in an attempt to make Windows a universal OS that's tablet and phone worthy.
Post reply on HN