Juniper: ha a hátsó kapun rossz emberek sétálnak be

Két fontos sebezhetőség létét jelentette be a Juniper hálózati eszközöket gyártó cég. A Cisco legnagyobb riválisaként jellemezhető vállalat még 2004-ben 4 milliárd dollárért vásárolta fel a NetScreent, a hálózati biztonsági megoldásokat fejlesztő céget. A NetScreen tűzfalakat, VPN-célgépeket, forgalomirányító és -alakító eszközöket gyárt, ezek szoftveres alapja pedig a saját fejlesztésű ScreenOS. A közzétett információk szerint e rendszer bizonyos kiadásai két sebezhetőséget tartalmaznak, amelyek adminisztrátori jogosultság elérését illetve a "VPN-forgalom visszafejtését" teszik lehetővé támadók számára. A hibajavítást tartalmazó frissítést a cég közzétette, és minden eszköz azonnali frissítését javasolja.

Az első sebezhetőség viszonylag triviális: a támadók egyszerűen egy "mindent vivő" jelszót helyeztek el a rendszerben, így az adott kódot megadva (bármilyen érvényes felhasználói név mellett) hozzáférés nyerhető, a legmagasabb jogosultsággal. A kód szinten bedrótozott jelszó működését ráadásul az eszköz üzemeltetője kitörölni vagy deaktiválni sem tudja, a frissítés azonban (szerencsére) lezárja ezt a bejáratot.

A Juniper leírása szerint a második sebezhetőség lehetővé teszi, hogy a "megfelelő tudással rendelkező támadó" visszafejtse a VPN-kapcsolatokon keresztül folyó titkosított forgalmat. Ez  ugyanis azt jelenti, hogy a támadó lehallgathatja a cég szinte teljes külső adatforgalmát, ráadásul úgy, hogy arról a cégnek és az alkalmazottaknak semmilyen tudomása nincs. Ipari, politikai vagy diplomáciai kémkedéshez ideális. Mivel a sikeres lehallgatáshoz az is szükséges, hogy a titkosított forgalmat a támadók képesek legyenek elfogni, ez nem az egyszerű hackerek, hanem kormányok, titkosszolgálatok működési terepe.

^{Juniper NetScreen - mi volt a dobozban?}

A Juniper a műszaki részletekről mélyen hallgat, a klienseket egyszerűen a frissítéshez irányítja, így első kézből nem érhető el leírás a rendkívül súlyos problémáról. A biztonsági szakértők azonban az elérhető lemezképek és a hardverek elemzése alapján egészen pontosan rekonstruálni tudták a problémát, az eredmények pedig igen fekete képet festenek a Juniper hálózati eszközeinek biztonságáról. A cég azt állítja, hogy a hivatalos szoftverkiadásokhoz illetéktelen hozzáférés nyomán került be mindkét fenti hiba, ez azonban csak még aggasztóbbá teszi a helyzetet, ugyanis azt jelentheti, hogy a cég forráskódjához még a fejlesztés során hozzá tudott férni valamilyen támadó (legvalószínűbb az NSA lehet).

A sebezhetőség központjában egy hírhedt algoritmus, a Dual_EC_DRBG áll. Ez egy kriptográfiai szempontból biztonságos véletlenszám-generátor, amelyről ma már tudjuk, hogy az amerikai nemzetbiztonsági hivatal (NSA) szándékosan meggyengítette. Nagyon röviden: ez az algoritmus elvben teljesen véletlenszerű számsort állít elő, ehhez pedig egy Q konstanst használ kiindulási alapként. A kriptográfiai kutatók azonban már korábban bebizonyították matematikailag, hogy a Q-t rosszindulatúan generáló fél mindössze 30 bájtnyi kimenet birtokában meg tudja jósolni az algoritmus kimenetét, amivel pontosan a véletlenszerűség vész el, ez pedig katasztrofális hatással van a titkosítás megbízhatóságára (egy ultrarövid bevezető a problémába itt érhető el).

