La notizia in sintesi
- Unit 42 documenta tre attacchi alle passkey di Google.
- Il bersaglio è Chrome su Windows con TPM.
- Serve un malware già attivo sul computer della vittima.
- I siti devono controllare correttamente la verifica dell’utente.
(Riassunto generato con AI)
Passkey Google, i rischi individuati da Unit 42
Unit 42, il gruppo di ricerca di Palo Alto Networks, ha documentato tre tecniche che possono colpire le passkey sincronizzate in Google Password Manager tramite Chrome su computer Windows dotati di TPM. Gli attacchi, denominati Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key, richiedono però una condizione decisiva: un malware deve essere già in esecuzione sul dispositivo della vittima.
La ricerca mostra che, in questo scenario, un aggressore può abusare dei meccanismi con cui browser e autenticatore cloud gestiscono identità del dispositivo, registrazione e recupero delle credenziali. L’obiettivo non è spezzare la crittografia delle passkey, ma sfruttare il software che le utilizza e i controlli applicati dai servizi online.
Il tema è rilevante perché le passkey restano progettate per ridurre phishing, riuso delle password e furto remoto. Tuttavia, come evidenzia l’analisi, non possono neutralizzare da sole un codice malevolo già presente sul computer e capace di agire nel contesto dell’utente.
Come funzionano le tre tecniche documentate
La prima tecnica, Pass-ta-key, consente a un malware senza privilegi amministrativi di usare l’identità del dispositivo per firmare una richiesta rivolta all’autenticatore cloud di Google. La risposta ottenuta può apparire valida, senza impronta digitale, PIN, sblocco del sistema o interazione visibile della vittima.
Resta però un segnale tecnico: il flag User Verified indica se la verifica dell’utente è avvenuta davvero. Nei test, GitHub ha respinto l’accesso perché controllava correttamente quel valore; eBay lo ha inizialmente accettato pur richiedendo la verifica, correggendo poi il problema dopo la segnalazione.
Silver Pass-ta-key agisce invece sulla ri-registrazione del dispositivo. Invalidando una chiave esistente o cancellando lo stato locale, il malware può spingere Chrome a registrare nuovamente il computer e inserire una chiave dell’attaccante, se il servizio non ne verifica l’origine hardware.
Golden Pass-ta-key è la variante più delicata: punta al Security Domain Secret, il segreto di 32 byte che protegge le passkey sincronizzate dell’account. Durante registrazione o recupero, il dato raggiunge il client e può restare accessibile nella memoria del processo di Chrome.
“Il SDS viene comunque inviato al client e resta accessibile nella memoria di processo di Chrome”, ha spiegato Unit 42. Google ha rimosso il segreto dai log FIDO interni dopo la segnalazione, ma le fonti indicano che il percorso in memoria rimane possibile.
La conseguenza per utenti, siti e gestori
Se sottratto, il Security Domain Secret potrebbe permettere di decifrare le passkey sincronizzate, comprese quelle aggiunte successivamente allo stesso account. Secondo i ricercatori, l’implementazione descritta non offre un meccanismo specifico per ruotare o revocare il segreto dopo una possibile esposizione.
La principale conseguenza ricade quindi anche sui siti: chiedere la verifica utente non basta, occorre validare il flag restituito. Per i gestori di credenziali, la priorità è attestare le nuove chiavi, rafforzare recupero e registrazione e ridurre l’esposizione di segreti in memoria e nello stato locale.
Non sono stati descritti sfruttamenti reali, né risultano CVE assegnati al 3 agosto o indicazioni complete sulle versioni di Chrome coinvolte.
FAQ
Le passkey di Google Password Manager sono violate?
Sì, possono essere abusate soltanto se un malware è già operativo su Windows; la crittografia delle passkey non viene direttamente violata.
Quali dispositivi sono coinvolti nella ricerca?
Sì, il perimetro documentato riguarda Chrome su Windows con TPM e passkey sincronizzate da Google Password Manager.
Un malware può aggirare PIN e biometria?
Sì, Pass-ta-key può ottenere una risposta di autenticazione senza PIN, biometria o sblocco, ma i siti devono controllare il flag User Verified.
eBay e GitHub hanno reagito allo stesso modo?
No, GitHub ha respinto il test verificando il flag; eBay lo aveva accettato e ha successivamente corretto la vulnerabilità segnalata.
Come è stata verificata questa ricostruzione?
Sì, il contenuto nasce da analisi approfondita e verifica incrociata della nostra Redazione su più fonti: Hardware Upgrade e Tom’s Hardware.
