plik

www.hakin9.org

hakin9 Nr 01/2008

Obrona

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

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

][

]

03B59E174000

add

esi

ebp

][

0040179E

]

8B7E0C

mov

edi

esi

][

]

03BD9E174000

add

edi

[

ebp

][

0040179E

]

813F4B45524E

cmp

[

edi

]

04E52454B

;"NREK"

0F857C000000

jne

001013F35

Rysunek 1.

Wykrywanie reakcyjne (Reactive) kontra heurystyczne

(Proactive)

��
��

��

��
��

�

��

hakin9 Nr 01/2008

www.hakin9.org

Obrona

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

][

]

03B5????????

add

esi

ebp

][

????????

]

8B7E0C

mov

edi

esi

][

]

03BD????????

add

edi

ebp

][

????????

]

813F4B45524E

cmp

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

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

edx

05A4D

;"ZM"

75F8

jne

00040106E

8BCA

mov

ecx

edx

8B493C

mov

ecx

][

]

03CA

add

ecx

edx

3BC8

cmp

ecx

eax

7FED

00040106E

6681395045

cmp

ecx

04550

;"EP"

75E6

jne

00040106E

Rysunek 3.

Fragmenty dwóch wersji robaka Agobot

hakin9 Nr 01/2008

www.hakin9.org

Obrona

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

•   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

• 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:debski.jakub@wp.pl