Missing rotation of the organization key

In Vaultwarden version 1.30.3 (or earlier) the missing rotation of the organization key, allowing access to organization secrets despite revoked access, was identified. We have reported this vulnerability to the developer, who addressed the issue and fixed the vulnerability in version 1.32.0.

Users whose access to an organization has been revoked could still gain access to data from that organization, including access to data that is added after the time of the user being revoked.

Description

Vaultwarden allows members of an organization to share data (secrets) with each other. To implement this feature, all organization data is encrypted using the same symmetric key (later referred to as organization key) before they are stored on the server. Each member of the organization, who has access permission to the organization data, is provided with this shared organization key through a key-sharing mechanism that takes place during the user onboarding process.

While an onboarding process exists, the application does not provide any "offboarding" process for members leaving the organization. Thus, the shared organization key does not get rotated when a member leaves the organization. Consequently, a malicious leaving member, whose access should have been revoked, could keep a valid copy of the organization key. 

The lack of organization key rotation can be confirmed using the following steps:

  1. Create an organization with several members and secrets

  2. Take note of the encrypted secrets stored on the server

  3. Revoke access of some organization members

  4. Observe that the encrypted secrets gathered in step #2 have not been changed after step #3

Furthermore, Vaultwarden does not properly protect encrypted user data stored on the server side. An authenticated user can gain unauthorized access to encrypted data of any organization, even though the user is not a member of the targeted organization. The screenshot below depicts the issue. Here the requesting user is not a member of the targeted organization but data is returned nonetheless.

By additionaly exploiting this unauthorized access, a member who has left an organization could still retrieve encrypted data of that organization. In combination with the organization key that the malicious user has kept, the user could decrypt the retrieved data and gain unauthorized access to all organization secrets (in plaintext). This unauthorized access includes also the secrets that are created/updated after the user leaving.

This attack vector can be confirmed using the following steps:

First, a test user (Mallory - the attacker) is granted access to an organization, Foobar.

At this time, Mallory has access to the organization key. She also takes note of the organization ID and the (encrypted) key from response of the GET /api/sync endpoint.

Next, Alice (an organization admin) removes Mallory's (the attacker) access from 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 confirmed using the application user interface that Mallory no longer has access to the Foobar organization.

Mallory then exploits the unauthorized access to the encrypted organization data as described above and retrieves the newly added (encrypted) secrets from Foobar organization.

Mallory now needs to decrypt the encrypted secrets using the initial, unrotated organization key. This can be done by several ways:

  • Following the Bitwarden whitepaper, Mallory could decrypt the encrypted organization key using his personal encryption key, then use the plaintext organization key to decrypt the organization data

  • Mallory could tamper the exchanged traffic and trick the Bitwarden into decrypting the data for him

For a proof-of-concept, the method #2 is used.

Mallory just perform a refresh and tamper the response of the cipher synchronization request (GET /api/sync). In the screenshot below, since Mallory now does not have access to any secret, the field "Cipher is empty". Similarly, since his access to Foobar organization has been revoked, the field "Organizations" is empty as well. Mallory needs to populate theses two fields manually with data retrieved from previous steps:

  • Ciphers: with an array of encrypted data, which he retrieved by exploiting the unauthorized access to encrypted organization data.

  • Organizations: with metadata of the Foobar organization which he had when he was still a member of the organization.

After populating the necessary fields, the response is forwarded to a Bitwarden client. The client automatically performs data decryption. Eventually, Mallory see decrypted data in the user interface, with all secrets from 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 he is a member of. If the user then leaves the respective organization, he still has access to all organization secrets (in plain text).

Reference

https://github.com/BlackDex/vaultwarden/commit/94ce2786b93173ab36fb0ee24e111cbfde237c07

https://github.com/dani-garcia/vaultwarden/releases/tag/1.32.0

Discoverer

Mirko Richter (mgm security partners), Tuyen Thuc Nguyen (mgm securitry partners)