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

Bootkit: wyzwanie 2008 r.


Sergey Golovanov
Alexander Gostev
Alexey Monastyrsky

W naszych raportach często pojawia się termin MalWare 2.0 oznaczający model złożonych szkodliwych programów, które pojawiły się pod koniec 2006 roku. Najbardziej typowymi przykładami, a zarazem pierwszymi reprezentantami MalWare 2.0, są robaki Bagle, Warezov oraz Zhelatin.

Model Malware 2.0 charakteryzuje się następującymi cechami:

  • brakiem jednego centrum kontroli sieci zainfekowanych komputerów
  • aktywnym wykorzystywaniem metod mających na celu uniemożliwienie analizy szkodliwego kodu oraz prób przejęcia kontroli nad botnetem
  • krótkotrwałymi masowymi wysyłkami szkodliwego kodu
  • skutecznym wykorzystywaniem socjotechniki
  • wykorzystywaniem szeregu różnych metod w celu rozprzestrzeniania szkodliwych programów i stopniowym odchodzeniem od wykorzystywania metod przyciągających uwagę (np. e-mail)
  • wykorzystywaniem wielu modułów (zamiast jednego) w celu dostarczania różnych szkodliwych funkcji

Ewolucja MalWare 2.0 przysparza branży antywirusowej wielu kłopotów. Największy problem, według nas, polega na tym, że tradycyjne rozwiązania antywirusowe, oparte wyłącznie na wykorzystywaniu sygnaturowej lub heurystycznej analizy plików, nie potrafią skutecznie zwalczać ataków wirusów (nie mówiąc już o leczeniu zainfekowanych systemów).

