Three Major Bitwarden Security Issues

Code Contributions (Archived)
1

Security: Bitwarden Desktop app grants RCE to Bitwarden developers. · Issue #552 · bitwarden/desktop · GitHub

This is the first one. The Bitwarden desktop app grants full Remote Code Execution ability (RCE) to the Bitwarden developers via an unattended autoupdate mechanism that rewrites the local application code automatically on command from Bitwarden’s developers (usually performed in the case of a new version). This allows the Bitwarden developers, or anyone who can compromise the Bitwarden developers, or anyone who can coerce the Bitwarden developers (legally, like in the case of a demand from a national military, or illegally, like a kidnapper), to push a backdoored update version that would automatically compromise/upload 100% of the keys/passwords of every Bitwarden desktop user.

Security: Bitwarden's default match detection leaks client passphrase to community.bitwarden.com javascript · Issue #1396 · bitwarden/clients · GitHub

this is the second one. The default match detection on the browser extension is incorrect for the *.bitwarden.com domain, which means that your MASTER PASSWORD used on vault.bitwarden.com is leaked to the (relatively insecure) javascript application running this instance of Discourse for the web forum at community.bitwarden.com. It attempts to autocomplete because the second-level domain is the same, allowing all of the javascripts running on this app (Discourse) to potentially read/steal/upload your master password.

that same website, but at /bitwarden/web/issues/659

(This one isn’t linked because apparently new users can only put two hyperlinks in a post.)

The other is an issue with the Vault web application. The Content Security Policy (CSP) provided by the server allows three third-party organizations (PayPal, Stripe, and Braintree) privileges to potentially backdoor the application’s javascript (entirely at the sole option of those three services), again potentially leaking/stealing your master passphrase or every password to every site in your database.

This means that any attacker that can control those domains, or otherwise compel/coerce those domains to serve modified javascript, can steal all of your passwords.

Reported By

I’m sneak, aka Jeffrey Paul, aka @sneakdotberlin on Twitter. I can be reached at [email protected] or via Signal at +1 312 361 0355 if anyone has any questions.

4 Likes
2

Shouldn’t security issues be private? Why not report this to hacker one as a report?


Its up to you. I am no expert.
3

Shouldn’t security issues be private?

All of these issues are based on fully public information. Anyone paying attention, including malicious parties, can see these obvious issues, so there is no downside to publishing them: there are no secrets here. Correspondingly, I publish all of my research and findings immediately, so that end users may make informed choices at all times. Why should Bitwarden be entitled to the information about their errors but you, their consumer/customer, not?

More importantly, however, is that the biggest of these are deliberate design choices by the Bitwarden team, which explains the accusatory tone in at least one of them. This isn’t some oversight or “oops” or hidden discovery, this is the insecure system working as intended and designed and deployed by the Bitwarden team. Please do read the issues.

It’s my hope that by shining a spotlight on these choices, the userbase can pressure Bitwarden to make better choices in the design of their software. Making careless choices for convenience features, security-be-damned, like this one in security-critical software is really destructive and should be actively discouraged. Bitwarden-the-team didn’t discourage themselves from doing this, so it’s up to other people to do so now: you and I.

I expect to hear something like “Autoupdate is good for our users, and our users want it to always be the latest version, so this is why we do it.”, but it turns out the users don’t actually want what fully automatic autoupdate necessarily and inevitably entails, which is a vulnerability called “remote code execution”: the ability for a very large group of people (the sum of the national militaries and governments in the entire list of countries/jurisdictions of Bitwarden staff who can cut and push a release for the autoupdater, as well as any criminals in any of those staff’s places who are willing to coerce with violence) to steal 100% of every bitwarden end user’s passwords via an automatically deployed backdoor.

If I’m giving 100% trust to the provider’s staff instead of the correct functioning of the software itself, then why does it even bother getting encrypted? Surely you see the issue. It’s an encryption backdoor, whether they intended it to be such or not. (I assume they did not.)

It’s worth noting that this vulnerability, the ability for Bitwarden-the-company (or anyone who can control Bitwarden-the-company’s releases/deployments, such as a government or military or kidnapper/extorter/blackmailer) is inherent and unavoidable in the web-based version of bitwarden-the-software (at vault.bitwarden.com), because it’s technically impossible to ship secure end-to-end encryption software via a webpage.

At all times when using web applications (like vault.bitwarden.com) you are 100% trusting the server to ship you safe encryption code that won’t steal your keys and secrets. This is the way browser apps have to work: there’s no way around it.

