C

raig H. Rowland na konferencji Purplecon 2018 opowiedział o szybkiej ocenie kompromitacji systemu Linux. Jak zauważył, 90% wdrożeń opartych na publicznych chmurach obliczeniowych odbywa się na systemie operacyjnym Linux. Nawet jeśli nie mamy z nim bezpośrednio do czynienia z powodu wysokich poziomowo abstrakcji i wywołań (np. API) – prędzej czy później natchniemy się na niego, a jako przyszły administrator dobrze posiadać wiedzę o jego działaniu oraz czy jego zachowanie nie budzi jakiś zastrzeżeń. Jeśli posiadamy podejrzenie, że doszło do naruszenia jego bezpieczeństwa – nie panikujmy. Podstępując pochopnie możemy tylko pogorszyć sytuację poprzez zniszczenie krytycznej informacji z punktu widzenia analizy pozwalającej ustalić główną przyczynę włamania.

Powszechne problemy są zaskakująco powszechne.

Bardzo ciekawym porównaniem przy wykryciu włamania jest przypadek znany z medycyny. Kiedy podejrzewamy u siebie jakąś chorobę zazwyczaj od razu celujemy w bardzo ciężkie odmiany, aby później mogło się okazać, że rzeczywistość jest zupełnie inna. Analogicznie jest w tego rodzaju przypadkach. Nie musimy od razu bać się, że nasz system padł ofiarą APT (ang. Advanced Persistent Threats) – zaawansowanego, trwałego zagrożenia, które wykorzystuje ciągłe, jeszcze nieznane i wyrafinowane techniki ataków, aby uzyskać dostęp do systemu i pozostać w nim przez dłuższy okres czasu (z potencjalnie destrukcyjnymi skutkami). Bardziej musimy się martwić CRAP [szajsem krążącym po internecie] (ang. Commonly Run Attacks Preferred), czyli najczęściej uruchamianymi atakami, gdy tylko pojawi się nowy eksploit wykorzystujący niedawno wykrytą podatność. Za ich popularnością stoją skryptowe dzieciaki, których celem są mało ambitne cele. Skoro bardzo wiele usług jest podatna na tego rodzaju scenariusze nie ma potrzebny stosowania elitarnych 0-dzionków, aby stworzyć botnet lub sieć koparek kryptowalut. Dlatego posiadanie wiedzy o popularnych lukach w zabezpieczeniach pozwala z czasem na wykrywanie bardziej zaawansowanych atakujących (nawet rozbudowane ataki bazują na powszechnie dostępnych błędach).

Obrońcy muszą znać tysiące sposobów, na które system może zostać skompromitowany.
Atakujący muszą znać tylko ten jeden właściwy.

Atakujący muszą znać tysiące sposobów, aby zatrzeć po sobie ślady.
Obrońcy muszą zauważyć tylko jedną nieprawidłowość.

Do wielkiej piątki podczas wykrywania włamań w systemie Linux można zaliczyć:

• Procesy,
• Katalogi,
• Pliki,
• Użytkowników,
• Logi

Są to najczęstsze obszary dotykane podczas udanego ataku. Jeśli chodzi o podejrzane procesy Craig wspomina kilka najczęściej występujących cech: albo próbują udawać te “poprawne” albo wyglądają bardzo dziwnie; generują ruch sieciowy na dziwnych portach, nierozpoznawalnymi protokołami dla tych portów; mogą powodować wysoką utylizację CPU lub pamięci RAM; uruchomione są procesy, których pliki binarne zostały usunięte. Przykładem może być proces cron nasłuchujący na surowych gniazdach sieciowych oraz TCP:

netstat -naplet

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address   State       PID
tcp   0      0      0.0.0.0:22222 0.0.0.0:*         LISTEN      10580/cron
tcp   0      0      0.0.0.0:22    0.0.0.0:*         LISTEN      1293/sshd
tcp   0      332    192.168.1.122 120.136.1.1:56639 ESTABLISHED 11022/2
tcp6  0      0      :::22         :::*              LISTEN      1293/sshd
udp   0      0      0.0.0.0:555   0.0.0.0:*                     32481/t
raw   0      0      0.0.0.0:1     0.0.0.0:* 7                   10580/cron

