Clarissa Hana
Security researchers have uncovered a trio of sophisticated attack vectors that leverage malware already present on compromised Windows devices to exploit Google Password Manager’s synced passkeys. These vulnerabilities, collectively dubbed "Pass-ta-key," allow attackers to hijack accounts, circumvent user verification processes, and potentially extract the private keys underpinning passkey authentication. The findings, detailed in a report by Palo Alto Networks’ Unit 42, highlight critical weaknesses in the implementation and handling of device trust and credential synchronization within Google’s passwordless authentication system.
Passkeys, heralded as a significant advancement over traditional passwords, utilize cryptographic key pairs stored locally on a user’s device. One key remains on the device, while its public counterpart is registered with online services. Authentication occurs when the device uses its private key to cryptographically sign a challenge from the service, a process typically secured by a user’s PIN or biometric data. This design aims to mitigate common attack vectors like phishing, credential stuffing, and brute-force attempts, as passkeys cannot be easily guessed, reused, or phished. Google itself emphasizes their inherent security, stating, "Unlike passwords, passkeys can’t be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing." However, the Pass-ta-key research demonstrates that the security of passkeys is not absolute, particularly when the underlying device is already under the control of malicious actors.
The Genesis of the Pass-ta-key Attacks
The research team at Unit 42 focused their investigation on Google Password Manager’s implementation within the Chrome browser on Windows operating systems, specifically when a Trusted Platform Module (TPM) is present. A TPM is a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. The Pass-ta-key attacks do not break the fundamental cryptographic principles of passkeys. Instead, they cunningly exploit what the researchers identify as shortcomings in how Chrome and Google’s cloud authenticator manage device trust, the onboarding of new devices, account recovery procedures, and the synchronization of credentials across multiple devices. Crucially, all three identified attack methods necessitate that malware has already gained a foothold on the victim’s machine, meaning the user has already suffered a significant security breach.
Attack Vector 1: Impersonating a Trusted Device (Pass-ta-key)
The first identified attack, also named "Pass-ta-key," allows malware with standard user privileges to masquerade as a legitimate, trusted device within the Google ecosystem. This enables the malware to request and obtain a valid authentication response for one of the victim’s stored passkeys. The core mechanism involves the malware leveraging Chrome’s TPM-backed device identity key. This key is used to digitally sign a request sent to Google’s cloud authenticator. The critical vulnerability lies in the fact that this process can be initiated without requiring administrator privileges, direct user interaction, biometric authentication, or even the unlocking of the device.
Upon receiving the signed request, Google’s cloud authenticator, tricked into believing it originates from the victim’s trusted computer, issues a signed authentication response, often referred to as an assertion. This assertion is designed to grant access to the targeted online account. However, a key element of this assertion is a "User Verified" flag. This flag is intended to indicate whether a biometric scan or PIN entry was successfully performed by the user. The Pass-ta-key attack’s effectiveness is contingent on whether the target service properly validates this flag.
Unit 42’s research indicated that while the attack failed against platforms like GitHub, which rigorously checks the "User Verified" flag to ensure genuine user authentication, it proved successful against eBay. In the case of eBay, although user verification was mandated, the platform did not adequately validate the flag, allowing the malicious assertion to grant access. Following disclosure by the researchers, eBay has since rectified this security flaw. This incident underscores the importance of robust validation mechanisms at the service provider level, even when using advanced authentication methods like passkeys.
Attack Vector 2: Registering Malicious Verification Keys (Silver Pass-ta-key)
The second technique, termed "Silver Pass-ta-key," escalates the threat by enabling attackers to register their own user-verification key with Google’s cloud authenticator. This is achieved through a multi-step process initiated by the malware on the compromised device. The attacker first compels Chrome to re-register the device with Google’s authentication service. This can be accomplished by invalidating the device’s existing verification key or by deleting the local file that stores the passkey state information.
During this re-registration phase, the attacker can substitute their own chosen user-verification key. The vulnerability arises because the cloud authenticator, in its current implementation, fails to adequately verify if the newly registered key originates from trusted hardware. Consequently, Google’s system then accepts requests signed with the attacker’s malicious key as valid proof of the victim unlocking their device with a PIN or biometrics. This allows attackers to bypass services that strictly require and validate user verification, effectively granting them access to accounts they should not be able to reach.
Once the malicious key is successfully registered, the attacker can authenticate to the victim’s accounts from any system, without needing further ongoing access to the compromised computer. This represents a significant escalation, as it allows for persistent account takeover even after the initial malware infection may have been detected or partially mitigated.
Attack Vector 3: Stealing the Master Encryption Key (Golden Pass-ta-key)
The most alarming and severe of the discovered techniques is "Golden Pass-ta-key." This attack vector empowers malware to obtain the master key responsible for encrypting all passkeys synchronized across the victim’s Google Password Manager account. This critical encryption key is known as the security domain secret (SDS). The SDS is temporarily transmitted to Chrome during the process of a device registering or recovering access to a Google account.
Unit 42’s initial findings revealed that Chrome was inadvertently exposing this SDS in plaintext within its internal FIDO logs. Following the researchers’ disclosure of this vulnerability, Google reportedly removed the SDS from these logs. However, the researchers assert that the SDS is still transmitted to the Chrome client and remains temporarily accessible within the browser’s process memory.
As Unit 42 elaborates, "Although Google removed this secret from Chrome’s logging output following our report, the SDS is still sent to the client and remains accessible in Chrome’s process memory. If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory."
With this stolen master key, an attacker gains the ability to decrypt all of the victim’s synced passkey records. This decryption process allows for the recovery of the associated private keys. These recovered private keys can then be transferred to a separate system, enabling the attacker to impersonate the victim and gain unauthorized access to their online accounts. The implications are far-reaching, as the stolen master key can also be used to decrypt future passkeys that are synchronized to the compromised account. Alarmingly, Google’s current implementation reportedly lacks a mechanism to rotate or revoke this master key. This means that not only current but also all future synced passkeys remain vulnerable under the protection of the same compromised secret.
Broader Implications and Recommendations
While the researchers emphasize that passkeys, in principle, remain significantly more secure than traditional passwords, the Pass-ta-key attacks serve as a stark reminder that no security solution is entirely impervious, especially in the face of sophisticated malware operating on compromised endpoints. The attacks highlight that the security of passkeys is intricately linked to the overall security posture of the device on which they are stored and managed.
Unit 42 has put forth several recommendations to mitigate these risks:
- For Service Providers: Websites and online services should enforce and rigorously validate user verification. This means not just requiring a PIN or biometric but ensuring that the authentication flow correctly confirms that these verification steps were successfully completed by the user.
- For Credential Managers (like Google Password Manager):
- Credential managers must implement robust validation of newly registered device keys to prevent the substitution of malicious keys.
- Recovery and device re-registration processes need to be hardened to prevent attackers from exploiting these workflows.
- Crucially, master keys or security domain secrets should not be made accessible in browser process memory, even temporarily. Implementing more secure key management practices within the browser is paramount.
- For Users: While not directly addressed by the recommendations for system architects, users should continue to practice good cyber hygiene, including keeping operating systems and software updated, using reputable antivirus solutions, and being vigilant about potential phishing attempts or suspicious software downloads that could lead to device compromise in the first place.
The researchers responsibly disclosed their findings regarding the Google Password Manager attacks to Google and reported related user-verification flaws to affected services, including eBay, prior to the public release of their research. This responsible disclosure process is crucial for allowing vendors time to implement necessary fixes and patches.
As of the reporting of this article, BleepingComputer reached out to Google for comment regarding Unit 42’s findings and to ascertain the extent to which the described attacks have been addressed. A response was not immediately available. The ongoing dialogue between security researchers and technology providers is vital for the continuous improvement of digital security and the safeguarding of user data in an evolving threat landscape. The Pass-ta-key revelations underscore the complex interplay between authentication technologies, browser implementations, and the ever-present threat of advanced malware.
