2009.01_Analiza powłamaniowa.pdf

OBRONA

KONRAD ZUWAŁA

powłamaniowa

Stopień trudności

Wielokrotnie po wykryciu niepożądanej aktywności na

komputerze naszym celem jest wykrycie śladów aktywności

nieautoryzowanego użytkownika i zdobycie wiedzy o tym, co tak

naprawdę stało się na naszym komputerze. I właśnie temu celowi

służy analiza powłamaniowa.

wspólnego z analizą detektywistyczną.

Musimy ustalić czas, miejsca,

powiązać ze sobą wiele faktów. Często w

celu uzyskania informacji musimy zapuścić

się w najdziwniejsze miejsca systemu, nie

oszczędzając przy tym jego najgłębszych

zakamarków. Niejednokrotnie uzyskane

informacje będą szczątkowe, niedokładne,

będziemy musieli się sporo napocić w celu

ich powiązania i odnalezienia wzajemnych

zależności. Ale na tym właśnie polega

analiza powłamaniowa – na korzystaniu z

tych informacji, które uda nam się zdobyć w

skompromitowanym systemie.

Aby jednak zabrać się za analizę, należy

najpierw przygotować się teoretyczne do

podejmowanego zagadnienia. Nie zawadzi też

przygotować do tego celu system operacyjny w

odpowiedni, wymagany do podobnych czynności,

sposób.

Zakładam, że użytkownik korzysta z systemu

bazującego na jakimś Uniksie (FreeBSD,

OpenBSD, Linux, etc.), niemniej jednak część

zawartych w artykule treści jest uniwersalna

i może być odniesiona również do systemu

Windows.

Podstawową prawdą analizy

powłamaniowej jest nieszukanie niczego

szczególnego. Każdy, kto szuka czegoś

konkretnego w systemie, nie znajdzie tak

naprawdę nic. Na co bowiem zwracać uwagę?

Trudno jest na początku określić, czym

konkretnie powinniśmy się zająć. Oczywiście,

można powiedzieć, że chcemy dowiedzieć się,

kto, kiedy i w jaki sposób wtargnął do naszego

systemu operacyjnego i czego w nim dokonał.

Jednak, aby odpowiedzieć na te pytania,

musimy zgromadzić wiele różnorodnych

danych, najczęściej po drodze nie znajdując

konkretnych i wyraźnych dowodów. Będziemy

co najwyżej dysponowali strzępkami informacji,

które musimy w jakiś sposób ze sobą połączyć

i wyciągnąć z nich wnioski.

Jakie informacje są przechowywane w

naszym systemie? W większości przypadków

są to śmieci – pliki, które praktycznie nigdy nie

są używane. Na serwerach UNIX-owych tylko

niewielka część zbiorów jest systematycznie

wykorzystywana (otwierana, odczytywana).

Większość z nich nie jest potrzebna przez długi

czas, np. pliki konfiguracyjne są odczytywane

tylko w momencie uruchomienia programu, a

potem po prostu leżą one na dysku, czekając

na ponowny reboot maszyny bądź restart

programu, co sprawi, iż ich zawartość zostanie

odczytana. A jak wiemy, niektóre serwery nie są

restartowane latami.

Co z tego wynika? Nowoczesne komputery

są w stanie w kilka sekund zapełnić nawet

największe dyski twarde. Jednak procesy

systemowe odnoszą się ciągle do tych samych

danych, korzystając z plików. Gdy więc system

ciągle odczytuje i zapisuje w tych samych

Z ARTYKUŁU

DOWIESZ SIĘ

czym jest analiza

powłamaniowa,

jak się ją wykonuje,

jak działa system plików,

jak wygląda analiza

podejrzanego programu.

CO POWINIENEŚ

WIEDZIEĆ

znać podstawy administracji

systemu UNIX-owego,

znać podstawy języka C,

mieć ogólną wiedzę o

systemach komputerowych

i zasadzie ich działania.

