W poprzedniej części artykułu Rootkit na śniadanie opisywaliśmy narzędzia do automatycznego wyszukiwania rootkitów w systemie, działające za pomocą metody "cross-check" czyli porównywania list plików zwracanej przez system operacyjny z tym, co faktycznie jest na dysku.

W przypadku zastosowania rootkita ukierunkowanego specjalnie na konkretny program skanujący, takie narzędzia są najczęściej skazane na porażkę. To proste: ten, kto w systemie był pierwszy, może przejąć nad nim pełną kontrolę. Jedynie pewne niedopatrzenia ich autorów mogą powodować, że opisane wcześniej aplikacje, takie jak Rootkit Revealer czy BlackLight ,są w stanie wykryć rootkit w systemie przez niego opanowanym.

Zobacz również:

• Nearby Sharing od Google - wygodny sposób na przesyłanie plików

Każda aplikacja uruchamiana po zainstalowaniu rootkita będzie działać pod kontrolą tego złośliwego oprogramowania. Rootkit może dowolnie przejmować wywołania systemowe i podsuwać skanerowi takie dane, jakich ten oczekuje od "zdrowego" systemu. Autorzy skanera mogą w kolejnej wersji znaleźć miejsca, o których zapomnieli autorzy rootkita, i tam z kolei szukać jego śladów. Luka ta może z kolei zniknąć w kolejnej wersji rootkita - i tak bez końca. W tym wyścigu zbrojeń rootkit jest zawsze górą, ponieważ to on trafia do sieci jako pierwszy i w trakcie krótkiego "okresu swobody" może czynić szkody.

"Ciekawe" zastosowania

Problem nie jest tylko teoretyczny. Funkcjonalność rootkita Hacker Defender opisanego w poprzedniej części artykułu wręcz idealnie pasuje do zaprezentowanego przez firmę G DATA przykładu podrobienia podpisu elektronicznego za pomocą ukrytego w systemie filtra, który podmienia podpisywane dokumenty.

Sprzedająca certyfikaty X.509 firma Certum, której aplikację badała G DATA, odpowiedziała na tę demonstrację, że użytkownik powinien sam zadbać o to żeby w jego systemie działał firewall i antywirus. Ale kto będzie odpowiedzialny za konsekwencje fałszerstwa jeśli antywirus nie zobaczy rootkita?

Strider Ghostbuster

Istnieje jednak technika, która nie polega na żadnych wykrywaczach rootkitów, a na specyficznych właściwościach tych ostatnich oraz cechach systemu operacyjnego. W sytuacji gdy skaner działający w potencjalnie zarażonym systemie jest niewiarygodny, należy sprawdzić system ze środowiska, które na pewno jest "czyste". Pewnym rozwiązaniem jest uruchomienie na danym komputerze systemu z płyty CD z antywirusem i przeskanowanie dysku podejrzanego systemu. Stwarza to jednak wiele problemów praktycznych, po pierwsze związanych z aktualnością bazy antywirusa, a po drugie z czasem trwania skanowania.

Opracowana w ramach prowadzonego przez Microsoft projektu Strider metoda Ghostbuster Rootkit Detection wykorzystuje główną cechę rootkitów, jaką jest ukrywanie przez nie plików w systemie do ich wykrywania. Największa "zaleta" rootkitów staje się ich największą słabością. Technika ta polega na porównaniu listy plików wygenerowanej przez rootkit w zarażonym systemie z listą plików w systemie uruchomionym ze zdrowego systemu.

Opracowana w ramach prowadzonego przez Microsoft projektu Strider metoda Ghostbuster Rootkit Detection wykorzystuje główną cechę rootkitów, jaką jest ukrywanie przez nie plików w systemie do ich wykrywania. Największa "zaleta" rootkitów staje się ich największą słabością.

Technika ta polega na porównaniu listy plików wygenerowaną przez rootkit w zarażonym systemie z listą plików w systemie uruchomionym ze zdrowego kernela.

Ponieważ w bardzo krótkim czasie liczba plików obecnych w systemie nie zmienia się radykalnie, porównując listę plików wygenerowaną w stanie zarażonym oraz w stanie zdrowym, jesteśmy w stanie wykryć te, które zostały celowo ukryte. Będą to te pliki, które pojawiły się pomiędzy wykonaniem listingu systemu zdrowego i listingu systemu potencjalnie zarażonego rootkitem. Przez system zdrowy rozumiemy tutaj system operacyjny uruchomiony z pewnego, czystego nośnika, ale mający dostęp do "podejrzanego" systemu plików. Procedura badawcza jest następująca:

(1) listujemy wszystkie pliki w zakażonym systemie i zapisujemy listing do pliku A

(2) uruchamiamy czysty system z CD i z tego systemu powtarzamy listing plików na dysku systemu zarażonego, zrzut zapisujemy do pliku B

