Un malware già in esecuzione su un computer Windows può sfruttare il modo in cui Google Password Manager gestisce le passkey sincronizzate in Chrome.

In base allo scenario, può usare il computer della vittima per autenticarsi, registrare una chiave controllata dall’attaccante oppure recuperare il segreto che protegge le credenziali sincronizzate.

È quanto mostra una ricerca pubblicata il 3 agosto da Unit 42, la divisione di analisi delle minacce di Palo Alto Networks. I ricercatori descrivono tre tecniche chiamate Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key.

Il perimetro dello studio è preciso e fa riferimento a Google Password Manager in Chrome su Windows, con dispositivi dotati di Trusted Platform Module (TPM), il componente hardware usato per proteggere e utilizzare alcune chiavi crittografiche.

In tutti e tre i casi il pc deve essere già compromesso. Gli attacchi non partono da remoto contro una macchina sana, non richiedono di decifrare la passkey e non dimostrano che lo stesso problema esista in iCloud Keychain, servizio che salva e sincronizza in modo sicuro password, passkey, carte e dati di accesso tra dispositivi Apple oppure in altri gestori di credenziali o nelle chiavi di sicurezza fisiche che non sono state oggetto di test.

Il rapporto, inoltre, non documenta campagne criminali che abbiano già usato queste tecniche. Si tratta di prove di fattibilità e mostrano cosa potrebbe fare un malware dopo essere entrato nel computer con i normali permessi dell’utente.

La distinzione è importante perché non significa che le passkey siano state “rotte”, ma neppure che un dispositivo infetto diventi sicuro soltanto perché non usa più una password.

Ne abbiamo parlato con Marco Valenti, fondatore di MWI – MarkWeb Informatica, azienda specializzata in cybersecurity.

Perché una passkey non è una password

Una passkey usa una coppia di chiavi crittografiche. Il servizio conserva la chiave pubblica, mentre la chiave privata resta sul dispositivo o nel gestore di credenziali e viene usata per firmare una nuova richiesta a ogni accesso.

Non c’è quindi una password segreta condivisa che l’utente possa riutilizzare, digitare su un sito falso o lasciare in bella vista scritta su un foglietto appiccicato al monitor o lasciato sotto la tastiera del computer.

Google descrive le passkey come credenziali resistenti al phishing e protette dallo sblocco del dispositivo. La FIDO Alliance, che sviluppa gli standard su cui si basano, distingue però tra passkey sincronizzate nel cloud e passkey vincolate a un singolo dispositivo.

La sincronizzazione rende le passkey più comode, perché permette di ritrovarle su più dispositivi, ma aggiunge un’infrastruttura che deve registrare nuovi computer, recuperare le credenziali e stabilire quali prove di autenticazione sono affidabili.

È proprio questa catena di fiducia (e non l’algoritmo crittografico della passkey), a essere messa alla prova dalla ricerca di Unit 42.

Il NIST (National Institute of Standards and Technology), ovvero l’ente americano che definisce standard e linee guida tecniche, considera il codice malevolo presente su un terminale compromesso una minaccia capace di usare o inoltrare le operazioni di un autenticatore per conto dell’attaccante.

Pass-ta-key: usare il pc compromesso come dispositivo fidato

In un primo scenario, il malware sfrutta la chiave con cui il computer dimostra la propria identità al servizio cloud di Google. La chiave è protetta da TPM, ma l’attaccante non deve necessariamente estrarla in chiaro, può chiedere allo stesso modulo di firmare una richiesta costruita dal malware, imitando il comportamento legittimo di Chrome.

Il servizio cloud può così riconoscere il pc come dispositivo già registrato e produrre una risposta crittograficamente valida da presentare al sito a cui si vuole accedere. Qui entra in gioco un controllo essenziale, ossia la verifica dell’utente.

Se un sito richiede questa verifica, deve controllare sul server che il flag sia effettivamente impostato, come ricorda anche la guida di Google per gli sviluppatori.

Silver Pass-ta-key: sostituire la prova della verifica dell’utente

La seconda tecnica vuole che il malware forzi Chrome a ripetere la registrazione del dispositivo, per esempio cancellando il file locale che conserva lo stato dell’autenticatore cloud.

Durante la nuova registrazione, Google Password Manager chiede il PIN di recupero. Chrome, però, rinvia al successivo utilizzo la creazione della chiave collegata a Windows Hello – il sistema di autenticazione di Microsoft che permette di accedere a Windows tramite volto, impronta digitale o PI – evitando di mostrare due richieste di PIN una dopo l’altra. In quell’intervallo il sistema resta in attesa della chiave che dovrebbe attestare la verifica dell’utente.

