Exploitacja w stylu RBN

W przypadku przeciętnych metod exploitacji browsera jest to jedna strona zawierająca złośliwy kod na wybrana podatność/ci, bez żadnych odwołań do kolejnych serwerów ,itp.
Jako, że RBN dysponuje potężniejszymi zasobami przejętych kont hostingowych niczego nie świadomych użytkowników oraz hostingów typu bullets-proof natrafiwszy na złośliwą stronę tej produkcji nasza przeglądarka jest zabierana wręcz w podróż dookoła świata, a po drodze musi „przełykać” kolejne porcje okrutnego kodu.

[+]Massive Attack[+]

Tak, tak, strony zawierające exploity wymierzone w twoją przeglądarkę ,a tak naprawdę
strony uruchamiające mechanizm rozłożony na paru(nastu) serwerach,testuje ją pod kątem podatności.
Rzućmy okiem na przebieg takiego ataku.
Uwaga: nazwy hostów podane przy analizie ataku, są rzeczywistymi nazwami hostów ,lecz większość z nich jest obecnie offline.
Typowe linki prowadzące do phishing sitów wyglądają tak:
http://evil.com/some_folder/[BANK|SHOP]NAME
, podobnie jest i w naszym przypadku

http://nirvanafan.org/magazin/s/unicaja
http://nirvanafan.org/magazin/s/bbk
http://nirvanafan.org/magazin/s/ebay
etc…no i na tym sprawa się kończy jeżeli konto zostało przejęte przez prawie_grupe_zorganizowaną.
Ale, ten przypadek jest inny…
Kiedy będziemy usiłowali się dostać do katalogu http://nirvanafan.org/magazin/s/ing czeka nas nie mała niespodzianka wykraczająca już poza zasięg działań przeciętnych phisherów. Przyjrzyjmy się działaniu całego mechanizmu przy użyciu sniffera.
1# Request:
GET /magazin/s/ing/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Accept-Language: pl
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: nirvanafan.org
Connection: Keep-Alive
2#Response
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2007 15:15:59 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.3 mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a
X-Powered-By: PHP/5.2.3
Connection: close
Content-Type: text/html; charset=win-1251
Content-Encoding: gzip
Content-Length: 771
Content-encoded entity body (gzip): 771 bytes -> 4894 bytes
Binary Data:
Celowo nie wklejałem zawartości tego pakietu ponieważ dane są pakowane gzip’em.
Na nasze szczęście Wireshark daje możliwość obejrzenia danych z sesji http
po dekompresji. Rzućmy na nie okiem:

Już lepiej ,lecz dalej nic konkretnego. Interesujące, są dwa js’y, które postaramy się przedstawić w bardziej przejrzystej formie.

[+]Deobfuscated Javascripts[+]

W prosty sposób przy użyciu html’owego tagu textarea otrzymamy zawartość js w postaci plain-text, a sam kod js się nie wykona i tym samy nie będzie miał żadnego wpływu na działanie naszej przeglądarki. A tak wygląda ten zabieg:

Stronę taką można przygotować w paru linijkach jak widać powyżej, albo skorzystać już z gotowej, zawartej w iDefense [ Malcode Analysis Pack ].Po uruchomieniu tego fragmentu kodu w przeglądarce zawartość textarea przedstawia. się następująco:

Aha!, nareszcie kod wygląda przejrzyście. Jak widzimy tagi iframe ładują strony z obcego serwera, hym, od razu nasuwa, się pytanie czy aby na pewno includowane strony byłyby dla nas bezpieczne; ) ?Przyjrzymy się im bliżej w dalszej analizie. Warto wspomnieć, o tym iż zastosowanie stylu ‘display: none’ dla tagu iframe tworzy ten obiekt nie widzialny dla użytkownika przeglądającego stronę.

[+]Follow the src=[+]

Podczas analizy okazało się ,że obydwa linki przedstawione na screen’e powodują uruchomienie identycznego mechanizmu, także zajmiemy się badaniem rezultatów wywołania jednego z nich.
Request:
GET /traff.php?8429e639e8a91fe HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: alltraff.cn
Response:
HTTP/1.1 200 OK
Server: Apache/2
Content-Encoding: gzip
X-Pad: avoid browser bug
Content-encoded entity body (gzip): 150 bytes -> 229 bytes


Jak widać ponownie został użyty tag iframe do załadowania kolejnych stron, których zawartość warto będzie prześledzić, bo jak wskazuje jedno z pól nagłówka:
X-Pad: avoid browser Bug
,ich przeznaczenie nie stwarza żadnych wątpliwości.

