browser/apps/desktop/desktop_native/chromium_importer

Chromium Direct Importer

A rust library that allows you to directly import credentials from Chromium-based browsers.

Windows ABE Architecture

On Windows Chrome has additional protection measurements which needs to be circumvented in order to get access to the passwords.

Overview

The Windows Application Bound Encryption (ABE) subsystem consists of two main components that work together:

• client library — a library that is part of the desktop client application
• bitwarden_chromium_import_helper.exe — a password decryptor running as ADMINISTRATOR and later as SYSTEM

See the last section for a concise summary of the entire process.

Goal

The goal of this subsystem is to decrypt the master encryption key used to encrypt login information on the local Windows system. This applies to the most recent versions of Chrome, Brave, and (untested) Edge that use the ABE/v20 encryption scheme for some local profiles.

The general idea of this encryption scheme is as follows:

1. Chrome generates a unique random encryption key.
2. This key is first encrypted at the user level with a fixed key for v1/v2 of ABE. For ABE v3 a more complicated scheme is used that encrypts the key with a combination of a fixed key and a randomly generated key at the system level via Windows CNG API.
3. It is then encrypted at the user level again using the Windows Data Protection API (DPAPI).
4. Finally, it is sent to a special service that encrypts it with DPAPI at the system level.

This triply encrypted key is stored in the Local State file.

The following sections describe how the key is decrypted at each level.

1. Client Library

This is a Rust module that is part of the Chromium importer. It compiles and runs only on Windows (see abe.rs and abe_config.rs). Its main task is to launch bitwarden_chromium_import_helper.exe with elevated privileges, presenting the user with the UAC prompt. See the abe::decrypt_with_admin call in platform/windows/mod.rs.

This function takes two arguments:

1. Absolute path to bitwarden_chromium_import_helper.exe
2. Base64 string of the ABE key extracted from the browser's local state

First, bitwarden_chromium_import_helper.exe is launched by calling a variant of ShellExecute with the runas verb. This displays the UAC screen. If the user accepts, bitwarden_chromium_import_helper.exe starts with ADMINISTRATOR privileges.

The user must approve the UAC prompt or the process is aborted.

Because it is not possible to read the standard output of an application launched in this way, a named pipe server is created at the user level before bitwarden_chromium_import_helper.exe is launched. This pipe is used to send the decryption result from bitwarden_chromium_import_helper.exe back to the client.

The data to be decrypted are passed via the command line to bitwarden_chromium_import_helper.exe like this:

bitwarden_chromium_import_helper.exe --encrypted "QVBQQgEAAADQjJ3fARXREYx6AMBPwpfrAQAAA..."

2. Admin Executable

Although the process starts with ADMINISTRATOR privileges, its ultimate goal is to elevate to SYSTEM. To achieve this, it uses a technique to impersonate a system-level process.

First, bitwarden_chromium_import_helper.exe ensures that the SE_DEBUG_PRIVILEGE privilege is enabled by calling RtlAdjustPrivilege. This allows it to enumerate running system-level processes.

Next, it finds an instance of services.exe or winlogon.exe, which are known to run at the SYSTEM level. Once a system process is found, its token is duplicated by calling DuplicateToken.

With the duplicated token, ImpersonateLoggedOnUser is called to impersonate a system-level process.

At this point bitwarden_chromium_import_helper.exe is running as SYSTEM.

The received encryption key can now be decrypted using DPAPI at the system level.

Next, the impersonation is stopped and the feshly decrypted key is decrypted at the user level with DPAPI one more time.

At this point, for browsers not using the custom encryption/obfuscation layer like unbranded Chromium, the twice decrypted key is the actual encryption key that could be used to decrypt the stored passwords.

For other browsers like Google Chrome, some additional processing is required. The decrypted key is actually a blob of structured data that could take multiple forms:

1. exactly 32 bytes: plain key, nothing to be done more in this case
2. blob starts with 0x01: the key is encrypted with a fixed AES key found in Google Chrome binary, a random IV is stored in the blob as well
3. blob starts with 0x02: the key is encrypted with a fixed ChaCha20 key found in Google Chrome binary, a random IV is stored in the blob as well
4. blob starts with 0x03: the blob contains a random key, encrypted with CNG API with a random key stored in the system keychain under the name Google Chromekey1. After that key is decryped (under system level impersonation again), the key is xor'ed with a fixed key from the Chrome binary and the it is used to decrypt the key from the last DPAPI decryption stage.

The decrypted key is sent back to the client via the named pipe. bitwarden_chromium_import_helper.exe connects to the pipe and writes the result.

The response can indicate success or failure:

• On success: a Base64-encoded string.
• On failure: an error message prefixed with !.

In either case, the response is sent to the named pipe server created by the client. The client responds with ok (ignored).

Finally, bitwarden_chromium_import_helper.exe exits.

3. Back to the Client Library

The decrypted Base64-encoded key is returned from bitwarden_chromium_import_helper.exe to the named pipe server at the user level. The key is used to decrypt the stored passwords and notes.

TL;DR Steps

1. Client side:

   1. Extract the encrypted key from Chrome’s settings.
   2. Create a named pipe server.
   3. Launch bitwarden_chromium_import_helper.exe with ADMINISTRATOR privileges, passing the key to be decrypted via CLI arguments.
   4. Wait for the response from bitwarden_chromium_import_helper.exe.

2. Admin side:

   1. Start.
   2. Ensure SE_DEBUG_PRIVILEGE is enabled (not strictly necessary in tests).
   3. Impersonate a system process such as services.exe or winlogon.exe.
   4. Decrypt the key using DPAPI at the SYSTEM level.
   5. Decrypt it again with DPAPI at the USER level.
   6. (For Chrome only) Decrypt again with the hard-coded key, possibly at the system level again (see above).
   7. Send the result or error back via the named pipe.
   8. Exit.

3. Back on the client side:

   1. Receive the master key.
   2. Shutdown the pipe server.
   3. Use the master key to read and decrypt stored passwords from Chrome, Brave, Edge, etc.