Tech

Regisztrált a BKK e-jegy rendszerében? Hozzáférhettek az adataihoz!

Több mint háromezer ember adatai kerültek a birtokunkba: nevek, e-mail címek, személyiigazolvány-számok. Forrásunk szerint a BKK új online jegyértékesítési rendszeréből szerezhették meg őket. Szakemberek szerint ha valósak az adatok, akkor több súlyos biztonsági hibát is elkövettek a fejlesztők, az áldozatok pedig sérelemdíjért perelhetnek. Az adatvédelmi hivatalnál bejelentést tettünk, ott várják a BKK tájékoztatását.

Kicsit több mint egy hete indult el a Budapesti Közlekedési Központ e-jegyrendszere, és az újfajta jegyek és bérletek értékesítésére szolgáló, a T-Systems által üzemeltetett online rendszer.

Nemrég pedig a 24.hu birtokába került egy július 16-i keltezésű adatbázis. A rendelkezésünkre álló információk alapján úgy tűnik, a BKK online jegyértékesítőjében (shop.bkk.hu) regisztrált 3481 felhasználó adatai köszönnek vissza benne. Minden: teljes név, felhasználónév, e-mail cím, az igazolvány típusa és száma.

Vagyis aki az első napokban regisztrált az új rendszerben, annak az adatai a forrásunk által küldött adatbázisban szerepelhetnek. Az adatbázissal a jogszabályoknak megfelelően megkerestük a Nemzeti Adatvédelmi és Információszabadság Hatóságot (NAIH), amelynek át is adtuk az adatokat; az adatvédelmi hivatal összevetése igazolhatja majd minden kétséget kizáróan az adatok valódiságát.

Forrás: 24.hu

Mint Péterfalvi Attila NAIH-elnök a 24.hu-nak elmondta: a szerkesztőségünkhöz eljuttatott adatbázist a korábban bejelentett vizsgálat során felhasználják.

Tájékoztatást kértem a BKK-tól, hogy milyen adatvédelmi incidens történt. Ezt követően döntünk róla, hogy vizsgálati vagy hatósági eljárást indítunk az ügyben. A közlekedési társaság tájékoztatásában ki kell térnie rá, hogy milyen adatkört érintett, hány személynek az adatai kerültek ki, illetve mit tettek annak érdekében, hogy megakadályozzák az incidenst

– mondta Péterfalvi.

Az alábbi kérdéseket küldtük el a BKK és a T-systems Magyarország sajtóosztályának:

  • Hány kibertámadás történt a rendszer ellen annak indulás óta? Ebből hány volt sikeres?
  • Történt-e adatvesztés, adatszivárgás ez alatt az idő alatt? Ha igen, mekkora mértékű? Tettek-e bejelentést (adatvédelmi hivatal, rendőrség)?
  • Kell-e a regisztrált felhasználóknak aggódnia személyes adataik védelme ügyében?
  • Korábban szó volt róla, hogy a kezdeti indulás után, a hétvégén emelték a biztonsági szinten: ez mit jelent pontosan? Jelenleg milyen védelemmel van ellátva a rendszer?
  • A fejlesztőknek mennyi idő állt rendelkezésére a termék létrehozására?
  • Hogy látják, a rendszer indulásakor megfelelt a szakmai követelményeknek (modern felület, könnyű kezelhetőség, adatvédelem, IT-biztonság)?
  • Ha nem, milyen problémákat észleltek, s miket, mikor javítottak ki?

Megkeresésünkre a BKK sajtóosztálya közölte: „Az online értékesítési rendszer bevezetése alatt kialakult helyzet tisztázására Tarlós István főpolgármester átfogó vizsgálatot rendelt el.  A témával kapcsolatban információt a vizsgálat lezárása után tudunk adni.”

A T-Systems Magyarország kommunikációs osztálya közölte, hogy a cég „a sajtóban már korábban megjelent híreszteléseket” is folyamatosan vizsgálta. Azt írták:

