Trei atacuri asupra passkey-urilor din Chrome: ce demonstrează de fapt și ce nu
Unit 42 a publicat trei tehnici care ocolesc verificarea utilizatorului la passkey-urile Chrome. Toate pornesc de la malware deja prezent pe dispozitiv.
Pe 3 august 2026, cercetătorii Unit 42 de la Palo Alto Networks au publicat trei tehnici prin care un atacator poate folosi passkey-urile stocate în Google Password Manager fără ca utilizatorul să confirme ceva. Titlurile care au urmat sugerau că passkey-urile au fost sparte. Nu au fost — dar concluzia reală este mai utilă decât panica.
Ce fac, concret, cele trei tehnici
- Pass-ta-key — malware-ul extrage cheia de identitate a dispozitivului din Chrome și determină TPM-ul să semneze cereri controlate de atacator. Asertiunea rezultată nu are bitul „User Verified"; singura diferență față de una produsă după o verificare reală a utilizatorului este acel bit.
- Silver Pass-ta-key — atacatorul forțează o reînrolare a dispozitivului și își înregistrează propria cheie de verificare înainte ca Chrome să o creeze pe a sa, ocolind verificările de atestare hardware.
- Golden Pass-ta-key — malware-ul declanșează reînrolarea și extrage din memoria procesului Chrome secretul de 32 de octeți al domeniului de securitate, cât timp există în clar. Cu el se pot decripta cheile private ale passkey-urilor sincronizate.
La momentul publicării nu exista niciun CVE alocat și nicio dovadă de exploatare în sălbăticie. Google a eliminat o expunere a secretului din jurnalele Chrome, iar eBay a început să valideze bitul de verificare a utilizatorului.
De ce contează bitul acela
Standardul WebAuthn permite serviciului care primește autentificarea să ceară explicit verificarea utilizatorului — biometrie, PIN sau altă confirmare — și să verifice în răspuns că ea chiar a avut loc. Multe implementări nu o cer și nu o verifică, tratând simpla posesie a cheii ca fiind suficientă. Exact acolo lucrează primele două tehnici.
Ce rămâne adevărat despre passkey-uri
Passkey-urile rezolvă problema pentru care au fost create: phishingul de credențiale. Cheia privată nu părăsește dispozitivul, nu poate fi tastată într-un site fals și este legată criptografic de domeniul real. Un kit de tip adversary-in-the-middle care fură sesiuni Microsoft 365 nu funcționează împotriva unui passkey corect implementat. Aceasta rămâne valabil după cercetarea Unit 42.
Ce demonstrează cercetarea este limita firească a oricărui factor de autentificare: dacă dispozitivul pe care el trăiește este compromis, garanțiile lui se erodează. Este același adevăr care se aplică și aplicațiilor TOTP, și tokenurilor de sesiune, și managerelor de parole.
Ce se poate face
- Pentru echipele care construiesc aplicații: setați `userVerification` pe `required` și verificați efectiv bitul UV în asertiunea primită. Este o linie de configurare care închide două dintre cele trei căi.
- Atestați cheile nou înrolate și întăriți verificările la reînregistrare, astfel încât o reînrolare forțată să nu poată introduce o cheie a atacatorului.
- Nu lăsați secrete de domeniu în jurnalele clientului și limitați accesul la starea locală a passkey-urilor.
- Pentru organizații: prioritatea rămâne igiena endpointului. Toate cele trei căi presupun execuție de cod pe stația utilizatorului — EDR, control al aplicațiilor și privilegii limitate contează mai mult aici decât alegerea factorului de autentificare.
- Pentru conturile cu risc ridicat, un authenticator hardware separat (cheie de securitate fizică) nu este afectat de aceste tehnici, pentru că materialul criptografic nu trăiește în procesul browserului.
Ce înseamnă pentru instruirea angajaților
Mesajul care trebuie evitat este „passkey-urile nu mai sunt sigure". Este fals și produce exact reacția greșită — întoarcerea la parole. Mesajul corect este că passkey-urile rămân cea mai bună apărare disponibilă împotriva phishingului, iar sarcina utilizatorului nu se schimbă: să nu execute ce nu a cerut, să raporteze comportamente neobișnuite ale stației și să nu ignore avertismentele EDR-ului.
Despre cazul opus — când al doilea factor cade nu pentru că e compromis dispozitivul, ci pentru că atacatorul fură direct seed-urile TOTP dintr-un echipament de rețea — am scris în articolul despre campania INC Ransomware, publicat în aceeași zi.