Ma dömping van, a 47. „Adatvédelmi hozzájárulás kérése (GDPR)” levél esett be a postafiókomba.

Érdeklődve olvasom őket, kattintgatok és megerősítem, hogy továbbra is kezelhetik az adataimat – de bizony egy részükről nem is tudtam, hogy regisztráltam volna valamilyen hírlevelükre (ezekre természetesen nem kattintok).

(Ugyanitt megjegyzem, hogy mekkora malware terjesztést lehetne csinálni – csak a malware-t „Adatvédelmi hozzájárulás kérése (GDPR).docx” dokumentumba kell tenni, mindenki nyitná, mint az állat).

Szóval mi van azokkal, akikről biztosan tudom, hogy nem adtam meg nekik az adataimat?

Na kérem, ezt úgy hívják, hogy „kimosdatás” – azaz a korábban aggályos (értsd: hozzájárulás nélkül gyűjtött, vásárolt, fene-se-tudja-honnan-van, stb.) módon beszerzett címeket lehet vele kifehéríteni.

A trükk az, hogy úgy kell megírni a megerősítés kérését, mintha korábban az illető megadta volna az engedélyt, és csak a b*zi GDPR miatt újra be kell kérni.

Szorri, nem akarunk mi zavarni, csak tudod, a GDPR...Lécci, hát erősítsed már meg, amit már annó megtettél, tudod, hogy feliratkoztál...Emlékszel, ugyi? Na, lééééccci! HüjeGDPR!

És persze sokan vannak, akik meg is erősítik, hiszen itt a GDPR, mi is szop*nk vele, a szerencsétlen is, hát miért ne segítsünk. A másik, hogy tényleg a fene se emléxik, lehet megadtam, jelentkeztem, biztos fontos volt, ez meg megbízható amúgy is, látszik törődik az adataimmal meg a GDPR-al.

A kimosdatásnak a legszebb példája az, aki csak email címet harvestelt korábban, és amúgy lövése sincs arról, hogy hívják az illetőt.

Ilyenkor a profi kvázi újra regisztráltatja az illetőt, és nem csak megerősítését kér arról, hogy tárolhatja és kezelheti az adatot, hanem bekéri „újra” a nevét, címét, stb. – hiszen a GDPR elvárja, hogy a tárolt adatok pontosak és naprakészek legyenek. YEAHH!

Az ilyen – tulajdonképp regisztráció mögé bújtatott – hozzájárulás akkor tud a leghatékonyabb lenni, ha az email címet már nem kéri el, hanem meg jeleníti a „Megerősítés” lapon („már úgy is tudjuk, hiszen korábban már te magad adtad meg, most csak a hüje GDPR miatt kell ezeket az adatokat ÚJRA megerősítened”).

Szóval ötletes megoldás a GDPR hisztériát arra felhasználni, hogy kifehérítsük a szürke vagy fekete listáinkat, és olyanoktól is beszerezzük a hozzájárulást (és meg csomó, korábban nem tárolt adatot), aki egyébként korábban sem adtak hozzájárulást és engedélyt. Nice job. 

Ha IT oldalról nézzük, a GDPR-ban két technológia kerül nevesítésre, minden más technológiára csak burkolt célzást tartalmaz a 32. cikk.

Az álnevesítés és a titkosítás rossz nyelvek szerint azért került konkrétan megnevezésre, mert a 6 évig a GDPR szövegén dolgozó jogászok együttesen és mindösszesen ennek a két technológiának a nevével voltak tisztában.

Nézzük tehát a titkosítást

Az ESET vírusvédelmi gyártó szerint a titkosítás:

