Egy Windows gépen futó, sima felhasználói jogosultságú malware ujjlenyomat, PIN vagy bármilyen képernyőn megjelenő kérés nélkül be tud lépni az áldozat passkey-jel védett fiókjaiba.

A Unit 42 három támadási útvonalat írt le a Chrome Google Password Manager felhőalapú hitelesítője ellen. Ezek neve Pass-ta-key, Silver Pass-ta-key és Golden Pass-ta-key; a legerősebb változat a felhasználó szinkronizált passkey-eit védő mesterkulcsot veszi célba.

A kriptográfiát egyik módszer sem töri fel. A támadások a passkey körüli kódot támadják: azt, hogyan tárolja a Chrome az eszközkulcsokat, hogyan vesz újra fel egy eszközt, miután ez az állapot eltűnt, illetve hogy a bejelentkezési oldal egyáltalán ellenőrzi-e, hogy valóban hitelesítettek-e egy embert.

A támadások képesek észrevétlenül érvényes hitelesítési állítást szerezni, támadó által vezérelt felhasználó-hitelesítési kulcsot telepíteni, vagy kiolvasni a 32 bájtos Security Domain Secretet (SDS), amellyel a szinkronizált passkey-ek privát kulcsait visszafejtik.

A kutatók szerint az utóbbi két módszer az első végpont-fertőzés után is újra felhasználható hozzáférést adhat a támadó saját környezetéből. A jelentés nem ír le ismert, aktív kihasználást, nem ad meg CVE-azonosítókat, érintett Chrome-verziókat, és a teljes elhárítási állapotot sem részletezi.

A National Vulnerability Database 2026. augusztus 3-án végzett keresése nem talált olyan CVE-t, amely megfelelne a három elnevezett technikának.

A kutatás a Chrome-ban működő Google Password Managerre korlátozódik, Windows rendszereken, TPM-mel felszerelt gépeken. Minden támadási útvonal úgy indul, hogy a malware már fut az áldozat eszközén.

A Chromium forráskódja 2026. augusztus 3-i állapotában megerősíti az architektúra egyes részeit, de ebből nem következik automatikusan, hogy a legfrissebb stabil Chrome kiadás továbbra is kihasználható. Ezek utólagos, kompromittálás utáni technikák. Azt írják le, mit ér el a támadó egy már elvesztett gépen, nem pedig azt, hogyan veszítette el a felhasználó a gépet.

A támadás helyi felderítéssel indul. A Chrome a szinkronizált hitelesítési adatokat a %LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB könyvtárban tárolja. A kutatók szerint egy nem privilegizált folyamat is ki tud olvasni annyi metaadatot, hogy azonosítsa a passkey-ekhez tartozó szolgáltatókat és felhasználóneveket, valamint a hitelesítési adatok azonosítóit és a titkosított privát kulcsanyagot.

Első támadási útvonal

Az első technika, a Pass-ta-key, kiolvassa a Chrome által becsomagolt eszközazonosító kulcsot, majd ugyanazzal a TPM-mel írat alá egy támadó által vezérelt kérést a Windows Cryptography API: Next Generation (CNG) hívásain keresztül.

A jelenlegi Chromium forráskód megmutatja, miért újrahasznosítható ez a blob: a Chrome név nélkül hozza létre a TPM-kulcsot, a kódban lévő megjegyzés szerint azért, hogy ne kerüljön lemezre. Ezután a Chrome átlátszatlan blobként exportálja a kulcsot, majd később úgy tölti vissza, hogy egy olyan flag van beállítva, amely elnyom minden felugró kérdést. Ugyanebben a fájlban egy TODO a Chromium 398125799-es problémájára mutat, ahol azt javasolják, hogy ezeket a kulcsokat inkább címkézzék fel.

A Google Cloud Authenticator érvényes assertiont ad vissza, és az egyetlen különbség a valódi felhasználói ellenőrzés után keletkező assertionhöz képest egyetlen bit: a User Verified (UV) flag, amit nem állít be. A jelenlegi Web Authentication specifikáció szerint ha a relying party a userVerification értékét required-re állítja, akkor a folyamatot meg kell szakítania, ha ez a bit hiányzik.

A kutatók szerint a GitHub kikényszerítette ezt az ellenőrzést, míg az eBay elfogadta a teszt assertiont, amíg a cég a bejelentés után be nem foltozta az ellenőrzés hiányát. A három útvonal közül ez az, amely egy olyan ellenőrzésre épít, amit a relying party vezérel, vagyis az oldal akkor is elkaszálhatja a folyamatot, ha a felhőszolgáltatás hibázik – és a Unit 42 által vizsgált két szolgáltató közül az egyik ezt meg is tette.

