Cookie / Süti tájékoztató
Kedves Látogató! Tájékoztatjuk, hogy a weboldal működésének biztosítása, látogatóinak magasabb szintű kiszolgálása, látogatottsági statisztikák készítése, illetve marketing tevékenységünk támogatása érdekében cookie-kat alkalmazunk. Az Elfogadom gomb megnyomásával Ön hozzájárulását adja a cookie-k, alábbi linken elérhető tájékoztatóban foglaltak szerinti, kezeléséhez.
Elfogadom
Nem fogadom el
2016.02.18

A Juniper-botrány tapasztalatai hazánk kiberbiztonsága tekintetében

Kiberbiztonság témakörben nap mint nap történnek olyan események, amik aktualitást adnak egy, a témával foglalkozó írásnak. A vírustámadások, zsaroló programok rendszeres feltűnésétől, az igen fejlett eszközökkel (APT – Advanced persistent threat) – célzottan, már-már hadászati szinten – végrehajtott támadásokig sok említésre méltó terület van. Jelen cikk gondolatindítója az a trend, hogy egyes állami szervezetek különböző okokból gyengíteni, illetve korlátozni próbálnak IT biztonsági szoftvereket és védelmi eszközöket. A következőkben megvizsgáljuk, hogy ezen törekvések milyen következményekkel járnak a kibertér, a felhasználók, de akár hazánk biztonságára nézve az elmúlt hetek, hónapok, évek történéseinek fényében.
Ahogy az a médiából ismert, 2015.12.17-én pattant ki a botrány,  miszerint egyes Juniper termékek forráskódjához illetéktelen támadók fértek hozzá és módosították azt[1]. A támadó a program módosításával képessé vált az eszközökhöz a legmagasabb, adminisztrátori szinten hozzáférni.  Ezen felül arra is képes volt, hogy a Juniper termékek által szolgáltatásként nyújtott titkos, és ellenőrzött kapcsolaton áthaladó adatokat lehallgassa és teljes mértékben értelmezze. Félreértések elkerülése végett jegyezzük meg, hogy ezek a problémák nem elsősorban a Juniper-t gyártó cég hálózatára voltak veszélyesek. A rosszindulatú módosítások miatt minden olyan ügyfél hálózata kiszolgáltatottá vált a támadásoknak, akik az érintett Juniper termékekkel próbálták védeni adataikat. Ez a két biztonsági hiba tulajdonképpen az eszköztől elvárt biztonsági funkcionalitás totális megsemmisítése volt.

Érdekességként megjegyezhetjük, hogy a legmagasabb szintű hozzáférést a támadó úgy oldotta meg, – meglehetősen amatőrnek, és óvatlannak tűnő módon – hogy egy „mesterjelszót” kódolt a programba. Ez azt jelenti, hogy bárki, aki ezt a jelszót megszerezte, – esetleg célzott vizsgálat során az eszköz kódjában megtalálta – az képes volt a távoli, teljes jogú hozzáférésre.

Eddig a történet valójában nem különbözik sok más esettől, amikor támadók eredményesen támadnak valamilyen rendszert. Ilyen esetek sajnos időről-időre megtörténnek, néha még jó nevű informatikai biztonsági cégekkel is. Ismereteink szerint azonban ez az eset igazolta először a gyakorlatban azt a tételt, hogy a biztonsági cégek állami szervezetek által történő befolyásolása számos, nem várt veszélyt is rejt magában. Az alábbiakban ezt próbáljuk  megmutatni.

A Juniper-botrány tapasztalatai hazánk kiberbiztonsága tekintetébenA Juniper-botrány tapasztalatai hazánk kiberbiztonsága tekintetében

A sajtó az elmúlt hónapokban, években elég alaposan kivesézte számos amerikai IT eszközöket gyártó cég és a National Security Agency (NSA, USA) kapcsolatát. Ebből megtudható – elsősorban a Snowden botrány során nyilvánosságra került információk alapján – hogy az NSA számos amerikai informatikai gyártót befolyásolt. A szervezet több termékbe helyezett, vagy helyeztetett el olyan kódokat, algoritmusokat, amelyek lehetővé tették azt, hogy az állam hozzáférjen az eszközökhöz, valamint az eszközök által kezelt adatokhoz. A kiszivárogtatott információk szerint szinte minden nagy amerikai gyártó elvesztette a felhasználói bizalmat. A nyilvánosságra hozott adatok szerint például a legismertebb informatikai cég, a Microsoft is[2] benne volt ebben az együttműködésben.

