A cikk előző része elérhető itt.

Talán számos laikus számára furcsának tűnhet, de sok esetben az informatikai gyártók bejelentik a hibáikat. Ezen hibák nyilvántartására publikus sérülékenységi adatbázisok állnak rendelkezésünkre, például a cvedetails weboldal is ezt a célt szolgálja. Látható, hogy az 50 legnagyobb gyártó milyen sok termékéhez hoz nyilvánosságra hibabejelentéseket[1]. Természetesen ilyen esetekben a fejlesztők a saját termékeikhez nem hoznak nyilvánosságra olyan technikai részleteket, ami alapján támadó kódot lehetne írni az alkalmazáshoz, főleg a hiba javítása előtt. A hiba javítás után, a támadó nem fogja tudni eredményesen támadni azokat, akik a biztonsági frissítést telepítették. Azonban ahogy Anti bácsi mondja a Besenyő családban: „itt van a kutya elesve”. Meg kell jegyeznünk, hogy gyakran lehetséges egy meglévő javítás elemzésével visszafejteni a hiba lényegét és utólag készíteni hozzá támadó kódot[2], akkor is, ha a gyártó nem adott meg minden információt. Sajnos szoftverek milliói nincsenek frissítve az interneten, így belátható, hogy egy motivált támadónak érdemes még a javítás után is vesződni a feladattal egy megfelelően elterjedt szoftver esetében. 

Elsősorban ez az oka annak ami miatt a szállítók nyilvánosságra hozzák a hibákat. Ez egy figyelmeztetés a felhasználók és üzemeltetők felé, hogy ideje frissíteni! Sőt, adott esetben ez más gyártók számára is jelzés: a Google például havi rendszerességgel közli az Android hibákat, amely a telefongyártóknak (is) szól – akik egyébként sajnos sokszor még a kritikus hibákat sem javítják időben. Ezek a bejelentések más iparágból vett analógia szerint hasonló ahhoz, amikor az autókat visszahívják a gyárba javításra, csak itt a javítást helybe tudják vinni.

 

A hibabejelentések minden esetben tartalmazzák azt az információt, hogy mire vonatkozik a hiba (szoftver, modulok, verzió), milyen súlyos a probléma, és hogy elérhető-e a javítás. Ezen információk nagyon fontosak a felelős üzemeltetők számára. Bizonyos esetekben arra az időszakra is létezik védekezés, amíg a gyártó még nem javította ki a hibát. Ebben az esetben hálózati határvédelmi eszközök, vírusvédelmi eszközök vagy egyéb biztonsági szoftverek védhetik a hibás programot a javításig. Súlyos problémák esetében bizonyos biztonsági szoftver gyártók törekednek is arra, hogy mielőbb védelmi megoldást nyújtsanak. Sőt, olyan szoftverek is vannak, amelyek kifejezetten bizonyos támadási mintákra fókuszálnak, függetlenül attól, hogy az általuk védett hálózat milyen elemeket tartalmaz.

A gyártói hibabejelentésekhez hasonló, amikor a hibákat a rendszer felhasználói jelzik. Ennek egy „minősített” esete, amikor a felhasználó maga is szoftver gyártó. Ilyen esetben arra kell gondolni, hogy a legnagyobb szoftvergyártók sem képesek arra, hogy minden szolgáltatást saját szoftverekkel nyújtsanak. Szinte minden esetben használnak úgynevezett harmadik féltől származó komponenseket. Ebben az esetben nyilvánvaló, hogy ezen szoftverek biztonsága a nagy gyártóknak (akár a Google, Apple, FB, MS, …) is nagyon erős érdeke. Ezen cégek rendelkeznek a megfelelő szaktudással, illetve erőforrásokkal, hogy a rendszereik tesztelése közben a külső komponenseket is megvizsgálják. Elsősorban nyílt forráskódú komponensek esetében, hibajavításokat is készítenek, vagy támogatják azok elkészülését. Példaképpen említeném az OpenSSL projekt ismert hibáit. Ez egy olyan titkosítási algoritmusokat és protokollokat megvalósító szoftver, amely nagyon sok más termékbe került beépítésre. Az elmúlt években a szoftverben számos súlyos hiba derült ki[3], amelyek a legnagyobb gyártókat is érzékenyen érintették. A Google például azzal támogatta a szoftver biztonságosabbá tételét, hogy jutalmakat írt ki azoknak, akik hibákat javítanak elterjedt szoftverekben[4].

