P

ewnego, dawnego razu – pewna firma – nazwijmy ją X – zauważyła, że jej firmowy serwer z aplikacją Y zaczyna coraz bardziej wolniej przetwarzać dane. Ówczesny administrator (specjalizujący się głównie w systemach .exe) zwrócił się do mnie z prośbą o “rzucenie okiem”, czy czasami serwer lub aplikacja nie wymaga zmian w konfiguracji, w celu przywrócenia pierwotnej wydajności i czy nie wynika to z ilości danych jakie zostały już przetworzone. Po uzyskaniu klucza SSH na konto uprawnione do polecenia sudo – 18.02.2011 roku zalogowałem się na serwer Z firmy X w celu sprawdzenia ogólnego stanu serwera. Po uzyskaniu informacji o stanie wolnego miejsca na partycji dla danych z aplikacji za pomocą polecenia df -h przyszedł czas na sprawdzenie aktualnych procesów za pomocą ulubionego narzędzia htop.

Już po paru sekundach monitoringu podejrzenie wzbudził proces ttymon tymon, którzy wykorzystywał 95% czasu jednego z dwóch rdzeni procesora. Przy próbie zakończenia procesu system nie wykazywał żadnej reakcji. Dodatkowym czynnikiem przekonującym, że system wymaga bardziej gruntownego sprawdzenia był zrzucany błąd ładowania biblioteki, która została błędnie dodana do preloadera /etc/ld.so.preload.

serv-z:~# ls
ERROR: ld.so: object '/lib/libaux.so.2' from
/etc/ld.so.preload cannot be preloaded: ignored.

Za pomocą polecenia: lsof | grep ttymon udało mi się sprawdzić wszystkie używane pliki przez ten proces. Najbardziej podejrzany wydawał się:

[...]
ttymon    26133     root  cwd       DIR                8,2          0     219082 
/tmp/.ICE-unix/shv5/bin (deleted)
[...]

Po przejściu do katalogu /tmp/.ICE-unix/ i listingu zawartości zostało znalezione archiwum o nazwie httt.tar.gz, które jak się później okazało w rzeczywistości był źródłowym pakietem instalacyjnym oprogramowania typu rootkit o nazwie SHV5.

serv-z:~# cd /tmp/.ICE-unix/ 
serv-z:/tmp/.ICE-unix# ls -al 
total 660 
drwxrwxrwt   2 root     root         4096 Feb 18 10:34 . 
drwxrwxrwt   8 root     root         4096 Feb 18 10:34 .. 
-rw-------   1 root     root       662268 Nov 12 09:13 httt.tar.gz

Między innymi potwierdzeniem tego, że było to oprogramowanie typu rootkit była próba ukrycia macierzystego procesu w poleceniu ps, która kończyła się komunikatem:

serv-z:~# ps auxw | grep ttymon 
Unknown HZ value! (15) Assume 100. 
root      6470  0.0  0.0  3852  768 pts/1    S     2010   0:00 grep ttymon

Kolejnym krokiem podjętym w celu ustalenia źródła kompromitacji systemu było prześledzenie logów systemowych. Aktualny czas działania procesu ttymon wynosił 424 godzin, 46 minut i 41 sekund. W tym przypadku jakiekolwiek ślady po włamaniu, jeśli nie zostały jeszcze usunięte – powinny znajdować się w logach zapisanych w systemie z przed około tygodnia. Pierwszymi w kolejności (ze względu na układ alfabetyczny katalogów i plików) były logi serwera WWW Apache, które oprócz cyklicznego skanowania skanerem w00tw00t, nie wykazywały żadnych anomalii. Następnymi w kolejności były logi serwera pocztowego Exim. Po sprawdzeniu pierwszego pliku odpowiedzialnego za zgłaszanie błędów – okazało się, że cały proces włamania został zapisany w już zrotowanym po tygodniu pliku /var/log/exim4/rejectlog.1.

Włamanie nastąpiło 19.12.2010 r. (czyli proceder trwał około 3 miesięcy) z adresu IP: 88.84.139.31 (v27031.1blu.de) – serwera, jak się później okazało “wykupionego” na okres testowy u niemieckiego dostawcy usług hostingowych 1blu. Skrypty napisane w języku Perl, służące do zaatakowania serwera exim.pl i połączenia się z tzw. back shellem (port 4445), służącego do zdalnej konsoli i wydawania poleceń (c.pl) zostały pobrane na serwer za pomocą polecenia wget z darmowej usługi Dropbox (ID użytkownika: 16937203). Serwerem wykorzystanym do roli back shella został – jak wynikało z kopii strony WWW Google – prywatny serwer refic.org – 84.34.147.92. Po uzyskaniu dostępu do powłoki systemowej na serwer serv-z do katalogu /var/spool/exim4/ zostały wgrane programy służące do rozszerzenia uprawnień administracyjnych, zacierania śladów i zdalnego dostępu do powłoki serwera. Dalsze przeszukiwanie logów zaowocowało znalezieniem w pliku /var/log/auth.log powtarzających się wpisów dotyczących logowania się z konta administratora root na konto nobody:

