Praktyczna Analiza Malware. Przewodnik po usuwaniu złośliwego oprogramowania - Michael Sikorski, Andrew Honig

"Doskonały intensywny kurs w zakresie analizy złośliwego oprogramowania".

- Dino Dai Zovi, NIEZALEŻNY KONSULTANT W ZAKRESIE BEZPIECZEŃSTWA

"...najbardziej wszechstronny przewodnik po analizie złośliwego oprogramowania, oferujący szczegółowe omówienie wszystkich niezbędnych umiejętności niezbędnych do zrozumienia konkretnych wyzwań, przed którymi stoi współczesne malware".

- Chris Eagle, STARSZY WYKŁADOWCA W ZAKRESIE NAUK INFORMATYCZNYCH, NAVAL POSTGRADUATE SCHOOL

"Praktyczne wprowadzenie do analizy złośliwego oprogramowania - poleciłbym to każdemu, kto chce wnikliwie analizować złośliwe oprogramowanie występujące w systemach Windows".

- Ilfak Guilfanov, TWÓRCA IDA PRO

"...świetne wprowadzenie do analizy złośliwego oprogramowania. Każdy rozdział zawiera szczegółowe wyjaśnienia techniczne i praktyczne ćwiczenia laboratoryjne zapewniające bezpośrednie wprowadzenie do rzeczywistego malware".

- Sebastian Porst, INŻYNIER OPROGRAMOWANIA W GOOGLE

"...inżynieria odwrotna dla czytelników na wszystkich poziomach umiejętności. Bogate technicznie i przystępne laboratoria pogłębią Twoje zrozumienie sztuki i nauki związanej z inżynierią odwrotną. Gorąco polecam tę książkę zarówno początkującym, jak i ekspertom".

- Danny Quist, DOKTOR, ZAŁOŻYCIEL OFFENSIVE COMPUTING

"Jeśli chciałbyś przeczytać tylko jedną książkę o złośliwym oprogramowaniu lub chcesz włamać się do świata analizy malware, to powinieneś sięgnąć po tę książkę".

- Patrick Engbretson, PROFESOR W ZAKRESIE BEZPIECZEŃSTWA INFORMACJI, DAKOTA STATE UNIVERSITY I AUTOR The Basics of Hacking and Pen Testing

"...doskonały dodatek do materiałów szkoleniowych dla zaawansowanego kursu z zakresu bezpieczeństwa oprogramowania lub systemów wykrywania włamań. Laboratoria są szczególnie przydatne dla studentów w nauczaniu metod inżynierii odwrotnej, analizy i zrozumienia złośliwego oprogramowania".

- Sal Stolfo, PROFESOR, COLUMBIA UNIVERSITY

0. Elementarz analizy malware

Zanim przejdziemy do szczegółów analizy malware, musimy zdefiniować terminologię, uwzględnić typowe rodzaje złośliwego oprogramowania i wprowadzić podstawowe podejścia do jego analizy. Każde oprogramowanie, które robi coś, co powoduje szkodę dla użytkownika, komputera lub sieci - takie jak wirusy, konie trojańskie, robaki, rootkity, scareware i spyware - można uznać za malware. Chociaż złośliwe oprogramowanie występuje w wielu różnych postaciach, do jego analizy są wykorzystywane pewne typowe techniki. Ich wybór zależy od tego, jaki jest nasz cel.

Cel analizy malware

Celem analizy malware jest zazwyczaj zdobycie informacji potrzebnych do zareagowania na wtargnięcie intruza do sieci. Zazwyczaj chcemy ustalić, co się stało, i upewnić się, że udało się nam zlokalizować wszystkie zainfekowane maszyny i pliki. Analizując podejrzane malware, zwykle naszym celem jest ustalenie, co konkretny podejrzany plik binarny może zrobić, jak go wykryć w sieci oraz jak oszacować i powstrzymać powodowane przez niego szkody.

Po określeniu, które pliki wymagają pełnej analizy, nadchodzi moment na opracowanie sygnatur wykrywających infekcje złośliwym oprogramowaniem w sieci. Jak się dowiesz z tej książki, analiza malware może zostać wykorzystana do opracowania sygnatur hostowych i sieciowych.

Sygnatury hostowe lub indykatory służą do wykrywania złośliwego kodu na komputerach ofiarach. Indykatory te często określają pliki utworzone lub zmodyfikowane przez złośliwe oprogramowanie lub określone zmiany, które zostały wprowadzone do rejestru. W przeciwieństwie do sygnatur antywirusowych, indykatory malware koncentrują się na tym, co złośliwe oprogramowanie robi w systemie, a nie zaś na jego własnościach, co czyni je bardziej skutecznymi w wykrywaniu złośliwego oprogramowania, które zmienia swoją postać lub zostało usunięte z dysku twardego.

Sygnatury sieciowe służą do wykrywania złośliwego kodu poprzez monitorowanie ruchu sieciowego. Sygnatury sieciowe można tworzyć bez analizy złośliwego oprogramowania, chociaż indykatory tworzone za pomocą analizy malware są zwykle znacznie bardziej skuteczne, oferując wyższy wskaźnik wykrywalności i mniej fałszywych trafień.

Po utworzeniu sygnatur ostatecznym celem jest ustalenie, w jaki sposób działa złośliwe oprogramowanie. Jest to zazwyczaj najczęściej zadawane pytanie przez członków kierownictwa wyższego szczebla, którzy chcą pełnego wyjaśnienia poważnych włamań. Dogłębne techniki, których nauczysz się z tej książki, pozwolą ci określić cel i zdolności złośliwych programów.

Techniki analizy złośliwego oprogramowania

Najczęściej podczas przeprowadzania analizy malware będziemy dysponować tylko plikiem wykonywalnym, który nie jest czytelny dla człowieka. Aby go zrozumieć, będziemy używać różnych narzędzi i sztuczek, z których każde będzie ujawniać niewielką ilość informacji. Aby zobaczyć pełny obraz, będziemy musieli użyć różnych narzędzi.

Istnieją dwa podstawowe podejścia do analizy złośliwego oprogramowania: statyczne i dynamiczne. Analiza statyczna obejmuje badanie malware bez jego uruchamiania. Analiza dynamiczna polega na uruchomieniu malware. Obie techniki dzielą się również na podstawowe lub zaawansowane.

Podstawowa analiza statyczna

Podstawowa analiza statyczna polega na sprawdzeniu pliku wykonywalnego bez przeglądania rzeczywistych instrukcji. Może ona potwierdzić, czy plik jest złośliwy, podać informacje o jego funkcjonalności, a czasem dostarczyć informacje, które pozwolą na wygenerowanie prostych sygnatur sieciowych. Podstawowa analiza statyczna jest prosta i może być szybka, ale w dużej mierze jest nieskuteczna wobec wyrafinowanego złośliwego oprogramowania i może pomijać ważne zachowania.

Podstawowa analiza dynamiczna

Techniki podstawowej analizy dynamicznej polegają na uruchamianiu złośliwego oprogramowania i obserwowaniu jego zachowania w systemie w celu usunięcia infekcji, uzyskania skutecznych sygnatur lub uzyskania obu tych rezultatów. Zanim jednak będzie można bezpiecznie uruchomić złośliwe oprogramowanie, należy skonfigurować środowisko, które pozwoli przestudiować jego działanie bez ryzyka uszkodzenia systemu lub sieci. Podobnie jak techniki podstawowej analizy statycznej, techniki podstawowej analizy dynamicznej mogą być używane przez większość osób bez dogłębnej wiedzy na temat programowania, ale nie będą skuteczne w przypadku wszystkich złośliwych programów i mogą pominąć ważne funkcjonalności.

Zaawansowana analiza statyczna

Zaawansowana analiza statyczna polega na inżynierii odwrotnej elementów wewnętrznych malware poprzez załadowanie pliku wykonywalnego do deasemblera i sprawdzenie instrukcji programu w celu odkrycia, co on robi. Instrukcje są wykonywane przez CPU, a zatem zaawansowana analiza statyczna dokładnie nam powie, co robi program. Jednak ta analiza ma bardziej stromą krzywą uczenia się niż podstawowa analiza statyczna i wymaga specjalistycznej wiedzy na temat deasemblacji, konstrukcji kodu i koncepcji systemu operacyjnego Windows, o których będziemy uczyć się w tej książce.

Zaawansowana analiza dynamiczna

Zaawansowana analiza dynamiczna wykorzystuje debugger do sprawdzania wewnętrznego stanu działającego złośliwego pliku wykonywalnego. Techniki zaawansowanej analizy dynamicznej oferują inny sposób wydobywania szczegółowych informacji z pliku wykonywalnego. Są one najbardziej przydatne, gdy próbujemy uzyskać informacje, które trudno jest zebrać za pomocą innych technik. W tej książce pokażemy, jak korzystać z zaawansowanej analizy dynamicznej wraz z zaawansowaną analizą statyczną w celu pełnej analizy podejrzanego złośliwego oprogramowania.

Rodzaje złośliwego oprogramowania

Podczas przeprowadzania analizy malware często się okazuje, że możemy przyspieszyć analizę, zgadując, co próbuje zrobić złośliwe oprogramowanie, a następnie potwierdzając te hipotezy. Oczywiście lepiej to zrobimy, jeśli będziemy wiedzieć, jakie rzeczy typowo robi malware. W tym celu przedstawiamy kategorie, do których należy większość złośliwego oprogramowania:

Backdoor - złośliwy kod, który instaluje się na komputerze, aby umożliwić atakującemu dostęp; backdoory zazwyczaj pozwalają atakującemu połączyć się z komputerem przy użyciu prostego uwierzytelnienia lub nawet bez uwierzytelnienia i wykonywać polecenia w systemie lokalnym.

Botnet - podobny do backdoora, ponieważ umożliwia atakującemu dostęp do systemu, ale w tym przypadku wszystkie maszyny zainfekowane tym samym botnetem otrzymują te same instrukcje z jednego miejsca, z którego odbywa się atak.

Downloader - złośliwy kod, który istnieje tylko w celu pobrania innego złośliwego kodu; programy pobierające są zwykle instalowane przez atakujących, gdy po raz pierwszy uzyskują dostęp do systemu; program typu downloader pobiera i instaluje dodatkowy złośliwy kod.

Malware zajmujące się wykradaniem informacji - złośliwe oprogramowanie, które gromadzi informacje z komputera ofiary i zwykle wysyła je do atakującego; przykłady obejmują sniffery - moduły przechwytujące hasła i keyloggery; ten typ oprogramowania jest zwykle używany do uzyskiwania dostępu do kont internetowych, takich jak poczta e-mail lub bankowość internetowa.

Launcher - złośliwy program używany do uruchamiania innych złośliwych programów; tego typu programy zazwyczaj używają nietradycyjnych technik do uruchamiania innych złośliwych programów w celu zapewnienia sobie ukrycia lub lepszego dostępu do systemu.

Rootkit - złośliwy kod zaprojektowany w celu ukrycia istnienia innego kodu; rootkity są zwykle łączone z innym złośliwym oprogramowaniem, takim jak backdoory, aby umożliwić zdalny dostęp do atakującego i utrudnić wykrycie kodu przez ofiarę.

Scareware - malware zaprojektowany do przestraszenia zainfekowanego użytkownika i zmuszenia do zakupienia czegoś; zwykle ma taki interfejs użytkownika, który sprawia, że wygląda jak program antywirusowy lub inny program zabezpieczający; informuje użytkowników, że w ich systemie znajduje się złośliwy kod i że jedynym sposobem, aby się go pozbyć, jest zakup "oprogramowania", a w rzeczywistości sprzedawane przez niego oprogramowanie nie usuwa niczego więcej niż tylko scareware.

Malware rozsyłające spam - złośliwe oprogramowanie, które infekuje komputer użytkownika, a następnie używa go do rozsyłania spamu; to malware generuje dochody dla atakujących, umożliwiając im sprzedaż usług rozsyłania spamu.

Robak lub wirus - złośliwy kod, który może się kopiować i infekować dodatkowe komputery.

Malware często obejmuje wiele kategorii. Na przykład program może mieć komponent będący keyloggerem, który zbiera hasła, oraz robaka, który rozsyła spam. Często nie da się ściśle zaklasyfikować złośliwego oprogramowania według jego funkcjonalności.

Malware można również klasyfikować na podstawie tego, czy cel atakującego jest masowy, czy konkretnie wybrany. Malware nastawione na atak masowy, takie jak scareware, stosuje podejście mające na celu oddziaływanie na jak najwięcej komputerów. Spośród tych dwóch rodzajów występuje ono częściej, zwykle jest mniej zaawansowane i łatwiejsze do wykrycia oraz obrony, ponieważ to głównie na nim skupia się działanie oprogramowania zabezpieczającego.

Malware nastawione na konkretny cel, takie jak jedyny w swoim rodzaju backdoor, jest dostosowane do konkretnej organizacji. Stanowi ono większe zagrożenie dla sieci niż malware nastawione na atak masowy, ponieważ nie jest szeroko rozpowszechnione, a nasze produkty służące obronie prawdopodobnie przed nim nie ochronią. Bez szczegółowej analizy tego typu malware ochrona sieci przed nim i usunięcie infekcji jest prawie niemożliwe. Jest ono zwykle bardzo wyrafinowane, a jego zbadanie często wymaga zaawansowanych umiejętności analitycznych opisanych w tej książce.

Ogólne zasady analizy malware

Zakończymy to wprowadzenie kilkoma zasadami, o których należy pamiętać podczas przeprowadzania analizy.

Po pierwsze, nie warto dać się wciągnąć w szczegóły. Większość złośliwych programów jest dużych i złożonych i nie można zrozumieć każdego szczegółu. Zamiast tego należy skupić się na kluczowych cechach. Kiedy natrafimy na trudne i złożone fragmenty, postarajmy się uzyskać ogólne spojrzenie, zanim utkniemy w detalach.

Po drugie, pamiętajmy, że do różnych celów istnieją różne narzędzia i podejścia. Nie ma uniwersalnego sposobu. Każda sytuacja jest inna, a narzędzia i techniki, których się nauczymy, będą miały podobne, a czasem pokrywające się funkcjonalności. Jeśli nie osiągamy sukcesu za pomocą jednego narzędzia, wypróbujmy inne. Jeśli utkniemy, nie spędzajmy zbyt wiele czasu na jednym problemie - przejdźmy do czegoś innego. Spróbujmy przeanalizować malware z innej perspektywy lub po prostu spróbujmy innego podejścia.