Az eddigi vizsgálatok alapján jelenleg nincs tudomásunk az online jegyértékesítési rendszerrel kapcsolatos adatvédelmi incidensről; nincs tudomásunk arról, hogy bármely személy személyes adatai illetéktelenekhez juthattak volna. A belső vizsgálaton felül a T-Systems Magyarország hétfőn felkérte az EY nemzetközi tanácsadó céget egy külső, független szakértői vizsgálat lefolytatására is.

HIBA #1: Személyes adatok tárolása

A rendszer úgy működött, hogy a felhasználónevet és a jelszót emailben visszaküldték az adott felhasználónak, ez arra utal, hogy az adatokat mindenféle titkosítás nélkül, sima szövegként tárolhatták. (Ráadásul ezzel azt is „elárulták”, hogy melyik jelszóhoz melyik felhasználó tartozik – pedig fontos adatbiztonsági elvárás, hogy ezt a két adatot ne küldjük el együtt.)

A birtokunkba került képernyőmentéseken már az látszik, hogy a publikusan elérhető naplófájlokban volt egy bizonyos szintű védelem, egy elavult MD5 (hash) módszerrel voltak tárolva az adatok, azokat így még mindig könnyedén vissza lehetett fejteni.

Ha tényleg MD5-tel tárolták az adatokat, és nem sima szövegként, az már egy titkosítási szándékot takar

– mondta el kérdésünkre Ördög Rafael, az Emarsys webalkalmazás fejlesztője és technikai csapatvezetője.

Mint a szakember magyarázza: „Az egyirányú függvények úgy működnek, hogy az egyik irányban nagyon könnyű őket kiszámolni, a másik irányban pedig nehéz. Ez utóbbi arra hagyatkozik, hogy matematikailag meg lehet mondani, mekkora számítási kapacitás kell ahhoz, hogy kiszámoljuk. Ahogy nő a számítógépek képessége, úgy egy-egy hash függvény elavulttá válik. Pont ez a probléma az MD5-tel, hogy erre léteznek már algoritmusok, melyekkel vissza lehet fejteni az eredeti jelszót. Az általánosságban elmondható, hogy ha valaki MD5-öt használ, ismeri a titkosítási alapelvet, de nem a megfelelő függvényt, az aktuális szabványt használja.”

Miért problémás így titkosítani?

A hash egy egyirányú függvény, aminek ha megadunk egy tetszőleges hosszúságú szöveget, akkor abból egy fix hosszúságú, egyedi azonosítót generál. Az adott adatbázisokban ezt az egyedi hash-t és nem magát a jelszót tárolják sima szövegként.

Például: szormok = 7ac71ad56115c8fb73392549d3a78540

Modern rendszereknél a jelszavakat lassú, egyirányú függvényekkel kódolják (pl. Bcrypt, Scrypt vagy PBKDF2 10000+) Az MD5 viszont egy nagyon gyors függvény, így gyorsan végigpróbálható számos lehetőség. Példaképp a mai számítógépes kapacitások figyelembevételével, egy GTX980-as videókártyával MD5 esetén egy másodperc alatt 9745 millió hash-t tudnak végigpróbálni, míg Scryptnél másodpercenként csak 12 (!!) hash-t –azaz: egy másodperc alatt az A betűtől eljutnak az L-ig.

A brute force jelszótörő programok (pl. hashcat) mellett úgynevezett rainbow table-kkel is visszafejthetőek az egyszerűbb jelszavak. Ez lényegében egy óriási táblázat, ami az összes létező jelszókombinációt és a hozzá tartozó hash-t tartalmazza adott hosszúságig.

Így gyorsan visszafejthető, hogy ki használja az adatbázisban a “7ac71ad56115c8fb73392549d3a78540” jelszót, ami jelen esetben a “szormok”.

HIBA #2: Naplófájlok

A forrásunktól kapott képernyőmentések tanúsága szerint maguk a logok megfelelő jogosultság nélkül is hozzáférhetőek voltak, a naplófájlokban szerepelt, hogy ki, mikor jelentkezett be. A screenshoton látható: az e-mail címek és a jelszavak is kiolvashatóak, azokat sima szövegként tárolták.

A logok azok a naplófájlok, amik alapján visszakövethető, hogy mikor mi történt a rendszerben. A fejlesztők probléma, hiba, vagy akár betörés esetén ezek alapján nyomozzák vissza, hogy mi történt.

Miközben az alkalmazás fut, egy fájlba kiír szövegsorokat, amiben adatok vannak. Ha ezek nyilvánosságra kerülnek, azzal rengeteg mindenre lehet következtetni a rendszer belső működéséről. Éppen ezért a logokat, és az azokban tárolt adatokat is külön védeni szoktuk

– mondta Ördög Rafael.

A logokban normális esetben nem szokás érzékeny adatokat (jelszó és email cím) tárolni, mivel rendeltetésszerű használat mellett nincs rá szükség, és még akkor is felesleges kockázatot jelent, ha egyébként a logok nem érhetőek el nyilvánosan. A szakértő hozzáteszi:

a logokhoz külső szemlélőnek semmi köze, ha az publikusan elérhető volt, az egy biztonsági rés lehetett a BKK rendszerében.

Ha valaki hozzáfér a logokhoz, azzal adott esetben olyan információra tehet szert, ami árulkodó jel lehet a rossz szándékú támadó számára, hogy merre érdemes tovább próbálkoznia. Ezt felhasználva egyre mélyebbre fúrhatja magát a rendszerben.

HIBA #3: Adatbázismentések

A forrástól kapott képernyőképek szerint az adatbázisokat is publikusan hozzáférhető könyvtárba mentették. Bár ezeket azóta törölték, a naplófájlokban a screenshotok tanúsága szerint szerepelt, hogy mikor készül adatbázismentés és annak a közvetlen elérhetősége is, ennek alapján azt kívülről bárki letölthette.

Ha hozzájutnak az adatbázishoz, akkor könnyedén visszafejthetik az egyszerűbb jelszavakat. Ez azért is problémás, mert sokan ugyanazt a jelszót használják mindenhol, így más szolgáltatásokhoz (pl. Facebook, Gmail) is hozzáférhetnek az email/jelszópáros birtokában

– magyarázta Izsóf András, a Centrál Médiacsoport fejlesztője.

HIBA #4: Ellenőrizetlen külső adatok

A webes programozás alapja, hogy minden kívülről érkező adatot ellenőrizni kell, mielőtt azt bármilyen formában felhasználnánk – ez a képek alapján szintén hiányzik a kódból.

Ha így van, ez egy teljesen amatőr programozási hiba

– mondja Izsóf András.

Lényegében arról van szó, hogy a kívülről érkező paraméterek értékeit nem vizsgálhatták, egy az egyben átvehették azokat. Pedig alapszabály, hogy a felhasználó által megadott adatot ellenőrizni kell. Így adott esetben kijátszható a beléptetés, vagy könnyedén 50 forintosra varázsolható át a bérlet összege.

Ennek elkerülése érdekében mindig meg kell vizsgálni, hogy az adott változó valóban olyan formátumú adatot tartalmaz, mint amire számítunk.

Például ha a felhasználónév ($user) változó nem tesz eleget az e-mail címekre jellemző elvárásoknak, akkor le sem futtatjuk a lekérdezést, hibát dobunk – jelszónál ($pass) ugyanígy. Vagy mint a bérlet árát módosító, a rendőrség által bevitt fiatal esetében: a bérletárát tartalmazó változó értékét átírta egy neki tetsző összegre, amit a rendszer egy az egyben elfogadott. Nem vizsgálták, hogy az adott összeg valós-e, van-e ilyen áron bérlet a rendszerükben, hanem egyszerűen átvették azt.

TÍZ HIBA, AMIT NE KÖVESS EL