HAKIN9 1/2009

Analiza

A naliza powłamaniowa ma wiele

ANALIZA POWŁAMANIOWA

plikach, tak naprawdę zaciera po

sobie ślady. Zarówno po sobie, jak i po

potencjalnym intruzie – zacierane są

znaczniki czasowe, ślady jakiejkolwiek

niepożądanej modyfikacji plików. Dlatego

też w analizie powłamaniowej tak

bardzo cenione są informacje niezwykłe,

odbiegające od zwyczajnych operacji

dostępu do danych plików czy też

otwarcia zbiorów, które na ogół nie są

używane.

Kolejną niezwykle istotną kwestią

jest tak zwana kolejność zmienności

informacji (ang. Order Of Volatility ).

Jak wiadomo, część informacji ulega

szybszemu zatarciu i – w konsekwencji

– zatraceniu. Najszybciej informacje

zostaną utracone z nośników

elektrycznych (takich jak rejestry

procesora, jego pamięć cache, pamięci

RAM) czy odbiorników sieciowych, takich

jak karty sieciowe – które przecież

zawierają własne bufory czy kości

pamięci. Te informacje zwykle są dla

nas niedostępne, ponieważ czas ich

życia oscyluje w granicach mikro- czy

też nanosekund. W dalszej kolejności

mamy działające procesy, których

czas życia waha się od kilku sekund

do kilku godzin (wiadomo jednak, że

informacje, na których one operują,

ulegają ciągłej wymianie – toteż szybko

tracą one na aktualności). Dyski twarde,

w zależności od typu informacji, mogą je

przechowywać od kilku sekund do kilku

miesięcy czy nawet lat. Wszystko jest

kwestią wykorzystywanej informacji –

pliki tymczasowe tworzone przez niektóre

programy mogą istnieć zaledwie parę

sekund, podczas gdy lwia część danych

zalega na dyskach w niezmienionej

postaci przez wiele miesięcy. Nośniki

zewnętrzne, takie jak dyskietki, pamięci

masowe czy płyty CD/DVD/BlueRay, są

w stanie pamiętać zapisane na nich

dane przez wiele lat.

Co z tego wynika? Otóż w pierwszej

kolejności powinno się zabezpieczyć

dane ulotne, które możemy utracić w

krótkim czasie. Postępując w ten sposób,

powinniśmy zabezpieczać informacje i ich

nośniki w odpowiedniej kolejności –

począwszy od tych ulotnych, po te, którym

nic nie zagraża.

Kolejną rzeczą, z której musimy sobie

zdać sprawę podchodząc do takiej

analizy, jest iluzja, jaką wytwarza wokół

nas system operacyjny. Cały system

plików jest tak naprawdę iluzją. Pliki są

bowiem ciągiem zer i jedynek, informacją

elektromagnetyczną zapisaną na dysku

twardym. Foldery i pliki – to wszystko

jest iluzją stworzoną przez system

operacyjny, swoistym udogodnieniem,

które powoduje, że tak łatwo używa nam

się komputera. Należy o tym pamiętać

w trakcie odzyskiwania utraconych

plików czy też analizy fragmentów

zbiorów odnalezionych gdzieś na dysku

– możemy tego dokonać z całkowitym

pominięciem systemu plików, co sprawi,

że ilość uzyskanych informacji będzie

znacznie większa.

Trzeba też zwrócić uwagę na

poziom zaufania, jaki możemy mieć

do danej informacji. O ile pojedyncza

informacja może wydawać się mało

prawdopodobną, o tyle jej powtórzenie

się w wielu różnych miejscach może ją

znacznie uwiarygodnić. Weźmy przykład:

znaleźliśmy wpis o zalogowaniu się

użytkownika w pliku z logami serwera

telnet. Jest to jedna informacja, nie

musi być ona wiarygodna. Jeśli jednak

przejrzymy plik z historią poleceń

tego użytkownika w jego powłoce i

zobaczymy, że wpisywał odpowiednie