Na koniec pamiętajmy, że analiza malware jest jak gra w kotka i myszkę. W miarę opracowywania nowych technik analizy malware, jego autorzy reagują nowymi technikami, by tę analizę udaremnić. Aby odnieść sukces jako analitycy malware, musimy być w stanie rozpoznać, zrozumieć i bronić się przed tymi technikami oraz reagować na zmiany w sztuce analizy złośliwego oprogramowania.

1. Podstawowe techniki statyczne

Nasz przegląd analizy malware zaczniemy od analizy statycznej, która zwykle stanowi pierwszy krok w badaniu złośliwego oprogramowania. Analiza statyczna opisuje proces analizy kodu lub struktury programu w celu ustalenia jego celu. Sam program w tym momencie nie jest uruchomiony. Natomiast podczas przeprowadzania analizy dynamicznej analityk faktycznie uruchamia program, o czym dowiemy się w rozdziale 3.

W tym rozdziale omówimy wiele sposobów uzyskiwania przydatnych informacji z plików wykonywalnych. Omówimy następujące techniki:

- używanie narzędzi antywirusowych do potwierdzania szkodliwości;

- używanie skrótów (hash) do identyfikowania złośliwego oprogramowania;

- gromadzenie informacji z łańcuchów, funkcji i nagłówków znajdujących się w pliku.

Każda technika może dostarczyć różnych informacji, a te, których użyjemy, zależą od naszych celów. Zazwyczaj korzystamy z kilku technik, aby zebrać jak najwięcej informacji.

Skanowanie antywirusowe - przydatny pierwszy krok

Podczas pierwszego analizowania potencjalnego malware dobrym pierwszym krokiem jest sprawdzenie go za pomocą różnych programów antywirusowych, które mogą być w stanie go zidentyfikować. Ale narzędzia antywirusowe z pewnością nie są idealne. W celu identyfikacji podejrzanych plików opierają się głównie na bazie danych możliwych do zidentyfikowania fragmentów znanego podejrzanego kodu (sygnatury plików), a także na analizie behawioralnej i dopasowaniu wzorców (heurystyka). Jednym z problemów jest to, że twórcy złośliwego oprogramowania mogą łatwo modyfikować kod, zmieniając w ten sposób sygnaturę swojego programu i unikając skanerów antywirusowych. Ponadto oprogramowanie antywirusowe często nie wykrywa rzadko występującego malware, ponieważ po prostu nie ma go w bazie danych. Wreszcie heurystyki - choć często udaje im się zidentyfikować nieznany złośliwy kod, mogą pominąć nowe i unikalne złośliwe oprogramowanie.

