Recently, a user in the Bitwarden subreddit posted information on how to bypass the master password requirement prior to exporting the Bitwarden vault en mass, and published code to achieve this bypass on his blog.
Because the bypass requires modification of the extension on the targeted user’s computer, and with consideration to exclusions published on the Bitwarden bug bounty page (HackerOne) regarding exploits that require “physical access,” I’m asking for official clarification from Bitwarden whether this will be tracked as a vulnerability for remediation, and if so, in what time window is remediation likely to occur. AFAIK, this hasn’t been reported as a vulnerability because the author developed the bypass to help users (including himself, apparently) recover from a forgotten master password, not as an exploit, though the effect is the same.
My interests are specifically related to Bitwarden for Business product, as the issue is not likely to be a concern to personal users.
This is not a previously unknown issue/vulnerability, because it is simply one of many ways to read the unencrypted vault contents that are contained in device memory while the vault is unlocked. It is well-known that it is trivial for a bad actor with physical access to a device that is running an unlocked Bitwarden client to extract a copy of the unencrypted vault contents. There is no need to do anything as complicated as what has been proposed by Mr. Pastusek, a simple memory dump will be sufficient.
It is the users’ responsibility to keep their vaults locked when not in use, and to secure their devices against access by unauthorized individuals. In a business environment, you could set up something like a group policy to enforce Dynamic Lock, so that computers are automatically locked when an employee steps away.
Since you’ve asked for “official clarification from Bitwarden”, I should make it clear that my comments are my own; I am not a Bitwarden representative or speak for them.
P.S. I have moved your post to the Ask the Community section of the forum, since it did not contain a feature proposal.
I agree this is one threat vector. However performing a memory dump requires putting a debugging tool or RAM scraping malware on the target machine and either local admin or system privileges above normal business user privileges, to read out-of-process memory. This is a noisy process, both in the file transfer stage, privilege escalation stage and memory analysis/scraping stage. This noise provides defenders several opportunities to detect and interrupt the kill chain before credentials might actually be exfiltrated.
Pastusek’s exploit can be carried out without any additional tools or privileges on the target machine, or any system activity that might be detected and flagged as suspicious. There is also the principle of defense-in-depth that needs to be considered.
I also propose moving this conversation back to the feature request category, as the feature being requested is for Bitwarden to determine if this vulnerability can be remediated, or if it is an intrinsic risk for all password manager extensions.
You can access process memory without privilege escalation.
Edited to Add:
For example, in Windows, the easiest way is to open the Task Manager, right-click the process for the browser extension, and select “Create Memory Dump File”.
If your users are not allowed to use the Task Manager without privilege escalation, then an alternative approach would be to prepare a USB stick that has a portable memory editor/inspector (e.g., a freeware tool like HxD, or perhaps a custom-made script), then plug in the USB and run your tool to exfiltrate the memory content — no privilege escalation required.
This risk is intrinsic to all password managers that keep encryption keys and/or unencrypted vault data in memory while in use. Which I believe is all of them (although I’m open to hearing evidence to the contrary, if applicable).
I submitted a PR a while ago, disabling debugging access on the Desktop client for exactly this reason. At the time Bitwarden determined that the benefit of having access to the debugging tools for the users outweighted the “risks” since technical attackers can also take memory dumps.
Thus, I doubt this will be classified as a vulnerability.
My Bitwarden client, Goldwarden, uses some techniques for hardening. These are sadly not implementable in an electron app. Maybe in a native rust module…
The vault data itself is always encrypted, unless for a few microseconds, when accessed.The encryption keys are also protected using various kernel features and encryption.
Additionally, you could technically offload the password manager to a secure enclave such as Intel SGX. In that case, the secrets are really never present in unencrypted form in RAM. Though I have not had time to play around with this yet.
To be clear, none of these are absolute protections, but they make attacks significantly harder to engineer and reduce the number of situations in which it is possible.
In secured environments, normal users have no access to the task manager, command prompt or ability to use removable media. DLP is configured to flag any transfers of binary files. Each attempt to bypass these restrictions would generate an alert that the SOC will evaluate to determine if action is required, giving several opportunities to recognize and shut-down an attack before data can be exfiltrated.
Are you speaking as a representative of Bitwarden? Is this Bitwarden’s official position regarding this issue?
I am a Bitwarden customer, no different from you, and otherwise have no affiliation with Bitwarden. I do not speak for them, as I had previously clarified in my original response.
This is a community forum for peer-to-peer discussions, although Bitwarden staff also participate here from time to time. If you wish to communicate directly with Bitwarden, your best bet is to use the contact form.
Yes, I’m immature…