2022 szeptemberében egy támadó, aki megvásárolta az Uber egyik külsős munkatársának jelszavát, újra és újra megpróbált bejelentkezni. Minden kísérlet kétfaktoros jóváhagyási kérést küldött a munkatárs telefonjára. Az első néhány kérés még megállította a támadót. Aztán a munkatárs az egyiket jóváhagyta, és a támadó bejutott (az Uber biztonsági közleménye). Egy hónappal korábban a Cisco ugyanezt a mintát írta le a saját incidenséről: telefonhívások valakitől, aki a technikai támogatás munkatársának adta ki magát, és push-kérések áradata, amíg egy munkatárs az egyiket jóvá nem hagyta (Cisco Talos).
Mindkét cégnél be volt kapcsolva a többfaktoros hitelesítés. A támadók nem törték fel a második faktort, hanem megkerülték, olyan módszerekkel, amelyek azért működnek, mert a használt MFA egy fáradt embertől várja el, hogy a lehető legrosszabb pillanatban hozzon biztonsági döntést.
Ha az Ön MFA-ja egy SMS-kód vagy egy egyérintéses „Jóváhagyja?” push, érdemes rá tíz percet szánnia. Ma már ez az a két módszer, amellyel a támadók eleve számolnak, nem pedig az, amely megállítaná őket.
Három támadás, amely kifog a „valamilyen MFA-n”
- Push-bombing (MFA-kifáradás, MFA-bombázás, 2FA bombing). A támadónak már megvan a jelszó: egy kiszivárgott adatbázisból, adathalászatból vagy jelszó-újrahasznosításból. Egyik bejelentkezést indítja a másik után, jóváhagyási kérések áradatát zúdítva a felhasználó telefonjára, amíg valaki zavarában (vagy csak hogy vége legyen) rá nem koppint a Jóváhagyás gombra. Egyetlen koppintás, és bent vannak.
- SIM-csere. Az SMS-t sosem biztonsági csatornának tervezték. Az a támadó, aki ráveszi (vagy megvesztegeti) a mobilszolgáltatót, hogy egy telefonszámot új SIM-re helyezzen át, megkap minden oda küldött egyszer használatos kódot. Nincs kártevő, nincs adathalász oldal: csak egy telefonhívás az ügyfélszolgálatnak.
- Adversary-in-the-middle (AiTM). Egy meggyőző hamis bejelentkezési oldal valós időben közvetíti a valódit. Az áldozat megadja a jelszavát, a valódi rendszer elkéri a második faktort, és az áldozat meg is adja, hiszen ő tényleg be akar jelentkezni. A támadó proxyja begyűjti a létrejövő munkamenetet. Az MFA „működött”. A fiók mégis odaveszett.
Az amerikai kiberbiztonsági ügynökség, a CISA mindhármat megnevezi az útmutatójában, és éles határt húz: csak a FIDO/WebAuthn és a nyilvános kulcsú (PKI) hitelesítés számít adathalászat-ellenállónak, mert ott a kulcs a valódi webhely címéhez kötődik, és egy hasonmás oldal nem tudja használni. A push-alapú jóváhagyás még számegyeztetéssel (number matching) sem szerepel ezen a listán (CISA tájékoztató).
Mi állítja meg az egyes támadásokat
Ezeknek a támadásoknak különbözőek a gyenge pontjai, ezért érdemes pontosan megnevezni, melyiket mi győzi le.
- SIM-csere és kódlehallgatás: szüntesse meg a kódot. Ha a felhasználó kulcsa a telefon biztonságos hardverében jön létre, és soha nem hagyja el azt, akkor nincs megosztott titok egy adatbázisban, és SMS-ben sem érkezik semmi. Nincs mit lehallgatni, és egy telefonszám áthelyezésével semmi olyan nem kerül át, amit a támadó felhasználhatna.
- Push-bombing: a felhasználó olvashassa el, mit hagy jóvá. Sem kulcs, sem biometria nem segít, ha egy kérés már eljutott a telefonra, mert a támadás egyszerűen arra kéri a felhasználót, hogy mondjon igent. A biometria csupán azt igazolja, hogy a telefon tulajdonosa az, aki koppint, nem azt, hogy a bejelentkezés jogos. Az működik, ha a kérés konkrét, olvasható leírást hordoz arról, mit hagynak jóvá pontosan: melyik szolgáltatást, melyik műveletet, honnan. Egy olyan kérés, amelyet a felhasználó soha nem kezdeményezett, láthatóan nem az övé, ezért elutasítja. A kérések lejárata és annak korlátozása, milyen gyakran lehet kéréseket indítani, elveszi azt a mennyiséget, amelyre a támadás épít.
- Adversary-in-the-middle: a jóváhagyás önmagában nem állítja meg. Itt a felhasználót nem arra veszik rá, hogy valaki más bejelentkezését hagyja jóvá. A sajátját hagyja jóvá, csak rossz webhelyen. Az segít, ha látszik, honnan érkezett a kérés: ha a jóváhagyás megnevezi a címet, ahonnan a bejelentkezés jött, egy másik országban lévő proxy szemet szúr annak a felhasználónak, aki odanéz. Ez megdrágítja a támadást, de nem teszi lehetetlenné. Ahol a fenyegetési modell a szigorú értelemben vett adathalászat-ellenállást kívánja meg, ott a webhelyhez kötött FIDO-kulcsok a válasz, rövid munkamenet-élettartam és olyan bejelentkezési szabályok mellett, amelyek korlátozzák, hol használhatók a munkamenetek.
Ez a különbség az olyan MFA között, amelyet a támadó már kész szkripttel kerül meg, és az olyan között, amely ezeket a támadásokat láthatóvá vagy értelmetlenné teszi.
Hol illeszkedik ide a Notakey
A Notakey megszünteti a kódot, és minden jóváhagyást olvashatóvá tesz.
- A felhasználó kulcsa a telefon biztonságos hardverén belül jön létre, és soha nem hagyja el azt. Nincs SMS, amit le lehetne hallgatni, és nincs kód, amit tovább lehetne adni.
- Az értesítés csak egy csengetés. Amikor a felhasználó megnyitja az alkalmazást, az HTTPS-en keresztül tölti le a jóváhagyási kártyát attól a szervertől, amelyhez regisztrálták, így amit a felhasználó elolvas, az az Ön szerveréről származik, nem az értesítésből, és az aláírása pontosan arra a kérésre vonatkozik.
- A push-bombing ellen a védelem az, amit a felhasználó elolvas: a kártya megmutatja, melyik szolgáltatás kéri a jóváhagyást, és mit hagynak jóvá, így egy olyan kérés, amelyet senki sem kezdeményezett, ránézésre nyilvánvaló, és a felhasználó elutasítja. A kérések lejárnak, egy beépített korlátozó pedig szabályozza, milyen gyakran lehet őket indítani, így a támadáshoz szükséges kérésáradat hamar elakad.
- Az adversary-in-the-middle ellen a szerver beállítható úgy, hogy a kártyán megjelenjen a kérést indító IP-cím, a szolgáltatás neve vagy az URL, így a felhasználó látja, honnan érkezik valójában a bejelentkezés. Ennél többet nem állítunk: a proxy láthatóvá válik annak a felhasználónak, aki odanéz, de a támadás ettől nem válik lehetetlenné.
- Lefedi azokat az utakat, amelyeket a támadók valóban használnak. Lásd a gyakorlati útmutatókat: 2FA VPN-en RADIUS-szal, Windows távoli asztal és Linux SSH.
Győződjön meg róla saját maga
A különbséget úgy érezheti meg a leggyorsabban, ha egy ténylegesen elolvasható tranzakciót hagy jóvá: egy konkrét műveletet, a saját telefonjáról aláírva, ahelyett hogy egy szövegkörnyezet nélküli kérésre koppintana.
Próbálja ki az élő demót, és körülbelül két perc alatt aláír egyet, vagy kérjen bemutatót, és feltérképezzük, hogyan illeszthető pilot projektbe a saját infrastruktúráján a VPN-, SSO- vagy Windows-bejelentkezése.