komendy – uzyskamy dodatkowe

potwierdzenie informacji o jego

logowaniu. Jeżeli ponadto jakiś system

IDS, bądź inny sniffer działający w danej

sieci, potwierdzi, że miało miejsce takie

połączenie z hosta o adresie IP x.x.x.x

– wtedy możemy być prawie pewni, że

informacja jest prawdziwa. Jednak ciągle

nie mamy stuprocentowej pewności, jako

że sprawny atakujący mógł być w stanie

spreparować wszystkie wymienione

źródła. Mimo wszystko, im więcej źródeł

potwierdza istnienie informacji, w tym

wyższym stopniu możemy jej zaufać.

Możemy wyróżnić dwie metody

zdobywania informacji – w książce

Forensic Discovery autorstwa Dana

Farmera i Wierse'a Venema zyskały

one nazwę cyfrowej archeologii i

cyfrowej geologii. Są to oczywiście

analogie do tych dyscyplin naukowych

i ich użycia w realnym, niewirtualnym

świecie. Archeologia, jak sama nazwa

mówi, polega na badaniu tego, co jest

dziełem człowieka. Odnosząc to do

komputerów, dochodzimy do wniosku, że

musimy zbadać aktywność użytkownika

na konkretnej maszynie. Powinniśmy

zatem przeanalizować używane przez

niego pliki, uruchamiane procesy

– wszystko to, co zostało zainicjowane

z konta systemowego skojarzonego

z identyfikatorem podejrzanego.

Listing 1. Funkcja lstat() i powiązana z nią struktura

#include <sys/stat.h>

int lstat ( const char * path , struct stat * buf );

struct stat {

dev_t st_dev ; /* ID urządzenia zawierającego plik */

ino_t st_ino ; /* numer inode */

node_t st_mode ; /* ochrona */

nlink_t st_nlink ; /* ilość twardych dowiązań */

uid_t st_uid ; /* ID właściciela pliku */

gid_t st_gid ; /* ID grupy właściciela pliku */

dev_t st_rdev ; /* ID urządzenia (jeśli plik specjalny */

off_t st_size ; /* całkowity rozmiar, w bajtach */

blksize_t st_blksize ; /* rozmiar bloku systemu plików */

blkcnt_t st_blocks ; /* ilość zaalokowanych bloków*/

time_t st_atime ; /* czas ostatniego dostępu (access) */

time_t st_mtime ; /* czas ostatniej modyikacji (modiication) */

time_t st_ctime ; /* czas ostatniej zmiany (time) */

} ;

Listing 2. Budowanie obrazu partycji i kopiowanie go przez sieć

#!/bin/bash

dd if = / dev / hda1 bs = 100 k of = obraz . hda

nc - l - p 2345 > obraz . hda

1/2009

HAKIN9

OBRONA

Geologia zaś jest procesem badania

aktywności systemu operacyjnego

jako środowiska nadrzędnego nad

użytkownikiem, które jest przez niego w

pewien sposób kształtowane. Mówiąc

prościej, analizujemy wszystko to,

czego użytkownik nie uruchomił, a co

działa w systemie – dostęp do plików

konfiguracyjnych, operacje na dyskach,

informacje zgromadzone w systemie

plików, które nie są dziełem użytkownika.

Wiemy już, jak zabrać się za

analizę, musimy jeszcze odpowiednio

przygotować do niej system operacyjny.

Oczywiste jest, że potrzebujemy

odpowiedniej ilości miejsca na

dyskach twardych, aby przekopiować,

a następnie zamontować obrazy

systemu plików skompromitowanego

systemu. Niezbędne będą również

pewne narzędzia, które umożliwią nam

wykonywanie operacji na systemie

plików skompromitowanej maszyny

– czy to poprzez zamontowanie jego

obrazu na innym komputerze, czy też

na maszynie, która jest przedmiotem

naszych badań. Musimy pamiętać o