Ponieważ różne programy antywirusowe używają różnych sygnatur i heurystyk, przydatne jest uruchomienie kilku różnych tego typu programów przeciwko temu samemu podejrzanemu złośliwemu oprogramowaniu. Strony internetowe, takie jak VirusTotal (http://www.virustotal.com/), umożliwiają przesłanie pliku do przeskanowania przez wiele silników antywirusowych. VirusTotal generuje raport, który podaje całkowitą liczbę silników, które oznaczyły plik jako złośliwy, nazwę złośliwego oprogramowania i, jeśli to możliwe, dodatkowe informacje na temat złośliwego oprogramowania.

Haszowanie - odcisk palca malware

Haszowanie jest powszechną metodą stosowaną do jednoznacznej identyfikacji złośliwego oprogramowania. Złośliwe oprogramowanie jest przetwarzane przez program mieszający, który wytwarza unikalny skrót (hash) identyfikuje to oprogramowanie (rodzaj odcisku palca). Do analizy złośliwego oprogramowania najczęściej jest wykorzystywana funkcja skrótu Message-Digest Algorithm 5 (MD5), chociaż popularny jest również algorytm Secure Hash Algorithm 1 (SHA-1).

Na przykład użycie darmowego programu md5deep do obliczenia skrótu programu Solitaire dostarczanego z systemem Windows wygeneruje następujące dane wyjściowe:

C:\>md5deep c:\WINDOWS\system32\sol.exe

373e7a863a1a345c60edb9e20ec3231 c:\WINDOWS\system32\sol.exe

Skrót to 373e7a863ala345c60edb9e20ec3231.

Kalkulator WinMD5 z graficznym interfejsem użytkownika, pokazany na rysunku 1.1, może obliczać i wyświetlać skróty dla kilku plików jednocześnie.

Po wyznaczeniu unikalnego skrótu dla złośliwego oprogramowania możemy go użyć w następujący sposób:

- użyć skrótu jako etykiety;

- udostępnić ten skrót innym analitykom, aby pomóc im w identyfikacji złośliwego oprogramowania;

- wyszukać ten skrót online, aby sprawdzić, czy plik został już zidentyfikowany.

Rysunek 1.1. Rezultat WinMD5

Znajdowanie łańcuchów

Łańcuch w programie to łańcuch znaków, takich jak "the". Program zawiera łańcuchy, jeśli wyświetla komunikaty, łączy się z adresem URL lub kopiuje plik do określonej lokalizacji.

Przeszukiwanie w celu znalezienia łańcuchów może być prostym sposobem na uzyskanie wskazówek na temat funkcjonalności programu. Jeśli na przykład program uzyskuje dostęp do adresu URL, to w programie zobaczymy ten adres URL zapisany jako łańcuch. Do wyszukania w pliku wykonywalnym łańcuchów znaków, które zwykle są przechowywane w formacie ASCII lub Unicode, możemy użyć programu Strings (http://bit.ly/ic4plL).

UwagaMicrosoft używa terminu najszerszy zestaw znaków, aby opisać swoją implementację łańcuchów Unicode, które różnią się nieznacznie od standardów Unicode. W tej książce, gdy będziemy mówić o Unicode, będziemy mieli na myśli implementację Microsoftu.

Zarówno format ASCII, jak i Unicode przechowują znaki w sekwencjach zakończonych znakiem zerowym (NULL terminator), aby wskazać, że łańcuch jest kompletny. Łańcuchy ASCII używają 1 bajta na znak, Unicode zaś używa 2 bajtów na znak.

Rysunek 1.2 pokazuje łańcuch BAD zapisany jako ASCII. Łańcuch ASCII jest przechowywany jako bajty 0x42, 0x41, 0x44 i 0x00, gdzie 0x42 jest reprezentacją ASCII wielkiej litery B, 0x41 reprezentuje literę A itd. 0x00 na końcu jest znakiem zerowym.

Rysunek 1.2. Reprezentacja ASCII łańcucha BAD

Rysunek 1.3 pokazuje napis BAD zapisany jako Unicode. Łańcuch Unicode jest przechowywany jako bajty 0x42, 0x00, 0x41 itd. Wielka litera B jest reprezentowana przez bajty 0x42 i 0x00, a znakiem zerowym są dwa bajty 0x00.

Rysunek 1.3. Reprezentacja Unicode łańcucha BAD

Gdy Strings przeszukuje plik wykonywalny w poszukiwaniu łańcuchów ASCII i Unicode, ignoruje on kontekst i formatowanie, dzięki czemu może analizować dowolny typ pliku i wykrywać łańcuchy w całym pliku (chociaż oznacza to również, że może identyfikować bajty znaków jako łańcuchy, mimo że w rzeczywistości one nimi nie są). Strings wyszukuje trzyliterowe lub dłuższe sekwencje znaków ASCII i Unicode, po których występuje znak zakończenia łańcucha.

Czasami łańcuchy wykryte przez program Strings nie są rzeczywistymi łańcuchami. Jeśli na przykład Strings znajdzie sekwencję bajtów 0x56, 0x50, 0x33, 0x00, zinterpretuje to jako łańcuch VP3. Ale te bajty mogą w rzeczywistości nie reprezentować tego łańcucha - może to być adres pamięci, instrukcja procesora lub dane używane przez program. Strings pozostawia użytkownikowi możliwość odfiltrowania nieprawidłowych łańcuchów.

Na szczęście większość nieprawidłowych łańcuchów jest oczywista, ponieważ nie reprezentują one rzeczywistego tekstu. Na przykład następujący fragment pokazuje wynik działania Strings na pliku bp6.ex_:

C:>strings bp6.ex_

VP3

VW3

t$@

D$4

99.124.22.1

e-@

GetLayout

GDI32.DLL

SetLayout

M}C

Mail system DLL is invalid.!Send Mail failed to send message.

W tym przykładzie pogrubione łańcuchy można zignorować. Zazwyczaj, jeśli łańcuch jest krótki i nie odpowiada słowom, to prawdopodobnie nie ma znaczenia.

Jednocześnie łańcuchy GetLayout w  i SetLayout w  są funkcjami Windows używanymi przez bibliotekę graficzną. Możemy je łatwo zidentyfikować jako prawdziwe łańcuchy, ponieważ nazwy funkcji systemu Windows zwykle zaczynają się od wielkiej litery, tak jak i kolejne słowa.

GDI32.DLL w  również ma znaczenie, ponieważ jest to nazwa typowej biblioteki dołączanej dynamicznej (DLL) systemu Windows, używanej przez programy graficzne. (Pliki DLL zawierają kod wykonywalny, który jest współużytkowany przez wiele aplikacji).

Jak można sobie wyobrazić, wartość 99.124.22.1 w  to adres IP - najprawdopodobniej taki, którego złośliwe oprogramowanie będzie w jakiś sposób używać.

Wreszcie, Mail system DLL is invalid.!Send Mail failed to send message. w  jest komunikatem o błędzie. Często najbardziej przydatne informacje uzyskane podczas uruchamiania Strings znajdują się w komunikatach o błędach. Ta konkretna wiadomość ujawnia dwie rzeczy: temat wiadomości wysyłanej przez malware (prawdopodobnie za pośrednictwem poczty elektronicznej) oraz to, że zależy ono od biblioteki DLL systemu pocztowego. Informacje te sugerują, że być może warto sprawdzić dzienniki e-maili pod kątem podejrzanego ruchu oraz że inna biblioteka DLL (Mail system DLL) może być powiązana z tym konkretnym złośliwym oprogramowaniem. Zauważmy, że sama brakująca biblioteka DLL niekoniecznie musi być złośliwa; złośliwe oprogramowanie do realizacji swoich celów często wykorzystuje normalne biblioteki i pliki DLL.

Pakowanie i obfuskacja przez malware

Twórcy malware często wykorzystują pakowanie lub zaciemnianie (obfuskację), aby utrudnić wykrycie lub analizę ich plików. Programy z obfuskacją (zaciemnieniem) to takie, których wykonanie autor złośliwego oprogramowania próbował ukryć. Programy spakowane to podzbiór zaciemnionych programów, w których złośliwy program jest skompresowany i nie może być analizowany. Obie techniki poważnie ograniczają nasze próby statystycznej analizy złośliwego oprogramowania.

Nieszkodliwe programy prawie zawsze zawierają wiele łańcuchów. Malware, które jest spakowane lub zaciemnione, zawiera ich bardzo niewiele. Jeśli podczas przeszukiwania programu za pomocą Strings okaże się, że ma on tylko kilka łańcuchów, to prawdopodobnie jest on albo zaciemniony, albo spakowany, co sugeruje, że może być złośliwy. Aby przebadać go dokładniej, prawdopodobnie będziemy musieli zastosować na nim coś więcej niż tylko analizę statyczną.

UwagaKod spakowany i zaciemniony często zawiera co najmniej funkcje LoadLibrary i GetProcAddress, które służą do ładowania i uzyskiwania dostępu do dodatkowych funkcji.

Spakowane pliki

Jak pokazano na rysunku 1.4, po uruchomieniu spakowanego programu uruchamia się mały program opakowujący, którego zadaniem jest rozpakowanie spakowanego pliku, a następnie jego uruchomienie. Gdy spakowany program jest analizowany statycznie, szczegółowemu badaniu może zostać poddany tylko mały program opakowujący. (Bardziej szczegółowo pakowanie i rozpakowywanie omówiono w rozdz. 18).

Rysunek 1.4. Plik po lewej stronie jest oryginalnym plikiem wykonywalnym, z widocznymi wszystkimi łańcuchami, importami i innymi informacjami. Po prawej stronie znajduje się spakowany plik wykonywalny. Wszystkie łańcuchy spakowanego pliku, importy i inne informacje są skompresowane i niewidoczne dla większości narzędzi do analizy statycznej

Wykrywanie spakowanych programów za pomocą PEiD

Jednym ze sposobów wykrywania spakowanych plików jest użycie programu PEiD. Za pomocą tego narzędzia można wykryć typ pakera lub kompilatora zastosowanego do zbudowania aplikacji, co znacznie ułatwia analizę spakowanego pliku. Rysunek 1.5 pokazuje informacje o pliku orig_aj2.ex_ raportowane przez PEiD.

Rysunek 1.5. Program PEiD

UwagaRozwój i wsparcie dla PEiD zostało wstrzymane od kwietnia 2011 roku, ale nadal jest to najlepsze dostępne narzędzie do wykrywania pakera i kompilatora. W wielu przypadkach określi również, który pakiet został użyty do spakowania pliku.

Jak widać, PEiD zidentyfikował plik jako spakowany za pomocą UPX w wersji 0.89.6-1.02 lub 1.05-2.90. (Zignorujmy na razie inne pokazane tutaj informacje. Przeanalizujemy ten program bardziej szczegółowo w rozdz. 18).

Gdy program jest spakowany, to aby móc przeprowadzić dowolną analizę, należy go rozpakować. Proces rozpakowywania jest często złożony i został szczegółowo omówiony w rozdziale 18, natomiast program do pakowania UPX jest tak popularny i łatwy w użyciu do rozpakowywania, że zasługuje na szczególną uwagę w tym momencie. Na przykład, aby rozpakować złośliwe oprogramowanie za pomocą UPX, wystarczy pobrać UPX (http://upx.sourceforge.net/) i uruchomić go w następujący sposób, używając jako argumentu nazwy spakowanego programu:

upx -d PackedProgram.exe

UwagaWiele wtyczek PEiD-a bez ostrzeżenia uruchamia złośliwe oprogramowanie! (Zobacz rozdz. 2, aby dowiedzieć się, jak skonfigurować bezpieczne środowisko do uruchamiania złośliwego oprogramowania). Podobnie, jak wszystkie programy, zwłaszcza te wykorzystywane do analizy malware, PEiD też może zawierać słabe punkty. Na przykład w PEiD w wersji 0.92 występowało przepełnienie bufora, które umożliwiło atakującemu wykonanie dowolnego kodu. Pozwoliłoby to sprytnemu twórcy złośliwego oprogramowania napisać program wykorzystujący maszynę analityka malware. Pamiętajmy, aby używać najnowszej wersji PEiD.

Format plików Portable Executable

Do tej pory omawialiśmy narzędzia skanujące pliki wykonywalne bez względu na ich format. Jednak format pliku może ujawnić wiele informacji na temat funkcjonalności programu.

Format pliku Portable Executable (PE) jest używany przez pliki wykonywalne systemu Windows, kod obiektowy i biblioteki DLL. Format pliku PE to struktura danych, która zawiera informacje niezbędne dla modułu ładującego systemu operacyjnego Windows do zarządzania opakowanym kodem wykonywalnym. Prawie każdy plik z kodem wykonywalnym, który jest ładowany przez system Windows, ma format PE, chociaż w malware pojawiają się nieraz także pewne starsze formaty plików.

Pliki PE zaczynają się od nagłówka, który zawiera informacje o kodzie, typie aplikacji, wymaganych funkcjach z bibliotek i wymaganiach dotyczących przestrzeni. Informacje w nagłówku PE mają wielką wartość dla analityka malware.

Dołączane biblioteki i funkcje

Jedną z najbardziej przydatnych informacji, które możemy zebrać na temat pliku wykonywalnego, jest lista importowanych funkcji. Importy to funkcje używane przez dany program, które są faktycznie przechowywane w innym programie. Mogą być nimi biblioteki kodu zawierające funkcje wspólne dla wielu programów. Biblioteki kodu można wykorzystać w głównym pliku wykonywalnym poprzez dołączanie.

Programiści korzystają z importów w swoich programach, aby nie musieli ponownie implementować pewnych, tych samych funkcji w wielu aplikacjach. Biblioteki kodu można dołączać statycznie, w czasie wykonywania lub dynamicznie. Znajomość sposobu dołączania biblioteki kodu jest kluczowa dla naszego zrozumienia malware, ponieważ informacje, które możemy znaleźć w nagłówku pliku PE, zależą od sposobu dołączenia biblioteki kodu. W tym podrozdziale omówimy kilka narzędzi do przeglądania importowanych funkcji w pliku wykonywalnym.

Dołączanie statyczne, w czasie wykonywania i dynamiczne

Dołączanie statyczne jest najrzadziej stosowaną metodą łączenia bibliotek, chociaż jest powszechnie stosowana w programach dla Uniksa i Linuksa. Gdy biblioteka jest dołączana statycznie z plikiem wykonywalnym, cały kod z tej biblioteki jest kopiowany do pliku wykonywalnego, co powoduje zwiększenie jego rozmiaru. Analizując kod, trudno jest odróżnić kod dołączony statycznie od własnego kodu pliku wykonywalnego, ponieważ nic w nagłówku pliku PE nie wskazuje, że plik zawiera dołączony kod.

Chociaż niepopularne w nieszkodliwych programach, dołączanie w czasie wykonywania jest powszechnie stosowane w malware, zwłaszcza gdy jest spakowane lub zaciemnione. Pliki wykonywalne, które używają dołączania w czasie wykonywania, łączą się z bibliotekami tylko wtedy, gdy dana funkcja jest potrzebna, a nie na początku programu, jak w przypadku programów wykorzystujących dołączanie dynamiczne.

Kilka funkcji systemu Microsoft Windows pozwala programistom importować dołączane funkcje nie znajdujące się w nagłówku pliku programu. Spośród nich najczęściej są używane LoadLibrary i GetProcAddress. Wykorzystywane są także LdrGetProcAddress i LdrLoadDll. LoadLibrary i GetProcAddress umożliwiają programowi dostęp do dowolnej funkcji w dowolnej bibliotece w systemie, co oznacza, że gdy te funkcje są używane, nie można statycznie stwierdzić, z którymi funkcjami łączy się podejrzany program.

Ze wszystkich metod linkowania dołączanie dynamiczne jest najczęstszym i najbardziej interesującym dla analityków malware. Gdy biblioteki są dołączane dynamicznie, po załadowaniu programu system operacyjny hosta szuka niezbędnych bibliotek. Gdy program wywołuje funkcję z dołączonej biblioteki, funkcja ta jest wykonywana w tej bibliotece.

Nagłówek pliku PE przechowuje informacje o każdej bibliotece, która będzie załadowana, i o każdej funkcji, która będzie używana przez program. Użyte biblioteki i wywoływane funkcje są często najważniejszymi częściami programu, a ich identyfikacja jest szczególnie ważna, ponieważ pozwala odgadnąć, co robi program. Jeśli na przykład program importuje funkcję URLDownloadToFile, możemy przypuszczać, że łączy się on z internetem, aby pobrać zawartość, którą następnie zapisze w pliku lokalnym.

Eksplorowanie funkcji dołączanych dynamicznie za pomocą Dependency Walker

Program Dependency Walker (http://www.dependencywalker.com/), rozpowszechniany z niektórymi wersjami Microsoft Visual Studio i innymi pakietami programistycznymi Microsoftu, dla pliku wykonywalnego wyświetla tylko funkcje dołączane dynamicznie.

Rysunek 1.6 pokazuje analizę SERVICES.EX_ wykonaną przez Dependency Walker. Lewy panel w  pokazuje program oraz importowane biblioteki DLL, a mianowicie KERNEL32.DLL i WS2_32.DLL.

Rysunek 1.6. Program Dependency Walker

Kliknięcie KERNEL32.DLL pokazuje w prawym górnym panelu jego zaimportowane funkcje. Widzimy kilka funkcji, ale najciekawszą jest CreateProcessA, która mówi nam, że program prawdopodobnie utworzy inny proces, i sugeruje, że podczas uruchamiania programu powinniśmy uważać na uruchomienie dodatkowych programów.

Środkowy prawy panel pokazuje wszystkie funkcje KERNEL32.DLL, które mogą być zaimportowane - informacje, które nie są dla nas szczególnie przydatne. Zwróćmy uwagę na kolumnę w panelach i  oznaczoną jako Ordinal. Pliki wykonywalne mogą importować funkcje według wartości porządkowej zamiast po nazwie. Podczas importowania funkcji według wartości porządkowej nazwa funkcji nigdy nie pojawia się w oryginalnym pliku wykonywalnym i analitykowi może być trudniej się zorientować, która funkcja jest używana. Gdy malware importuje funkcję według wartości porządkowej, możemy się dowiedzieć, która funkcja jest importowana, patrząc na wartość porządkową w okienku .

Dwa dolne panele ( i ) zawierają dodatkowe informacje o wersjach bibliotek DLL, które zostałyby załadowane - odpowiednio - jeśli uruchomilibyśmy program i zostałyby zgłoszone błędy.

Biblioteki DLL programu mogą wiele powiedzieć o jego funkcjonalnościach. W tabeli 1.1 wymieniono typowe biblioteki DLL i to, co one mówią na temat aplikacji.

Tabela 1.1. Typowe DDL-e

DLL

Opis biblioteki

Kernel32.dll

bardzo powszechna biblioteka DLL; zawiera podstawowe funkcje, takie jak dostęp i manipulowanie pamięcią, plikami i sprzętem

Advapi32.dll

zapewnia dostęp do zaawansowanych i ważnych składników systemu Windows, takich jak Menedżer Usług i Rejestr

User32.dll

zawiera wszystkie komponenty interfejsu użytkownika, takie jak przyciski, paski przewijania i komponenty do kontrolowania działań użytkownika oraz reagowania na nie

Gdi32.dll

zawiera funkcje do wyświetlania i manipulowania grafiką

Ntdll.dll

jest interfejsem do jądra systemu Windows; pliki wykonywalne na ogół nie importują tego pliku bezpośrednio, chociaż zawsze jest on importowany pośrednio przez Kernel32.dll; jeśli plik wykonywalny importuje ten plik, oznacza to, że autor zamierzał użyć funkcji normalnie niedostępnych dla programów Windows; z tego interfejsu będą korzystać niektóre działania, takie jak ukrywanie funkcji lub manipulowanie procesami

WSock32.dll i Ws2_32.dll

sieciowe biblioteki DLL; program, który uzyskuje dostęp do jednej z nich, najprawdopodobniej łączy się z siecią lub wykonuje działania za jej pośrednictwem

Wininet.dll

zawiera funkcje sieciowe wyższego poziomu, które implementują protokoły, takie jak FTP, HTTP i NTP

Konwencje nazewnictwa funkcji

Podczas oceny nieznanych funkcji systemu Windows warto zwrócić uwagę na kilka konwencji nazewnictwa, ponieważ pojawiają się one często i mogą być mylące, jeśli ich nie rozpoznamy. Na przykład często występują nazwy funkcji z przyrostkiem Ex, takie jak CreateWindowEx. Gdy Microsoft aktualizuje funkcję, a nowa jest niezgodna ze starą, Microsoft nadal obsługuje starą funkcję. Nowa funkcja ma taką samą nazwę jak stara funkcja z dodanym przyrostkiem    Ex. Funkcje, które zostały znacząco zaktualizowane dwukrotnie, mają w nazwie dwa przyrostki    Ex.

Wiele funkcji, które jako parametry przyjmują łańcuchy, zawierają A lub W na końcu swoich nazw. Przykładem jest CreateDirectoryW. Ten znak nie pojawia się w dokumentacji funkcji - oznacza po prostu, że funkcja akceptuje parametr będący łańcuchem i że istnieją dwie różne wersje funkcji: jedna dla łańcuchów ASCII i druga dla łańcuchów z najszerszym zestawem znaków. Należy pamiętać o pominięciu końcowej litery A lub W podczas wyszukiwania funkcji w dokumentacji Microsoftu.

Importowane funkcje

Nagłówek pliku PE zawiera także informacje o specyficznych funkcjach używanych przez plik wykonywalny. Nazwy tych funkcji systemu Windows mogą dać nam dobre wyobrażenie o tym, co robi dany plik wykonywalny. Microsoft doskonale dokumentuje interfejs Windows API za pomocą biblioteki Microsoft Developer Network (MSDN). (W załączniku A znajduje się również lista funkcji często używanych przez złośliwe oprogramowanie).

Eksportowane funkcje

Podobnie jak w przypadku importowania, biblioteki DLL i pliki EXE eksportują funkcje w celu interakcji z innymi programami i kodem. Biblioteka DLL zazwyczaj implementuje jedną lub więcej funkcji i eksportuje je do wykorzystania przez plik wykonywalny, który może je następnie zaimportować i wykorzystać.

Plik PE zawiera informacje o tym, które funkcje eksportuje plik. Ponieważ biblioteki DLL są specjalnie tworzone w celu zaoferowania funkcjonalności wykorzystywanej przez pliki EXE, eksportowane funkcje są najczęściej spotykane w bibliotekach DLL. Pliki EXE nie są zaprojektowane w celu zapewnienia funkcjonalności dla innych plików EXE, a eksportowanie funkcji jest rzadkie. Jeśli w pliku wykonywalnym odkryjemy eksport, często może on nam dostarczyć użytecznych informacji.

W wielu przypadkach twórcy oprogramowania nazywają swoje eksportowane funkcje w sposób, który dostarcza użytecznych informacji. Jedną z powszechnych konwencji jest używanie nazw stosowanych w dokumentacji Microsoftu. Aby na przykład uruchomić program jako usługę, musimy najpierw zdefiniować funkcję ServiceMain. Obecność eksportowanej funkcji o nazwie ServiceMain informuje, że złośliwe oprogramowanie działa jako usługa.

Niestety, choć dokumentacja Microsoft nazywa tę funkcję ServiceMain, a programiści zazwyczaj nazywają ją tak samo, to taka funkcja może mieć dowolną nazwę. Dlatego nazwy eksportowanych funkcji mają w rzeczywistości ograniczone zastosowanie w przypadku wyrafinowanego złośliwego oprogramowania. Jeśli malware korzysta z eksportu, często albo całkowicie pomija nazwy, albo używa nazw niejasnych lub wprowadzających w błąd.

Możemy wyświetlić informacje o eksporcie za pomocą programu Dependency Walker omówionego w "Eksplorowaniu funkcji dołączanych dynamicznie za pomocą Dependency Walker" na stronie 16. Aby wyświetlić listę eksportowanych funkcji, należy kliknąć nazwę pliku, który chcemy zbadać. Na rysunku 1.6 okienko pokazuje wszystkie funkcje eksportowane w pliku.

Analiza statyczna w praktyce

Teraz, gdy poznaliśmy już podstawy analizy statycznej, przeanalizujmy prawdziwe malware. Przyjrzyjmy się potencjalnemu keyloggerowi, a następnie spakowanemu programowi.

PotentialKeylogger.exe - rozpakowany plik wykonywalny

Tabela 1.2 pokazuje skróconą listę funkcji importowanych przez PotentialKeylogger.exe, zebranych za pomocą Dependency Walker. Ponieważ widzimy tak wiele importów, od razu możemy stwierdzić, że ten plik nie jest spakowany.

Tabela 1.2. Skrócona lista bibliotek DLL i funkcji importowanych w PotentialKeylogger.exe

Kernel32.dll

User32.dll

User32.dll (kontynuacja)

CreateDirectoryW

BeginDeferWindowPos

ShowWindow

CreateFileW

CallNextHookEx

ToUnicodeEx

CreateThread

CreateDialogParamW

TrackPopupMenu

DeleteFileW

CreateWindowExW

TrackPopupMenuEx

ExitProcess

DefWindowProcW

TranslateMessage

FindClose

DialogBoxParamW

UnhookWindowsHookEx

FindFirstFileW

EndDialog

UnregisterClassW

FindNextFileW

GetMessageW

UnregisterHotKey

GetCommandLineW

GetSystemMetrics

GetCurrentProcess

GetWindowLongW

GDI32.dll

GetCurrentThread

GetWindowRect

GetStockObject

GetFileSize

GetWindowTextW

SetBkMode

GetModuleHandleW

InvalidateRect

SetTextColor

GetProcessHeap

IsDlgButtonChecked

GetShortPathNameW

IsWindowEnabled

Shell32.dll

HeapAlloc

LoadCursorW

CommandLineToArgvW

HeapFree

LoadIconW

SHChangeNotify

IsDebuggerPresent

LoadMenuW

SHGetFolderPathW

MapViewOfFile

MapVirtualKeyW

ShellExecuteExW

OpenProcess

MapWindowPoints

ShellExecuteW

ReadFile

MessageBoxW

SetFilePointer

RegisterClassExW

Advapi32.dll

WriteFile

RegisterHotKey

RegCloseKey

SendMessageA

RegDeleteValueW

SetClipboardData

RegOpenCurrentUser

SetDlgItemTextW

RegOpenKeyExW

SetWindowTextW

RegQueryValueExW

SetWindowsHookExW

RegSetValueExW

Podobnie jak większość programów średniej wielkości, ten plik wykonywalny zawiera bardzo dużo importowanych funkcji. Niestety, tylko niewielka część tych funkcji jest szczególnie interesująca w analizie malware. W tej książce zajmiemy się importami wykonywanymi przez malware, koncentrując się na najciekawszych funkcjach z punktu widzenia analizy złośliwego oprogramowania.

Jeśli nie mamy pewności, co robi dana funkcja, musimy ją sprawdzić. Aby pomóc w przeprowadzeniu analizy, załącznik A zawiera listę wielu funkcji najbardziej interesujących dla analityków złośliwego oprogramowania. Jeśli dana funkcja nie jest wymieniona w załączniku A, należy ją wyszukać w onlinowej witrynie MSDN.

Jako nowy analityk poświęcisz czas na wyszukiwanie wielu niezbyt interesujących funkcji, ale szybko zaczniesz się też uczyć, które funkcje mogą być ważne, a które nie. Na potrzeby tego przykładu pokażemy dużą liczbę importów, które nie mają wielkiego znaczenia, zaznajomimy się też zatem z patrzeniem na dużą ilość danych i skupianiem się na pewnych kluczowych perełkach informacji.

W normalnych warunkach nie wiedzielibyśmy, że to złośliwe oprogramowanie jest potencjalnym keyloggerem i musielibyśmy szukać funkcji, które dostarczą nam pewnych wskazówek. Dlatego będziemy się koncentrować tylko na funkcjach, które dostarczają informacji dotyczących funkcjonalności programu.

Import Kernel32.dll w tabeli 1.2 mówi nam, że to oprogramowanie może otwierać i manipulować procesami (za pomocą OpenProcess, GetCurrentProcess i GetProcessHeap) oraz plikami (za pomocą ReadFile, CreateFile i WriteFile). Funkcje FindFirstFile i FindNextFile są szczególnie interesujące i możemy ich użyć do przeszukiwania katalogów.

Jeszcze bardziej interesujący jest import z User32.dll. Duża liczba funkcji manipulacyjnych GUI (takich jak RegisterClassEx, SetWindowText i ShowWindow) wskazuje na wysokie prawdopodobieństwo, że ten program ma GUI (chociaż GUI niekoniecznie musi być wyświetlane użytkownikowi).

Funkcja SetWindowsHookEx jest powszechnie używana w programach szpiegujących i jest najpopularniejszym sposobem, w jaki keyloggery przechwytują dane z klawiatury. Ta funkcja ma również zasadne zastosowania, ale jeśli podejrzewamy, że mamy do czynienia z malware i widzimy tę funkcję, to prawdopodobnie patrzymy na funkcję keyloggera.

Interesująca jest również funkcja RegisterHotKey. Rejestruje klawisz skrótu (taki jak CTRL-SHIFT-P), dzięki czemu za każdym razem, gdy użytkownik naciśnie pewną kombinację klawiszy, aplikacja jest powiadamiana. Bez względu na to, która aplikacja jest aktualnie aktywna, klawisz skrótu przeniesie użytkownika do tej aplikacji.

Importy z GDI32.dll są związane z grafiką, co po prostu potwierdza, że program prawdopodobnie ma GUI. Importy z Shell32.dll informują nas, że ten program może uruchamiać inne programy - jest to cecha wspólna zarówno dla złośliwego oprogramowania, jak i normalnych programów.

Import z Advapi32.dll mówi nam, że ten program używa rejestru, z czego z kolei wynika, że powinniśmy szukać łańcuchów, które wyglądają jak klucze rejestru. Ścieżki rejestru przypominają katalogi. W tym przypadku znaleźliśmy łańcuch Software\Microsoft\Windows\CurrentVersion\Run, który jest kluczem rejestru (często używanym przez złośliwe oprogramowanie) kontrolującym, które programy są uruchamiane automatycznie podczas startu systemu Windows.

Ten plik wykonywalny zawiera również kilka eksportów: LowLevelKeyboardProc i LowLevelMouseProc. Dokumentacja Microsoftu mówi: "Procedura podpięcia LowLevelKeyboardProc jest funkcją wywołania zwrotnego zdefiniowaną na poziomie aplikacji lub biblioteki, używaną wraz z funkcją SetWindowsHookEx". Innymi słowy, funkcja ta jest używana wraz z SetWindowsHookEx w celu określenia, która funkcja będzie wywoływana, gdy wystąpi określone zdarzenie - w tym przypadku niskopoziomowe zdarzenie związane z klawiaturą. Dokumentacja SetWindowsHookEx wyjaśnia dalej, że ta funkcja zostanie wywołana, gdy wystąpią pewne niskopoziomowe zdarzenia związane z klawiaturą.

Dokumentacja Microsoft używa nazwy LowLevelKeyboardProc, a programista tej aplikacji w tym przypadku uczynił tak samo. Dzięki temu jesteśmy w stanie uzyskać cenne informacje, ponieważ programista nie zaciemnił nazwy eksportu.

Korzystając z informacji uzyskanych z analizy statycznej tych importów i eksportów, możemy wyciągnąć istotne wnioski oraz sformułować hipotezy dotyczące tego złośliwego oprogramowania. Po pierwsze, wydaje się prawdopodobne, że jest to lokalny keylogger, który używa SetWindowsHookEx do rejestrowania naciśnięć klawiszy. Możemy także przypuszczać, że ma GUI, które jest wyświetlane tylko dla konkretnego użytkownika, i że skrót klawiszowy zarejestrowany za pomocą RegisterHotKey określa skrót klawiszowy, którego używa atakujący, aby zobaczyć GUI keyloggera i uzyskać dostęp do zarejestrowanych naciśnięć klawiszy. Możemy dalej spekulować na podstawie działań dotyczących rejestru oraz istnienia Software\Microsoft\Windows\CurrentVersion\Run, że program modyfikuje go tak, aby był ładowany podczas uruchamiania systemu.

PackedProgram.exe - ślepy zaułek

Tabela 1.3 pokazuje pełną listę funkcji importowanych przez drugi przypadek nieznanego malware. Zwięzłość tej listy mówi, że ten program jest spakowany lub zaciemniony, co dodatkowo potwierdza fakt, że ten program nie zawiera czytelnych łańcuchów. Kompilator Windows nie utworzyłby programu, który importuje tak małą liczbę funkcji; nawet program Hello, World miałby ich więcej.

Tabela 1.3. DLL i funkcje importowane w PackedProgram.exe

Kernel32.dll

User32.dll

GetModuleHandleA

MessageBoxA

LoadLibraryA

GetProcAddress

ExitProcess

VirtualAlloc

VirtualFree

Fakt, że ten program jest spakowany, jest cenną informacją, ale jego spakowany charakter uniemożliwia nam również zdobycie wiedzy na temat programu za pomocą podstawowej analizy statycznej. Będziemy musieli użyć bardziej zaawansowanych technik analizy, takich jak analiza dynamiczna (opisana w rozdz. 3) lub rozpakowanie (opisane w rozdz. 18).

Nagłówki i sekcje plików PE

Nagłówki plików PE mogą zawierać znacznie więcej informacji niż tylko importy. Format pliku PE zawiera nagłówek, a po nim serię sekcji. Nagłówek zawiera metadane dotyczące samego pliku. Po nagłówku znajdują się rzeczywiste sekcje pliku, z których każda zawiera przydatne informacje. W miarę postępów będziemy w książce kolejno omawiać strategie przeglądania informacji w każdej z tych sekcji. Oto najczęstsze i najciekawsze sekcje w pliku PE:

.text - zawiera instrukcje wykonywane przez procesor; wszystkie pozostałe sekcje przechowują dane i informacje pomocnicze; zasadniczo jest to jedyna sekcja, którą można wykonać, i powinna być jedyną sekcją zawierającą kod;

.rdata - zazwyczaj zawiera informacje dotyczące importów i eksportów, które są tymi samymi informacjami dostępnymi dla narzędzi Dependency Walker i PEview; mogą się w niej również znajdować inne dane tylko do odczytu używane przez program; czasami plik będzie zawierać sekcje .idata oraz .edata przechowujące informacje o importach i eksportach (zobacz tab. 1.4);

.data - zawiera globalne dane programu, które są dostępne z dowolnego miejsca w programie; lokalne dane nie są przechowywane w tej sekcji ani nigdzie indziej w pliku PE (omówimy ten temat w rozdz. 6);

.rsrc - zawiera zasoby używane przez plik wykonywalny, które nie są uważane za jego części, takie jak ikony, obrazy, menu i łańcuchy; łańcuchy mogą być przechowywane w sekcji .rsrc lub w głównym programie, ale często są umieszczane właśnie tutaj w celu obsługi wielu języków.

Nazwy sekcji są często spójne w ramach tego samego kompilatora, ale mogą być różne w różnych kompilatorach. Na przykład Visual Studio dla kodu wykonywalnego używa .text, Borland Delphi zaś używa CODE. System Windows nie dba o rzeczywistą nazwę, ponieważ wykorzystuje bardziej szczegółowe informacje znajdujące się w nagłówku PE, aby określić sposób użycia sekcji. Co więcej, aby utrudnić analizę nazwy sekcji są czasami zaciemnione. Na szczęście najczęściej są używane nazwy domyślne. Tabela 1.4 zawiera listę tych najczęściej spotykanych.

Tabela 1.4. Sekcje pliku PE dla pliku wykonywalnego w systemie Windows

Sekcja pliku wykonywalnego

Opis

.text

zawiera kod wykonywalny

.rdata

przechowuje dane tylko do odczytu dostępne globalnie w programie

.data

przechowuje globalne dane dostępne w całym programie

.idata

występuje czasami i zawiera informacje o importowanych funkcjach; jeśli ta sekcja nie jest obecna, informacje o importowanych funkcjach będą się znajdować w sekcji .rdata

.edata

występuje czasami i zawiera informacje o eksportowanych funkcjach; jeśli ta sekcja nie jest obecna, informacje o eksportowanych funkcjach będą się znajdować w sekcji .rdata

.pdata

występuje tylko w 64-bitowych plikach wykonywalnych i przechowuje informacje dotyczące obsługi wyjątków

.rsrc

przechowuje zasoby potrzebne dla pliku wykonywalnego

.reloc

zawiera informacje dotyczące relokacji plików bibliotek

Badanie plików PE za pomocą PEview

Format pliku PE przechowuje ciekawe informacje w nagłówku. Jak pokazano na rysunku 1.7, do przeglądania tych informacji możemy użyć narzędzia PEview.

Na rysunku lewy panel wyświetla główne części nagłówka PE. Pozycja IMAGE_FILE_HEADER jest podświetlona, ponieważ jest aktualnie zaznaczona.

Pierwsze dwie części nagłówka PE - IMAGE_DOS_HEADER i MS-DOS Stub Program są historyczne i nie dostarczają nam żadnych informacji, które mogłyby nas szczególnie zainteresować.

Następna sekcja nagłówka PE, IMAGE_NT_HEADERS, pokazuje nagłówki NT. Sygnatura jest zawsze taka sama i można ją zignorować.

Wpis IMAGE_FILE_HEADER, podświetlony w prawym panelu , zawiera podstawowe informacje o pliku. Etykieta Time Date Stamp w  informuje, kiedy ten plik wykonywalny został skompilowany, co może być bardzo przydatne w analizie złośliwego oprogramowania i reagowaniu na incydenty. Na przykład odległy czas kompilacji sugeruje, że jest to starszy atak, a programy antywirusowe mogą zawierać sygnatury dla tego złośliwego oprogramowania. Bliski czas kompilacji sugeruje odwrotność.

Rysunek 1.7. Podgląd IMAGE_FILE_HEADER w programie PEview

Czas kompilacji jest nieco problematyczny. Wszystkie programy Delphi jako czasu kompilacji używają 19 czerwca 1992 roku. Jeśli zobaczymy ten czas kompilacji, to prawdopodobnie będziemy mieli do czynienia z programem w Delphi i w rzeczywistości nie będziemy wiedzieć, kiedy został on faktycznie skompilowany. Ponadto, kompetentny twórca malware może łatwo sfałszować czas kompilacji. Jeśli zobaczymy czas kompilacji, który nie ma sensu, to prawdopodobnie został on sfałszowany.

Sekcja IMAGE_OPTIONAL_HEADER zawiera kilka ważnych informacji. Etykieta Subsystem wskazuje, czy jest to program działający z konsoli czy z GUI. Programy konsolowe mają wartość IMAGE_SUBSYSTEM_WINDOWS_CUI i działają w oknie poleceń. Programy z GUI mają wartość IMAGE_SUBSYSTEM_WINDOWS_GUI i działają w systemie Windows. Używane są również mniej popularne podsystemy, takie jak Native lub Xbox.

Najciekawsze informacje pochodzą z nagłówków sekcji znajdujących się w IMAGE_SECTION_HEADER, co pokazano na rysunku 1.8. Te nagłówki służą do opisania każdej sekcji pliku PE. To kompilator generalnie tworzy i nazywa sekcje pliku wykonywalnego, a użytkownik ma niewielką kontrolę nad tymi nazwami. W rezultacie sekcje są zwykle spójne między plikami wykonywalnymi (zobacz tab. 1.4), a wszelkie odchylenia mogą być podejrzane.

Na przykład (rys. 1.8) Virtual Size mówi nam, ile miejsca jest przydzielane sekcji podczas procesu ładowania. Size of Raw Data pokazuje, jak duża jest sekcja na dysku. Te dwie wartości powinny zwykle być równe, ponieważ dane powinny zajmować tyle samo miejsca na dysku co w pamięci. Małe różnice są normalne i wynikają z różnic między wyrównaniem w pamięci i na dysku.

Rozmiary sekcji mogą być przydatne w wykrywaniu spakowanych plików wykonywalnych. Jeśli na przykład Virtual Size jest znacznie większy niż Size of Raw Data, to wiemy, że sekcja zajmuje więcej miejsca w pamięci niż na dysku. Często wskazuje to na spakowany kod, szczególnie jeśli sekcja .text zajmuje więcej miejsca pamięci niż na dysku.

Rysunek 1.8. Podgląd IMAGE_SECTION_HEADER sekcji .text w programie PEview

Tabela 1.5 pokazuje sekcje z PotentialKeylogger.exe. Jak widać, każda z sekcji .text, .rdata i .rsrc ma Virtual Size i Size of Raw Data takiego samego rozmiaru. Sekcja .data może się wydawać podejrzana, ponieważ ma znacznie większy rozmiar sekcji po załadowaniu do pamięci niż rozmiar sekcji w pliku, ale jest to normalne w przypadku tej sekcji w programach Windows. Pamiętajmy jednak, że sama ta informacja nie mówi nam, że program nie jest złośliwy; pokazuje po prostu, że prawdopodobnie nie jest on spakowany i że nagłówek pliku PE został wygenerowany przez kompilator.

Tabela 1.5. Informacje o sekcjach PotentialKeylogger.exe

Sekcja

Rozmiar wirtualny

Rozmiar sekcji

.text

7AF5

7C00

.data

17A0

0200

.rdata

1AF5

1C00

.rsrc

72B8

7400

Tabela 1.6 pokazuje sekcje PackedProgram.exe. Sekcje w tym pliku mają wiele anomalii: nietypowe są sekcje o nazwach Dijfpds, .sdfuok i Kijijl, sekcje .text, .data i .rdata zaś są podejrzane. Sekcja .text ma wartość Size of Raw Data równą 0, co oznacza, że nie zajmuje ona miejsca na dysku, a jej VirtualSize to A000, co oznacza, że miejsce zostanie przydzielone dla segmentu .text. To mówi nam, że kod wykonywalny zostanie rozpakowany do zaalokowanej sekcji .text.

Tabela 1.6. Informacje o sekcjach PackedProgram.exe

Sekcja

Rozmiar wirtualny

Rozmiar sekcji

.text

A000

0000

.data

3000

0000

.rdata

4000

0000

.rsrc

19000

3400

Dijfpds

20000

0000

.sdfuok

34000

3313F

Kijijl

1000

0200

Podgląd sekcji zasobów za pomocą Resource Hackera

Teraz, gdy skończyliśmy przeglądać nagłówek pliku PE, możemy przyjrzeć się niektórym innym sekcjom. Jedyną sekcją, którą możemy zbadać bez dodatkowej wiedzy z późniejszych rozdziałów, jest sekcja dotycząca zasobów. Aby przejrzeć sekcję .rsrc, możemy skorzystać z bezpłatnego narzędzia Resource Hacker dostępnego na stronie http://www.angusj.com/. Klikając elementy Resource Hackera, będziemy mogli zobaczyć łańcuchy, ikony i menu. Wyświetlane menu są identyczne z tymi używanymi przez program. Rysunek 1.9 pokazuje ekran Resource Hackera dla windowsowego programu Kalkulator - calc.exe.

Rysunek 1.9. Wygląd okna Resource Hackera dla calc.exe

Panel po lewej stronie pokazuje wszystkie zasoby zawarte w tym pliku wykonywalnym. Każdy główny folder pokazany w lewym okienku reprezentuje inny typ zasobu. Istotne sekcje do analizy złośliwego oprogramowania zawierają:

- sekcja Icon zawiera listę obrazów wyświetlanych wtedy, gdy plik wykonywalny pojawia się na liście plików;

- sekcja Menu przechowuje wszystkie menu pojawiające się w różnych oknach, takich jak menu Plik, Edycja i Widok; zawiera nazwy wszystkich menu, a także tekst pokazywany dla każdego z nich; nazwy powinny dać nam dobry pogląd na ich funkcjonalności;

- sekcja Dialog zawiera menu dialogowe programu; okno dialogowe pokazuje, co zobaczy użytkownik po uruchomieniu calc.exe; gdybyśmy nie wiedzieli nic więcej o calc.exe, moglibyśmy zidentyfikować go jako program typu kalkulator, po prostu patrząc na to okno dialogowe;

- sekcja String Table przechowuje łańcuchy znaków;

- sekcja Version Info zawiera numer wersji oraz często nazwę firmy i oświadczenie o prawach autorskich.

Sekcja .rsrc pokazana na rysunku 1.9 jest typowa dla aplikacji Windows i może zawierać wszystko to, czego wymaga programista.

UwagaMalware, a czasami także i nieszkodliwe oprogramowanie, często przechowują tutaj zagnieżdżony program lub sterownik, a przed uruchomieniem programu wyodrębniają wbudowany plik wykonywalny lub sterownik. Resource Hacker pozwala wyodrębnić te pliki do indywidualnej analizy.

Korzystanie z innych narzędzi dla plików PE

Do przeglądania nagłówka PE dostępnych jest wiele innych narzędzi. Dwa najbardziej przydatne narzędzia to PEBrowse Professional i PE Explorer.

PEBrowse Professional (http://www.smidgeonsoft.prohosting.com/pebrowsepro-file-viewer.html) jest podobny do PEview. Pozwala na podgląd bajtów z każdej sekcji oraz pokazuje przeanalizowane dane. PEBrowse Professional najlepiej radzi sobie z prezentowaniem informacji z sekcji dotyczącej zasobów (.rsrc).

PE Explorer (http://www.heaventools.com/) ma bogaty interfejs graficzny, który pozwala poruszać się po różnych częściach pliku PE. Możemy edytować niektóre części pliku PE, a zawarty w nim edytor zasobów doskonale nadaje się do przeglądania i edycji zasobów pliku. Główną wadą tego narzędzia jest to, że nie jest ono darmowe.

Podsumowanie nagłówka Pe

Nagłówek PE zawiera przydatne informacje dla analityka malware i będziemy nadal je analizować w kolejnych rozdziałach. Tabela 1.7 zawiera przegląd kluczowych informacji, które można uzyskać z nagłówka PE.

Tabela 1.7. Informacje w nagłówku PE

Pole

Ujawniane informacje

Importy

funkcje z innych bibliotek używane przez malware

Eksporty

funkcje malware, które mogą być wywoływane przez inne programy lub biblioteki

Znacznik czasu

czas kompilacji programu

Sekcje

nazwy sekcji w pliku oraz ich rozmiary na dysku i w pamięci

Podsystem

wskazanie, czy program jest aplikacją wiersza poleceń, czy zawiera GUI

Zasoby

łańcuchy, ikony, menu i inne informacje zawarte w pliku

Podsumowanie

Korzystając z zestawu stosunkowo prostych narzędzi, możemy przeprowadzić analizę statyczną malware i uzyskać pewien wgląd w jego działanie. Ale analiza statyczna jest zazwyczaj tylko pierwszym krokiem i zwykle konieczne są dalsze badania. Następnym krokiem jest skonfigurowanie bezpiecznego środowiska, w którym można uruchomić złośliwe oprogramowanie i przeprowadzić podstawową analizę dynamiczną, co zobaczymy w dwóch kolejnych rozdziałach.

2. Analiza malware na maszynach wirtualnych

Przed uruchomieniem malware w celu przeprowadzenia analizy dynamicznej należy skonfigurować bezpieczne środowisko. Nowe malware może być pełne niespodzianek, a jeśli uruchomimy je na maszynie produkcyjnej, może szybko rozprzestrzenić się na inne maszyny w sieci i bardzo trudno będzie je usunąć. Bezpieczne środowisko pozwoli zbadać malware bez narażania komputera lub innych urządzeń w sieci na nieoczekiwane i niepotrzebne ryzyko.

Aby bezpiecznie badać złośliwe oprogramowanie, można użyć dedykowanych maszyn fizycznych lub wirtualnych. Malware można analizować na pojedynczych fizycznych maszynach w fizycznie izolowanych sieciach. Są to izolowane sieci z maszynami odłączonymi od internetu lub jakichkolwiek innych sieci, aby zapobiec rozprzestrzenianiu się złośliwego oprogramowania.

Fizycznie odizolowane sieci umożliwiają uruchamianie malware w prawdziwym środowisku bez narażania innych komputerów na ryzyko. Wadą tego scenariusza testowego jest jednak brak połączenia z internetem. Wiele elementów złośliwego oprogramowania zależy od połączenia z internetem w celu pobrania aktualizacji i poleceń, przekazania kontroli oraz innych zachowań.

Kolejną wadą analizy malware na maszynach fizycznych, a nie wirtualnych, jest to, że może być ono trudne do usunięcia. Aby uniknąć tych problemów, większość osób testujących złośliwe oprogramowanie na fizycznych urządzeniach używa narzędzia takiego jak Norton Ghost, w celu zarządzania obrazami kopii zapasowych swoich systemów operacyjnych, które przywracają na swoich komputerach po zakończeniu analizy.

Główną zaletą korzystania z fizycznych maszyn do analizy malware jest to, że złośliwe oprogramowanie może czasem działać inaczej na maszynach wirtualnych. Gdy analizujemy je na maszynie wirtualnej, niektóre malware jest w stanie wykryć, że jest uruchamiane na maszynie wirtualnej i w trakcie analizy będzie się zachowywać inaczej.

Ze względu na ryzyko i wady związane z używaniem fizycznych maszyn do analizy złośliwego oprogramowania do analizy dynamicznej najczęściej są używane maszyny wirtualne. W tym rozdziale skupimy się na wykorzystaniu maszyn wirtualnych do analizy malware.

Struktura maszyny wirtualnej

Maszyny wirtualne są jak komputer wewnątrz komputera, co pokazano na rysunku 2.1. System operacyjny gościa jest instalowany w systemie hosta maszyny wirtualnej - system operacyjny działający na maszynie wirtualnej jest odizolowany od systemu hosta. Malware działający na maszynie wirtualnej nie może uszkodzić systemu operacyjnego hosta. A jeśli złośliwe oprogramowanie uszkodzi maszynę wirtualną, to możemy po prostu ponownie zainstalować na niej system operacyjny lub przywrócić maszynę wirtualną do stanu początkowego.

Rysunek 2.1. Tradycyjne aplikacje działają tak, jak pokazano w lewej kolumnie. System operacyjny gościa znajduje się całkowicie w maszynie wirtualnej, a aplikacje wirtualne działają w systemie operacyjnym gościa

VMware oferuje popularną serię produktów do wirtualizacji maszyn stacjonarnych, które można wykorzystać do analizy malware na maszynach wirtualnych. VMware Player jest darmowy i może być używany do tworzenia i uruchamiania maszyn wirtualnych, ale brakuje mu niektórych funkcjonalności niezbędnych do skutecznej analizy malware. VMware Workstation kosztuje nieco mniej niż 200 USD i jest ogólnie lepszym wyborem do analizy malware. Zawiera on funkcjonalności takie jak migawki, które pozwalają zapisać aktualny stan maszyny wirtualnej oraz możliwość klonowania lub kopiowania istniejącej maszyny wirtualnej.

Istnieje wiele alternatyw dla VMware, takich jak Parallels, Microsoft Virtual PC, Microsoft Hyper-V i Xen. Różnią się one m.in. obsługiwanymi systemami operacyjnymi hosta i gościa. W tej książce będziemy się skupiać na wykorzystaniu VMware do wirtualizacji, ale jeśli wolisz inne narzędzie do tego celu, to i tak powinieneś znaleźć w tej dyskusji coś ciekawego dla siebie.

Tworzenie maszyny do analizy malware

Zanim będzie można użyć maszyny wirtualnej do analizy malware, należy ją oczywiście najpierw utworzyć. Ta książka nie dotyczy przede wszystkim wirtualizacji, nie będziemy zatem się zajmować wszystkimi szczegółami. Po przedstawieniu dostępnych możliwości najprostszym rozwiązaniem, chyba że mamy inne wymagania, jest wybór domyślnej konfiguracji sprzętu. Rozmiar dysku twardego należy wybrać w zależności od potrzeb.

VMware inteligentnie wykorzystuje miejsce na dysku i dynamicznie zmienia rozmiar swojego dysku wirtualnego w zależności od zapotrzebowania na pamięć. Jeśli na przykład utworzymy dysk twardy o pojemności 20 GB, ale będziemy przechowywać na nim tylko 4 GB danych, VMware odpowiednio zmniejszy rozmiar wirtualnego dysku twardego. Rozmiar wirtualnego dysku wynoszący 20 GB to zazwyczaj dobry początek. Ta ilość powinna wystarczyć do przechowywania systemu operacyjnego gościa i wszelkich narzędzi potrzebnych do analizy malware. VMware dokonuje wielu wyborów za nas i w większości przypadków te wybory są trafne.

Następnie instalujemy system operacyjny i aplikacje. Większość malware i narzędzi do jego analizy działa w systemie Windows, a zatem jako wirtualny system operacyjny prawdopodobnie zainstalujemy system Windows. W chwili pisania tego tekstu Windows XP nadal jest najpopularniejszym systemem operacyjnym (co zaskakujące) i celem większości złośliwych programów. Nasze poszukiwania skoncentrujemy na Windows XP.

Po zainstalowaniu systemu operacyjnego możemy zainstalować dowolne wymagane aplikacje. Zawsze możemy zainstalować je później, ale zwykle łatwiej jest skonfigurować wszystko naraz. Dodatek B zawiera listę przydatnych aplikacji do analizy malware.

Następnie instalujemy VMware Tools. Aby rozpocząć instalację, z menu VMware wybieramy VM Install VMware Tools. VMware Tools poprawiają komfort użytkowania, zwiększając szybkość reakcji myszy i klawiatury. Umożliwia także dostęp do folderów współdzielonych, przesyłanie plików metodą przeciągnij i upuść oraz różne inne przydatne własności, które omówimy w tym rozdziale.

Po zainstalowaniu VMware czas na konfigurację.

Konfigurowanie VMware

Większość malware zawiera funkcjonalności sieciowe. Na przykład robak przeprowadza ataki sieciowe na inne maszyny, próbując się rozprzestrzeniać. Ale nie chcemy zezwalać robakowi na dostęp do własnej sieci, ponieważ może przenosić się on na inne maszyny.

Analizując malware, prawdopodobnie będziemy chcieli zaobserwować jego aktywność sieciową, aby pomogło to nam zrozumieć intencje autora, utworzyć sygnatury lub w pełni poznać możliwości programu. VMware oferuje kilka opcji sieciowych dla sieci wirtualnej, jak pokazano na rysunku 2.2 i omówiono w poniższych punktach.

Rysunek 2.2. Opcje konfiguracji sieci wirtualnej dla karty sieciowej

Odłączanie od sieci

Chociaż maszynę wirtualną możemy skonfigurować tak, aby nie miała łączności z siecią, zwykle odłączanie od sieci nie jest dobrym pomysłem. Może to być przydatne tylko w niektórych przypadkach. Bez podłączenia do sieci nie będziemy w stanie analizować złośliwej aktywności w sieci.

Jeśli jednak mamy powód do odłączenia sieci w VMware, możemy to zrobić albo usuwając kartę sieciową z maszyny wirtualnej, albo odłączając kartę sieciową od sieci, wybierając VM Removable Devices.

Możemy także kontrolować, czy karta sieciowa jest podłączana automatycznie po włączeniu maszyny, zaznaczając pole wyboru Connect at power on (zobacz rys. 2.2).

Konfigurowanie połączenia sieciowego tylko w obrębie maszyny hosta

Połączenie sieciowe tylko w obrębie maszyny hosta, funkcja tworząca oddzielną prywatną sieć LAN między systemem hosta a systemem gościa, jest powszechnie używana do analizy malware. Sieć LAN tylko w obrębie maszyny hosta nie jest podłączona do internetu, co oznacza, że malware jest zawarte tylko na maszynie wirtualnej, ale dopuszcza pewną aktywność sieciową.

UwagaPodczas konfigurowania maszyny hosta warto się upewnić, że zostały zainstalowane poprawki, aby chronić się na wypadek, gdyby testowane złośliwe oprogramowanie próbowało się rozprzestrzeniać. Dobrym pomysłem jest skonfigurowanie restrykcyjnej zapory sieciowej z maszyny wirtualnej do hosta, aby zapobiec rozprzestrzenianiu się złośliwego oprogramowania na host. Zapora dostarczana z systemem Windows XP z dodatkiem Service Pack 2 i nowszymi jest dobrze udokumentowana i zapewnia wystarczającą ochronę. Jednak nawet jeśli poprawki są aktualne, złośliwe oprogramowanie może próbować się rozprzestrzenić do systemu operacyjnego hosta, wykorzystując exploit typu zero-day.

Rysunek 2.3 przedstawia konfigurację sieci dla połączenia sieciowego tylko w obrębie maszyny hosta. Po włączeniu tego typu połączenia VMware tworzy wirtualną kartę sieciową na hoście i maszynach wirtualnych oraz łączy je bez powiązania z fizyczną kartą sieciową hosta. Fizyczna karta sieciowa hosta jest nadal podłączona do internetu lub innej sieci zewnętrznej.

Rysunek 2.3. Połączenie sieciowe tylko w obrębie maszyny hosta w VMware

Użycie wielu maszyn wirtualnych

Ostatnia konfiguracja łączy najlepsze cechy wszystkich wariantów. Wymaga wielu maszyn wirtualnych połączonych poprzez sieć LAN, ale odłączonych od internetu i maszyny hosta, aby malware było podłączone do sieci, ale sieć nie była podłączona do niczego ważnego.

Rysunek 2.4 pokazuje niestandardową konfigurację z dwiema maszynami wirtualnymi połączonymi ze sobą. W tej konfiguracji jedna maszyna wirtualna jest skonfigurowana do analizowania złośliwego oprogramowania, a druga maszyna świadczy usługi. Te dwie maszyny wirtualne są podłączone do tego samego wirtualnego switcha VMNet. W tym przypadku komputer hosta jest nadal podłączony do sieci zewnętrznej, ale nie do maszyny ze złośliwym oprogramowaniem.

W przypadku korzystania do analizy z więcej niż jednej maszyny wirtualnej przydatne będzie połączenie tych maszyn jako zespołu maszyn wirtualnych. Gdy nasze maszyny są połączone w ramach zespołu maszyn wirtualnych, możemy wspólnie zarządzać ich ustawieniami sieciowymi i zasilaniem. Aby utworzyć nowy zespół maszyn wirtualnych, należy wybrać File New Team.

Korzystanie z maszyny do analizy malware

Aby w jak największym stopniu poznać funkcjonalność swojego malware, musimy zasymulować wszystkie usługi sieciowe, na których jest ono oparte. Na przykład malware często łączy się z serwerem HTTP, aby pobrać dodatkowe złośliwe oprogramowanie. Aby zaobserwować tę aktywność, musimy umożliwić malware dostęp do serwera DNS (Domain Name System) w celu rozwiązania adresu IP serwera, a także serwera HTTP, który będzie odpowiadał na żądania. W opisanej niestandardowej konfiguracji sieci, na maszynie świadczącej usługi powinny być uruchomione usługi, z którymi komunikuje się malware. (W następnym rozdziale omówimy różne narzędzia przydatne do symulacji usług sieciowych).

Podłączanie malware do internetu

Czasami, mimo oczywistych zagrożeń, będziemy chcieli podłączyć do internetu swoją maszynę z uruchomionym malware, aby zapewnić bardziej realistyczne środowisko do analizy. Największe ryzyko polega oczywiście na tym, że komputer będzie wykonywać złośliwe działania, takie jak rozprzestrzenianie złośliwego oprogramowania na inne hosty, stając się węzłem w rozproszonym ataku typu "odmowa dostępu" (DDoS) lub po prostu będzie spamował. Innym ryzykiem jest to, że twórca malware może zauważyć, że łączymy się z serwerem złośliwego oprogramowania i próbujemy je analizować.

Nigdy nie należy umożliwiać malware dostępu do internetu, bez uprzedniej analizy, co może ono zrobić po podłączeniu. Dostęp możemy umożliwić tylko wtedy, gdy wiemy, że nie ma ryzyka.

Najczęstszym sposobem połączenia maszyny wirtualnej z internetem za pomocą VMware jest użycie mostkowanej karty sieciowej, która umożliwia podłączenie maszyny wirtualnej do tego samego interfejsu sieciowego co maszyna fizyczna. Innym sposobem połączenia malware działającego na maszynie wirtualnej z internetem jest użycie trybu translacji adresów sieciowych (NAT) VMware.

Tryb NAT współdzieli połączenia IP hosta z internetem. Host działa jak router i tłumaczy wszystkie żądania z maszyny wirtualnej, tak jakby pochodziły z adresu IP hosta. Ten tryb jest przydatny, gdy host jest podłączony do sieci, ale konfiguracja sieci utrudnia, a nawet uniemożliwia podłączenie adaptera maszyny wirtualnej do tej samej sieci.

Jeśli na przykład host używa adaptera bezprzewodowego, trybu NAT można łatwo użyć do połączenia maszyny wirtualnej z siecią, nawet jeśli sieć bezprzewodowa ma włączony Wi-Fi Protected Access (WPA) lub Wired Equivalent Privacy (WEP). Lub, jeśli adapter hosta jest podłączony do sieci, która zezwala na łączenie się tylko niektórych kart sieciowych, tryb NAT pozwala maszynie wirtualnej połączyć się poprzez host, omijając w ten sposób ustawienia kontroli dostępu do sieci.

Podłączanie i odłączanie urządzeń peryferyjnych

Urządzenia peryferyjne, takie jak dyski CD-ROM i zewnętrzne dyski USB, stanowią szczególny problem dla maszyn wirtualnych. Większość urządzeń można podłączyć do maszyny fizycznej lub wirtualnej, ale nie do obu.

Interfejs VMware umożliwia podłączanie i odłączanie urządzeń zewnętrznych do maszyn wirtualnych. Jeśli podłączymy urządzenie USB, gdy aktywne jest okno maszyny wirtualnej, VMware podłączy urządzenie USB do gościa, a nie do hosta, co może być niepożądane, biorąc pod uwagę rosnącą popularność robaków rozprzestrzeniających się za pośrednictwem pamięci USB. Aby zmodyfikować to ustawienie, należy wybrać VM Settings USB Controller i usunąć zaznaczenie pola wyboru Automatically connect new USB devices, aby uniemożliwić podłączenie urządzeń USB do maszyny wirtualnej.

Wykonywanie migawek

Wykonywanie migawek to koncepcja unikalna dla maszyn wirtualnych. VMware'owe migawki maszyny wirtualnej pozwalają zapisać bieżący stan komputera i wrócić do tego punktu później, podobnie jak w przypadku punkt przywracania systemu Windows.

Oś czasu na rysunku 2.5 ilustruje działanie migawek. O 8:00 robimy migawkę maszyny. Zaraz po tym uruchamiamy próbkę malware. O godzinie 10:00 następuje powrót do migawki. System operacyjny, oprogramowanie i inne komponenty urządzenia wracają do tego samego stanu, w jakim były o 8:00, a wszystko, co wydarzyło się między 8:00 a 10:00 jest usuwane tak, jakby nigdy się nie zdarzyło. Jak widać, wykonywanie migawek to niezwykle potężne narzędzie. To jest jak wbudowana funkcja cofnij, która oszczędza kłopotów z koniecznością ponownej instalacji systemu operacyjnego.

Rysunek 2.5. Oś czasu migawki

Po zainstalowaniu systemu operacyjnego i narzędzia do analizy malware oraz skonfigurowaniu sieci wykonujemy migawkę. Użyjemy tej migawki jako naszej bazowej migawki. Następnie uruchamiamy malware, wykonujemy analizę, a potem zapisujemy dane i wracamy do bazowej migawki, dzięki czemu wszystko możemy powtórzyć.

Ale co, jeśli jesteśmy w trakcie analizy malware i chcemy zrobić coś innego z maszyną wirtualną bez usuwania wszystkiego tego, co zostało zrobione? Menedżer migawek VMware umożliwia powrót do dowolnej migawki w dowolnym momencie, bez względu na to, jakie dodatkowe migawki zostały wykonane od tego czasu lub co się stało z komputerem. Ponadto możemy rozgałęziać swoje migawki, tak aby podążały różnymi ścieżkami. Spójrzmy na następujący przykładowy przepływ działań:

1. Analizując próbkę 1 malware, jesteśmy sfrustrowani i chcemy spróbować innej próbki.

2. Wykonujemy migawkę analizy próbki 1 malware.

3. Wracamy do obrazu podstawowego.

4. Zaczynamy analizować próbkę 2 malware.

5. Wykonujemy migawkę, aby zrobić sobie przerwę.

Po powrocie do maszyny wirtualnej możemy uzyskać dostęp do dowolnej migawki w dowolnym momencie, jak pokazano na rysunku 2.6. Dwa stany komputera są całkowicie niezależne i można zapisać tyle migawek, ile jest miejsca na dysku.

Rysunek 2.6. Snapshot Manager w VMware

Przesyłanie plików z maszyny wirtualnej

Wadą korzystania z migawek jest to, że wszelkie prace na maszynie wirtualnej są tracone po przywróceniu wcześniejszej migawki. Możemy jednak zapisać swoją pracę przed załadowaniem wcześniejszej migawki, przesyłając dowolne pliki, które chcemy zachować, do systemu operacyjnego hosta za pomocą funkcji przeciągnij-i-upuść VMware. Tak długo, jak VMware Tools jest zainstalowany w systemie operacyjnym gościa i obydwa systemy operacyjne to Windows, powinniśmy mieć możliwość przeciągnięcia i upuszczenia pliku bezpośrednio z systemu gościa do systemu hosta. To najprostszy i najłatwiejszy sposób przesyłania plików.

Innym sposobem przesyłania danych w VMware jest użycie udostępnionych folderów. Udostępniony folder jest dostępny zarówno z poziomu systemu operacyjnego hosta, jak i gościa, podobnie jak udostępniony folder w Windows.

Ryzyka związane z wykorzystaniem VMware do analizy malware

Niektóre malware może wykryć, że działa na maszynie wirtualnej, gdyż istnieje wiele technik umożliwiających stwierdzenie takiej sytuacji. VMware nie traktuje tego jako luki w swoich zabezpieczeniach i nie podejmuje wyraźnych kroków w celu uniknięcia wykrycia. Niektóre malware będzie działać inaczej podczas uruchamiania na maszynie wirtualnej, co może utrudnić życie jego analitykom. (W rozdz. 17 bardziej szczegółowo omówimy techniki związane z wykrywaniem VMware).

Podobnie jak wszystkie programy, także VMware czasami ma luki w zabezpieczeniach. Mogą one zostać wykorzystane, powodując awarię systemu operacyjnego hosta lub nawet spowodować uruchomienie kodu w systemie operacyjnym hosta. Chociaż istnieje tylko kilka publicznych narzędzi lub dobrze udokumentowanych sposobów wykorzystywania błędów w VMware, to znalezione luki dotyczą zabezpieczeń folderów współdzielonych, stworzono także narzędzia wykorzystujące błędy w funkcji przeciągnij-i-upuść. Warto się upewnić, że nasza wersja VMware jest w pełni załatana.

Oczywiście, nawet po podjęciu wszelkich możliwych środków ostrożności, podczas analizy złośliwego oprogramowania zawsze występuje pewne ryzyko. Cokolwiek robimy, nawet jeśli uruchamiamy analizę na maszynie wirtualnej, powinniśmy unikać przeprowadzania analizy złośliwego oprogramowania na krytycznej lub wrażliwej maszynie.

Nagrywanie/odtwarzanie - komputer na biegu wstecznym

Jedną z ciekawszych funkcji VMware jest nagrywanie/odtwarzanie. Ta funkcja w VMware Workstation rejestruje wszystko, co się dzieje, aby można było to później odtworzyć. Nagranie oferuje 100-procentową wierność; każda instrukcja wykonana podczas oryginalnego nagrania jest wykonywana podczas powtórki. Jeśli nawet nagranie zawiera bardzo nietypową sytuację przytrafiającą się raz na milion, której nie można zreplikować, zostanie ona uwzględniona w powtórce.

VMware oferuje również możliwość nagrania filmu, która rejestruje tylko wyjście wideo, natomiast nagrywanie/odtwarzanie faktycznie wykonuje instrukcje procesora systemu operacyjnego i programów. I w przeciwieństwie do filmu, możemy przerwać wykonywanie w dowolnym momencie w celu interakcji z komputerem i wprowadzenia zmian na maszynie wirtualnej. Jeśli na przykład popełnimy błąd w programie, który nie ma funkcji cofania, możemy przywrócić maszynę wirtualną do stanu sprzed tego błędu, aby zrobić coś innego.

Wraz z wprowadzaniem kolejnych narzędzi w tej książce, sprawdzimy wiele bardziej zaawansowanych sposobów korzystania z nagrywania/odtwarzania. Powrócimy do tej funkcjonalności w rozdziale 8.

Podsumowanie

Uruchamianie i analizowanie malware przy użyciu VMware i maszyn wirtualnych wymaga następujących kroków:

1. Rozpoczęcia od czystej migawki bez uruchomionego złośliwego oprogramowania.

2. Przeniesienia malware na maszynę wirtualną.

3. Przeprowadzenia analizy na maszynie wirtualnej.

4. Zebrania uwag, zrzutów ekranu oraz danych z maszyny wirtualnej i przeniesienia ich na maszynę fizyczną.

5. Przywrócenia na maszynie wirtualnej czystej migawki.

Ponieważ powstają nowe narzędzia do analizy malware, a istniejące są aktualizowane, konieczne będzie aktualizowanie czystego obrazu bazowego. Wystarczy zainstalować narzędzia i aktualizacje, a następnie zrobić nową, czystą migawkę.

Aby przeanalizować malware, zwykle musimy je uruchomić, aby móc zaobserwować jego zachowanie. Podczas jego uruchamiania należy uważać, aby nie zainfekować komputera lub sieci. VMware pozwala uruchamiać złośliwe oprogramowanie w bezpiecznym, kontrolowanym środowisku i zapewnia narzędzia potrzebne do usunięcia malware po zakończeniu analizy.

W tej książce, gdy omawiamy uruchamianie złośliwego oprogramowania, zakładamy, że odbywa się to na maszynie wirtualnej.

O autorach

Michael Sikorski jest konsultantem ds. bezpieczeństwa komputerowego w firmie Mandiant. Zajmuje się inżynierią odwrotną w zakresie złośliwego oprogramowania na potrzeby dochodzeń związanych z pojawiającymi się incydentami oraz zajmuje się badaniami i tworzeniem specjalistycznych rozwiązań w zakresie bezpieczeństwa dla klientów firmy. Mike stworzył wiele kursów z zakresu analizy złośliwego oprogramowania i prowadzi je dla różnych odbiorców, w tym FBI i Black Hat. Do Mandiant przeniósł się z MIT Lincoln Laboratory, gdzie prowadził badania w zakresie pasywnego mapowania sieci i testów penetracyjnych. Mike jest również absolwentem trzyletniego System and Network Interdisciplinary Program (SNIP) w NSA. Będąc w NSA, miał znaczący udział w badaniach w zakresie technik inżynierii odwrotnej i otrzymał wiele nagród za kreatywność w dziedzinie analizy sieci.

Andrew Honig jest ekspertem w zakresie bezpieczeństwa informacji w Departamencie Obrony. Prowadzi kursy z zakresu analizy oprogramowania, inżynierii odwrotnej i programowania w systemie Windows w National Cryptologic School oraz posiada certyfikat Certified Information Systems Security Professional (CISSP). Andy'emu jest powszechnie przypisywanych kilka zero-day exploitów w produktach wirtualizacyjnych VMware. Opracował on także narzędzia do wykrywania nowatorskiego złośliwego oprogramowania, w tym dotyczącego jądra. Jest ekspertem w analizie i poznawaniu zarówno złośliwego, jak i normalnego oprogramowania, ma również ponad 10-letnie doświadczenie jako analityk w branży bezpieczeństwa komputerowego.

O recenzencie technicznym

Stephen Lawler jest założycielem i prezesem małej firmy konsultingowej zajmującej się oprogramowaniem i bezpieczeństwem. Stephen od ponad 7 lat aktywnie działa w zakresie bezpieczeństwa informacji, przede wszystkim w inżynierii odwrotnej, analizie złośliwego oprogramowania i badaniach podatności na zagrożenia. Był członkiem Malware Analysis Team w firmie Mandiant oraz pomagał w głośnych włamaniach komputerowych mających wpływ na kilka firm z listy Fortune 100. Wcześniej pracował w dziale Security and Mission Assurance (SMA) firmy ManTech International, gdzie w ramach ciągłych działań związanych z zapewnieniem bezpieczeństwa oprogramowania wykrył liczne luki zero-day i oraz techniki badania podatności na błędy. Wcześniej, gdy nie miał nic wspólnego z bezpieczeństwem komputerowym, był głównym programistą komponentu symulatora sonaru w programie SMMTT US Navy.

O współpracujących autorach

Nick Harbour jest analitykiem malware w Mandiant i doświadczonym weteranem branży inżynierii odwrotnej. Swoją 13-letnią karierę w dziedzinie bezpieczeństwa informacji rozpoczął jako ekspert w dziedzinie kryminalistyki komputerowej i badacz w Department of Defense Computer Forensics Laboratory. Przez ostatnie 6 lat Nick pracował w Mandiant i koncentrował się głównie na analizie malware. Jest badaczem w dziedzinie technik inżynierii odwrotnej oraz napisał kilka programów pakujących i narzędzi do zaciemniania kodu, w tym PE-Scrambler. Kilkakrotnie podczas Black Hat i Defcon prezentował tematy dotyczące przeciwdziałania technikom inżynierii odwrotnej i śledczej. Jest głównym programistą i wykładowcą kursu Black Hat Advanced Malware Analysis.

Lindsey Lack jest dyrektorem technicznym w Mandiant z ponad 12-letnim doświadczeniem w zakresie bezpieczeństwa informacji; specjalizuje się w inżynierii odwrotnej malware, ochronie sieci i działaniach związanych z bezpieczeństwem. Pomogła utworzyć i uruchomić Security Operations Center, prowadziła badania w zakresie ochrony sieci oraz opracowała rozwiązania związane z zabezpieczaniem usług hostingowych. Wcześniej pracowała w National Information Assurance Research Laboratory, Executive Office of the President (EOP), Cable and Wireless oraz w armii amerykańskiej. Oprócz tytułu licencjata z informatyki na Uniwersytecie Stanforda, w Naval Postgraduate School Lindsey otrzymała również tytuł magistra informatyki w zakresie bezpieczeństwa informacji.

Jerrold "Jay" Smith jest głównym konsultantem w Mandiant, gdzie specjalizuje się w inżynierii odwrotnej malware i analizach kryminalistycznych. W tej roli brał udział w wielu reakcjach na incydenty, pomagając wielu klientom firm z listy Fortune 500. Przed dołączeniem do Mandiant Jay pracował w NSA, ale nie wolno mu na ten temat mówić. Jay uzyskał tytuł licencjata w dziedzinie elektrotechniki i informatyki na Uniwersytecie Kalifornijskim w Berkeley oraz tytuł magistra w dziedzinie informatyki na Johns Hopkins University.

Przedmowa

Niewiele dziedzin bezpieczeństwa cyfrowego wydaje się być równie asymetrycznych, co te dotyczące złośliwego oprogramowania, narzędzi ochrony i systemów operacyjnych.

Latem 2011 roku uczestniczyłem w prezentacji Peitera (Mudge) Zatko podczas Black Hat w Las Vegas w stanie Nevada. Podczas swojego przemówienia Mudge przedstawił asymetryczny charakter nowoczesnego oprogramowania. Wyjaśnił, w jaki sposób przeanalizował 9000 plików binarnych malware oraz wyznaczył średnią wynoszącą 125 linii kodu (LOC) dla swojego zestawu próbek.

Można byłoby stwierdzić, że próbki Mudge zawierały tylko "prosty" lub "prymitywny" malware. Można byłoby spytać - a co z czymś naprawdę "uzbrojonym"? Czymś w stylu (wstrzymaj oddech) - Stuxnet? Według Larry'ego L. Constantine'a1 Stuxnet zawierał około 15 000 LOC, a zatem był 120 razy większy niż próbka złośliwego oprogramowania o średniej wartości 125 LOC. Stuxnet był wysoce wyspecjalizowany i ukierunkowany, prawdopodobnie ze względu na swój ponadprzeciętny rozmiar.

Opuszczając na chwilę świat malware'u, edytor tekstowy, którego używam (gedit, edytor tekstowy GNOME), zawiera gedit.c z 295 LOC, gedit.c zaś jest tylko jednym ze 128 plików źródłowych (wraz z 3 dodatkowymi katalogami) opublikowanym w git-owym repozytorium kodu źródłowego dla gedit2. Zsumowanie wszystkich 128 plików i 3 katalogów daje 70 484 LOC. Stosunek LOC nieszkodliwych aplikacji do malware'u wynosi ponad 500 do 1. W porównaniu z dość prostym narzędziem, takim jak edytor tekstu, typowa próbka złośliwego oprogramowania wydaje się bardzo wydajna!

Wartość 125 LOC podana przez Mudge'a wydawała mi się dość niska, ponieważ istnieją różne definicje "złośliwego oprogramowania". Wiele złośliwych aplikacji istnieje jako "pakiety" z wieloma funkcjami i elementami infrastruktury. Aby ocenić tego rodzaju złośliwe oprogramowanie, policzyłem to, co można zasadnie uznać za elementy "źródłowe" trojana Zeus (.cpp, .obj, .h itp.) i uzyskałem 253 774 LOC. Porównując program taki jak Zeus z typową próbką Mudge'a, mamy stosunek ponad 2000 do 1.

Mudge następnie porównał LOC złośliwego oprogramowania z wartością wyznaczoną dla produktów przeznaczonych do przechwytywania i eliminowania złośliwego oprogramowania. Jako swoje oszacowanie dla nowoczesnych produktów obronnych podał wartość 10 milionów LOC. Aby uprościć matematykę, wyobraźmy sobie, że istniejące produkty zawierają co najmniej 12,5 milionów linii kodu, ustanawiając stosunek ofensywnego LOC do defensywnego LOC na poziomie 100 000 do 1. Innymi słowy, na 1 "ofensywną" linię kodu obrońcy piszą 100 000 LOC służących obronie.

Mudge porównał także LOC szkodliwego oprogramowania z systemami operacyjnymi, dla których szkodliwe oprogramowanie zostałe utworzone w celu ich ataku. Analitycy szacują, że Windows XP został zbudowany z 45 milionów LOC, natomiast nikt nie wie, z ilu linii kodu jest zbudowany Windows 7. Mudge podał 150 milionów jako wartość dla współczesnych systemów operacyjnych, przypuszczalnie myśląc o najnowszych wersjach Windowsa. Aby uprościć matematykę, zredukujmy to do 125 milionów, przez co będziemy mieli stosunek 1 milion do 1 określający rozmiar docelowego systemu operacyjnego do wielkości złośliwego oręża stworzonego do atakowania go.

Zatrzymajmy się, aby podsumować wyniki, które uzyskaliśmy, licząc LOC:

120:1 Stuxnet w stosunku do typowego malware

500:1 prosty edytor tekstu w stosunku do typowego malware

2000:1 pakiet malware w stosunku do typowego malware

100 000:1 narzędzie ochrony w stosunku do typowego malware

1 000 000:1 docelowy system operacyjny w stosunku do typowego malware

Z punktu widzenia obrońcy, stosunek wielkości narzędzi do obrony i docelowych systemów operacyjnych do typowych przykładów złośliwego oprogramowania wypada blado. Nawet przyjęcie pakietu malware jako typowej wielkości próbki nie wydaje się zbytnio poprawiać sytuacji obrońcy! Wygląda na to, że narzędzia do obrony (i ich sprzedawcy) poświęcają dużo wysiłku na wyprodukowanie tysięcy LOC, ale tylko po to, by mogli obejść ich sprytni, zwinni intruzi, którzy mają znacznie mniej LOC.

Co ma zrobić obrońca? Odpowiedzią jest wzięcie przykładu z tych, którzy mają przewagę nad przeciwnikiem - potraktujmy "przeszkodę" jako "okazję"! Zapomnijmy o rozmiarach narzędzi służących do obrony i systemów operacyjnych - niewiele można na to poradzić. Cieszmy się faktem, że próbki złośliwego oprogramowania są tak (relatywnie) małe, jakie są w rzeczywistości.

Wyobraźmy sobie, że próbujemy zrozumieć na poziomie kodu źródłowego zawierającego 12,5 miliona LOC, jak działa narzędzie przeznaczone do obrony. To trudne zadanie, chociaż niektórzy badacze zajmują się tego typu projektami. Jednym z niesamowitych przykładów jest artykuł "Sophail: A Critical Analysis of Sophos Antivirus" autorstwa Tavisa Ormandy'ego3, zaprezentowany podczas Black Hat w Las Vegas w 2011 roku. Tego rodzaju analiza jest jednak wyjątkiem, a nie regułą.

Zamiast martwić się milionami LOC (albo setkami lub dziesiątkami tysięcy), przenieśmy się do obszaru zawierającego tysiąc lub mniej - czyli miejsca, w którym można znaleźć znaczną część światowego malware. Naszym głównym celem jako obrońcy przed malware jest określenie, co ono robi, jak objawia się w naszym środowisku i co z tym zrobić. Kiedy mamy do czynienia z próbkami o rozsądnych rozmiarach i odpowiednimi umiejętnościami, mamy szansę odpowiedzieć na te pytania i tym samym zmniejszyć ryzyko dla swojej firmy.

Jeśli autorzy malware są gotowi tworzyć złośliwe oprogramowanie, to autorzy książki, którą czytacie, są tu po to, aby dostarczyć umiejętności. Praktyczne analizowanie malware to książka, którą moim zdaniem każdy analityk złośliwego oprogramowania powinien mieć pod ręką. Jeśli jesteś początkujący, to warto, żebyś zapoznał się z wprowadzającym, praktycznym materiałem, którego potrzebujesz, aby wziąć udział w walce. Jeśli jesteś średniozaawansowanym praktykiem, to zabierze cię ona do następnego poziomu. Jeśli jesteś zaawansowanym inżynierem, to znajdziesz tu perełki, które popchną cię jeszcze wyżej - i dzięki temu będziesz mógł powiedzieć: "proszę, przeczytaj ten świetny podręcznik", gdy otrzymasz pytania od tych, dla których jesteś mentorem.

Praktyczne analizowanie malware to tak naprawdę dwie książki w jednej - pierwsza zawiera tekst pokazujący czytelnikom, jak analizować współczesne złośliwe oprogramowanie. Moglibyście kupić książkę tylko z tego powodu, a i tak wiele byście skorzystali z jej porad. Jednak autorzy postanowili pójść o krok dalej i napisać drugą książkę - ten dodatkowy tom można by nazwać Analiza malware w zastosowaniach i składa się on z ćwiczeń, krótkich odpowiedzi i szczegółowych rozważań przedstawionych na końcu każdego rozdziału oraz w załączniku C. Autorzy napisali również całe złośliwe oprogramowanie, którego używają jako przykładów, po to, aby zapewnić bogate, ale bezpieczne środowisko do nauki.

Dlatego zamiast rozpaczać nad widocznymi asymetriami, przed którymi stoją cyfrowi obrońcy, cieszmy się, że złośliwe oprogramowanie ma taką postać, jaką obecnie ma. Uzbrojeni w książkę taką jak Praktyczne analizowanie malware, będziemy mieć przewagę, której potrzebujemy, aby lepiej wykrywać włamania do naszej firmy lub firmy naszych klientów i odpowiednio na nie reagować. Autorzy są ekspertami w swoich królestwach, porady zaś pochodzą z pierwszej linii frontu, nie z teorii z odosobnionego laboratorium badawczego. Życzymy miłej lektury i pamiętajcie, że każdy fragment złośliwego oprogramowania, które poddajecie inżynierii odwrotnej i analizie, zwiększa koszty przeciwnika, wystawiając jego mroczne sztuczki na światło wiedzy.

Richard Bejtlich (@taosecurity)

Chief Security Officer w Mandiant oraz założyciel TaoSecurity

Manassas Park, Virginia

2 stycznia 2012 roku

Wprowadzenie

Dzwoni telefon i koleś od sieci mówi, że cię zhakowano i że poufne informacje twoich klientów zostały skradzione z twojej sieci. Śledztwo zaczynasz od sprawdzenia dzienników w celu zidentyfikowania zaatakowanych hostów. Skanujesz maszyny za pomocą antywirusa w celu znalezienia złośliwego programu i masz łut szczęścia, gdy zostaje wykryty koń

trojański o nazwie TROJ.snapAK. Kasujesz ten plik w celu rozwiązania problemu i korzystając z zapisu ruchu sieciowego, tworzysz sygnaturę w systemie wykrywania włamań (Intrusion Detection System, IDS) w celu upewnienia się, że żadne inne maszyny nie zostaną zainfekowane. Następnie łatasz dziurę, przez którą atakujący się włamali, aby się upewnić, że to się więcej nie powtórzy.

Kilka dni później goście od sieci wracają z informacją, że z twojej sieci znowu są kradzione poufne dane. Wygląda to na taki sam atak, ale nie masz pojęcia, co robić. Najwyraźniej twoja sygnatura IDS nie działa jak należy, ponieważ zainfekowanych jest więcej komputerów, a twoje oprogramowanie antywirusowe nie zapewnia wystarczającej ochrony, aby odizolować zagrożenie. Teraz kierownictwo wyższego szczebla domaga się wyjaśnienia, co się stało, a wszystko, co możesz im powiedzieć o złośliwym oprogramowaniu, to to, że jest to TROJ.snapAK. Nie znasz odpowiedzi na najważniejsze pytania i wygląda to trochę kiepsko.

Jak dokładnie określić, co robi TROJ.snapAK, dzięki czemu będzie można wyeliminować zagrożenie? Jak wygenerować bardziej efektywną sygnaturę sieciową? Jak się dowiedzieć, czy tym złośliwym oprogramowaniem zainfekowane są inne maszyny? Jak się upewnić, że udało się usunąć cały pakiet złośliwego oprogramowania, a nie tylko jedną jego część? W jaki sposób można odpowiedzieć na pytania kierownictwa dotyczące działania tego złośliwego programu?

Wszystko, co możesz zrobić, to powiedzieć szefowi, że musi zatrudnić drogich zewnętrznych konsultantów, ponieważ nie jesteś w stanie chronić swojej sieci. To nie jest jednak najlepszy sposób na zapewnienie sobie utrzymania stanowiska.

Ach, ale na szczęście wykazałeś się wystarczającą inteligencją, aby zdobyć egzemplarz Praktycznego analizowania malware. Umiejętności, których nabędziesz dzięki tej książce, nauczą cię odpowiadać na te trudne pytania i pokażą, jak chronić sieć przed złośliwym oprogramowaniem.

Czym jest analiza malware?

Złośliwe oprogramowanie, zwane także malware, odgrywa rolę w większości włamań do komputerów i incydentów związanych z bezpieczeństwem. Każde oprogramowanie, które wyrządza szkodę użytkownikowi, komputerowi lub sieci, może zostać uznane za złośliwe oprogramowanie. Należą do niego wirusy, konie trojańskie, robaki, rootkity, scareware i spyware. Podczas gdy różne inkarnacje szkodliwego oprogramowania wykonują różne szkodliwe działania (jak zobaczymy w tej książce), to my - analitycy złośliwego oprogramowania - dysponujemy pewnym podstawowym zestawem narzędzi i technik do jego analizy.

Analiza malware jest sztuką badania złośliwego oprogramowania w celu zrozumienia, jak ono działa, jak je zidentyfikować oraz jak je pokonać lub wyeliminować. I nie musimy być hakerami, aby tego dokonać.

Biorąc pod uwagę, że istnieją miliony złośliwych programów, a każdego dnia ich przybywa, analiza malware ma kluczowe znaczenie dla każdego, kto reaguje na incydenty związane z bezpieczeństwem komputerowym. A przy braku specjalistów zajmujących się analizą malware na wykwalifikowanych analityków złośliwego oprogramowania istnieje duże zapotrzebowanie.

Nie jest to książka o tym, jak znaleźć złośliwe oprogramowanie. Koncentrujemy się na analizie malware po jego wykryciu. Będziemy skupiać się na złośliwym oprogramowaniu działającym w systemie operacyjnym Windows - zdecydowanie najbardziej popularnym systemie operacyjnym, który jest obecnie używany - ale zdobyte umiejętności przydadzą się także podczas analizy złośliwego oprogramowania w dowolnym systemie operacyjnym. Będziemy się koncentrować na plikach wykonywalnych, ponieważ to one najczęściej występują i są najtrudniejszymi plikami, jakie można napotkać. Jednocześnie postanowiliśmy uniknąć omawiania złośliwych skryptów i programów w Javie. Zamiast tego zagłębimy się w metody stosowane do analizy zaawansowanych zagrożeń, takich jak backdoory, ukryte malware i rootkity.

Wymagania wstępne

Bez względu na twoją znajomość lub doświadczenie w analizie malware, w tej książce znajdziesz coś pożytecznego dla siebie.

W rozdziałach od 1 do 3 zostaną omówione podstawowe techniki analizy złośliwego oprogramowania, które nawet osoby bez doświadczenia w zakresie bezpieczeństwa lub w programowaniu będą w stanie wykorzystać do oceny malware. Rozdziały od 4 do 14 zawierają bardziej zaawansowany materiał, który uzbroi cię w najważniejsze narzędzia i umiejętności potrzebne do analizy większości złośliwych programów. Te rozdziały wymagają pewnej wiedzy na temat programowania. Najbardziej zaawansowany materiał z rozdziałów od 15 do 19 będzie przydatny nawet dla doświadczonych analityków malware, ponieważ obejmuje strategie i techniki analizy również najbardziej wyrafinowanych złośliwych programów, takich jak te wykorzystujące techniki zapobiegania deasemblacji i debugowania czy techniki pakowania.

Ta książka cię nauczy, jak i kiedy korzystać z różnych technik analizy malware. Zrozumienie, kiedy zastosować określoną technikę, może być równie ważne jak jej znajomość, ponieważ użycie niewłaściwej techniki w niewłaściwej sytuacji może być frustrującą stratą czasu. Nie będziemy zajmować się każdym narzędziem, ponieważ zmieniają się one przez cały czas, najważniejsze zaś są podstawowe umiejętności. Ponadto w całej książce będziemy wykorzystywać realistyczne próbki złośliwego oprogramowania (które można pobrać ze strony http://www.practicalmalwareanalysis.com/ lub http://www.nostarch.com/malware.htm), aby pokazać ci różne rzeczy, które będziesz mógł spotkać podczas analizy złośliwego oprogramowania.

Nauka w praktyce

Nasze bogate doświadczenie w prowadzeniu profesjonalnych zajęć z inżynierii odwrotnej i analizy złośliwego oprogramowania nauczyło nas, że uczniowie najlepiej się uczą, gdy ćwiczą zdobywane umiejętności. Przekonaliśmy się, że jakość ćwiczeń laboratoryjnych jest równie ważna jak jakość wykładu i bez tego komponentu prawie niemożliwe jest nauczenie się analizowania złośliwego oprogramowania.

W tym celu ćwiczenia laboratoryjne podane na końcu większości rozdziałów pozwalają rozwijać umiejętności nabyte w danym rozdziale. Te ćwiczenia rzucą ci wyzwanie z użyciem realistycznego malware zaprojektowanego w celu zademonstrowania najczęstszych rodzajów zachowań, które napotkasz w złośliwym oprogramowaniu z rzeczywistego świata. Ćwiczenia laboratoryjne mają na celu rozwinięcie koncepcji przedstawionych w danym rozdziale, bez przytłaczania cię niepowiązanymi informacjami. Każde laboratorium zawiera jeden lub więcej złośliwych plików (które można pobrać ze stron http://www.practicalmalwareanalysis.com/ lub http://www.nostarch.com/malware.htm), kilka pytań, które poprowadzą cię przez laboratorium, krótkie odpowiedzi na pytania oraz szczegółową analizę malware'u.

Ćwiczenia laboratoryjne mają symulować realistyczne scenariusze analizy złośliwego oprogramowania. Jako takie zawierają generyczne nazwy lików, które nie zawierają sugestii co do funkcjonalności złośliwego oprogramowania. Podobnie jak w przypadku prawdziwego złośliwego oprogramowania, zaczniemy od braku informacji i będziemy musieli użyć nabytych tu umiejętności, aby zebrać wskazówki i dowiedzieć się, co robi dane malware.

Czas wymagany na każde laboratorium będzie zależeć od twojego doświadczenia. Możesz spróbować ukończyć dane ćwiczenie samodzielnie lub postępować zgodnie ze szczegółową analizą, aby zobaczyć, jak w praktyce są stosowane różne techniki.

Większość rozdziałów zawiera trzy laboratoria. Pierwsze ćwiczenie laboratoryjne jest na ogół najłatwiejsze i większość czytelników powinna być w stanie je ukończyć. Drugie ćwiczenie jest umiarkowanie trudne, a większość czytelników będzie potrzebować pewnych wskazówek znajdujących się w rozwiązaniu. Trzecie laboratorium będzie trudne i tylko najbardziej biegli czytelnicy będą w stanie je ukończyć bez pomocy wskazówek znajdujących się w rozwiązaniu.

Co znajduje się w książce?

Praktyczne analizowanie malware zaczyna się od prostych metod, które można wykorzystać do uzyskania informacji od stosunkowo niewyszukanych złośliwych programów, i przechodzi do coraz bardziej skomplikowanych technik, które można wykorzystać do postępowania z nawet najbardziej wyrafinowanym malware. Oto co znajduje się w poszczególnych rozdziałach:

- rozdział 0, "Elementarz analizy malware" ustanawia ogólny proces i metodologię analizy złośliwego oprogramowania;

- rozdział 1, "Podstawowe techniki statyczne" uczy sposobów uzyskiwania informacji z pliku wykonywalnego bez jego uruchamiania;

- rozdział 2, "Analiza malware na maszynach wirtualnych" przeprowadzi cię przez proces konfigurowania maszyn wirtualnych jako bezpiecznych środowisk do uruchamiania złośliwego oprogramowania;

- rozdział 3, "Podstawowa analiza dynamiczna" uczy łatwych w użyciu, ale skutecznych technik analizy złośliwego programu poprzez jego uruchomienie;

- rozdział 4, "Kurs błyskawiczny asemblera x86" to wprowadzenie do asemblera x86, który stanowi podstawę do używania IDA Pro i przeprowadzania dogłębnej analizy złośliwego oprogramowania;

- rozdział 5, "IDA Pro" pokazuje, jak korzystać z IDA Pro - jednego z najważniejszych narzędzi do analizy malware; IDA Pro będziemy używać w pozostałej części książki;

- rozdział 6, "Rozpoznawanie w asemblerze konstrukcji języka C" zawiera przykłady kodu języka C w asemblerze i uczy, jak zrozumieć wysokopoziomową funkcjonalność kodu asemblera;

- rozdział 7, "Analizowanie malware w systemie Windows" obejmuje szeroki zakres pojęć specyficznych dla systemu Windows, niezbędnych do zrozumienia szkodliwych programów z tego systemu;

- rozdział 8, "Debugowanie" wyjaśnia podstawy debugowania oraz to, jak debuggera powinni używać analitycy złośliwego oprogramowania;

- rozdział 9, "OllyDbg" pokazuje, jak korzystać z OllyDbg - najpopularniejszego debuggera dla analityków malware;

- rozdział 10, "Debugowanie jądra za pomocą WinDbg" opisuje, jak używać debuggera WinDbg do analizowania rootkitów oraz malware działającego w jądrze;

- rozdział 11, "Zachowanie malware" opisuje popularne funkcjonalności malware i pokazuje, jak rozpoznać daną funkcjonalność podczas analizy złośliwego oprogramowania;

- rozdział 12, "Ukryte uruchamianie malware" omawia sposób analizowania szczególnie podstępnej klasy złośliwych programów, które ukrywają swoje wykonanie w innym procesie;

- rozdział 13, "Szyfrowanie danych" pokazuje, w jaki sposób złośliwe oprogramowanie może szyfrować dane, aby utrudnić identyfikację jego działań w ruchu sieciowym lub na hoście ofiary;

- rozdział 14, "Sygnatury sieciowe dotyczące malware" uczy, jak używać analizy malware do tworzenia sygnatur sieciowych, które przewyższają sygnatury utworzone tylko na podstawie przechwyconego ruchu;

- rozdział 15, "Zapobieganie deasemblacji" wyjaśnia, w jaki sposób niektórzy autorzy malware projektują swoje szkodliwe oprogramowanie tak, że trudno jest je deasemblować, oraz jak rozpoznać i pokonać te techniki;

- rozdział 16, "Zapobieganie debugowaniu" opisuje sztuczki stosowane przez twórców malware w celu utrudnienia debugowania kodu i sposoby przezwyciężania tych przeszkód;

- rozdział 17, "Zapobieganie użyciu maszyn wirtualnych" pokazuje techniki stosowane przez malware utrudniające analizę na maszynie wirtualnej oraz to, jak obejść te techniki;

- rozdział 18, "Pakowanie i rozpakowywanie" uczy, w jaki sposób złośliwe oprogramowanie wykorzystuje pakowanie, aby ukryć swój prawdziwy cel, a następnie opisuje krok po kroku podejście służące rozpakowywaniu spakowanych programów;

- rozdział 19, "Analizowanie shellcode" wyjaśnia, czym jest shellcode oraz przedstawia wskazówki i porady dotyczące analizy złośliwego shellcode;

- rozdział 20, "Analizowanie C++" pokazuje, jak zmienia się kod C++ po skompilowaniu oraz jak przeprowadzić analizę złośliwego oprogramowania utworzonego za pomocą C++;

- rozdział 21, "64-bitowe malware" wyjaśnia, dlaczego autorzy szkodliwego oprogramowania mogą tworzyć 64-bitowe malware oraz co należy wiedzieć o różnicach między wersjami x86 a x64;

- dodatek A, "Ważne funkcje systemu Windows" krótko opisuje funkcje systemu Windows powszechnie używane w złośliwym oprogramowaniu;

- dodatek B, "Narzędzia do analizy malware" zawiera listę przydatnych narzędzi dla analityków malware;

- dodatek C, "Rozwiązania ćwiczeń laboratoryjnych" zawiera rozwiązania ćwiczeń laboratoryjnych zawartych w rozdziałach w całej książce.

Naszym celem jest uzbrojenie cię w umiejętności analizowania i zwalczania wszelkiego rodzaju złośliwego oprogramowania. Jak zobaczysz, zajmiemy się wieloma problemami, natomiast za pomocą ćwiczeń laboratoryjnych rozwiniemy przedstawioną wiedzę. Po przeczytaniu tej książki zdobędziesz umiejętności analizowania dowolnego złośliwego oprogramowania, w tym prostych technik szybkiego analizowania typowego malware oraz złożonych, wyrafinowanych umiejętności do analizy nawet najbardziej enigmatycznego złośliwego oprogramowania.

Zaczynajmy!