GoKawiilSecurity 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.
Passkeys are a passwordless authentication method that uses cryptographic keys stored on a user's device to sign in to online accounts.
They are considered safer than passwords because they cannot be guessed, reused, or easily stolen through phishing, while also allowing users to authenticate with a PIN or biometrics, such as a fingerprint or facial recognition.
"Unlike passwords, passkeys can't be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing," reads Google's passkey documentation.
However, a new report by Palo Alto Networks' Unit 42 demonstrates 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).
All three attacks require malware to already be running on the victim's computer and do not break the cryptography used by passkeys. Instead, they 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.
... continue reading