2013-ban szivárgott ki, hogy egy jó nevű amerikai biztonsági cég, az EMC / RSA Security – 10 millió dollárért cserébe – egy, az NSA által készített fejlesztői csomagot használt bizonyos termékeiben[3],[4]. A csomag tartalmazta a Dual_EC_DRBG nevű véletlenszám-generátor algoritmust is. A véletlenszám-generátorokat a kriptográfiában legfőképpen más kriptográfiai algoritmusok által használt kulcsok előállítására használjuk. A szóban forgó algoritmust a készítői szándékosan úgy gyengítették meg, hogy a generált véletlen számok az NSA számára mégse legyenek teljesen véletlenek, s így a megfelelő adatokat használva képesek legyen a teljes „véletlen” kimenetet kiszámolni. Emiatt adott feltételek mellett az NSA gyakorlatilag korlátlan hozzáféréssel bír a titkos forgalom felett, mivel a véletlen-szám generátor által előállított kulcs ismeretében képes visszaállítani a rejtjelzett adatokat. Ezt vélhetően azzal a – mellesleg alapvetően téves – feltételezéssel teszi, hogy erre más nem lehet képes. Már ekkor közöltek kutatók egy tanulmányt arról, hogy ezen gyenge algoritmus – illetve a csomagban lévő még egy másik algoritmus – jelentős mértékben degradálja az alkalmazott titkosítási eljárás(ok) erősségét[5]. Az RSA 2013 őszén már maga is azt tanácsolta az ügyfeleiknek, hogy ne használják az érintett fejlesztői könyvtárakat.

Ennek ellenére – vagy éppen ezért – a most kompromittálódott Juniper eszközökben, vélhetően ismét az NSA közreműködése által, szintén a Dual_EC_DRBG[6] nevű véletlen-szám generátor, illetve az azt tartalmazó fejlesztői könyvtár került felhasználásra.

Fentiek alapján a biztonsági szakértők – vélhetően teljes joggal – azt feltételezik, hogy az ismeretlen – tehát nem az NSA-hoz tartozó – támadó úgy volt képes kompromittálni Juniper eszközöket, hogy azt, vagy azokat a gyengítéseket használta ki, amelyeket az amerikai kormányszerv helyezett el a rendszerben. Az egyelőre még nem bizonyított, hogy a fentebb ismertetett illetéktelen hozzáférések és módosítások is tulajdonképpen ennek az állami beavatkozásnak a következményei-e. Ezzel együtt vélhetően ez az első olyan ismert és nagy sajtónyilvánosságot kapott eset, amikor kormányzati nyomásra elhelyezett informatikai gyengeséget más szervezetek is kihasználtak.

A Juniper-botrány tapasztalatai hazánk kiberbiztonsága tekintetében

Az ilyen típusú problémák nagyon is valósak, komolyan kell venni őket. További adalék a felvetett probléma jelentőségének érzékeltetésére, hogy a Juniper-botrány után röviddel a Fortinet biztonsági cég egyes tűzfal termékeiben is hasonlóan durva problémát találtak. Az érintett eszközök kódjában visszafejthető hozzáférési adatok voltak. Ezen adatok segítségével a támadók a legmagasabb adminisztrátori jogosultsággal, távolról voltak képesek hozzáférni az eszközökhöz[7]. Természetesen az ilyen típusú hibák a felhasználók szempontjából igen rossz helyzetet teremtenek. A támadó így a rendszerükben lévő védelmi(!) eszközön magas jogosultságot szerezhet, amivel a teljes hálózat kompromittálása felé tesz egy jelentős lépést. A Fortinet azt állítja, hogy a fejlesztők véletlenül hagyták benne az eszközök kódjában a hozzáférési adatokat, amit eredetileg a cég mérnökei az új eszközök beállításakor vagy hibaelhárításkor használtak. 