A titkosítás az információ oly módon történő kódolása, hogy azt illetéktelen személyek ne legyenek képesek elolvasni. (https://encryption.eset.com/hu/mi-az-a-titkositas/ )

A több oldalról is borzasztóan pongyola megfogalmazás (és szeretném a kriptós kollégákat megkérni, hogy ne köpjenek le mert idézem), de alighanem ezt értették meg a GDPR rendelet megalkotói, ezért szerintem fogadjuk el ezt a definíciót – de kicsit megfordítva.

A titkosítás az információ oly módon történő kódolása, hogy azt csak az arra jogosult személyek legyenek képesek elolvasni.

A titkosítás ugyanis a GDPR 32. cikk b. pontjában szereplő „bizalmas jelleg” – azaz a bizalmasság teljesülésének feltételét biztosítja. Az információt csak az olvashatja el, aki arra jogosult (mert rendelkezik olyan eszközzel/eljárással/jelszóval/kulccsal, amely ezt lehetővé teszi a számára).

Mikor kell a GDPR szerint titkosítást alkalmazni?

A GDPR egyáltalán nem rendelkezik erről konkrétan.

A 32. cikk 1-es pontja beszél arról, hogy az adatkezelés kockázatait figyelembe véve kell a megfelelő biztonsági szintet meghatározni.

Tehát, ha úgy gondolod (ne gondold, mérd fel, és írd le!), hogy az adott adatkezelési folyamatot nem fenyegeti olyan mértékű kockázat, hogy indokolt lenne részedről (a költség és egyéb vonzatokra tekintve) titkosítást alkalmazni – akkor ne alkalmazz titkosítást.

Nézzünk erre példát (DPIA/BIA-s kollégák szintén ne köpjenek le, próbálom közérthetően megfogalmazni).

A CRM/ERP rendszerben kell-e titkosítanod?

Működés:

A CRM/ERP rendszer nálatok működik, a sarokban búgó szerveren. Gyula, a rendszergazda hetente egyszer néz rá (távolról), mert egyébként van neki főállása is valahol, de mivel a főnök unokatestvérének volt kollégiumi szobatársa, ezért ő a külsős rendszergazda.

Nem tudjuk, Gyula hogy néz rá a szerverre, de a cucc működik vagy 12 éve, és még soha nem volt vele semmi gond (Gyula jó rendszergazda!).

A kollégáiddal a böngészőből éritek el, tök kényelmes az egész, beírod a címet, kér egy nevet meg egy jelszót (már nem emlékszel mi a jelszavad, 12 éve állította be Gyula, de a böngésződ emlékszik rá szerencsére). Mostanában kicsit macerásabb, mert a Chrome meg a Firefox valami olyat kiabál, hogy nem titkosított a kapcsolat, ezért inkább a régi Internet Explorert használod, Gyula abba is beállította neked a jelszót és az IE jól működik, problémamentes a belépés.

Mind a 10 sales kolléga eléri a szervert és az összes adatot látja benne.

Milyen személyes adatokat tárol:

Hááááát 12 évre visszamenőleg minden ügyfél, kapcsolat, célpont nevét, címét, telefonszámát, lábméretét, szülinapját, anyja nevét, ha ügyfél akkor a szerződést, a személyigazolványa másolatát, a születési anyakönyvi kivonatát, stb. A jó sales MINDENT tud az ügyfeleiről, és még többet tud a LEENDŐ ügyfeleiről.

Jelenlegi biztonsági intézkedések:

Már most is túlzók. A szervert csak a cégen belülről lehet elérni. Amúgy a céges TPLINK-típusú tűzfal minden kibertámadást kivéd, hiszen soha nem volt semmilyen gond vele, úgyhogy ez szerinted túlzás, jó lenne otthonról is elérni, mert van, amikor otthonról kell dolgoznod, de megoldod végülis, mert az esti melóhoz szükséges adatokat hazaküldöd a Gmailedre és abból dolgozol.  

Gyula azt mondja, hogy a szerver meg van védve a kibertámadásoktól, a mentésről meg ő gondoskodik, mert otthonra le tudja menteni (mert ő bezzeg eléri!!) az adatbázist, és le is szokta havonta menteni, de tök felesleges, még soha nem kellett visszaállítani, mert minden működik. Jó, néha, amikor a böngésző elfelejti a jelszót, akkor Gyula szokott segíti, megnézi a legutóbbi mentést az otthoni gépén, és abból meg tudja mondani a jelszót a feledékeny kollégának (miért nem írja fel az ilyen!!).

Van szünetmentes USP eszköz a szerveren, amitől a szerver szünet nélkül működik.

Kockázatok:

Szerinted semmi, a rendszer működik, atomstabil (és egyébként tényleg!).

Volt valami IT felmérés (a főnök akarta, hogy legyen, Gyula egyik haverja a Béla jött el felmérni, de pont előtte balhézott össze a Gyulával, úgyhogy egy csomó sületlenséget írt le, kár volt kidobni rá a pénzt. 

1. A szerver elérése titkosítatlan HTTP protokolon keresztül történik. A Chrome és a Firefox ugyan szól érte és figyelmezet, de Gyula mitigálta a problémát azzal, hogy minden felhasználó használjon Explorert, hát az van benne a Windózba, az jobb.
   
   
2. Jelszócsere 12 éve nem volt, mindenki a böngészőben elmentve tárolja a belépési adatokat. Állítólag azt a vírus el tudja lopni, de hülyeség, a TPLINK-típusú tűzfal megállítja a kibertámadásokat.
   
   
3. A belépéshez szükséges jelszó az adatbázisban nem titkosítottan tárolódik, hiszen Gyula a szofisztikált mentésből ki tudja olvasni a jelszót.
   
   
4. A szofisztikált mentés konkrétan azt jelenti, hogy az adatbázis és abban tartott személyes adatok Gyula otthoni gépére tárolódnak (tök rendes tőle, és nem számít fel tárolási díjat se!!).
   
   
5. Gyula valamilyen módon eléri a szervert távolról, Béla leírta, hogy Gyula egy „Port Forward” nevű programot használ erre a célra amit a tűzfalra telepített (??! – nem is vettünk ilyet, tök rendes Gyulától, hogy a sajátját használja, főleg úgy, hogy egyébként nincs is szerződés vele aláírva), meg állítólag nem csak Gyula éri el, de más is, de biztos hazudik.
   
   
6. A felhasználók a személyes adatokat máshol is kezelik, nem csak a rendeltetési helyen, hiszen pl. Te is hazaküldöd a Gmailedre, és az otthoni gépeden dolgozol az adatokkal. Legalább egy csomóról van mentés nálad is, ha valami baj lenne Bála gépével.

És így tovább.. (esküszöm, nem nagyon túlzok, a példa életből vett)

Szóval, hol kell akkor titkosítani?

Hát jelen esetben majdnem tökmindegy, de egyébként:

• A bejelentkezéshez szükséges jelszót (megfelelően) titkosítva kell az adatbázisban tárolni, ez alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza.
  
  
• Mivel a rendszer nagymennyiségű személyes (és egyébként más, üzleti-bizalmas, titkos, fontos, szenzitív) adatot tárol, az adatok elérésének titkosított kapcsolaton keresztül kellene történnie. Alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza (bizalmasság, sértetlenség).
  
  
• Ha hazaküldöd az adatokat magadnak akkor az adat rendeltetési helyétől eltérő helyen valósul meg az adatkezelés. Ez csak abban az esetben történhet, ha a másik helyen működő rendszerben „megfelelő technikai és szervezési intézkedéseket hajt(ottak) végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja” – ez pedig az otthoni gépedre nem igaz (jelen esetben mondjuk a céges és az otthoni között nemigazan van biztonsági szint különbség, de elvekről van szó és nem gyakorlatról :)). És még ebben az esetben is problémás, hiszen nem dokumentált adatkezelés, feldolgozás történik. Ráadásul a Gugli postafiókodban a cég által kezelt személyes adatok lesznek megtalálhatók.
  
  
• Gyula mentési eljárása látszólag megfelel a rendelkezésre állás elvárásának, azonban a személyes adatok rendeltetési helyüktől eltérő helyen kerülnek tárolásra, megfelelő védelmi intézkedések és szabályzások nélkül. A tárolt adatok megismerhetővé válhatnak, hiszen Gyula gépéhez mások is hozzáférhetnek (nagyi, tesó, iráni hekker). Gyula, mint SaaS Backup Service gondoskodjon a megfelelő, titkosított tárolásról :) És persze legyen megfelelő szerződés.
  
  
• A „Port Forward program” használata elérhetővé teszi nem titkosított csatornán (HTTP) keresztül az szerver elérését, ez a bizalmasság, sértetlenség és rendelkezésre állás hármas egységét is sérti. Kicsit jobb lenne a helyzet, ha Gyula átállítaná a rendszert a HTTPS kapcsolatra, mert akkor legalább az alapvető (titkosított kapcsolat) elvárások szűk szeletkéjét ki lehetne pipálni. Egyébként a rendszerhez kívülről mások is hozzáférnek (iráni, pakisztáni, líbiai hekker)

A vicces példából egy nagyon fontos dolog derül ki. Maguknak a személyes adatoknak nem kell titkosítva tárolódniuk az adatbázisban.

Számos ponton jöhet be a titkosítás a képbe, de az adatokat magukat nem szükséges titkosítani, amennyiben a megfelelő védelmi intézkedések (pl a kapcsolat titkosítása, a hozzáféréshez szükséges jelszó titkosítása, stb.) garantálják, hogy a rendszerben csak az arra jogosult személyek férhessenek hozzá az adatokhoz.

Kitárolt adatok

Egy csomó esetben az adatbázisban tárolt adatok megjelennek másol is, munkaállomásokon, fájlszervereken, adathordozókon, levelezésben.

Ilyen esetekben viszont el kell gondolkodni az adatok titkosításán, hiszen az adatok a védett (?) rendszerből kikerülve hozzáférhetőve válhatnak jogosulatlan személyek számára is.

Néhány tipp:

• Fájlszerveren nem szükséges a személyes adatokat titkosítani, ha a jogosultság-kezelés és a hozzáférés védelem biztosítja, hogy csak a jogosult személyek férhessenek hozzá az adatokhoz. (rendszergazdák kíméljenek)
  
  
• Laptop esetében az adatokat nem feltétlen kell titkosítani, ha maga a laptop titkosítva van (full disk encryption). Egyszerűbb a teljes laptopot titkosítani, mint egyes fájlokat.
  
  
• Ha emailben küldünk személyes adatokat (és itt arra gondolok, hogy nagymennyiségű személyes adatot), akkor szükséges a titkosítás bevezetése. Nyilván 1-1 adatcsoport esetében nem kell titkosítani, de szerintem, ha fájlokat küldünk amelyben bizalmas adatok vannak, akkor nem árt a titkosítás. Erre akár egy jelszóvédett ZIP is megfelelő, csak a jelszót ne emailbe küldjük, hanem egy másik csatornán, pl. SMS-ben.
  
  
• USB adathordozón szintén szükséges a titkosítást használni, részegen elhagyni egy pendrájvot igen könnyű. De ez sem a GDPR-al jön be a képbe, általános biztonsági intézkedés az adatok bizalmasságának biztosítására. Itt is lehet csak a személyes adatokat tartalmazó fájlt titkosítani (jelszóvédett ZIP), vagy az egész adathordozót.

A GDPR Hasznos Holmik mai részében a sütiket (cookie) nézzük meg egy kicsit közelebbről.

Nem csak azért, mert mindenkit rohadtul idegesítenek a felbukkanó cookie-szabályok (amiket amúgy nem olvasnak el, általános tény, hogy egy weblap legkevesebb látogatót gyűjtő két oldala a cookie szabályokról, illetve az adatvédelemről rendelkező két oldal), hanem azért, mert ez egy olyan pont, amelyet egy jogi egyetem melletti romkocsmából toborzott, egyszeri NAIH auditor-gyakornok kényelmesen, az irodában üldögélve is viszonylag egyszerűen ellenőrizni tud.

Szóval mi az a süti és miért kell nekünk foglalkozni vele?

Egy random cookie-szabályzatból idézve: „A cookie (továbbiakban süti) egy rövid szöveges adat, amely segít a felhasználó beállításainak mentésében. Ezt a weboldal küldi el az Ön böngészőjének, majd mikor az adott oldalt újra meglátogatja, a böngésző visszaküldi azt, és a weboldalon elérhetővé válnak a korábbi adatok, beállítások.”

Szóval a lényeg, hogy a sütiket a weboldalak generálják és tárolják le a látogató munkaállomására.

Ez a tény azért fontos, mert a 2003. évi C. törvény az elektronikus hírközlésről is már rendelkezett arról, hogy a felhasználó eszközén csak a felhasználó teljeskörű tájékoztatása után, a felhasználó beleegyezésével lehet csak adatot letárolni.