Kiemelném, hogy míg az előző cikkemben említett példák esetében legtöbbször kétséges volt a hibák keresésének és nyilvánosságra hozatalának megfelelősége, sőt adott esetben törvényessége, addig ebben a fejezetben ismertetetteket nyilvánvalóan senki nem gondolja üldözendőnek.

Itt jegyeznénk meg, hogy ebben a formában mindenképpen van jogosultsága annak, hogy adott esetben egy hiba bejelentése valóban közérdekű bejelentés, hiszen a felhasználók így képesek lehetnek védekezni. A hibák elhallgatása pedig egyértelműen gyengíti a biztonságot.

A hibák kezelésének evolúciójában nagy szerepet játszott a szabad, nyílt forráskódú szoftverek elterjedése. Ezek olyan szoftverek, amelyeknek a működést leíró, úgynevezett forráskódjuk bárki számára elérhető és megismerhető[5]. A forráskód emberi szem számára is jól értelmezhető, és amennyiben a fejlesztő ismeri a nyelvet, úgy pontosan tudja, hogy a szoftver mit csinál. Másrészt, ha valaki veszi a fáradtságot és átnézi a kódot, akkor akár hibákat is találhat. Bizonyos típusú könnyen felismerhető hibákat automata hibakereső eszközök is képesek megtalálni. A nyílt forráskódú szoftverek esetében – fentiek miatt – soha nem is volt kérdés az elmúlt évtizedekben, hogy minden hibát nyilvánosságra hoznak, és a fejlesztői közösségek igyekeznek mielőbb kijavítani azokat (hiszen egyből ismertek a technikai részletek is). Emiatt nem véletlen, hogy ezekben a rendszerekben a szoftverek és a frissítések kezelése messze megelőzte a kereskedelmi termékek hasonló funkcióit.

E kérdésnél érdemes eltűnődni azon, hogy a zárt forráskód előnyt jelent-e a nyílt forráskóddal szemben. A több évtizedes tapasztalat az bizonyítja, hogy nem, mivel a forráskódok átvizsgálása legtöbbször sokkal nehézkesebb, mint egyéb hibakeresési technikák megvalósítása, így a forráskód ismerete – a tapasztalatok szerint – nem eredményezi lényegesen több hiba megtalálását. Egy megfelelő fejlesztői bázissal rendelkező nyílt forráskódú fejlesztés, legalább olyan kódminőséget garantál, mint egy jó kereskedelmi szoftverfejlesztés. Sőt sok szakember előnynek tartja a nyílt forráskódot, mivel ezeket a szoftvereket így sokkal több etikus biztonsági szakértő és fejlesztő vizsgálhatja meg, mint egy zárt fejlesztői közösség által végzett fejlesztést.

Itt említeném meg, hogy minden IT biztonsági kérdésben tévút arra építeni a biztonságot, hogy bizonyos adatokat (pl.: forráskódot, algoritmus leírást, stb.) huzamosabb ideig titokban tudunk tartani, biztosan meg tudunk védeni. Az erről szóló elvet, a kriptográfia területén, már 1883-ban kimondta Auguste Kerckhoffs[6]. Eszerint egy titkosító rendszerben csak a kulcs lehet titok (ami viszonylag könnyen cserélhető), és az eljárás matematikai erősségének kell biztosítani a biztonságot. Nyilvánvaló, hogy az algoritmusok, forráskódok megszerzésére rengeteg mód van (ellopják, megveszik, megzsarolják, elrabolják, …). Ha azt gondoljuk, hogy azért biztonságos egy rendszer, mert a támadók nem ismerik a technikai részleteit, akkor keserű csalódásban lehet részünk. Ezt támasztja alá az is, hogy nem kell sokat keresnünk, hogy ilyen incidenseket találjunk. Idén például a Windows 10 esetében került ki tömegével forráskód[7].