Biztonsági szakértői szemmel nehéz eldönteni, hogy melyek a rosszabbak, a szándékos vagy a véletlen hibák, de az látszik, hogy mindkét típus alapvetően fenyegeti rendszereinket. Egy rendszer biztonsági vizsgálatára számos technikai vizsgálat-típus létezik. A vizsgálatok és tesztelések során sokféle gyengeséget lehet felderíteni, amelyeket a megfelelő szakértők képesek megérteni, és adott esetben saját céljaikra is kihasználni. Tehetséges biztonsági szakértők a világon mindenütt vannak, akik képesek ilyen vizsgálatok végrehajtására. Ne felejtsük el, hogy az érintett eszközök kereskedelmi termékek, a világon bárhol megvásárolhatóak, hazavihetőek és akár laboratóriumi körülmények között vizsgálhatóak. Ismert tény, hogy számos ország nagy erőforrásokat fordít arra, hogy jelentős kiberbiztonsági védekezési és támadási potenciállal rendelkezzen. Vélhetően egy (vagy több) ilyen, államilag is támogatott csoport talált rá az NSA által elhelyezett gyengeségek kihasználására, s talán ezek segítségével további, saját kódokat is képesek voltak beépíteni az érintett Juniper termékekbe.

Ezen gyengeségek segítségével – vélhetően éveken keresztül és teljes titokban – voltak képesek a védelmi rendszeren keresztül(!) a termék ügyfeleinél a védettnek hitt információkhoz, illetve rendszerekhez hozzáférni.

Hogy ne csak az amerikai informatikai ipar eljárásait vizsgáljuk, említés szinten legyen itt két példa a világ másik részéről is, amely illusztrálja, hogy az IT biztonság gyengítésére való törekvés minden olyan országban felmerül, ahol erre a lehetőség van:

·         A Yulong cég Coolpad okostelefonjában 2014 decemberében találtak gyárilag telepített backdoort[8]

·         A ZTE 2012-ben elismerte, hogy backdoor volt az egyik termékében. Az nem egyértelmű, hogy fejlesztői hiba, vagy szándékos beavatkozás történt, azzal együtt, hogy a kártékony kód egy gyári(!) frissítéssel érkezett az eszközökre[9]

Kis színesként említsük még meg, hogy 2015 márciusában Obama elnök élesen kritizálta[10] a kínai kormány szabályozási tervét, amely alapján kényszerítenék a Kínában tevékenykedő amerikai cégeket arra, hogy hátsó ajtókat nyissanak az kínai piacra szánt szoftverekben és hardverekben. A tervezet azt is előírná, hogy a biztonsági termékek esetében a gyártóknak át kell adniuk a kormány részére a használt titkosító algoritmusok visszafejtéséhez szükséges kulcsokat is. A pénzügyi területeken az is előírás lenne, hogy az alkalmazások forráskódjait is át kell adni, a zárt forráskódú szoftverek esetében is!

A Juniper-botrány és a kapcsolódó események rámutatnak arra, hogy mégoly erős biztonsági algoritmusok, protokollok, folyamatok és rendszerek is egyetlen gyenge pont miatt kártyavárként omolhatnak össze. Ez bekövetkezhet nem csak az NSA és a kormányszervek, hanem egyéb külső szereplők beavatkozására is. Gondoljuk meg, hogy fizikai biztonsági berendezések, elektronikus riasztó rendszerek vagy páncélszekrények esetében mindenki könnyen belátja azt, hogy ha szándékosan gyengítenénk ezeket az eszközöket, vagy „kiskapukat” hagynánk bennük, akkor azt nem csak az állami szervezetek vagy a gyártók tudnák kihasználni, hanem vélhetően igen rövid időn belül a bűnözői csoportok is. Mivel a kriptográfia lényegesen bonyolultabb, ennek a működését sokkal nehezebb elképzelni, így az itt felvetődött problémákat sem a széles tömegek, sem a vezetők nem látják át teljes mértékben. Valójában a különbség csak az alkalmazott eszközökben, a résztvevő szakértők tudásában és esetleg az alkalmazott szakértők költségében van.

A kriptográfiai eszközök gyengítése miatt nem csak konkurens államok hírszerzői érhetnek el eredményeket, de ez remek lehetőséget teremthet az üzleti hírszerzési köröknek, illetve a szervezett bűnözői csoportoknak is. Ezek a csoportok is képesek szakértőket alkalmazni és komoly pénzügyi erőforrásokat áldozni céljaik érdekében. A biztonsági alkalmazásokat gyengítő törekvések totálisan meggyengíthetik azon üzemeltetők eszköztárát, akik pénzügyi, egészségügyi vagy kormányzati adatainkat akarják megvédeni, mivel adott esetben ők is sérülékeny termékeket is vásárolhatnak.

