Ez az e-mail cím a spamrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.

Így könnyítheti meg a támadó dolgát a többlépcsős hitelesítés

2017. november 02., csütörtök 15:04

Az olyan, tömegigényt kiszolgáló szolgáltatók, mint a Google vagy a Facebook valamivel több, mint 5 évvel ezelőtt vezették be azt, ami az ebanking környezetekben már gyakorlatilag standard volt: az azonosítón és a jelszón kívül a szolgáltatás a beléptetésnél a felhasználó azonosítása érdekében még valamilyen információt kérnek, aminek a leggyakoribb megvalósítási módja volt a múltban az egyszer használatos SMS-ben érkező token illetve persze a tokengenerátor. Ma persze már sokkal gyakoribb megoldás, hogy egy mobilapp generálja a tokeneket, aminek két-három különböző megvalósítása uralta le a piacot.

A Google Authenticator a TOTP-ra és a HOTP-ra alapuló kódgenerálást egyaránt támogatja. Aki esetleg allergiás lenne mindenre, ami Google, az használhat Duo Mobile-t ami ugyanez a kettő, legjobban elterjedt idő-alapú tokengeneráló algoritmust használja. Ami jelentősen eltérő, de szintén elterjedt app, az Authy, ezen kívül az olcsósága miatt érdemes lehet Yubikey-t használni az azonosítás második lépésében, amit egyre több és több rendszer támogat, emellett lehetőség van arra is, hogy valaki egyszerűen beszerezze a Yubikey API-ját és beépítse a saját rendszerébe. Továbbra is gyakori megoldás a második lépést telefonhívással vagy SMS-sel megoldani.

Főleg ott, ahol tömegigényt kell kielégíteni, nyilván a fejlesztőknek úgy kellett implementálniuk a kétlépcsős hitelesítést, hogy a fiók tulajdonosa számára az se jelentsen fennakadást, ha a tokenek generálásához használt mobil elveszik vagy éppen a mobil nem hívható, esetleg nem tud SMS-t fogadni bármilyen okból. Éppen ezért a 2FA beállításakor a minden ilyen rendszer felhívja a felhasználó figyelmét, hogy mentse le valahova azt a 10 kódot, ami abban az esetben is alkalmas az azonosítás második lépésekor, ha a mobil sehogy sem érhető el, amiben már önmagában van fantázia támadói oldalról.

Mielőtt úgy gondolnánk, hogy legalább a web legnagyobbjai komolyan is veszik a 2FA-t, érdemes tudni, hogy a Facebook esetén a support egyszerűen kikapcsolja a kétlépcsős hitelesítést pusztán azzal, hogy a támadó a fiókhelyreállításnál behazudja, hogy nem tud hozzáférni az áldozat fiókjához, mi több, ezt követően hitelesebben tudja kiadni magát, mint a fiók valódi tulajdonosa. A Google és persze a G Suite esetében azért sokkal jobb a helyzet, mivel egy algoritmus ellenőrzi a fiókhelyreállítási kísérletkor, hogy a felhasználó valóban nem tud-e belépni és persze, ha azt látja, hogy rendszeresen problémamentesen bejelentkezik, mint korábban bármikor, a támadó el sem jut a supportig. Viszont sem a Facebooknak, sem pedig a Googlenek nincs sem kapacitása, sem pedig lehetősége egy-egy bejelentés jogosságát kivizsgálni, ezért nem csoda, hogy inkább lazábbra fogják a figurát a biztonság terén, minthogy felhasználót veszítsenek. Céges környezetben a G Suite adminja lehet rázós célpont, ne felejtsük el, hogy a Facebook is elkezdett nyomulni a Workplace by Facebook-kal, ami később szintén okozhat izgalmas pillanatokat céges környezetben.

Több multifaktoros megoldás összehasonlítását a Wikipedián erre találjuk.

Van viszont egy sokkal, de sokkal húzósabb kockázat az egész kétlépcsős hitelesítéssel kapcsolatban, ami hát persze, hogy az emberi természetet, mint a permanens módon leggyengébb láncszemet célozza.

Azt szoktam mondani, hogy a totális tudatlanságtól már csak a hamis biztonságérzet a veszélyesebb, és tényleg. Amint az egyszeri felhasználó vagy akár egy privilegizált felhasználó beállította a kétlépcsős hitelesítést, onnantól kezdve nyugodtan alhat, hiszen még egy jelszólopás esetén is a támadó nem tud majd továbblépni a 2FA miatt, nemde? Elvben igen. Viszont nem eléggé tudatos felhasználónál éppen ez a hatás tovább feszíti a hamis biztonságérzet és az effektív biztonság közti szakadékot!

Aki használ 2FA-t gyakrabban vagy kevésbé gyakran találkozik olyan, mobiljára érkező SMS-sel, amiben egy-egy szolgáltatás küldi az SMS-t, csak annyit jelez, hogy a belépés sikeres, sikertelen, de ideális esetben be vannak állítva olyan triggerek, amik szokatlan tevékenységkor is SMS-ben figyelmeztetik a felhasználót abban az esetben is, ha egyébként a 2FA-t általában nem SMS-en keresztül használja, hanem valamelyik okosmobil-appal.