Második támadási útvonal

A Silver Pass-ta-key a következő réteget veszi célba. A malware rákényszeríti a Chrome-ot, hogy újraregisztrálja az eszközt. A Chrome nem hozza létre azonnal a user-verification kulcsot, és ebben a rövid időablakban a támadó beregisztrálhat egy saját kulcsot helyette.

A Unit 42 szerint a szolgáltatás nem ellenőrzi, hogy az újonnan regisztrált kulcs valóban biztonságos hardverből származik-e. Az ezzel a kulccsal aláírt assertionök UV flaget tartalmaznak, ami a kutatók szerint lehetővé teszi a későbbi bejelentkezéseket az áldozat eszköze nélkül is. A jelenlegi Chromium forráskód önállóan is megerősíti, hogy az újonnan regisztrált eszközök deferred_uv_key_creation állapotban maradhatnak, de a nyilvános kód önmagában nem igazolja vissza a legutóbbi stabil Chrome kiadás ellen végrehajtott, szerveroldali kulcshelyettesítési támadást.

A közzétett leírás nem tér ki arra, hogy az éles szolgáltatás ma már ellenőrzi-e a hardveres attesztációt, mielőtt elfogad egy helyettesítő kulcsot. A Unit 42 ezt a vizsgálatot javasolja ennek az útvonalnak a mérséklésére.

Harmadik támadási útvonal

A Golden Pass-ta-key magát az SDS-t támadja. A Unit 42 szerint a malware újraregisztrálást indíthat, majd kiolvashatja a titkot a Chrome folyamata memóriájából, amíg az rövid ideig egyszerű szövegként ott van, és ezzel visszafejtheti a szinkronizált passkey-ek privát kulcsait.

A jelenlegi Chromium forráskód megerősíti az alapvető kitettséget: a Chrome 32 bájtos security-domain secreteket hoz létre vagy fogad a kliensfolyamat adatstruktúráiban. Ez igazolja, hogy a titok bekerül a Chrome memóriájába, de a megbízható kiolvasás, a fiókátvétel és a jövőbeli secret-epochok közötti tartós megőrzés továbbra is a Unit 42 beszámolójára épül, vagy nyitott kérdés marad.

A kutatók szerint a Google eltávolította a korábbi SDS-kitettséget a Chrome FIDO logjaiból, és az eBay most már ellenőrzi az UV flaget. Azt is mondták, hogy a titok továbbra is eljut a kliensre, és a Chrome memóriájában marad, ezért a naplózási változtatás önmagában nem zárja le az általuk leírt támadási útvonalat.

A közzétett információk nem tisztázzák, hogy mindhárom támadási útvonalat lezárták-e. 2026. augusztus 3-ig a Google nyilvános Chrome-anyagaiban, illetve az eBay támogatási és sajtóoldalain végzett keresések nem találtak olyan közleményt, amely dokumentálná a két említett változtatást, és egyik forrás sem ír le olyan módszert, amellyel a felhasználó ellenőrizhetné, hogy az SDS kiszivárgott-e.

A Google nyilvános támogatási dokumentációja lehetővé teszi a Google Password Manager PIN módosítását vagy az összes Password Manager-adat törlését, de nem ír le kifejezetten SDS-hez kötődő forgatási vagy visszavonási lehetőséget.

A The Hacker News megkereste a Google-t, hogy megtudja, egy ellopott security-domain secret túléli-e a Password Manager PIN megváltoztatását, és a Palo Alto Networksöt is további részletekért a kutatással kapcsolatban. A cikket frissítik, ha választ kapnak.

A relying party-knak a userVerification értékét required-re kell állítaniuk, és a visszakapott UV bitet kell ellenőrizniük, nem elég a kérésben szereplő beállításra hagyatkozni. A hitelesítő szolgáltatóknak attesztálniuk kell az újonnan regisztrált kulcsokat, szigorítaniuk kell az újraregisztrálási és helyreállítási ellenőrzéseket, korlátozniuk kell a helyi passkey-állapothoz való hozzáférést, és távol kell tartaniuk a master kulcsokat a kliens logoktól és memóriától.

A vizsgált források nem térnek ki arra, hogy a Google Password Manager PIN megváltoztatása vagy a Password Manager-adatok törlése érvényteleníti-e azokat a secreteket, amelyek már egy támadó birtokában vannak. Pedig erre lenne szüksége annak a felhasználónak, aki feltételezi, hogy a fiókja kompromittálódott, és lépni akar.