Inne podejrzane czynności skupiają się często na zapisach do katalogów, które posiadają prawa zapisu dla wszystkich /tmp, czy /dev/shm. Tutaj nieocenionym źródłem może być system plików procfs. Skierowanie odpowiednich poleceń w jego stronę może dać nam bardzo dużo informacji o tym, co aktualnie dzieje się w systemie. Na przykład polecenie:

ls -alR /proc/*/cwd 2> /dev/null | grep tmp

lrwxrwxrwx 1 root root 0 Nov 14 02:07 /proc/10580/cwd -> /tmp

Ukazuje nam proces ID 10580, który został uruchomiony z katalogu /tmp. Inna komenda:

ls -alR /proc/*/exe 2> /dev/null | grep deleted

lrwxrwxrwx 1 root root 0 Nov 13 07:39 /proc/10580/exe -> /usr/bin/perl (deleted)

Ukazuje nam proces ID 10580, który jest uruchomiony w systemie, ale jego plik binarny został usunięty (popularna technika używana przez szkodliwe oprogramowanie, aby różne systemy wykrywania bazujące na źródle z danych dyskowych ich nie mogły wykryć). Skoro nie jest to typowy proces w systemie Linux, można pokopać trochę głębiej:

cat /proc/10580/comm

/usr/sbin/cron

cat /proc/10580/cmdline

/usr/sbin/cron

ls -al /proc/10580/exe

lrwxrwxrwx 1 root root 0 Nov 13 07:39 /proc/10580/exe -> '/usr/bin/perl (deleted)'

Jak możemy zobaczyć przez pierwsze dwa polecenia – proces bardzo chce nas przekonać, że jest daemonem cron. Ale wedle zasady, że obrońcy muszą zauważyć tylko jedną nieprawidłowość – ostatnie polecenie ukazujące łącze symboliczne zawierające aktualną ścieżkę dostępu do wykonywanego polecenia demaskuje cały podstęp.

Przejdźmy teraz do katalogów. Autor wystąpienia wylicza, że ich istnienie związane jest z następującymi powodami: chowane jest w nich szkodliwe oprogramowanie; chowane są w nich skradzione dane; chowane są w nich dane umożliwiające dalsze rozprzestrzenianie się po skompromitowanej sieci; chowane są w nich mechanizmy pozwalające na ponowną infekcję np. w razie restartu maszyny. Najczęściej wybierane są katalogi w ścieżkach:

/tmp, /var/tmp        /lib*, /usr/lib*
/dev                  /etc
/dev/shm              /var/log
/bin                  /var/spool
/sbin                 public_html
/usr/bin              uprzywilejowane katalogi domowe
/usr/sbin             standardowe katalogi domowe

Jeśli chodzi o dziwne nazwy, które próbują udawać inne ścieżki i maskować się przy listowaniu zawartości to możemy spotkać:

ls -al /bin

total 17120
drwxr-xr-x 2  root root 4096    Jul 25 21:45
drwxr-xr-x 2  root root 4096    Sep 7  09:52 .
drwxr-xr-x 10 root root 12288   Sep 7  09:52 .
drwxr-xr-x 2  root root 4096    Mar 25 2017  .
drwxr-xr-x 2  root root 4096    Mar 25 2017  . .
drwxr-xr-x 24 root root 4096    Oct 11 04:01 ..
drwxr-xr-x 2  root root 4096    Jun 4  01:56 ..
drwxr-xr-x 2  root root 4096    Jun 4  02:25 ...
drwxr-xr-x 2  root root 4096    Jun 7  00:46 ..%
-rwxr-xr-x 1  root root 1037528 May 16 12:49 bash
-rwxr-xr-x 1  root root 520992  Jun 15 23:46 btrfs
-rwxr-xr-x 1  root root 249464  Jun 15 23:46 btrfs-calc-size

Jeśli dodamy teraz parametr -p dodający slash “/” do każdego katalogu zobaczymy prawdziwe nazwy tych mimików:

ls -lap /bin