Na most képzeljük el, hogy biztonságtudatos, azaz még csak nem is totálisan paranoid felhasználónk kap egy SMS-t az alábbi sablon szövegek valamelyikével:

  • "Your account was logged into from a new browser or device. Review the login: https://oldal.tld/token_helye"
  • "Your account was recently logged into from Safari on Windows."
  • "Password reset code: [öt-hat számjegyű szám] Or reset your password here: http://oldal.tld/token_helye"
  • "Access data for your account has been ordered by you personally or by someone else. Your temporary password: [jelszó helye]"

Az első scenario: szóval landolt egy SMS, amiben kedvesen tudatja velünk a szolgáltatás, hogy mi a belépési tokenünk, amiről tudjuk, hogy csak a helyes felhasználói név és jelszó megadása után szokta kérni a rendszer, aztán esetleg ott egy adathalász oldalra mutató link, az SMS-t pedig egy az egyben a támadó küldte. Az adathalász oldalon már kedvesen elkérhető az áldozat felhasználói neve, jelszava, amit ugye lehet, hogy még kismillió helyen használ.. Mire pedig rájön, hogy adathalász támadás áldozata lett, már lehet, hogy késő. A támadás megspékelhető a második scenarioval kombinálva. 

A második forgatókönyv, alighanem sokkal régebben ismert volt, minthogy figyelmeztetést adott volna ki ezzel kapcsolatban több IT biztonsági cég is, a Symantec a Gmail példáján keresztül mutatja be a támadást az alábbi videóban: https://www.youtube.com/watch?v=_dj_90TnVbo

Tehát a támadó indít egy jelszóhelyreállítást, tokent kér az áldozat mobiljára, majd küld a mobilra egy SMS-t azzal a szöveggel, hogy valaki illetéktelenül belépett a fiójába, a kapott tokent küldje vissza SMS-ben válaszként, ha nem ő volt, a felhasználóban pedig megáll az ütő, nem gondolkozik, nem nézi a mobilszámot, küldi is vissza a támadónak a jelszóhelyreállító tokent, amivel a támadó új jelszót állít be.

Megjegyzem, éppen ez a támadás ma már a Google és G Suite accountoknál nem használható ebben a formában, mivel a fiókhelyreállítás megkezdése előtt a Google korábbi viselkedési adatokat elemez,  további adatokat kér, mint például azt, hogy mikor jelentkeztünk be sikeresen utoljára, honnan, milyen platformról, melyik szolgáltatásba, és így tovább, viszont a Facebook továbbra is sérülékeny! És persze ki tudja, hogy hány és hány vállalati rendszer úgyszintén.

Lehetne elemezni a támadást step-by-step bőven, ami itt a kulcselem, az ijedtség és az azonnaliság kényszere, amik persze hasonlóan kiirthatatlan sajátosságok, mint a tudatlanság. A módszer alighanem annyira hatékony, hogy alighanem még akkor is működik, ha a felhasználó arra a mobiljára kapja ezt a riasztást, amelyiken ilyet fogadni sosem szokott.

Korábban egy ISACA Második Szerdai előadáson volt róla szó, hogy a breachek több, mint fele azonosítók ellopásával van összefüggésben, aminek sejthetően a legnagyobb része nettó jelszólopások. Mint látható, a többlépcsős hitelesítés sem silver bullet, bájos, hogy az illetéktelen hozzáférést látszólag nagyon komolyan megnehezítő megoldás újabb lehetséges, hatékony támadási formák lehetőségét teremtették meg.

Az viszonylag világosan látható, hogy mi nem jelent megoldást. Például a fiókhoz tartozó mobilszám titokban tartása, hiszen a mai világban egész egyszerűen nem lehet mobilszámot titokban tartani, de még ha lehetne, akkor sem lenne túl életszerű, hogy a felhasználó arra rendszeresítsen egy mobilt, aminek a számát titokban tartja, hogy azt csak belépésekhez használja.

Ha többlépcsős azonosításról van szó, eljátszhatunk azzal a gondolattal, hogy egy nagyobb szervezetnél a főadmin gondol egyet, aztán teljesen saját tokengeneráló alkalmazást fejleszt, majd vezet be. Ott meg aztán nagyon-nagyon sok ponton homokszem kerülhet a gépezetbe például akkor, ha azok a véletlen számok mégsem annyira véletlenszerűek, ami az egyik leggyakoribb hiba ilyen alkalmazások implementációjakor. Viszont a támadó miért is bíbelődne ilyennel, amikor ott a fent vázolt, sokkal egyszerűbb módszer? 

Megjelent: 171 alkalommal
Értékelés:
(0 szavazat)
A hozzászóláshoz be kell jelentkezned

Adminisztráció

Regisztrációt kizárólag ISACA tagoktól fogadunk el, így a regisztrációs folyamat során felkérjük Önt, hogy ISACA tagsági számát küldje meg számunkra!
Köszönjük!