zasadzie ulotności informacji – najpierw

powinniśmy pozbierać informacje z

pamięci komputera, procesów, czyli tego

wszystkiego, czego nie jesteśmy w stanie

fizycznie skopiować na inny komputer.

Zestawem potrzebnych narzędzi jest

The Coroner's Toolkit lub też projekt, który

miał go zastąpić – The Sleuth Kit. TCT

jest projektem stworzonym przez autorów

wymienionej wcześniej książki, która

dostępna jest za darmo w Internecie.

Więcej na ten temat można znaleźć w

ramce W Sieci.

Instalacja obu zestawów

narzędziowych jest raczej intuicyjna i

każdy średnio doświadczony użytkownik

systemu UNIX-owego będzie w stanie ją

wykonać. Przystąpmy więc do analizy.

Pokazuje on prototyp funkcji lstat(), której

zadaniem jest pobranie informacji o pliku

i zapisanie ich do specjalnej struktury,

która odpowiada parametrom zbioru,

jakie przechowywane są w systemie

plików.

Struktura stat zawiera zmienne

odpowiadające parametrom pliku. Nas

interesują trzy ostatnie pozycje – są to

właśnie znaczniki MAC. Z pomocą tej

struktury można napisać program, który

będzie przeszukiwał system plików w

celu odnalezienia jakichś podejrzanych

modyfikacji.

Możemy np. za jego pomocą

sprawdzić pliki systemowe czy

konfiguracyjne, które ostatnio były

modyfikowane. Jak powiedzieliśmy

wcześniej, pliki te są zwykle bardzo

rzadko otwierane. Jeśli zauważymy

jakieś podejrzane zmiany czasu,

modyfikacje plików systemowych lub

konfiguracyjnych czy nawet pojawienie

się nowych programów, których w

systemie nie powinno być – mamy

ślad. O znacznikach MAC powiemy

więcej w sekcji artykułu poświęconej

UNIX-owym systemom plików. Tam

dokładniej omówimy, czym tak naprawdę

jest system plików i jak go wykorzystać

do naszych celów – do odnalezienia

niezbędnych śladów.

Czas to pieniądz

– zdobywanie informacji

o czasie

W większości przypadków cała analiza

nie dąży do tego, aby zobaczyć, co się

stało. To jest raczej oczywiste – jeśli ktoś

miał dostęp do naszego komputera,

mógł zrobić praktycznie wszystko, na co

miał ochotę. Nie mamy na to większego

wpływu. Ważniejsza jest informacja,

kiedy coś miało miejsce. Pozwoli nam

to zorientować się, jakie informacje

mogły przeciec z naszego komputera

czy przez jaki okres nasza maszyna

była narażona na ingerencję z zewnątrz.

Sprawdzając czas, prędzej czy później

dojdziemy też do tego, co tak naprawdę

było przyczyną kompromitacji systemu

i co zostało bądź mogło zostać na

nim zrobione. Warto przypomnieć, że

niniejszy artykuł nie będzie tłumaczył,

w jaki sposób wykryć, że system został

skompromitowany – to temat na

oddzielną publikację. Artykuł opisuje to,

co należy zrobić, dysponując już wiedzą

o naruszeniu integralności naszego

systemu operacyjnego.

Znaczniki MAC

MAC (ang. Modified , Accessed ,

Changed – czyli modyfikowany, używany,

zmieniany) to atrybuty systemu plików,

określające czas różnych operacji

dostępu do pliku. Spójrzmy na Listing 1.

System logujący ruch

sieciowy – kopalnia informacji

Wiele większych serwerów

korporacyjnych, czy nawet systemów w

małych firmach, których infrastruktura

sieciowa nie jest szczególnie

rozbudowana, posiada specjalne

systemy logujące ruch sieciowy.

Programy te, których przykładem jest

argus, pozwalają zapisywać wszystkie

zdarzenia, które miały miejsce w sieci.

Oczywiście napotykamy w tym miejscu

