bardóczi ákos @post.r

Nem tudom, hogy ki emlékszik még arra a 2012. őszén napvilágot látott sebezhetőségre, amikor valaki szimplán a felhasználó email-címének ismeretében felül tudta írni az áldozat jelszavát és az új jelszóval be tudott lépni. 

A régi sebezhetőség lényege az volt, hogy ha valaki az elfelejtett jelszóra klikkelt, majd kért egy jelszóhelyreállító tokent emailen, kapott egy 6 számjegyű számot, amit csak meg kellett adni a Facebook jelszóhelyreállító oldalán, majd ha helyes volt a számsor, máris az új jelszót lehetett megadni és azzal belépni. Az „apró” probléma csak az volt, hogy bárki kérhette bárki más nevében a jelszóhelyreállítást, a Facebook semmilyen módon nem korlátozta azt, hogy a helyes számsor ismerete nélkül mennyiszer lehet hibás számsort megadni, azaz valószínűségi alapon átlagosan félmillió, de maximálisan egymillió ismétléses permutáció végigpróbálgatásával [a 000000-999999 tartományban] véletlenül is meg lehetett találni az új jelszó beállításához szükséges számsort, miután valaki egy fiók jelszavának helyreállítását kérte. Márpedig egy fél-egymillió lehetőséget végigpróbálgatni automatizáltan nem olyan nagy manőver. A hibát, a bejelentést követően a Facebook nagyon gyorsan javította. 

Javította, a főoldalon. Viszont a Facebook felületének béta verziójában bennmaradt egészen mostanáig. Anand Prakash indiai kutató véletlenül vette észre, hogy a hiba a bétában és a mobil bétában továbbra is elérhető, a bejelentésért pedig a Facebook ki is csengette neki a bug bounty keretében a 15000 USD-t, ugyan nem lennék meglepve, ha kiderülne, hogy korábban más már a feketepiacon is árulta.  

A mai napon felkerült proof-of-concept videóban látható, ahogyan a Burp suite segítségével egyesével újraküldi a kéréseket a jelszóhelyreállító oldalnak, mire az egy idő után el nem fogadja a brute force, azaz nyers erővel megtalált számsort a béta felület és fel nem ajánlja új jelszó beállítását. Elég erős így majdnem négy év után újra látni ugyanazt a hibát. 

A jelszavakkal kapcsolatos közhelyeket annyival egészíteném ki, hogy ha meg akarjuk védeni azt, akkor nem feltétlenül a legbölcsebb dolog feltolni a netre… Nem, titkosítva sem. Igaz, hogy a mai jelszókezelő szolgáltatások olyan titkosítást használnak, amik elvben lehetetlenné teszik a jelszavak kinyerését a mesterjelszó ismerete nélkül, egy pillanatig se felejtsük el, hogy hány és hány, matematikailag cutting-edge titkosítást használó szoftverben találnak hibát rendszeresen! Azaz amikor valami konkrétan észrevétlenül maradt programozási hiba miatt törhető.

Én sosem használtam netes jelszóemlékeztető szolgáltatásokat, viszont ha betartom a jelszó erősségével kapcsolatos irányelveket és természetesen nem használom ugyanazt a jelszót még csak két azonos helyen sem, két lehetőség marad: az egyik, hogy kitalálok valami rendszert arra, hogy hogyan képezzem a jelszavaim, ami függ a szolgáltatás nevétől vagy típusától például, a másik pedig az, hogy a jelszavakat valahova felirkálom.

A következőben egy mindenki számára kivitelezhető módszert mutatok be arra, hogy hova érdemes a jelszavakat felirkálni, ha már a mai világban egyszerűen nincs más ésszerű megoldás, hiszen ha használsz olyan 20 jelszót, amit meg is változtatgatsz havonta és azok kellően bonyolultak is, kizárt, hogy mindet fejben tudd tartani.

Mit NE tegyünk? Ha már elvetettük a netes jelszókezelő alkalmazásokat, kézenfekvőnek tűnik létrehozni valamilyen Office dokumentumot, Excelt vagy Word-öt, amibe aztán szépen bemásoljuk az összes jelszót és azért, hogy egyetlen megnyitással vagy a fájl ellopásával mégse kerüljenek ezek a hozzáférési adatok olyanhoz, akihez nagyon nem kellene, az Office fájlt titkosítva mentjük. Mi ezzel a baj? Ismétcsak tisztában kell lenni vele, hogy a dokumentumok jelszóval való védelme rendeltetése szerint mire alkalmas és mire nem. Az Office dokumentumokat ugyan többféle titkosítással is menthetjük, alapvetően ezek gyenge titkosítások. Másrészt ha megnyitsz például a egyszerű DOC fájlt, akkor megjelenik tipikusan a vele azonos lévő mappában egy rejtett fájl, ami gyakorlatilag annak a fájlnak a nyers példánya, amin aktuálisan dolgozol és törlődik, ha a dokumentumot bezártad. Ha viszont valaki másnak is hozzáférése van a munkamappához például hálózati meghajtón keresztül vagy éppen csak lefagy a gép, igen, kitaláltad: a Word vagy Excel által átmenetileg létrehozott fájlt szépen ott marad, titkosítatlanul vagy épphogy titkosítva, aztán később viheti, aki látja.

