Stan zagrożeń w internecie znajduje się obecnie na poziomie standardowym. Nie występują duże epidemie a eksperci z Kaspersky Lab nie zanotowali żadnych poważnych incydentów związanych z bezpieczeństwem. Poziom zagrożenia: 1

Rustock - mit czy rzeczywistość?


Alexander Gostev
Starszy analityk wirusów, Kaspersky Lab

Nieuchwytny rootkit

W grudniu 2006 roku wśród badaczy rootkitów (zarówno czarnych, jak i białych kapeluszy), rozeszły się pogłoski o tym, że ktoś stworzył i wypuścił "całkowicie niewykrywalnego" rootkita, znanego jako Rustock.C, którego nie można wykryć na komputerach, na których jest aktywny, przy pomocy żadnego istniejącego rozwiązana do zwalczania wirusów czy rootkitów.

Długie poszukiwania "mitycznego rootkita" okazały się bezowocne. W rezultacie, wszelkie informacje o rootkicie Rustock.C traktowane były w kręgach badaczy rootkitów jak żart. Sytuacja ta trwała do maja 2008 roku.

Diagnoza "lekarska"

Na początku maja rosyjska firma Dr.Web poinformowała społeczność antywirusową, że ich eksperci wykryli nowego rootkita o nazwie Ntldrbot, znanego również jako Rustock.C. Wiadomość ta była równie nieprzyjemna co sensacyjna.

Według firmy Dr.Web, rootkit uniknął schwytania przez producentów antywirusowych od października 2007 roku. Pojawiły się głosy, że Rustock.C został wykorzystany do stworzenia jednej z największych dzisiaj sieci zombie służącej do rozsyłania spamu. Dr.Web powoływał się również na badanie przeprowadzone przez Secure Works, według którego botnet stworzony przy użyciu rootkita Rustock stanowił trzecią pod względem wielkości sieć zombie, zdolną do rozesłania w ciągu jednego dnia nawet do 30 bilionów wiadomości spamowych. Jednak szacunki Secure Works nie mogły mieć nic wspólnego z nowo wykrytym rootkitem, ponieważ aż do maja 2008 roku był on nieznany. Eksperci Secure Works mieli najprawdopodobniej na myśli botnet stworzony przy użyciu wcześniejszych wariantów rootkita Rustock - A oraz B (Trojan-Clicker.Win32.Costrat i SpamTool.Win32.Mailbot, według klasyfikacji firmy Kaspersky Lab).

Z informacji opublikowanych przez firmę Dr.Web wynika, że jej eksperci zdobyli próbkę prawdziwego rootkita Rustock.C pod koniec marca 2008 roku. Ponad miesiąc zajęło im analizowanie kodu rootkita, stworzenie i opublikowanie narzędzi umożliwiających wykrywanie i leczenie. Inne firmy antywirusowe zostały poinformowane o wynikach dopiero później.

Stworzony przez firmę Dr.Web opis rootkita pozostawiał zbyt wiele pytań bez odpowiedzi. Po pierwsze, nie było jasne, w jaki sposób i kiedy rozprzestrzenił się rootkit i dlaczego od października 2007 roku nikt nie zdołał go wykryć.

Rozpowszechnianą przez firmę Dr.Web próbką kodu rootkita był sterownik Windows o rozmiarze 244 448 bajtów.

Niestety brakowało tak zwanego droppera, tj. pliku służącego do instalowania rootkita w systemie. Gdyby został dostarczony, bardzo ułatwiłby pracę laboratorium antywirusowego, polegającą na analizowaniu rootkita i opracowywaniu procedur wykrywania i leczenia rootkita Rustock.C. Ponadto mógłby pomóc wyjaśnić, w jaki sposób został rozprzestrzeniony ten rootkit.

Nie pojawiły się żadne wiarygodne informacje dotyczące występowania rootkita "na wolności". Równie dobrze Rustock.C mógł być jedynie okazem w kolekcji jakiegoś "zbieracza" i nie był rozprzestrzeniany, co wyjaśniałoby, dlaczego znalezienie go zajęło tak dużo czasu.