na pewien problem.

Otóż średniej wielkości serwer WWW

potrafi w ciągu doby wygenerować

dziesiątki (jeśli nie setki) gigabajtów

Listing 3. Odczytywanie informacji z dziennika systemu plików

# tune2fs -l /dev/hda1 | grep -i journal

ilesystem features : has_journal iletype needs_recovery sparse_super

Journal UUID : < none >

Journal inode : 8

Journal device : 0x0000

# icat / dev / hda1 8 > ~/ fsJournal

W Sieci

• http://www.porcupine.org/forensics/forensic-discovery – doskonała publikacja dotycząca analizy powłamaniowej,

• http://www.porcupine.org/forensics/tct.html – The Coroner's Toolkit,

• http://pl.wikipedia.org/wiki/Ext3 – system plików ext3.

58 HAKIN9 1/2009

ANALIZA POWŁAMANIOWA

ruchu sieciowego. Analizowanie

wszystkich danych zebranych przez

takie oprogramowanie mogłoby

powodować spore kłopoty – komu

chciałoby się to czytać? Jednak,

dzięki pomocy programów logujących,

można np. wyszczególnić tylko

połączenia na wybrany port czy też z

określonego hosta. Możliwe jest również

wygenerowanie logów na podstawie

daty zdarzenia sieciowego – jest to

kwestia dobrania odpowiedniego

oprogramowania i specyfikacji filtrów

wyszukiwania.

Załóżmy, że za pomocą analizy

znaczników MAC znaleźliśmy w systemie

nowy program – nazwijmy go telnetd .

Program podszywa się pod serwer

telnetu, nasłuchując oczywiście na

innym porcie w celu zamaskowania

swego istnienia. Dzięki obecności

oprogramowania analizującego ruch

sieciowy możliwe jest wychwycenie,

że pewien program nasłuchuje na

określonym porcie. Wtedy mamy już 2

informacje – nowy program w systemie

i w dodatku oczekujący połączeń z

Internetu. Przypadek? Chyba nie...

Z powyższego przykładu widać,

że warto mieć zainstalowane

oprogramowanie, którego zadaniem

jest nadzór ruchu sieciowego. W

szczególnych sytuacjach, takich jak

opisana, jego istnienie może być dla

nas nieocenioną pomocą. Warto więc

zawczasu zaopatrzyć się w tego typu

narzędzie.

W produkcie Microsoftu mamy dyski

twarde oznaczone literami alfabetu

łacińskiego. Aby dostać się do danej

partycji dysku, należy wybrać najpierw

literę odpowiadającą danemu dyskowi

fizycznemu bądź logicznemu (czyli na

przykład partycji).

W Linuksie, FreeBSD czy innym

podobnym systemie nie odczuwamy

w żaden sposób faktu, że właśnie

uzyskaliśmy dostęp do innego dysku

twardego, bądź też do innej jego partycji.

Nie odnosimy się bowiem do żadnego

symbolu pozwalającego nam wybrać

dany dysk.

Najwyższym poziomem w hierarchii

*niksa jest katalog / . Jest to nadrzędne

miejsce dla wszystkich innych plików

i katalogów w systemie – nie możemy

wejść do katalogu wyżej (odpowiada

to katalogowi X: w systemie Windows,

gdzie X oznacza literę dysku twardego).

Każdy system UNIX-owy zawiera pewien

standardowy zestaw podkatalogów

w katalogu głównym – są to m.in.

/mnt/ , /bin/, /usr/ , etc. Odpowiadają

one Windowsowemu katalogowi C:

\WINDOWS , C:\PROGRAM FILES . Uważny

Czytelnik od razu dostrzeże różnicę

w konwencji rozdzielania katalogów

�

��

Budowa systemu

plików UNIX-a

System plików w UNIX-ach znacząco

różni się od tego spotykanego w

systemach operacyjnych Microsoftu.

Podstawową różnicą jest podejście do

plików i katalogów – na pewno często