Mennyivel elegánsabb, ha egy jelszót olyan helyen tárolunk, ahol ember nem gondolná, hogy ott tároljuk, másrészt mégis bizonyos esetekben kellő biztonságot ad: a szteganográfia.

A weben kismillió megoldás akár online is kínálja, hogy az általad beírt szöveget, mondjuk jelszavakat belevési egy MP3-ba, képfájlba, akármibe, ami aztán később letölthető, megnyitva pontosan olyan, mintha MP3 illetve képfájl lenne, viszont a megfelelő szerkesztővel megnyitva kinyerhető a bele rejtett szöveg. Ilyen webes szolgáltatásokat nem mernék ajánlani senkinek, hiszen nem lehetünk benne biztosak, hogy a szolgáltatás nem épphogy a jelszavak lenyúlására van kitalálva.

A legegyszerűbb megoldások egyikét viszont megmutatom, amit nevezhetnénk akár kézműves kriptónak is. Az alapján az jelenti, hogy a különböző fájltípusok, jól ismert és alaposan dokumentált szerkezettel rendelkeznek. Ha például érdekel, hogy egy egyszerű JPEG kép, ami semmilyen metaadatot nem tartalmaz, tényleg csak annyit, hogy tömörített vagy sem, milyen színmélységet használ, milyen a szélessége és hosszúsága, nos, itt körülbelül egy atomrakéta tervrajzának pontosságával van leírva, holott tudjuk, hogy a JPEG számtalan metaadatot tartalmazhat és tartalmaz is, mint például azt, hogy milyen fényképezőgéppel készült a fotó, a Photoshop melyik verziójával igazítottak rajta és így tovább.

Ami a mi szempontunkból lényeges egyszerűsítve, hogy a mostani JPEG egy olyan tömörített képfájl típus, ami többek közt ellenőrzőösszeget is tartalmaz, azt is, hogy a kép meddig tekinthető még egyáltalán az eredeti képnek. Bizonyos esetekben ha csak minimálisan sérül a fájl olyan módon, hogy néhány bájt megváltozik benne, a képet vagy meg lehet nyitni vagy nem, megint más esetben, vegyük azt az egyszerű példát, amikor a JPEG tömörítettsége 0, akár jelentős „zaj” is lehet a fájlon belül, amit egyszerűen nem fog értelmezni a képnézegető program vagy a sérüléseket figyelmen kívül hagyja, de természetesen utazik a fájllal együtt, ha például azt lemásoljuk. És itt a lényeg: hogy ez a bűvös zaj bizonyos terjedelmi korláton belül szinte bármi lehet.

Első lépésben tehát szükség van egy tetszőleges formátumú képfájlra. Ezt követően egy tetszőleges képszerkesztővel nyissuk meg és mentsük el JPEG-be olyan módon, hogy egyáltalán ne alkalmazzon a képszerkesztő tömörítést.

Ezt követően az új, teljesen tömörítetlen fájlt nyissuk meg egy olyan szövegszerkesztővel, ami plain text szerkesztésére alkalmas, azaz mondjuk notepaddel vagy ahogy tetszik, valami ilyen rémség fog látszódni.

Ezt követően egy ritkább helyre [nem magyarázom] helyezzünk egy tetszőleges szöveget, mondjuk egy részletet Shakira-tól.

A nyers szövegként szerkesztett fájlt mentsük az eredeti formátumban, majd ellenőrizzük, hogy megnyitható-e. Megnyitható!

Ezt követően, ha előkukáznánk azt a szövegrészt, amit a képbe rejtettünk, csak egy egyszerű szöveges böngésző kell.

Persze, erre lehet mondani, hogy a JPEG különböző metaadat mezőjébe is bőven el lehetne rejteni ezeket, a JPEG metaadatait a Windows és az OSX nagyon gyorsan indexeli és aszerint is kereshetünk ugye. Viszont abban az esetben, ha adott egy mappa mondjuk ezer metallica-s képpel, még egy erősebb géppel is piszok sok időbe telik, hogy valaki, aki ki akarja nyerni az így elrejtett szöveget, megtalálja azt, hiszen alapvetően fájlformátumtól függetlenül egy adott szövegrészre keresni fájlok belsejében egy komolyabb fájlkezelővel vagy scripttel még mindig veszettül lassú.

Természetesen ajánlható ezen kívül, hogy a mappát, aminek a képei közé rejtettük a belevarrt szövegrészt, titkosítsuk linuxnál Truecrypttel, Windows esetén EFS-sel, OSX esetén pedig Filevaulttal, a legnormálisabb megoldás pedig persze az, ha pendrive-on van, az, hogy ez mezei pendrive, EFS-re formázott vagy hardveres titkosítást alkalmazó, már csak attól függ, hogy az igen csak hasznos paranoiditás milyen szintjén vagyunk.