Fentiek egyértelműen igazolják a hibák kutatásának, bejelentésének és nyilvántartásának létjogosultságát.

Az előző cikkben többek között a T-BKK incidens kapcsán elemeztük a bejelentések etikusságát. Ebből adódóan érdemes elemeznünk azt, hogy biztonsági szakemberek, a biztonsági hibákat és sérülékenységeket on-line és off-line is kereshetik.

On-line hibák keresése esetében a vizsgálat a hálózaton keresztül zajlik. Ennek minden esetben nyoma van a hálózaton. Ekkor a vizsgált rendszer üzemeltetői – ha ügyesek és szakmailag felkészültek – láthatják, hogy a rendszerükben éppen történik valami szokatlan. Megfelelő hálózati határvédelmi eszközök adott esetben riasztásokat is adnak, amennyiben ilyen tevékenységet észlelnek. Abban az esetben, ha az üzemeltetés észrevesz ilyen cselekményt, kétféle kimenet lehetséges. 

Amennyiben éppen egy megbízás alapján történő etikus hacking vizsgálat van folyamatban – ezt azonosíthatják a szerződés és a vizsgálat forrása alapján – akkor az üzemeltetés hagyja a vizsgálat folytatását. Érdekességképpen megjegyezzük, hogy vannak olyan munkák, ahol az etikus hackerek meghatározott feladata, hogy minél észrevétlenebbül teszteljenek, éppen azért, hogy az üzemeltetési módszerek és készenlét is tesztelésre kerüljön. A vizsgált szervezet vezetése természetesen ebben az esetben tud a vizsgálatról, azonban az üzemeltetők nem.

Amennyiben azonban nincs éppen etikus hacking vizsgálat, akkor az üzemeltetés egyértelműen támadásnak minősítheti az esetet, és megteheti a szükséges lépéseket. Ez a támadás technikai megállításától – források kitiltása, rendszerek lezárása, stb. – a jogi lépésekig (feljelentés) is terjedhet. Ebből látszik, hogy egy jól védekező szervezet esetében nem nagyon fordulhat elő online rendszereknél egy megbízás nélküli, jószándékú tesztelés és hibabejelentés. 

Sajnos a szervezetek nagy része nem védekezik olyan szinten, hogy ezeket a teszteléseket észrevegye. Ennek megfelelően igen furcsa helyzetet eredményezhetnek, amikor komolyabb hibákat jelentenek be jószándékú hackerek a szervezetnek. Ebben az esetben általában károkozás egyáltalán nem történik, azonban illetéktelen hozzáférés néha igen. Másrészt mivel a tesztelőnek sikerült érzékeny hibát felderítenie, így többnyire nem számíthat a szervezet üzemeltetőinek jóindulatára, hiszen azok igazoltan hibáztak (egyrészt megvolt a biztonsági rés, másrészt nem vették észre a tesztet). Ebből látható, hogy egy olyan helyzetben kell etikáról, adott esetben törvényességről beszélni, ahol egyik szereplő sem viselkedik hibátlanul, így nyilván sok tényezőt lehet mérlegelni. Egy biztos: egy hibabejelentés szinte minden esetben jobb a szervezetnek, mintha egy bűnözői csoport találna hibát a rendszerben.

