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.