56

OBRONA

HAKIN9 1/2009

A

naliza powłamaniowa ma wiele
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ę?

KONRAD ZUWAŁA

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.

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

Stopień trudności

Analiza

powłamaniowa

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.

57

ANALIZA POWŁAMANIOWA

HAKIN9

1/2009

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 modyfikacji (modification) */

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

OBRONA

58

HAKIN9 1/2009

ANALIZA POWŁAMANIOWA

59

HAKIN9

1/2009

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.

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.

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.

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

filesystem

features

:

has_journal

filetype

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.

OBRONA

58

HAKIN9 1/2009

ANALIZA POWŁAMANIOWA

59

HAKIN9

1/2009

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.

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.

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

Rysunek 1.

Struktura plików systemu Linux

���

����

���

���

����

���

������������

����

���

���

���

����

����

����

���

���

���

�

�������

�����

�����

���������

���

����

����

����

���

�����

���

�����

�������

���

�����

���

����

�����

���

���

�����

������

���

���

����

���

���

�����

���

OBRONA

60

HAKIN9 1/2009

ANALIZA POWŁAMANIOWA

61

HAKIN9

1/2009

– 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

OBRONA

60

HAKIN9 1/2009

ANALIZA POWŁAMANIOWA

61

HAKIN9

1/2009

prawdziwy serwer telnetu. Najprostszą
metodą jest wygenerowanie sumy
md5 dla takiego pliku i jej porównanie
z dostępnymi sumami md5 dla plików
poszczególnych dystrybucji systemów,
które możemy znaleźć w Internecie.
Polecenie wygląda następująco:

md5sum telnetd

. Sumę porównujemy

z odpowiednią wielkością pochodzącą z
bazy danych odpowiadającej określonej
dystrybucji systemu. Jeśli sumy md5 są
inne, znaczy to, że mamy do czynienia
z dwoma różnymi programami. Możliwy
jest też scenariusz, w którym plik telnetd
będzie w rzeczywistości innym plikiem
z danego systemu, np. /bin/login, co
umożliwi intruzowi zdalne zalogowanie
się do systemu. Należy więc sprawdzić,
czy przypadkiem któraś z innych sum
md5 nie pasuje do analizowanego
pliku. Ważnym jest też czas utworzenia
tego pliku – informuje nas on o
prawdopodobnej dacie kompromitacji
systemu.

Kolejnym krokiem będzie analiza

logów z interfejsów sieciowych.
Często pozwoli nam to ustalić, które
hosty łączyły się w określonym dniu z
komputerem na danym porcie, np. na
tym, na którym nasłuchiwał program
telnetd. Mając adres IP takiego hosta,
możemy sprawdzić, czy aby nie
występuje on jeszcze gdzieś w logach.
Zwykle jest on obecny pod wcześniejszą
datą, co pozwala nam zobaczyć, jaki
program był przyczyną kompromitacji
analizowanego systemu. Mówiąc
prościej – która aplikacja była na tyle
dziurawa, że atakujący mógł dokonać jej
zdalnej exploitacji.

Gdy wiemy już, co było przyczyną

kompromitacji systemu i kiedy miała ona
miejsce, możemy przystąpić do bardziej
szczegółowej analizy znalezionego
programu. Nie jest to tematem niniejszej
publikacji, toteż ograniczymy się jedynie
do krótkiego przeglądu dostępnych
możliwości.

Analizę podejrzanego programu

możemy podzielić na statyczną
i dynamiczną.

Statyczna analiza obejmuje

wszystko, co możemy zrobić bez
uruchamiania podejrzanego programu.
Możemy za pomocą polecenia

strings

wypisać wszystkie łańcuchy

znakowe zawarte w programie,
sprawdzić, z jakimi bibliotekami jest
on dynamicznie połączony. Końcowym
– i najtrudniejszym – etapem jest
dezasemblacja kodu programu w
celu dokładnego prześledzenia jego
działania. Jest to jednak zadanie
żmudne i czasochłonne, do tego
wymaga niemałych umiejętności
programistycznych – doskonała
znajomość asemblera jest tutaj
absolutnie niezbędna.