Hogyan jön ez elő a Juniper esetében? A kutatók szerint a hálózati eszköz pontosan ezt a Dual_EC_DRBG-t használta az adatfolyam titkosítására, érdekes módon azonban nem az NSA által ajánlott Q-t használva, hanem egy másik konstanst épített be. Míg arról van némi sejtésünk a Snowden-féle szivárgás óta, hogy az NSA-által generált Q lehetővé teheti a visszafejtést, a Juniper által használt konstans esetében erről fogalmunk sincs - a konstans cseréjével a cég pontosan az algoritmus gyengeségét is kivédhette, de adott esetben a saját, rosszindulatúan generált Q-val gyakorlatilag saját backdoort is tehetett a rendszerbe.

A történet persze itt nem áll meg, sőt, az igazi csavarok csak most jönnek. A Snowden-féle szivárogtatás nyomán azonnal felmerült, hogy minden szoftverből ki kell irtani a Dual_EC_DRBG-t, mivel az nem eléggé megbízható. Ekkor a Juniper is elismerte, hogy az algoritmust saját eszközeiben is használja, a cég azonban védekezésül felhozta, hogy nem közvetlenül, hanem egy másik véletlenszám-generátoron (a biztonságosnak tekintett ANSI X9.17-en keresztül) használja fel azt, így a nyers Dual EC adatfolyam nem érhető el, a támadási felület ezzel pedig védett. A cég a fentiek nyomán a Dual EC használatával nem is hagyott fel.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Ahogy azonban Matthew Green kriptográfus említi blogbejegyzésében, a védekezés csak akkor áll meg, ha nincs más módszer arra, hogy a rosszindulatú támadó az említett 30 bájtnyi nyers, feldolgozatlan kimenetet ne tudja kiolvasni a Dual_EC_DRBG-ből és ezzel meg tudja határozni az algoritmus pontos állapotát. "És ki gondolta volna" - teszi hozzá Green - "pont egy ilyen hiba van a ScreenOS több verziójában", amely lehetővé teszi a nyers kimenet kiolvasását, ezzel az algoritmus teljes további kimenete kiszámolható.

Ez az algoritmus és a Q értéke tehát a kulcsa a fent említett hátsó kapunak, amelyet a támadók is pontosan tudtak. A támadás ugyanis gyakorlatilag semmit nem módosított a rendszeren, csupán a Q értékét változtatta meg, valószínűleg egy olyan számra, amelyet a támadók speciálisan generáltak, és amely szintén lehetővé teszi a Dual_EC_DRBG megtörését, ezzel pedig feltörhetővé teszi a titkosítást. Ahogy Green fogalmaz: "összességében a támadók észrevették, hogy a Juniper szoftverében már található egy backdoor (akarva-akaratlanul, döntse el az olvasó), majd fogták ezt a hátsó ajtót és saját céljaikra újrahasznosították. Végeredményben volt egy hosszú periódus, amikor a támadók vissza tudták fejteni a Juniper eszközök által titkosított forgalmat szerte a világban".

Különös aktualitása van

A fentieknek jelenleg az ad különös hangsúlyt, hogy a technológiát és a kriptográfiát hírből sem ismerő amerikai politikusok komoly nyomás alá helyezték a tech-cégeket. A jobb- és baloldali képviselők lassan egyhangúan követelik azt, hogy a cégek építsenek a titkosítás ellen backdoort a szoftvereikbe és algoritmusaikba, mely a kormányzat számára egyedi hozzáférést tesz lehetővé a titkosított tartalomhoz. Az érv szerint ha a szilícium-völgyi zsenik valóban nekiállnának, akkor képesek lennének létrehozni egy olyan kiskaput, amely a kommunikáció biztonságát nem bontja meg, a kormánynak mégis hozzáférést ad. Az ötlet már Európában is gyökeret vert, a brit titkosszolgálat nyomásgyakorlására várhatóan az Egyesült Királyság is törvénybe fogja foglalni a kötelező backdoort az általánosan alkalmazott titkosítás esetében.

Ez természetesen köszönőviszonyban sincs a kriptográfia alapjaival, az ellenérveket felsorolni is nehéz, a legfontosabb azonban, hogy az ilyen különleges kulcs csak elvben egyedi, a létrehozott kiskaput bűnözők, vagy nem-szövetséges kormányzatok ugyanúgy megtalálhatják, mint a hozzáférést követelő amerikai kormányzat - ahogy végül a Juniper kiskapujával sem az eredeti beültető szerzett hozzáférést a szakemberek szerint.