Érdemes egy olyan esetet megemlíteni, ahol úgy lehet egyértelműen hibát detektálni, hogy sem károkozás, sem illetéktelen hozzáférés nem történik. A hálózati szolgáltatások és a kliens programok történelmi okokból elég gyakran, a szolgáltatás nyújtása közben, mintegy kiegészítő adatként „bemutatkoznak”. Az átküldött adatokban szépen beleírják, hogy ők milyen szoftver, milyen verzióval, sőt adott esetben a telepített komponensekről, rendszerelemekről is adnak információt. Például, amikor megnézünk egy weboldalt, akkor alapesetben a böngészőnk elküldi ezeket az adatokat (milyen operációs rendszer, milyen böngésző, mely verziója, gyakran a nyelvi beállítások, stb.), amire a válaszoló webszerverek is többnyire küldenek ilyen információkat – persze pont ezért ajánlott ezt a funkciót tiltani. Ennek vizsgálatához gyakorlatilag semmire sincs szükség, ez teljesen nyíltan benne van a forgalomban. Ennek megfelelően, ha a felhasználó megszólít egy szolgáltatást, akkor már a válaszból láthatja, hogy milyen szoftver van a túloldalon. Így, ha az verziószám alapján egy elavult, régen nem frissített, ismert hibákkal rendelkező szoftver verziót találunk, akkor minden kutatás és tesztelés nélkül tudhatjuk, hogy az adott szolgáltatás sebezhető. Ebben az esetben úgy tudunk hibát bejelenteni, hogy sem károkozás, sem illetéktelen hozzáférés nem történt. Persze a szervezetben – főleg az üzemeltetési területen – többnyire nem fognak örülni ennek, mivel ebben az esetben az üzemeltető hanyagsága vagy hozzá nem értése egyértelmű.

Az előző cikkből teljes mértékben kimaradt annak ismertetése, hogy informatikai hibákat off-line is lehet keresni. Egy operációs rendszer, egy böngésző vagy egy irodai szoftver esetén a tesztelő (legyen bármi is a szándéka) a saját infrastruktúráján telepített szoftvereket vizsgál. Ezt nyilvánvalóan senki nem tudja detektálni.

Természetesen nagyon sok hálózati szoftvert is lehet ilyen körülmények között vizsgálni, amennyiben képesek vagyunk ezeket egy saját környezetben felépíteni. Ilyenformán egy ismert weboldal keretrendszer telepítése és vizsgálata sem lehet akadály. Sőt számos kereskedelmi termékből is a tesztelő vehet egy példányt, és amit majd a saját környezetében, számos módon tud tesztelni. 

Amennyiben a támadó/tesztelő egy cég hálózatának szoftveres felépítéséről információkat szerez, akkor képes lehet egy saját teszt környezetben felkészülni erre. Az információszerzés sok esetben nem is olyan nehéz, mint gondolnánk, kezdve a szervezetek dokumentumaiban figyelmetlenségből kikerülő információktól, az informatikai vezetők által különböző konferenciákon megtartott előadásokig. Ezek sok esetben remek források a támadók számára.

Az offline tesztelés lehetősége a beépített szoftverekkel rendelkező hardverekre is megvan, legyen az akár egy wi-fi router, vagy egy okos porszívó. A tesztelő megvásárolja az eszközt és otthon azt csinál vele, amit akar, illetve amit tud.

A vizsgálatok során a szakértők kezében számos lehetőség áll rendelkezésre, kezdve az eszköz működésének visszafejtésétől, az általa generált hálózati forgalom elemzésén keresztül, a különböző automata vagy kézi tesztelési módszerekig.

Fentiekből látható, hogy ez a terület sokkal rejtőzködőbb, mint az online hibakeresések. Itt sokkal markánsabban elkülönülhet az etikus és az etikátlan viselkedés, tekintettel arra, hogy az etikátlan viselkedés történetét nagy valószínűséggel meg sem tudjuk, mivel ezt nem hozzák nyilvánosságra. Ezek az esetek úgy derülnek ki, hogy megjelenik a hálózatokon egy támadó kód, amely eddig nem ismert hibát használ ki (lásd például az év eleji zsarolóvírus támadásokat[8]). Ilyen esetben valaki elkészítette hibán alapuló támadó kódot, és vagy eladta a feketepiacon, vagy ő maga valósította meg a támadásokat. Nyilvánvaló, hogy ilyen típusú, rejtett hibakereséseket folytatnak bűnözői csoportok, hacktivista csoportok, és állami hírszerző szolgálatok is.