(155/4) Egy előfizetőnek vagy felhasználónak elektronikus hírközlő végberendezésén csak az érintett felhasználó vagy előfizető világos és teljes körű - az adatkezelés céljára is kiterjedő - tájékoztatását követő hozzájárulása alapján lehet adatot tárolni, vagy az ott tárolt adathoz hozzáférni.

Szóval ez sem újkeletű dolog, ez a módosítás 2011-ben került bele a törvénybe, ezt sem a GDPR „találta ki”.

Új elemként jön be a képbe viszont a 2012/4-es adatvédelmi munkacsoport vélemény, amely kicsit pontosította és nevén nevezete a sütiket, és ajánlást tett arra, hogy mely sütik tárolásához szükséges és melyhez nem szükséges a felhasználó hozzájárulása.

Végül a süti-helyzet tisztázására a NAIH 2017-ben kiadott egy tájékoztatót (webáruházak számára), amelyben megpróbálja tisztába tenni a kérdéskört. 

A süti-szörny lecsap

Ami a NAIH véleményben újdonság (és amellyel nemigazán törődik senki), hogy az olyan sütik esetében, amelynek tárolásához a felhasználó hozzájárulása szükséges (nagyjából a session és biztonsági sütiken kívül mindegyik), minden egyes sütihez be kell kérni a hozzájárulást.

Azaz, a jelenlegi cookie-szabályok és tájékoztatók 90%-a hibás: ugyanis egyszerre, egy lépésben kéri meg az összes sütire a felhasználó beleegyezését, ez pedig a NAIH szerint nem megfelelő.

„Ezzel kapcsolatban fontos kiemelni, hogy a hozzájárulást a webáruház üzemeltetőjének sütinként külön-külön kell beszereznie. Nem fogadható el az a megoldás, ha a webáruház üzemeltetője valamennyi, a felhasználó hozzájárulását igénylő sütihez egyszerre kér egyetlen hozzájárulást.„

Namost ez azért jó, mert ha egy kicsit fejlettebb weboldal például 31db sütit akar tárolni a felhasználó munkaállomásán, akkor ezek szerint 31 hozzájárulás szükséges a sütik tárolásához – el lehet képzelni, hogy mennyire fogja ezt a felhasználó szeretni, másrészt pedig mennyire nehéz ezt karbantartani a weboldal üzemeltetője részéről.

Tapasztalat, hogy a weboldalak üzemeltetőinek többnyire lövésük sincs arról, hogy az érvényes cookie-szabályzat kiadása óta az oldalon bekövetkezett fejlesztések, változások (pl. Sanyi, nincs valami chat program, amit be lehetne integrálni?!) milyen új sütiket akarnak kitárolni a látogató munkaállomására. Akkor hogyan is akarják bekérni a hozzájárulást?

Erre a problémára mutatunk egy jó megoldást a következő videóban.

Cookiebot - sütik feltérképezése és dinamikus süti-szabályok, tájékoztatók és hozzájárulások létrehozása

A videót itt tudjátok megnézni, és persze, iratkozzatok fel a csatornára. 

Néha nem kell feltörni semmilyen szolgáltatást ahhoz, hogy felhasználó neveket és jelszavakat gyűjtsön az, aki ilyenben leli örömét.

Erre jó példa a Trello – közkedvelt én-nem-is-tudom-mi menedzsment megoldás: de annyi tuti, hogy nem feltétlenül arra találták ki, hogy a nyitott oldalain jelszavakat tároljanak.

Alighanem a Trello táblák gazdái jobban tennék, ha valahogyan máshogy tennék mindezt, mert, hogy a publikus kártyákban nem túl célszerű, arra itt van a bizonyíték:

A Google segítségével és némi kereséssel hekkelés nélkül is lehet felhasználói adatokat gyűjteni - amelyeket a felelőtlen Trelló felhasználók saját maguk szivárogtatnak ki. 

A múlt héten közreadott kiszivárgott hozzáférésekkel kapcsolatos posztunk igen népszerű lett, talán annak is köszönhetően, hogy igen masszív magyar érintettségekkel is büszkélkedett.  

Kis emlékeztető, egy orosz fórumon felbukkant, 404millió rekordos, kiszivárgott felhasználói adatokat tartalmazó listát vizsgáltunk meg, amelyben 1,5 millió magyar felhasználói rekordot találtunk, illetve több olyan magyar weboldalt, amelyből felhasználói adatokat loptak el.

Most egy picit visszamegyünk az időben, na nem túl sokat, csak úgy fél évet.

2017 decemberében felbukkant egy olyan 1.4 milliárd rekordot tartalmazó kompiláció, amelyet a breach adatokat vizsgálók, illetve az Account Takeover (ATO, kompromittált felhasználói adatok felderítése) területén motorozók ma alapműnek tekintenek, és amely évekre visszamenőleg tartalmazza a nagyobb adatszivárgások adatait.

A kombólista („Combolist of 1.4 Billion Credentials”) legnagyobb hátránya (mint minden kombólistának), hogy nem tartalmazza a forrásokat, azaz, mely felhasználói adatok pontosan honnan származnak. Emiatt a források visszaazonosítása igen nehézkes, a legtöbben egyébként nem is foglalkoznak vele, elterjedt gyakorlat, hogy önálló forrásként kezelik (annak ellenére, hogy mindenki tudja, hogy sokezer forrásból származó információkat tartalmaz).

A cucc mérete 40GB körül van, szóval a feldolgozása sem túl egyszerű, de szerintem mindenképpen érdemes vele legalább annyit foglalkozni, hogy megnézzük, milyen magyar érintettségeket tartalmaz, illetőleg, ha a magyar érdekeltségeket összehasonlítjuk a múltheti kompliációval, hogyan néz ki a statisztika és mekkora egyezőséget mutat a múltheti adatokkal.

Több, mint kétmillió magyar felhasználói adatrekord

Leszűrve a majdnem 1,4 milliárd rekordot, a 2017-es kombólista 2.404.244, azaz majdnem két és fél millió ".hu" végződésű email címet és hozzátartozó jelszót vagy jelszó hasht tartalmaz.

Ennél lényegesen több magyar felhasználói rekord szerepelhet az adatbázisban, nyilván a "gmail.com" és más, nem ".hu" végződésű rekord azonosítása elég macerás, szerintem nyugodtan számolhatunk 1,3-mas szorzóval: azaz a 2017-es lista szerintem legalább 3.1 millió magyar érintettségű felhasználói rekordot tartalmaz.

Egyedi rekordok kérdése

Sokszor felmerül a kérdés, hogy rekordokról beszélünk és nem felhasználókról, azaz, hogy mégis hány egyedi felhasználó érintett a breach adatokban?

A kérdésre nehéz válaszolni mivel kombólistáról van szó, ahol a források nem ismertek.

A felhasználók előszeretettel használják ugyanazt a felhasználó név és jelszó párost több rendszerben is, így, ha két rendszerből is kiszivárogtak az adatok, a kombólistában is esélyes, hogy kétszer is ugyanaz az adat fog szerepelni, így a forrás ismerete nélkül a rekord nemigazán mondható sima duplázásnak (hisz valójában két breach eseményből származik a két rekord).

(Arra természetesen van lehetőség, hogy egyedi felhasználókat nézzünk, hiszen az email címek deduplikálásával megkapjuk az egyedi felhasználószámot, de semmiképpen nem az egyedi breach eseményekkel lesz ez egyenlő.)

Ha rekordszinten összehasonlítjuk a két listát, 676 121 egyező ('.hu') rekordot kapunk, tehát a két listának közel 30%-os metszete van, azaz 676 ezer olyan rekord van, amely mindkét listában is megtalálható, illetve több, mint 700 ezer olyan rekord található a „Combolist of 1.4 Billion Credentials” két és fél milliós ".hu" blokkjában, amely viszont a múltheti listában egyszer sem szerepel.

A „Combolist of 1.4 Billion Credentials” kombólista közel 1,8 millió egyedi, ".hu" végű email címet (felhasználó név), míg az „orosz fórum lista” másfélmillió .hu végű rekordja „csak” 833 ezer egyedi email címet (felhasználó név) tartalmaz.

10 millió breach rekord országa

A két listából azért már sejthető a magyar ATO helyzet, de azért a sejtés helyett nézzünk konkrét adatokat is.

A mennyiségek bemutatásához egy olyan listát használunk, amelyhez egy ATO felderítéssel foglalkozó szervezet jóvoltából jutottunk hozzá, és amely listában a 100 legtöbb breach rekorddal rendelkező ".hu" domain található.

A lista nem a feltört oldalakat és szolgáltatásokat tartalmazza, hanem olyan felhasználói rekordokat (csak a számosság!), amelyek valamilyen külső szolgáltatásból szivárogtak ki és ahol a felhasználónévben az adott domain cím szerepel.

A 100-as lista összesen 9,7 millió magyar felhasználói breach rekordot tartalmaz, tehát ez a 100 domain együttesen összesen 9,7 millió kiszivárgott felhasználói rekorddal rendelkezik.

• A „TOP-20” kategóriában kizárólag hazai Internet szolgáltatók vagy levelezési szolgáltatást nyújtók találhatók.
• A „TOP-1” egy hazai szolgáltató, 5,4 millió rekorddal.
• A „TOP-5” kategória tagjai együtt 8,6 millió rekordot jelentenek, ők adják a TOP-100 lista 9,7 milliós mennyiségének 89%-át.
• Ha a „TOP-20” kategóriába tartozókat összeszámoljuk, 9,3 millió breach rekordról beszélhetünk, ez a teljes TOP-100 mennyiség 96,3%-a.
• A lista 100. helyén tanyázó domainhez már „csak” 1623 kiszivárgott adatrekord tartozik.

...és már csak 10 nap van a GDPR-ig :)

Nem tudom leértünk-e már a verem legaljára, vagy még innen is van lejjebb?

"Az auditot szakértőink akár már 100 ezer forinttól vállalják."

Ugyanitt bablevesért szpunk.

És még azt mondják, hogy a GDPR megfelelőség sokba kerül, mennyi költség és idő! 

A GDPR megfelelőség akár lehet nagyon egyszerű is, egyetlen fillérbe sem kerül, és kb. 2 perces munkával megoldható.

Azt mondod, hogy hazudok?

Pedig hidd el, megoldható, bízz bennem (bár azért figyelmedbe ajánlom a Vagyongyűjtés szabályai 47-es pontját: „Az ingyen tanács ritkán olcsó”).

De ha nem hiszed, jöjjön egy kiváló, low-cost GDPR megfelelőség példája. A jobjet.com nemzetközi álláskereső/közvetítő megoldásával kiérdemelte a 101%-os GDPR megfelelőséget. 

Íme:

Na ugye!

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.

Egy orosz fórumon előkerült egy brutális mennyiségű felhasználó nevet és jelszót tartalmazó, kategórizált breach lista, amelyben többszázezer (inkább már milliós tételről beszélünk) magyar felhasználó is szerepel. A szuperül összegyűjtött, könyvtárakba rendezett lista egy úgynevezett „kombó”, amelyben sok rendszerből kiszivárgott hozzáférések találhatók.