początkujący użytkownik jakiegoś UNIX-a

słyszy, że w UNIX-ie wszystko jest plikiem .

Jest to po części prawda, ponieważ w

systemie tym większość urządzeń (jeśli

nie wszystkie) ma swoją reprezentację

w postaci specjalnego pliku. Możliwy

jest dzięki temu bezpośredni dostęp do

tego urządzenia, co przyda nam się w

późniejszej części analizy.

Hierarchia systemu plików jest

również inna aniżeli w systemie Windows.

��

Rysunek 1. Struktura plików systemu Linux

1/2009

HAKIN9

OBRONA

– w systemie Windows używa się do

tego znaku \, natomiast w systemach

Linux czy FreeBSD jest to znak / (chociaż

w nowszych systemach Windows znak /

również działa).

System plików *niksa rozróżnia

wielkość liter, więc pliki XYZ i xyz to

dwa całkiem różne obiekty. Dodatkowo

musimy pamiętać, że nie występuje

tutaj pojęcie rozszerzenia pliku – jest

ono zupełnie opcjonalne i służy jedynie

naszej wygodzie, abyśmy z łatwością

mogli się zorientować, z czym mamy do

czynienia.

Zostało nam jeszcze do omówienia

kilka niezwykle istotnych pojęć, które

zaraz wykorzystamy w praktyce.

Pierwszym z nich jest tak zwane

dowiązanie do pliku, zwane inaczej

węzłem (ang. inode ). Jest to liczba

określająca dany plik, wskazująca na

dany obiekt, umożliwiająca dostęp

do niego. Mamy także dwa rodzaje

dowiązań (linków): są to dowiązania

miękkie i twarde. Twarde dowiązanie

wskazuje bezpośrednio na dane

zapisane na dysku twardym, odnosi

się po prostu do danego obszaru, jaki

zajmuje plik na urządzeniu. Określa na

przykład blok pamięci dysku twardego, w

którym rezyduje dany plik, jego fizyczny

adres.

Dowiązanie miękkie jest zaś

strukturą, która wskazuje na nazwę pliku

w systemie, nie zaś bezpośrednio na

dane, do których plik ten się odwołuje.

Jest to inaczej popularny skrót do

pliku. Przypuśćmy, że utworzyliśmy

plik /MojPlik . Mamy więc tylko jedno

dowiązanie twarde wskazujące na dane,

które przechowuje ten plik. Używając

polecenia ln -s , jesteśmy w stanie

utworzyć wiele dowiązań symbolicznych,

które będą de facto skrótami do tego

pliku, odnosząc się do jego nazwy w

systemie plików. Jednak tylko jedno

dowiązanie twarde będzie wskazywało

na dane zawarte w tymże pliku.

Do czego jest nam to potrzebne?

Otóż jest to niezbędne do zrozumienia

koncepcji usuwania pliku przez system

operacyjny. Jak pewnie każdy słyszał,

możliwe jest odzyskanie danych z

usuniętego pliku. Otóż kasowanie pliku

przez system operacyjny jest niczym

innym jak usunięciem twardych i

miękkich dowiązań do danego pliku

– tak, że nie jest możliwe jego odczytanie

z poziomu systemu plików. Dodatkowo

dany blok dysku, w którym znajdował

się ten plik, zostaje przez system

operacyjny zaznaczony do nadpisania

– przy nadarzającej się okazji system

operacyjny zapisze w danym miejscu

inne dane, niszcząc to, co było tam

wcześniej przechowywane. Możliwość

taka jest zależna od aktywności danego

komputera – jeśli często są na nim

wykonywane operacje odczytu/zapisu,

wtedy prawdopodobieństwo takiego

usunięcia, aby odzyskanie pliku było

bardzo trudne, znacząco wzrasta.

Wiadomość ta jest niezwykle

przydatna w analizie powłamaniowej

– możemy spróbować odczytać

zawartość dysku twardego z pominięciem

