Vulnerability in Vaultwarden's access management
Especially in times of increasing cybercrime, the protection of sensitive company data is more important than ever. You may already rely on password managers like Vaultwarden to securely store and manage your organization's data. But even proven solutions can have vulnerabilities.
On behalf of the German Federal Office for Information Security (BSI), we have thoroughly reviewed the open source application Vaultwarden. Using state-of-the-art methods such as static code analysis and targeted dynamic analyses (pentests), we have delved deeply into the security of these solutions.
In the process, we discovered a security-critical vulnerability in Vaultwarden: Formerly authorized users could continue to access confidential organizational data despite having their access rights revoked, including data that was newly added after the rights were revoked. We reported this vulnerability to the developers. The current version 1.32.0 of Vaultwarden closes the gap and ensures comprehensive protection again.
In this blog post, you will learn how this vulnerability arose, what consequences it could have for your company, and how you can effectively protect yourself and your data. Rely on transparency and security: Stay informed to identify and minimize risks early on! Take advantage of our expertise, contact us if you have any questions or need support in securing your systems!
In Vaultwarden version 1.30.3 (or earlier), a missing rotation of the organization key was discovered, which meant that access to organization secrets was still possible despite revoked access rights. We reported this security vulnerability to the developer, who fixed the problem and closed the security vulnerability in version 1.32.0.
Users whose access to an organization was revoked could still access data from that organization, including data added after the user's access was revoked.
Description
Vaultwarden allows members of an organization to share data (secrets) with each other. To implement this feature, all organization data is encrypted with the same symmetric key (hereinafter referred to as the organization key) before being stored on the server. Each member of the organization who has access rights to the organization data receives this shared organization key via a key distribution mechanism that takes place during the user's onboarding process.
While there is an onboarding process, the application does not provide an "offboarding" process for members leaving the organization. Therefore, the shared organization key is not rotated when a member leaves the organization. Consequently, a malicious departing member, whose access should actually be revoked, could retain a valid copy of the organization key.
The lack of organization key rotation can be confirmed with the following steps:
- Create an organization with multiple members and secrets.
- Note the encrypted secrets stored on the server.
- Revoke access for some organization members.
- Observe that the encrypted secrets collected in step 2 have not changed after step 3.
Furthermore, Vaultwarden does not sufficiently protect the encrypted user data stored on the server. An authenticated user can gain unauthorized access to encrypted data from any organization, even if they are not a member of that organization. The following screenshot illustrates the issue. Here, the requesting user is not a member of the organization in question, yet the data is returned.
By further exploiting this unauthorized access, a member who has left an organization could continue to retrieve encrypted data from that organization. In combination with the organization key that the malicious user has retained, the user could decrypt the retrieved data and gain unauthorized access to all of the organization's secrets (in plaintext). This unauthorized access also includes secrets created/updated after the user's departure.
This attack vector can be verified with the following steps:
First, a test user (Mallory – the attacker) gains access to an organization called Foobar.
At this point, Mallory has access to the organization key. She also notes the organization ID and the (encrypted) key from the response of the GET /api/sync endpoint.
Next, Alice (an organization administrator) removes Mallory's (the attacker) access to the Foobar organization. After this step, Mallory no longer has access to the organization data.
Alice then adds new secrets to the Foobar organization.
At this point, it could be verified via the application's user interface that Mallory no longer has access to the Foobar organization.
Mallory then exploits the unauthorized access to the encrypted organization data described above and retrieves the newly added (encrypted) secrets from the Foobar organization.
Mallory must now decrypt the encrypted secrets with the original, non-rotated organization key. This can be done in several ways:
- According to the Bitwarden whitepaper, Mallory could decrypt the encrypted organization key with his personal encryption key and then use the plaintext organization key to decrypt the organization data.
- Mallory could manipulate the exchanged traffic and trick Bitwarden into decrypting the data for him.
For a proof of concept, method #2 is used.
Mallory simply performs an update and manipulates the response to the encryption synchronization request (GET /api/sync). Since Mallory now has no access to secrets, the "Cipher" field in the following screenshot is empty. Since his access to the Foobar organization has been revoked, the "Organizations" field is also empty. Mallory must manually populate these two fields with data from the previous steps:
- Ciphers: with an array of encrypted data that he retrieved by exploiting the unauthorized access to encrypted organization data.
- Organizations: with metadata of the Foobar organization that he had when he was still a member of the organization.
After the required fields are populated, the response is forwarded to a Bitwarden client. The client automatically performs the decryption of the data. Finally, Mallory sees the decrypted data in the user interface, with all the secrets of the Foobar organization.
Assigned CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-39925
Affected component: https://github.com/dani-garcia/vaultwarden/
Attack type: Remote
Attack vectors: To exploit the vulnerability, a malicious user must keep a copy of the organization keys of the organizations to which they belong. If the user then leaves the respective organization, they will still have access to all organization secrets (in plaintext).
Reference:
https://github.com/BlackDex/vaultwarden/commit/94ce2786b93173ab36fb0ee24e111cbfde237c07
https://github.com/dani-garcia/vaultwarden/releases/tag/1.32.0