(3) porównujemy pliki A i B, wszystkie poważniejsze różnice to najprawdopodobniej rootkit.

Jak widać procedura wymaga ponownego uruchomienia systemu, jednak samo badanie jest o wiele szybsze niż skanowanie antywirusem. Nie jest też uzależnione od jakichkolwiek sygnatur. Rootkit sam wskazuje nam pliki, które ukrywa, a im bardziej je będzie ukrywać, tym bardziej będą one widoczne. Metoda ta jest także niezależna od systemu operacyjnego, ponieważ cel rootkita - ukrywanie plików - jest identyczny zarówno w Windows, jak i Linuxie.

Ghostbusting w praktyce

Do poszukiwania rootkita tą metodą wykorzystaliśmy bootowalny CD z Windows. Kluczowe wymagania co do systemu-nadzorcy to obsługa NTFS oraz aktualna wersja programu dir.exe. Wersje obecne w starszych wersjach Windows nie obsługują wszystkich wymaganych flag, pozwalających na listowanie ukrytych plików.

Pewnym problemem okazało się znalezienie bootowalnego systemu spełniającego te kryteria - Windows XP pozwala jedynie na sformatowanie dyskietki bootującej, jednak zawarty tam interpreter poleceń nie obsługuje odpowiednich flag w poleceniu "dir", a pochodzący z XP program dir.exe wymaga do uruchomienia środowiska graficznego pomimo że działa w trybie tekstowym. Z tych samych powodów spełzły na niczym próby zastosowania FreeDOS, CD instalacyjnych do Windows i podobnych wynalazków. Albo wersja "dir" była nie ta, albo brak było obsługi NTFS.

Najlepszym rozwiązaniem okazało się wykorzystanie sprytnego programu BartPE, który pozwala na zbudowanie bootowalnego CD z pełnym systemem Windows. Przy wykorzystaniu płyt instalacyjnych Windows XP i odrobinie kombinacji związnych z koniecznością równoczesnego nałożenia SP2 (BartPE robi to niemal w pełni automagicznie) mieliśmy CD z graficznym acz okrojonym XP i kilkoma narzędziami w rodzaju Rootkit Revealera jako bonusem.

Mając to narzędzie w zarażonym systemie uruchamiamy linię komend (Start->Run->cmd.exe), przechodzimy do głównego katalogu i robimy listingi wszystkich plików w dwóch wariantach:

1. CD \

2. DIR /S /B /AH >INFSBAH.TXT (wszystkie pliki z flagą "hidden")

3. DIR /S /B /A-H >INFSBA-H.TXT (wszystkie pliki bez flagi "hidden")

Wyniki te pozostawiamy w tym samym miejscu w którym zostały utworzone czyli w katalogu C:\ zarażonego systemu. Następnie uruchamiamy system z płyty CD, uruchamiamy linię komend, przechodzimy na badany dysk (C:\) i powtarzamy listingi do innych plików (dla odróżnienia niech zaczynają się od "CL" jak "clean"):

1. CD C:\

2. DIR /S /B /AH >CLSBAH.TXT

3. DIR /S /B /A-H >CLSBA-H.TXT

Dysponujemy teraz dwoma parami plików - dwa z nich to lista plików widzianych przez zarażony system, druga to lista plików widziana przez zdrowy system na dysku tego pierwszego. Odpowiedź na pytanie o lokalizację potencjalnego intruza wskaże nam zatem porównanie obu par plików.

Najwygodniej wykorzystać do tego narzędzie WinDiff. Ładujemy do niego kolejno pliki INFSBAH.TXT i CLSBAH.TXT, a w drugim rzucie INFSBA-H.TXT i CLSBA-H.TXT. W każdym z nich po kliknięciu guzika "Expand" poszukujemy czerwonych pól oznaczających różnice. Może być ich trochę, biorąc pod uwagę że Windows intensywnie wykorzystuje ukryte pliki do własnych celów, jednak każda większa grupa nie wyglądająca na pliki systemowe jest podejrzana.

W naszym testowym przypadku Hacker Defendera rootkit był widoczny jak na dłoni w drugiej parze plików. Pliki, które "zniknęły" z systemu zarażonego rootkitem, w czystym systemie są znowu widoczne.

Metoda ta będzie jednak skuteczna tylko wtedy, gdy rootkit będzie ukrywał pliki. Można spytać, po co komu rootkit, który nie ukrywa plików - przecież wtedy z łatwością wykryje go większość antywirusów? Otóż Joanna Rutkowska opisuje koncepcję rootkitów nowej generacji, które mogą ukrywać pliki selektywnie albo usuwać się przed restartem systemu. W długo działających systemach serwerowych rootkit i tak prawdopodobnie zdąży zebrać dość przydatnych informacji, by bez wielkiej hańby ulotnić się przed restartem mogącym oznaczać próbę jego znalezienia.