Etikus és etikátlan hackerek, informatikai hibák bejelentése és nyilvánosságra hozatala

Arról, hogy a BKK és a T-Systems hol és hogyan hibázott (gyakorlatilag mindenben) cikkek sora született, azonban a hasonló hibabejelentésekről, és ezek hátteréről kevés valós információ olvasható. A média egy jelentős része – egyébként tévesen – számos cikkben leközölte, hogy bezzeg külföldön, ha hibát talál az „etikus hacker”, akkor azt megdicsérik, és még pénzt is kap. Valójában a helyzet lényegesen árnyaltabb és bonyolultabb! Jelen írásban e témát járjuk kicsit körül.

Az informatikai hibák természete

A hibabejelentések azóta léteznek, amióta informatika létezik. A hibák keresése nyilvánvalóan fontos dolog, mivel elvárás, hogy a rendszerek megfelelő funkcionalitással és biztonságosan működjenek. A fejlesztések során általában igaz az, hogy egy hibát minél hamarabb észrevesznek, annál olcsóbb a javítása. Ez az oka annak, hogy minden – szakmailag értékelhető színvonalú – fejlesztés esetén komoly tesztelési munka is zajlik, már a tervezési és fejlesztési fázistól. Gondoljuk bele, mennyivel olcsóbb egy autó szoftverét javítani kiadás előtt, mint mondjuk a kiadás után visszahívni százezer terméket. A fentiek általában igazak minden rendszerre és szoftverre.

A hibák másik problémája, hogy ha egy rendszer bármilyen értékkel bíró dolgot kezel, – mondjuk egy webbank rendszer, vagy egy valuta tőzsdei szoftver – akkor nyilvánvaló, hogy nem csak a hiba javítása kerülhet pénzbe, hanem a hiba kihasználásával akár nagy értékeket is lehet lopni[1].

Egy hiba esetében fontos szempont, hogy mennyire könnyen javítható. Nehéz erre jó példát hozni, de képzeljük el, hogy mi a különbség aközött, hogy egy ház tetején szétcsúszik néhány cserép, vagy megreped és megsüllyed az alap. Az első eset, bár bagatellnek is tűnhet, mégis akár komoly értékek ázhatnak el egy nagy viharban. Ezzel együtt nyilván sokkal egyszerűbben kezelhető, mint a második eset. Ugyanígy van ez a szoftverek és rendszerek esetében is. Míg mondjuk egy, a BKK-s példában is szereplő paraméter ellenőrzés leprogramozása nem tűnik heroikus erőfeszítésnek, addig egy alapvető rendszer tervezési hiba akár a rendszer teljes újratervezését és újraírását is kikényszerítheti. Ez akár több hónapos, vagy akár éves munkával, és magas költséggel járhat.

A hibabejelentők és a hibát elkövetők természete

Fentiek után vizsgáljuk meg, hogy ki, és miért jelent be hibákat. A „hacker” kifejezés az informatika hőskorában egyértelműen egy pozitív jelző volt azokra nézve, akik értettek a programozáshoz, élvezték is azt, és olyan technikai bravúrokat tudtak végrehajtani, amiket csak kevesen. Később ez a szó – a játék feltörésektől kezdődően – egyre inkább az informatikai támadók / bűnözők szinonimája lett. Az utóbbi években került be a köztudatba az „etikus”, és a „nem etikus” hacker megnevezés[2].

Napjainkban a hibáknak saját fekete piaca van. A hibák olyan kihasználási módját, amivel a támadó el tud valamit érni, „exploit”-nak nevezzük. Ezeken a piacokon nagyon komoly összegeket lehet keresni. Képzeljük el, hogy mennyit érhet egy olyan „exploit”, amivel szervezett bűnözői körök, vagy állami hírszerző szolgálatok számítógépek millióit képesek elfoglalni. Például a titkosító vírusok által előszeretettel kihasznált irodai szoftverekben lévő gyengeségek. Nyilván, ahol kereslet van, ott kínálat is meg fog jelenni. A fekete piacokon keringő hibák és kihasználási módjuk – az eladók és a vásárlók szándékából legalábbis – sosem fognak nyilvánosságra kerülni, ezek nem kerülnek bejelentésre! Nem csak fekete piaca van a támadó kódoknak, hanem bizonyos cégek teljesen nyíltan és hivatalosan foglalkoznak ezek vásárlásával. Ők általában kapcsolatba lépnek a gyártókkal a javítás érdekében, másrészt gyakran árulják ezeket az eszközöket, főleg állami hírszerző intézményeknek.