Secondo Unit 42, un attaccante può inserire al suo posto una chiave sotto il proprio controllo perché l’autenticatore cloud non verifica in modo sufficiente che quella chiave provenga da hardware attendibile. Da quel momento le richieste firmate dall’attaccante possono arrivare ai siti, come se la vittima avesse confermato l’accesso con volto, impronta o PIN. L’attacco può così essere riutilizzato anche da un altro computer.

Golden Pass-ta-key: sottrarre il segreto che protegge le passkey sincronizzate

Il terzo scenario descritto da Unit 42 è da considerare il più grave e prende di mira il Security Domain Secret (SDS), un segreto simmetrico di 32 byte usato per cifrare le chiavi private delle passkey sincronizzate nell’account Google. Durante la registrazione o il recupero di un dispositivo, questo valore deve essere reso disponibile a Chrome.

I ricercatori hanno inizialmente trovato il SDS in chiaro nei log interni FIDO del browser. Google ha poi eliminato il valore da quei log, e la modifica è rintracciabile anche nel registro pubblico degli aggiornamenti di Chromium.

Tuttavia, la rimozione dai log non chiude l’intera catena. Durante una nuova registrazione il SDS continua a transitare nella memoria del processo di Chrome. Un malware che forza quel passaggio e acquisisce la memoria nel momento opportuno può recuperare il segreto, usare i dati sincronizzati presenti nel profilo del browser per decifrare le chiavi private e trasferirle su un altro sistema.

A quel punto l’attaccante può firmare autonomamente le richieste di autenticazione, senza coinvolgere il computer della vittima o il servizio cloud. Il rapporto segnala inoltre che, nell’implementazione analizzata, non esiste un meccanismo per ruotare o revocare il SDS. Se il segreto venisse sottratto, la compromissione potrebbe quindi avere effetti anche sulle passkey sincronizzate successivamente.

Che cosa cambia per siti, aziende e utenti

Per i servizi che accettano passkey, la misura immediata è richiedere la verifica dell’utente e controllare sul server ogni risposta. Questa precauzione blocca il primo scenario, ma non i due successivi. Ai fornitori dei gestori di credenziali spetta invece rafforzare registrazione e recupero, verificare l’origine delle nuove chiavi e ridurre l’esposizione dei segreti nella memoria e nei dati locali del browser.

Per gli utenti, il messaggio è di non abbandonare le passkey che restano più resistenti delle password contro phishing, riuso delle credenziali e furto di database. Il limite è un altro e riguarda la consapevolezza.

Infatti, una passkey non può rendere innocuo un computer che ospita già un malware. Aggiornare Chrome e Windows, prevenire le infezioni e controllare gli accessi anomali all’account resta quindi essenziale.

Richieste inattese o ripetute del PIN di recupero di Google Password Manager durante un uso normale meritano attenzione, perché possono indicare che il processo di registrazione del dispositivo è ripartito. Chi gestisce account particolarmente sensibili può valutare una passkey legata a una chiave di sicurezza fisica: la FIDO Alliance la classifica come credenziale vincolata al dispositivo e quindi priva del meccanismo di sincronizzazione cloud studiato da Unit 42.

Non è una protezione assoluta contro ogni malware, ma evita lo specifico segreto cloud preso di mira da Golden Pass-ta-key.

Le passkey salvate in Chrome possono essere controllate e rimosse dalle impostazioni di Google Password Manager. Prima di farlo, però, è necessario bonificare il dispositivo e assicurarsi di avere un metodo alternativo per accedere all’account.

La ricerca mostra quindi un punto preciso. La crittografia delle passkey può restare intatta mentre viene attaccata l’infrastruttura che le circonda.

Il parere dell’esperto

Le passkey in quanto tale non vanno demonizzate. A dovere essere rivista, casomai, è la fiducia cieca con la quale siamo soliti affidarci a tecnologie che appaiono salvifiche e che, seppure in ambienti e condizioni particolari, salvifiche non sono.

Marco Valenti fa il punto sulla situazione.

