Miért nem elég csak a passkey?
A megszokott többfaktoros hitelesítési (MFA) módszerek, mint az SMS-kód vagy időalapú alkalmazás-kód, egyre kevésbé nyújtanak védelmet, hiszen az Attacker-in-the-Middle (AitM) stratégiát használó adathalász kitek képesek kijátszani őket: a hamis weboldalukon átirányítják a felhasználót, és valós időben továbbítanak minden adatot az igazi oldalnak, majd vissza. Így megszerzik a hitelesített munkamenetet.
Ennek ellenére a passkey-alapú hitelesítés domainhez kötött, így ha egy támadó próbálja felhasználni az ellopott passkey-t, az egyszerűen nem fog működni másik domainen. Még a legfejlettebb adathalász kitek sem tudnak érvényes hitelesítési értéket létrehozni ilyen helyzetben.
Nem elhanyagolható tényező, hogy a bűnözők mindenáron igyekeznek kifinomultabb utakat találni. Az alábbiakban bemutatjuk, milyen módszerekkel próbálják kijátszani a passkey-alapú biztonságot.
Downgrade: a „visszaléptető” támadások
Az egyik leggyakoribb trükk az úgynevezett downgrade (visszaléptető) támadás. Ilyenkor a támadó szándékosan kevésbé biztonságos belépési módot kényszerít a felhasználóra. Például: a valódi alkalmazás felajánlaná, hogy beléphess passkey-jel vagy tartalék MFA-kóddal, de a hamisított oldal csak az utóbbit mutatja, eltüntetve a biztonságos passkey opciót.
Ez a támadástípus SSO (Single Sign-On, egyetlen bejelentkezés több szolgáltatáshoz) esetén is működik: ha az alkalmazás engedi, a támadó egy tartalék felhasználónév-jelszó párost választ, így sikerül megkerülni a biztonságosabb megoldásokat.
Ha egy fióknál megmarad bármilyen tartalék vagy kevésbé védett bejelentkezési lehetőség, a támadók ezt fogják kihasználni.
Eszközkódos (device code) adathalászat
Egy másik támadási módszer az úgynevezett device code phishing (eszközkódos adathalászat). Ilyenkor a támadók kihasználják azokat az eszközöket, amelyek nem támogatják a passkey-t (például böngésző nélküli hardverek, okoseszközök vagy korlátozott bemeneti lehetőségű eszközök). A legitim eszközregisztrációs folyamat során a felhasználó kap egy egyedi kódot, amelyet egy weboldalon kell megadnia a hozzáférés engedélyezéséhez.
Ha a támadó rávesz, hogy egy általa adott kódot gépelj be egy igazi weboldalon, hozzáférést kap a fiókodhoz – miközben minden úgy tűnik, mintha rendben lenne. Nincs naprakész figyelmeztetés a jogosultságokról, a folyamat legitimnek látszik. Ilyen támadások többször is előfordultak Oroszországból indított, Microsoft 365-fiókok elleni célzott akciókban.
Consent phishing: amikor rossz helyre adsz engedélyt
A consent phishing (beleegyezéses adathalászat) lényege, hogy a támadók ráveszik a célszemélyt: engedélyezzen egy rosszindulatú alkalmazásnak hozzáférést az adataihoz vagy hogy cselekedjen a nevében. Mivel a modern rendszerek, mint a Microsoft Azure, a Google Workspace vagy akár a GitHub mind támogatják az OAuth-alapú jogosultságadást (harmadik fél alkalmazás jogosulttá tétele), a támadók egy hamis alkalmazást regisztrálnak, majd egy linkkel kérnek jóváhagyást – a felhasználó néhány kattintással átadja az irányítást.
Ami különösen veszélyes: ha egyszer megadod ezt a jogosultságot, a támadó később is hozzáférhet a fiókhoz, akkor is, ha a jelszót vagy az MFA-t módosítod. Sőt, ezzel további támadásokat is indíthat, például kártékony programot terjeszthet más felhasználók felé.
E-mailes vagy kódos megerősítés kijátszása
Az e-mailes verifikáció (megerősítő link vagy kód e-mailben) szintén gyakori kockázat: a támadó szociális manipulációval rávesz, hogy továbbítsd neki a kapott kódot, vagy kattints az általa küldött linkre, így megkerülve a biztonsági kontrollokat.
Még kifinomultabb trükk, amikor valaki egy cég e-mail domainjére új identity provider (IdP) fiókot regisztrál, amin keresztül SSO-t használ. Felmérések szerint 10-ből 6 alkalmazás megengedi ezt a kiskaput, így a támadók ki tudják játszani a belső kontrollokat is – főleg, ha a fiókhoz nincs jól beállított központi kezelés.
Alkalmazás-specifikus jelszavakkal való visszaélés
Az alkalmazás-specifikus jelszavak (app-specific password, ASP) még ma is elérhetők néhány nagy szolgáltatónál (például a Google-nél vagy az Apple-nél), hogy a régi alkalmazások, amelyek nem tudnak modern OAuth-alapú hitelesítést, mégis hozzáférhessenek adataidhoz. Ezeket általában a felhasználó külön generálja.
A támadók szociális manipulációval rávehetnek, hogy (magukat technikai támogatásnak vagy szolgáltatói képviselőnek kiadva) generálj nekik ilyen jelszót, majd azt elküldd nekik. Így a támadó MFA nélkül, automatizált módon, hosszú távon hozzáférhet minden fontos adatodhoz – anélkül, hogy a legtöbb biztonsági figyelmeztetés megszólalna.
Korábban például orosz információs műveletek célpontjainál használtak ilyen támadásokat személyre szabott social engineering trükkökkel.
Helyi fiókok és passkey támogatás elmaradása
A legkönnyebb utat gyakran azok a helyi fiókok jelentik, amelyek egyáltalán nem támogatják a passkey-t. Számos népszerű üzleti alkalmazás, mint a Slack, a Mailchimp, a Postman vagy a GitHub jelenleg sem használ közvetlenül passkey-t, hanem csak az SSO-t (amit viszont sokszor ki lehet játszani a fent említett trükkökkel).
Sok vállalatnál emellett regisztrálva maradnak a régi, gyenge vagy kompromittált belépési módok, illetve tartalék jelszavak, így egy átlagos, 1000 fős szervezetben akár 15 000 különböző fiók és sebezhetőség is létrejöhet.
Ennek fényében: Mire figyelj igazán?
Általánosságban igaz: ha a fiókodban bármilyen nem passkey-alapú, gyenge vagy tartalék lehetőség létezik, a támadók előbb-utóbb ki fogják használni azt. Csak azok a fiókok igazán védettek, ahol kizárólag passkey van engedélyezve, és semmilyen tartalék (MFA-s vagy jelszavas) alternatíva nincs beállítva – de már a kész rendszerekben is bőven előfordulhatnak kockázatos beállítások, például a Microsoft alapértelmezett conditional access (CA) sablonjai gyakran nem tekintik veszélyesnek a gyanús bejelentkezéseket.
Az alkalmazások, fiókok és bejelentkezési módok dzsungelében a szervezeti IT-biztonságnak folyamatos auditokat, felülvizsgálatokat kell végeznie ahhoz, hogy valódi védelmet nyújtson az adathalászat ellen.