total 17120
drwxr-xr-x 2  root root 4096    Jul 25 21:45  /    # spacja
drwxr-xr-x 2  root root 4096    Sep 7 09:52   ./   # spacja kropka
drwxr-xr-x 10 root root 12288   Sep 7 09:52  ./
drwxr-xr-x 2  root root 4096    Mar 25 2017  . /   # kropka spacja
drwxr-xr-x 24 root root 4096    Oct 11 04:01 ../   
drwxr-xr-x 2  root root 4096    Jun 4 01:56  .. /  # kropka kropka spacja
drwxr-xr-x 2  root root 4096    Jun 4 02:25  .../  # kropka kropka kropka
drwxr-xr-x 2  root root 4096    Jun 7 00:46  ..%/  # kropka kropka znak specjalny
-rwxr-xr-x 1  root root 1037528 May 16 12:49 bash
-rwxr-xr-x 1  root root 520992  Jun 15 23:46 btrfs
-rwxr-xr-x 1  root root 249464  Jun 15 23:46 btrfs-calc-size

Możemy też wykorzystać polecenie find:

find / -type d -name ".*"

/root/.local
/root/.ssh
/lib/modules/4.15.0-34-generic/vdso/.build-id
/bin/. .
/dev/.blKb
/dev/shm/. .

Oprócz katalogów w systemie mogą zostać pozostawione pliki, a wraz z nimi ślady po ataku. One również nie muszą być tymi plikami, za które się podają lub znajdują się w miejscu, w którym ich nie powinno być. Szczególnie zmodyfikowane pliki binarne. Poniżej przykład pliku pozostawionego przez niestarannie napisanego lub zaciętego podczas działania czyściciela logów:

ls -al /tmp

total 44
rwxrwxrwt 8   root root 12288 Sep 5 00:12 .
drwxr-xr-x 23 root root 4096  Sep 5 00:03 ..
drwxrwxrwt 2  root root 4096  Sep 5 00:03 .font-unix
drwxrwxrwt 2  root root 4096  Sep 5 00:03 .ICE-unix
drwxrwxrwt 2  root root 4096  Sep 5 00:03 .Test-unix
-rw-r--r-- 1  root root 2304  Sep 5 00:12 utmp.bak
drwxrwxrwt 2  root root 4096  Sep 5 00:03 .X11-unix
drwxrwxrwt 2  root root 4096  Sep 5 00:03 .XIM-unix

Innymi dziwnymi plikami są te, które posiadają ustawiony bit niezmienności, aby nie można ich było w prosty sposób usunąć z systemu:

lsattr / -R 2> /dev/null | grep "\----i"

----i---------e--- /tmp/.t
----i---------e--- /bin/pss

Maskarada plików to najczęściej przyznawanie fałszywych rozszerzeń różnym plikom (na uwagę polecenia file zasługuje parametr --preserve-date):

file * -p

1.jpg: ELF 32-bit LSB executable, ARM,  ...statically linked, stripped
2.jpg: ELF 32-bit LSB executable, ARM,  ...statically linked, stripped
3.jpg: ELF 32-bit MSB executable, MIPS, ...statically linked, stripped
4.jpg: ELF 32-bit LSB executable, MIPS, ...statically linked, stripped
index.html: data
logo.jpg: PHP script, ASCII text
logo.png: PNG image data, 32 x 32, 8-bit/color RGBA, non-interlaced

czyli JPGi okazują się wykonywalnymi ELFami, HTML jest nieznanymi danymi, a kolejny plik graficzny jest w rzeczywistości plikiem PHP. Idąc tym tropem rozumowania możemy przeszukać cały system w poszukiwaniu dziwnych ELFów:

find / -name ".*" -exec file -p '{}' \; | grep ELF

/var/tmp/.ICE-unix/.db: ELF 64-bit ... stripped

Ukryty plik binarny w katalogu /tmp. Dlaczego akurat tutaj? Przecież każdy normalny system operacyjny *nix ma w większości poprawne nazwy plików i nic nie próbuje ukryć przed swoim użytkownikiem. Podobnie jest w przypadku potoków nazwanych (ang. named pipes), które bardzo często są wykorzystywane przez narzędzia typu backdoor, powłoki bindujące (ang. bind shell) lub powłoki zwrotne (ang. reverse shell). Bardzo często nie są sprzątane nawet po tym jak powłoka już się zamknęła:

find / -type p

/run/dmeventd-client
/run/dmeventd-server
...
/tmp/f

