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

Ütközések II. - HTTP kiszolgálók hash-táblái

2011.12.28. 20:00 | buherator | 3 komment

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.

Címkék: microsoft google java php apache python asp.net tomcat oracle dos plone geronimo cruby jruby

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.

Symbol Developer · http://www.symboltech.hu 2011.12.29. 21:34:27

Jopar eves technologia a webszerverek parameteratadasa es csak most derult ki, hogy vacak: )

A post korrekt leiras.

_2501 2011.12.29. 22:53:12

@Symbol Developer: ako ezt figyeld: a zikeás bútorok fiókjai tervezésükből adódóan sérülékenyek papír injektálásra, azaz ha a fiók kulcsra zárva van is, a fölötte lévő résen be tudsz injektálni tetszőleges papírt. ez is régi technológia, de még most se derült ki!

komolyra fordítva értem én hogy mire gondoltál de nem tudom hol megfogni. :) nem a technologia a vacak hanem egyes implementációk.

b3ha 2012.01.01. 16:32:33

@_2501: Így van, az implementációban csúszott hiba.

Érdekes volt látni, ahogy a különböző platformok reagáltak. A perl-nek meg köszönik, hogy már 2003-ban megoldotta a problémát :)