Bug bounty programok keretein belül etikus hackereink számos sérülékenységet fedeznek fel ügyfeleink számára. A kézhez kapott riportok segítségével lehetőséget kapnak kijavításukra, ezzel biztosítva a támadható felületek csökkentését.

Ügyfeleink között tudhatunk logisztikai céget, elektronikus aláírást biztosító vállalatot, alapítványokat, startup-okat, utazási oldalt, jogi tanácsadást kínáló irodákat. Ebben a bejegyzésünkben megosztunk Veletek néhány IT biztonsági sérülékenységet, melyek ügyfeleinknél már felmerültek. 

Mikor gondolkodnak el az ügyfelek az IT biztonság felmérésének lehetőségén? 

Jellemzően 3 lehetséges esetet különböztetünk meg: 

• Valamilyen külső kényszer hatására kell az IT biztonsági vizsgálatot elvégezni, az állapotot felmérni. Ez általában törvényi megfelelőséget jelent, pénzügyi szervezeteknél az MNB, mint felügyeleti szerv nyomására, közműveknél szintén törvényi kényszer (2013. évi L törvény, 41/2015 BM rendelet). 

• A második eset, ha támadás történik és anyagi kár keletkezik. Ebben az esetben a vállalat megérzi a probléma (veszteség) miatt az IT biztonság fontosságát. 

• A harmadik lehetőség, amikor egy szerződésnél a másik fél elvárja az IT biztonsági feltételek teljesülését, ennek hiányában pedig nem szerződik. 

Tapasztalataink szerint az operáció, a napi működés nagyon sok erőforrást felemészt. IT biztonsági felmérésre csak akkor fordítanak a cégek erőforrást, ha ezt valami kikényszeríti. 

A jövőre nézve azt gondoljuk, hogy az egyre több támadás miatt a cégek minimum 2 évente fognak belső és külső auditokat végeztetni, hogy az IT biztonság megfelelő legyen. Az elszenvedett kár nagysága (üzleti veszteségek az IT biztonság hiányosságai miatt), és a bírságok lehetősége jó irányba tereli a cégvezetőket, és egyre többen különítenek majd el anyagi forrásokat erre a célra. 

Az IT biztonság felmérésének általában ki a kezdeményezője?

Ha egy cégnél van külön IT biztonsági felelős akkor Ő, más esetben az IT igazgató, az operációs vezető, esetleg compliance-el foglalkozó munkatárs. 

A felelősség azonban mindig a menedzsmenté, hiszen ők ismerik a legjobban a cég profilját, nekik kell tudni és forszírozni a vizsgálatokat, amennyiben szükségesek.  Így tehát, valamelyik felső vezetőnek kell ezzel tisztában lennie és kezdeményeznie a vizsgálatot. 

A gyakorlati kezdeményezés legtöbbször nem a hirearchia csúcsáról érkezik, de az irányvonalak ott kerülnek meghatározásra. Fontos, hogy az üzlet tisztában legyen azzal, hogy a vizsgálatok elvégzése szükséges.

Jellemzően milyen IT sérülékenységekkel szembesülnek az ügyfelek?

Általában olyan hibák merülnek fel, melyek megtalálhatóak az OWASP top 10 sérülékenységek listáján. Gyakori a különböző session ellenőrzési és lejárati folyamatok hiánya, de gyenge jelszó irányelvvel is találkoztunk már.

Melyek azok a sérülékenységek, melyek egy kis magyar webshopnál jellemzően előfordulhatnak? 

A bug bounty program előnye a „több szem többet lát” lehetőségnek köszönhetően, hogy az egészen apró hibák is feltárásra kerülnek. Természetesen először a legkockázatosabb sérülékenységekre utaznak a bug vadászok, úgyhogy a már említett OWASP top 10 sérülékenységeket mindenképp a program elején találják meg a sérülékenység szakértőink. Ezek után következnek a logikai hibák az alkalmazásban, például a kedvezmény kupon kihasználása.

A sérülékenységek felfedezése után, ügyfeleink riport formájában kapják meg a talált bugokat, és a hozzájuk tartozó javítási lehetőségeket. A gyengeségek között is vannak könnyen orvosolható, illetve komplexebb, összetettebb, nehezebben javítható hibák.

Gyorsan javítható: Az interneten „kint felejtett” CONFIG fájlok eltüntetése a leggyorsabban orvosolható sérülékenység. Ezek felfedezése és megoldása is nagyon gyors folyamat, csupán pár kattintással megoldható. 

Nehezebben javítható: A nehezen orvosolható sérülékenységek azok, melyek jelentős anyagi áldozatokkal járnak. Ezek általában az EOL (End of Life) rendszerek (adatbázis kezelők, operációs rendszerek, alkalmazások), melyek tele vannak sérülékenységgel, de lecserélésük munkaállomások és szerverszámok függvényében komoly tervezést és erőforrás befektetést kíván. 

