Otóż cała historia rozgrywa się na serwerze z zainstalowanym RedHatem 9, ale może oczywiście dotyczyć każdego innego systemu (ostatnio bardzo się zdziwiłem sposobem dystrybucji Debiana, w którym np. pakiet ssl był w bardzo starej i dziurawej wersji).

Pewnego pechowego dla mnie dnia dostałem maila od mojego ISP (providera internetowego), że maszyna wspomniana wyżej skanuje inne komputery przez ssh. Podstawową rzeczą, którą należało zrobić to sprawdzenie procesów (może mam jakiegoś nadgorliwego użytkownika). Moim oczom ukazał się taki oto obrazek:

# ps auxw
nobody 23199 0.0 0.3 1436 392 ? S 18:15 0:00 smtp
nobody 23200 0.0 0.9 2148 1144 ttyp8 S 18:15 0:00 sh -i
nobody 23406 0.0 0.3 1432 416 ? S 18:15 0:00 ./bind
nobody 23408 0.0 0.9 2148 1164 ttyp9 S 18:15 0:00 sh -i
nobody 24225 0.0 0.2 1384 308 ttyp9 S 18:15 0:00 ./sshscan-211 213.186.35
nobody 24332 22.8 0.4 1444 560 ttyp9 S 18:15 0:55 ./sshscan-211 213.186
nobody 24768 0.0 0.3 1432 416 ? S 18:16 0:00 ./bind
nobody 24769 0.0 0.9 2148 1144 ttypa S 18:16 0:00 sh -i
nobody 25142 0.0 0.3 1352 436 ttyp5 S 18:16 0:00 ./vuln 217.157.smb 217.157.smb.out 20
nobody 25219 0.0 0.4 1360 520 ttyp8 S 18:16 0:00 ./samba -b 0 -v 213.186.242.231
nobody 26849 0.5 0.3 1344 428 ttyp7 S 18:17 0:00 ./vuln 64.180.smb 64.180.smb.out 20
nobody 2218 0.0 1.2 9648 1532 ? S 18:19 0:00 /usr/local/apache/bin/httpd -DSSL
nobody 2240 0.0 0.3 1436 388 ? S 18:19 0:00 smtp
nobody 2242 0.0 0.9 2148 1144 ttypb S 18:19 0:00 sh -i
nobody 2316 0.0 1.2 9648 1532 ? S 18:19 0:00 /usr/local/apache/bin/httpd -DSSL
nobody 2317 0.0 1.2 9648 1532 ? S 18:19 0:00 /usr/local/apache/bin/httpd -DSSL
nobody 2317 0.0 1.2 9648 1532 ? S 18:19 0:00 /usr/local/apache/bin/httpd -DSSL
nobody 3183 0.0 0.3 1336 432 ttyp4 S 18:19 0:00 ./o0o 64.218.smb.out
nobody 5439 0.0 0.3 1372 496 ttypb S 18:19 0:00 ./l -h 213.186.242.231
nobody 5440 0.0 0.2 1340 304 ttypb T 18:19 0:00 ./l -h 213.186.242.231
nobody 5447 0.0 0.0 0 0 ttypb Z 18:19 0:00 [l ]
nobody 10027 0.0 0.3 1336 432 ttyp6 S 18:19 0:00 ./o0o 144.89.smb.out
nobody 13037 0.0 0.3 1344 448 ttyp7 S 18:19 0:00 ./vuln 64.180.smb 64.180.smb.out 20
nobody 13146 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13160 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13163 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13165 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13179 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13183 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13187 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13201 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13205 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13210 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13231 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13232 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186
nobody 13233 0.0 0.4 1444 568 ttyp9 S 18:19 0:00 ./sshscan-211213.186

(przytoczony wyżej fragment jest tak naprawdę zaczerpnięty ze strony http://guide.ovh.com/MachineSemiHackee/ na której wprawdzie po francusku ale jest obszerny opis całej procedury sprawdzania systemu)

Widzimy tu kilka procesów, które powinny nas mocno zaniepokoić. Te procesy to przede wszystkim sshscan, które występują w dużych ilościach i w imieniu użytkownika nobody, który zwykle przypisany jest do obsługi Apache. Drugim niepokojącym mnie procesem był proces sh -i, który występuje w zbyt dużych ilościach i jest to proces shell-a.

Zacząłem rozgryzanie problemu od wycięcia procesów użytkownika nobody (przy okazji tak się zagalopowałem ze wyciąłem sobie serwer WWW). Jak się okazało zostawienie procesów sh -i powodowało, że za chwilę powstawały nowe procesy sshscan. Co jednak z tego że procesy były czyste jak łza skoro niestety za jakieś pół dnia pojawiły się znowu. Przy pomocy find-a zacząłem szukać ostatnio modyfikowanych plików i generalnie tych, które były własnością nobody. Podstawowym moim błędem było zostawienie katalogu temp z pełnym dostępem do niego, na tą bolączkę generalnie pomaga albo montowanie bez prawa wykonywania - noexec albo ograniczenie praw do katalogu dla użytkowników. Okazało się, że i to nie do końca daje rozwiązanie, bo raz że ktoś nam po serwerze buszuje dwa że nie wiadomo skąd to paskudztwo się naprawdę bierze. W poszukiwaniach dotarłem w końcu do logu Apache. A w nim znalazłem dość groźnie wyglądający zapis:

--09:43:30-- http://www.jakis_host.domena/jakis_plik.roz

=> `jakis_plik_roz'

Connecting to nazwa_hosta:port... connected.

Proxy request sent, awaiting response... 200 OK

Length: 1,400,426 [text/plain]

100%[====================================>] 1,400,426 584.70K/s

09:43:32 (584.17 KB/s) - `jakis_plik.roz' saved [1,400,426/1,400,426]

Ile czasu się zastanawiałem skąd wget wziął się w logach Apache to moje, ale w końcu doszedłem do tego. Zacząłem w końcu od tego, co trzeba było zrobić od początku:

a) sprawdzić logi logowań użytkowników.

b) przejrzeć katalogi użytkowników.

Niestety okazało się, że powodem była zbyt łagodna (no dobra - brak) polityka nadawania haseł.

Opis działania naszego włamywacza:

1) Testowanie kolejnych hostów przy pomocy słownika haseł/loginów poprzez ssh.

2) złowionych w ten sposób „dawców" testuje pod względem uprawnień do katalogu domowego i dostępu do katalogu /temp.

3) sprawdzanie czy apache ma standardową kompilację i konfigurację, jeśli tak to zakładany jest katalog: public_html a w nim skrypt php (oczywiście obsługa php musi być wcześniej zapewniona) będący tak naprawdę shellem (no dobrze nie do końca tak, ale chodzi tu o funkcjonalność).

4) wgrywane są programy skanujące sieć

5) następuje skanowanie kolejnych potencjalnych „dawców"

Na koniec polecam pewien programik, który potrafi przeskanować nasz system pod kątem szczelności : Rkhunter (WWW.rootkit.nl) sprawdza on, jakie oprogramowanie, w jakich wersjach jest zainstalowane na serwerze i w przypadku, gdy napotka takie z dziurami informuje w odpowiedni sposób użytkownika, program ma też parę innych zalet m.in. aktualizację definicji plików/zmian w systemie powodujących złe jego funkcjonowanie oraz definicję programów posiadających znane błędy w działaniu.

Tekst nadesłał Maciej Theuss

Liczba komentarzy (1) - Dodaj swój komentarz do tego artykułu...