Analiza dynamiczna obejmuje

wszystkie działania, jakie możemy
przeprowadzić podczas działania
badanego programu. Obejmuje to takie
działania jak debugowanie programu w
czasie rzeczywistym czy jego śledzenie
za pomocą systemowej funkcji

strace

.

Wiąże się to jednak z oczywistym
ryzykiem, jakim jest zniszczenie systemu,
na którym pracujemy.

W tym celu stworzono specjalne

systemy wirtualne do takiej właśnie
analizy. Starają się one emulować
określony system z daną platformą
sprzętową w celu maksymalnego
oszukania podejrzanego programu.
Można przechwytywać wywołania
funkcji systemowych, przerwań
sprzętowych, dostęp do interfejsów
sieciowych. Słowem – wszystko to,
czego może taki program potrzebować,
gdy jest uruchomiony w rzeczywistym
środowisku.

Poznanie działania podejrzanego

programu jest dość istotnym elementem
analizy powłamaniowej – pozwala ono
przekonać się, do czego mógł być
wykorzystany skompromitowany system.
Po wykonaniu takiej analizy powinniśmy
już dysponować informacją o tym, kiedy
wszystko się zaczęło – możemy nawet
dowiedzieć się, kiedy ostatni raz intruz
logował się do skompromitowanego
systemu. To wystarczy, aby sporządzić
odpowiedni raport z takiej analizy.

Szukanie informacji
w nietypowych miejscach

Ostatnią rzeczą, którą poruszymy w
tej publikacji, będzie pewnego rodzaju
ciekawostka – wyszukiwanie informacji
w miejscach całkowicie nietypowych.

Na początek weźmy dziennik

systemu plików. Dostęp do niego jest

możliwy, ale tylko poprzez bezpośrednie
odwołanie się do jego i-węzła na
dysku twardym, z pominięciem struktur
systemu plików. Musimy więc znaleźć
– za pomocą programu tune2fs dla
systemu ext3 – odpowiedni numer
inode odpowiadający dziennikowi
systemu plików, a następnie – używając
programu icat (inode cat) z pakietu TCK
– przekopiować zawartość owego węzła
do pliku na dysku twardym. Możemy
wtedy przeszukiwać dziennik w celu
znalezienia czegoś interesującego.

Pewnym smaczkiem jest również

bezpośrednie przeszukiwanie pamięci
na systemach UNIX-owych. Oczywiście,
jest ono przydatne tylko wtedy, gdy
stosunkowo szybko wykryliśmy włamanie.
Wtedy możemy sprawdzić, co aktualnie
znajduje się w pamięci i ewentualnie
przefiltrować wyniki w poszukiwaniu
dowodów. Służy do tego specjalny
plik-urządzenie w katalogu /dev – jest
to /dev/mem, czyli pamięć. Za pomocą
kombinacji komend

cat /dev/mem |

grep cosInteresujacego

możemy

przeszukać pamięć pod kątem
zawartości danych szczególnie dla nas
w tym momencie ważnych. Listing 3.
pokazuje, jak odczytać dziennik systemu
plików – jest to realizowane w sposób
dość nietypowy, stąd umiejscowienie
opisywanej operacji akurat w tym dziale.

Podsumowanie

Analiza powłamaniowa jest
nieodzownym narzędziem w sytuacji,
w której padliśmy ofiarą cyberataku.
Pozwala ustalić, kiedy to zdarzenie miało
miejsce i co mogło zostać wykonane
w skompromitowanym systemie – w
jakim celu użył go atakujący. Wiedza ta
jest konieczna w sytuacji, gdy chcemy
zabezpieczyć się przed powtórnym
złamaniem naszego systemu.
Pozostaje mieć nadzieję, że systemy
administrowane przez Czytelnika nie
będą musiały zostać poddane analizie
powłamaniowej.

Konrad Zuwała

Autor zajmuje się bezpieczeństwem aplikacji

internetowych oraz szeroko rozumianą ochroną

systemów komputerowych. W wolnych chwilach

programuje (głównie C/C++, PHP) oraz zarządza

portalem internetowym.

Kontakt z autorem: [e-mail]