Fontos leszögezni, hogy az elterjedt kriptográfiai protokollokban és a bennük használt algoritmusokban nyugvó bizalom ezzel a történettel nem gyengült meg. Ismereteink szerint a széles körben elterjedt algoritmusok a megfelelő kulcsmérettel, implementációval és használati módokkal továbbra is biztonságosak. Ezen algoritmusok teljes felépítése és pontos működése bárki számára szabadon megismerhető. Tudósok, matematikusok és kriptoanalízissel foglalkozó szakemberek folyamatosan vizsgálják az algoritmusokat, amelyek az ismert támadási módoknak ellenállnak. Az algoritmusok teljes megismerhetősége fontos tudományos kritérium. Auguste Kerckhoffs 1883-ban megállapította[11], hogy adott  algoritmus biztonságát az alkalmazott matematikai módszereknek kell szavatolnia. Ez esetben csak a titkosítási kulcso(ka)t kell titokban tartani. Tévhit az, hogy az algoritmus titokban tartása garantálja a biztonságot, sőt ez hamis biztonságérzetet adhat. Ennek gyakorlati jelentősége azért fontos, mert egy „titkos algoritmus” kompromittálása esetén teljes kriptorendszereket kellene lecserélni, míg egy kulcs kompromittálása esetében csak az adott kulcsot. A biztonsági szakértők általános tapasztalata, hogy a „titkos”, zárt körben készült algoritmusok gyakran nagyon gyengék és könnyen törhetőek. Ez rendszerint abból adódik, hogy nem megfelelő tudással rendelkező szakértők dolgozzák ki őket. További ok, hogy az algoritmusok titkossága miatt lényegesen kevesebb biztonsági vizsgálatot végeznek el rajtuk, mint az ismert algoritmusok esetében. Ennek megfelelően ajánlott olyan eszközöket, eljárásokat alkalmazni, amelyek a tudomány jelenlegi állása szerint megfelelően működnek. Szerencsére vannak ilyen ismert eljárások.

A megfelelő tudással rendelkező szervezetek képesek megfelelő titkosítási és biztonsági módszereket alkalmazni. Ez igaz akár terrorista és egyéb bűnszervezetekre, elnyomás alatt lévő jogvédőkre, de akár azon egyszerű állampolgárokra is, akik kényesek a magán szférájukra. Belátható, hogy a fent bemutatott állami törekvések nem feltétlenül érik el a céljukat, sőt, ez még fejlődésre is inspirálhatja az érintett szervezeteket a biztonsági technológiák használatának területén. Mivel számos elterjedt eszköz megbízhatósága immár bizonyítottan megkérdőjelezhető, így várhatóan ezek a szervezetek és személyek – vagy akár országok is – tudatosan és tervezetten más utakat fognak választani az adataik védelmére.


ÖSSZEFOGLALÁS ÉS JAVASLATOK:

Milyen tapasztalatokat, következtetéseket és javaslatokat tudunk a fentiekből levonni? Véleményem szerint a következőket: 

1.    A különböző informatikai és információtechnológiai biztonsági eljárásoknak mély tudományos alapjai vannak. Ahogy azt sem tudjuk hosszú távon megakadályozni, hogy matematikai, atomfizikai, számítástechnikai és egyéb ismeretekhez hozzáférjen minden ország, így természetesen ez érvényes a kriptográfiára és kapcsolódó témákra is.

2.    Látható, hogy bármilyen biztonsági gyengítés kihasználását nem lehet kontrollálni abban az esetben, ha az adott gyengített rendszer vagy termék széles körben elérhető. A mai biztonsági vizsgálatoknak széles palettája alkalmazható anélkül, hogy az ellen az adott eszközök hatékonyan tudnának védekezni. A támadóknak számos lehetősége van a passzív vizsgálatok elvégzésétől akár fizikai bontással járó laboratóriumi vizsgálatokig.

3.    A biztonsági rendszerek szándékos gyengítése nem emeli az állam és az állampolgárok (legyen az bármelyik ország állampolgára) biztonsági szintjét, és nem növeli a védekezési lehetőségeket a terrorizmus, vagy más nem kívánt fenyegetések ellen. Ezzel szemben gyengíti a szervezetek saját védekezési lehetőségeit, és további – nem belátható – veszélyeknek tesszük ki őket ezáltal.

