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 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:

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:

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.

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.

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:

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].

Ú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.