They’ve ported the exact same “100% trust in the server” vulnerability which is an unavoidable requirement in a web application over to their web-technology-based desktop application as well (even though desktop apps don’t have to have this same vulnerability), so it’s entirely possible that they won’t see this as a problem to be fixed (because they’ve chosen to build a web app that unavoidably always has this issue): hence public disclosure, so that you can decide for yourself if this is wise or not.

Why not report this to hacker one as a report?

Use of HackerOne requires agreeing to their Terms of Service, and it’s not reasonable to expect that anyone who wants to report or publicize an issue go and agree to some uninvolved third party’s legal contract just to say “hey this is a problem”. I have no desire to create a HackerOne user account just to file some design defects which are plain as day to any user of the software.

4

Another argument in favor of immediate publication is that my previous security issue report for Bitwarden from almost a year ago (which was assigned CVE-2019-19766) is still not fixed.

Three days ago @tgreer said that the year-old issue is not being worked on, in another post here that I can’t link to (because I’m limited to a maximum of two links per post for some reason).

I don’t have high hopes. As a Bitwarden user I really hope the company starts taking security seriously and fixes these issues ASAP, because it’s going to be a big amount of work to switch to a different password manager (and change all my passwords) if they don’t immediately start fixing security problems when they’re reported. A password manager is security software; if it’s not made and kept secure it’s worse than useless: it’s a seatbelt that doesn’t work.

1 Like
5

Thanks for the very detailed explanation. Yes, Users should be aware of the vulnerabilities. Thanks for reporting them.I hope the team will fix these issues as quickly as they can. Many users in the past have requested an option or way to turn off automatic updates.They are downloaded immediately at startup of the app.
Recently, I saw a video on Youtube which addressed the security issues of web clients of end to end encrypted application like ProtonMail, Tutanota, Whatsapp etc. I wondered if this applied to the web vault as well. Also, I came to know Signal is secure as they do not have a web client.

6

For tracking of the underlying design issue, I created another issue for the web app, which is unfixable so long as the web app exists:

I’m not permitted to post a link to it for some reason, but it’s also on GitHub dot com, at

/bitwarden/web/issues/660

7

So its best to use the web vault only at emergencies, right?
Here is the link

https://github.com//bitwarden/web/issues/660#issue-705107304

1 Like
8

Why is this hidden?

1 Like
9

Hi @sneakm, welcome to the Bitwarden community forums! I would highly encourage you to review the direction on where to post within the forums so your posts can be understood and get the right attention from the community, including the Bitwarden team.

The “Contributions” section of the forums where you’ve posted this is intended for folks who wish to contribute and want to ensure a) their contribution would be accepted and b) to get feedback from the community and Bitwarden team before embarking on any development work (preventing wasted effort, etc.).

So, while I’ll be closing this thread here momentarily, let me take a moment to aptly respond assuming contributing was your intent of this post (i.e. you wish to make contributions to the Bitwarden code and community):

  1. Desktop auto-update is not going away. We do sign our releases and manage them accordingly, auto-update allows us to fix and patch vulnerabilities, etc. and users naturally need to have some level of trust in our company, products and employees, including our build environments (which should also be visible in Github Actions). If you wish to operate a desktop application without auto-updates, I would encourage you to compile the client apps yourself, maintain your own offline vault, in a closed-network environment w/o internet access and proper firewall/NAT rules, proxies, bastion hosts, etc. to create the virtual faraday cage you require for absolute control over your operating environment also preventing OS auto-updates and any other software updates from running as well. I would imagine 98% of users don’t require this level of control and are better served by auto-updates.

  2. Our match detection has been working very well w/o incident. When issues are detected with our match detection they are fixed with the utmost priority, for obvious reasons. We offer different types of match detection along with custom regular expressions, etc. for more advanced use-cases. As far as compromised credentials, I would encourage you to not use automatic auto-fill/submit if that is a concern.

  3. The CSP that drives appropriate permissions for PayPal, Stripe and Braintree are in place to support scripts solely on our checkout/billing pages and further only when the user takes explicit action to add funs/checkout when upgrading their plan. We don’t “willy-nilly” include scripts from these services across the entire site.

Further on this point, if you feel there is a legitimate vulnerability, I would encourage you to actually provide a HackerOne report with proper steps to reproduce and stage a would-be compromised site/domain, even if using a hosts file for PayPal, for example, and alternate SSL certificate, etc. and attempting to coerce vault data (unencrypted or otherwise) out of sessionStorage/memory using JavaScript… otherwise this becomes a non-productive theoretical argument.

4 Likes