www.hakin9.org

hakin9 Nr 01/2008

58

Obrona

J

est to obecnie najpopularniejsza metoda
detekcji, choć ma istotną wadę, mianowi-
cie jest metodą reakcyjną. Ponieważ In-

ternet umożliwia błyskawiczne rozprzestrze-
nianie się niebezpieczeństwa, jest ona często
niewystarczająca.

Metoda oparta na wzorcach zagrożeń cha-

rakteryzuje się niebezpieczną luką w czasie
pomiędzy pojawieniem się zagrożenia a udo-
stępnieniem wzorca je wykrywającego. Wzo-
rzec jest przygotowywany przez specjalistów
z firm antywirusowych, którzy muszą otrzymać
nową próbkę, następnie przeanalizować ją
i przygotować sygnaturę, która będzie zagroże-
nie w sposób jednoznaczny identyfikować, nie
powodując przy tym fałszywych alarmów (Ry-
sunek 1.). Alternatywą dla ręcznego wybierania
wzorców jest wykorzystanie automatycznie ge-
nerowanych sum kontrolnych, ale są one wraż-
liwe nawet na drobne modyfikacje i stosowa-
nie ich szybko prowadzi do nadmiernego roz-
rostu baz.

Rozwiązaniem tego problemu są zdoby-

wające coraz większą popularność mechani-
zmy prewencyjne oparte na klasyfikacji heu-
rystycznej. Heurystyka (gr. heurisko – znaleźć)
to umiejętność odkrywania nowych faktów

i związków pomiędzy faktami poprzez umiejęt-
ne postawienie hipotez. Algorytmy heurystycz-
ne na podstawie wiedzy o cechach istniejących
niebezpieczeństw są w stanie przeanalizować
skanowany obiekt i stwierdzić, czy można go
zaklasyfikować jako niebezpieczny.

Uogólnione wzorce

Metody wykrywania nieznanych wirusów by-
ły implementowane w programach antywiru-
sowych od początku ich istnienia. Najprost-

Heurystyka w programach

antywirusowych

Jakub Dębski

stopień trudności

Istnieją dwie główne metody wykrywania złośliwego

oprogramowania – oparte na wzorcach zagrożeń i na analizie

heurystycznej. Pierwszy typ zapewnia stuprocentową

wykrywalność zagrożeń, które są znane, jednak wymaga ciągłej

aktualizacji baz sygnatur.

Z artykułu dowiesz się

• czym jest heurystyka w programach antywiruso-

wych,

• jakie są rodzaje wykorzystywanych heurystyk,
• przed jakimi problemami stoją twórcy heury-

styk.

Co powinieneś wiedzieć

• powinieneś znać podstawy asemblera,
• powinieneś mieć ogólne pojęcie o budowie

systemów operacyjnych,

• powinieneś znać terminologię związaną z nie-

bezpiecznym oprogramowaniem.

Heurystyka w programach antywirusowych

hakin9 Nr 01/2008

www.hakin9.org

59

szą metodą rozpoznawania no-
wych wersji wirusów są uogólnione
wzorce. Wzorzec (scan-string, pat-
tern) jest ciągiem bajtów wyekstra-
howanym z wirusa, który w sposób
jednoznaczny go identyfikuje. Ma-
jąc wzorzec wirusa możemy zasto-
sować jeden z licznych algorytmów
dopasowujących, w celu znalezie-
nia go w badanym pliku. Wzorzec
musi spełniać kilka wymagań, aby
można go było zastosować do iden-
tyfikacji zagrożenia:

• powinien być fragmentem cha-

rakterystycznym dla wirusa (nie
może występować w czystych
plikach),

• nie może być zbyt krótki (mógłby

powodować fałszywe alarmy),

• nie może być zbyt długi (dopa-

sowanie go byłoby długotrwałe,
a zajętość pamięci znaczna przy
licznej bazie zagrożeń).

Przyjrzyjmy się fragmentowi wirusa
asemblerowego, który spełnia wy-
magania wzorca (Listing 1).

Powyższy fragment jest cha-

rakterystyczny, ponieważ poszu-
kuje pod wyliczanym adresem sło-
wa KERN, co nie powinno wystą-
pić w pliku czystym. Po lewej stro-
nie znajdują się bajty reprezentu-
jące instrukcje, których ciąg może
stanowić wzorzec służący do wy-
krycia wirusa.

Ponieważ wirus ten uzyskuje do-