systemu plików, licząc, że odczytamy

jakieś wartościowe informacje. Co więcej,

możemy pokusić się o odzyskanie

wartościowych plików, które mógł

usunąć włamywacz. Faktem jest jednak,

iż jest to proces niezwykle praco- i

czasochłonny, często kończący się

niepowodzeniem. Gdy chcemy odzyskać

wartościowe dane, lepiej powierzyć to

zadanie wykwalifikowanym specjalistom,

którzy pracują w firmach na co dzień

zajmujących się podobnymi pracami.

Ostatnią istotną z naszego punktu

widzenia cechą systemu plików

nowoczesnego systemu operacyjnego,

takiego jak Linux, FreeBSD, Microsoft

Windows, jest tzw. journaling , czyli –

tłumacząc na język polski – księgowanie.

Jak sama wskazuje, jest to pewien

sposób zapisywania informacji o tym,

co miało miejsce w systemie plików

– operacje zapisu pliku, jego odczytu –

słowem, swoisty dziennik tego, co system

plików wykonał w określonym czasie. Jest

tak w większości przypadków, bowiem

możliwe jest także takie skonfigurowanie

księgowania, aby – zależnie od

naszych potrzeb – zapisywało cały plik

podwójnie, dzięki czemu możliwe będzie

odtworzenie na przykład niepoprawnie

zapisanych danych.

Wszystko jest kwestią pewnego

kompromisu pomiędzy wydajnością

(czyli operacją odczytu/zapisu) a

bezpieczeństwem – no i oczywiście

ilością miejsca na dysku, podwójny

zapis pochłania przecież dwa razy

więcej miejsca niż jest to wymagane dla

standardowej operacji zapisu.

Najpopularniejszym trybem jest

jednak ten, który nie księguje całego

pliku, tylko jego metadane (dane, jakie

ma o pliku system plików, zilustrowane za

pomocą struktury stat przedstawionej na

Listingu 1).

Przeszukiwanie systemu plików

Pierwszą rzeczą, jaką należy zrobić, jest

zbudowanie obrazu systemu plików.

Służy do tego komenda dd . Jej działanie

jest zaprezentowane na Listingu 2.

Za pomocą polecenia dd budujemy

obraz dysku twardego, nazywamy go np.

obraz.hda .

Następnie możemy albo

przekopiować ręcznie dany obraz na

inna maszynę, albo wykorzystać do tego

celu sieć – jak pokazano na Listingu.

Jednakże należy wziąć pod uwagę,

że sieć może nie być bezpieczna,

wtedy część informacji może zostać

przechwycona przez niepożądane

osoby. W takiej sytuacji należy

rozważyć zastosowanie szyfrowania

transferowanego pliku.

Następnym krokiem będzie

zamontowanie systemu plików ofiary

na naszym komputerze. Dokonujemy

tego za pomocą polecenia mount

tak, jakbyśmy montowali inne dowolne

urządzenie dyskowe. Za pomocą

przełącznika -t ustalamy, jaki system

plików zawiera obraz. Dodajemy również

opcje ro , noexec , nodev (aby zapobiec

przypadkowemu nadpisaniu obrazu

czy uruchomieniu programów). Teraz

możemy działać.

Na początek sprawdzimy znaczniki

MAC zamontowanego systemu plików.

Służy do tego polecenie mctime pakietu

narzędzi TCT, który zainstalowaliśmy

uprzednio na systemie używanym do

przeprowadzenia analizy. Polecenie to

pokaże nam, które pliki były używane – a

przecież, jak powiedzieliśmy na samym

początku, każde użycie pliku zwykle

niewykorzystywanego powinno wzbudzić

naszą ciekawość. Załóżmy, że odkryliśmy

plik, który ma nazwę telnetd , jak miało to

miejsce w przykładzie zamieszczonym

powyżej. Na początku powinniśmy się

upewnić, czy aby na pewno nie jest to

60 HAKIN9 1/2009

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: