Július második felében komoly botrányt okozott a Budapesti Közlekedési Központ (BKK) internetes jegyvásárlási rendszerének bevezetése. A politikai felhangoktól sem mentes ügyről ebben a posztban a vezetők számára leszűrhető informatikai tanulságokat foglaljuk össze, de szokás szerint, előbb megnézzük időrendben, hogy mi történt pontosan és mit tudunk az esetről.

TLDR;

Július 13-n megjelenik a BKK online jegyértékesítő rendszere, amelyről az első napokban számos súlyos biztosági és funkcionális hiba derül ki, de a rendszer egy hétig elérhető és működik, 5000-en regisztrálnak, 800-an vásárolnak 6 millió forintért, közben több hullámban internetes támadás éri a rendszert.

Amikor egy héttel később, július 21-én nyilvánosságra kerül, hogy egy súlyos hibát bejelentő fiatalt a T-Systems feljelentésére a rendőrség őrizetbe vett, elszabadul a pokol az Interneten, kommentáradat zúdul a BKK és a TSM Facebook oldalaira, és 3 napig elérhetetlen a BKK internetes oldalán számos más utastájékoztató rendszer is. Végül az online jegyértékesítő rendszert lekapcsolják, elindulnak a vizsgálatok és a politikai játékok is.

A postban az időrendbe szedett események után összeszedjük, hogy milyen tanulságokkal szolgálhat az eset az informatikáért felelős vezetők számára az architektúra és alkalmazások, az üzemeltetés és incidens menedzsment, a informatikai projektmenedzsment, valamint a nyilvánosság kezelése tekintetében.

Események időrendben

Július 13-án délután bejelenti a BKK, hogy elindult az online értékesítési rendszere. A hírt az MTI-n keresztül majd minden portál átveszi.

Ezen a napon írja alá a BKK és a T-systems Magyarország (TSM) a feljesztésre vonatkozó szerződésmódosítást is, de a két cég már hetekkel megelőzően együtt dolgozik a rendszer üzembe állításán és tesztelésén.

Az első értékelések felhasználói kényelmetlenségekről szólnak és használhatósági problémákat vetnek fel, de a fogadtatás a sajtóban pozitív. Az Index kéri az olvasói véleményét is, és jelzi, hogy másnap próbavásárlást fog végezni.

Péntek, július 14.

Napközben megjelennek az első komolyabb hibákat jelző posztok.

A Twitteren a regisztrációkor használt Captcha rendszert szedik ízekre, az Index (12:01-kor) a próbavásárlás során észlelt hibákról tudósít: a megadott emailcímet nem kell visszaigazolni, sokat kell gördíteni az idő beállításánál. A vásárláskor nem találják meg a később nagy port felvert HTTP Post Request hibát, hanem a cikk szerint „A vásárlás az OTP felületén szépen lezajlik”.

A legsúlyosabb ismert és nyilvánossá váló biztonsági hiba az, hogy a rendszer emailben kiküldi a felhasználónevet és a jelszót egyszerű szöveges formátumban. Erre már számos IT szakember felkapja a fejét, mert jelszót nem tárolunk, és nem küldünk ki e-mailben, de azért a hiba javítása nem tűnik bonyolultnak.

A tesztvásárlás konklúziója ekkor még az Index-en az, hogy

BKK e-jegyét a legnagyobb jóindulattal is csak egy nyilvánosan tesztelt korai bétaváltozatnak nevezhetjük, amit élesben, a mi pénzünkön próbálnak használhatóvá csiszolni. Érthető, hogy most vezették be, a nyár közepén, és nem amikor az iskolások hadával is meg kell küzdeni.

Péntek délután 14:49-kor bejelenti a később etikus hacker-nek nevezett fiatal a shop@bkk.hu-ra, majd valamivel később a BKK Ügyfélszolgálatának az e-mail címére, a HTTP Post request hibát. A BKK az így vett bérletet a bejelentés után egy órával érvényteleníti.

A bejelentő értesíti az Indexet is, ahol 16:31-kor megírják, hogy meghekkelhető a BKK rendszere, egy tervezési és programozási hibát kihasználva bármennyiért lehet jegyet venni.

...a post request hiba nyilvános, a szerver felé továbbított kérésben a kosárba rakáskor kell átírni egy számot, mert a böngésző küldi el a szervernek, hogy mennyibe kerüljön a bérlet. Aki így vesz magának bérletet, annak tisztában kell lennie azzal, hogy bűncselekményt követ el...

A BKK első reakciója az Index megkeresésére, hogy a rendszert érik támadások, de folyamatosan működőképes, elérhető és folyamatosan használják, de nem rendeltetésszerű használat esetén vizsgálják a bűncselekmény gyanúját. Közlik, hogy „a rendszer már bevezetési időszak kezdetén olyan automatikus visszaélés figyelő funkcióval kezdte meg működését, amely az ilyen jellegű próbálkozásokat detektálja és azonnali intézkedésre ad lehetőséget.” Itt valószínűleg egy IDS rendszerre utalnak.

Az első hétvége

További problémás esetekről jelentek meg posztok az Interneten

A böngészőkbe beépített fejlesztői eszközökkel módosítani lehetett a felhasználónév beviteli mezejének írásvédettségét, oda más felhasználónevet beírva megkapták a felhasználó adatait, köztük a szövegként tárolt jelszóval, egyben leírva a dilemmát is, hogy mit kell ilyenkor jóhiszemű informatikusként csinálni.

Arról is olvashattunk, hogy valaki nem tudja törölni a rendszerből a fiókját, vagy a személyi okmányának adatait.

Frissítés (aug. 2.): a BKK webszerver gyenge pontjaitól ír a Válasszunk blog az SSL beállításokat ellenőrizve néhány nyilvános ellenőrző eszközzel. Megtalálják a DROWN és a BEAST sérülékenységet is.

Videón dokumentáltan jelent meg, hogy lemásolt elektronikus bérlettel 10 esetből 10-szer jutottak át az ellenőrzésen, a másolt jegyet a QR olvasós ellenőrzés nem tudta kiszűrni.

Ez a hiba súlyosnak tűnik, mert ha orvosolják is az adatbiztonsági problémákat, a bérlet QR-kódja mindig másolható marad, azaz a bliccelés kockázata a javításokkal sem tud eltűnni.

Kedd, július 18.

Sajtótájékoztatót tartanak a főváros, a BKK és a TSM részvételével. Elmondják, hogy a T-Systems üzemelteti a BKK-automata hálózatot, egy ehhez kapcsolt szerződésmódosítással tették lehetővé, hogy ők építsék az online digitális értékesítési rendszert is. Az új online értékesítési rendszer az elmúlt napokban kibertámadásoknak volt kitéve, de a felhasználók adatai biztonságban vannak, leállításnak nincs oka. Az értékesítési rendszerre ötezren regisztráltak, 800-an vásároltak jegyet vagy bérletet. Az üzemeltető T-Systems büntetőfeljelentést tett az ellen, aki a 10.000 forintos bérletet 50 forintért akarta megvenni, és a Nemzeti Nyomozó Iroda megkezdte a nyomozást, 600 támadást regisztráltak néhány nap alatt.

Péntek, július 21.

Egy héttel a bevezetés után megjelenik a hír, hogy a Nemzeti Nyomozó Iroda információs rendszer vagy adat megsértése vétség elkövetésének megalapozott gyanúja miatt folytat nyomozást, egy gyanúsítottat őrizetbe vettek, aki rabosítás után szabadlábon védekezik.

Ennek hatására elszabadul a pokol az Interneten, kommentáradat zúdul a BKK és a TSM Facebook oldalaira.

Napközben nyilvánosságra kerül, hogy az alkalmazáson kívül a BKK webszerver konfigurációja sem biztonságos és sérülékeny lehet a DROWN típusú támadással szemben, vagyis rosszul konfigurált a biztonságos kommunikációt szolgáló HTTPS beállítás. Fontos, hogy ez a hiba nem a bevezetett alkalmazással függ össze, és már a bevezetés előtt is létezhetett.
Frissítés (aug. 2.): a sérülékenységről már július 15-én írt a Válasszunk blog.

Az alkalmazással összefüggésben további hiba került nyilvánosságra: a regisztráció törlésekor nem ellenőrizték a törlést kérő személy azonosságát.

Este, az őrizetbe vétel hírére kitört botrány hatására a BKK és a TSM vezérigazgatói közös nyilatkozatot adnak ki, hogy sajnálattal értesültek arról, hogy a gyanúsított egy fiatal diák, aki a médiában megjelent nyilatkozatai szerint jószándékkal járt el, egyben cáfolva a keddi sajtótájékoztatón elhangzottakat.

Szombat, július 22.

Másnap, egy héttel a botrány kezdete után, a két vezető újabb, most már személyes hangú közleményben, elnézést kérve próbálja tovább nyugtatni a kedélyeket (BKK, TSM)

Közben egy BKK közlemény előbb arról tájékoztat, hogy folyamatos támadások és túlterheltség miatt nem elérhetőek a weboldalukon futó utastájékoztató szolgáltatások, majd egy másik közleményben közlik, hogy a BKK az informatikai rendszereit védő tűzfalat jelentősen megerősítette, az online értékesítési rendszer működése  zavartalan, az elektronikus ellenőrzés újra működik.

Megjelennek ez első, közérthetően megfogalmazott leírások a feltárt hibák jellegéről és fontosságáról.

Hétfő, július 24.

A hétvégi közleménnyel ellentétben hétfőig nem működött a BKK weboldalán a menetrendi oldal, azaz a járatok menetrendjei, illetve a járatok zavarairól hírt adó BKK Info tájékoztató rendszer, vagyis a legalapvetőbb utastájékoztatási funkciók 3 napig nem működtek. Az utastájékoztatás hétfői nap folyamán helyreállt, de az online értékesítés azóta sem érhető el.

Reggel egy rádióinterjúban a BKK vezetője rosszhiszeműséggel vádolja az etikus hacker-t, nem tudván, hogy a BKK Ügyfélszolgálata is megkapta a hiba bejelentését. A vezetői nyilatkozatok alapján néhány média megjegyzi, hogy BKK és a T-Systems vezérigazgatói napokon át nem voltak képben a e-jegyrendszer témájában. 

A Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) közölte, hogy tájékoztatást kért a BKK-tól az online jegyárusító rendszerrel kapcsolatban, és a válaszok alapján dönt, hogy milyen vizsgálatot folytassanak le. Felhívta a figyelmet, hogy a 2018. május 25-től érvénybe lépő uniós GDPR rendelkezés nem csupán azt követeli meg, hogy az adatkezelő nyilvántartást vezessen az incidensekről, hanem az incidensek hatósági bejelentését is előírja.

Napvilágra került a szerződéskötés módja és jogi helyzete: a BKK nem hirdetett közbeszerzést, hanem utólag beleillesztette az online bérletrendszer fejlesztésére vonatkozó részt egy régebbi, T-Systemsszel kötött, a jegyautomatákról szóló szerződésbe.

Este megszólalt a T-Systems International is, hangsúlyozva, hogy az etikus hackerek tevékenysége támogatandó és nem üldözendő, valamint kérték a Magyar Telekom és a TSM vezetőit ennek támogatására.

Kedd, július 25.

Információ jelenik meg arról, hogy a BKK közbeszerzési eljárásban az év elején szerződött a Kürt Zrt-vel a BKK meglévő infrastruktúrájának információbiztonsági állapotfelmérése és folyamatos auditálására. A Kürt ezt pontosítja azzal, hogy a szerződés alapvetően nem a most futó webes projekt biztonsági ellenőrzéséről szól, és bár a BKK megtehetné az AFC projekt keretszerződése alapján, hogy most is igénybe vegye a Kürt erőforrásait, szakértelmét a webes jegyárusító portállal kapcsolatban is, erre nem került sor, tehát ők nem auditálták a webes rendszer működését. 

Nyilvánosságra kerül egy T-Systems Magyarország munkatársainak küldött levél, amelyben a TSM vezérigazgatója arra kérte a cég munkatársait július 12-én délután, hogy „komolyabb terhelési teszt”-ként tegyék próbára a BKK-nak fejlesztett webes jegyértékesítési rendszert. Ekkor már az éles rendszer működött, beleértve a banki fizetési interfészt is.

A 24.hu birtokába került egy július 16-i keltezésű adatbázis a BKK online jegyértékesítőjében (shop.bkk.hu) regisztrált 3481 felhasználó adataival. Az adatbázissal az újság a jogszabályoknak megfelelően megkereste a Nemzeti Adatvédelmi és Információszabadság Hatóságot (NAIH), és átadták az adatokat.

Szerda, július 26.

További információk jelennek meg a BKK és a T-Systems közti szerződés tartalmáról és a szerződéskötés módjáról, sőt ismertté válik a vonatkozó szerződésmódosítás is.

A szerződésből jól látszik, hogy a BKK jegykiadó automatákkal kapcsolatos "TVM" (Ticket Vending Machine) szolgáltatáshoz kapcsolódva a T-Systems feladata a TVM központi vezérlő egységéhez egy webes értékesítési modul fejlesztése és üzembe helyezése volt. Megjegyzendő, hogy a szerződés nem rendelkezik az üzemeltetéshez kapcsolódó kérdésekről.

Az online értékesítő rendszer hibáinak megértése miatt fontos, hogy a szerződés alapján a T-Systems feladata a backend rendszer fejlesztése és telepítése volt, a BKK végezte a frontend (honlap és webszerverek) fejlesztését, és a T-Systems felelt az integrációért. A backend rendszert a TVM üzemeltetéséhez használt hardverre telepítik, a frontend-et a BKK más utastájékoztató szolgáltatásokat végző webszervereire.

Csütörtök, július 27.

A T-Systems elismerte, hogy rendszernek voltak olyan hiányosságai, amelyek további fejlesztést kívántak. Bejelentik, hogy a cég fejlesztőcsapata folyamatosan dolgozik a rendszer továbbfejlesztésén, és őszre új platformra helyezik a BKK e-jegyrendszerét, a tesztelésére pedig „bug bounty” módszereket is bevetnek.

Kiderült, hogy a szolgáltatás indulását követően három hullámban több típusú és intenzitású támadás érte a rendszer különböző pontjait, bár a támadások pontos időzítése és napjai nem ismertek.

• Az első IT szakértelmet igénylő támadások még kisebb számú kísérletekkel a rendszer feltörését célozták.
• A második hullámban a támadások jellege kibővült. Ekkortól szervezett, 87 különböző IP címről érkező és még magasabb szakértelmet kívánó automatizált, 9450 kártékony kérés érkezett.
• A harmadik hullámban részben külföldi szerverekről érkező támadáshullám mértéke a szolgáltatás működésének leállításához vezett.

A Főpolgármester a T-Systems-et helyezte nyomás alá, magyarázatot követelve a rendszer működésével kapcsolatos hibákról, szivárogtatással vádolva a munkatársait, és a német tulajdonostól kért magyarázatot. Bár nem a poszt tárgyához tartozik, fontos hogy a T-Systems Magyarországnak magyar tulajdonosa van, a Magyar Telekom, ahol a tulajdonosi és menedzsment kinevezésével kapcsolatos jogokkal is rendelkeznek. A T-Systems International Magyarországon az IT-Services Hungary Kft-vel van jelen.

Péntek, július 28.

Gazdaságossági kételyek jelennek meg azt boncolgatva, hogy a várható online értékesítés darabszáma és a szolgáltatásra fordított költség alapján egy online bérlet eladása 250 forint körüli összegbe kerül a BKK-nak.

Szombat, július 29.

Részletek jelennek meg a BKK és a webes értékesítési rendszert szolgáltató T-Systems Magyarország szervereit ért terhelésről. A hivatkozott, de nem nyilvános jelentés szerint a rendszert több alkalommal szándékos túlterheléses és a sérülékenységre irányuló támadás érte. A másodpercenként keletkező naplóbejegyzések száma az átlagos 300-400-ról 13 ezer fölé ugrott, ami óránként közel 47 millió bejegyzést jelent. Ennek hatására a felhasználók nem tudták elérni rendszert.

Azt mi tesszük hozzá, hogy ha egy oldalletöltés 5-10 naplóbejegyzést generál, akkor értelmezésünk szerint a fenti számok  másodpercenként 1-2000 oldalletöltést jeleznek, ami jelenthet egy kiugró érdeklődést is, nem feltételenül csak egy terheléses támadást, de kíváncsian várjuk a részleteket.

Tanulságok menedzsment szempontból

 Négy területre bontva teszünk kísérletet a vezetők számára fontos informatikai tanulságok megfogalmazására.

1. Architektúra és alkalmazás

2. Üzemeltetés és incidens menedzsment

3. Projektmenedzsment

4. Nyilvánosság kezelése

1. Architektúra és alkalmazás

A legnyilvánvalóbb programozási és tervezési hibák az elmúlt két hétben már napvilágra kerültek. A hibák súlya nem egyforma, van köztük kényelmetlenséget okozó hiba, és komoly, a rendszer funkcionalitását akadályozó rendszerhiba is. A vezetői felelősséget és a tanulságokat három csoportba bonthatjuk:

1. Funkcionalitás és tervezései kérdések: vezetői felelősség azt biztosítani, hogy az alkalmazás elvégezze azt, amiért létrehozzák. Triviálisnak hangzik, de nem az, mert az ördög a részletekben van. Például egy súlyos tervezési hibának tűnik, melynek akár bevételcsökkenéssel járó anyagi következményei is lehetnek, hogy a megvett elektronikus jegy másolható, és nem látszik, hogy ezt hogyan lehetne könnyen és gyorsan javítani. Ugyanide sorolható a backend és a fizetési rendszer közti elmaradt vagy hibás ellenőrzések ténye, lásd 50 forintos bérlet. Kisebb súlyú, de a sikert hosszú távon alapvetően meghatározó használhatósági problémák is ide sorolhatók: sok görgetés, bizonytalanság a korábbi lépésekről, a visszalépés lehetősége, ...

2. Felhasználói adatok szabályos kezelése: különösen a jövőre életbe lépő, szigorú EU adatvédelmi rendelet értelmében vezetői felelősség tudni és biztosítani, hogy az alkalmazás az ügyfelek adatait biztonságosan tárolja és kezeli, hogy tisztában legyünk a fellépő problémákról és tudjuk kezelni azokat. Az ismert hibák alapján nem történt megfelelően a felhasználók azonosítása és a felhasználói jogosultságok vizsgálata (Jogosult-e az adott felhasználó az általa kért adatok ismeretése?) Problémás a felhasználói adatok, jelszó, igazolványszám, ... titkosítás nélküli tárolása és e-mailben való kiküldése is, illetve ide tartozik, hogy biztosítani kell a felhasználó kérésére az adatai törlését.

3. Internetes biztonság: internetes rendszerek esetén különösen fontos, vezetői feladat a támadások elleni védelmi képesség ellenőrzése. Ennél az alkalmazásnál a backend számos esetben nem kellően szigorú vagy egyáltalán nem végzi el az frontend-től, azaz a böngészőből kapott adatok ellenőrzését. Ilyen példák a beviteli mezők tartalmának ellenőrzése és semlegesítése, a rossz szándékó script-ek kiszűrése, a csak olvasható mezők változatlanságának ellenőrzése.

A fenti hibákkal kapcsolatos további tanulság, hogy bizony szigorú minőségellenőrzés és folyamatos tesztelés nélkül nem szabad alkalmazást kiadni a kezeink közül.

2. Üzemeltetés és incidens menedzsment

A fellépő problémák sokszor jól és hatékonyan kezelhetők begyakorolt üzemeltetési folyamatokkal, különösen egy jó incidensmenedzsment folyamattal. Az elmúlt két hét alapján számos probléma azonosítható ezen a területen.

1. Emelt szintű támogatás az induláskor: aranyszabály, de itt elfelejtkeztek arról, hogy egy induló rendszer támogatása mindig több erőforrást igényel, mint később. Nincs nyoma kiemelt támogatásnak a rendszerindulást követő napokban, se az üzemeltetést végző technikai erőforrások, se a felelős menedzsment részéről. A kérdések, panaszok, hibák a BKK általános ügyfélszolgálatára futnak be, BKK-T-Systems szerződés nem rendelkezik az üzemeltetésről, a hibákról nincs minimális visszajelzés sem a nyilvánosság felé, és sokszor látható volt, hogy lassan, késlekedve javítják őket.

2. Elavult konfiguráció az operációs rendszerben: a HTTPS konfigurációt érintő DROWN sérülékenység tisztán jelzi, hogy a BKK webszervere nem volt megfelelő biztonsági és karbantartottsági szinten, a T-Systems alkalmazástól függetlenül.

3. Támogató folyamatok kialakulatlansága: zűrzavarra és rendezetlenségre utal, hogy nem ellenőrizték a felhasználók regisztrációjának törlésekor a törlést igénylő személyét. Napokig előfordulhatott, hogy kérésre bárkinek a regisztrációját törölhették.

4. Méretezés és architektúra: a nyilvánosságra került adatok alapján nem volt elképzelhetetlenül magas a rendszer terhelése. Az adatok alapján 2000 körülire tehető a konkurens felhasználók száma, ami nem kezelhetetlen mértékű. Ez a Budapesten és környékén lakó emberek 0.1%-a, nem elképzelhetetlen ennyi kiváncsi látogató egy új BKK-s rendszeren. Ha ez a látogatói szám problémát okozott a rendelkezésre-állásban, akkor vezetői feladat vizsgálni a webszerverek méretezését, illetve a támogató rendszerek (tűzfal, cache, behatolásvédelem) megfelelő működését is. Kérdés, hogy a terhelés csökkentésében segítő modern megoldások használatára, lásd CDN megoldások, cloudfront vagy cloudflare, sor került-e és azok mekkora terheléscsökkentést jelenthettek volna?

5. Megkerülő megoldások minősége: hamár incidens van, mert első szándékból nem működik valami, akkor vezetői felelősség annak a megoldása, hogy a workaround legalább működjön. Az elmúlt két hétben, különösen a július 22-23-i hétvége alatt számos jele volt annak, hogy ez nem így volt, hanem kapkodó megoldások, ellentmondásos kommunikáció és nem működő ideiglenes megoldások fokozták a zűrzavart.

3. Projektmenedzsment

A szűk határidők és ellenmondásos elvárások miatt különösen fontos lett volna egy potens és felhatalmazással rendelkező projektmenedzsment. Mivel ebben a vonatkozásban alig van értékelhető információ, csak néhány megjegyzést teszünk.

Nem érthető, hogy miként tervezték a rendszer tesztelését? A határidővel kapsolatos ismert problémákon túl olyan kérdésekre gondolunk, hogy volt-e megfelelő tesztkörnyezet, milyen eszközökkel és milyen terhelési szintet megcélozva voltak-e terheléses tesztek, volt-e biztonsági vagy penetration teszt?

Lehetőség lett volna harmadik fél (Kürt) bevonására, nem világos, hogy erre miért nem került sor.

4. Nyilvánosság kezelése

A nyilvánosság kezelését csak annyiban érintjük, hogy felhasználókkal kapcsolatos adatbiztonsági problémák esetén illik (és 2018-tól kötelező lesz) vagy megerősíteni és bejelentést tenni, vagy azok megtörténtét cáfolni. Semmit nem mondani, késlekedve reagálni csak a probléma növelését jelenti.

Ide tartozó kérdés, hogy a felsővezetés több esetben nem volt tisztában a részletekkel. Ha a nyilvánosság már ismeri ezeket a részleteket, akkor a felsővezetést tájékoztatni kell a részletekről, olyan módon kell megtenni, hogy meg is tudják érteni. Sokszor segít, ha az információkat struktúráltan, az alábbi kérdések mentén készítik össze:

1. Mi történt és mi most a helyzet?

2. Mit fogunk csinálni és melyik intézkedés hol tart?

3. Mikorra áll helyre a működés?

Disclaimer

A szerző 2016-ig az T-Systems International magyarországi cégénél, az IT-Services Hungary Kft dolgozott vezetőként az informatikai üzemeltetés területén, de magyar ügyfelek felé 2012-től nem végeztek szolgáltatást. Az esetben érintett T-Systems Magyarországgal nincs és nem volt kapcsolata, a T-Systems International nemzetközi gyakorlatát viszon jól ismeri.