Ezeket felismerve, – illetve az a tény, hogy vannak jóravaló „etikus” hackerek is – számos nagy informatikai gyártó hirdetett úgynevezett „bug bounty” programokat. Azaz a fellelt hibákért („bug”), – néha tényleg komoly – jutalmakat fizetnek, persze csak akkor, ha a tesztelők a projekt szabályainak megfelelően vizsgálják a rendszereket. Ilyen szabályok általában, hogy az anonimitását, illetve a hiba részleteit a tesztelő ne tudja megőrizni, – legfőképpen a kihasználásának a módját – nem hozhatja nyilvánosságra a javításig, sőt, bizonyos esetekben még akkor sem. Ne felejtsük el azonban, hogy ezek a cégek nem a „bug bounty” projektet használják tesztelésre, hanem a fejlesztés és üzembeállítás során nagyon komolyan tesztelik a rendszereket. Azaz ezek a hibák már olyanok, amelyek egy átfogó, módszertanokkal támogatott tesztelés után maradtak a rendszerben. Ez azért van, mert egy több millió kód sorból, és akár szerverek, modulok, komponensek tucatjaiból álló rendszert egyszerűen képtelenség teljes mélységben tesztelni.

Laikusok számára furcsának tűnhet, de a komolyabb elterjedtséggel rendelkező szoftvereknek publikus sérülékenységi adatbázisaik vannak, ahol adott esetben ellenőrizni lehet, hogy adott szoftver adott verziója rendelkezik-e ismert hibával. Itt a hibák információt is meg lehet nézni, például a probléma mértéke, típusa, illetve létezik-e ismert támadás rá[3]. Ez egyébként nagy segítség az okos üzemeltetők és biztonsági szakértők számára, másrészt nagy szomorúság azon üzemeltetőknek, akik nem frissítik rendesen a szoftvereiket.

Ezek mellett, szinte valamennyi komolyabb szoftver fejlesztői rendelkeznek hibabejelentést támogató felületekkel, útmutatókkal azokban az esetekben is, ha nem akarnak vagy tudnak fizetni a bejelentőknek. Itt felhasználók, fejlesztők vagy külső tesztelők jelenthetnek be hibákat, minden probléma nélkül.

Alapesetben az IT biztonsági szakértők megbízás alapján, a munkájuk részeként végeznek biztonsági tesztelést. Kutatóintézetek[4] és IT biztonsági cégek[5] kutató munkatársai szintén a munkájuk részeként vizsgálnak elterjedt, nagy fontosságú szoftvereket akár megbízás nélkül is, szakmai és tudományos okokból. A fellelt hibákról tanulmányokat és jelentéseket írnak, és esetenként a javításokban is segítséget nyújtanak. Ezek a szervezetek többnyire felelősen kezelik ezt a tudást. Az itt dolgozó emberek többnyire igen szerencsések, mert a munkájuk a hobbijuk is egyben.

Bizonyos hackerek pusztán szórakozásból keresnek és jelentenek be hibákat. Nyilvánvaló, hogy a bejelentéseket – az esetek döntő többségében – a bejelentő jóindulattal teszi, mivel azt is megtehetné, hogy nem szól senkinek. Az ilyen hibák megtalálása a szervezetek nagy részénél sohasem derülne ki. A motiváció lehet a kíváncsiság, a kibertér biztonságosabbá tétele, bizonyos esetben a pénz, de akár a szakmai hírnév is. Egy komolyabb hiba megtalálása nagy hírértékkel bír szakmán belül, így a megtaláló rövid időn belül nagy ismertséget szerezhet és jó ajánlatokat kaphat.

Nagy probléma, hogy a fejlesztő és üzemeltető szervezeteknél – főleg azoknál, akik nem informatikai területen működnek – sok esetben nincs meg a kultúrája a bejelentések fogadásának, és még inkább elfogadásának. Kétségkívül keveseknek esik jól, ha a munkájukban hibát találnak, különösen ha súlyos hibát, azonban – ha nem vagyunk tökéletesek – akkor ezzel sajnos együtt kell élni. Saját tapasztalataim is megerősítik azt a fordított arányosságot, hogy általában a fejlesztők, az üzemeltetők, és a cégek minél kevésbé biztonságtudatosak, és minél inkább nem végeznek megfelelő teszteléseket, annál rosszabbul viselik a bejelentéseket. Azok, akik a fejlesztés során is nagy figyelmet fordítanak a területre, azok többnyire örülnek, ha valaki etikusan segít nekik a munkájukban.

Fentiek miatt, sok hacker nem is jelenti a megtalált hibákat, mert nem akar problémát magának. Mindezt teszik úgy, hogy a megismert gyengeségeket – azon túl, hogy szakmai közegben esetleg eldicsekszik leleményességével – nem használják fel semmire. 

Hibák etikus és kevésbé etikus bejelentése

