Three Attacks on Google Password Manager Let Attackers Hijack Passkey Accounts

Researchers at Unit 42 (Palo Alto Networks) have described three attack scenarios against the cloud authenticator Google Password Manager in the Chrome browser. All of them let a malicious program already running on the victim's computer with ordinary user privileges log into accounts protected by passkeys — with no fingerprint, no PIN and not a single on-screen prompt.

An important caveat: passkey cryptography has not been broken. The attacks target the code around the keys — how Chrome stores device keys, how it re-registers a device after that state is lost, and whether the site checks that the user was actually verified at all. All three paths require the malware to already be present on the machine, so this is post-exploitation: the methods describe what an attacker can reach on an already-compromised device, not how that device was taken over. The research is limited to Chrome on Windows with a TPM module.

Three paths

The techniques are named after well-known attacks on Kerberos. Pass-ta-key extracts the wrapped device identity key and forces the same TPM to sign a forged request through Windows CNG. Google returns a valid assertion, and the only thing distinguishing it from a genuine one is a single unset bit — the User Verified flag. The WebAuthn specification requires a site with the userVerification: required parameter to reject such an assertion. According to the researchers, GitHub honored the check, while eBay accepted the test assertion until it closed the gap after being notified.

Silver Pass-ta-key forces Chrome to re-run device registration. At the moment when the browser has not yet created its user verification key, the attacker slips in one of their own. The service, it is claimed, does not verify that the new key came from secure hardware — and the assertions it signs carry the UV flag, granting access to the account without the victim's device.

The most serious, Golden Pass-ta-key, targets the master key — the 32-byte Security Domain Secret used to decrypt synchronized private keys. The malware triggers a re-registration and reads the secret from the memory of the Chrome process, where it briefly appears in the clear.

What's next

The techniques have no CVE identifiers, and no cases of real-world exploitation have been reported. Google, according to the researchers, previously removed the secret leak from Chrome's FIDO logs, and eBay began checking the UV flag, but no public advisories about these changes could be found. The main question for those affected also remains open: does changing the PIN or deleting Password Manager data invalidate an already-stolen secret — Google's documentation describes no such mechanism.

Relying parties are advised to require user verification and to personally check the returned UV bit, and credential providers to attest new keys and not release master keys into logs and memory.

Source: The Hacker News