Closing: BWN-01-008 – Malicious API server could steal organization encryption keys

[paragonie-scott]

Despite what the Cure53 audit report says, this isn't an intractable problem. Solving it isn't drop-dead-simple, but 90% of the work is done already. The problem is related to the problem of secure code delivery although with focus almost exclusively on public keys rather than update files.

• https://github.com/paragonie/chronicle#userbase-consistency-verification
• AnarchKey: Experimental PKI for Securing Software Updates paragonie-scott/public-projects#5

All you need to do is maintain an append-only cryptographic ledger of Bitwarden servers and their public keys. Chronicle was specifically designed for these sorts of use-cases.

Then you can simply add a process publish all servers' public keys into this ledger. This allows you to build an independently auditable history of all public-key <-> identity associations. Any attempt to backdoor a Bitwarden user will be irrevocably detectable, since attackers will have to announce their presence to all users in order for any user to accept their malicious public key.

Not only does this provide confidence that nobody has provided a malicious public key, it also serves as a legal deterrence to nation states that cannot compromise computers in their own country (i.e. NSA).

This deterrence is a consequence of the userbase consistency feature: In order to compromise anyone, you have to put everyone at risk. Additionally, you abandon all stealth in doing so.

[kspearrin]

Thanks for the suggestion, however, I am not sure I understand how this would fit into the a design to provide public key authentication to the Bitwarden clients

1. API server publishes users and their associated public keys to this ledger?
2. Somehow the clients validate the returned API public keys with this ledger? How would that be done?

I am coming at this with no experience in using blockchain technologies before, though I do have a basic understanding of how they work.

[paragonie-scott]

I'd hesitate to call this ledger design a blockchain for various reasons.

You can have two separate ledgers:

1. Totally local, records changes to users' public keys.
2. Central to Bitwarden's official server, only authenticates servers' public keys; has no concept of users.

If you decide that only one of the two is necessary, that's fine too.

The basic idea is that you can force public keys to be committed to the ledger in order to be trustworthy.

In the first case, you're authenticating local users' public keys in a way that is auditable even if the API server is malicious (i.e. hacked). In the second case, you're authenticating the servers themselves. The latter might be less useful.

This allows you to verify public keys even in the presence of a malicious API server, and even in the worst case scenario (a collusion between the malicious API server and ledger), you create an irrevocable audit trail of the compromise which allows investigators to narrow down who was affected (n.b. it's really obvious when only one public key is swapped out). This is assuming attacks succeed; if suddenly a public key changes for another user, you could simply block the change unless it's recorded in the ledger and then only accept it based on some policy (e.g. user acknowledgement).

It may be helpful to review exactly which issue I'm seeking to address here:

If the Bitwarden server were to be compromised (specifically the API server) it could be used to serve forged public keys and steal information stored in an organization’s vault. This would only be possible if an organization admin were to confirm a new user to their organization while the API server was in this compromised state.

...and...

As it stands, the Bitwarden server acts as a trusted public key server. Unfortunately, this is not an easy problem to solve for a couple of reasons:

1. The only known solution would be to allow users to perform a side channel method of
   authenticating public keys returned by the Bitwarden server during the confirmation step of every new organization user. This method of authentication would need to be completed by manually verifying the returned public key’s fingerprint with the new user via in person, phone call, through email, etc. Since this process cannot be automated, this method of authentication would not provide a friendly user experience for organization admins going through the already somewhat burdensome process of onboarding new users.
2. The process for managing an organization is done by using the Bitwarden web vault. The web vault is already vulnerable to malicious server attacks due to the remotely hosted nature of how websites work in general. If the server were compromised to a state where the attacker could forge public keys returned by the API, that same attacker would likely be in a position where they could publish malicious client-side code to other parts of the web vault. This would certainly be a much easier way to steal user's encryption keys rather than forging public keys during the onboarding steps of a new organization user.

As long as users have a need for using the web vault (a critical business requirement for Bitwarden) they will always be vulnerable to malicious server attacks and are required to place a certain level of trust in the server that they are accessing. Going forward, we will continue to investigate the possibility of adding additional methods of public key authentication (see #1 above) using other Bitwarden client apps, such as the desktop app, which are less susceptible to malicious server-side attacks.

We will also further prioritize making more general features (ex. master password changes, data imports, organization management, etc.) available in other Bitwarden apps so that users do not have to rely on using the web vault for certain tasks.

Finally, it should be noted that users also have the ability to self-host the Bitwarden server on their own trusted infrastructure which would remove the risks associated with this issue almost entirely.

A lot of the explanation from this section of the report is actually incorrect in general (but correct as Bitwarden is currently implemented). There are ways to address these server trust issues without requiring self-hosting.

What I proposed above is a solution that allows an API server to verifiably respect the principle of least authority.

[Hinton]

We use GitHub issues as a place to track bugs and other development related issues. The Bitwarden Community Forums has a section for submitting, voting for, and discussing product feature requests like this one.

Please sign up on our forums and search to see if this request already exists. If so, you can vote for it and contribute to any discussions about it. If not, you can re-create the request there so that it can be properly tracked.

This issue will now be closed. Thanks!