GBHackers

Malware Can Steal Google’s Synced Passkeys Without Password or Fingerprint


Security researchers have revealed a series of attacks that could enable malware on a compromised Windows device to hijack accounts protected by Google-synced passkeys. This can occur without stealing a password, capturing a fingerprint, or requiring the victim to unlock their device.

In research published on August 23, 2023, Palo Alto Networks’ Unit 42 detailed three attack techniques, collectively referred to as “Pass-ta-key,” which target the Google Password Manager in Chrome on Windows systems equipped with a Trusted Platform Module (TPM).

These attacks require malware to be already running on the victim’s standard user account but do not require administrator privileges.

Message from GitHub passkey login failure (Source: Unit 42)

Malware Can Steal Google’s Synced Passkeys

Passkeys are intended to eliminate the risks associated with phishing-prone passwords by using cryptographic key pairs. Google’s synced-passkey architecture relies on a cloud authenticator and hardware-backed device keys to protect private keys.

However, Unit 42 found that malware could exploit device identity, recovery, and enrollment mechanisms to gain valid authentication assertions.

The first technique, called “Pass-ta-key,” allows malware to impersonate a trusted device. Chrome stores passkey synchronization data locally in its LevelDB database at:

%LocalAppData%GoogleChromeUser DataSync DataLevelDB.

This data includes WebAuthn credential records that contain service names, usernames, credential IDs, and encrypted private key material. Researchers noted that malware can access this data without elevated privileges, enabling it to identify accounts where the victim uses passkeys.

The malware can then extract Chrome’s TPM-wrapped device identity key material and utilize standard Windows Cryptography API: Next Generation (CNG) operations to sign requests. This allows an attacker to communicate with Google’s cloud authenticator as if they were using the victim’s trusted device.

When a website has WebAuthn user verification set to “preferred,” the attacker may receive a valid assertion and sign in remotely.

 Attacker-side authentication flow in the Silver Pass-ta-key attack 9Source: Unit 42)
 Attacker-side authentication flow in the Silver Pass-ta-key attack 9Source: Unit 42)

Although websites that require user verification should reject assertions lacking the User Verified (UV) flag, Unit 42 reported that some relying parties did not validate this flag correctly. For instance, eBay was found to be affected during testing but resolved the issue after disclosure.

A more serious variant, termed “Silver Pass-ta-key,” focuses on device re-enrollment. An attacker can delete Chrome’s `passkey_enclave_state` file or issue a device-forget command, forcing the browser to re-onboard the device.

During a temporary `uv_key_pending` state, the attacker can then register a user-verification key they control with the cloud authenticator. This key can generate assertions with the UV flag enabled, bypassing biometric or PIN verification requirements.

Authenticator data layout. Source-Unit42
Authenticator data layout. Source-Unit42

Unlike the initial attack, this method allows reusable access from an attacker-controlled environment, even if the victim’s device is offline.

The third technique, “Golden Pass-ta-key,” presents the broadest risk. Researchers discovered that Chrome’s recovery process could potentially expose the 32-byte security domain secret (SDS), a master key used to protect synced passkeys.

Google has since removed the secret from Chrome device logs following the disclosure, but Unit 42 indicated that the SDS may still be temporarily accessible in Chrome’s process memory during device onboarding.

If stolen, the SDS could decrypt all synced passkey private keys stored in Chrome synchronization data. This would enable attackers to copy, reuse, or sell credentials, and potentially retain access even after a victim re-enrolls their devices.

Unit 42 recommends that websites enforce a userVerification = required policy and rigorously validate the UV flag. Credential providers should validate attestation for new device keys, strengthen recovery workflows, prevent sensitive keys from being stored in client memory, and monitor for suspicious modifications to local passkey state files.

These findings emphasize that while passkeys are more resistant to traditional phishing and password theft, vulnerabilities can arise from endpoint compromises when cloud synchronization, device trust, and recovery systems are not equally secured.

ALERT: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.



Source link