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

191–200 of 209 posts

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

#191

Post by o11c »

viraptor wrote: post #178
o11c wrote: post #156

Earlier quoted context omitted.

I don't think it's possible on Windows. It's trivial on Unix - just make the program setgid and change the folder permissions to only allow the group. This can be nested, though that requires that the relevant program be aware of the need to walk through several levels, though often a symlink can hide that. Note that when creating such a directory setup, `chown`ing away the user requires a privileged helper utility.…

Or use selinux/apparmor - those have supported app sandboxing without group tricks for a long time.

Those are useless because they're opt-in, and we can't expect malicious programs to opt in.

There's probably some mandatory mode but since it breaks all sorts of programs nobody can afford to use it.

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

#192

Post by lxgr »

gruez wrote: post #184
lxgr wrote: post #171

Earlier quoted context omitted.

> Suffice to say, unless your last name is Snowden, it should not be a concern to you. I wouldn't be so sure about that. People store banking/payment credentials in them, so there is a large incentive to mount a scalable attack against an even moderately popular password manager. Crypto wallets are a popular target too for the same reason (although the risk is even more immediate there).

How are you going to "mount a scalable attack" against a local-only password manager?

Malware targeting unlocked local password managers would be one option.

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

#193

Post by giancarlostoro »

iudqnolq wrote: post #181
giancarlostoro wrote: post #44

Earlier quoted context omitted.

> The response was that if access to %Appdata% is completely blocked Windows won't work anymore. Yikes. I really wish that instead of Microsoft wasting resources on telemetry nonsense, they would focus on optimizing their OS and modernizing some of these blatant security issues. I guess it wont happen until we have another wave of ransomware malware or something of the sort.

That's like saying Linux doesn't have sandboxed apps because chmod -R 000 /var will break your system. Technically sort of right, but not a useful or interesting observation.

The difference being Windows is a much higher target for abuse since its the most commonly used OS for Desktop, somewhere as high as 70% marketshare or higher, depending on where you get those numbers from. It's also used a lot in corporate environments as well. Linux usage of /var/ and /etc/ differs depending on various factors too... Developers / distro maintainers put files in different places.

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

#195

Post by gruez »

lxgr wrote: post #192
gruez wrote: post #184

Earlier quoted context omitted.

How are you going to "mount a scalable attack" against a local-only password manager?

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?

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

#196

Post by viraptor »

o11c wrote: post #191
viraptor wrote: post #178

Earlier quoted context omitted.

Or use selinux/apparmor - those have supported app sandboxing without group tricks for a long time.

Those are useless because they're opt-in, and we can't expect malicious programs to opt in. There's probably some mandatory mode but since it breaks all sorts of programs nobody can afford to use it.

Apparmor is opt-in so it protects from exploration mostly, but selinux can definitely work with the whole system by default. It's not trivial, but you can at least prevent apps from accessing personal information unless explicitly allowed. I've been using it for years without issues. It really requires only a minimal amount of learning and you don't need to turn it off.

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

#197

Post by briHass »

lxgr wrote: post #166
RedTeamPT wrote: post #24

Earlier quoted context omitted.

Actually it is not just an issue with AD design, but the AD design only makes it slightly worse. The underlying issue is that biometrics are not required to retrieve the biometric key from DPAPI and instead of authenticating with Windows Hello, any program could just simply ask DPAPI for the key.

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 by a CA in a valid code signing cert. However, that wouldn't matter in this case, since they had domain admin and could easily manipulate the cert store.

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

#198

Post by rkagerer »

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…

It really is a simple concept

At first I thought you meant that sarcastically.

Microsoft got overzealous showing off their long file names back when that capability was introduced to their filesystem, and any sense of organization in the OS fell apart after that.

I actually miss .ini files. It was nice being able to keep your software's data alongside it (in a simple folder like C:\Programs\3DS) and made it easier to clean up remnants. I understand what drove the design, but a more sparing and opinionated approach could have produced a much more elegant outcome.

Incidentally, even Microsoft software is wildly inconsistent in how it uses the registry.

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

#199

Post by rkagerer »

pixl97 wrote: post #137
cameronh90 wrote: post #91

Earlier quoted context omitted.

The point is that, nowadays, apps should by default be isolated from each other, rather than AppData and HKCU being a free-for-all. Windows makes it hard to whitelist known-safe apps (there’s WDAC but it’s poorly documented and a PITA) and every program you run has access to everything of importance on your system. Imagine how upset people would be if it turned out TikTok on your phone can access your entire iCloud D…

We accept it on the desktop because the desktop app model is from before the internet. There was only 'trusted' applications that had access to all the users data (and really most of the time the entire machine), and really there wasn't even the idea of an internet connection being built in at all. In addition desktop applications are based around the ability to read the users data files. Desktop users typically want…

Older desktop apps also tended to be more trustworthy.

There's so much commodity garbage out there now (e.g. I find it near impossible to find quality ad-free apps on Google Play)

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

#200

Post by rkagerer »

burnte wrote: post #66
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…

Thank you! And Program Files is for x64 windows apps, Program Files x86 is for 32bit apps but vendors use both interchangeably and sometimes use both for the same app!

Don't forget about Wow64 and redirection ;-).
Post reply on HN