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

Két Pwnie meséje - 2. rész

2012.06.19. 12:00 | detritus | 3 komment

Az első részben Pinkie Pie exploitjáról kaphattunk némi áttekintést, most pedig Sergey Glazunov 60.000 dolláros darabjának leírását posztolták a chromium blogján. Ha lehet, ez talán még agyafúrtabb, mint az előző, és aki első olvasásra nem veszti el a fonalat a felénél, az hazudik.

Az első fejvakarás akkor kezdődik, mikor az ember azt látja, hogy a preparált weboldal megtekintésétől a kódfuttatásig lezajló eseménysorozat lépésszámát nagyjából 14-ig számolták. A másik elképesztő tulajdonsága az exploitnak, hogy memória korrupció nem is történik benne, más jellegű (pl. rossz jogosultságkezelés) hibák apró kockáiból lett összerakva.

Az egész egy UXSS-sel (Universal XSS) kezdődik, vagyis a támadó szkriptjét egy weboldal borogatása helyett a böngésző manipulálására lehet felhasználni. Ha ez működik, akkor azt lehet kihasználni, hogy a Chrome egy érintett HTML oldalára nem alkalmazták a Content Security Policy-t (CSP). Arról van szó, hogy vannak speciális, a chrome:// forrásból (originből - lásd még SOP) származó oldalak (pl.: chrome://about), amik csak lokális gépen, közvetlenül nyithatók meg, külső HTML-ből (http[s]) vagy pl. IFRAME-ből nem, és nekik esetenként privilegizált API hívásokhoz is hozzáférésük van. Glazunov rájött, hogy ha egy érvénytelen chrome-extension:// erőforrást akar megnyitni IFRAME-ből, akkor a háttérben betöltődik egy UXSS-sel sebezhető hibaoldal a chrome://chromewebdata forrásból, amin nem kerül alkalmazásra a CSP (ez ugyanis megfogta volna az UXSS-t). Még néhány hibát kihasználva lehetett eljutni oda, hogy a chrome://chromewebdata nevében JavaScriptet lehessen futtatni.

De ez még kevés az örömhöz. A chrome://chromewebdata nem fér hozzá érzékeny API hívásokhoz, privilégiumokat pedig nem osztogatnak csak úgy, azt "örökölni" lehet egy közvetlenül megnyitott chrome:// forrású folyamattól. Az érzékeny chrome://* oldalakra pedig többnyire működik a CSP.

A továbblépéshez a chrome://chromewebdata nyitott egy új ablakot a chrome://net-internals originbe, ami egy IFRAME-et tartalmazott. Egy újabb bug lehetővé tette, hogy az új ablakra egy Visszát hívva a WebKit azt higyje, hogy közvetlen navigációval jutottunk az oldalra, így megadott neki néhány plusz WebUI privilégiumot. Ez után az új ablakba ágyazott IFRAME nyitott egy about:blank oldalt, és egy újabb hiba kihasználásával beadta a chrome://net-internals-nak, hogy az egy közvetlen gyermek - így az about:blank megkapta a korlátozott WebUI jogokat.

Ez után az üres oldalt a chrome://downloads-ra irányítva újabb jogokat lehetett nyerni, mivel a WebKit úgy látta, egy már részben privilegizált oldal kíván a letöltésekkel ügyködni. Ezután Glazunov fogta, és letöltött egy távoli DLL-t, majd a helyi fájlrendszerről a wordpad.exe-t. Mivel a wordpad.exe a helyi hosztról származott, elindítása nem eredményezett figyelmeztetést a felhasználó számára. A szövegszerkesztő azonban buta módon automatikusan betöltötte a mellé lerakott támadó DLL-t - egyszerűen brilliáns!

Az exploit tehát nagyjából ezen az úton haladt:

  • találni olyan hibákat, amivel a támadó chrome://<valami> origin-t tud uralni (ez esetben chromewebdata és net-internals)
  • ezt felruházni megfelelő jogosultságokkal
  • letölteni a támadó által megadott dll-t és egy megbízható programba berántva kódot futtatni rajta keresztül

Nagyjából ennyi a Chromium blog postja, de a végén figyelmeztetnek, hogy ez korántsem a teljes kép. Például csak az UXSS-t háromszor kellett használni. Az egész eléggé magáért beszél: azokban a termékekben, amelyek fejlesztésekor komolyan veszik a biztonságot, elmúlt a könnyű exploitok kora. 

Címkék: google google chrome pwnium

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.

Tyra3l 2012.06.19. 12:35:00

vicces hogy pl. a binary planting-et mennyire lefikaztak a full-disclosure levlistan anno.

Tyrael

synapse · http://www.synsecblog.com 2012.06.19. 16:57:30

A binary planting hatalmas nagy fuckup.