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"><B>atm.n****.com</B></a>

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

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:

 

 
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.

 
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.

 
Okno g艂贸wne panelu administracyjnego

Mimo pozornego ograniczenia interfejs administracyjny Neosploita posiada szeroki zestaw funkcji.

 
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.

 
Panel administracyjny Neosploita od wewn膮trz

 
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)

 
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.

 
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.

 
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艣膰.

 
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.

 
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.

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

 
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.

 
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.

 
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.

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

 
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.

 
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.

 
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.

 
Liczba unikatowych wizyt ze Stan贸w Zjednoczonych w panelu administracyjnym podczas przemieszczania si臋 go do kolejnej domeny

 

 
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.

 
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.

 
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.

 
Wykrywanie komponentu Flash Playera z nieza艂atan膮 luk膮

 
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.

 
Gdy plik wykonywalny zostaje uruchomiony, KIS 2009 analizuje go...

 
...i je艣li analiza wyka偶e potencjalne zagro偶enie, uruchomienie pliku zostanie zablokowane

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

 
Wykrywanie rootkita w pami臋ci

a nast臋pnie sektora startowego...

 
Leczenie MBR-a

Rezultat - system zosta艂 wyleczony.

 
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.