Mit nem törhet fel egy etikus hacker, és hogy lehet megélni ebből a szakmából?

Muszáj szerződés a white hat hackerkedéshez? Mi van akkor, ha nyílt forráskódban találunk sérülékenységet? Mi mindent lehet kiszúrni ezzel a módszerrel, és mekkora minderre a kereslet Magyarországon?

A NIS2 uniós irányelv miatt egyre nagyobb szüksége van a cégeknek képzett kiberbiztonsági munkatársakra, köztük etikus hackerekre is – mondja interjúnkban Bőhm Tamás, a Robert Bosch Cybersecurity Lead Engineer munkatársa, rövidesen startoló Etikus hackelés kezdőknek képzésünk előadója. Hangsúlyozza, hogy egy folyamatosan változó környezetben jövőálló szemléletet igyekszik átadni a résztvevőknek.

Ki számít etikus – white hat – hackernek? Csak az, akinek szerződése van egy sebezhetőség tesztelésére, vagy az is, aki feltör valamit, de nem él vele vissza, hanem jelenti a cégnek?

Jó kérdés. Sokan összekeverik, és szeretik romantizálni ezt a szerepet, mondván: az igazi etikus hacker az, aki segíti a közösséget. Ám jogi szempontból az számít etikus hackernek, aki rendelkezik megbízási szerződéssel egy cég irányába arra, hogy a rendszereit tesztelje egy szempontrendszer alapján. Fontos, hogy ennek listázott konkrétumai, követelményei is vannak. Vagyis meg van határozva, hogy mit akarunk tesztelni, és milyen metodológiával. Ennek jogilag is meg kell felelni, olyanról például szó sem lehet, hogy felbérel egy cég arra, hogy egy másikat hackeljek meg. Nagyon komoly és szigorú követelményeket kell betartani.

A lényeg, hogy az etikus hacker az, akinek megbízási szerződése van. Aki a saját szakállára próbál meg feltörni rendszereket – akár szabad-, akár munkaidejében – , de ezekkel nem él vissza, hanem jelenti őket, nos, ilyen példák is valóban voltak Magyarországon is az elmúlt 10 évben is. Ám őket inkább már grey hatnek szoktuk nevezni, azért is, mert az adott cég ilyenkor nem ad hozzájárulást a folyamathoz. Ami a kettő között félúton van, de inkább már a white hat kategória, az a bug bounty. Ez azt jelenti, amikor cégek meghirdetnek olyan programokat, ahol ahelyett, hogy leszerződnének valakivel mondjuk egy penetrációs tesztre, bejelentik, hogy aki a megadott oldalaikon talál valamit, az kap egy bizonyos összeget a sérülékenység súlyossága alapján. De ez a fajta vizsgálat is egy programon és egy meghatározott scope-on belül történik.

A közelmúltban volt két ismertebb releváns ügy is: az egyik a BKK akkori e-jegyrendszerét, a másik pedig a Magyar Telekom informatikáját érintette. Mindkettőnél feljelentették azt, aki jelzett a cégeknek egy biztonsági rést, amellyel nem élt vissza. Utóbbi eset kapcsán a TASZ azt írta, szerintük az etikusság feltétele, hogy a hacker tevékenysége nem veszélyes a társadalomra. Mit gondolsz ezekről az esetekről?

Külön kell választani a dolog etikai és jogi részét. Ha egy rendszerben egy kutató talál egy sérülékenységet, és nem használja ki, hanem jelenti egyből a szolgálatnak vagy a szervezetnek, az szerintem etikailag egy helyes eljárás. Jogilag viszont az illető mégis valaki másnak a rendszereit támadta – még akkor is, ha ez mondjuk a BKK-s ügy esetén egy elég triviális támadás volt. A telekomos ügyet nem ismerem pontosan, de szerintem érthető, ha a cégek ilyenkor nagyon defenzívek lesznek, nem tudhatják ugyanis, hogy aki támadott, az milyen szándékkal jött.

Még ha a sérülékenységet jelezte is a cég felé, lehet, hogy fél évvel előtte eladta a feketepiacon valaki másnak. Tehát ez egy nagyon ingoványos talaj. Szerintem az a jó megközelítés, amit külföldön a nagy techcégek is csinálnak az említett bug bounty programokkal. Ezeknél meg van adva bizonyos sérülékenységekhez egy-egy konkrét ársáv, amilyen összeget kaphat az, aki jelent nekik egy sebezhetőséget. Ez motiváció a kutatóknak is, hogy azokat a területeket teszteljék, amelyek benne vannak a programban, és a cégnek is egyfajta biztosítás, hogy emiatt támadják a rendszereiket.