stęp do własnych danych techni-
ką delta offset (tu względem reje-

stru ebp), w innych wersjach wirusa,
po wprowadzeniu do niego niewiel-
kiej zmiany, adresy mogą się zmie-
nić. Aby uogólnić ten wzorzec na in-
ne wersje, możemy zastąpić część
bajtów znakiem zastępczym odpo-
wiadającym podczas dopasowywa-
nia za dowolny bajt (Listing 2).

W ostatniej linii mamy skok wa-

runkowy, którego adres docelowy
jest offsetem względem aktualnej
instrukcji. Po dodaniu do wirusa do-
datkowych rozkazów offset ten może
się zmienić, więc w miejsce tych baj-
tów możemy wstawić znaki zastęp-
cze lub całkiem je wyciąć, ponieważ
znajdują się na końcu scan-stringa.
Dzięki powyższym zabiegom scan-
string będzie potrafił wykryć zarów-
no nowe wersje tego wirusa, jak też
wszystkie wirusy, które zawierają
opisany wzorzec. Ponieważ autorzy
niebezpiecznych programów często
wykorzystują fragmenty istniejące-
go złośliwego kodu, możliwe jest wy-
branie wzorca wychwytującego zu-
pełnie nowe zagrożenia.

Zbytnie skracanie i uogólnianie

scan-stringów może powodować
fałszywe alarmy. Rozwiązaniem

tego problemu jest stosowanie kil-
ku krótkich wzorców, które mu-
szą znajdować się w badanym pli-
ku, aby stwierdzić obecność wiru-
sa. Od tego podejścia już tylko krok
do heurystyki statycznej, czyli naj-
popularniejszej metody heurystycz-
nego wykrywania wirusów.

Heurystyka

Heurystykę w programach antywi-
rusowych można podzielić na kilka
kategorii w zależności od sposo-
bu działania. Najczęstszym spoty-
kanym podziałem jest wyszczegól-
nienie heurystyki statycznej i dy-
namicznej. Do metod heurystycz-
nych zalicza się również analizę
behawioralną oraz sprawdzanie
integralności. Przypatrzmy się po-
szczególnym typom i przeanalizuj-
my ich wady i zalety.

Heurystyka statyczna

Heurystyka statyczna opiera się na
analizie obiektu w postaci, w jakiej
zostanie on przekazany do analizy;
na traktowaniu obiektu jako ciągu
bajtów. Analiza taka bazuje na dys-
kryminatorach zebranych z istnieją-
cych niebezpiecznych programów,
czyli na cechach odróżniających nie-
bezpieczne programy od czystych
plików. Aby analizowany obiekt zo-
stał uznany za podejrzany, musi za-
wierać określoną liczbę dyskrymina-
torów. Dyskryminatory najczęściej
są ciągami bajtów, ale mogą być
związane np. z nietypowym wyglą-
dem pliku wykonywalnego.

Rozpatrzmy przykład wykrywa-

nia typowego, napisanego w asem-
blerze wirusa za pomocą heurysty-
ki statycznej. Typowy wirus infekuje
plik wykonywalny poprzez dołącze-
nie do niego swojego kodu, następ-
nie przeszukuje dysk w celu znale-

Listing 1.

Fragment wirusa asemblerowego nadający się na wzorzec

8BBDAA174000

mov

edi

,[

ebp

][

004017AA

]

8B7778

mov

esi

,

[

edi

][

78

]

03B59E174000

add

esi

,[

ebp

][

0040179E

]

8B7E0C

mov

edi

,[

esi

][

0C

]

03BD9E174000

add

edi

,

[

ebp

][

0040179E

]

813F4B45524E

cmp

d

,

[

edi

]

,

04E52454B

;"NREK"

0F857C000000

jne

.

001013F35

Rysunek 1.

Wykrywanie reakcyjne (Reactive) kontra heurystyczne

(Proactive)

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

������

��������

��������

��������

��������

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

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

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

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

�

�

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

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

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

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

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

hakin9 Nr 01/2008

www.hakin9.org

Obrona

60

zienia innych plików podatnych na
infekcję. Aby wykryć wirusa przy
użyciu heurystyki statycznej, musi-
my zgromadzić kolekcję mikrowzor-
ców, których występowanie będzie
świadczyło o podejrzanym dzia-
łaniu. Stworzenie użytecznej ba-
zy mikrowzorców wymaga wiedzy
na temat zasady działania wirusów
i technik w nich stosowanych.

Mikrowzorcem może być przy-

kładowo pobranie offsetu delta,
które można znaleźć w większo-
ści wirusów plikowych. Offset delta
pobierany jest przez wirusa w celu
ustalenia adresu początku samego
siebie. Jest on wirusowi potrzeb-
ny, jeżeli chce w prosty sposób ko-
rzystać z danych, które są zawarte
w obszarze wirusa. Popularną me-
todą ustalenia offsetu delta jest se-
kwencja rozkazów:

E800000000 call $+5
5D pop ebp
ED sub ebp, ????????

co przekłada się na mikrowzorzec

E8000000005DED

.

Występowanie tego mikrowzorca

może sugerować, że ciąg bajtów jest
kodem, który został dopisany do pli-
ku wykonywalnego. Innym przykła-
dem mikrowzorca może być spraw-
dzanie formatu pliku PE32 przed in-
fekcją lub podczas poszukiwania
w pamięci adresów funkcji API, za
pomocą porównań z charaktery-
stycznymi oznaczeniami MZ i PE.

Jego adres znajduje się pod offse-
tem 3C względem MZ (Listing 3).

W tym przykładzie za uogólniony

scan-string może służyć ciąg bajtów

4D5A75*8B*3C*504575,

gdzie * to 1-10

dowolnych znaków. Innymi mikrow-
zorcami infektorów plików mogą być
nazwy funkcji API pojawiające się
nie w sekcji importów, teksty *.exe,
„*.*”, będące specyfikacją dla wyszu-
kiwania plików do zarażenia lub war-
tości CRC32 policzone z nazw API
(wiele wirusów, szczególnie wzoro-
wanych na napisanych przez grupę
29A, korzystało z procedury wyszu-
kiwania adresów API bazującej na
sumie kontrolnej nazwy).

W przypadku złośliwych progra-

mów pisanych w językach wysokie-
go poziomu podejrzane może być
występowanie tekstów określają-
cych klucze rejestru odpowiedzialne
za autostart aplikacji w systemie (np.
SOFTWARE\Microsoft\Windows\
CurrentVersion\Run), fragmenty, z któ-
rych składane są maile (np. MA-
IL FROM:) czy adresy blokowanych
stron WWW (np. windowsupda-
te.microsoft.com). Wykrywanie heu-

rystyczne niebezpiecznego opro-
gramowania tworzonego w języ-
kach wysokiego poziomu jest jednak
znacznie bardziej skomplikowane niż
wykrycie kodu asemblerowego.

W celu zwiększenia jakości kla-

syfikacji przy użyciu heurystyki sta-
tycznej można połączyć mikrow-
zorce z nietypowym wyglądem pli-
ku spowodowanym modyfikacjami
przeprowadzonymi podczas infek-
cji. Przykładowo za nietypowe moż-
na uznać sytuacje, gdy:

• punkt wejścia do programu (Entry-

Point) wskazuje na ostatnią sek-
cję, która nie jest sekcją kodu (wi-
rus dopisał się do ostatniej sekcji),

• entryPoint wskazuje na wnętrze

nagłówka pliku PE (małe wirusy
platform Win9x umieszczały się
w nagłówku pliku),

• sekcja kodu posiada oprócz atry-

butu wykonywalne, także odczyt
i zapis (częste w przypadku wi-
rusów polimorficznych),

• sekcja relokacji lub sekcja zasobów

jest większa, niż być powinna.

Utrudnieniem techniki wykrywania
wirusów według nietypowego wy-
glądu stały się popularne ostatnio
kompresory (np. UPX) i protekto-
ry (np. Asprotect) plików wykony-
walnych, które wprowadzają typo-
we dla wirusów modyfikacje. Moż-
liwe jest zidentyfikowanie protekto-
ra i zignorowanie go przy tego typu
detekcji, ale – szczególnie w przy-
padku protektorów o otwartych źró-
dłach – protektory są często mody-
fikowane i zidentyfikowanie wszyst-
kich ich wersji jest kłopotliwe. Z dru-
giej strony samo występowanie za-
bezpieczenia w pliku stanowi pierw-
szą oznakę, że autor programu ma
coś do ukrycia i jest to podejrzane.

Listing 2.

Istotne informacje z fragmentu wirusa asemblerowego

8BBD????????

mov

edi

,[

ebp

][

????????

]

8B7778

mov

esi

,[

edi

][

78

]

03B5????????

add

esi

,[

ebp

][

????????

]

8B7E0C

mov

edi

,[

esi

][

0C

]

03BD????????

add

edi

,[

ebp

][

????????

]

813F4B45524E

cmp

d

,[

edi

],

04E52454B

;"NREK"

0F85

jne

????????

Rysunek 2.

Epidemia robaka Bagle.AS. (Źródło: www.virus-radar.com)

���

���

���

���

���

���

���

���

���

�

����

������

�

����

����

����

����

����

����

����

����

����

�����

�����

�����

�����

�����

��

���

��

���

��

���

��

���

��

���

�����

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

Heurystyka w programach antywirusowych

hakin9 Nr 01/2008

www.hakin9.org

61

Zaletą heurystyki statycznej jest

duża szybkość działania – tym więk-
sza, że analizowane obszary zwykle
nie są duże i można w całości wczy-
tać je do pamięci. Jej wadą jest ogra-
niczone pole analizy umożliwiają-
ce wykrycie jedynie tych zagrożeń,
które posiadają często występujące
cechy. Heurystyka taka potrafi prze-
analizować jedynie kod, który nie jest
zaszyfrowany, ale po uzyskaniu po-
staci zdeszyfrowanej (np. za pomo-
cą emulacji) można ją przekazać po-
nownie do skanowania przy użyciu
heurystyki statycznej.

Po znalezieniu w analizowa-

nym obiekcie wystarczającej licz-
by charakterystycznych cech może-
my stwierdzić, że obiekt jest niebez-
pieczny. Heurystyka statyczna dla in-
nych rodzajów wirusów, na przykład
skryptowych lub makrowirusów, two-
rzona jest w sposób analogiczny.

Heurystyka dynamiczna

Heurystyką dynamiczną nazywa
się analizę przeprowadzaną pod-
czas działania podejrzanego pro-
gramu, dzięki czemu możliwe jest
poznanie zachowania obiektu lub
uzyskanie postaci obiektu dającej
więcej informacji. Zwykle taką ana-
lizę przeprowadza się podczas uru-
chomienia podejrzanego progra-
mu w środowisku bezpiecznym,
za pomocą emulatora procesora
i systemu operacyjnego. Środowi-

sko takie nazywane jest piaskow-
nicą (ang. sandbox). Program
w niej uruchomiony – niczym dziec-
ko znajdujące się w piaskownicy –
nie może popsuć niczego, co znaj-
duje się poza nią, a jego działania
można obserwować i analizować.
Do heurystyki dynamicznej można
zaliczyć również analizę behawio-
ralną przeprowadzaną na działa-
jącym systemie, o której więcej bę-
dzie w dalszej części tekstu.

Emulatory w programach anty-

wirusowych początkowo tworzone
były w celu odszyfrowania części
zaszyfrowanej wirusów polimor-
ficznych. Wykonywały polimorficz-
ny kod wirusa do czasu, aż zakoń-
czył on deszyfrację, co najczęściej
wiązało się z wywołaniem funkcji
systemowej. Następnie rozszerzo-
no ich funkcjonalność o możliwość
analizy behawioralnej, więc wywo-
łanie funkcji systemowej nie kończy

działania, ale jest również emulo-
wane zgodnie z zachowaniem rze-
czywistego systemu operacyjnego.
Wykonując program w bezpiecz-
nym środowisku można spraw-
dzić, jakie akcje próbuje on podjąć
i stwierdzić w ten sposób, czy sta-
nowi potencjalne zagrożenie.

Innymi podejrzanymi zachowa-

niami, które może wykryć heurysty-
ka dynamiczna, są na przykład: li-
niowa modyfikacja obszaru pamię-
ci, a potem skok w zmodyfikowany
obszar (deszyfracja, często stoso-
wana w wirusach polimorficznych),
wykonywanie pustych pętli, któ-
re nie modyfikują stanu rejestrów
procesora ani pamięci (sztucz-
ka utrudniająca analizę programu
i spowalniająca emulację), czy wy-
konywanie kodu w obszarze sto-
su. Wszystkie te cechy świadczą
o tym, że wykonywany program nie
jest programem normalnym.

Wśród twórców wirusów istnie-

je przekonanie, że skomplikowanie
kodu polimorficznego utrudnia zna-
lezienie wirusa w pliku. Nic bardziej
mylnego. Sam kod polimorficzny
i metamorficzny jest relatywnie pro-
sty do wykrycia, gdyż jest całkowi-
cie różny od kodu wygenerowanego
przez kompilator, a nawet od kodu
asemblerowego stworzonego przez
człowieka. Generatory polimorficzne
tworzą znaczną liczbę instrukcji lub
zestawów instrukcji nic nierobiących,
tzw. śmieci. Kod ten, całkowicie nie-
zoptymalizowany, daje się za pomo-
cą mniej lub bardziej skomplikowa-
nych metod zidentyfikować i potrak-
tować jako podejrzane zachowanie.
Ponieważ protektory plików wykony-
walnych również zawierają polimor-

Listing 3.

Fragment wirusa infekującego pliki. Sprawdzenie nagłówka

pliku

66813A4D5A

cmp

w

,[

edx

],

05A4D

;"ZM"

75F8