Feb 14 06:25:01 serv-z su[13871]: Successful su for nobody by root 
Feb 14 06:25:01 serv-z su[13871]: + ??? root:nobody 
Feb 14 06:25:01 serv-z su[13871]: (pam_unix) session opened for user nobody by (uid=0) 
Feb 14 06:25:01 serv-z su[13871]: (pam_unix) session closed for user nobody

które zostało aktywowane jako konto z powłoką:

serv-z:~# cat /etc/passwd | grep nobody 
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh

Kolejnym krokiem prawdopodobnie było już wgranie w/w rootkita. Przeskanowanie systemu aplikacjami typu chkrootkit oraz rkhunter wyraźnie wskazywało na obecność szkodliwego oprogramowania, a tym samym kompromitacji całego systemu z możliwością jego kontroli na poziomie administracyjnym.

Jak doszło do włamania?

Typowy przypadek porzuconego na własny los serwera – ze względu na brak cyklicznych aktualizacji bezpieczeństwa systemu sprawdziłem wersje posiadanego oprogramowania serwera pocztowego, na którym wykonano zdalny exploit:

serv-z:~# dpkg -l | grep exim4
ii  exim4               4.63-17       metapackage to ease exim MTA (v4) installation 
ii  exim4-base          4.63-17       support files for all exim MTA (v4) packages 
ii  exim4-config        4.63-17       configuration for the exim MTA (v4) 
ii  exim4-daemon-light  4.63-17       lightweight exim MTA (v4) daemon

Po sprawdzeniu informacji o dostępnych lukach okazało się, że ta wersja serwera exim w systemie Debian Lenny 5.0 zawierała krytyczny błąd, który pozwalał na uruchomienie dowolnego kodu w kontekście użytkownika exim.

Niestety nie doszło do ustalenia tożsamości sprawcy włamania lub dotarcia do kolejnych jego śladów – po krótkiej wymianie korespondencji okazało się, że firma 1blu.de po zakończeniu okresu testowego po prostu odcinała sieciowy dostęp do serwera i zwracała go do puli dostępnych serwerów na testy – gdzie został nadpisany innym systemem operacyjnym niszcząc wszelkie pozostawione dowody (atakujący był na tyle sprytny i znał mechanizmy firmy hostingowej, że włamania dokonał kilka godzin przed wygaśnięciem wynajmowanego serwera). Również serwer refic.org prawdopodobnie został porzucony i skompromitowany – ze względu na brak jakiejkolwiek odpowiedzi na komunikację e-mail.

Po krótkich konsultacjach i sporządzeniu raportu na temat stanu serwera i aplikacji – firma X uznała, że najwyższym priorytetem jest przywrócenie normalnego działania programu – tym bardziej, że nie doszło do usunięcia żadnych danych. Jedyną niewiadomą była odpowiedź na pytanie, czy skompromitowany serwer nie posłużył dalej jako jump station do kolejnych włamań – dlatego przed jego reinstalacją – został stworzony i zabezpieczony obraz całego serwera (po upływie roku do firmy X nie dotarł żaden komunikat wskazujący na ten fakt).

Sam serwer został przywrócony do pierwotnego stanu i zaktualizowany do najnowszej, dostępnej wersji, a wszystkie hasła – mimo ich zaszyfrowania w bazie danych – zmienione (aplikacja webowa łączyła się na dedykowanych użytkowników). Dodatkowo oprócz wprowadzenia innych mechanizmów bezpieczeństwa (w tym pouczenia administratora firmy X o ważności aktualizacji bezpieczeństwa – nawet, jeśli zajmuje się hobbistycznie innymi systemami) została zablokowana możliwość łączenia się z serwerem pocztowym ze świata (ponieważ tylko do wysyłania i otrzymywania stanu wysłanej wiadomości serwer pocztowy nie musi posiadać możliwości otrzymywania połączeń z innych, zewnętrznych serwerów – wszystko z jego strony wykonywane jest w pojedynczej sesji, do której poprawnego działania wystarczy stanowe śledzenie na zaporze ogniowej ruchu wychodzącego).

Więcej informacji: Niektóre fanty z włamania.