Az ilyen programokon kívül akkor csak szerződéssel javaslod bárkinek, hogy sérülékenységeket keressen?

Igen, fontos, hogy legyen egy szerződésünk, ha cégeknek, egyéb szervezeteknek ilyen jellegű munkát csinálnánk. Hiszen senki sem akar börtönbe kerülni azért, mert talált egy akár triviális sérülékenységet. Emellett egy ilyen együttműködéssel pénzt is lehet keresni, szóval valamilyen szinten mindkét oldal profitál belőle. Eltérő helyzet azonban a nyílt forráskódú projekteké, amelyek a kódját bárki elérheti az interneten. Ezeket lokálisan, a saját hálózatán mindenki szabadon tesztelheti.

Abból nem lesz jogi probléma?

Nem, hiszen ott nyílt a forráskód, ahhoz hozzáférsz, és hozzá is járulhatsz a fejlesztéséhez. Több ismerősöm, és én is találtam már ilyen projektekben sérülékenységet. Ezt az ember jelentheti a szervezetnek, aki kiadja a nyílt forráskódú terméket, vagy – ha egy kisebb, esetleg közösségi projektről beszélünk – a termék vagy a forráskód könyvtárának a karbantartójának. A GitHubon megvannak erre a különböző mechanizmusok.

Mit tegyünk, ha véletlenül futunk bele egy sérülékenységbe? Inkább maradjunk csöndben?

A szervezet válogatja, mit kezd ezzel. Szokott olyan is lenni, hogy ha találtál egy sérülékenységet, és jelentetted a szervezetnek, akkor kiírnak gyakorlatilag egy privát bug bounty programot, amelyben csak te veszel részt. Ennek keretében valamilyen úton megtörténik a szerződés, így ha utólag is, de mégis lesz egy megállapodásotok arról, amit csináltál. Ami ilyenkor elő szokott jönni, az a responsibility disclosure, magyarul mondjuk úgy: a sérülékenység felelősségteljes publikálása. Ez arról szól, hogy egy sérülékenységet először nem a publikum, hanem a szervezet felé tárunk fel.

Bőhm Tamás több mint 6 éve dolgozik etikus hackerként, jelenleg a Robert Boschnál vezető kiberbiztonsági mérnök, és egy saját penetration testing szolgáltatás felelőse. Korábban vizsgált banki és autós rendszereket, webalkalmazásokat, és gyártósorokat is. Csapatával a DEFCON Car Hacking Village hackerversenyen harmadik helyezést értek el.

Ők megmondják, hogy nagyjából mikorra tudják kijavítani, mikorra landol a frissítés mondjuk a felhasználók 80-90%-ánál, és akkor azután mondjuk egy héttel publikálhatják a sérülékenységet. Hiszen általában a biztonsági kutató is szeretne ebből valamennyi hírnevet, renomét. Vannak, akik szeretik a káoszt, és azt mondják, hogy ilyen az élet, tessék, itt a sérülékenység, és kiposztolják az X-re, megjelölve mondjuk a Windows fiókját. De én azt mondom, hogy inkább próbáljuk meg a saját érdekünkben a jogi keretek között tartani ezt a munkát, mert mindenkinek az az egyszerűbb.

Milyen célokra lehet használni ezt a módszertant?

A határ a csillagos ég. Vannak penetration testerek, akik egy rendszert a megadott keretek között vizsgálnak. Továbbá vannak az etikus hackerek, akik emellett még social engineering vagy open source intelligence (OSINT) technológiákat is alkalmaznak. Bár az OSINT a scope-tól függően a penetrációs teszteknél alapból megjelenhet, a social engineering módszertanát már az etikus hackerek használják. Egy még eggyel tágabb fogalom a red teaming, akik már a fizikai biztonságot és a social engineeringet is tesztelik – például hogy miként tudsz belépni egy épületbe úgy, hogy elhiteted valakivel, hogy mondjuk szerelő vagy. Egy etikus hacker munkájában gyakorlatilag minden kihasználható technikai sérülékenység valamilyen módon előjöhet. Nyilván ez attól függ, az ember hogyan választ célpontot. Egy webes alkalmazáson például nehezebben fogunk olyan sérülékenységet találni, mint egy vastag kliens, azaz egy, a lokális gépeden futó szoftver esetén. Bár ki tudja.

Mennyiben mások a lokális és webes sérülékenységek?

A lokális szoftvereknél az operációs rendszerek saját védelmi mechanizmusai megnehezítik a sérülékenységek kihasználását. Így valószínűleg a webes, illetve a cloud irányban a leggyakoribbak a sérülékenységek. Vannak olyan rendszerek is – mint például a gyárak és raktárak által használt Operation Technology (OT) –, amelyek néha gyárilag sérülékenyek. Nem azért, mert ez volt a cél, de egyszerűen olyan kevés számítási kapacitással rendelkeznek, olyan régi és elavult rendszerek, hogy amikor készültek, még nem volt lehetőség, illetve tudás, hogy azokba egy modernkori biztonsági mechanizmust beépítsenek.

A webes, illetve cloudos alkalmazások kapcsán az OWASP-nak van egy top 10-es listája a leggyakoribb sérülékenységekről. A legfrissebb verzióban eléggé feltörekvő a business logic, vagyis a nem technikai, hanem logikai sérülékenységek köre. Magyarországon is a BKK-botránykor az volt a hiba, hogy nem volt szerveroldalon validálva, amit a felhasználó beküld. Magyarán elhittek bármit, amit a felhasználó beküldött. A webes kommunikáció során van ugyanis egy kérés, és arra egy válasz. Ebben az esetben például a felhasználó küld egy kérést, amelynek a body részében szerepel például, hogy egy bérlet ára mondjuk 5000 forint. Ha a szerver ellenőrzés nélkül elhiszi, hogy az 5000 forint, abból nagy probléma lehet, hiszen akkor a felhasználó átírhatja egy forintra is.

Az elhíresült eset során is ez történt. Ez azért probléma, mert a felhasználónál, az ő saját gépén bármit lehet módosítani. Ezért szerveroldalon meg kell vizsgálni a beküldött adatokat. A másik gyakori hiba az IDOR (Insecure Direct Object Reference, nem biztonságos közvetlen objektumhivatkozás). Ez arról szól, hogy miként érjük el a különböző fájlokat online. A legtöbb esetben valamilyen azonosítással, például egy biztosító cégnél a saját szerződésedet csak te tudod elérni, a felhasználónevedet és a jelszavadat megadva. Ugyanakkor lehetnek olyan módszerek is, ahol ha az ember tudja a nevét a fájlnak, amit el szeretne érni, akkor megnyithatja mondjuk ezen adatok megadása nélkül is. Például beírja az URL-címét. Ez mondjuk úgy történhet meg, hogy valakinek a sütije, amiben a munkamenet-azonosítója benne van, az valid, hiszen ugyanannál a biztosítónál ügyfél, ahol te is. Sok rendszer ugyanis csak azt nézi, hogy az illető valid felhasználó-e, azt pedig már nem, hogy a saját PDF-jét igyekszik-e megnyitni.

Mi volt a legerősebb, legizgalmasabb, legsúlyosabb dolog, amit a munkád során az etikus hackeléssel sikerült feltárnod?

Sok minden volt technikailag nagyon szép és jól összerakott, amikor kombinálva lettek különböző sérülékenységek, és abból állt össze egy kihasználási útvonal. Nem is emelnék ki egyet, de amikor több különböző sérülékenységet rakunk össze, és abból áll össze egy kódfuttatás, azok a legszebbek. Esetleg az említett IDOR például még figyelemre méltó dolog lehet, ezeket azért mégis kiemelném. Nyilván, ha az ember kis teljesítményű eszközöket – mint egy router, vagy hasonló beágyazott eszközök – tesztel, ott ezek sokkal gyakoribbak, hiszen nincs elég számítási kapacitás ahhoz, hogy minden biztonsági mechanizmus megfelelően legyen implementálva.

Meg lehet-e élni az etikus hackelésből, van-e ennek idehaza piaca, elfogadottsága?

