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

Protokollok-közti exploitálás

2011.10.02. 15:49 | buherator | 4 komment

A szeptemberi meetup kapcsán elkezdtem egyre többet foglalkozni a BeEF-fel, aminek az lett az eredménye, hogy felvettek a commiterek közé, és rögtön a nyakamba is akasztottak egy feladatot: az Inter-Process Expolitation/Communication modulok közül a "POSIX" változatot kellett működésre bírnom. 

De mi is az az IPEC? A válasz részben ebben a régi leírásban, részben egy azóta már az Internet süllyesztőjébe veszett doksiban keresendő - de én inkább a forráskódot választottam :) A kiindulási pont az, hogy (mondjuk egy XSS hibán keresztül) képesek vagyunk JavaScriptet futtatni egy tűzfal mögött ülő áldozat böngészőjében. A tűzfal mögött van egy szigorúan nem-HTTP szolgáltatás, pl. IMAP vagy egy bindshell. Az IPEC lényege az, hogy a protokollmegvalósítások engedékenységét kihasználva (ebben az esetben) HTTP-be tudjuk csomagolni a különböző IMAP illetve shell parancsokat.

A dolog elsőre triviális:

GET /index.html?&ls; HTTP/1.1
Host: 192.168.1.100:4444

Egy egyszerű GET kérést küldve egy nyitott bindshellnek, a kérés &-ig tartó, illetve ; utáni részei értelmezhetetlen parancsként hibát dobnak, míg az ls parancs lefut. Az első probléma akkor jelentkezik, amikor URL-ben nem engedélyezett karaktereket szeretnénk küldeni - ezeket ugyanis az áldozat böngészője rögtön URL-kódolja, ami nem fog tetszeni a shellnek. Ezen az apróságon azonban viszonylag egyszerűen túllendülhetünk, ha az űrlap adatokat multipart POST kérésként küldetjük el, ilyenkor ugyanis az általunk kontrollált üzenet rész (nagyrészt) kódolatlanul kerül be a HTTP kérés törzsébe:

POST / HTTP/1.1
Host: 192.168.1.100:4444

Content-Type: multipart/form-data; boundary=Xx1337xX

--Xx1337xX
Content-Disposition: form-data; name="submit-name"

;ls -la > /var/www/ls.html ;

--Xx1337xX

 

A komolyabb probléma, hogy hogyan kapom meg a visszaadott adatokat? A fenti példában ugyan megpróbálom kitolni egy DocumentRoot-ba az eredményt, de ez egyrészt nem biztos, hogy lehetséges, másrészt még mindig nem látok be a tűzfal mögé. 

A megoldás itt kevésbé magától értetődő: Készítsünk egy IFRAME-et, benne egy FORM-mal, ami el fogja küldeni a parancsainkat! A parancsokat úgy kell megfogalmaznunk, hogy a bindshell egy szabályos HTTP választ adjon vissza (fejlécekkel, sortöréssel) , hiszen másként az áldozat böngészője jó eséllyel nem fogja feldolgozni az adatokat. Ezzel elérhetjük azt, hogy a parancs eredménye betöltődjön az IFRAME-be, mintha csak egy rendes webszerver válaszolt volna. Az IFRAME-en kívüli kód (ami vissza tudna szólni nekem) azonban nem tudja kiolvasni az IFRAME tartalmát, így ismét trükközni kell: generáltassunk a bindshellel a parancs eredménye után egy JavaScript kódot, ami a window.location paramétert úgy írja át, hogy az tartalmazza a parancs kimenetét:

<div id="ipc_content">
/bin
/boot
/dev <!--...stb...-->
</div>
<script>window.location=parent+'#ipc_result='+ \  encodeURI(document.getElementById('ipc_content').innerHTML);</script>

Mivel az IFRAME-et létrehozó szkript hozzáférhet az IFRAME által mutatott aktuális címhez, a parancs kimenete is hozzáférhetővé vált!

A történet persze tovább bonyolódik, ha kevésbé megengedő, vagy összetettebb szintaktikájú parancsfeldolgozóhoz szeretnénk hozzáférni, de az infromáció kicsatornázásának fenti módja szerintem mindenképpen figyelemre méltó, másrészt pedig nem biztos, hogy szükségünk van a kimenetekre, ha mondjuk csak egy tűzfalszabályt írunk át.

Címkék: xss beef ipec inter protocol exploitation

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.

_bela- 2011.10.25. 16:12:12

Erdekes, hogy a postfix eseteben, ha az EHLO helyett GET-el vagy POST-al koszonunk, akkor '221 2.7.0 Error: I can break rules, too. Goodbye.' uzenettel lezarja a kapcsolatot, amugy minden mas esetben jon a szokasos '502 5.5.2 Error: command not recognized
'.
Mivel a HTML elemek csak GET vagy POST kerest engednek meg, marad valami XHR vagy flash alapu keres, amivel tetszoleges headert tudunk kuldeni. Viszont a cross domain policy miatt, meg nem fog lefutni a kivant keres...

_bela- 2011.10.25. 16:18:06

@_bela-:
vim postfix-2.7.1/src/smtpd/smtpd.c +909
/* .IP "\fBsmtpd_forbidden_commands (CONNECT, GET, POST)\fR"
/* List of commands that causes the Postfix SMTP server to immediately
/* terminate the session with a 221 code.

buherator · http://buhera.blog.hu 2011.10.25. 17:07:54

@_bela-: No igen, ez a kódrészlet jó eséllyel az ilyen támadások hatására került be (meg kéne nézni a commit histroyt...). Minden esetre a lehetőség implementációfüggő, érdekes lenne megnézni egy szélesebb statisztikát a népszerű szerverek viselkedéséről!
süti beállítások módosítása