Biztonsági kutatók három új támadási technikát mutattak be, amelyek segítségével egy már kompromittált Windows számítógépen futó malware visszaélhet a Google Password Managerben szinkronizált passkey-ek mögötti hitelesítési infrastruktúrával.
A Palo Alto Networks Unit 42 kutatói által feltárt módszerek lehetővé tehetik, hogy egy támadó bizonyos körülmények között a felhasználó ujjlenyomatának, arcfelismerésének vagy Windows Hello PIN-kódjának tényleges használata nélkül hitelesítse magát passkey-jel védett szolgáltatásokban.
A három technikát a kutatók:
- Pass-ta-key
- Silver Pass-ta-key
- Golden Pass-ta-key
néven mutatták be.
A támadások fokozatosan egyre komolyabb hozzáférést biztosítanak. Az első módszer még a kompromittált számítógépet használja hitelesítési eszközként, míg a legsúlyosabb variáció elméletileg lehetővé teheti a szinkronizált passkey-ekhez tartozó privát kulcsok visszafejtését és azok támadói infrastruktúrán történő használatát.
Fontos azonban hangsúlyozni: a kutatás nem bizonyította, hogy a WebAuthn vagy a passkey-ek alapjául szolgáló nyilvános kulcsú kriptográfia feltörhető lenne.
A támadás kiindulópontja minden bemutatott esetben az, hogy a támadó már képes kódot futtatni a felhasználó Windows rendszerén.
A sérülékeny pontot tehát nem maga a digitális aláírási algoritmus, hanem az azt körülvevő:
- böngésző;
- eszközregisztráció;
- cloud authenticator;
- kulcsszinkronizáció;
- helyreállítási mechanizmus;
- valamint felhasználó-ellenőrzési folyamat
jelenti. A Unit 42 szerint ez egy új, fontos támadási felületet hoz létre a jelszómentes hitelesítés terjedésével.
A passkey továbbra is lényegesen biztonságosabb a hagyományos jelszónál
A passkey-ek aszimmetrikus kriptográfiát alkalmaznak.
A regisztráció során létrejön egy kulcspár:
- egy nyilvános kulcs, amelyet a szolgáltató tárol;
- és egy privát kulcs, amelyet a hitelesítő kezel.
Bejelentkezéskor a szolgáltatás egy egyszer használatos kihívást küld, amelyet a privát kulccsal kell digitálisan aláírni.
A privát kulcsot a felhasználónak soha nem kell begépelnie, és az nem kerül át jelszóhoz hasonló újrafelhasználható titokként a weboldalhoz.
A WebAuthn szabvány ráadásul a credentialt egy adott Relying Partyhoz, vagyis szolgáltatáshoz köti. Egy például github.com számára létrehozott passkey nem használható egyszerűen egy támadó által létrehozott hasonló domainen.
A W3C WebAuthn specifikációja szerint a credential privát kulcsa az authenticatorhoz kapcsolódik, és normál működés során nem kerülhet más fél birtokába.
Ez az oka annak, hogy a passkey-ek rendkívül ellenállók:
- klasszikus phishinggel;
- credential stuffinggal;
- password sprayinggel;
- jelszóadatbázis-szivárgással;
- és az egyszerű jelszólopással
szemben.
A most bemutatott támadások nem ezeket a tulajdonságokat törik meg.
A szinkronizált passkey bonyolultabb infrastruktúrát igényel
Az eszközhöz kötött passkey esetében viszonylag egyszerű a biztonsági modell: a privát kulcs az adott authenticatoron marad.
A Google Password Manager azonban lehetővé teszi, hogy ugyanazok a passkey-ek több engedélyezett eszközön is használhatók legyenek.
Ehhez a rendszernek képesnek kell lennie:
- a credentialök titkosított szinkronizálására;
- egy új eszköz hitelesítésére;
- kulcsok biztonságos helyreállítására;
- valamint annak eldöntésére, hogy valóban az engedélyezett felhasználó használja-e a credentialt.
A Google hivatalos dokumentációja szerint a Google Password Manager PIN többek között arra szolgál, hogy a felhasználó új eszközön hozzáférhessen passkey-eihez, igazolja saját személyazonosságát, és a titkosított adatokhoz még maga a Google se férhessen hozzá olvasható formában.
A Unit 42 kutatásának középpontjában éppen ez a kiegészítő infrastruktúra áll.
Hogyan működik a Google Cloud Authenticator?
A kutatók elemzése szerint egy támogatott Windows-rendszeren a Chrome az eszközt először regisztrálja a Google Cloud Authenticatorhoz.
A folyamat során több, egymástól eltérő szerepű kulcs vesz részt a hitelesítésben.
Az egyik az eszköz identitását bizonyítja a cloud szolgáltatás számára.
Egy másik kulcs a felhasználó helyi ellenőrzéséhez kapcsolódik, vagyis például ahhoz, hogy a Windows Hello segítségével PIN-kódot, ujjlenyomatot vagy arcfelismerést használt-e.
A Google rendszerének ezután biztonságosan hozzá kell férnie a szinkronizált credentialök titkosításához használt kulcsanyaghoz.
A Unit 42 ezt a központi elemet Security Domain Secretnek – SDS-nek nevezi.
A kutatás szerint ez egy 32 bájtos titok, amely kulcsszerepet játszik a Google Password Manager passkey-infrastruktúrájának titkosításában.
A malware először feltérképezheti, milyen passkey-eket használ az áldozat
A kutatók szerint a Chrome helyi profiljában található adatokból egy, a felhasználó jogosultságaival futó malware információkat szerezhet a szinkronizált WebAuthn credentialökről.
Ez önmagában még nem jelenti a privát kulcs megszerzését.
A támadó azonban olyan metaadatokat láthat, amelyek segíthetnek azonosítani:
- mely szolgáltatásokhoz létezik passkey;
- milyen felhasználónév kapcsolódik hozzá;
- milyen credential identifier tartozik hozzá;
- és milyen titkosított kulcsanyag található az eszközön.
Ez komoly felderítési értéket jelenthet.
Egy információlopó malware például megállapíthatja, hogy az áldozat rendelkezik-e passkey-jel:
- kriptotőzsdéhez;
- fejlesztői platformhoz;
- vállalati azonosítási rendszerhez;
- pénzügyi szolgáltatáshoz;
- vagy más kiemelt célponthoz.
Ezután a támadó koncentrálhat a számára legértékesebb credentialre.
Pass-ta-key: a TPM-et használják a támadó helyett
Az első támadási technika a Pass-ta-key.
A Google Password Manager Windows alatt egy hardveresen védett eszközazonosító kulcsot használ annak igazolására, hogy egy kérés egy korábban regisztrált számítógépről érkezik.
A kulcs a Windows Cryptography API: Next Generation – CNG – infrastruktúráján keresztül kapcsolódhat a rendszer Trusted Platform Module-jához.
A TPM egyik legfontosabb biztonsági tulajdonsága, hogy a privát kulcsot nem kell olvasható formában exportálni.
Ez hatékony védelmet nyújt például az ellen, hogy egy támadó egyszerűen átmásolja a kulcsot egy másik számítógépre.
A Unit 42 azonban rámutatott egy fontos különbségre.
A malware-nek nem feltétlenül kell ellopnia a privát kulcsot.
Ha már a jogosult számítógépen fut, megpróbálhatja magát a legitim TPM-et rávenni arra, hogy a támadó által megadott adatot aláírja.
A kutatók szerint a Google Password Manager eszközazonosításához használt kulcs művelete nem minden esetben igényel Windows Hello-jóváhagyást.
Ez azt jelentheti, hogy az áldozat gépén futó malware a háttérben használja a hardveresen védett kulcsot anélkül, hogy:
- PIN-kérés;
- ujjlenyomat-ellenőrzés;
- arcfelismerés;
- vagy más látható felhasználói jóváhagyás
jelenne meg.
A Google Cloud Authenticator pedig egy valóban regisztrált eszköztől származó hiteles aláírást kap.
Van azonban egy fontos korlátozás: a UV bit
A Pass-ta-key első változata nem feltétlenül tudja azt bizonyítani, hogy maga a felhasználó is elvégezte a helyi ellenőrzést.
A WebAuthn authenticator data tartalmaz egy User Verified – UV – flaget.
Ez jelzi, hogy az authenticator ténylegesen elvégezte-e a felhasználó ellenőrzését.
A W3C specifikáció szerint a UV flag akkor lehet beállítva, ha a user verification ténylegesen megtörtént.
Ez lehet például:
- biometrikus ellenőrzés;
- eszköz-PIN;
- Windows Hello;
- vagy más authenticator által támogatott hitelesítési mechanizmus.
Ha egy szolgáltatás biztonsági követelménye szerint user verification szükséges, nem elegendő egyszerűen azt kérnie a böngészőtől.
A szervernek a visszakapott authenticator data alapján ellenőriznie is kell a UV flaget.
A Google WebAuthn fejlesztői dokumentációja ugyancsak figyelmeztet arra, hogy a UV bit jelzi, valóban megtörtént-e a felhasználó ellenőrzése.
Ez az első támadási variációval szemben fontos védelmi réteg.
A kutatók GitHubon és eBayen is tesztelték
A Unit 42 két különböző szolgáltatáson vizsgálta a Pass-ta-key működését.
A kutatás szerint a GitHub megfelelően ellenőrizte a user verification állapotát, és nem fogadta el azt az assertiont, amelynél nem történt meg a szükséges felhasználó-ellenőrzés.
Az eBay tesztelt implementációja ezzel szemben a kutatók szerint ugyan userVerification: "required" feltételt kért, de a szerveroldali ellenőrzés nem kezelte megfelelően a visszaérkező UV állapotot.
Az Unit 42 értesítette az eBayt, a problémát pedig a publikáció előtt javították.
Ez jól példázza, hogy a passkey-biztonság nem kizárólag az authenticatoron múlik.
A szolgáltatónak is helyesen kell ellenőriznie a WebAuthn-választ.
Silver Pass-ta-key: hamis user verification
A második támadás ennél lényegesen tovább megy.
A Silver Pass-ta-key célja, hogy megkerülje azt a védelmet is, amelyet a megfelelően ellenőrzött UV flag biztosít.
A kutatók azt vizsgálták, hogyan történik egy Windows eszköz első regisztrációja és újraregisztrációja a Google Cloud Authenticator rendszerében.
A Unit 42 szerint bizonyos állapotokban a támadó manipulálhatja a helyi enrolment információkat, és egy új onboarding folyamatot idézhet elő.
A támadás során egy támadó által kontrollált user-verification kulcs kerülhet regisztrálásra.
Ha a cloud infrastruktúra ezt legitim ellenőrzési kulcsként fogadja el, később a támadó olyan hitelesítési választ generálhat, amelynél a rendszer már úgy tekinti:
a felhasználó ellenőrzése megtörtént.
Ennek eredményeként a UV bit is beállítható.
Ez azért jelent jelentős különbséget, mert a megfelelően konfigurált szolgáltatás sem feltétlenül tudja megkülönböztetni a hamis ellenőrzési folyamatot a valóditól, ha az authenticator maga állítja, hogy user verification történt.
A Silver támadás túlélheti az eredeti fertőzést
Az első Pass-ta-key variáció egyik fontos korlátozása, hogy az áldozat számítógépét használja hitelesítési eszközként.
A Silver Pass-ta-key már komolyabb tartósságot adhat.
Ha a támadó saját kulcsát sikerül legitim user-verification kulcsként regisztrálnia, a későbbi hitelesítéshez már nem feltétlenül szükséges az eredeti számítógép folyamatos használata.
A Unit 42 ezért azt javasolja, hogy az authenticator-szolgáltatók egy új vagy lecserélt ellenőrzési kulcs esetében ne csak annak meglétét ellenőrizzék, hanem annak eredetét és attestation tulajdonságait is.
Az újraregisztrációt szintén magas kockázatú műveletként kell kezelni.
Golden Pass-ta-key: a szinkronizált passkey-ek fő titkának megszerzése
A kutatás legsúlyosabb támadási módszere a Golden Pass-ta-key.
Ennek célpontja közvetlenül a Security Domain Secret.
A Unit 42 szerint az SDS lényegében a Google-fiók szinkronizált passkey-ökoszisztémájának egyik központi titkosítási eleme.
A kutatók először azt fedezték fel, hogy bizonyos FIDO diagnosztikai logokban az SDS olvasható formában megjelenhetett.
A kutatás szerint ezt a konkrét logging problémát a Google a felelős bejelentést követően megszüntette.
A kutatók szerint azonban maradt egy mélyebb architekturális probléma:
amikor a Chrome helyreállítja vagy újra inicializálja a Google Password Manager passkey-infrastruktúráját, az SDS-nek valamilyen ponton elérhetővé kell válnia a böngésző folyamatának.
Ez azt jelenti, hogy átmenetileg a Chrome memóriájában is jelen lehet.
A malware a Chrome memóriájában keresheti a titkot
A Golden Pass-ta-key támadás során a malware a kutatók szerint új onboarding folyamatot idézhet elő.
Ezután figyelheti a passkey-infrastruktúrához kapcsolódó állapotváltozásokat, illetve a Chrome memóriáját.
Amikor a 32 bájtos SDS megjelenik a böngésző memóriájában, a támadó megpróbálhatja azt kinyerni.
Ha ez sikerül, a támadó össze tudja kapcsolni:
- az SDS-t;
- a Chrome helyi adatbázisából megszerzett titkosított WebAuthn-adatokkal.
A kutatók szerint ennek segítségével visszafejthetők lehetnek a szinkronizált passkey-ekhez kapcsolódó privát credential kulcsok.
Ez már gyökeresen más támadási modell.
A támadónak nem kell:
- folyamatosan használnia az eredeti TPM-et;
- fenntartania a malware-t az áldozat számítógépén;
- vagy minden bejelentkezésnél a Google Cloud Authenticatoron keresztül hitelesítenie.
Az így megszerzett kulcsanyagot elméletileg saját authenticator-infrastruktúrába is áthelyezheti.
A Unit 42 a kutatás során egy kriptovaluta-szolgáltatás elleni hitelesítéssel is demonstrálta a koncepciót.
A kutatók szerint a jövőbeni credentialök is veszélybe kerülhetnek
A Golden Pass-ta-key egyik legaggasztóbb következménye az SDS életciklusával kapcsolatos.
A Unit 42 elemzése szerint ugyanaz a Security Domain Secret szolgálhat a security domainhez tartozó több szinkronizált credential védelmére.
A kutatók arra figyelmeztetnek, hogy amennyiben a támadó megszerzi ezt a titkot, az olyan passkey-ekre is veszélyt jelenthet, amelyek ugyanazon security domain alatt később kerülnek szinkronizálásra.
Ezt azonban fontos megfelelő fenntartással kezelni.
A Google nyilvános dokumentációja jelenleg nem részletezi olyan mélységben az SDS rotációs és visszavonási mechanizmusát, hogy kívülről teljes bizonyossággal megállapítható legyen a megszerzett SDS teljes élettartama.
Ezért a jövőbeni passkey-ekre vonatkozó tartós kockázat jelenleg a Unit 42 technikai elemzésének következtetése.
A Google Password Manager PIN megváltoztatása nem feltétlenül ugyanaz, mint a passkey-ek visszavonása
A Google lehetővé teszi a Google Password Manager PIN módosítását.
A hivatalos Chrome dokumentáció szerint ehhez a Google Password Manager beállításainál a Change Google Password Manager PIN lehetőség használható.
A dokumentáció azt is lehetővé teszi, hogy a felhasználó végső esetben teljesen resetelje Google Password Manager passkey-eit.
Ez minden tárolt passkey törlésével jár, így azokat később az egyes szolgáltatásokhoz újra létre kell hozni.
A Google dokumentációja azonban nem állítja, hogy egy egyszerű PIN-módosítás automatikusan új SDS-t generálna.
Ezért egy feltételezett privát kulcs kompromittálódása esetén nem célszerű kizárólag a Password Manager PIN cseréjére támaszkodni.
A legbiztosabb módszer: a passkey visszavonása magánál a szolgáltatónál
Egy passkey hitelesítésének másik oldala mindig az adott szolgáltató.
A webhely az accountban tárolja a passkey nyilvános kulcsához tartozó credential recordot, és ezzel ellenőrzi a későbbi digitális aláírást. A WebAuthn szabvány lehetővé teszi ezeknek a credential recordoknak a törlését.
Ezért ha egy passkey privát kulcsa potenciálisan kompromittálódott, a legfontosabb lépés az, hogy azt magánál az érintett szolgáltatásnál is vissza kell vonni.
Ha például egy GitHubhoz tartozó passkey került veszélybe, akkor azt a GitHub-fiókban kell törölni.
A régi privát kulccsal készített aláírás így többé nem felel meg egy aktív credentialnek.
Nem távoli támadásról van szó
A kutatás egyik legfontosabb korlátozása, hogy mindhárom támadási útvonal post-compromise technika.
A támadó először valamilyen más módon malware-t kell hogy futtasson az áldozat Windows-rendszerén.
Ez történhet például:
- phishing;
- fertőzött program;
- böngészős vagy alkalmazássérülékenység;
- supply-chain támadás;
- vagy más kezdeti hozzáférési módszer
eredményeként.
A Unit 42 jelenleg nem közölt bizonyítékot arra, hogy a Pass-ta-key technikákat valódi támadásokban alkalmaznák.
A kutatók nem kapcsolták azokat ismert malware-családhoz vagy threat actorhoz, és nyilvános CVE-azonosító sem kapcsolódik a teljes támadási lánchoz.
Ez tehát nem azt jelenti, hogy valaki az internetről egyszerűen „ellophatja” bármely Google Password Managerben tárolt passkey-t.
A támadónak előbb kompromittálnia kell a végpontot.
Miért fontos mégis a kutatás?
Az információlopó malware-ek ma már rendszeresen próbálják megszerezni:
- böngészőben tárolt jelszavakat;
- session cookie-kat;
- OAuth tokeneket;
- kriptotárcákat;
- hitelesítési adatokat.
A passkey-ek terjedése csökkenti a hagyományos credential theft értékét.
Egy jelszó hiányában nincs mit egyszerűen kimásolni a böngésző adatbázisából és később újra felhasználni.
Ez azonban gazdasági ösztönzőt teremt a támadók számára arra, hogy más rétegeket kezdjenek célba venni.
A most publikált kutatás azt mutatja, hogy ilyen új célpont lehet:
- az eszköz trust relationshipje;
- a TPM által kezelt identitáskulcs;
- a passkey onboarding;
- a recovery mechanizmus;
- vagy a szinkronizációs master secret.
Vagyis a credentiallopás nem feltétlenül tűnik el.
Átalakul.
Mit kell tenniük a WebAuthn-t használó szolgáltatóknak?
Azoknak a szervezeteknek, amelyek saját alkalmazásaikban passkey-alapú bejelentkezést biztosítanak, érdemes felülvizsgálniuk a WebAuthn implementáció szerveroldali részét.
Magas biztonsági követelmény esetén:
userVerification: "required"
beállítás használata indokolt.
De ez önmagában nem elegendő.
A szervernek a visszaérkező authenticator data alapján azt is ellenőriznie kell, hogy a UV flag ténylegesen be van-e állítva.
A WebAuthn szabvány és a Google fejlesztői útmutatója is egyértelműen különbséget tesz a user verification igénylése és annak tényleges megtörténte között.
A magas kockázatú felhasználóknál érdemes lehet eszközhöz kötött hardverkulcsot használni
A szinkronizált passkey-ek egyik legnagyobb előnye a használhatóság.
Ha a felhasználó új telefont vagy számítógépet kap, credentialjei helyreállíthatók és több engedélyezett eszközön használhatók.
Ez azonban szükségszerűen összetettebb infrastruktúrát jelent.
Kiemelt kockázatú fiókok esetében ezért továbbra is lehet létjogosultsága olyan device-bound hardveres security keyeknek, amelyek privát kulcsai nem szinkronizálhatók felhőn keresztül más eszközre.
Ez különösen megfontolandó:
- rendszergazdák;
- privileged accountok;
- pénzügyi munkatársak;
- fejlesztők;
- kódtárak kezelői;
- vezetők;
- kritikus infrastruktúrához hozzáférő személyek
esetében.
Ez nem jelenti azt, hogy a szinkronizált passkey-ek általánosan nem biztonságosak.
A két modell egyszerűen eltérő kompromisszumot kínál a biztonság és a hordozhatóság között.
Mit tegyen a felhasználó, ha malware-fertőzésre gyanakszik?
Ha egy olyan Windows-számítógép fertőződhetett meg, amelyen Google Password Manager passkey-ek találhatók, az esetet nem célszerű pusztán jelszócserével lezárni.
A biztonságosabb megközelítés:
- az érintett gép izolálása;
- szükség esetén újratelepítése vagy megbízható állapotból történő helyreállítása;
- a Google-fiók aktív munkameneteinek és eszközeinek átvizsgálása;
- ismeretlen eszközök eltávolítása;
- kritikus fiókok passkey-einek ellenőrzése;
- szükség esetén a passkey-ek közvetlen visszavonása;
- majd új credentialök létrehozása egy bizonyítottan tiszta eszközről.
A Google Password Manager szükség esetén valamennyi tárolt passkey resetelését is lehetővé teszi, amely után azokat az érintett szolgáltatásokhoz újra létre kell hozni.
A jelszómentes hitelesítés nem jelent támadhatatlanságot
A Unit 42 kutatása nem cáfolja a passkey-ek egyik legfontosabb ígéretét.
A passkey továbbra is jelentősen erősebb védelmet biztosít a klasszikus credentialalapú támadásokkal szemben, mint a hagyományos jelszó.
Nincs:
- újrafelhasználható jelszó;
- egyszerűen ellopható shared secret;
- klasszikus phishing oldalon begépelhető credential;
- vagy több szolgáltatás között újrahasznosítható titok.
A támadási felület azonban egyre inkább az infrastruktúra más részei felé tolódik.
A szinkronizált passkey biztonsága már nem kizárólag a kriptográfián múlik.
Függ:
- az endpoint biztonságától;
- a böngésző implementációjától;
- a hardveres kulcskezeléstől;
- az onboarding folyamatoktól;
- a recovery mechanizmusoktól;
- a cloud authenticator működésétől;
- és végül attól is, hogy maga a weboldal megfelelően ellenőrzi-e a WebAuthn-választ.
A Pass-ta-key kutatás legfontosabb üzenete ezért nem az, hogy „a passkey feltörhető”.
Sokkal inkább az, hogy a legerősebb kriptográfiai hitelesítés is csak annyira biztonságos, mint a teljes infrastruktúra, amely létrehozza, tárolja, szinkronizálja, helyreállítja és használja a hozzá tartozó kulcsokat.
Ahogy a jelszómentes hitelesítés egyre szélesebb körben terjed, várhatóan a kiberbűnözők figyelme is egyre inkább ezekre a periférikus trust boundary-kre helyeződik át.
A jelszó ellopásának korszaka tehát lassan háttérbe szorulhat.
A hitelesítési infrastruktúra elleni támadásoké viszont most kezdődhet igazán.