Ha valósak az adatok, akkor a BKK online jegyértékesítési rendszere esetén a T-Systems egy Kürt audit mellett is több olyan hibát elkövetett, ami a 10 legveszélyesebb biztonsági hiba között van.

„Nehéz elképzelni, hogy ez megtörtént egy olyan vállalat esetén, melynek etikus hacker szolgáltatása is van, s egy komoly audit cég felügyelete mellett. Ahogy azt is nehéz elképzelni, hogy válsághelyzetben sózatlan MD5 hash-sel oldották meg a sima szövegként tárolt jelszó problematikáját” – mondja Ördög Rafael.

JOG #1: Mikor követünk el bűncselekményt?

Ha valaki ilyen adatbázis birtokába jut, akkor a Nemzeti Adatvédelmi és Információszabadság Hatóságnál (NAIH) tehet bejelentést, telekommunikációs cég esetén pedig a Nemzeti Média- és Hírközlési Hatóságnál (NMHH) – mondta el a 24.hu-nak Halász Bálint, a Bird & Bird nemzetközi ügyvédi iroda jogásza. A hatóság hivatalból kivizsgálja az ügyet.

A magyar büntetőtörvénykönyv tiltja a személyes adattal való visszaélést (Btk. 219 §), alapesetben egy évig terjedő szabadságvesztéssel büntethető az elkövető. Ugyanakkor csak akkor valósul meg ez a bűncselekmény, ha bizonyítható, hogy az elkövetőt haszonszerzési cél hajtotta vagy a visszaélés során jelentős érdeksérelem történt.

A Btk. szerint ötmillió és ötvenmillió forint közötti kár minősül jelentősnek, ami bankkártya-adatok jogosulatlan felhasználásánál valósulhat meg.

A Btk. fenti szakasza akkor is alkalmazható, ha az illető nem saját maga törte fel az adatbázist, és nem ő szerezte meg az adatokat, de ezek valahogy eljutottak hozzá, és azokat kezelte, például tárolta, felhasználta, közzétette, azaz visszaélt velük.

Fotó: Getty Images

Az információs rendszer vagy adat megsértése (Btk. 423. §) valósul meg akkor, ha valaki az információs rendszer védelmének „megsértésével vagy kijátszásával jogosulatlanul belép, vagy a belépési jogosultsága kereteit túllépve, vagy azt megsértve bent marad”. Ezt két évig terjedő szabadságvesztéssel büntetik.

Ugyanakkor ha a bűncselekmény célpontja közérdekű üzem, így például a közösségi közlekedési üzem, akkor a büntetés mértéke már két évtől nyolc évig terjedő szabadságvesztés is lehet. Ebben az esetben azt kell vizsgálni, hogy történt-e jogosulatlan belépés vagy bent maradás.

Ugyanakkor e bűncselekmény akkor is megvalósul, ha az elkövetőt nem hajtotta haszonszerzési cél és mindegy az érdeksérelem mértéke is. Az olyan etikus hekker tevékenységének büntetőjogi megítélése, aki nem a megbízója kifejezett kérésére teszteli a rendszerét, nem egyértelmű, ugyanis a belépéssel megvalósul a bűncselekmény. Az olyan esetekben, amikor a hekkert valóban a jó szándék vezérelte, általában azért szüntetik meg a büntetőeljárást, mert nem volt bizonyítható hogy a cselekmény valóban veszélyes volt a társadalomra, amely minden bűncselekmény előfeltétele.

JOG #2: Mi az adatkezelő feladata?

A jelenleg hatályos magyar adatvédelmi törvény, az Infotv. 2015. október módosítását követően minden személyes adatot kezelő vállalkozásnak és egyéb személynek kötelező nyilvántartást vezetnie az adatvédelmi incidensekről.

Ha incidens (például hackertámadás, adatszivárgás) történik, akkor az adatkezelőnek ebbe kell vezetnie az eset körülményeit, különösen, hogy kik az érintettek, milyen adatokhoz fértek hozzá, mikor, hogyan történt, mit tett meg a kockázatok csökkentése vagy az elhárítása érdekében.