Analiza laboratoryjna

2 maja firma Kaspersky Lab rozpoczęła dogłębną analizę kodu rootkita. Zadanie, przed jakim stanęli nasi eksperci, było naprawdę trudne, ponieważ cały kod rootkita został zaszyfrowany przy pomocy nieznanej metody i nie mógł zostać zanalizowany przy pomocy zwykłej analizy skompresowanego kodu oraz technik emulacji. Sytuacje komplikował dodatkowo fakt, że każdy plik rootkita posiadał pewien rodzaj połączenia sprzętowego z zainfekowanym komputerem i nie mógł być wykonany ani analizowany na innych komputerach czy wirtualnych maszynach.

Jednak nasi eksperci potrzebowali tylko dwóch dni, aby pokonać te trudności, złamać klucz i odszyfrować większość ciała rootkita. Wieczorem 14 maja mogliśmy oglądać fragmenty prawdziwego kodu rootkita Rustock.C.

Podczas szukania rozwiązania skomplikowanego problemu technicznego, który opisaliśmy wyżej, próbowaliśmy również znaleźć plik, który zainstalował rootkita w systemie, ponieważ pomogłoby to nie tylko przyspieszyć proces analizy kodu rootkita, ale również ustalić źródła rozprzestrzeniania rootkita Rustock.C.

W wyniku naszego badania znaleźliśmy 599 plików rootkita Rustock.C. Niektóre z nich stanowiły tak zwane czyste ciało rootkita, inne były zainfekowanymi sterownikami systemowymi. W rzeczywistości wszystkie pliki były wynikiem polimorficznych zmian dokonanych w tym samym kodzie.

Kiedy stworzono rootkita?

Mieliśmy więc sześćset plików różnych rozmiarów, które zostały schwytane w nasze pułapki w innym czasie. Wszystkie te pliki zostały zebrane w okresie od 10 września 2007 roku do 14 maja 2008 roku. Wyprzedzając trochę opis zdarzeń, można w tym miejscu powiedzieć, że nigdy nie znaleźliśmy próbek rootkita Rustock.C, które zostały stworzone przed wrześniem 2007 roku. Możliwe, że wcześniej powstało kilka wariantów dla celów testowych. Jednak rootkit, który Dr.Web określa jako Ntldrbot, z pewnością pochodzi z września 2007 roku.

A co z pogłoskami o rootkicie Rustock.C, jakie krążyły pod koniec 2006 roku? Uważamy, że w tym czasie Rustock.C jeszcze nie istniał. Został stworzony prawdopodobnie w odpowiedzi na histerię, jaka towarzyszyła poszukiwaniu go. Świadczy o tym fakt, że nazwa szkodliwego programu zawarta w kodzie rootkita brzmi "Rustock.C". Nazwa ta różni się od tych, które autor nadał wariantom Rustock.A i B ('spambot' plus numer wersji). Nazwa Rustock została nadana przez firmę Symantec pierwszym wariantom rootkita pochodzącym z 2005 i 2006 roku. Takiej nazwy użyli badacze rootkitów, a "nieuchwytny" rootkit otrzymał nazwę Rustock.C poprzez analogię do znanych wariantów Rustock.A i .B. Być może autor nadał tę nazwę nowemu rootkitowi, aby potwierdzić, że pogłoski o jego istnieniu są prawdziwe.

Niezależnie od tego, jak było naprawdę, pierwsze "działające" próbki rootkita Rustock.C pojawiły się we wrześniu 2007 roku, a jego rozwój rozpoczął się kilka miesięcy wcześniej.

Modyfikacje

Analiza 599 dostępnych plików ujawniła wiele interesujących faktów, które wcześniej nie były znane.

Zidentyfikowaliśmy cztery modyfikacje rootkita Rustock.C.

Wariant C1 pojawił się 10 września 2007 roku. "Czyste ciało" rootkita ma rozmiar od 244 440 do 244 512 bajtów i zawiera sterownik oraz DLL. Taką modyfikację zbadali eksperci z firmy Dr.Web i zaprezentowali innym producentom antywirusowym.

Wariant C2 pojawił się 26 września. Jego rozmiar wynosi od 158 432 do 158 464 bajtów.

Warianty C3 i C4 zostały stworzone 9 i 10 października 2007 roku. Ich rozmiar waha się od 158 400 do 158 496 bajtów.

Mimo że modyfikacja C1 jest o prawie 100 KB większa niż te, które pojawiły się później, pomiędzy nią a innymi modyfikacjami nie widać dużych różnic. Autor zoptymalizował tylko algorytm zaciemniana dla ciała rootkita. Kod DLL (spambot) niewiele różni się w poszczególnych wariantach.

Spambot

Analiza rootkita zajęła nam pięć dni: został on całkowicie rozpakowany i wykonany na wirtualnych maszynach (mimo że nie posiadaliśmy "droppera"). Pozwoliło to uzyskać dostęp do kodu DLL (spambot), którego ochrona i utrzymanie jest głównym celem rootkita Rustock.C.

Podczas swojego działania rootkit wypakowuje ze swojego ciała bibliotekę DLL i wykonuje ją w pamięci systemu, wstrzykując ją do procesu winlogon.exe. Biblioteka DLL istnieje tylko w pamięci RAM i nigdy nie jest obecna na dysku twardym w postaci pliku. Jej celem jest wysyłanie spamu z zainfekowanego komputera. Aby wykonać to zadanie, łączy się z serwerem pod adresem 208.66.194.215 i otrzymuje od niego szablony wiadomości. Adres IP należy do amerykańskiego dostawcy usług hostingowych MCCOLO, którego zasoby od dłuższego czasu były wykorzystywane do rozprzestrzeniania szkodliwych programów i utrzymywania stron cyberprzestępczych.

Wykrywanie i leczenie

Mimo różnych metod wykorzystywanych przez autora rootkita Rustock.C w celu ochrony jego ciała (łącznie z programem szyfrującym i kluczem szyfrowania), dodanie rootkita do baz antywirusowych firmy Kaspersky Lab nie stanowiło żadnego problemu. Wygląda na to, że ktokolwiek stworzył tego rootkita, był tak pewny jego skuteczności, że nie przywiązywał zbytniej wagi do zabezpieczenia go przed ochroną antywirusową. Autor chciał utrudnić analizę kodu szkodnika (zarówno przez producentów antywirusowych, jak i innych twórców wirusów), przedłużyć czas potrzebny na taką analizę.

Leczenie plików systemowych zainfekowanych przez rootkita jest bardziej problematyczne. Działanie rootkita polega na infekowaniu wyłącznie sterowników Windows stworzonych przez firmę Microsoft, które uruchamiają się wraz ze startem systemu. Właśnie w ten sposób rootkit zdołał zarówno przejąć system, jak i ukryć swoją obecność. Pierwotny sterownik, który został zainfekowany, był przechowywany w ostatniej sekcji ciała rootkita i również był zaszyfrowany.

Algorytm wykorzystywany przez rootkita do szyfrowania zainfekowanego przez siebie sterownika okazał się dość prosty i w żaden sposób nie był związany ze sprzętem zainfekowanego komputera. Dzięki temu mogliśmy w pełni zaimplementować wykrywanie i leczenie.

Rootkit ten został sklasyfikowany jako Virus.Win32.Rustock.a, ponieważ w rzeczywistości jest on w pełni funkcjonalnym wirusem plikowym działającym w trybie jądra.

Kaspersky Lab opublikował procedury wykrywania i leczenia zainfekowanych plików 20 maja 2008 roku (8 dni po tym, jak rozpoczęto badania nad rootkitami).

W nowej wersji produktów antywirusowych firmy Kaspersky Lab - Kaspersky Anti-Virus 2009 oraz Kaspersky Internet Security 2009 - w pełni zaimplementowano wykrywanie rootkita Rustock.C, który jest aktywny w zainfekowanym systemie, oraz leczenie zainfekowanych plików. Użytkownicy innych wersji mogą skanować swoje komputery w celu wykrycia Rustocka przy użyciu Dysku Ratunkowego dla dowolnej wersji produktów antywirusowych firmy Kaspersky Lab. Produkty te wykrywają również i leczą podejrzane pliki pod warunkiem, że infekcja nie jest aktywna na komputerze.