jne

.

00040106E

8BCA

mov

ecx

,

edx

8B493C

mov

ecx

,[

ecx

][

3C

]

03CA

add

ecx

,

edx

3BC8

cmp

ecx

,

eax

7FED

jg

.

00040106E

6681395045

cmp

w

,[

ecx

],

04550

;"EP"

75E6

jne

.

00040106E

Rysunek 3.

Fragmenty dwóch wersji robaka Agobot

hakin9 Nr 01/2008

www.hakin9.org

Obrona

62

ficzne deszyfratory, ich nowe wersje
mogą być fałszywie identyfikowane
powyższymi metodami.

Stosowanie emulacji w proce-

sie analizy ma kilka istotnych minu-
sów. Główną wadą jest relatywnie
niewielka szybkość działania same-
go emulatora, a dodatkowe spraw-
dzenia wykonywane podczas ana-
lizy heurystycznej jeszcze emula-
cję spowalniają. Duże znaczenie
dla szybkości działania ma też pro-
blem stopu, czyli stwierdzenie, kie-
dy emulacja powinna się zakończyć.
Choć powstało wiele metod przy-
spieszających działanie emulatorów
i wciąż powstają nowe (np. wyko-
rzystanie wirtualizacji procesorów),
istnieje kilka barier nie do pokona-
nia. Najtrudniejszą z nich jest niede-
terministyczność wykonywania ko-
du. Dla niebezpiecznego programu
nie jest problemem, jeżeli zadziała
raz na kilka uruchomień. Może być
to spowodowane wywołaniem funk-
cji zwracającej losową wartość lub
warunkami logicznymi, które środo-
wisko musi spełnić. Emulator dzia-
łający w sposób deterministyczny
nie jest w stanie obsłużyć tych sytu-
acji, ponieważ emulacja podąża jed-
ną ścieżką, nie badając wszystkich
możliwych rozgałęzień kodu. Zatem
emulator może pójść ścieżką, któ-
ra kończy działanie niebezpieczne-
go programu, przez co nie będzie
można stwierdzić podejrzanego za-
chowania. Autorzy niebezpiecznego
oprogramowania starają się również

wykrywać uruchomienie w sztucz-
nym środowisku i reagować na nie,
ukrywając swoją obecność. Innym
przykładem niedeterministyczności
może być odmienne działanie pro-
gramu w różnych wersjach systemu
operacyjnego. Przed twórcą emula-
tora pozostaje problem wyboru, któ-
rą wersję emulować.

Analiza behawioralna

Każdy proces działający w trybie
użytkownika musi komunikować się
z systemem operacyjnym za pomo-
cą udostępnionego interfejsu API.
W trybie tym pracują wszystkie stan-
dardowe aplikacje, w tym większość
niebezpiecznych programów, po-
nieważ nie muszą do działania uzy-
skiwać nadzwyczajnych uprawnień
w systemie. Monitorując wywoła-
nia funkcji systemowych jesteśmy
w stanie uzyskać dokładne informa-
cje na temat zachowania analizowa-
nego programu. Monitorowanie mo-
że odbywać się albo podczas emu-
lacji w środowisku bezpiecznym, al-
bo w działającym systemie. Monito-
rowanie działającego systemu, mi-
mo jego spowolnienia, zyskuje coraz
większą popularność, ponieważ jest
w stanie wykryć zagrożenia, którym
emulacja nie jest w stanie sprostać.

Zaletą analizy behawioralnej jest

przeniesienie klasyfikacji na znacz-
nie wyższy poziom abstrakcji. Nie
operujemy w tym przypadku na po-
jedynczych instrukcjach kodu ma-
szynowego, ale w domenie opisanej

przez zachowania. Unikamy w ten
sposób problemów wynikających
z różnic w kodzie, które szczególnie
widoczne są w przypadku progra-
mów wygenerowanych przez kom-
pilatory języków wysokiego pozio-
mu (Rysunek 3). Co więcej, zmiany
wprowadzane w kolejnych wersjach
niebezpiecznego oprogramowania
zwykle w niewielki sposób zmie-
niają jego zachowanie, gdyż auto-
rzy zwiększają, co najwyżej, funk-
cjonalność programu.

Przykładowo, wykorzystując emu-

lator możemy stwierdzić, że program
wykonuje podejrzaną sekwencję wy-
wołań systemowych i określić obiekt
jako nowego wirusa lub jako odmia-
nę istniejącego. Większość wirusów
działających pod Windows na począt-
ku działania pobiera z systemu adresy
funkcji, które będą wykorzystywane.
Zakładając, że adres 0x77e60000 jest
adresem biblioteki KERNEL32.DLL
w pamięci procesu, pobieranie listy
wygląda następująco (wynik progra-
mu TraceApi na wirusie Win32.Miam).
Patrz Listing 4.

