Mi az a készülékkód-folyamat?
A készülékkód- vagy eszközauthorizációs folyamat olyan internetkapcsolattal rendelkező, de klasszikus beviteli módszerrel nem rendelkező eszközök hitelesítésére szolgál, mint a nyomtatók, okostévék vagy akár egy wifis kenyérpirító. Ezeken nem lehet a felhasználónevet és jelszót begépelni, ezért az eszköz kér egy hatszámjegyű eszközkódot a felhőből, majd ezt egy másik, böngészővel rendelkező eszközön validálja a felhasználó. Ha sikeres az ellenőrzés, az eredeti eszköz hozzáférési tokent kap, így csatlakozhat a felhőszolgáltatáshoz.
Fontos megjegyezni, hogy a készülékkód-folyamat réspiacra készült, speciális helyzetekben használatos; az átlagos felhasználók általában nem találkoznak vele.
Adathalászat készülékkóddal: támadás a Microsoft Azure ellen
A hackerek kifinomult adathalász-kampányokban arra veszik rá az áldozatot, hogy legitim Microsoft-oldalon adják meg a készülékkódot, majd bejelentkezzenek felhasználónévvel, jelszóval és akár többfaktoros kóddal is. Mégis, a támadó mindent az eredeti Azure API-kon keresztül szervez, az áldozat végig legitim Microsoft URL-t lát, így ritkán gyanakszik.
A támadás lépései:
1. A támadó kér egy eszközkódot az Azure API-tól (ehhez semmilyen jogosultság nem kell).
2. Az áldozatot ráveszik, hogy egy szintén eredeti Microsoft-oldalon adja meg ezt a kódot, belép, és megadja az MFA-kódot is.
3. A támadó az eszközkód ismeretében a megfelelő API-nál lekéri az így keletkező hozzáférési és frissítő tokeneket, amelyekkel innentől kezdve a felhasználó nevében dolgozhat.
Fontos megjegyezni, hogy az egész támadás a Microsoft infrastruktúráján keresztül fut, nem történik klasszikus „feltörés” vagy exploitálás – mindössze visszaélés egy legitim folyamattal, társadalmi manipulációval.
Egyedülállóan veszélyes, hogy a támadó határozza meg, milyen szolgáltatásokat és milyen klienseket ér el a token: például, ha a Graph API vagy akár a Microsoft Authentication Broker van megadva, akár e-mail-szinkron, naplóolvasás, fájlkezelés, multifaktoros regisztráció, sőt új eszközök csatlakoztatása is lehetséges. Ezek a tokenek kifejezetten erősek, ha jól van beállítva a támadó oldalán a lekérdezés; vagyis a támadó sokszor jobban jár, mintha hagyományosan törné fel a fiókot.
Google: szinte teljesen védett a készülékkódos adathalászat ellen
A készülékkód-folyamat nem csak az Azure-ben található meg, hanem a Google is támogatja az OAuth 2.0 ezen ágát – csakhogy egészen másképp! A Google Workspace/Google Cloud szolgáltatásoknál néhány kulcsfontosságú különbség miatt a támadási lehetőség rögtön elhal.
Először is, a Google szigorúan korlátozza, hogy a készülékkód-folyamaton keresztül milyen jogosultságokat lehet szerezni. Gyakorlatilag csak Google Drive-fájlkezelésre, illetve néhány YouTube-engedélyre szűkül a lehetőség; a felhasználó teljes fiókját, levelezését vagy identitását nem lehet ilyen egyszerűen kompromittálni.
Másodszor, a támadónak saját kliensazonosítóval kell OAuth-alkalmazást készítenie, mivel a Google nem engedélyez nyilvános, bárki által használható kliensazonosítókat ebben a folyamatban – szemben az Azure-nál található, bárki által használható client ID-kkal. További plusz korlát: ha egy alkalmazás „túl sok” vagy túl erős jogosultságot kér, csak szigorú Google-ellenőrzés után használhatja bárki.
A technikai kivitelezés (pl. Python- vagy más szkripttel történő készülékkód-lekérés és polling) hasonló az Azure-hoz, de az így szerzett hozzáférési tokenek rendkívül korlátozottak maradnak. Így a támadók legfeljebb adott Google Drive-fájlokon kísérletezhetnek.
Fontos megjegyezni, hogy lehetséges, hogy léteznek kevéssé dokumentált, rejtett támadási vektorok is a Google-nél, de a publikusan ismert lehetőségek alapján a Microsoft-féle támadás itt nem volna kivitelezhető.
Azure és Google: összevetés és tanulságok
Az Azure-féle készülékkódos phishing rendkívül veszélyes, mivel a támadó szabadon választhat jogosultságokat, ténylegesen kompromittálhat teljes fiókokat, és nem kell a folyamat során gyanús linkeket vagy saját, hamisított oldalakat alkalmaznia. Mindent el lehet intézni a hivatalos, jogtiszta Microsoft URL-eken keresztül, így a védekezés is jóval nehezebb.
Ezzel szemben a Google rendszere, bár támogatja az OAuth 2.0 eszközkód-folyamatot, szűkíti a kiadható jogosultságokat, tiltja a névtelen fejlesztői alkalmazásokat, valamint kötelezően átvizsgálja az appokat, ha azok túl erős engedélyeket igényelnek. Így egyrészt technikailag, másrészt adminisztratív módon akadályozza a támadásokat.
Összességében elmondható, hogy azonos protokoll alkalmazása ellenére az implementáció részletei óriási különbségeket eredményeznek a támadások sikerességében és súlyosságában: az Azure jelenleg komolyabban veszélyeztetett, míg a Google megközelítése erősen korlátozza az adathalászok mozgásterét.