A prescindere dal tipo di attacco, come possono prepararsi le organizzazioni all’evenienza che le incursioni del cyber crimine saranno sempre più raffinate?
“Partiamo da un dato di fatto importante. Gli attacchi descritti da Unit 42 non hanno scardinato nessun algoritmo crittografico. Hanno semplicemente trovato le crepe che si aprono quando il modo in cui un sistema è stato progettato non coincide perfettamente con il modo in cui viene usato nella pratica.

Non è un problema che riguarda solo le passkey: è lo schema ricorrente dietro quasi tutti gli attacchi degli ultimi anni.

Il cuore del problema non sono le passkey in sé, ma la fiducia eccessiva che riponiamo nei dispositivi. Se un computer è già infetto da un malware, l’attaccante può operare nell’ombra, estraendo chiavi o fabbricando firme valide senza che l’utente se ne accorga, e spesso senza nemmeno bisogno di privilegi elevati.

Questo ci dice una cosa fondamentale: la crittografia più robusta del mondo diventa inutile se l’endpoint (il dispositivo che usiamo) non è sicuro.

Molte delle falle individuate nascono da configurazioni permissive, dove il sistema chiede una verifica di sicurezza ma non la impone in modo rigoroso, oppure non controlla fino in fondo se quella verifica è stata realmente superata.

Mi sento anche di far notare che la ricerca fa un esempio interessante: se un sistema di autenticazione chiede all’improvviso, e ripetutamente, di reinserire un PIN di recupero durante un utilizzo che dovrebbe essere ormai di routine, questo può essere il segnale che qualcuno sta forzando una procedura di re-registrazione del dispositivo.

Sono anomalie comportamentali, non pattern riconoscibili da un antivirus tradizionale, ed è per questo che gli strumenti di analisi del comportamento (le piattaforme SIEM/XSIAM ) diventano sempre più centrali rispetto alle classiche liste di indicatori di compromissione.

Come spesso amo dire , la sicurezza informatica non è un prodotto ma un servizio. Va applicata un’analisi continuativa in grado di adattarsi alle nuove minacce per essere sicuri che le nostre infrastrutture aziendali siano davvero al sicuro e protette per i nuovi vettori di attacco.

Secondo me il fatto che GitHub ed eBay abbiano corretto le falle individuate da Unit 42 prima ancora della pubblicazione della ricerca dimostra che avere processi interni chiari per raccogliere, verificare e correggere rapidamente segnalazioni di questo tipo fa la differenza reale tra un rischio teorico e un incidente evitato”.

Nonostante le scoperte di Unit 42, le passkey sono sicure? Ne consiglia l’uso?

“La risposta breve è: sì, le consiglio assolutamente. Anzi, resto convinto che siano lo strumento di autenticazione più sicuro disponibile oggi su larga scala. Ma è importante leggere la ricerca con la giusta lente, perché i titoli sensazionalistici possono trarre in inganno.

I ricercatori non hanno violato la crittografia. Hanno mostrato che alcune implementazioni specifiche (in particolare come Google gestisce certe fasi di recupero su Chrome per Windows) avevano delle debolezze nel verificare chi stava davvero usando il dispositivo. È la differenza tra scoprire che la combinazione della cassaforte è debole e scoprire che, in certe condizioni, si può convincere il custode ad aprirla senza fare troppe domande.

C’è poi un dettaglio che ridimensiona molto l’allarme: tutti e tre gli attacchi funzionano solo se il pc della vittima è già infetto. Se un attaccante ha il controllo totale del tuo computer, ha già mille strade per farti danno (rubare sessioni, vedere cosa digiti, installare spyware). In questo scenario, le passkey sono un bersaglio in più, non l’unico problema. Il vero rischio non è la passkey, è il dispositivo compromesso.

Quello che resta è sicuramente il fatto che la ricerca ha il merito di aver acceso un faro necessario su un punto critico: molti servizi non controllano tutti i segnali di sicurezza disponibili, come la conferma biometrica reale. Alcuni grandi player hanno già corretto il tiro, segno che il sistema funziona.

Il mio consiglio pratico è quello di continuate a usarle. Per l’utente comune, restano una difesa formidabile contro il phishing e il furto di credenziali. La priorità assoluta resta però la cura del proprio dispositivo: tenerlo aggiornato e pulito.

Per le aziende e gli sviluppatori, il messaggio è di non dare nulla per scontato: attivare le passkey è solo il primo passo; bisogna verificare che ogni singolo segnale di sicurezza venga controllato rigorosamente dal proprio sistema. La tecnologia è ottima, ma va implementata con la stessa cura con cui è stata progettata”, conclude Marco Valenti.