A gondokat még fokozza, ha olyan szoftvert használ a cég az üzleti célok megvalósításához, melyek csak EOL rendszereken futnak. 

Problémás továbbá a nem megfelelő kriptográfia használat (gyenge titkosítási algoritmus SHA-1 és régebbi megoldások, TLS 1.1 és régebbi megoldások, nem megfelelő salt, és alacsony iterációs szám hash képzésnél (jelszó tárolásnál lehet gond). 

Ezeken kívül nehezebben kezelhető még:

–       az adatbázis szolgáltatói portok publikus elérhetősége,  

–       nem megfelelő tűzfal konfiguráció, 

–       rossz IPS és IDS beállítás. 

Összességében megállapítható, hogy a jelentős fejlesztői erőforrásokkal vagy ügyfél oldali beruházással javítható sérülékenységek a legnehezebben orvosolhatók.

Mennyi kárt okozhat egy bizonyos típusú sérülékenység?

A sérülékenységek tudatában kockázatelemzés alapján kell a cégeknek meghatározni milyen kárt szenvedhetnek el. Attól is függ, hogy a támadó mekkora kárt akar okozni vagy mennyi váltságdíjat kér a megszerzett információkért cserébe. 

Alapjában véve a lentebb olvasható sérülékenységekkel számolunk (persze ezek csak a fő kategóriák), melyeket a cégeknek saját magukra vetítve számon kell tartani, és saját maguk üzleti folyamatait figyelembe véve rangsorolni, költséghatékonyság elemzést lefolytatni, hogy milyen kontrollok kerüljenek alkalmazásra. 

Tehát meg kell állapítani, hogy rájuk nézve mi a bekövetkezési valószínűsége és a becsült károkozási képessége az adott sérülékenységnek. Ezen kívül az OWASP top 10 sérülékenységeket sem árt figyelembe venni, melyek az alap kategóriákkal átfedésben vannak.

A kategóriák pontos meghatározása érdekében a Nemzeti Közszolgálati Egyetem tananyagát használtuk fel: 

Information Disclosure (információ kitakarás): Minden olyan típusú hiba ide tartozik, amely valamilyen többletinformációt szolgáltat egy támadónak, amelyet felhasználhat egy későbbi támadáshoz. Ha egy támadó a szerver válaszaiból pontosan meg tudja határozni, hogy milyen típusú, illetve verziójú operációs rendszer fut a szerveren, akkor célzottan tud különböző ismert sérülékenységeket kihasználni az operációs rendszer ellen. Információ kitakarás kategóriába tartozik egy webalkalmazás könyvtár struktúrájának listázhatósága is. Amennyiben feltérképezhető, hogy pontosan milyen fájlok, programok találhatóak a szerveren, akkor azokat elemezve, újabb sérülékenységek tárhatók fel. Tehát ha nincsenek kitakarva a verziók, akkor a verzió alapján rá tud keresni a támadó a sérülékenységre és kihasználhatja azt, amennyiben van olyan sérülékenység az adott verzióban, eljuthat adatbázisig és értékes információkat szerezhet meg. 

Brute Forcing (nyers erő alkalmazása): Ezen sérülékenység faktor nagyon sok helyen fordulhat elő, és rengeteg támadási forma épülhet a kihasználására. Bármilyen alkalmazásról vagy protokollról legyen is szó, közös tulajdonsága a sérülékenységi faktornak, hogy nagy mennyiségű kérést lehet intézni egy adott szolgáltatásra vonatkozóan anélkül, hogy bármilyen ellenintézkedés történne. Az egyik legkézenfekvőbb és legelterjedtebb sérülékenység a különböző login felületeknél tapasztalható. Több próbálkozás után a rendszer nem lassítja, korlátozza a próbálkozások számát. Egy rosszindulatú felhasználó így rengeteg felhasználónév/jelszó párost tud kipróbálni. Előbb-utóbb hozzáférést szerezhet a rendszerhez.

Phishing: Az ebbe a sérülékenységi faktorba tartozó hibák közös tulajdonsága, hogy felhasználóktól próbálnak adatokat szerezni illetéktelen módon. Ennek egyik jó példája az e-mailen történő adatszerzés, vagy a különböző honlapok utánzásával végrehajtott adatlopás. Az egyik legelterjedtebb példa, hogy rosszindulatú felhasználók lemásolnak pénzintézeti beléptető felületeket, és e-mailben arra kérik az ügyfelet, hogy jelentkezzen be a hamis online felületen, megszerezve így a felhasználók személyes adatait. Ez óriási reputációs veszteséget eredményezhet, hiszen az ügyfelek bizalma megtörhet. Több 10 milliós lehet a kár cégméret függvényében.

Input Validation (bemeneti adat ellenőrzése): Ebbe a kategóriába tartoznak a különböző kód beszúrásos támadások. A bemeneti mezők nem megfelelő ellenőrzése különböző kártékony kódok beillesztését teszik lehetővé. Ide tartoznak többek között az SQL-injection típusú hibák, vagy az XSS típusú támadások is. 

Password management (jelszókezelés): Ebbe a kategóriába tartozik minden olyan típusú sérülékenység, amely jelszókezelési problémákkal hozható összefüggésbe. A jelszavak hosszának és komplexitásának minőségi kritériumai jó példa a sérülékenység faktorra. Például egy 4 karakter hosszú, csak kisbetűt tartalmazó jelszó önmagában rejti a veszélyt, így ezek kijavítása nélkülözhetetlen. Idetartoznak továbbá a különböző rossz jelszó lenyomat (hash) készítési és jelszó titkosítási technikák is. Amennyiben egy vizsgálat során valahol elavult lenyomat (hash) készítés algoritmussal találkozunk (pl: MD5, SHA-1), a sérülékenység ebbe a kategóriába lesz besorolva. Minden olyan probléma, ahol a jelszó kezelésén, tárolásán kell változtatni szintén ebbe a kategóriába fog esni.

Factory defaults (gyári beállítások): A gyári beállítások önmagában hordozzák a veszélyeket. Legyen az web alkalmazás, hálózati eszköz, vagy bármilyen más hardver vagy szoftver elem, amennyiben gyári beállításokkal kerül üzembe helyezésre, az kockázatot rejt magában.  A gyári beállításokat bárki megnézheti egy adott eszközhöz, vagy szoftverhez, így hozzáférhet a menedzsment felülethez, átkonfigurálva a hálózati elemet. A gyári beállítások problémája nemcsak jelszavakhoz, hanem egyéb más technikai paraméterhez is kapcsolódhat. Jó példa lehet erre egy hálózati nyomtató rossz konfigurációja. 

Access Control management (hozzáférés szabályozás): Ebbe a kategóriába tartozik minden olyan sérülékenység, amely valamilyen rosszul beállított hozzáférés problémához vezethető vissza. Jó példa erre egy rosszul konfigurált VLAN, amelyben minden felhasználó képes csatlakozni a szerverhez. Egy jól beállított hálózaton a szerver menedzselését kizárólag rendszergazdák végezhetik, így felesleges mindenki számára hozzáférést biztosítani a szerverhez. Szintén ebbe a kategóriába tartozik például egy nem megfelelő port-security-val ellátott hálózat. Amennyiben illetéktelen eszköz csatlakoztatható egy belső hálózathoz, úgy egy rosszindulatú felhasználó támadásokat hajthat végre a hálózaton.

Misconfiguration (konfigurációs hiba): Ebbe a kategóriába több dolog tartozhat. Általában minden olyan problémát ide sorolunk, ami valamilyen téves konfiguráción, vagy konfiguráció hiányán alapszik. A gyári beállításoknál említett problémák, egy az egyben itt is alkalmazhatóak. Ide tartoznak továbbá például a rosszul konfigurált NETBIOS megosztások is, amelyek következtében olyan könyvtárak válnak olvashatóvá, írhatóvá, melyek egy átlag felhasználó számára általában nem elérhetőek. Az egyik legalapvetőbb hiba, a rossz SSL tanúsítványok használata is ide sorolható, vagy a rosszul beállított hálózati protokollok titkosítatlan kommunikációja.

Hogyan kerülnek kijavításra a talált bugok?

A sérülékenység felfedezése után, a bug bounty riport általában a fejlesztő csapathoz kerül. Ők átnézik a hibát, a reprodukálás lépéseit, a kritikussági szintet és ha érvényesnek találták a riportot, elfogadják. Ezután berakják a fejlesztési sorba a kockázatnak és a kapacitásuknak megfelelően. Mi már nem ellenőrizzük, hogy a hiba kijavításra került-e, kérés esetén azonban a sérülékenység orvoslásában is tudunk segíteni.

Számunkra elengedhetetlen, hogy az ügyfelek minőségi riportokat kapjanak, amelyek tiszták, nem duplikátumok, és a fejlesztők által is könnyen megérthetők. Az is fontos, hogy ne automata sérülékenység vizsgáló programok által kidobott hibát tartalmazzon, hanem bizonyítva is legyen (Proof of concept), legyenek kiszűrve a fals, negatív hibák. Ezeket az elővalidálási – triage – folyamatunk miatt biztosítani tudjuk minden ügyfelünk számára.

Bug bounty sikere ügyfeleinknél

Az elmúlt évek során számtalan ügyfelünknek nyújtott segítséget a bug bounty program. A legbüszkébbek azonban arra vagyunk, hogy egy olyan cégnél, ahol előtte pentesztet végzett egy másik szolgáltató, sikerült több mint 15 újabb sérülékenységet felfednünk. Ez a példa is demonstrálja a közösségi tesztelés erejét.