[+]Fake path[+]

http://winhex.org/tds/in.cgi?5
Request:
GET /tds/in.cgi?5 HTTP/1.1
Referer: http://alltraff.cn/traff.php?18429e639e8a91fe
Host: winhex.org
Response:
HTTP/1.1 302 Found
Location: http://208.72.168.176/e-Z1odey1701/index.php
Set-Cookie: SL_5_0000=_1_; domain=winhex.org; path=/;
expires=Tue, 22-Jan-2008 04:03:16 GMT
Content-Encoding: gzip
Content-Length: 170
Content-encoded entity body (gzip): 170 bytes -> 216 bytes


Meta tag URL, wymusza na przeglądarce odświeżenie strony wraz z przekierowaniem na wskazany przez niego adres, czyli w naszym wypadku http://208.72.168.176/e-Z1odey1701/index.php.
Request:
GET /e-Z1odey1701/index.php HTTP/1.1
Host: 208.72.168.176
Referer: http://alltraff.cn/traff.php?18429e639e8a91fe
Response:
HTTP/1.1 200 OK
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/4.4.4-8+etch3 mod_perl/2.0.2 Perl/v5.8.8
Line 1 : ai siktir vee? ->translate->’get lose’
Cała ścieżka wskazana przez http://winhex.org/tds/in.cgi?5 okazała się fałszywa, jedynie utrudniająca i wydłużająca analizę.
Przeanalizujmy teraz ścieżkę związaną z wywołaniem:
http://5yearscontract.com/check/versionl.php?t=578
Request:
GET /check/versionl.php?t=578 HTTP/1.1
Referer: http://alltraff.cn/traff.php?18429e639e8a91fe
Host: 5yearscontract.com
Response:
HTTP/1.1 200 OK
Server: Apache/2.2.6 (Unix) PHP/5.2.5


Jak widać wywołanie /check/versionl.php?t=578 kończy się załadowaniem
7 rożnych stron. Uchylając rąbka tajemnicy powiem, że celem każdej z nich jest exploitacja przeglądarki, a w końcowej fazie pobranie malware’u na komputer ofiary. Tak ,tak nie jedna nie dwie, a 7 witryn zawierających złośliwy kod!!!Jako, że różnice w powyższych plikach, są niewielkie(różne język programowania wykorzystany do napisania skryptu oraz odmienna lista kontrolek ,które maja zostać wyexploitowane) to omówię jedynie parę wybranych.

[+]Evil n140xx sites[+]

Przyjrzymy się teraz zawartości następujących plików :
/n14041.htm
/n14042.htm
/n14048.htm

Jak możemy zauważyć większość kodu jest w postaci nie zdatnej do odczytania. Do uzyskania w miarę przejrzystego kodu użyjemy techniki stosowanej w poprzednich przypadkach.
A oto jej rezultat:

To co najbardziej widoczne jest na pierwszy rzut oka ,to różnica w językach programowania wykorzystanych do napisania tych dwóch skryptów(czyżby zapobiegawczo?), poza tym, ktoś postarał się o to żeby kodu nie czytało się zbyt łatwo i przyjemnie. Widać zastosowanie obfuscatora kodu, który utrudnia jego analizę(losowe nazwy funkcji, zmiennych, “łamanie” stringów).
Przyjrzyjmy się teraz bliżej skryptowi n14048.htm napisanemu w js:

Po wstępnej analizie osoby zorientowane w metodach exploitacji zauważą, że jest tu wykorzystana metoda zwana Heap Spraying, a podatność, którą stara się ten skrypt wykorzystać to:
“CLSID:A09AE68F-B14D-43ED-B713-BA413F034904”);
/* Vulnerabilit: WZFILEVIEW.FileViewCtrl.61
http://www.zerodayinitiative.com/advisories/ZDI-06-040.html
*/
(oczywiście kod został wcześniej przeze mnie poprawiony pod kątem nazw zmiennych, itp.)
Spójrzmy jeszcze na koniec na plik n14041.htm

Jak widzimy lista kontrolek do exploitacji jest spora.
Jeżeli exploitacja zakończy się sukcesem to tak jak wcześniej wspominałem zostanie pobrany plik(ie_updates3r.exe) z lokalizacji zaznaczonej zieloną ramką, po czym zostanie on uruchomiony na komputerze ofiary.
Dalszy przebieg wydarzeń jest już zależny od chwilowej fantazji panów z RBN’u :).