4.    A biztonsági rendszerek szándékos gyengítése nem csökkenti nagymértékben azon szervezetek, illetve személyek lehetőségeit akik mégis hatékony titkosítási, illetve biztonsági megoldásokat akarnak használni.

5.    Alapvetően téves az az irány, hogy saját, „titkos” algoritmusokat, protokollokat alkalmazzunk, ez alól természetesen kivétel, ha képesek vagyunk igen erős, világszínvonalú kriptográfiai szakértői csapat felállítására.

6.    Nagyon fontos következtetés, hogy minden országnak aki állva akar maradni az internet korának biztonsági kihívásaival szemben, jelentős erőket kell fordítani a szakemberek képzésére. Az IT biztonság minden területén szükség van oktatásra, korszerű módon, az akadémiai és a versenyszféra bevonásával. Nagy szükség van (volna) mind technikai jellegű biztonsági szakemberek, mind a szabályozási területeket ismerő szakemberek képzésére. A specializált IT biztonsági szakembereken kívül fontos, hogy saját területükön az üzemeltetők, a fejlesztők és az IT vezetők IT biztonsági gyakorlati képzésben részesüljenek. Ez azért is különösen fontos, mert általános tapasztalat, hogy a szervezetek – sem a KKV-k, sem az állami szervezetek –  nem rendelkeznek megfelelő IT biztonsági tudással. Az állami szektor esetében külön probléma, hogy az IT biztonsági szakértelem még az IT területen belül is drága, így ez számukra nehezen megszerezhető és megtartható kompetencia

7.    Célirányosan segíteni kell a hazai fejlesztéseket, innovációt minden biztonsági területen. Az európai uniós és hazai K+F pályázatok körében az informatikai iparág támogatásának területén a hazai IT biztonsági képességek növelése elengedhetetlen fontosságú, mivel a tapasztalatokból úgy tűnik, hogy a külföldi gyártók bizonyos felhasználói területeken nem minden esetben megbízhatóak.

8.    A biztonsági követelményeket a tervezés és a fejlesztések során már alapvetően be kell építeni minden informatikai rendszerbe. Fel kell számolni azt a tévhitet, hogy a rendszer akkor van kész, amikor a funkcionális működése rendben van. Ezt a célt a rendszerfejlesztők biztonsági képzésével, illetve szabályozással lehet elérni. Ebben jó példa, hogy az induló állami fejlesztések esetében már előírás, hogy a 2013. évi L törvény követelményeit már a tervezési szakaszban is figyelembe kell venni.

9.    A szervezeteknél a védekezés és annak tervezése ne üzemeltetési szemlélettel történjen. Bár egyszerűbb homogén infrastruktúrát üzemeltetni, mégis többszintűen és változatos megközelítéssel kell védeni a kritikus rendszereket, úgy, hogy az esetleges gyenge láncszemek lehetőleg ne degradálják le teljes mértékben a szervezet védekezési lehetőségeit.

10. A szervezeteknek, illetve állami szinten biztonsági eljárásokat kell kidolgozni a Juniper, illetve a Fortinet típusú incidensek kezelésére. Az ehhez hasonló biztonsági események felmerülése esetén az érintett szervezeteknek vizsgálatot kell indítani. A vizsgálat(ok) során fel kell deríteni azt, hogy a szervezetek informatikai rendszereiben történtek-e illetéktelen hozzáférések. Az eljárás során bizonyára hasznos lehetőségek merülnének fel arra nézve is, hogy hogyan lehet az ilyen típusú kockázatokat kezelni.

11. A fentiekből egyértelmű, hogy valódi ellenőrzési kontrollokat kell kialakítani azokkal a rendszerekkel, eszközökkel szemben, amelyek védenek bennünket. Ezek nem lehetnek ismeretlen működésű „fekete dobozok”. Optimális esetben a felelős szervezeteknek birtokolnia kellene az alkalmazott eszközök teljes műszaki leírását, forráskódját és a működésének pontos ismeretét, persze a józan ész – illetve a szakértői kompetencia és anyagi erőforrások – határain belül. Különösen fontos ez a kritikus infrastruktúra elemek, illetve az állami adatvagyon védelme esetében.


 
Következő esemény
2025.05.27 00:00