Adathalászat OTP generátor által előállított jelszóval is védett oldalak esetén

Adathalászat OTP generátor által előállított jelszóval is védett oldalak esetén

Előző bejegyzésünkben a záró kérdésünk az volt, hogyan néz ki egy támadás, ha a támadott oldal használ OTP (One-Time Password) generátor által biztosított jelszót is?

Jelen bejegyzésünkben csak az eltérő folyamat modellt mutatjuk be, bár a két folyamat között csak kevés az eltérés.

Pár szó az OTP generátorokról:

  • Az OTP – One-Time Password –, az egyszer használatos jelszó rövídítése. Alapvetően szoftveres (pl.: Google Authenticator), és hardveres (pl.: RSA SecureID Authenticator) generátorok léteznek.
  • A szoftveres authentikátorok használata manapság leggyakrabban mobil telefonokon történik.
  • Az OTP megoldások közös jellemzője, hogy egy token csupán egy szerverrel (kvázi egy azonosítási szolgáltatással) működik együtt. (Szervezetek között nem hordozható megoldás, ha csak nem tartanak fenn közös OTP azonosító szolgáltatást.)
  • Két tipikus változata az idő alapú (TOTP), és a HMAC hasító algoritmuson alapuló (HOTP) implementáció.


A folyamat:

  1. A támadó, aki kontrollálja a közbeékelt adathalász webhelyet, vagy célzottan az áldozat felhasználót keresi meg egy, a korábbi bejegyzésben vázolt preparált email-el, vagy tömeges email küldéssel próbál gyanútlan áldozatokat odacsalni az adathalász weboldalhoz.
  2. Sikeres "beetetés" esetén a felhasználó próbál bejelentkezni a hamisított weboldalon, megadva a felhasználói nevét és jelszavát, amit az adathalász webhely egyből tud naplózni.
  3. Mivel az oldal alkalmaz OTP alapú 2. faktoros azonosítást is, szükséges, hogy az elkapott felhasználói név és jelszót felhasználva a támadó (illetve az őt helyettesítő automata program) bejelentkezzen az eredeti oldalra is.
  4. Sikeres bejelentkezés esetén a felhasználó a személyes OTP eszközével generál egy új egyszer használható jelszót, aminek az érvényessége a konkrét OTP megoldástól is függ, de jellemzően limitált ideig érvényes.
  5. A felhasználó még mindíg az adathalász oldalon van, így ott begépeli a generált jelszót.
  6. Ezen a ponton a támadó gyakorlatilag már meg is szerezte a hozzáférési azonosítókat a támadott rendszerhez, de a gyanú elterelése érdekében a bejelentkezési adatok birtokában jellemzően végrehajtja a támadott weboldalon is a bejelentkezést, és
    1. vagy egy szolgáltatás nem elérhető hibaüzenetet küld az áldozatnak,
    2. vagy irányíthatja őt az eredeti weboldal megfelelő szolgáltatásához, mintha minden rendben történt volna.
  7. Ezt követően már szabad az út a támadó számára, hogy a neki tetsző adatainkoz hozzáférjen, mivel kontrollja van egy eltérített élő munkamenet felett. Amíg ez a munkamenet él, addig bármilyen adatunkhoz hozzáfér, azokat módosíthatja, az eredeti felhasználót kizárhatja a rendszerből.    

Összehasonlítva az U2F megoldással, ahhoz képest az alábbi eltérések vannak:

  • bonyolultabb használni,
  • drágább az üzemeltetése,
  • kompatibilis mobil telefonokra, vagy dedikált eszközökre van szükség,
  • a generátor eszközök lemerülése esetén nem működik,
  • nem nyújt védelmet az adathalász támadások ellen.

Hogyan néz ki egy támadás, ha a támadott weboldal QR kódos azonosítást használ?

Nézd meg, a következő blogbejegyzésünket! :)


Kapcsolódó cikkek:

Adathalászat QR-kóddal védett oldalak esetén

Adathalászat SMS jelszóval is védett oldalak esetén
 
Adathalászat jelszóval védett oldalak esetén

Kell-e védekeznünk az adathalászat ellen?