Pass-ta-key espone le passkey sincronizzate di Google Password Manager

🛡️ Executive Summary

• Pass-ta-key sfrutta un dispositivo Windows già compromesso per ottenere autenticazioni valide senza PIN, biometria o interazione dell’utente.
• Silver Pass-ta-key registra una chiave di verifica controllata dall’attaccante, mentre Golden Pass-ta-key punta al segreto che protegge tutte le passkey sincronizzate.
• Gli attacchi non violano la crittografia delle passkey: sfruttano fiducia del dispositivo, recupero delle credenziali e controlli WebAuthn incompleti.

Tre nuove tecniche denominate Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key mostrano come un malware già presente su un computer Windows possa abusare delle passkey sincronizzate attraverso Google Password Manager. Gli attacchi consentono, con livelli differenti di gravità, di ottenere una risposta di autenticazione valida, registrare una chiave controllata dall’attaccante o recuperare il materiale necessario a decifrare le chiavi private sincronizzate. La ricerca riguarda Google Chrome su Windows, dispositivi dotati di Trusted Platform Module e sistemi già compromessi. Non viene violata la crittografia alla base di WebAuthn: il problema emerge nei flussi che collegano dispositivo, browser, autenticatore cloud, recupero dell’account e verifica effettiva dell’utente.

Pass-ta-key trasforma il dispositivo compromesso in un autenticatore

Le passkey sostituiscono password e codici temporanei con una coppia di chiavi crittografiche: la chiave pubblica viene registrata presso il servizio, mentre quella privata rimane nell’autenticatore dell’utente e firma le richieste di accesso. Con Google Password Manager, le credenziali possono essere sincronizzate tra più dispositivi dopo essere state cifrate. Questo modello offre una protezione nettamente superiore contro phishing, riutilizzo delle password e credential stuffing, ma continua a dipendere dall’affidabilità dell’endpoint che richiede l’autenticazione. Nell’analisi tecnica dedicata alla superficie d’attacco delle passkey sincronizzate, Unit 42 descrive tre tecniche che partono tutte dalla presenza preventiva di malware sul computer della vittima. Chrome conserva nel database locale di sincronizzazione informazioni codificate sulle credenziali WebAuthn, tra cui servizio associato, nome utente, identificatore della credenziale e chiave privata cifrata. Questi metadati possono essere letti da un processo eseguito con i normali privilegi dell’utente e permettono all’attaccante di individuare gli account sui quali la vittima utilizza una passkey.

La prima tecnica, chiamata Pass-ta-key, recupera la chiave di identità del dispositivo protetta dal TPM e sfrutta le API crittografiche di Windows per farle firmare una richiesta controllata dall’attaccante. Google Cloud Authenticator interpreta la richiesta come proveniente da un dispositivo già riconosciuto e restituisce un’asserzione crittograficamente valida, senza che la vittima sblocchi il computer, utilizzi il PIN, fornisca un dato biometrico o visualizzi una richiesta. La tecnica non estrae direttamente la chiave privata dal TPM, ma usa il dispositivo compromesso come un oracolo di firma. Il rischio conferma che l’evoluzione verso l’autenticazione senza password, già visibile con l’integrazione delle passkey in Android Credential Manager, riduce gli attacchi basati sui segreti condivisi senza eliminare quelli successivi alla compromissione dell’endpoint.

Il controllo User Verified decide se il primo attacco riesce

L’asserzione ottenuta con Pass-ta-key contiene un indicatore fondamentale chiamato User Verified, o UV, che segnala se l’utente ha realmente confermato l’operazione attraverso PIN, biometria o un altro meccanismo di sblocco. Nel primo attacco il flag rimane disattivato. Un servizio che richiede la verifica dell’utente e controlla correttamente questo valore deve quindi rifiutare l’accesso, anche se la firma crittografica è valida. Durante i test, GitHub ha bloccato l’asserzione perché applicava il controllo previsto, mentre eBay l’ha inizialmente accettata nonostante avesse richiesto la verifica dell’utente. Il servizio ha successivamente corretto la propria implementazione dopo la segnalazione dei ricercatori.