Dziwna nazwa oraz katalog /tmp – podręcznikowy przykład. Innym sposobem jest możliwość wykorzystania menadżerów pakietów, które wskażą nam jakie pliki zostały zmodyfikowane w systemie:

[root@centos ~]# rpm -Va | grep ^..5.

SM5....T. c /etc/ssh/sshd_config
S.5....T. c /etc/ssh/ssh_config
S.5....T. c /root/.bashrc

[root@ubuntu ~]# debsums -ca

/etc/sudoers
/usr/sbin/nologin

Dlaczego plik binarny nologin został podmieniony? Przecież jest on używany do blokady logowania. Przejdźmy teraz do podejrzanych użytkowników. Według twórcy prezentacji pierwszą oznaką dziwnej aktywności są pliki historii umieszczone w katalogach użytkowników. Jeśli są one obecne, a nie powinny być – nie ma ich, a powinny lub są łączem symbolicznym do innych plików:

ls -alR | grep .*history

lrwxrwxrwx 1 www www 9 Nov 13 00:23 .bash_history -> /dev/null
-rw------- 1 root root 53083 Nov 12 23:49 .bash_history

Analogicznie jeśli chodzi o klucze SSH, które stosowane są jako jeden z mechanizmów persystencji:

find / -name authorized_keys

/root/.ssh/authorized_keys # Oj, oj SSH bezpośrednio na konto root!
/bin/.ssh/authorized_keys
/home/jscott/.ssh/authorized_keys
/home/www/.ssh/authorized_keys

Mogą one znajdować się w dziwnych ścieżkach dostępu lub są dodane do użytkowników, którzy nie powinni mieć tego rodzaju dostępu do systemu. Warto wtedy sprawdzić, jacy użytkownicy logowali się ostatnio do systemu (o ile logi nie zostały wyzerowane – o czym w dalszej części):

lastlog

Username         Port     From             Latest

root                                       **Never logged in**
daemon                                     **Never logged in**
bin                                        **Never logged in**
sys                                        **Never logged in**
sync                                       **Never logged in**
games                                      **Never logged in**
man                                        **Never logged in**
lp                                         **Never logged in**
mail                                       **Never logged in**
news                                       **Never logged in**
uucp                                       **Never logged in**
proxy                                      **Never logged in**
nobody           pts/0    105.21.21.71    Mon Apr 15 18:45:49 +0200 2020
backup                                     **Never logged in**
list                                       **Never logged in**
irc                                        **Never logged in**
www-data                                   **Never logged in**
syslog                                     **Never logged in**
sshd                                       **Never logged in**
mysql                                      **Never logged in**
ubuntu          pts/0    90.231.162.219   Thu Apr 16 22:24:21 +0200 2020

Innym bardzo częstym sposobem, którym szkodliwe oprogramowanie zapewnia sobie aktualizację oraz powrót do systemu są wpisy crontab:

crontab -l

* * * * * /tmp/.d >/dev/null 2>&1

Wpis w cronie administratora, wywołujący co minutę skrypt o dziwnej nazwie z katalogu /tmp? Bardziej podeżanie już chyba nie może być.

Pliki logów są dla atakujących są tym, co światło dla ćmy.

Ostatnim punktem są logi systemowe. Jest to najbardziej popularny punkt wśród adwersarzy, ponieważ zawsze odczuwają potrzebę posprzątania po swojej aktywności i po swoich adresach IP. Najczęściej modyfikacji podlegają:

/var/log/wtmp    - historyczne dane logowania
/var/log/lastlog - ostatnie logowania użytkowników
/var/log/btmp    - wszystkie niepoprawne logowania
/var/run/utmp    - bieżące dane logowania