A bejelentések során egyébként többféle súlyos hibát is el szoktak követni „etikus” és kevésbé „etikus” hackerek. Az egyik tipikus hiba, hogy a rendszer – engedély nélküli – vizsgálata során túl messzire mennek, és adott esetben adatokat szereznek meg, vagy hozzáférést érzékeny rendszerekhez. Ezzel már tulajdonképpen bűncselekményt is elkövethetnek.

Ilyen esetekre két érdekes példát mutatunk.

Idén áprilisban a T-systems-nek egy másik a BKK botrányhoz hasonló incidense is volt[6]. A rendszerében egy fiatal hacker hibákat talált, majd ezt jelentette nekik. A cég meghívta beszélgetni a srácot, de sajnos nem tudtak megállapodni együttműködésben. A hacker folytatta a vizsgálatokat, és még komolyabb hibákat talált, amiket elmondása szerint szintén nem használt fel, hanem jelenteni akarta a cégnek. Ekkor már valóban, nagy mennyiségű, igen érzékeny adatokhoz is hozzáférhetett volna. A hacker – ha igazak a híradások – nem követte el azt a súlyos hibát, hogy adatokat hozott volna el, és elmondása szerint továbbra is együtt akart működni a céggel. A cég viszont feljelentette őt, az ügye jelenleg is vizsgálat alatt van (a srácot rabosították, illetve informatikai eszközeit lefoglalták). Ebben a helyzetben a céget nem lehet egyértelműen elítélni, mivel vélhetően fenyegetve érezte magát, azonban ez az eset is jelzi, hogy az ilyen helyzeteket nem tudják jól kezelni.

Egy másik, sokkal egyértelműbb példa a következő[7]: 2010-ben N. Attila feltörte a Marriot szállodalánc rendszerét. A hibákat jelentette és „szolgálataiért” állás szeretett volna a cégtől. Bizonyítékként elhozott adatokkal, – többek között személyes adatokkal és kártyaszámokkal – is alátámasztotta kérését, sőt kilátásba helyezte, hogy ha nem tudnak megállapodni, akkor bizalmas adatokat is nyilvánosságra fog hozni! Ezt követően az USA-ba csalták a hackert, majd a repülőtéren letartóztatták. A cselekményért később 30 hónapnyi börtönbüntetést kapott. Talán nem sértek meg senkit, ha emlékeztetek rá: az informatikusok általában nem a magas érzelmi és szociális érzékenységükről és fejlettségükről híresek. Így lehet az, hogy a hacker, talán nem is fogta fel, hogy a tevékenysége mennyire fenyegető lehetett a cég számára.

Levonva a következtetést: míg az első esetben akár egy remek és elhivatott alkalmazottat is nyerhetett volna a cég egy etikusan viselkedő ember személyében, addig a második esetben a cégnek nem volt sok választása az adatok ellopása és fenyegetés erőssége miatt.

Kis érdekességként jegyezném meg, hogy a Marriott az incidens miatt állítólag 1 millió dolláros kárt szenvedett. Talán ez is rávilágít arra, hogy jobb biztonsági fejlesztésekre időben elkölteni 100.000 dollárt, mint utólag 1 milliót.

A hibák részleteinek nyilvánosságra hozatala

Érdekes szempont még a témában, hogy a fellelt hibát és annak részleteit a megtaláló nyilvánosságra hozza-e, és ha igen, akkor mikor. Erre nincsenek írott szabályok vagy törvények, sőt a szakma is igen megosztott ebben a kérdésben. Sokan azt mondják, hogy időt kell adni a cégeknek a javításra. Sajnos azonban még a legnagyobb gyártók is megteszik időről időre, hogy nem javítanak belátható időn belül hibákat[8]. Egy súlyosabb hibánál ez azt jelentheti, hogy a hiba felfedezése és javítása közötti időben a támadók a hiba ismeretében eredményesen tudják kompromittálni az érintett gépeket. Így az érintett rendszerek ebben az időben gyakorlatilag ki vannak szolgáltatva a támadóknak. Fontos, hogy ha az érintettek tudnának a hibáról, akkor bizonyos esetekben képesek lennének kerülő úton, a javítás nélkül is védekezni (pl.: hálózati határvédelmi eszközökkel).

A komolyabb kutatólaborok, illetve ezzel foglalkozó biztonsági cégek általában a hiba felfedezése után jelzik azt a gyártónak, majd bizonyos idő elteltével – általában 3-4 hónap – nyilvánosságra hozzák a hiba részleteit, a „Disclosure Policy”-juk alapján.