Pytania i odpowiedzi

Wydawałoby się, że problem znalazł rozwiązanie: rootkit został zwalczony, a jego ofiary otrzymały niezawodne rozwiązanie do wykrywania i usuwania tego zagrożenia. Jednak zasadnicze pytania pozostawały bez odpowiedzi: w jaki sposób Rustock rozprzestrzeniał się i czy naprawdę istnieje "na wolności"? Znalezienie odpowiedzi na te pytania były dla nas sprawą honoru.

Rozprzestrzenianie Rustocka

Przez kilka dni wszystkie dostępne próbki rootkita były dokładnie analizowane w celu zidentyfikowania ich "ustawień sprzętowych". W ten sposób moglibyśmy mniej więcej określić, na jaką skalę został rozprzestrzeniony Rustock. Dane te zostały porównane z datami wykrycia każdej z tych próbek.

W okresie od 10 września do 23 listopada 2007 roku znaleźliśmy 599 próbek, z czego 590 zostało przechwyconych przez nasze pułapki. Tylko 9 uzyskaliśmy w okresie od 23 listopada 2007 do połowy maja 2008 roku.

Statystyki te posłużyły nam do zawężenia poszukiwań i porównania plików z czterema modyfikacjami znanego nam rootkita.

Analiza dała następujące wyniki:

Modyfikacje Daty wykrycia Okres(y) epidemii Liczba plików
C1 10 września 2007 10-13 września 2007 321
C2 26 września 2007 27 września – 9 października 2007;
12 – 22 listopada 2007
199
C3 9-10 października 2007 9 – 17 października 2007;
12– 22 listopada 2007
31
C4 9-10 października 2007 9 – 17 października 2007;
12– 22 listopada 2007
48

W okresie od 17 października 2007 do 12 listopada 2007 roku nie wykryliśmy żadnego rootkita Rustock. Jednak w okresie od 12 do 22 listopada nastąpił nowy wzrost aktywności, która dotyczyła głównie modyfikacji C2 (która pojawiła się 26 września), w mniejszym zaś stopniu modyfikacji C3 i C4.

Od 23 listopada 2007 roku Rustock był przez kilka miesięcy nieaktywny (lub zniknął na dobre?).

Zebrane dane okazały się bardzo użyteczne, wciąż jednak nie było jasne, na jaką skalę rozprzestrzeniał się Rustock, ani też jakie metody zostały użyte w celu jego dystrybucji. Mimo całego wysiłku nie udało się zidentyfikować "droppera" rootkita.

W końcu jednak dopisało nam szczęście. Znaleźliśmy ponad 500 dodatkowych plików rootkita, które stanowiły wszystkie brakujące ogniwa w łańcuchu.

Botnet

Nasze przypuszczenie, że aktywna dystrybucja Rustocka rozpoczęła się 10 września 2007 roku potwierdziło się. Teraz dokładnie wiemy, w jaki sposób i z jakich serwerów rootkit został pobrany i zainstalowany na komputerach. Znamy też odpowiedzi na takie pytania, jak "Gdzie jest dropper?" oraz "Czy użytkownicy produktów antywirusowych naprawdę byli bezbronni wobec nieuchwytnego rootkita, który rozprzestrzeniał się przez przynajmniej trzy miesiące?".

Niestety, metoda i kanały wykorzystywane do dystrybucji Rustocka zaniepokoją wielu ekspertów bezpieczeństwa IT. Każdemu specjaliście z zakresu rozwiązań antywirusowych nie będą obce następujące nazwy:

CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Tak, po raz kolejny mamy do czynienia z jedną z najbardziej znanych grup cyberprzestępczych w Internecie, a powyższe nazwy dotyczą stron internetowych i szkodliwych programów. Gang ten istnieje od początku 2004 roku lub dłużej i nadal jest aktywny. Najbardziej znanymi i najszerzej rozpowszechnionymi tworami tej grupy były takie trojany, jak Harnig, Tibs, Femad, LoadAdv i różne modyfikacje trojana Trojan-Downloader.Agent i Small, jak również Inject Trojan.