Szerencsére egyre jobban elfogadott. Én 2019 óta dolgozom etikus hackerként, már akkor is eléggé az volt, de mostanra ez különösen igaz. Bejött a NIS2 EU-s irányelv, amely kötelezi a cégeket, hogy időközönként penetrációs teszteket, etikus hackelési folyamatokat hajtsanak végre. A NIS2 ugyanis előírja a vállalatoknak, hogy megfelelő kiberbiztonsági folyamatokat és követelményeket alakítsanak ki a saját szervezetükön belül, illetve azt is, hogy milyen kötelezettségeik vannak az állam, esetünkben a Nemzeti Kibervédelmi Intézet felé. A penetrációs tesztek mellett minden esetleges támadást 24 órán belül jelenteni kell az intézetnek. Azt nem tudom, hogy az irányelv miatt több etikus hackert alkalmaznak-e Magyarországon – a tapasztalataim alapján a jelenlegi munkaerőpiac nem a legfényesebb –, de biztosan van egy növekvő tendencia.

Ezek nem olcsó dolgok. Egy etikus hackelési vizsgálat nagyon drága tud lenni, hiszen szakképzett munkaerő kell hozzá, és egy hosszú folyamatról beszélünk – általában úgy egy hétig tart egy normál méretű webes alkalmazás esetén, és ez nyilván a célponttól függően változik. Szakképzett munkaerőre mindig lesz igény. Kérdés, a növekvő igény mennyire látszik majd meg a fizetéseken is. Ugyanakkor az IT területén belül a biztonságtechnika mindig is egy egészen jól fizetett területnek számított, ugyanakkor viszonylag sokat is kell érte dolgozni.

Kiknek szól a kurzus, és mi lesz a fókusza?

Elsősorban kezdőket várnék, a tananyag fókuszának pedig két dolgot jelöltem ki: adok 2025-re egy képet arról, mik az etikus hackelés pillanatnyi alapjai, emellett viszont nem feltétlenül azt szeretném átadni, hogy éppen most milyen sérülékenységeket hogyan lehet megtámadni, hanem azt a szemléletet, amellyel ezt a munkát végezni lehet a jövőben is. Az etikus hackelés ugyanis nem egy olyan szak, amit egyszer megtanulunk egyetemen vagy valahol, utána pedig ülünk ezen a tudáson 10-20 évig, hanem folyamatosan változik. Szinte naponta jönnek új támadási technikák, sérülékenységek, a kliens pedig elvárja, hogy ezeket már másnaptól tudjuk is tesztelni.

Ez egy nagyon gyorsan fejlődő szakma, ha az ember nem csinálja egy-két évig, akkor azért kell valamennyi idő, amíg újra kell tanulnia bizonyos dolgokat, amik azóta megváltoztak. Így pont ezt a jövőállóságot szeretném kiépíteni a résztvevők számára. Persze az etikus hackerré válás egy többéves folyamat, nem lehet mindent megtanulni 16 alkalom alatt. A kiberbiztonság területén egyébként is jellemzően nagyon kevés a junior, mert szerteágazó tudásra van szükség, sok mindent kell egyszerre ismerni, hogy az ember átlássa a rendszerek működését, és rengetegféle projekt jön. Szóval lehet, hogy az egyik nap még webes alkalmazást kell tesztelni, másnap pedig már egy autóban ülünk, és annak a működését próbáljuk végig. Így ehhez a változékony szakmához egy jövőálló szemléletmódot kínálok, amellyel a résztvevők el tudják dönteni, merre folytatnák a megkezdett utat az etikus hackelésen belül.

Ennek a területnek ugyanis rengeteg leágazása létezik, amelyeket külön meg kell tanulni, amerre tovább lehet menni. Ha pedig valaki esetleg közben rájön, hogy neki mégsem az etikus hackelés jön be, de egyébként dolgozna a kiberbiztonság területén, akkor fontos kiemelni, hogy ez egy hatalmas terület. Az etikus hackelés egy niche része az iparágnak, emellett még sok egyéb munkakörben is szükség van rengeteg szakképzett munkaerőre. Ilyen a security architect, aki a biztonsági rendszereket rakja össze, az SOC analyst, aki a különböző incidenseket elemzi, vagy a kiberbiztonsági mérnök, aki a különböző rendszereket implementálja. Szóval aki nem feltétlen csak kódolna, hanem ezt a biztonsági vonalat vinné, biztos vagyok benne, hogy valahol megtalálja a helyét.

Szerző: Tarnay Kristóf Ábel

Megosztás: