Od prawie roku jeden z serwerów, którymi się opiekuję jest pod ciągłym atakiem wirusów. A konkretnie całej serii mutacji wirusa Bagle. Kiedyś wydawało mi się, że mechanizm wygląda tak: wirusy pojawia się, szybko rozprzestrzenia, ludzie instalują poprawki i po paru tygodniach wirus już nie istnieje. Okazuje się jednak, że w rzeczywistości epidemia nie wygasa tak szybko, a wielu użytkowników nie ma świadomości, że ich komputery są od roku zawirusowane.
Wszystko zaczęło się na początku czerwca 2006, kiedy to zajrzałem w statystyki
serwera WWW i w pierwszej chwili pomyślałem, że stał się on celem ataku
DDoS. Po zajrzeniu
w logi zobaczyłem tysiące odwołań do nieistniejącego pliku
/nul.php przychodzące z najróżniejszych komputerów.
pool-70-19-217-150.bos.east.verizon.net - - [04/Jun/2006:08:18:24 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2)" lns-bzn-20-82-250-5-184.adsl.proxad.net - - [04/Jun/2006:08:18:46 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" host140-90.pool8255.interbusiness.it - - [04/Jun/2006:08:19:04 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" host71-78.pool8255.interbusiness.it - - [04/Jun/2006:08:19:06 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" host71-78.pool8255.interbusiness.it - - [04/Jun/2006:08:19:06 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" host140-90.pool8255.interbusiness.it - - [04/Jun/2006:08:19:07 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" 85-53-79-85.mad1.adsl.uni2.es - - [04/Jun/2006:08:19:55 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" 85-53-79-85.mad1.adsl.uni2.es - - [04/Jun/2006:08:19:55 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" anancy-152-1-97-93.w86-213.abo.wanadoo.fr - - [04/Jun/2006:08:20:03 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" anancy-152-1-97-93.w86-213.abo.wanadoo.fr - - [04/Jun/2006:08:20:03 +0200] "GET /nul.php HTTP/1.1" 404 213 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
Szybkie wygooglanie pomogło zlokalizować przyczynę – wirusy. Okazało się, że autorzy pewnych wariantów wirusa Bagle z nieznanych mi przyczyn upatrzyli m.in. mój serwer jako miejsce do pobierania aktualizacji. Na liście sprawdzanych URL-i widnieje kilkadziesiąt hostów, co można sprawdzić w bazach antywirusowych: Bagle.FY, Bagle.GS itp.
Celem wirusa jest oczywiście najbardziej popularna platforma systemowa – Microsoft Windows. Mechanizm ataku jest typowy: użytkownicy dostają spam zawierający skompresowanego i zaszyfrowanego ZIP-em wirusa oraz obrazek z hasłem do tegoż archiwum. Dzięki szyfrowaniu znacznie trudniej jest opracować sygnaturę wirusa do ewentualnego zastosowania na bramce e-mail, ponieważ zawartość archiwum zmienia się wraz z losowo wygenerowanym kluczem szyfrującym. Choć wydawało się to kiedyś niemożliwe, wirus który wymaga sporo ręcznej ingerencji użytkownika, może rozprzestrzeniać się bardzo efektywnie. Jak można otworzyć ZIP-a przysłanego bez zapowiedzi, z jakimś losowym hasłem, a potem jeszcze uruchomić plik .exe znajdujący się w tym archiwum? Czy naprawdę nie wzbudza to żadnych podejrzeń? Niestety są to pytania retoryczne – świadomość ludzi jest tak niska, że na własne życzenie chętnie zawirusują sobie system. Po uruchomieniu pliku .exe wirusik dodaje się do wszelkich miejsc startowych w Rejestrze i przystępuje do rozsyłania swoich kopii, naturalnie przy wykorzystaniu książki adresowej wiodącego programu pocztowego – Outlooka. Kółko się zamyka.
Pewne warianty Bagle, w tym właśnie te omawiane tutaj, posiadają opcję automatycznego pobierania aktualizacji przez WWW. Odpytują hosty z wbudowanej listy i jeśli coś tam znajdą, prawdodobnie uruchamiają pobrany kod. Zakładając, że atakujący ma dostęp do choć jednego z serwerów wymienionych na liście, może zbudować całkiem odporną i wydajną sieć maszyn zombie, które np. mogą potem służyć do ataków DDoS czy rozsyłania spamu.
Po pewnym czasie zaczęły się też pojawiać inne URL-e, np.
/777.gif, /999.gif, /mul2.php itd.
Aby dziadostwo nie zaśmiecało mi logów i nie obciążało serwera, napisałem
szybko zestaw regułek do Apache:
# poniższe regułki blokują niepożądane wywołania na samym starcie # i zwracają kod 403 Forbidden, zamiast 404 Not Found <LocationMatch "/([mn]ul2?\.php|mu2l\.php|(777|999)\.gif)"> Order Deny,Allow Deny from All </LocationMatch> # w ten sposób wyłączamy logowanie wywołań w access.log SetEnvIf Request_URI "/([mn]ul2?\.php|mu2l\.php|(777|999)\.gif)" nolog CustomLog /var/log/apache/access.log combined env=!nolog
To w zasadzie załatwiło sprawę wirusa. Dzisiaj, kiedy mija prawie rok od początku jego aktywności postanowiłem sprawdzić ilu użytkowników nadal jest zawirusowanych. Poniżej prezentuję wykres liczby odwołań do plików Bagle, każdy słupek odpowiada okresowi jednego tygodnia.
Aktywność wirusa Bagle w okresie czerwiec 2006 – maj 2007
Widać wyraźnie gwałtowny wzrost popularności na początku epidemii. W czasie najbardziej aktywnego tygodnia serwer dostał prawie 3,4 mln wywołań, co przekłada się na przeciętnie 5,5 wywołania na sekundę. Całkiem sporo, prawda? Dalej już można obserwować trend spadkowy. Widoczny jest też duży spadek aktywności w okresie świąt Bożego Narodzenia, kiedy wiele komputerów nie jest w ogóle włączanych. Z drugiej strony ludzie może mają więcej czasu i zajmują się chętniej naprawianiem komputerów, w tym też usuwaniem wirusów.
Obecnie serwer dostaje ponad 400000 bezsensownych prób pobrania plików tygodniowo. Biorąc pod uwagę spowalniający trend spadkowy można się spodziewać, że potrwa to pewnie jeszcze ze dwa lata. Gdyby np. właścicielowi serwera przyszło płacić za ruch sieciowy, to umieszczenie jego URL w kodzie wirusa mogłoby wygenerować istotne koszty. Co gorsza administrator nie ma żadnej kontroli nad ruchem przychodzącym, ani też możliwości zablokowania go na poziomie stosu TCP/IP, ze względu na dynamiczne adresy użytkowników. No chyba że… chciałby zwalczyć wirusa jego własną bronią :-)
Można by wystawić jakiś plik wykonywalny pod jedną z wymienionych wyżej nazw i sprawdzić jak wirus zachowuje się w tej sytuacji. Być może umożliwiłoby to zdalne odinstalowanie wirusów. W czerwcu zeszłego roku przetestowałem wszystkie wbudowane w wirusie URL-e. Żaden z nich nie serwował nic ciekawego. Jeśli kiedyś znajdę na to czas, może przetestuję ten wariant.
