Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

CRIME

2012.09.29. 11:17 | buherator | 3 komment

Eljött az ideje, hogy kicsit körbejárjuk az legújabb SSL-fejtegetős témát, hála annak, hogy Juliano Rizzo és Thai Duong publikálták a diáikat (és van egy kis szabadidőm :). 

A Rizzo-Duong páros legutóbb a szintén SSL megfejtésre használatos BEAST támadással tűnt fel nagyjából egy éve, a most prezentált CRIME pedig ennek a leszármazottja. A rövidítés a Compression Ratio Info-leak Made Easy (vagy Mass Exploitation) kifejezésre oldható fel, és valójában több hasonló módszert fog össze, melyek különböző algoritmus- illetve protokoll-kombinációk ellen használhatók. Részletek a Tovább után:

A CRIME alkalmazhatóságának két feltétele van: Egyrészt a támadónak le kell tudnia hallgatni az áldozat hálózati forgalmát, másrészt rá kell vennie őt, hogy látogasson meg egy speciális weboldalt. Ezek előállhatnak egy egyszerű wifi hotspot alatt (mondjuk egy kávézóban), de a kutatók szerint a legreálisabb veszélyt az államilag végrehajtott, ISP-ken keresztüli akciók jelenthetik. Fontos megjegyezni, hogy a második követelmény akkor is teljesülhet, ha egy aktív támadó módosítja egy, az áldozat által HTTP-n böngészett weboldal válaszait.

Ahogy a név is mutatja, innentől fogva a hangsúly a tömörítésé. A weben általában a DEFLATE eljárást használják, ami lényegében Huffman-kódolást illetve LZ77 tömörítést jelent. Ezekről remek leírásokat olvashatok bármely kódolástechnikával foglalkozó könyv első fejezeteiben, a működésről most annyit érdemes tudni, hogy alapvetően mindkét eljárást redundanciát, konkrétan megegyező bit- illetve byte szekvenciákat keres a bemenetben, melyeket rövidebb szekvenciákkal helyettesít a kimeneten. Például:

"A buherátorok bugokat buktattak le" -> "A 1herátorok 1gok2 1kt2tak le"

Ezzel máris öt karaktert spóroltunk, csak az 1->"bu" 2->"at" megfeleltetést kell ismerni a veszteségmentes tömörítés feloldásához. Nomármost, a tömörítés általában mindenfajta titkosítás előtt történik, a titkosított adatok entrópiája ugyanis elég magas, kevés bennük az ismétlődés, fordítva tehát nem érne sokat Huffman tudománya. A titkosítás ezek után csak részben (erről később) fedi el a tömörített üzenet hosszát. 

A támadó ezt úgy tudja kihasználni, hogy hozzácsap némi adatot a titkosítandó (általa egyébként nem ismert) nyílt szöveghez, majd figyeli a tömörített és titkosított kimenet méretét. A gyakorlatban ez például úgy történhet, hogy lekérdeztetünk egy képet az áldozat böngészőjével:

<img src="https://example.com/?PHPSESSID=AAA"/>

Ekkor valami hasonló fejlécet küld el a böngésző az example.com-nak:

GET /?PHPSESSID=AAA HTTP/1.1
Host: example.com
User-Agent: Mozilla v1337
Cookie: PHPSESSID=<ismeretlen érték> 

A trükk az, hogy ha a PHPSESSID A-val kezdődik, akkor a teljes fejlécet egy kicsitvel jobban lehet majd tömöríteni, mintha nem lett volna jó a tippünk. A hálózati forgalom csomagjainak méretét figyelve a jó találat élesen elkülönül a többitől, így a PHPSESSID byte-jai egyenként kipörgethetők. Elméletben.

Kerekített bitek

A gyakorlatban van pár bökkenő, először is az, hogy a DEFLATE biteket ad, a végső kimenet pedig byte-okra kerekítve kerül vissza a támadóhoz, vagyis a tuti eredményhez minimum 8 bitnyi hosszkülönbségre van szükség a DEFLATE kimenetén.

Ezen egyrész az ún. kétpróbás módszerrel lehet javítani, ami azt használja ki, hogy az LZ77 csak bizonyos számú megelőző bitet vesz figyelembe a referenciák létrehozásakor, vagyis ha két azonos szekvencia túlzottan távol (az ún. ablakon túl) helyezkedik el egymástól, nem történik tömörítés. A módszer próbálkozásonként két lekéréssel dolgozik, az egyikben a tipp a sütivel egy ablakban, a másikban a süti ablakán kívül helyezkedik el. A prezentáció szerint a zlib DEFLATE megvalósításának mélyreható ismeretének birtokában mindig legalább 8 bitnyi hosszkülönbség érhető el a két próba között, ennél bővebb leírást azonban sajnos nem kapunk. 

A másik módszer a Google által kifejlesztett, a HTTP 2.0 leendő alapjaként számontartott SPDY protokoll tulajdonságait használja ki a pontosabb becslés érdekében. A SPDY szintén DEFLATE-et használ a fejlécinformációk tömörítésére, de fontos különbség az eddigiekhez képest, hogy az egy irányba menő összes forgalom tömörítése azonos tömörítési kontextusban történik, vagyis egy üzenet tömörítését a megelőző üzenetek tartalma is befolyásolja. Mivel az egyes fejlécek igen rövidek, a kódoló a szabványban rögzített Huffman-táblát fogja használni, ami 7-9 bites kódokat használ, ami szinte biztosan eltérést fog okozni a byte-ra kerekített kimeneten. 

Utóbbi módszer eleve kicsit gyorsabb a kétpróbásnál, ráadásul az SPDY használata eleve hatékonyabbá teszi az adatkommunikációt. Az SPDY protokollt implementálja többek között a Google Docs, a Gmail, a Twitter és a Wordpress, ezek a szolgáltatások tehát hatékonyan támadhatók lennének - a Google és a Mozilla a kutatók megkeresése után ideiglenes megoldásként kikapcsolta a fejléc tömörítést a Chrome és a Firefox böngészőkben, az SPDY 4-es változata a jövőben remélhetőleg tartós megoldást ad majd a problémára.

TLS

Magában a TLS protokollban is megadták a lehetőséget a titkosítás előtti tömörítésre, a legtöbb implementáció pedig a már jól ismert DEFLATE algoritmust támogatja. A megvalósítás annyiban különbözik az eddigiektől, hogy az üzenetfolyam 16K-s darabokban kerül külön-külön kontextusokban tömörítésre. Ez egy elegáns, "választott határoló" típusú támadásra ad lehetőséget:

Töltsük fel a fejlécet olyan hosszan, hogy a titok első byte-ja még az első 16K-s blokkba, a többi a másodikba essen! Mivel a HTTP fejléceknek szinte az egésze ismert, offline szimulálhatjuk a tömörítést minden lehetséges esetre (itt a számosság az ismeretlen paraméterek függvénye), majd az elfogott titkosított üzenet mérete alapján következtethetünk a helyes tippre. A titkos többi része a határoló eltolásával hasonlóan fejthető. 

A TLS tömörítést egyedül megvalósító Chrome böngészőben a lehetőséget kikapcsolták.

Távlatok

Természetesen a tömörítésből adódó információszivárgás nem csak (ezeket) a webes protokollokat érintheti. A kutatók említés szinten kitérnek a szinte mindenhol alkalmazott tömörített HTTP válaszok támadási lehetőségeire (itt feltétel, hogy a szerver válasza tartalmazza a támadó bemenetének egy részét), Nick Mathewson pedig már felvetette a VNC titkosítás támadhatóságát is az RFB protokoll CopyRect kódolásán keresztül is.

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

boldii10 2012.10.26. 23:55:30

Két hiány, egy: akkor most mekkora erőfeszítéssel nagyjából mit ér el a támadó (nagyon el van rejtve a szövegben, nem csak itt)? (nincs megfogalmazva az elején három kifinomult mondatban, ami sokakon segíthet)

2.) az ügy referenciája CVE-2012-4929

buherator · http://buhera.blog.hu 2012.10.27. 17:21:38

@boldii10: Szerintem a harmadik bekezdés pont erről szól + ott a videó, három kifinomult mondatot majd ír az index. A CVE számot köszi!