Az előző posztomban mutattam be ezt a csodálatos leletet, majd gyorsan pár magyar websitetot is összeírtam, akiknek a felhasználói megtalálhatók ezekben az állományokban. 

Második forduló

Sikerült tovább pörgetnem a breach adatfájlokat.

A „Dump” kategória alatti 424 fájlt néztem meg, amely 424 website lenyúlt felhasználó név és jelszó (vagy hash) párosát tartalmazza. Nem ritkák az ilyen gyűjtemények, sok fórumon árulgatnak ilyen „adatbázisokat”.

Vegyék, vigyék! Cak cáz, kici lehet ötven?

Sejtettem, hogy rohadt sok ismétlődés lesz, és persze így is volt, az előző posztban említett magyar oldalak itt is megtalálhatók voltak, úgyhogy szofisztikált deduplikálás következett (kitöröltem őket a francba :), illetve olyan listákat, amelyekben láthatóan random generált címek voltak szintén töröltem), végül a .hu végű email címekre rászűrve néztem végig a listát.

(mivel csak a .hu domain végződésű email címekkel foglalkoztam, ennél sokkal több magyar érintett van ezekben a fájlokban, hiszen a gmail.com vagy más végződések kiestek a rostán)

Ami maradt, az 57 947 .hu domain végű rekord, amelyeket jellemzően régi adatszivárgásokból állnak össze.

De ennél azért többről beszélünk. Most is akadt olyan site, amely eleve magyar, szóval következzen egy kis lista (feltételezve, hogy minden itt regisztrált személy magyar, tehát nem csak a .hu domain végződésű címeket számolom):

Megint nem maradt időm végignézni a csábító Gaming szekciót, amely 105 breach állományt tartalmaz. A gyűjtemény szintén websiteokra van bontva, szóval legalább 105 site (breach source) található benne. 

Alighanem érdekes lesz :)

Egy kis állapotjelentés a kiszivárgott magyar hozzáférésekkel kapcsolatban

A legtöbb szervezett visszajelentkezett ma, megköszönték az értesítést – nyilván ez azt jelenteti, hogy korábban nem tudtak arról, hogy valami történt a felhasználói adatbázisukkal.

Érdekes közjáték, hogy amikor felhívtam ma reggel az egyik szervezetet, a beszélgetés végén a kolléga megkérdezte, hogy miért szóltam nekik, mi a célom azzal, hogy szóltam, valamint, hogy akkor ezt ingyen csinálom? :)

Megpróbáltam elmagyarázni, hogy szakmai kötelesség, meg minden, hááát, nem tudom mennyire sikerült :)

Tegnap már igen álmos voltam amikor posztoltam, és nem nyomoztam sok mindennek utána. Ma már rájöttem, hogy az Euronote kikerült adatbázisával kapcsolatban már bőven voltak nyomok, most meg is találtam, hogy a publikálás dátuma idén februári (azt nem lehet tudni, hogy mikor vitték el).

Tegnap már nem volt erőm átnézni a kicsit összehányt részeket a listákból, de most jobban megnézve, alighanem a java még hátravan. Rengeteg játék oldal (kb 100), randi oldalak (Badoo, Zoosk) és lehetne sorolni, alighanem ezek jó része már régebbi (pl. Badoo breach 2016 – 122 MILLIÓ rekord, Zoosk breach 2016, 54 MILLIÓ rekord) – és pl. a Dump listában benne van az Euronote is, szóval már itt is lesznek ismétlődések.

Úgyhogy megpróbálok azokkal a listákkal foglalkozni, amelyekben van valamilyen magyar érintettség, az is éppen elegendő lesz szerintem :)

És a legfontosabb hír a végére, amit ma mindenki megkérdezett: NEM, nem voltak politikai pártok, vagy kormányzati felhasználók a pornó adatbázisban (legalább is hivatalos címmel nem :))