A BKK-s példában a fiatal hacker nem sok időt adott a cégnek, mivel egy napon belül nyilvánosságra hozta a hibát és annak kihasználásának módját. Tekintettel arra, hogy ez a hiba nem igazán volt „jól felhasználható” – mindenképpen kellett hozzá egy bankkártya ami visszakövethető, valamint a megszerezhető árú a BKK bérlet, ami lássuk be a nemzetközi szervezett bűnözés fantáziáját még nagy mennyiségben sem igazán mozgatja meg, – így a nyilvánosságra hozatal nem okozott közvetlen veszteséget senkinek. Sőt, a napokban jelent meg a hír, hogy az ügyészség a nyilvánosságra hozatalt közérdekű bejelentésnek minősítette, a fiatalember által elkövetett cselekményt pedig a társadalomra veszélytelennek minősítette – szakmai szemmel nézve is nagyon helyesen – így nem vádolják bűncselekménnyel[9]. Persze meggondolandó, hogy ha a jelzett hiba alapján valaki lopott kártyaadatokkal tömegével vásárolt volna bérleteket, amiket aztán fel is használt volna, akkor is ez lett volna-e az ügy kimenetele.

Komolyabb hibák esetében egy hiba részleteinek azonnali nyilvánosságra hozatala („full disclosure”) akár nagyon komoly kockázat is lehet. Ebben az esetben potenciális támadók tömegei ismerhetik meg a támadási módot, és egy nehéz javítás esetében akár hónapokig is tarthat. Ennek ellenére a gyakori, nem megfelelő gyártói hozzáállás miatt számos olyan szakértő van, akik teljes mellszélességgel kiállnak emellett. Az indoklásuk szerint a felhasználóknak tudniuk kell, hogy milyen fenyegetés leselkedik rájuk. Az ilyen típusú nyilvánosságra hozatal egyik ismert terepe a „full disclosure” levelező lista, ahol 2002(!) óta hoznak nyilvánosságra hibákat. E listára felkerülő hibák néha botrányokat is okoznak. 2010-ben egy Google-s mérnök hozott nyilvánosságra itt egy Microsoft Windows Help and Support Center szolgáltatását érintő sebezhetőséget, mert az MS által javasolt 60 napos javítási határidőt elfogadhatatlannak tartotta[10].

Itt osztanék meg egy igen szélsőséges példát: egy újzélandi hacker, Barnaby Jack[11] az ATM automaták mellett a vezeték nélküli orvosi eszközök (pl.: inzulin pumpa, pacemaker-ek és egyéb szív implantátumok) specialistája volt. 2012-ben demonstrálta, hogy az egyik pacemaker hackelése során akár halálos áramütést lehet okozni a betegnek. Emellett számos hibát detektált, amelyek komoly egészségügyi kockázatokat jelenthetnek. Jack 2013-ban, 35 évesen heroin, kokain, Benadryl és Xanax túladagolásban halt meg, egy héttel a Las Vegasi Black Hat konferencia előtt, ahol hasonló sérülékenységről tartott volna előadást.

Összegzés

Fenti példákból és okfejtésekből látható, hogy egy hiba kezelése, és nyilvánosságra hozatala közel sem egyszerű dolog. Nem lehet azt mondani, hogy a cégek örüljenek és fizessenek, de azt sem, hogy a hackerek minden esetben etikusak. Mint minden területen, a szervezeteknek itt is felkészült szakértőkre van szüksége ahhoz, hogy megfelelően kezeljék ezeket az eseteket. Nagy tanulság továbbá, hogy érdemes az ehhez hasonló eseteket – amennyire lehet – megelőzni, hiszen egy tesztelés nélkül élesbe állított rendszer vélhetően igen hamar támadók célkeresztjébe kerül, és nem biztos, hogy az etikus oldal képviselői lesznek közöttük elsőként. Tanulságos példa lehet, a teljes mértékben etikátlan informatikai támadásra az HBO jelenleg zajló esete. A hackerek a hibák bejelentése helyett nagyon keményen zsarolják a céget az ellopott adatok, filmek, dokumentumok nyilvánosságra hozatalával. Az HBO 250.000 dollárt ajánlott nekik, ők azonban 6 millió dollárt követelnek! Jelenleg a csatorna már nem akar tárgyalni a támadókkal[12]. Az biztos, hogy ha nem is fizetnek, akkor is sokba fog kerülni nekik az incidens.

A hibákat kereső hivatásos vagy műkedvelő szakértők pedig mindenképpen figyeljenek arra, hogy ne lépjék át a határokat! A tevékenységük során próbáljanak igazodni olyan módszertanokhoz, ajánlásokhoz, amelyek biztosítják azt, hogy a viselkedésük ne fenyegető legyen hanem etikus. Nem szabad elfelejteni, hogy a nagyon keskeny ösvényen egyensúlyoznak azok, akik megbízás, illetve szerződés nélkül keresnek hibákat.