Spośród incydentów mających miejsce w 2008 roku reprezentujących zagrożenie, jakie stanowi MalWare 2.0, należy wspomnieć historię rootkita Rustock. (Szczegółowe informacje o tym rootkicie można znaleźć tutaj: http://www.viruslist.pl/analysis.html?newsid=498). W rootkicie tym zaimplementowano wiele nowych technologii, metod i podejść, które mogą mieć istotny wpływ na przyszłą ewolucję MalWare 2.0.

Najnowszy z takich incydentów, opisany w tym raporcie, jasno obrazuje współczesną sztukę wojny, jaka toczy się między twórcami wirusów a firmami antywirusowymi, i pokazuje wagę nowych technologii ochrony.

Interesujący incydent ponownego uruchamiania się komputerów

W połowie sierpnia na forach internetowych użytkownicy zaczęli się skarżyć, że po odwiedzeniu przez nich pewnych stron internetowych ich komputery zaczęły ponownie się uruchamiać. Co spowodowało takie zachowanie komputerów - nie wiadomo. Jedyne możliwe wyjaśnienie sugerowało, że przyczyna restartu komputerów znajduje się na odwiedzonych stronach.

Wstępne oględziny podejrzanych stron niczego nie ujawniły - strony okazały się nieszkodliwe. W większości przypadków, szkodliwi użytkownicy, którzy chcą zainfekować maszyny, włamują się na legalne strony i umieszczają odsyłacze do swoich zasobów, które zawierają exploity na tych stronach. Technika ta nosi nazwę 'drive-by download' (http://www.viruslist.pl/glossary.html?glossid=179). Gdy użytkownik odwiedzi zainfekowaną stronę, na jego maszynie zostanie zainstalowany szkodliwy kod, bez jego wiedzy czy zgody. Jednak na stronie niczego nie wykryto - żadnych podejrzanych ramek iframe czy skryptów.

Problem można było przypisać automatycznemu restartowi systemu Windows po zainstalowaniu aktualizacji; było to dość prawdopodobne, zwłaszcza że incydent ten zbiegł się w czasie z opublikowaniem przez firmę Microsoft najnowszej łaty. Sytuacja okazała się jednak o wiele poważniejsza.

Podczas przeprowadzania dochodzenia wykorzystaliśmy wiele maszyn wirtualnych, za pośrednictwem których odwiedzaliśmy podejrzane strony. Nie ograniczaliśmy się do odwiedzenia tych stron - aktywnie przechodziliśmy z jednej części strony do innej i klikaliśmy odsyłacze. Po pewnym czasie komputer testowy uruchomił się ponownie.

Analiza systemu wykazała zmiany w sektorze rozruchowym. Takie zmiany mogły wskazywać na obecność bootkita w systemie. O bootkitach i problemach, jakie mogą spowodować takie technologie, wspominaliśmy w naszym raporcie obejmującym pierwszy kwartał 2008 roku (http://www.viruslist.pl/analysis.html?newsid=492). Jednak od marca 2008 roku nie wykryto żadnych nowych wariantów bootkita. Czy to możliwe, że bootkit powrócił?

Podmienione odsyłacze

Gdy już ustaliliśmy, które strony i które odsyłacze powodowały restart komputerów użytkowników, mogliśmy przeprowadzić bardziej szczegółową analizę.

Jak się okazało, szkodliwi użytkownicy zastosowali stosunkowo oryginalne (aczkolwiek nie nowe) podejście do wstrzykiwania odsyłaczy. Do stron, na które włamali się, nie dodali własnej ramki iframe czy też skryptów, ponieważ tego typu modyfikacje są bardzo łatwe do wykrycia. Zamiast tego w miejsce "legalnych" odsyłaczy wstawiali "szkodliwe".

Legalny odsyłacz wyglądał tak: <a href="http://atm.n****.com">atm.n****.com

Po włamaniu się na stronę odsyłacz ten wyglądał tak: <a href="http://***.com/cgi-bin/index.cgi?dx"> atm.n****.com

Aby komputer został zainfekowany, użytkownik musiał nie tylko otworzyć stronę na zhakowanej witrynie, ale również kliknąć podmieniony odsyłacz. W ten sposób liczba potencjalnych ofiar zmniejsza się, ale nieznacznie, szczególnie jeśli odsyłacze są podmieniane ręcznie i starannie wybierane przez szkodliwych użytkowników.

Informacje o witrynach, takich jak ***.com/cgi-bin/index.cgi?dx, zaczęły pojawiać się w Internecie mniej więcej na początku czerwca 2008 roku. Były to głównie skargi właścicieli witryny oraz użytkowników legalnych witryn dotyczące dziwnych odsyłaczy, które pojawiły się w zaufanych zasobach. Stało się jasne, że w Internecie znajdowało się wiele takich "centrów infekcji"; jednak mimo wielu różnych nazw domen wszystkie z nich utrzymywane były na wspólnych serwerach.

Poniższy diagram pokazuje niewielką liczbę stron, które wykryliśmy:

butkit_1108_pic01s.png  enlarge.gif

butkit_1108_pic02s.png  enlarge.gif
Lokalizacja serwerów, które zainfekowały użytkowników bootkitem (zaczynając od lewej: nazwa domeny, adres IP serwera, podsieć, w której jest zlokalizowany serwer, autonomiczny system)

Spersonalizowane exploity

Co się stanie, gdy użytkownik kliknie podmieniony odsyłacz? Serwer przetworzy przychodzące zapytanie, uzyskując informacje o tym, z jakiej strony "przyszedł" użytkownik, jakiej używa przeglądarki, jakie zainstalował wtyczki, oraz zdobędzie adres IP użytkownika. Przy pomocy tych informacji serwer przydzieli użytkownikowi unikatowe ID, które zostanie następnie zapisane na serwerze.

Przykładem takiego ID przydzielanego odwiedzającemu przez zainfekowany serwer jest index.cgi@ac6d4ac70100f060011e964552060000000002e4f11c2e000300190000000006

Ostatnie cyfry ID pokazują, że użytkownik posiadał zainstalowaną szóstą wersję programu Acrobat Reader.

Dla każdego indywidualnego użytkownika tworzony jest następnie exploit. Jeśli na komputerze użytkownika zainstalowana jest podatna na ataki wersja Acrobata, na maszynę taką zostanie pobrany exploit PDF. Jeśli zainstalowany jest Real Player, zostanie pobrany exploit dla tego programu itd. W zależności od przydzielonego użytkownikowi ID serwer wygeneruje klucz zaciemniania, który zostanie wykorzystany w celu zaszyfrowania odpowiedniego exploita.

butkit_1108_pic03s.png  enlarge.gif
Przykład zaciemnionego exploita

W większości przypadków pobierane były exploity wykorzystujące luki w przetwarzaniu plików PDF, SWF oraz QuickTime. Lista luk w zabezpieczeniach wykorzystywanych przez szkodliwych użytkowników jest stosunkowo długa i nieustannie uaktualniana. Poniżej wymienione zostały najczęściej wykorzystywane luki w zabezpieczeniach:

  • CVE-2007-5659
  • CVE-2006-0003
  • CVE-2006-5820
  • CVE-2007-5779
  • CVE-2008-1472
  • CVE-2007-0018
  • CVE-2006-4777
  • CVE-2006-3730
  • CVE-2007-5779
  • CVE-2008-0624
  • CVE-2007-2222
  • CVE-2006-0005
  • CVE-2007-0015

Po stworzeniu exploita dla danego użytkownika szkodnik zaczyna działać na zaatakowanej maszynie poprzez niezabezpieczoną aplikację. W czasie gdy exploit działa na komputerze, pobierany jest trojan dropper. Program ten wykorzystuje unikatowe ID użytkownika oraz klucz serwera, które są przechowywane w bazie danych serwera.

Z zewnątrz wszystko wygląda całkowicie nieszkodliwie i nie wzbudza żadnych podejrzeń: po uruchomieniu exploita serwer zwraca rzeczywisty adres strony, którą użytkownik chciał odwiedzić, oraz stronę, do której prowadzi podmieniony odsyłacz kliknięty przez użytkownika. Ofiara uzyskuje dostęp do zasobu, do którego chciała uzyskać dostęp, nie zdając sobie sprawy, że komputer został podłączony do innego serwera i zainfekowany.

Ponadto, jeśli użytkownik ponownie kliknie podmieniony odsyłacz, exploit nie zostanie ponownie uruchomiony, ani nie nastąpi kolejna próba infekcji - użytkownik zostanie natychmiast przekierowany na legalna stronę. Zainfekowany serwer prowadzi bazę danych odwiedzających, przez co żadne ID nie jest wykorzystywane dwukrotnie.

Powrót Neosploita

Na jakiej podstawie wygenerowane zostały "indywidualne" exploity dla użytkowników? Ku naszemu zaskoczeniu, tu właśnie natknęliśmy się na coś, co uważaliśmy za przeszłość: panel administracyjny Neosploit.

Pakiet exploitów Neosploit znany jest od około połowy 2007 roku, gdy zaczęto sprzedawać go na czarnym rynku za kilka tysięcy dolarów (od $1 000 do $3 000). Stanowił on poważną konkurencję dla innych zestawów malware, takich jak MPack oraz IcePack.

Pod koniec 2008 roku pojawiły się informacje (http://ddanchev.blogspot.com/2008/07/neosploit-team-leaving-it-underground.html) (http://blogs.zdnet.com/security/?p=1598), jakoby znana grupa cyberprzestępców odpowiedzialna za stworzenie, dystrybucje i wsparcie Neosploita przestała istnieć.

Przedstawiciele tej grupy wydali następujące oświadczenie:

"Niestety, wspieranie naszego produktu nie jest już możliwe. Przepraszamy za wszelkie niedogodności, ale biznes to biznes i czas poświęcany temu projektowi nie przynosi korzyści. Przez ostatnie kilka miesięcy robiliśmy wszystko, aby zaspokoić potrzeby naszych klientów, jednak w pewnym momencie musieliśmy zaprzestać wsparcia. Byliśmy z wami przez 1,5 roku i mamy nadzieję, że był to dobry okres dla waszego biznesu".

Takie nagłe "zamknięcie interesu" oznacza zazwyczaj, że organy ścigania prowadzą dochodzenie przeciwko grupie lub przestępcy planują coś "większego" i przygotowują sobie alibi.

Ostatnią wersją Neosploita, stworzoną i sprzedawaną przed rozwiązaniem grupy, była wersja 2.0.17. Jednak na serwerze odpowiedzialnym za generowanie exploitów odkryliśmy panel administracyjny Neosploita w wersji 2.0.23.

butkit_1108_pic04s.png  enlarge.gif
Okno główne panelu administracyjnego

Mimo pozornego ograniczenia interfejs administracyjny Neosploita posiada szeroki zestaw funkcji.

butkit_1108_pic05.png 
Okno dialogowe dodawania nowego użytkownika do systemu

Panel administracyjny Neosploita, który został użyty do generowania exploitów, tworzenia i zarządzania bazami danych zainfekowanych użytkowników itd., jest plikiem wykonywalnym napisanym w języku programowania C++ i skompilowanym w taki sposób, aby mógł działać w systemach Linux i FreeBSD.

butkit_1108_pic06s.png  enlarge.gif
Panel administracyjny Neosploita od wewnątrz

butkit_1108_pic07s.png  enlarge.gif
Zdezasemblowany kod serwera odpowiedzialnego za zaciemnianie exploitów

Neosploit miał być umieszczany na stronach hostingowych i skonfigurowany w sposób zapewniający maksymalnie szybką instalację i uruchomienie. Jednak, z wykorzystywaniem Neosploita wiąże się jeden poważny problem, polegający na tym, że jest to produkt "komercyjny". Problem sprowadza się do tego, że zakupione wydanie Neosploita może być wykorzystywane tylko dla ograniczonej liczby połączeń - podobnie jak w przypadku produktów shareware, które mogą być wykorzystywane tylko do określonego momentu.

Każda próba zainfekowania użytkownika i wygenerowania exploita powoduje, że serwer Neosploit łączy się z serwerem, który prawdopodobnie rejestruje liczbę połączeń (w momencie przeprowadzania analizy serwer był zlokalizowany na Ukrainie). Autorzy Neosploita mogą monitorować wykorzystywanie swoich tworów i/lub opłaty za swoje usługi na podstawie liczby zainfekowanych użytkowników. Możliwe, że jeżeli nie będzie można nawiązać połączenia z serwerem, exploit nie zostanie wygenerowany, a użytkownik nie zostanie zainfekowany.

Bootkit

Po załadowaniu się do systemu trojan dropper uruchamia się poprzez niezabezpieczoną aplikację, wypakowuje z siebie program instalacyjny bootkita i wysyła do niego unikatowe ID użytkownika.

Następnie instalator modyfikuje sektor rozruchowy i umieszcza w sektorach dysku twardego główne ciało szkodliwego programu.

Przykład wpisu w obszarze startowym dysku

CreateFileA("\\\\.\\RealHardDisk0", GENERIC_WRITE | GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0x0, 0x0)

butkit_1108_pic08s.png  enlarge.gif
Przykład zainfekowanego głównego rekordu rozruchowego

Jeżeli wszystkie te działania zostaną pomyślnie wykonane w systemie, trojan dropper przesyła polecenie ponownego uruchomienia komputera. To właśnie ten nieoczekiwany restart systemu, który ma miejsce w czasie gdy użytkownik jest on-line, wzbudził podejrzenie użytkowników, którzy usiłując dociec, co się dzieje, zaczęli pisać o tym na forach.

Po powtórnym uruchomieniu komputera bootkit przechwytuje szereg funkcji systemowych i zaczyna działać w systemie - ukrywając swoje działanie i funkcjonując jako bot w sieci zombie.

butkit_1108_pic09_en.png 
Sekwencja infekcji użytkownika

Migrujące centrum kontroli

Wszystkie technologie, jakie wykryliśmy podczas analizowania mechanizmu przenikania, wyglądają interesująco; niektóre są oryginalne (na przykład podmienianie odsyłaczy, zaciemnianie exploitów w locie dla określonego systemu), ogólnie jednak żadna z nich nie jest unikatowa. Z podobnymi technologiami spotkaliśmy się już wcześniej, jednak przed sierpniem 2008 roku nie zdarzyło się, aby wszystkie z nich zostały wykorzystane w ramach jednego ataku.

Prawdziwa niespodzianka czekała na nas dopiero wtedy, gdy przeanalizowaliśmy działanie bota: centrum kontroli bota (C&C) nieustannie przesuwało się z jednej domeny do innej!

Na podstawie naszych obserwacji w ciągu jednego dnia centrum kontroli przesuwało się czasem 2 do 3 razy. Na przykład rano działało w domenie aykjfgves.com, w porze lunchu przeniosło się na dmiafgves.com, by wieczorem zajmować gfdpves.com. W rezultacie, zainfekowane komputery, które tworzyły część botnetu, aby móc się połączyć, zmuszone były nieustannie szukać aktywnego centrum kontroli.

Wykrycie takich botnetów jest bardzo trudne, a nawet gdy zostaną już wykryte, trudno je rozbić. Szkodliwy użytkownik może w każdej chwili przenieść centrum kontroli na dowolną z dziesiątek, lub nawet setek, specjalnie przygotowanych domen. Nawet gdy centrum kontroli zostanie zidentyfikowane, w ciągu kilku godzin zostanie przeniesione na inną domenę. A wtedy, aby je znaleźć, trzeba będzie analizować pakiety sieciowe wysyłane przez boty szukające swojego nowego domu.

Nie ma wątpliwości, że metoda ta ma na celu zarówno zwalczanie konkurencji, która może próbować ukraść botnet, jak również utrudnianie działnia firm antywirusowych i organów ściągania.

butkit_1108_pic10s.png  enlarge.gif
Przykład lokalizacji serwerów wykorzystywanych do zarządzania botnetem (od lewej do prawej: nazwa domeny, adres IP serwera, podsieć, w której są zlokalizowane serwery, autonomiczny system)

Generowanie nazw domen według specjalnego algorytmu oraz rejestrowanie powstałych domen umożliwia szkodliwemu użytkownikowi przemieszczanie centrum kontroli przez długi czas. W celu rejestrowania domen wykorzystuje się wiele zajmujących się tym organizacji pochodzących z różnych części świata: Ameryki, Afryki, Azji i Europy. Użyte przez właściciela dane rejestracyjne zawierają wyraźne ślady rosyjskie, chociaż same dane są bez wątpienia fałszywe.

Centrum kontroli wykorzystuje najróżnorodniejsze usługi hostingowe na świecie, potrafi w ciągu kilku minut przenieść się do nowego hostingu, co uniemożliwia zamknięcie go, nie wpływa jednak negatywnie na jego funkcjonalność.

butkit_1108_pic11s.png  enlarge.gif
Przykład lokalizacji serwerów wykorzystywanych do dopasowywania nazw domen do adresów IP centrum kontroli (zaczynając od lewej strony: domena, adres IP serwera; podsieć, w której zlokalizowane są serwery, autonomiczny system)

Metoda ta przypomina technologię Fast-Flux, która jest aktywnie wykorzystywana przez robaki z rodziny Zhelatin (robak Storm). Jednak Fast-Flux pozwala tylko na ciągłą zmianę adresów IP zainfekowanych domen, podczas gdy technologia zaimplementowana w bootkicie umożliwia zmienianie domen jak również adresów IP.

Centrum kontroli zawiera bazę danych zarejestrowanych domen, które mogą być wykorzystane do hostingu centrum kontroli.

Przykład zarejestrowanych domen

ccuuuag.biz 67.228.229.122 zarejestrowana: 2008-08-07
ewwxbhdh.com 74.50.107.78 zarejestrowana: 2008-08-07
paiuuag.com 208.73.210.32 zarejestrowana: 2008-08-06
paiuuag.net 208.73.210.32 zarejestrowana : 2008-08-06

Podczas początkowego procesu infekcji, gdy uruchamiany jest exploit, maszyna ofiary pobiera bootkita, który ma pracować z aktywnym w danym momencie centrum kontroli. Gdy system zostanie ponownie uruchomiony i bootkit zacznie działać z pełną mocą, bot próbuje połączyć się z centrum kontroli. Szkodliwy program tworzy specjalnie spreparowany pakiet sieciowy przy użyciu ID zainfekowanego komputera i próbuje wysłać go do serwera kontroli, który posiada już informacje o zainfekowanych komputerach.

butkit_1108_pic12s.png  enlarge.gif
Przykład wysłanego pakietu

Jeżeli nie jest możliwe połączenie się z centrum kontroli, bot użyje specjalnego algorytmu, aby wygenerować nazwy domen .com, .net oraz .biz. Liczba wygenerowanych nazw domen zależy od aktualnej daty i czasu. Backdoor próbuje połączyć się z każdą z tych domen i wysłać specjalnie utworzony pakiet jako klucz autoryzacji.

butkit_1108_pic13s.png  enlarge.gif
Przykład szukania domen

Jak tylko jedna z domen okaże się tą "właściwą" (np. zaakceptuje pakiet i odpowie przez wysłanie własnego unikatowego pakietu), bot połączy się z nią jako klient botnetu i zacznie szyfrować komunikację z centrum kontroli. Z reguły w wyniku tej komunikacji na maszynę ofiary pobierany jest dodatkowy moduł (DLL).

butkit_1108_pic14_en.png 
Częściowy schemat funkcji bota

Moduł szpiegujący

Od początku 2008 roku botnet zbadało wielu ekspertów z branży, jednak badanie ograniczyło się do części rootkita i prób wyjaśnienia, w jaki sposób funkcjonuje botnet.

Badanie to - którego wyniki są nam znane - nie dało odpowiedzi na najważniejsze dla nas pytania: "Dlaczego?" lub, mówiąc inaczej: "gdzie w tym wszystkim są pieniądze?"

Opisując historię bootkita, chcieliśmy nadać ostateczne szlify. W tym celu musieliśmy dokładnie zrozumieć, co tak wyrafinowany bootkit ukrywał w systemie.

Po tym, jak maszyna ofiary połączy się z centrum kontroli botneta, uzyskuje zaszyfrowany pakiet o rozmiarze przekraczającym 200KB. Następnie bootkit odszyfrowuje ten pakiet, wewnątrz którego znajduje się plik DLL, który bootkit ładuje do pamięci, a który nie istnieje jako plik na dysku!

W rezultacie bootkit sprawia, że załadowany DLL jest niewidoczny podczas analizy systemu przy użyciu tradycyjnych metod. Jest również niewidoczny dla większości programów antywirusowych. Pamiętacie, co robił Rustock? On również ładował DLL do pamięci, był jednak obecny na dysku maszyny ofiary. Bootkit jest o wiele bardziej wyrafinowany.

Naturalnie, ładowanie kodu do pamięci oznacza, że podczas powtórnego uruchamiania systemu kod znika, przestaje istnieć, a system staje się czysty (z wyjątkiem obecności bootkita w systemie). Ma to jednak pewne plusy: program antywirusowy, który skanuje pamięć podczas startu systemu operacyjnego nie wykryje niczego podejrzanego - z tej prostej przyczyny, że nie ma niczego podejrzanego do wykrywania. Jednak, jak tylko komputer połączy się z Internetem, bootkit nawiązuje połączenie z centrum kontroli i ładuje DLL na maszynę ofiary.

Co robi DLL?

Przyjrzyjmy się historii Sinowala (tak bowiem klasyfikujemy tego bootkita). Pod koniec 2007 roku, gdy pojawił się bootkit, nazwa ta była już stosowana: duża liczba trojanów szpiegujących służących do kradzieży danych (głownie danych dostępu do kont bankowości online) otrzymywała nazwę Trojan-Spy.Win32. Sinowal.

Podczas analizy bootkita zauważyliśmy, że algorytm zaciemniania ciała bootkita był identyczny z algorytmem zaciemniania wykorzystywanym przez trojana o nazwie Trojan-Spy.Win32.Sinowal. Doszliśmy do wniosku, że autorzy bootkita i trojana szpiegującego to te same osoby. Przed przeprowadzeniem szczegółowej analizy DLL podobieństwo między użytymi algorytmami zaciemniania było jedynym potwierdzeniem, że te dwa szkodliwe programy pochodzą z tego samego źródła.

Gdy wydobyliśmy ukryty DLL z pamięci komputera i zbadaliśmy, w jaki sposób działa, nie mieliśmy już wątpliwości: DLL jest identyczny z trojanem Trojan-Spy.Win32.Sinowal i wykonuje te same funkcje co trojan szpiegujący.

Po autoryzacji botnetu w sieci na maszynę ofiary pobierany jest moduł DLL, którego celem jest kradzież haseł i przechwytywanie ruchu sieciowego.

Sinowala można nazwać uniwersalnym złodziejem. Po tym, jak znajdzie się w systemie, natychmiast zaczyna skanować w celu znalezienia wszystkich dostępnych haseł do szeregu różnych aplikacji.

butkit_1108_pic15s.png  enlarge.gif
Zdezasemblowany kod modułu kradnącego hasła

Lista atakowanych aplikacji

Total Commander Thunderbird FlashFXP SecureFX
Windows The Bat Trellian FTP LeechFTP
Commander Internet Explorer Crystal FTP e-Safekey
AK-Mail Mozilla FireFox Folder Flash Player
Inetcomm LeechFTP FAR Manager PuTTY
Outlook FTPS FTP Voyager WinSCP
MSO FireFtp CuteFTP SecureCRT

Większość aplikacji atakowanych przez moduł do kradzieży poufnych danych tworzonych jest w celu administracji witryny internetowej. Jest to krytyczne dla szkodliwych użytkowników, ponieważ to właśnie na tych stronach może znajdować się centrum kontroli lub exploity.

Jednak dla cyberprzestępców największą wartość mają konta bankowe.

butkit_1108_pic16s.png  enlarge.gif
Częściowa lista stron bankowych, do których hasła kradnie moduł szpiegujący. Pełna lista zawiera około 300 stron

Przechwytując wszystkie połączenia sieciowe z maszyny ofiary, DLL skanuje ruch w celu znalezienia kontaktu ze stronami bankowymi. Wszystkie dane wprowadzone przez użytkownika na takich stronach zostaną wysłane do serwera szkodliwego użytkownika.

Moduł szpiegujący może uruchomić atak man-in-the-middle, wykorzystując bootkita jako platformę posiadającą pełny dostęp do zasobów systemu operacyjnego. Pozwala to modułowi szpiegującemu przechwycić informacje poufne wprowadzone za pośrednictwem przeglądarki.

Moduł ten posiada prawie wszystkie funkcje programu szpiegującego, od banalnego przechwytywania danych wprowadzanych za pośrednictwem klawiatury do subdomen chronionych połączeń SSL. Podczas łączenia się ze stroną https program szpiegujący może otworzyć dodatkowe okna w przeglądarce w celu autoryzacji. Do takiego okna użytkownik może przez pomyłkę wprowadzić dane dotyczące swojego konta, ponieważ okno to wydaje się być częścią strony banku.

Program szpiegujący może przekierować zapytania użytkownika na strony phishingowe.

Wszystkie przechwycone dane są szyfrowane i wysyłane do wyspecjalizowanego serwera.

butkit_1108_pic17s.png  enlarge.gif
Przykład lokalizacji serwerów, które obsługują połączenia SSL i są wykorzystywane do przekierowywania użytkowników na strony phishingowe (od lewej strony: nazwa domeny; adres IP serwera; podsieć, w której jest zlokalizowany serwer; autonomiczny system).

butkit_1108_pic18s.png  enlarge.gif
Przykład lokalizacji serwera, do którego są wysyłane skradzione hasła do aplikacji (od lewej: nazwa domeny; adres IP serwera; podsieć, w której jest zlokalizowany serwer; autonomiczny system)

Zainfekowana sieć

Rozpatrując ogólny schemat ataku, należy pamiętać, że wszystkie komponenty sieci bootkita są w nieustannym ruchu. Kontrolując serwery domen, szkodliwi użytkownicy mogą szybko i łatwo zmienić lokalizację exploitów, panel administracyjny centrum kontroli, miejsce, w którym ładowane są moduły, oraz przechwytywanie poufnych danych. To sprawia, że system jest bardzo stabilny, ponieważ rekonfiguracji komponentów sieci można dokonać bez wprowadzania żadnych modyfikacji do konfiguracji bootkita lub jego modułów.

butkit_1108_pic19_en.png 
Jak wygląda interakcja bootkita z serwerami

Skala infekcji

Zarówno pierwszy bootkit, który pojawił się pod koniec zeszłego roku, jak i Rustock rozprzestrzeniały się za pośrednictwem zasobów grupy IframeBiz. Jednak, bootkit pojawił się w zupełnie inny sposób: scenariusz był znacznie bardziej techniczny i wiele należało tu zawdzięczać epidemii spowodowanej przez Rustocka i Sinowala.

Zmierzenie skali epidemii poprzez zliczanie użytkowników, którzy skarżyli się, że ich komputery uruchamiają się powtórnie, nie byłoby najwłaściwsze. Kategoryczną odpowiedź mogłyby dostarczyć statystyki centrum kontroli botnetu; jednak nie mieliśmy pełnego dostępu do panelu administracyjnego. Mimo to, jesteśmy w stanie podać pewne dane liczbowe.

Badając incydent, wyróżniliśmy pięć głównych serwerów wykorzystywanych do pobierania exploitów. Aby przedstawić skalę zjawiska, dość powiedzieć, że w ciągu 24 godzin serwery te odwiedziło ponad 200 000 użytkowników ze Stanów Zjednoczonych.

butkit_1108_pic20.png

butkit_1108_pic21.png 
Liczba unikatowych użytkowników ze Stanów Zjednoczonych odwiedzających strony, na których umieszczone były exploity

Jak już wspominaliśmy, panel administracyjny wykorzystywany do kontrolowania botnetu nieustannie zmienia lokalizację według specjalnego algorytmu. Jednak nie wszystkie boty łączą się z nim, gdy jest "w ruchu".

Poniższe wykresy pokazują kilka centrów w trakcie przemieszczania się - "ogon" tworzą przyłączające się do nich boty - oraz dane dotyczące liczby zainfekowanych systemów. Wyraźnie widać, że rozmiar botnetu osiągnął prawie 100 000 botów, co stanowi dość dużą liczbę. Należy zauważyć, że dane te dotyczą tylko amerykańskich użytkowników.

butkit_1108_pic22.png 
Liczba unikatowych wizyt ze Stanów Zjednoczonych w panelu administracyjnym podczas przemieszczania się go do kolejnej domeny

butkit_1108_pic23.png 

butkit_1108_pic24.png 
Liczba unikatowych użytkowników ze Stanów Zjednoczonych odwiedzających panel administracyjny, który pozostał w starych domenach

Metody ochrony

Autorzy bootkita podjęli ogromny wysiłek, aby stworzyć dobrze zabezpieczony, wysoce mobilny pakiet i starannie zaplanowali każdy etap, od zainfekowania użytkownika po zarządzanie botnetem. Zależało im, aby nie popełnić błędów, nawet w takich drobnych kwestiach jak wstrzykiwanie ramki iframe do kodu strony.

Mimo wyrafinowanych technologii wykorzystanych przez autorów bootkita współczesne produkty antywirusowe powinny potrafić zapobiec przeniknięciu szkodliwego kodu do komputera.

Zastanówmy się, co mogło pomieszać szyki cyberprzestępcom na każdym etapie procesu infekcji.

Podejście zastosowane przez cyberprzestępców (tzn. nakłonienie użytkowników do odwiedzenia zainfekowanych stron i wygenerowanie unikatowych exploitów) miało na celu nie tylko zainfekowanie jak największej liczby użytkowników, ale również zwalczanie różnych technologii zastosowanych w obecnych produktach antywirusowych.

Tak więc podmienianie odsyłaczy zamiast dodawania ramki iframe ma na celu zwalczanie tradycyjnego skanowania ruchu sieciowego; takie skanowanie powoduje, że podejrzana ramka iframe jest sprawdzana bardziej rygorystycznie lub całkowicie blokowana.

Biorąc pod uwagę dziesiątki, a czasami nawet setki legalnych stron, na które włamują się szkodliwi użytkownicy, aby dodać do nich szkodliwy kod, najlepszym sposobem ochrony przed takimi zagrożeniami jest zaimplementowanie technologii, która blokuje nieznane szkodliwe strony.

butkit_1108_pic25s.png  enlarge.gif
Odmowa dostępu: użytkownik z zainstalowanym programem KIS 2009 próbuje przeglądać zainfekowaną stronę

Exploity generowane są automatycznie dla każdego nowego użytkownika, jednak w przeciwieństwie do kodu exploita, który zmienia się za każdym razem, mechanizm zaciemniania pozostaje taki sam. To oznacza, że oprogramowanie antywirusowe jest w stanie wykryć zaciemniony skrypt przy pomocy wykrywania sygnaturowego lub heurystycznego.

butkit_1108_pic26.png 
Wykrywanie zaciemnionego exploita

Jeżeli mimo wszystko exploit zostanie pobrany na maszynę ofiary, nie będzie w stanie uruchomić się, jeśli użytkownik regularnie łata swój system operacyjny i aplikacje. Skaner luk w zabezpieczeniach potrafi wykryć "dziurawe" aplikacje.

butkit_1108_pic27_en_s.png  enlarge.gif
Wykrywanie komponentu Flash Playera z niezałataną luką

butkit_1108_pic28_en_s.png  enlarge.gif
Opis luki na stronie viruslist.com

Wyobraźmy sobie, że użytkownik ma zainstalowaną "dziurawą" aplikację, dzięki czemu exploit mógł się uruchomić. Na maszynę ofiary zostanie pobrany dropper bootkita: ten plik wykonywalny jest tworzony na serwerze dla każdego użytkownika, dlatego wykrywanie na podstawie sygnatur jest utrudnione.

Na tym etapie najskuteczniejszą metodą stosowaną przez produkt antywirusowy będzie ochrona proaktywna, która umożliwia analizowanie nieznanych plików, określenie ich funkcji i przeprowadzenie analizy heurystycznej kodu i zachowania szkodliwego programu.

butkit_1108_pic29_en_s.png  enlarge.gif
Gdy plik wykonywalny zostaje uruchomiony, KIS 2009 analizuje go...

butkit_1108_pic30_en_s.png  enlarge.gif
...i jeśli analiza wykaże potencjalne zagrożenie, uruchomienie pliku zostanie zablokowane

butkit_1108_pic31_en.png 
Plik posiada wysoki współczynnik zagrożenia i został wykryty heurystycznie jako Heur.Backdoor.Generic

Jeżeli w momencie infekcji użytkownik nie ma zainstalowanego wystarczająco skutecznego rozwiązania antywirusowego, bootkit, który przeniknął do systemu, uruchomi się przed systemem operacyjnym i rozwiązaniem antywirusowym. Pozwala to bootkitowi kontrolować istotne funkcje systemowe i ukryć swoją obecność na zainfekowanej maszynie.

Szkodliwy kod można wykryć i zneutralizować przy pomocy programu antywirusowego wyposażonego w skuteczny moduł ochrony przed rootkitami, rozpoczynając od skanowania pamięci systemu...

butkit_1108_pic32_en_s.png  enlarge.gif
Wykrywanie rootkita w pamięci

a następnie sektora startowego...

butkit_1108_pic33_en_s.png  enlarge.gif
Leczenie MBR-a

Rezultat - system został wyleczony.

butkit_1108_pic34_en_s.png  enlarge.gif
Raport z całkowitego leczenia programu KIS 2009

Wnioski

W swoim czasie bootkit stanowił dla twórców wirusów przełom technologiczny. Obecnie bootkit jest wyposażony w potężną procedurę i funkcje rozprzestrzeniania w ramach botnetu.

Dzięki technologiom zaimplementowanym w rootkicie Rustock ten szkodliwy program mógł wyślizgnąć się firmom antywirusowym oraz utrudnić swoją analizę. Bootkit wykorzystuje również szereg różnych metod w celu uniemożliwienia wykrycia tego programu na wczesnych etapach infekcji, próbuje zainfekować jak najwięcej użytkowników i uniemożliwić zdjęcie botnetu.

Przykładem tych metod jest wykorzystanie wysoce zorganizowanego podejścia i technologii; wykorzystanie różnych luk w zabezpieczeniach innych aplikacji; przesunięcie z trybu rozruchowego systemu operacyjnego do zera, trzeciego pierścienia i od nowa; stworzenie aplikacji w języku programowania C++ dla systemów operacyjnych *nix; protokoły kryptograficzne; metody wykorzystywane do autoryzacji botów w systemie itd.

Nie ma wątpliwości, że rozwinięcie takiego systemu zajęło kilka miesięcy, wymagało zapewnienia jego płynnego działania oraz nakładów na nabycie lub stworzenie nowych exploitów, domen, hostingu itd.

Stworzenie, zaplanowanie, zaimplementowanie i obsługa takiego systemu nie byłoby możliwe dla jednej czy dwóch osób. Jest on wynikiem pracy nie jednej, ale kilku grup cyberprzestępców, którzy ściśle ze sobą współpracują, odpowiadając za oddzielne obszary projektu.

Historia bootkita pokazuje, jak dalece problemy bezpieczeństwa informacji dotykają zwykłych użytkowników. Wszystkie przeanalizowane wyżej technologie są obecnie aktywnie wykorzystywane w przeważającej większości szkodliwych programów.

Przeglądarka jako wektor infekcji, technologie rootkit, botnety, kradzież danych użytkownika, kryptografia, zaciemnianie, technologie rozwiązań antywirusowych - z tym wszystkim spotkaliśmy się już w trzecim kwartale 2008 roku. Jednak w bootkicie mieliśmy szansę zobaczyć to wszystko razem.

Jedynym sposobem skutecznego zwalczania takich złożonych zagrożeń jest wykorzystywanie wielu różnych technologii ochrony, takich jak: ochrona online, filtrowania ruchu, analiza zachowań, piaskownica, analiza ruchu sieciowego i zapora sieciowa. Współczesne rozwiązanie antywirusowe powinno potrafić nie tylko zwalczać rootkity, ale również neutralizować bootkity.