Az offline hibakeresési módszerrel fellelt hibák esetében a gyártóknak, vagy a nyilvánosságnak szóló bejelentések többnyire etikusnak tekinthetők. A hibabejelentő nincs semmilyen módon arra kényszerítve, hogy ismertesse a hibát bárkivel, így megtehetné, hogy rosszra használja. Persze ebben a kérdésében a hibabejelentés módja, a kiadott információk minősége és a nyilvánosságra hozás ideje árnyalhatja az etikusság „szintjét”. (Erre az előző cikkemben hoztam példákat.)

Kérdésként merülhet fel, hogy miért foglalkoznak etikus hackerek ilyen típusú hibakereséssel. A legegyszerűbb ok, hogy biztonsági cégek, illetve nagy gyártók megbízásából egyszerűen a munkáját végzi a szakértő. További valós motiváció, hogy az általuk használt eszközöket, szoftvereket megvizsgálják biztonsági szempontjából, hiszen adott esetben ők is felhasználói a termékeknek. Másrészt a biztonsági tanácsadási iparban a hitelesség múlhat azon, hogy egy tanácsadó csak olyan terméket ajánl, amiben maga is megbízik, ezt pedig vizsgálat nélkül nem megy.

Illetve vannak olyan szakértők, akiknek ez pénzkereseti lehetőség, mivel egyes biztonsági cégek, legális keretek között, szerződést kötve vesznek informatikai hibákat , illetve az előző cikkben is említett bug bounty programok is fizetnek ezekrét (pl.: FB , Google ).

Napjainkban az interneten zajló kiber-háborús helyzet miatt bizony számos termék megbízhatósága kérdőjeleződött meg az elmúlt időszakban. A véletlen hibák mellett sajnos számíthatunk a biztonság szándékos gyengítésére is. Ez 15 évvel ezelőtt kicsit paranoiás gondolatnak tűnt, de azóta az idő messzemenően igazolta ezt. Az elmúlt 5 évben tömegével buktak meg szoftver és hardvereszközök azzal, hogy beépített hátsó ajtót (úgynevezett „back door”-t ) tartalmaztak. Csak egy rövid válogatás: D-Link routerek 2013 ; CoolReaper és számos egyéb kínai okostelefonok 2014-ből   ; Juniper hálózati eszközök 2015 ; Allwinner eszközök 2016 ; de a Microsoftnak már 2007-ben volt a Juniper-hez hasonló esete . Ezek a problémák sosem derültek volna ki, ha nem lennének olyan etikus hackerek, fejlesztők és biztonsági szakértők, akik hibákat keresnek az informatikai termékekben.

Fentieknek megfelelően hazánk kibervédelmi helyzete azon is múlik, hogy az államigazgatási szervezetek, a kritikus infrastruktúra elemek, illetve a gazdasági társaságok milyen hardvereket, szoftvereket használnak, és milyen szaktudású informatikai biztonsági szakértők állnak a rendelkezésükre.

A hibakeresés – minden etikai megfontolás mellett – valamint a hibák nyilvántartása és kezelése szükségszerű eszköze a biztonság fejlesztésének. A hibák keresésének tiltása azon kívül, hogy gyakorlatilag lehetetlen, még módfelett káros is lenne. Ezzel szemben ajánlott lenne a hazai IT fejlesztési, üzemeltetési és IT biztonsági képességek ilyen irányú fejlesztése is. Ezt akár már a középiskolában meg kellene kezdeni.

Mindenképpen érdemes lenne a hazai IT kultúrában kialakítani azokat az eljárásokat, amelyek azt eredményezik, hogy egyrészt megfelelő, szabványos és egyértelmű módon lehessen bejelenteni a hibákat, másrészt a hibabejelentéseket megfelelően kezeljék a szervezetek. Persze a helyes eljárás mindig a konkrét esettől függ. Az elmúlt időszak hazai incidensei miatt remélhetően előremutató szakmai diskurzus indul el a területen.