Mióta az azonosításhoz használnak jelszavakat, gyakorlatilag ugyanaz a probléma velük: a felhasználó leírja, elhagyja, lenyúlják, lelesik, kölcsönadja, a jelszó túl gyenge és folytathatnám a sort. A blogon már többször is téma volt az egyre több helyen bevezetett többlépcsős, konkrétabban kétlépcsős hitelesítést valamilyen formában, azaz amikor a felhasználói nevünk és a jelszavunk, - mint két statikus azonosító – mellett meg kell adni még egy, egyszer használatos azonosítót is, ami például egy SMS-ben érkező token vagy egy mobilalkalmazás által generált, adott ideig érvényes számsor. Tanulságos, hogy ezt a netbankos rendszereknél vezették be először, majd jóval később, sorra azok a szolgáltatók, akiknél nagy mennyiségű információ tárolódik, mára pedig támogatja gyakorlatilag minden komolyabb webszolgáltatás.

Ami még érdekesebb, hogy a Yandex január táján gondolt egy nagyot és a nagy és ingyenes szolgáltatók közt elsőként opcionálisan olyan authentikációt tett elérhetővé a belépéshez, amivel a jelszó teljes egészében nélkülözhető: csak a felhasználói nevet kell megadni, a jelszót pedig képletesen egy olyan állandóan kulcs helyettesíti, ami végülis mindig nálunk van.

A beállítási folyamat meglehetősen egyszerű, az okostelefonunkra le kell tölteni a Yandex Key alkalmazást, majd a lépésről lépésre történő webes beállításkor megjelenő QR-kódot beolvasni vele, de megadhatjuk a képernyőn megjelenő átmeneti karaktersorozatot is. Jó, jó, de ezt eddig tudta többek közt a Google Authenticator, a Microsoft Authenticator, a Duo Mobile és a többi is, nem? Itt jön a csavar: a Yandex Key beállításához kötelezően be kell állítani egy négy számjegyből álló alkalmazás PIN-t is.

Innentől kezdve, ha megpróbálunk belépni a Yandex-fiókba, a Yandexen csak a felhasználói nevet kell beírni, majd a jelszó helyett a QR-kód ikonjára kattintani, ekkor egy QR-kód jelenik meg a képernyőn. Ezt be kell olvastatni a Yandex Key appal és a beléptetés megtörténik. Viszont! Abban az esetben, ha a Yandex Key megnyitása után hibás PIN-t adunk meg, szintén bescannelhető ugyan a QR-kód, viszont azzal a beléptetés nem fog menni és – ami a lényeg – ha valaki mondjuk az ellopott mobilunkkal próbálni így belépni, nem fog  tudni, mivel az alkalmazás PIN-t nem ismeri. Ha eddig nem lenne eléggé csavaros a dolog, az alkalmazás nem figyelmeztet érvénytelen PIN esetén sem, így a támadónak nagyon megnehezíti a dolgát, mert még ha neki is állna végigpróbálgatni a 10000 ismétléses permutációt, ami a PIN lehet 0000-9999 tartományban, nem fogja tudni könnyen megállapítani, hogy mikor talált.  

Akkor ez most végülis kétlépcsős hitelesítés vagy sem? Végülis igen, de eddig nem látott kivitelben. Jelszó helyett mindössze a négy számjegyű alkalmazás PIN az egyetlen fix elem, amire emlékezni kell, meg persze a saját felhasználói nevünk.

Természetesen a többi 2-FA megoldáshoz hasonlóan itt is van lehetőség alkalmazásjelszavakat létrehozni vagy visszavonni például levelezőklienshez, viszont vegyük észre, hogy a Yandex ezzel a módszerrel kiiktatta a felhasználók azonosításában örök problémát jelentő tényezőt, a statikus jelszót!

Abban az esetben, ha a mobil nem alkalmas QR-kód olvasására, a QR-kód helyett a webes belépésnél kérhetjük azt is, hogy egy egyszer használatos karaktersorozatot kelljen megadni, ami szintén a Yandex Key-en olvasható le.

Amíg nagyon bétában futott, tapasztaltam olyat, hogy nem sikerült belépni a helyes PIN ellenére sem, a hibát azóta már javították, az ok valószínűleg az volt, hogy a mobilalkalmazás más időzónát használt, mint ami a Yandex-fiókban be volt állítva. Hogy ennek mi a jelentőssége, azzal senkit sem büntetnék, erre lehet olvasni róla. 

A posztnak azt a címet adtam, hogy „Email biztonság”, mert a Yandexet évek óta elsősorban levelezésre használom. Viszont érdemes tudni, hogy az orosz google-nek is csúfolt webes óriás a levelezésen túl fájlhoszting szolgáltatóként is működik, van benne térképalkalmazás, webes fordító, naptár, gyakorlatilag minden, ami a Google-account vagy éppen Microsoft-accountok használatakor is elérhető.

Az ok, ami miatt a Yandex alig ismert Európa nyugati régióiban, egyszerű, konkrétan az, hogy nagyon sokáig nem volt elérhető angol nyelven, néhány éve viszont szinte minden szolgáltatását elérhetővé tették angol nyelven is. Ha először használod és oroszul jelenik meg, de nem tudsz oroszul, egyetlen kattintással állítható át a teljes felület angolra.