Pobranie adresów wykorzysty-

wanych funkcji API jest dla wirusa
niezbędne w sytuacji, gdy chce on
skorzystać z funkcji systemowych,
które nie znajdują się w Import Ad-
dress Table infekowanego pliku. Se-
kwencje takie można znaleźć w wi-
rusach asemblerowych i takie za-
chowanie świadczy o działaniu dołą-
czonego do programu wirusa.

Oczywiście heurystyczna klasy-

fikacja behawioralna może dotyczyć
wszystkich czynności, które wykonu-
je analizowany program, a które mo-
gą być niebezpieczne. Najczęściej
monitorowanie behawioralne doty-
czy typowych działań niebezpiecz-
nych programów, jakimi są:

• modyfikacja plików wykonywal-

nych,

• pobieranie i uruchamianie plików

z Internetu,

• wysyłanie listów za pomocą wła-

snego silnika SMTP,

• modyfikacja rejestru,
• modyfikacja plików systemowych,
• zabijanie procesów (np. progra-

mów antywirusowych),

Listing 4.

Początek logu programu TraceApi na wirusie Win32.Miam

GetProcAddress

(

77e60000

,

GetModuleHandleA

)

GetProcAddress

(

77e60000

,

GetCurrentDirectoryA

)

GetProcAddress

(

77e60000

,

FindFirstFileA

)

GetProcAddress

(

77e60000

,

FindNextFileA

)

GetProcAddress

(

77e60000

,

CreateFileA

)

GetProcAddress

(

77e60000

,

GetFileSize

)

GetProcAddress

(

77e60000

,

LocalAlloc

)

GetProcAddress

(

77e60000

,

ReadFile

)

GetProcAddress

(

77e60000

,

SetFilePointer

)

GetProcAddress

(

77e60000

,

WriteFile

)

GetProcAddress

(

77e60000

,

CloseHandle

)

GetProcAddress

(

77e60000

,

LocalFree

)

GetProcAddress

(

77e60000

,

GetLocalTime

)

GetProcAddress

(

77e60000

,

SetCurrentDirectoryA

)

GetProcAddress

(

77e60000

,

GetWindowsDirectoryA

)

GetProcAddress

(

77e60000

,

GetSystemDirectoryA

)

GetModuleHandleA

(

User32

.

dll

)

Heurystyka w programach antywirusowych

hakin9 Nr 01/2008

www.hakin9.org

63

• modyfikacja innych procesów,
• szpiegowanie klawiatury,
• nasłuchiwanie na otwartych por-

tach,

• praca programu bez widocznego

okna.

Problemem dla monitorów beha-
wioralnych mogą być aplikacje wie-
lowątkowe, ponieważ monitor mu-
si skupić się albo na czynnościach
wykonywanych globalnie przez ca-
łą aplikację, albo na czynnościach
wykonywanych przez poszczegól-
ne wątki. Większość współcześnie
tworzonego niebezpiecznego opro-
gramowania działa jednak w jed-
nym wątku.

Monitory behawioralne posiadają

zwykle rozbudowywaną bazę fałszy-
wych alarmów, gdyż niebezpieczne
programy pisane w językach wyso-
kiego poziomu charakteryzują się
pod względem zachowania wysokim
podobieństwem do plików czystych.
Przykładowo moduły autoaktualiza-
cji programów są pod względem za-
chowania bardzo podobne do popu-
larnych downloaderów.

Oprócz przeprowadzania skom-

plikowanej analizy zachowań, blo-
kowane mogą być wszystkie po-
tencjalnie niebezpieczne akcje, ta-
kie jak wstrzykiwanie kodu do in-
nych procesów i tworzenie w nich
zdalnych wątków czy automatycz-
ne uruchamianie makr MS Office.
Co więcej, niektóre programy anty-
wirusowe blokują wykonanie przez
użytkownika wszystkich skryptów
(.vbs, .bat, .cmd), traktując je jako
potencjalnie niebezpieczne.

Również monitorowanie dostępu

do rejestru staje się elementem pro-
gramów antywirusowych. Wymaga
jednak interaktywnego stwierdzenia,
czy dana modyfikacja była zamierzo-
na, czy nie, co jest kłopotliwe dla nie-
doświadczonego użytkownika.

Sprawdzanie

integralności

Najprostszym podejściem do heu-
rystycznego wykrywania obecno-
ści niebezpiecznego oprogramo-
wania jest zbadanie, czy określo-
ne obszary systemu (pliki, rejestr)

