Az orosz fórumon néhány napja felfedezett, úgynevezett kombó lista feldolgozása és vizsgálata még mindig folyamatban van, de annyi már biztosan állítható, a (csaknem) teljes lista 404 millió felhasználói rekordot, és ebben legkevesebb másfélmillió magyar (.hu domain végződésű) felhasználói rekordot tartalmaz. 

Ennél a tényleges magyar érintettek száma jóval magasabb lehet, hiszen a magyar személyek által használt gmail.com, outlook.com és más, nem .hu végződésű emailcím és jelszó (vagy hash) párost azonosítani meglehetősen nehézkes, de alighanem a másfélmilliós szám is éppen elég sokkoló (még akkor is, ha ez egy historikus lista, azaz jópár évre visszamenőleg tartalmaz adatokat). 

Ugyan voltak olyan fájlok, amiket nem lehetett letölteni, vagy kibontani, de az eddig feldolgozott listák alapján így néz ki a statisztika:

Elég mellbevágók ezek a számok, de ha azt nézzük, hogy kb. 8-10 milliárd kompromittált hozzáférés kering publikus vagy zárt közösségekben, akkor ez igazából még 10% sincs :)

A SpyCloud ATO rendszere, 2018.05.10.

A régebbi DropBox a Zoosk és a Badoo randioldalak listája hiányos, azaz csak a felhasználó neveket és jelszavakat vagy jelszó hash-eket tartalmazza, a listában nem szerepelnek a további adatok (preferenciák, ki mit szeret, lakcím, elérhetőségek, stb.). Ezek az adatok is természetesen elérhetők, csak nem ezekben a listákban. 

Úgy gondolom, hogy az Account Takeover (ATO) terület, azaz a kompromittált hozzáférések felderítése, monitorozása és az érintettek riasztása nagyon komoly szerepet fog kapni a közeljövőben. Nem csak a GDPR miatt, hanem azért, mert egyre több alkalmazás van, de a felhasználói szokások szinte semmit sem változtak, ennek bizonyítására elegendő csak a jelszavakat megnézni :)

Magyar oldalak története

Mind a hét azonosítható magyar oldalt értesítettem, a fogadtatás - ha nem is örömteli, de kedvező volt, meg is kezdték az esemény kezelését.

A kszemle.hu elmondta, hogy egyrészt kiértesítették a felhasználókat a történtekről, és felkérték őket a jelszócserére. Emellett a fejlesztők atnézték a rendszert, és azonosították, hogy 2016 karácsonyán került sor az incidensre, egy SQL hibán keresztül húzták le az adatbázist. Az oldal szerint a fejlesztők be is zárták ezt a rést, valamint ígéretet tettek, hogy erősebb titkosítással fog a későbbiekben tárolódni a jelszó.

A matarka.hu is korrekten visszajelzett, kiértesítették a felhasználókat az esetről, és kérték, hogy cseréljék le a jelszavakat – na nem a matarka.hu oldalon, hanem mindenhol, ahol esetleg azt a jelszót használták. A matarka.hu elmondta, hogy amikor tudomást szereztek az esetről, a bejelentkezési szolgáltatást és a mögöttes funkciót kikapcsolták, az adatbázis vonatkozó részét pedig törölték (így a mögöttes SQL injection hiba ugyan nem került kijavításra, viszont legalább nincs haszna). Az oldal kiválóan működik login nélkül is, a bejelentkezés csak minimális funkciókhoz volt szükséges, ezt pedig egyszerűbb volt kikapcsolni, mint az alkalmazást kijavítani.

A cfoto.hu oldallal kapcsolatban nincs információm, megköszönték az értesítést, az intézkedésekkel kapcsolatban nem tudom, hogy léptek-e valamerre.

Az mbarat.hu oldal kivétel, itt nem sikerült senkit elérnem, a megadott telszám nem működik, az email is visszapattant (a domain tulajdonos cég felszámolás alatt). Egy ismerősön keresztül próbáltam elérni az oldal gazdáját, de érdemi eredmény nélkül. UPDATE: sikerült elérni az oldal tulajdonosát, nem tudott az esetről, visszahívást igért.

A lucaforum.demoscene.hu az Ayra Recordings kiadóhoz tartozó lap, egy 15 éve működő, de jellemzően már nem használt fórumoldal, amelyet emlékből őriztek meg és tartottak működésben. A felhasználókat próbálják kiértesíteni és megkérni őket a jelszócserére (főleg más oldalakon, ahol esetleg ugyanazt a jelszót használták).

Az aktrecords.hu oldal is megkezdte a felhasználók kiértesítését, egyenlőre nem tudni, hogy mikor történt a breach esemény.

Mi a tanulság?

Ahogy Fülig Jimmy fogalmazta meg: Mindnyájunkat érhet baleset.

Nagyon fontos, hogy egy bekövetkezett adatszivárgás (breach) eseményt nem szabad eltitkolni. Úgy is ki fog derülni, és akkor már sokkal rosszabb pozícióból kell kárt menteni.

Arról nem is beszélve, hogy a május 25. utáni GDPR-érában 72 órán belül le kell jelenteni az eseményt az adatvédelmi hatóság (NAIH) felé, ha azt súlyosnak véli a Szervezet. A lejelentés elmaradása igen komoly (sokmilliós) adatvédelmi bírságot vonhat maga után, főleg a GDPR szerint.

Fontos tanulság, hogy az érintett magyar oldalaknak nem volt tudomása a bekövetkezett eseményről, ami azt jelenti, hogy a 2016-2017-2018 időszakban bekövetkezett eseményt nem észlelték, mert nem figyelték az oldalak naplóeseményeit.

A kszemle.hu utólag ki tudta deríteni (tehát naplóztak, csak nem figyelték és nem volt riasztás), mikor és mi történt – ez alapján pedig be is tudta foltozni a rést. Sajnos azonban a monitorozás, naplók feldolgozása korábban elmaradt – így hiába naplózta a rendszer a támadást, arról az üzemeltetők nem értesültek – így 2016 óta az incidens felderítetlen maradt.

Nyilván fontos tanulság, hogy nem ártana sérülékenységvizsgálatot végezni a rendszereken, az oldalak esetében ez elmaradt (Ludmilla fóruma esetében ez még megérthető is), és egy SQL injection támadáson keresztül el tudták vinni a felhasználói adatbázist.

Szintén jól látható a magyar oldalak esetében, hogy nemigazán fordítottak gondot a jelszavak megfelelő tárolására. A pucér (sótlan) MD5 vagy a MySQL hash korántsem elegendő, ezekből viszonylag hatékonyan lehet visszaállítani a jelszavakat. A cleartext (titkosítatlan) tárolásra pedig szerintem nincsen bocsánat.

Nagyon fontos, ha bekövetkezik a baj, nem csak az adatvédelmi hatóság (NAIH) elől nem szabad eltitkolni az eseményt, de ki is kell értesíteni a felhasználókat.

Sajnos a felhasználók hajlamosak az egyes hozzáférések alatt ugyanazt a jelszót használni, tehát hiába kapcsoljuk le a saját kompromittált szolgáltatásunkat, a nálunk megszerzett jelszóval a felhasználók által használt pl. Gmail, Linkedin, DropBox, stb. online rendszerekbe is be lehet jelentkezni (kivéve, ha persze valaki kétfaktoros hitelesítést használ, ami az ilyen esetek miatt erősen javasolt).

Ha felhasználói oldalról nézzük az eseményt, már unalomig ismételt, hogy ne használjuk ugyanazokat a jelszavakat a különböző rendszerekben, használjuk többfaktoros hitelesítést, változtassunk jelszót, stb.