Grupa ta od zawsze należała do awangardy pod względem innowacyjności wirusów: jako pierwsza zastosowała na dużą skalę trojany downloadery w plikach chm; to właśnie na jej serwerach znaleziono pierwsze warianty exploitów wykorzystujących luki w zabezpieczeniach przetwarzania plików ANI i ICO. To właśnie ta grupa wykorzystywała trojany napisane w języku programowania Java (Trojan-Downloader.Java.ClassLoader) i zapoczątkowała modę na downloadery skryptowe.

Znakiem rozpoznawczym grupy IFrameBiz były domeny w obszarze .biz i nazwy plików w formacie loadadv*.exe.

Ślady grupy prowadzą do Rosji, gdzie bez wątpienia mieszka większość jej członków. W początkowych etapach swojego istnienia grupa ta w dużym stopniu wykorzystywała zasoby hostingowe zlokalizowane w St. Petersburgu. Wiadomo również, że współpracowała z niesławną siecią RBN (Russia Business Network), którą wielu ekspertów wiąże z tym miastem.

W ciągu czterech lat swego istnienia grupa stworzyła jeden z najpotężniejszych obecnie systemów rozprzestrzeniania szkodliwych programów. Jej botnet, złożony z milionów komputerów zainfekowanych różnymi trojanami downloaderami (głównie Tibs i Femad ) potrafi w bardzo krótkim czasie zainstalować dowolny nowy szkodliwy program na zainfekowanym komputerze. Obecnie jest to najlepsza alternatywa dla wysyłania szkodliwego kodu za pośrednictwem poczty elektronicznej, metoda, z którą branża antywirusowa już dawno wie, jak sobie radzić.

Botnet IFrameBiz jest aktywnie wykorzystywany w celu rozprzestrzeniania nowych szkodliwych programów. Klienci płacą za czas, w którym ich trojany będą rozprzestrzeniane za pośrednictwem botnetu. Następnie trojany są pobierane na zainfekowane maszyny. Powszechną praktyką jest instalowanie przez tego samego downloadera (np. Tibs ) kilku trojanów od różnych klientów. Istnieje spore zapotrzebowanie na taką usługę, a klienci nie mają pojęcia, że ich zlecenia są realizowane w tym samym czasie co zlecenia kilku innych klientów.

Usługi oferowane przez botnet IFrameBiz były i są wykorzystywane przez twórców wielu programów adware, przez osoby, które chcą stworzyć swoje własne botnety, spamerów, osoby przeprowadzające ataki DDoS itd. Można powiedzieć, że sieć RBN stanowi sprzętowo-techniczną część biznesu twórców wirusów, natomiast IFrameBiz część programową, jak również punkt startowy dla licznych szkodliwych programów.

Autorzy Rustocka złożyli zamówienie na rozprzestrzenianie swojego rootkita za pośrednictwem botnetu IFrameBiz latem 2007 roku. Stworzono zupełnie nowy moduł rozprzestrzeniania rootkita za pośrednictwem kanałów IFrameBiz. Być może trojany IFrameBiz nie potrafiły niezauważenie aktywować Rustocka w systemach użytkownika, może autorzy rootkita chcieli zachować kod rootkita w tajemnicy, obawiając się, że ich pomysł lub technologia zostaną skradzione.

Rekonstrukcja zdarzeń

Poniższy przykład pokazuje, co zdarzyło się pod koniec września 2007 roku na zainfekowanym komputerze, który stanowił część botnetu IFrameBiz.

Downloader (prawdopodobnie Tibs) zainstalowany w systemie łączy się z jednym z serwerów botnetu w strefie .hk (tj. Chorwacja - grupa ta zaczęła wykorzystywać domeny w tej strefie w 2007 roku) i próbuje pobierać plik loadadv351.exe.