nie ulegają zmianie. Jeszcze kilka
lat temu nie było problemem mo-
nitorowanie zmian w plikach po-
przez sprawdzenie zapamiętanej
poprawnej sumy kontrolnej. Wraz
z upowszechnieniem Internetu
wzrosła liczba aplikacji, które au-
tomatycznie aktualizują się do naj-
nowszych wersji, modyfikując nie
tylko pliki danych, ale też pliki wy-
konywalne. Także sam system ope-
racyjny nie jest stały, ale modyfiko-
wany za pomocą ukazujących się
mniej lub bardziej regularnie łat.
Uwzględniając fakt, że baza sum
kontrolnych może również stać się
celem ataku, monitorowanie zmian
na podstawie sum kontrolnych jest
coraz rzadziej stosowane.

Sprawdzanie integralności dzia-

ła jednak w przypadku heurystycz-
nego wykrywania rootkitów, jak
czyni to System Virginity Verifier.
Analizuje on zmiany wprowadzone
w pamięci modułów systemowych
i porównuje je z poprawnymi war-
tościami odczytanymi z plików
(najlepiej podpisanych cyfrowo).
Jeżeli integralność modułów zo-
stanie naruszona, prawdopodobne
jest działanie rootkita, który zmo-
dyfikował system w celu ukrycia
w nim obiektów.

Integralność plików możemy

sprawdzić dzięki istnieniu coraz czę-
ściej stosowanych podpisów cyfro-
wych. Niektóre programy antywiru-
sowe nie potrafią przebić się przez
warstwy zabezpieczające plików wy-
konywalnych i wszystkie takie pli-
ki zgłaszają jako podejrzane. Jeżeli
jesteśmy twórcami oprogramowania
i chcemy zabezpieczyć program,
jednocześnie nie przyprawiając
użytkowników o palpitacje serca na
skutek fałszywego alarmu, program
taki powinniśmy podpisać. Firmy an-
tywirusowe będą dzięki temu mo-
gły zidentyfikować twórcę programu
i nie zgłaszać użytkownikowi zabez-
pieczenia jako podejrzanego.

Sprawdzanie integralności sta-

ło się jednym z podstawowych me-
chanizmów bezpieczeństwa w sys-
temie Windows Vista. Wspomnia-
ny mechanizm Kernel Patch Pro-
tection sprawdza, czy nie zostały
wprowadzone w systemie nielegal-
ne zmiany:

• modyfikowanie tablicy usług syste-

mowych (systfem service tables),

• modyfikowanie tablicy przerwań

(IDT),

• modyfikowanie tablicy globalnych

deskryptorów (GDT),

Rysunek 4.

Wizualizacja robaków InTheWild według podobieństwa

behawioralnego. Widzimy duże skupienia określające rodziny

hakin9 Nr 01/2008

www.hakin9.org

Obrona

64

• używanie w jądrze stosu, który nie

został przydzielony przez jądro,

• łatanie dowolnej części jądra.

Sprawą dyskusyjną jest, czy me-
chanizm ten rzeczywiście zwięk-
sza bezpieczeństwo systemu. Mo-
dyfikowanie systemu operacyjne-
go było od dawna stosowane przez
programy zabezpieczające, dzięki
czemu mogły one wykonać dodat-
kowe sprawdzenia, które uniemoż-
liwiał sam system. Przykładowo
działający w czasie rzeczywistym
system analizy zachowań musi
zintegrować się z systemem, być
bliżej systemu niż niebezpieczne
oprogramowanie, aby mógł je kon-
trolować. Istnienie Kernel Patch
Protection uniemożliwia taką in-
tegrację. Chociaż mechanizm ten
zabezpieczy system przed niektó-
rymi rootkitami, ich twórcy i tak są
w stanie go ominąć, wykorzystując
nielegalne sztuczki. Sztuczek tych
nie mogą jednak stosować produ-
cenci programów antywirusowych,
dzięki czemu złośliwe oprogramo-
wanie uzyskuje nad zabezpiecza-
jącym przewagę. Redukując moż-
liwości analizy behawioralnej Mi-
crosoft zmniejszył siłę heurystycz-
nej detekcji najpopularniejszych
zagrożeń, czyli działających w try-
bie użytkownika.

Wykrywanie anomalii

Kiedy mówimy o heurystycznej de-
tekcji niebezpiecznego oprogramo-
wania, możemy wyróżnić dwa typy
klasyfikacji, które faktycznie są wy-
krywaniem anomalii:

• wszystko, co nie jest podobne

do normalnego programu, jest
niebezpieczne,

