New Pass-ta-key attacks let malware hijack Google-synced passkeys
Security researchers have discovered three attacks that allow malware on already-compromised Windows devices to abuse Google Password Manager's synced passkeys to take over accounts, bypass user verification, and extract passkey private keys.
Intelligence analysis by Llama
New Pass-ta-key attacks allow malware to hijack Google-synced passkeys, bypass user verification, and extract private keys. The attacks exploit weaknesses in Chrome and Google's cloud authenticator, requiring malware to already be running on the victim's computer.
Imagine you have a super-safe lock on your house that only you can open. But, if someone gets inside your house and steals the key, they can open the lock and get into your house. Passkeys are like those super-safe locks, but the new attacks discovered by security researchers show that if someone gets malware on your computer, they can steal the key and use it to get into your online accounts.
Analysis
A New Class of Attacks on Passkeys
Security researchers have discovered three novel attacks, collectively called 'Pass-ta-key,' that target Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module (TPM). These attacks allow malware to hijack passkeys, bypass user verification, and extract private keys. The attacks exploit weaknesses in how Chrome and Google's cloud authenticator handle device trust, onboarding, recovery, and synced credentials.
The first technique, named Pass-ta-key, allows unprivileged malware to impersonate a trusted device and request a valid authentication response for one of the victim's passkeys. The malware abuses Chrome's TPM-backed device identity key to sign a request sent to Google's cloud authenticator. This can be done without administrator privileges, user interaction, biometrics, or unlocking the device. Google's cloud authenticator then treats the request as coming from the victim's trusted computer and returns a signed authentication response, known as an assertion, that can be used to log in to the targeted account.
However, the assertion includes a User Verified flag indicating whether biometric or PIN verification occurred. This causes the attack to fail if a service requires and properly validates that user verification was successful. The attack failed against GitHub, which properly checked the User Verified flag, but successfully tested the attack against eBay. Although eBay required user verification, it did not properly validate the flag indicating whether that verification occurred. eBay has since fixed the issue after the researchers reported it.
The second technique, named Silver Pass-ta-key, goes further by allowing attackers to register their own user-verification key with Google's cloud authenticator. The attacker first uses malware on the compromised device to force Chrome to re-register it by invalidating its existing verification key or deleting the local file containing its passkey state. During the re-registration process, the attacker can register a user-verification key they control because the cloud authenticator does not validate whether the new key originated from trusted hardware. Google then accepts requests signed with the attacker's key as proof that the victim unlocked the device using a PIN or biometrics. This allows the attacker to access accounts that properly require and validate user verification.
Once the malicious key is registered, the attacker can authenticate from another system without needing further access to the victim's computer. The third and most severe technique, named Golden Pass-ta-key, allows malware to obtain the master key used to encrypt all passkeys synced through the victim's Google Password Manager account. This master key, known as the security domain secret, is temporarily sent to Chrome when a device registers or recovers access to the account. Unit 42 initially found that Chrome exposed the secret in plaintext through its internal FIDO logs. Google removed the secret from the logs after the researchers reported the issue, but Unit 42 says it is still sent to Chrome and remains temporarily accessible in the browser's process memory.
The attacker can then use the stolen master key to decrypt the victim's synced passkey records and recover their private keys. Those private keys can be transferred to another system and used to impersonate the victim and sign in to their accounts. Unit 42 warns that the stolen master key could also be used to decrypt future passkeys synced to the account. Google's current implementation reportedly provides no way to rotate or revoke the key, meaning current and future synced passkeys remain protected by the same secret.
While the researchers say passkeys remain significantly safer than traditional passwords, the attacks demonstrate that they do not eliminate the risks posed by malware already running on a compromised device. Unit 42 recommends that websites require and properly validate user verification. Credential managers should also validate newly registered device keys, harden recovery and device re-registration processes, and prevent master keys from becoming accessible in browser memory.
Key points
- Security researchers have discovered three novel attacks, collectively called 'Pass-ta-key,' that target Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module (TPM).
- The attacks allow malware to hijack passkeys, bypass user verification, and extract private keys.
- The attacks exploit weaknesses in how Chrome and Google's cloud authenticator handle device trust, onboarding, recovery, and synced credentials.
- The first technique, named Pass-ta-key, allows unprivileged malware to impersonate a trusted device and request a valid authentication response for one of the victim's passkeys.
- The second technique, named Silver Pass-ta-key, allows attackers to register their own user-verification key with Google's cloud authenticator.
- The third and most severe technique, named Golden Pass-ta-key, allows malware to obtain the master key used to encrypt all passkeys synced through the victim's Google Password Manager account.
Google has already fixed the issue with eBay, and the company is working to address the vulnerabilities in Chrome and Google's cloud authenticator. Additionally, websites and credential managers can take steps to prevent such attacks by requiring and properly validating user verification, validating newly registered device keys, hardening recovery and device re-registration processes, and preventing master keys from becoming accessible in browser memory.
The attacks demonstrate that passkeys are not entirely secure against malware, and that websites and credential managers need to take steps to prevent such attacks. If not addressed, these vulnerabilities could lead to widespread exploitation and compromise of online accounts.