Plik ten jest ulepszonym modułem tego samego botnetu - Trojan.Win32.Inject.mt zgodnie z klasyfikacją stosowaną przez firmę Kaspersky Lab. Nazwa odzwierciedla działanie tego szkodliwego programu: wstrzykiwanie swojego kodu do procesu Explorer.exe. Dzięki temu trojan może obejść wiele różnych zapór sieciowych i bez ograniczeń pobierać pliki do systemu.

Trojan przesyła raporty o pomyślnej instalacji do serwerów IFrameBiz i otrzymuje od nich polecenia, mówiące mu, które pliki powinny zostać pobrane i skąd. Raporty te pełnią również funkcję systemu statystycznego rodzajów dla botnetu, pozwalając ich właścicielom na śledzenie liczby pomyślnych pobrań szkodliwych programów i dostarczanie raportów klientom.

Trojan pobiera kilka plików z różnych serwerów - z serwerów klienta lub z zasobów klienta na serwerach IFrameBiz. W takim przypadku, pliki są ładowane z zasobów klienta wydzierżawionych od IFrameBiz (http:// *.biz/progs/*). Jednocześnie zbierane są i wysyłane informacje o zainfekowanym komputerze, łącznie z systemem operacyjnym, dyskiem twardym itd. Informacje te są niezbędne w celu określenia statusu botnetu, jego dystrybucji geograficznej itd.

W rezultacie, w systemie pojawia się kilka nowych plików. Interesują nas szczególnie dwa z nich: nazwijmy je '1.exe' i '2.exe'. Na razie skoncentrujemy się na pliku 1.exe (plikowi 2.exe przyjrzymy się później).

Plik ten jest kolejnym downloaderem, aczkolwiek raczej niezwykłym. Jego pierwsza próbka została wykryta przez Kaspersky Lab 10 września 2007 roku, w dniu, w którym pojawiły się pierwsze warianty Rustocka. W świetle faktów opisanych wyżej, trudno nazwać to dziwnym zbiegiem okoliczności. Od tego samego dnia produkty Kaspersky Lab wykrywały tego downloadera jako Trojan-Downloader.Win32.Agent.ddl.

Szkodliwy program zawiera sterownik, który ładuje się do jądra systemu operacyjnego (innymi słowy mamy tu do czynienia z rootkitem). Kod sterownika jest zaszyfrowany przy użyciu zaawansowanego algorytmu szyfrowania, bardzo podobnego do algorytmu wykorzystanego do szyfrowania Rustocka.

Po usunięciu wszystkich warstw ochrony ze sterownika, ukazuje się interesująca część: downloader dla Rustocka jest nie mniej "mityczny" niż sam rootkit.

Brakujące ogniwo

Mimo że pogłoski o rootkicie Rustock krążyły już od grudnia 2006 roku, pierwszy i jedyny raz, gdy wspomniano o rzeczywistym istnieniu downloadera, miał miejsce pod koniec października 2007 roku, prawie dwa miesiące po tym, jak został wykryty i dodany do naszych antywirusowych baz danych. Nie powinno nas zatem dziwić, że skoro Rustock.C wymknął się badaczom antywirusowym, nikt nie zastanawiał się nad jego downloaderem.

Jednak nawet po wykryciu rootkita Rustock.C, gdy należało rozpocząć poszukiwania jego "droppera", niektóre firmy antywirusowe pomyślały, że wykrycie rootkita wystarcza. Nie tracili czasu na ustalanie, w jaki sposób rootkit zdołał przedostać się do komputerów użytkowników i czy użytkownicy nie byli zabezpieczeni przed nieuchwytnym rootkitem.

Nasze badanie dostarczyło odpowiedzi na oba te pytania. 10 września 2007 roku, tj. pierwszego dnia, w którym Rustock.C został rozprzestrzeniony za pośrednictwem botnetu IFrameBiz, oprogramowanie Kaspersky Anti-Virus wykryło jego "droppera": był to Trojan-Downloader.Win32.Agent.ddl. Następnie wielu producentów antywirusowych dodało sygnaturę tego trojana do swoich antywirusowych baz danych.

Przez kilka miesięcy komputery użytkowników mogły być chronione przed infekcją nieuchwytnego rootkita jedynie poprzez niezwłoczne wykrycie jego downloadera.

Niestety nawet dzisiaj (początek czerwca 2008) niektóre produkty antywirusowe nadal nie wykrywają trojana Agent.ddl.

Downloader

Jak już wspomnieliśmy wcześniej, trojan składa się z dwóch komponentów: ciała i sterownika. Sterownik zbiera następujące informacje o systemie: identyfikatory producenta, model urządzenia dla płyty głównej, jak również datę instalacji i dokładną wersję systemu operacyjnego. Informacje te są następnie szyfrowane i wysyłane do serwera autora Rustocka (lub jego klientów): 208.66.194.215.

Serwer, do którego wysyłane są dane (208.66.194.215), jest tym samym, który został wykorzystany dla biblioteki DLL rootkita (spambot): jest to źródło wiadomości spamowych wysyłanych przez Rustocka. Jednak metoda stosowana przez sterownik downloadera w celu interakcji z serwerem jest inna niż metoda wykorzystywana przez spambot.

Sterownik Agent.ddl działa bezpośrednio z wirtualnym narzędziem TCP/IP, z pierścienia 0, uniemożliwiając wykrywanie ruchu wychodzącego przy użyciu pewnych programów nadsłuchujących i/lub zapór sieciowych na komputerach z aktywnymi infekcjami. Agent.ddl ustanawia połączenie na porcie 443, próbując zamaskować swoje dane jako pakiety HTTPS. W rezultacie, nawet gdy badacze przechwycą ruch na bramie, mogą nie wiedzieć, że w rzeczywistości nie mają do czynienia z danymi HTTPS, ale z zaszyfrowanymi danymi zebranymi na zainfekowanym komputerze.

Poniżej przedstawiamy przykład pakietu z zainfekowanej maszyny, który został zamaskowany jako dane HTTPS:

Wraz z każdym uruchomieniem sterownika zmienia się klucz szyfrowania. Wykrywanie zostaje utrudnione, ponieważ zewnętrzny obserwator nie zna algorytmu i klucza szyfrowania.

Należy wspomnieć, że autorzy trojana downloadera próbowali utrudnić życie każdemu, kto chciał zbadać kod sterownika tak bardzo jak to możliwe.

Adres IP serwera centralnego oraz numer portu, na którym sterownik ustanawia połączenia, są zakodowane w ciele programu w taki sposób, aby ukrywały swoją funkcję:

push 00000BB01 ; port – 443
push 0E00C04E1
sub d,[esp],00849C211; różnica to 0xD7C242D0, czyli adres IP
208.66.194.215

Autorzy włożyli również wiele wysiłku w zaciemnienie swojego kodu. Na przykład prosta operacja:

mov [eax], ecx

po zaciemnieniu wygląda następująco:

push ebx
mov ebx, 0x03451b8c
sub ebx,eax
sub ebx, 0x03451b8c
neg ebx
mov [ebx], ecx
pop ebx

Jedno polecenie zostało zastąpione siedmioma. Można więc sobie wyobrazić, jak wygląda reszta sterownika!

Wróćmy teraz do komunikacji sieciowej. Szkodliwy kod wysyłał do serwera pakiet z informacjami o zainfekowanym komputerze. W odpowiedzi na otrzymane dane serwer prawdopodobnie wysłał plik, który został specjalnie zaszyfrowany dla określonej maszyny, z kluczem pasującym do sprzętu komputera, z którego otrzymano pakiet.

W ten sposób autorzy rozwiązali problem wykrycia, zbadania i uruchomienia droppera przez zewnętrznych analityków, dzięki czemu nie musieliby znajdować klucza szyfrowania w celu zbadania kodu rootkita.

Wygenerowany plik rootkita, jego "czyste ciało", jest pobierany na atakowaną maszynę, na której jest uruchamiany przez trojana Agent.ddl. Rustock.C infekuje swój pierwszy sterownik systemowy, dodając kolejny komputer do nowego botnetu spamowego.

Serwer wykorzystywany przez rootkita Rustock.C jest teraz zablokowany. Wszystkie wysyłane do niego pakiety są filtrowane przez routery sieciowe. Wydaje się, że organy ścigania interesują się teraz również tym adresem IP.

Wnioski

Rekonstrukcja zdarzeń dokonana przez naszych ekspertów pokazuje, że rootkit rozprzestrzeniał się aktywnie od września do listopada 2007. Wykorzystanie sieci IFrameBiz mogło zapewnić mu szerokie rozpowszechnienie. Jednocześnie opisane wyżej fakty wskazują na to, że nieuchwytność rootkita wynikała z wysokiego poziomu szyfrowania jego kodu i zastosowania licznych technik zapobiegających debugowaniu, które utrudniały jego analizę przez większość ekspertów.

Producenci antywirusowi mieli tego rootkita od momentu pojawienia się go "na wolności". Od mniej więcej tego samego czasu większość produktów antywirusowych, z bardzo nielicznymi wyjątkami, zapewniało wykrywanie jego aktywności podczas instalacji w systemie, jak również wykrywanie komponentów odpowiedzialnych za jego instalację i dystrybucję. Przy pomocy prostych narzędzi do monitorowania zmian w systemie plików łatwo można było uniemożliwić mu przedostanie się do systemu.

Mimo że w przypadku Rustocka miało to miejsce kilkanaście razy, jego kod nie został szczegółowo zanalizowany aż do maja 2008 roku.

Rustock.C rzeczywiście istnieje, nie jest żadnym mitem. Mitem natomiast jest nieuchwytność tego rootkita: nie wynika ona z żadnych nadzwyczajnych możliwości maskowania tego szkodnika, ale opiera się na pogłoskach, jakie pojawiły się pod koniec 2006 roku i działały na korzyść autorów szkodliwego oprogramowania.

Tylko rootkit stworzony z myślą o istniejących możliwościach wykrywania będzie potrafił obejść środki ochrony zapewniane przez takie systemy. Wojna na poziomie jądra sprowadza się do pytania, kto będzie pierwszy - rootkit czy rozwiązanie do ochrony przed rootkitami.

Celem autora Rustocka nie było stworzenie niewykrywalnego rootkita. Chciał jedynie utrudnić analizę szkodnika po jego wykryciu. Dzięki temu można było opóźnić moment wykrycia go przez rozwiązania antywirusowe w stosunku do rozpoczęcia jego dystrybucji.

Pozostaje tylko jedno pytanie: dlaczego w połowie października 2007 roku autor Rustocka przestał ulepszać swojego szkodnika i wypuszczać nowe warianty? Czy to znaczy, że rozpoczął nowy projekt i gdzieś istnieje już 'Rustock.D'?

Nie znamy jeszcze odpowiedzi na to pytanie, jednak niezależnie od tego, jaka jest, pojedynczy szkodliwy program, nawet taki, który pozostawał niewykryty przez kilka miesięcy, nie wpływa na ogólną sytuację: każdego dnia pojawiają się tysiące innych szkodliwych programów skutecznie neutralizowanych przez rozwiązania antywirusowe.

W sytuacji, gdy Internet pozostaje domem dla IFrameBiz i innych podobnych grup, które każdego dnia rozprzestrzeniają setki nowych szkodliwych programów, włamują się na strony internetowe i wywołują liczne epidemie, nie ma sensu świętować pojedynczego zwycięstwa.

PS Wcześniej pisaliśmy, że Trojan.Win32.Inject.mt instalował dwa pliki w systemie - 1.exe oraz 2.exe - nie omówiliśmy jednak charakteru drugiego pliku.

Był to wariant Sinowala, trojana szpiegującego. Tego samego, który dwa miesiące po zdarzeniach opisanych w tym artykule przyprawił o ból głowy firmy antywirusowe i znany jest jako 'bootkit'.

Rustock i Sinowal były rozprzestrzeniane w tym samym czasie i za pośrednictwem tego samego botnetu. Nowe warianty Rustocka przestały pojawiać się w połowie października 2007 roku. Pierwsze próbki "bootkita" zostały wykryte miesiąc później, w listopadzie 2007 roku.

Czy to zbieg okoliczności? Może pewnego dnia dowiemy się.

Źródło:
Kaspersky Lab