• wszystko, co jest podobne do

niebezpiecznego programu, jest
niebezpieczne.

Pierwszy rodzaj wykrywania ano-
malii był skuteczny w przypadku in-
fektorów plików. Wykrywanie poli-
morfizmu i metamorfizmu, nietypo-
wej budowy plików czy kodu asem-
blerowego w punkcie wejścia pro-
gramu pozwalało na odróżnienie

plików bezpiecznych od zainfeko-
wanych. W momencie, gdy auto-
rzy złośliwych programów prze-
rzucili się na języki wysokiego po-
ziomu, programy bezpieczne i nie-
bezpieczne stały się zbyt podob-
ne, by można je było łatwo rozróż-
nić. Twórcom heurystyk pozostało
poszukiwanie podobieństw złośli-
wych programów do innych złośli-
wych programów. Co to oznacza?
Współcześnie nie jest możliwe wy-
krycie całkowicie nowego typu za-
grożenia, gdy nie ma ono cech
wspólnych z już istniejącymi.

Na szczęście dla użytkowni-

ków (i twórców programów antywi-
rusowych), autorzy złośliwych pro-
gramów wprowadzają w kolejnych
wersjach niewielkie zmiany, bazu-
ją na istniejących rozwiązaniach
i używają do zabezpieczenia plików
popularnych narzędzi. Dzięki temu
nowe zagrożenia posiadają wiele
cech wspólnych na wszystkich po-
ziomach, od podobieństwa binar-
nego, aż do podobieństwa opisane-
go w domenie zachowań (Rysunek
4). Już po otrzymaniu jednej prób-
ki program antywirusowy, wykorzy-
stujący zaawansowaną heurystykę,
jest w stanie wykryć wszystkie wa-
rianty tego zagrożenia.

Oszukiwanie heurystyki

Teoretycznie detekcja niebezpiecz-
nego programu, którego autor po-
starał się, żeby program nie był wy-
kryty, jest bardzo trudna. W sytu-
acji, gdy autor złośliwego programu
napisze go od podstaw, nie wzoru-
jąc się na istniejących rozwiąza-
niach, istnieje dość nikła szansa,
że algorytm heurystyczny go wy-
kryje. Jeszcze mniejsze jest praw-

dopodobieństwo wykrycia takiego
zagrożenia przy użyciu uogólnio-
nego wzorca. Co więcej, na sku-
tek dostępności darmowych lub te-
stowych wersji programów antywi-
rusowych, autor nowego programu
może sprawdzić, czy jest on wykry-
wany metodami heurystycznymi.
W takim przypadku może modyfi-
kować go do czasu, aż przestanie
być uznawany za podejrzany. Ist-
nieją również serwisy online ska-
nujące plik dużą liczbą silników an-
tywirusowych, takie jak Jotti's mal-
ware scan czy VirusTotal, z których
twórca robaka czy trojana może
skorzystać.

Z tego powodu firmy antywiruso-

we trzymają w rękawie kilka asów,
jakimi są niedostępne ogólnie me-
chanizmy detekcji, które umożliwia-
ją wczesne wykrycie nowego zagro-
żenia i dostarczenie próbki do firmy
w celu błyskawicznego przygotowa-
nia remedium.

Podsumowanie

Heurystyka w programach anty-
wirusowych ewoluuje wraz z za-
grożeniami. Programy antywiruso-
we od kilku lat nie służą jedynie
do wykrywania i usuwania wiru-
sów komputerowych, ale skupiają
się na ochronie użytkownika przed
szerokim wachlarzem ataków. Sta-
ły się pakietami zabezpieczający-
mi przed złośliwym oprogramo-
waniem, włamaniami, phishingiem,
rootkitami, a nawet spamem. Do
ich wykrycia mogą wykorzystać al-
bo wzorce, albo mechanizmy pre-
wencyjne, jakimi są współcześnie
heurystyki. Co jest skuteczniej-
sze? Wiadomo – lepiej zapobie-
gać, niż leczyć. l

O autorze

Jakub Dębski, starszy analityk w firmie ESET (producent programu NOD32), spe-
cjalizującej się w ochronie proaktywnej z wykorzystaniem najbardziej zaawanso-
wanych mechanizmów analizy heurystycznej. Wcześniej wieloletni pracownik pol-
skich firm antywirusowych. Był kierownikiem projektu silnika mks_vir, następnie
ArcaVir. Studia na Wojskowej Akademii Technicznej ukończył obroną pracy dy-
plomowej na temat wykorzystania sieci neuronowych w detekcji zagrożeń inter-
netowych.
Kontakt z autorem:[e-mail]