Il caso dimostra che impostare userVerification su required nella richiesta WebAuthn non basta: il relying party deve anche controllare il flag restituito dall’autenticatore prima di creare la sessione. Una passkey può quindi essere crittograficamente autentica ma non soddisfare il livello di verifica richiesto dal servizio. Questa distinzione è importante perché la sicurezza passwordless dipende dall’intera catena di validazione e non soltanto dalla protezione della chiave privata. Lo stesso principio emerge nelle campagne che aggirano i normali fattori di accesso senza rubare direttamente la password, come il phishing passwordless contro Microsoft Entra che manipola i flussi di autenticazione. Le passkey restano resistenti al phishing tradizionale perché sono associate al dominio legittimo, ma un attaccante già presente sul sistema può tentare di manipolare il browser, il dispositivo fidato o le condizioni con cui il servizio valuta l’asserzione ricevuta.

Silver Pass-ta-key registra una chiave controllata dall’attaccante

Silver Pass-ta-key supera il limite del flag UV intervenendo durante la registrazione del dispositivo presso l’autenticatore cloud. Il malware invalida lo stato locale utilizzato da Chrome o elimina i dati che identificano la precedente configurazione, costringendo il browser ad avviare un nuovo processo di enrollment. In questa fase la chiave destinata alla verifica dell’utente può essere creata in un secondo momento. L’attaccante sfrutta questa finestra per generare una propria coppia crittografica e registrare la chiave pubblica controllata come nuova user-verification key. Secondo la ricerca, il servizio cloud non verifica in modo sufficiente che la chiave appena aggiunta provenga da hardware attendibile o da un’operazione realmente autorizzata dall’utente.

Le richieste firmate con la chiave dell’attaccante possono quindi presentare il flag UV attivo, facendo apparire come completato uno sblocco biometrico o tramite PIN mai avvenuto. A differenza della prima tecnica, Silver Pass-ta-key permette di autenticarsi successivamente da un sistema diverso senza mantenere l’accesso al computer originariamente compromesso. L’attaccante non si limita a sfruttare temporaneamente il dispositivo della vittima, ma introduce un nuovo elemento di fiducia nel sistema di sincronizzazione. La debolezza risiede quindi nei processi di onboarding, recupero e registrazione delle chiavi, che devono applicare controlli almeno equivalenti a quelli utilizzati durante l’autenticazione ordinaria.

La crescente diffusione di passkey su browser, sistemi operativi e servizi social, descritta anche con l’adozione dell’autenticazione passwordless da parte di Meta, rende questi flussi di recupero un obiettivo sempre più interessante: quando una credenziale non può essere reimpostata come una normale password, l’attaccante tenta di farsi riconoscere come nuovo dispositivo legittimo.

Golden Pass-ta-key punta al segreto di tutte le passkey sincronizzate

La tecnica più grave, Golden Pass-ta-key, prende di mira il Security Domain Secret, un segreto di 32 byte utilizzato per proteggere il materiale crittografico delle passkey sincronizzate. Il valore viene reso disponibile al client durante alcune operazioni di registrazione o recupero del dispositivo. I ricercatori hanno inizialmente rilevato che Chrome lo esponeva in chiaro nei log interni FIDO; Google ha eliminato questa presenza dopo la segnalazione. Secondo Unit 42, tuttavia, il segreto deve ancora raggiungere Chrome e rimane temporaneamente accessibile nella memoria del processo. Un malware può forzare una nuova registrazione, individuare il valore mentre viene elaborato e usarlo per decifrare i record sincronizzati conservati localmente. L’attaccante potrebbe così recuperare le chiavi private delle passkey, trasferirle su un altro sistema e utilizzarle senza dipendere ulteriormente dal dispositivo della vittima.

La ricerca sostiene inoltre che il segreto potrebbe proteggere anche credenziali sincronizzate successivamente, ampliando l’impatto oltre gli account già presenti al momento dell’infezione. Non è stato però associato alcun codice CVE, non risultano campagne di sfruttamento attivo e la documentazione pubblicata non chiarisce se tutte le varianti siano state completamente corrette nei servizi di produzione. La ricerca si concentra su Chrome per Windows con TPM e non dimostra automaticamente la stessa esposizione su Android, ChromeOS, macOS o altri password manager. Google descrive le passkey custodite nel proprio gestore come cifrate end-to-end e protette da chiavi accessibili soltanto sui dispositivi dell’utente; Golden Pass-ta-key non contesta questa architettura, ma mostra che un segreto destinato a un client compromesso può diventare accessibile mentre viene utilizzato. L’evoluzione di Google Password Manager come archivio sincronizzato di credenziali e passkey aumenta quindi l’importanza della protezione della memoria del browser e dei flussi con cui un nuovo dispositivo viene ammesso nel dominio di sicurezza.