Az adatkezelőnek a magyar jogszabályok szerint nem kötelező jelentenie az esetet: azaz nem kell bejelentenie a hatóságoknak, és értesíteniük a felhasználókat.

Kivételt képez, ha a privát szférára jelentős hatással járó adatlopás történik. Természetesen most is dönthet úgy egy adatkezelő, hogy a bejelentést, illetve az értesítést megteszi, hogy felhívja az érintettek figyelmét a kockázatokra és arra, hogy azokat hogyan tudják csökkenteni.

A rendelkezésre álló információk alapján valószínűsíthető, hogy jelen esetben a BKK az adatkezelő, a rendszert üzemeltető T-Systems pedig adatfeldolgozó, tulajdonképpen alvállalkozó.

Ha incidens történt, és az adatvédelmi hivatal tájékoztatást kér – ahogy kért is – akkor az adatkezelőnek betekintést kell engednie ezen nyilvántartásba. Ha egy érintett magánszemély kér tájékoztatást személyes adatai kezeléséről, akkor úgyszintén ebből kell őt tájékoztatnia arról, hogy adatai érintettek voltak-e incidensben.

A mostani magyar szabályozás, a telekommunikációs szektort kivéve, reaktív jellegű, azaz nyilvántartást kell vezetni, és ha valaki kér ebből adatot, akkor válaszolni kell rá.

“Ez persze a 2018. májs 25-én életbe lépő új uniós adatvédelmi rendelettel (GDPR) módosul. Akkor már nem csak az elektronikus hírközlési szolgáltatók (telefon- és internetszolgáltatók) lesznek kötelesek proaktívan jelenteni az incidenseket, és értesíteni az ügyfeleket, hanem minden adatkezelő, mint amilyen a BKK is” – magyarázza a jogász.

JOG #3: Mit tehet az áldozat?

Először is: ha a jelszót, amit a kompromittálódott rendszerben használtuk, máshol is ugyanazzal a felhasználónévvel vagy e-mail címmel együtt alkalmaztuk, akkor a lehető leghamarabb változtassuk meg.

Milyen jogi eszközök állnak rendelkezésre, ha sejtjük, hogy a személyes adataink kompromittálódtak? Kétféle, mondja Halász Bálint.

  1. Panasszal élhetünk az adatvédelmi hatóság felé, elindul egy vizsgálat, amelynek végeztével a hatóság kiszabhat szankciókat, így például jelenleg 20 millió forintig terjedő bírságot. A hatóság ugyanakkor nem állapít meg az érintetnek járó kártérítést.
  2. Pert indíthatunk a jogaink megsértése miatt. Ezt törvényszéki szinten lehet megindítani, akár az érintett lakóhelye szerinti bíróságon is, így például egy debreceni lakóhellyel rendelkező magánszemélynek nem kell Budapesten perelnie, akkor sem, ha az adatkezelő székhelye a fővárosban van. A törvényszék soron kívül köteles eljárni, ez azt jelenti, hogy viszonylag gyorsan sor kerül tárgyalásra és néhány hónapon belül megszülethet az elsőfokú ítélet. A bíróság jogsértés esetén sérelemdíj megfizetésére is kötelezheti az adatkezelőt. Ennek lényege, hogy nem kell bebizonyítani az illetőnek, hogy mekkora összegű kár vagy hátrány érte, csak a jogsértés tényét. A bíróság egy egyösszegű sérelemdíjat állapít meg, a jelenlegi bírói gyakorlat alapján 10 ezer, esetleg 100 ezer forintos nagyságrendű lehet – az utóbbi csak különösen súlyos hátrányt okozó esetekben. Ez egy 3481 fős bázis esetén összesen legalább 34,8 millió forint, egy belvárosi lakás ára.

Ajánlott videó

Nézd meg a legfrissebb cikkeinket a címlapon!
Olvasói sztorik