Oraz inne znajdujące się w ścieżce /var/log/*. Typowymi oznakami są np. wyzerowane pliki logów:

ls -al /var/log

total 104
drwxrwxr-x 8  root   syslog 4096   Oct 24 06:25 .
drwxr-xr-x 17 root   root   4096   Jul 25 23:18 ..
-rw-r----- 1  syslog adm    0      Oct 25 00:55 auth.log
-rw-r----- 1  syslog adm    0      Oct 25 00:55 auth.log.1
-rw-r----- 1  syslog adm    0      Oct 25 00:55 auth.log.2.gz
-rw-rw---- 1  root   utmp   0      Oct 25 00:55 btmp
-rw------- 1  root   utmp   0      Oct 25 00:55 btmp.1
...
-rw-r——--- 1  syslog adm    0      Oct 25 00:55 kern.log
-rw-r----- 1  syslog adm    0      Oct 25 00:55 kern.log.1
-rw-r----- 1  syslog adm    0      Oct 25 00:55 kern.log.2.gz
-rw-r--r-- 1  root   root   292292 Oct 24 21:09 lastlog
-rw-r----- 1  syslog adm    0      Oct 25 00:55 syslog
-rw-r----- 1  syslog adm    0      Oct 25 00:55 syslog.1
-rw-r----- 1  syslog adm    0      Oct 25 00:55 syslog.2.gz

Prawie wszystkie pliki poziadają 0 bajtów długości, nawet te skompresowane. W dodatku posiadają te same daty, co pokazuje ich masową modyfikację. Jeśli sprawdzimy rekordy utmp możemy tam znaleźć dziwne puste rekordy sugerujące, że ktoś chciał ukryć swoją obecność:

utmpdump /var/run/utmp

Utmp dump of /var/run/utmp
[2] [000] [~~  ] [reboot  ] [~     ] [5.3.0-45    ] [0.0.0.0     ] [2020-04-04T12:53:22]
[1] [053] [~~  ] [runlevel] [~     ] [5.3.0-45    ] [0.0.0.0     ] [2020-04-04T12:53:43]
[6] [409] [tty1] [LOGIN   ] [tty1  ] [            ] [0.0.0.0     ] [2020-04-04T12:53:46]
[7] [301] [ts/0] [agresor ] [pts/0 ] [90.31.62.19 ] [90.31.62.19 ] [2020-04-16T20:24:21]
[8] [578] [ts/1] [        ] [pts/1 ] [            ] [90.31.62.19 ] [2020-04-15T20:32:38]
[0] [   ] [    ] [        ] [      ] [            ] [0.0.0.0     ] [                   ]

Identycznie sytuacja może wyglądać dla niepoprawnych logowań:

utmpdump /var/log/btmp

[6] [066] [   ] [agresor] [ssh:notty ] [19.0.51.17  ] [19.0.51.17 ] [2020-04-06T07:05:01]
[6] [830] [   ] [agresor] [ssh:notty ] [89.23.16.48 ] [89.23.16.48] [2020-04-09T20:56:58]
[6] [643] [   ] [agresor] [ssh:notty ] [89.23.16.28 ] [89.23.16.28] [2020-04-11T12:45:14]
[0] [000] [   ] [       ] [          ] [            ] [0.0.0.0    ] [                   ]
[0] [000] [   ] [       ] [          ] [            ] [0.0.0.0    ] [                   ]
[0] [000] [   ] [       ] [          ] [            ] [0.0.0.0    ] [                   ]

Lub z innej perspektywy:

lastb

agresor ssh:notty    89.23.16.28    Sat Apr 11 14:45 - 14:45  (00:00)
agresor ssh:notty    89.23.16.48    Thu Apr  9 22:56 - 22:56  (00:00)
agresor ssh:notty    19.0.51.17     Mon Apr  6 09:05 - 09:05  (00:00)
                       Thu Jan 1 00:00 - 00:00 (00:00)
                       Thu Jan 1 00:00 - 00:00 (00:00)

Dwa różne polecenia pokazują nam, że ostatnie rekordy zostały wyzerowane przez czyściciela logów.

Podsumowanie:

W swojej prezentacji Craig H. Rowland zwraca szczególną uwagę byśmy skupili się na prostych rzeczach. Pamiętali o zasadzie znalezienia jednej nieprawidłowości, która da nam wyraźny sygnał o tym, że coś jest nie tak z systemem. Jeśli atakujący wchodzący do systemu wykonuje po kolei kroki: A, B, C, D i E – wystarczy, że złapiemy jego jedną literkę, aby popsuć mu cały alfabet. Możemy to osiągnąć poprzez szukanie podejrzanych: procesów, katalogów, plików, użytkowników i operacji na logach za pomocą prostych narzędzi oraz bacznej uwadze.

Więcej informacji: Linux Compromise Assessment Command Cheat Sheet, Command Line CompromiseDetection for Linux, Linux Rapid Compromise Assessment – Craig H. Rowland