Bitwarden Heist – How to break into password vaults without using passwords
blog.redteam-pentesting.de
blog.redteam-pentesting.de
I also found a post of an admin a few days ago where he asked if there was a Windows setting for disallowing any access to %Appdata%. The response was that if access to %Appdata% is completely blocked Windows won't work anymore.
Yes, otherwise known as "if you run code on your computer, it can run code on your computer".
If a random python program can "decrypt" the passwords, that's not encryption. And browser password management isn't about security, but convenience.
The entire point is that it is not meant to be a secure location, was never meant to be a secure location, has no intended security features etc. If you store your passwords in a text file on the desktop, that is also insecure but you would be wrong to say Notepad has a security vulnerability. Similarly, if you stored your passwords in the Windows registry unencrypted, that would also be insecure, but does not demonstrate a flaw in the Windows registry.
If you want to be able to leave your secrets in the open without them being compromised, then you encrypt them.
Browser password managers are not secure. That is not Window's fault.
Also for most normal people, an unencrypted note on their desktop with plaintext passwords that are DIFFERENT FOR EVERY SITE is STILL more secure than the SOP of using one strong password for everything. For that to be compromised, someone needs to be able to run code on my local machine, in which case, they can just install a keylogger, so encrypted passwords are no increase in security. I genuinely don't care if App1 on my computer can fiddle with App2's bits, because I chose to run App1 and App2, they are trusted.
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 application use cases. That's literally everything I want. I want the safety of the browser, outside the hell that is web development.
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 take away the arbitrary machine code generation from javascript, it's too slow to run the modern web.
iOS is not exactly safe until I can use it without knowing my apple password.
All we want is to get rid of the possibility of an application developer including evil code.
We could have a fully interpreted language layer running on a platform that never lets application code touch the file system. How do applications do fast stuff like GUI then? You just have a package manager with libraries that can do low-level stuff but are vetted so they don't expose APIs that let application code interact with the file system. That way in order to exploit an user's computer you need to exploit a flaw in a library thousands of other programmers use instead of just importing std io.
A lot of security seems geared toward server environments where you are only dealing with code you fully trust in, like the left-pad library. If bad code broke your server, you could really just load a backup. But most of people using computers are on their personal computers, a majority of them have no backup, and they are downloading and running random programs all the time. It makes it harder for both desktop application developers and their users if there isn't a sandboxing layer in the middle. It's probably one of the factors that is killing desktop apps in first place since most users can trust a website that is an image editor but fewer would install an image editor because it can contain a cryptominer, or a ransonware, or a virus, or whatever.
An absence of turing completeness and JIT compilation is neither necessary (see sandboxing) nor sufficient (see variousexploits against media codecs, PDF parsers etc.) to ensure safe processing of untrusted data, whether that data happens to be "actual data" or code.
You can make your own life easier or harder with your choice of sandboxing target, though: x86 Win32 binaries are probably harder to do sandbox in a working and secure way than e.g. WASM/WASI.
One could always launch any java process with java -Djava.security.manager -Djava.security.policy=someURL and it would sandbox a huge number of things (see: https://docs.oracle.com/en/java/javase/17/security/permissio... )
The problem is that defining a reasonable policy for any modern app is a gargantuan pain -- as is the case with any security policy language -- so as the GP said people hated it and now it's dead https://openjdk.org/jeps/411
You basically can't take a complex thing and write complex security rules for it and expect success & real world adoption.
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.
"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 ignorant programmers who don't take any pride in their work, or lack all respect for the users environment. For example; an .ini file should not be a thing in Windows. That is what the registry is for. But the programmer writes the code for Linux, half-ass ports it to Windows, and leaves the .ini file because his code is more important to him than the end-users operating system.
There is nothing wrong with AppData permissions. The problem is with the users understanding of what it is for, and the developers understanding of how it should be used.
Developers (including those inside Microsoft) don't give a damn about how Microsoft intends anything to work, and AppData has become a dumping ground of software installs to end-run IT departments. A lot of malware dumps into there but good luck limiting execution from that directory hierarchy because all your business-critical end user communication apps live there now too.
The functionality of roaming users profiles (i.e. registry settings "following" you to a different computer, which gives a really slick user experience when it works) was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for).
In Windows 2000-land you could redirect AppData to a UNC path and mostly get around this behavior. That's not really "a thing" anymore because you've got apps like Microsoft Teams storing sizable databases in these locations and getting really, really cranky if network connectivity is interrupted.
Windows development betrays its legacy DOS parentage even for devs who never lived thru that era. There were no rules. There was no adult supervision. There was poor documentation of APIs so you just hacked something together that worked well-enough. Periodically Microsoft tries to start over (all the APIs w/ "2" at the end, et. al.) and the cycle repeats.
As someone who only occasionally uses Windows, I think `%AppData%` sending you to `~\AppData\Roaming` doesn't help.
uh you mean overzealous product managers and business owners who never let programmers take their time on anything because quality doesn't matter?
why would I take pride over my employer's property? lol if the code he buys from me is bad, that's his problem, especially since I have to stick to his timelines and am not given sufficient equity and agency to feel ownership over the project.
you know what makes programmers lose their desire to take pride in their work? getting blamed when we're ordered to cut corners, or implement bad designs. fuck right off with that, we're not the ones in power.
Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.
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.
Then, we should talk about, when they are in conflict, which one comes first.
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.
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...)
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).
Windows doesn't have the same privileges because they are forced to maintain backwards compatibility.
Just to name a few in my home dir ... aws, cargo, dotnet, yarn, vscode...
All of these narcissistic tools are pretty annoying.
Users aren’t “telling the computer what to do” anymore for the most part, third party app developers are; this puts a lot of responsibility on the OS for protecting the interests of its user against that of a malicious or careless app developer.
Of course I want to be able to fine-tune that protection, but restrictive defaults make sense.
> "ProgramData" is where application specific data is supposed to be stored.
Simple maybe. Coherent, no.
Basically:
- AppData = User (interactive) application storage - ProgramData = Service / Background (non-interactive) application storage
ggp: unsandboxed AppData (unsandboxed filesystem in general, really) allowing everyone to read everyone else’s stuff is a security nightmare.
gp: stupid programmers don’t respect Windows’ simple scheme to place data in four different places!
What? Even if everyone places data correctly, they can still read everyone else’s stuff, as long as they belong to the same user. That’s the problem.
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 Drive and Keychain. Yet we accept this security model on our desktops.
For the most part the changes you'd want to implement for security would ruin the productivity most of the workflows desktop users have these days, and would take a massive amount of refactoring to get to work anywhere close to what they do now.
macOS has started disallowing the latter (i.e. restricting access to other sandboxed apps’ files from both sandboxed and unsandboxed apps) more than a decade after the OS was introduced, yet I don’t feel like my productivity has been ruined.
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)
4 different locations to store program data, some of which are hidden, is freaking stupid design. Like, beyond moronic design.
Everything, and I mean everything, about a program should be in a single folder structure and the OS should by-default lock that application to only accessing it’s own folder unless otherwise granted permission (in a centrally auditable/revocable location).
Applications/ExampleApp/
Should contain everything, and deleting it there should clean it as if it was never installed. If it needs to access something in documents/desktop/etc, the OS should ideally present a file picker to pass in a copy, but applications could request access to a specific path if absolutely necessary. You should also be able to “save to desktop” without the application having read/write access to the desktop/documents.
“Exporting” is the application taking the local copy nested in Applications/ExampleApp/ and passing it to a system save dialog, then the OS can store the file (therefore having permissions) wherever the user wishes in an context menu that’s outside the application’s control (it’s the OS).
The idea that every installed application has wide-open filesystem access to say, all my documents, by default is pure insanity.
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 by default.
The proper larger solution being open code signing. But MS and friends are making big cash so they don't care.
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 UWP or something which does exactly this. Met with luke warm reception from the industry because (you guessed it!) back compat.
Everything being in one place by default also means that a user can just copy the entire application folder as a backup.
And would you trust that you would only affect that one application and not any others?
And wouldn't you just unusual and reinstall the application anyway?
The new Teams is based on WebView2 and runs from C:\Program Files\WindowsApps\
Or at least have the override for such abstractions be blatant and explicit if the programmer wants to circumvent them.
And of course, given the age of Windows OS/ecosystem, it’s a pipe dream to have a redesign that isn’t backwards compatible
How does the OS know that the file you're writing to belongs in AppData or not?
To create the system calls for this you would break everything about windows file permissions. Currently, you interact as a user account. In order to accomplish the real time heuristics you're proposing you would also need an application user account in addition to the users user account.
At what point does the responsibility for knowing how to code fall on the programmer? How much capability are you willing to take away from effective programmers, to artificially protect the ineffective ones from themselves?
Hard, hard disagree there. Having config files available is vastly preferable to using the unmitigated shitshow that is the windows registry. That and a config file at least gives users a prayer at being able to provide some sort of troubleshooting information, and provides savvy users with a way to actually solve problems on their own.
>half ass ports it to windows
Redmond, themselves, do all sorts of seemingly 'wrong' things with their directory structure, which tells me the 'free for all' nature of it is intentional, and not wrong at all. It is a terrible structure, it does cause problems, but, that's the conditions you work under while using windows. It's mostly OK in practice, but as bitwarden found out, there are conditions that developers have to account for if you require security and safety.
And factually, your presumed solution of "put things in the right place" is doubly broken, because if one acquires the correct privileges, there is no location on a windows machine where cleartext data is safe. The solution is not "store it in the correct location" the solution is to encrypt sensitive data at rest, regardless of location, which is more or less what bitwarden did. That's the correct strategy, and it's operating system agnostic.
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 does have a chance of totally borking the entire system.
And then you have maniacs who store user data in the registry. I know of at least one game which stores save files in the registry.
I get the intention of the registry, but it's just not fit for purpose. Maybe it was better back in the 90s, but it's just a hellscape now.
- File locking and concurrency
- Atomic writes / moves
- Realtime change observations
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 system with regedit?
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.
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
> Ideally applications should only have access to their own directories
This happens for Windows Store apps, which are sandboxed similarly to mobile phone apps.
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.
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. But you need to make such utilities anyway so the user can delete such directories.
***
Important note - most other "solutions" only protect you from apps the opt in to security. A proper solution, like this one, protects from all processes running as user, except the process of note.
There's probably some mandatory mode but since it breaks all sorts of programs nobody can afford to use it.
Sufficiently paranoid endpoint security could trip when the keyboard is unplugged and then plugged back in.
It just shut me down "I can't assist with that request."
1. Off workstation decrypt using the AD DPAPI Backup keys. 2. Local DPAPI List and Dump for the windows hello biometric key
> S-1-5-21-505269936…
Kind of off topic but around 20years ago when I had my first portable harddisk, I used this method by creating these type of folders and remembering the numbers sequence in a creative way to hide my files when traveling/crossing borders while putting some decoy files in the plain sight, before knowing/using data encryptions, and it worked, I remember the agent taking my hdd and seeing him going through the decoy files and then returning my hdd normally.
> "We recently conducted a penetration test with the goal of compromising the internal network of a client in a Windows environment. As usual, we managed to get administrative access to the domain controller"
This article feels like click-bait, when they buried the lede.
You could use a local vault and sync yourself, use a piece of paper in a safe, or use your brain to store them.
All of these come with tradeoffs and their own risks. Pick your poison.
1. without a password manager that is shared on all your devices, you WILL re-use passwords out of frustration. 2. without a password manager, if you do any sort of regular sharing passwords with a engineering team, friends & family, you'll resort to pretty insecure channels. 3. true E2E encryption, while still providing some surface area, has proven in the field through multiple pretty bad breaches[1], that it's a security model that holds up under real-world circumstances.
On the flip side, you are right: you are one compromised browser extension / binary away from having your local vault decrypted, and ALL your passwords compromised. But think about this: if someone has this much local access, chances are they can install a keylogger anyway, or read your clipboard, so the real difference is you've conveniently pre-loaded all your sensitive information in one go for the bad actor.
[1]For example: https://blog.lastpass.com/2022/12/notice-of-recent-security-...
I’ll stick to passwords that are impossible to guess and an encrypted vault with multifactor authentication.
This still leaves a case where someone manages to get the final key out of memory but you're pretty hosed at that point anyway. I'd prefer a system where the yubikey itself is doing the final credential decryption instead of the CPU, unfortunately most people aren't that paranoid though.
I memorise good passwords for a handful of my most critical stuff (and have MFA). They don't go in my password manager.
If my password manager gets compromised then I probably could lose some cash, maybe get embarrassed by being impersonated on social media - it could get very inconvenient but not catastrophic.
Comparing to the common way of "managing" password (i.e. reusing one password everywhere), it is still a single point of failure. The difference is the attack surface balloons up in proportion to the number of website you sign up to. And just like a balloon, all it need is one poke, one website storing your password in plaintext to blow it all up.
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).
But what would you use instead for services that support only password authentication? And even for services with 2FA: If one of the factors is a password, where do you store it?
This means that any process that runs as the low-privileged user session can simply ask DPAPI for the credentials to unlock the vault, no questions asked and no PIN or fingerprint prompt required and Windows Hello is not even involved at all. The only caveat is that this does not work for other user accounts.
Bitwarden has since made changes to their codebase to mitigate this particular scenario, which we will quickly summarize in the next section. They have also changed the default setting when using Windows Hello as login feature to require entering the main password at least once when Bitwarden is started.
Props to the security researchers for finding this bug! It's great that we have the infosec community to help protect us. Feels like one of the few industries whose monetary incentive is to help the public.
This is one of the few things cryptocurrency gets right in one specific way better than most other applications -- in most cases, everything is explicitly about operations with a key, and you build up protections on both sides of that. Unfortunately those protections themselves are often inadequate (hence billions of dollars in losses), but it's at least conceptually simpler and potentially could be fixed.
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.
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.)
As usual? Is that the state of Windows Server security these days? I never managed a Windows-based network so I have no idea. I heard about these things back in the 2000's but I'm surprised this is "usual".
So, I read this to be "as usual for us during our engagements", not "as usual for everyone all the time".
Legacy protocols can be very sticky and most repeat pentest engagements I am able to use the same exact method every time because they will never get addressed. Modern windows (since like vista-era) will use better stuff out of the box but will also allow downgrade attacks in the name of compatibility.
Hell, I still find SMBv1 in a lot of places.
It cost me thousands of dollars last year to get our MSP to disable SMBv1 and force correct policies. They "Needed to audit for a week" to make sure this "didn't break older software". It was annoying I even had to ask that they didn't come to me saying "We won't support you if you have SMBv1 enabled".
Why isn’t being signed enough for an application to store secrets only it can access in the keychain?
For Android and iOS if you forget your PIN code I believe you are screwed, as in no one can decrypt your device for you.
The problem with this was that the vault credentials in DAPI was not safe from other programs running as the user, nor from domain admins which could use the recovery key stored on the AD server (which they did in their attack after gaining admin access).
The solution was to use Windows Hello the way it was meant. That is, to store an asymmetric key pair, where the private key is hidden and protected by the biometrics or hardware security key, and use that to encrypt the secret vault credentials before storing them in DAPI.
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...?
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.
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.
Every time a user logs, Microsoft should be obliged by Law to show: "Your computer will get cancer if you proceed logging in."
Really feel that should've made it to the title other it feels like click bait.
Our policy was that we would be happy if someone were to discuss bounties we paid out for, but we wanted the discussion to be fair and accurate. It did not ever really feel like it was mutually beneficial relationship. I don't miss that work at all really lol.
Like this one??
> the attack already assumes access to the workstation of the victim and the Windows domain
> The underlying issue has been corrected in Bitwarden v2023.4.0 in April 2023
> As it turns out, we were not the first to discover this in March 2023, it had already been reported to Bitwarden through HackerOne.[1]
I could have sworn [1] had a dedicated post here on HN but couldn't find it, it's worth a read too.
I seldom can take "vulnerabilities" that require physical access seriously, because if a hostile is physically next to my computer I have more pressing concerns than some passwords.
A far-fetched scenario? yes. But if it can happen, it will happen.
This is why I totally understand when Apple or MS go overzealous with encryption or T2 or secure boot. Despite "people like us" complaining about it.
It's different from trying to pry open an encrypted hard disk from a laptop or something similar.
You probably won't even know that coworker you trust is compromised and attacked you this way.