Slika 1. Grafički prikaz podjele alata za prikrivanje napadača u računalnom sustavu temeljene na postojanosti
Nikola Ivković
Iako nema konsenzusa oko definicije rootkita (u danjem tekstu izrazi rootkit i alat za prikrivanje napadača koristit će se ravnopravno) on se obično definira kao: alat ili skupina alata koji pomoću tehnika za skrivanje (eng. stealth) nastoje trajno očuvati prisutnost napadača ili aktivnog koda u sustavu. Važno je za uočiti da se rootkit ne koristi za zadobivanje pristupa računalu i administratorskim ovlastima, to se postiže na neki drugi način, već se njime samo zadržavaju ta prava na način da se ta prisutnost u sustavu skriva od administratora, programa za nadzor sustava i detekciju zlonamjernog i neželjenog koda.
Da bi ispunio svoj cilj alat za prikrivanje napadača može skrivati: procese, dretve, datoteke, mape, uređaje, podatke u registru sustava (eng. registry keys), usluge (eng. services), mrežne portove, veze, skrivene kanale (eng. covert channels), memorijske stranice, mutacije podataka i izvršnog koda, virtualne strojeve itd.
Alat za prikrivanje napadača često se kombinira s raznim oblicima zlonamjernog koda, ali ga koriste i unutar nekih sigurnosnih programa kao što su: antivirusni programi, sigurnosne stijene (eng. firewalls), sustavi za detekciju/sprječavanje upada(eng. intrusion detection/prevention systems, IDS/IPS).
Prvi alati za prikrivanje napadača javili su se u kasnim osamdesetima [1] na Unixu, a koristili su jednostavne tehnike za prikrivanje tragova kao što je brisanje log datoteka. S vremenom su alati za prikrivanje napadača evoluirali u mnogo sofisticiranije i moćnije oblike, a zadnjih godina došlo je do naglog porasta njihove brojnosti i kompleksnosti. Microsoft je objavio izviještaj [2] u kojem stoji da je u razdoblju od siječanja 2005. do veljače 2006. na 14% računala, na kojima je pronađen neki oblik zlonamjernog koda pomoću Malicious Software Removal Tool, bilo inficirano rootkitima.
Iz McAfee-jevog izvještaja [3] vidi se kolika je brzina rasta pojave alata za prikrivanje napadača. U 2005 zabilježili su oko 6 puta više infekcija alatima za prikrivanje napadača nego u 2004.godini, a u samo prvom kvartalu 2006. broj detekcija bio je nešto veći nego u cijeloj 2005. godini.
Alati za prikrivanje napadača javljaju se na raznim platformama i operacijskim sustavima (Unix, Linux, Mac OS X, Windows,...) i nisu samo problem Windows operacijskih sustava. No s obzirom na veliku raširenost Windowsa oni su u radu pretpostavljeni kao operacijski sustav u primjerima te kada se navode pojedini detalji i mehanizmi operacijskog sustava.
Alati za prikrivanje napadača mogu se podijeliti u dvije skupine s obzirom na to koriste li za svoje spremanje trajnu memoriju ili ne, a oni koji koriste trajnu memoriju mogu se dalje podijeliti u dvije podskupine kao što se i vidi na slici 1.
Slika 1. Grafički prikaz podjele alata za prikrivanje napadača u računalnom sustavu temeljene na postojanosti
Postojan rootkit može preživjeti isključivanje i ponovo pokretanje računala (eng. system reboot). Zbog toga mora koristiti neki oblik trajnog spremišta, tipično tvrdi disk, te mora imati mehanizam za automatsko pokretanje nakon novog uključivanja računala. Zbog tih svojih karakteristika lakše ga je detektirati nego nepostojan alate za prikrivanje napadača.
Dalje, postojan alat za prikrivanje napadača može se podijeliti u dvije potkategorije:
a) Standardan postojan alat za prikrivanje napadača koristi sekundarnu memoriju koja je i inače namijenjena za spremanje programa i podataka, npr. tvrdi disk, disketa, optički diskovi i sl. Najveći broj alata za prikrivanje napadača može se smjestiti upravo u ovu skupinu.
b) Alat za prikrivanje napadača ugrađen u sklopovlje odn. memoriju koja je ekskluzivno namijenjena za hardver kao što su BIOS i ostali firmware. Ovaj tip alata za prikrivanje napadača teško je proizvesti s obzirom da ovisi o hardveru i za njegovu implementaciju potrebno je poznavati jezike vrlo niske razine. Ipak nedavno je J. Heasman proizveo alate za prikrivanje napadača kao dokaz koncepta [4,5] koji se skrivaju u BIOS-u i programirljivoj ROM memoriji unutar PCI uređaja. S obzirom da se mnogi uređaji mogu nadograditi izravno iz Windowsa bez potrebe za gašenjem i paljenjem računala, napadač ne mora nužno imati niti fizički kontakt s računalom. S obzirom da ovaj alat za prikrivanje napadača ne ostavlja trag na tvrdom disku teško ga je detektirati, kada ga se i detektirani teško ga je ukloniti, a može preživjeti ne samo reinstalaciju operacijskog sustava nego i zamjenu tvrdog diska. Osim toga postoji i teoretska prijetnja da bi netko uspio proizvesti alat za prikrivanje napadača koji bi reprogramirao mikrokod centralnog procesora i time uveo instrukcije kojima bi mogao zaobići razdvajanje prstena u kojima se izvode instrukcije. Ipak takvo što još nitko nije uspio jer proizvođači skrivaju procedure izmjene mikrokoda, a neki od njih koriste i kriptografiju da bi onemogućili takav neovlašteni postupak.
Ovaj tip rootkita svoj programski kod sprema samo u radnu memoriju računala koja nakon gašenja računala gubi svoj sadržaj, te kao posljedica toga on ne može preživjeti gašenje i paljene računala. To ga na prvi pogled čini inferiornim, ali zbog toga ga je mnogo teže detektirati i provesti nad njim forenzičku analizu. Iako se čini nevjerojatno čini se da danas ne postoji siguran i pouzdan način čitanja radne memorije računala, a otpajanje od sustava i izdvajanje memorijskih modula za analizu nije moguće kao što je to moguće s tvrdim diskovima, jer se gašenjem računala gubi sadržaj. Važno je imati na umu i činjenicu da neki poslužitelji rade jako dugo bez isključivanja sustava pa tako nepostojan alat za prikrivanje napadača može biti dugo aktivan u sustavu gotovo kao i nepostojan.
Drugi način klasifikacije može se provesti u odnosu na razinu apstrakcije u kojoj alati za prikrivanje napadača rade. U pravilu alat za prikrivanje napadača koji koristi nižu razinu apstrakcije imaju daleko veću moć, ali ga je zato i puno teže proizvesti, a i puno je osjetljiviji na promjene i nadogradnje sustava. Naravno alat za prikrivanje napadača koji radi na nižoj razini apstrakcije može imati i pojedine module na višim razinama apstrakcije.
Slika 2. Grafički prikaz podjele alata za prikrivanje napadača u računalnom sustavu temeljene na razini apstrakcije
Procesi koji se izvode u korisničkom načinu rada imaju ograničene resurse i ne ugrožavaju jezgru operacijskog sustava. Razvoj bilo kakvih programa, pa tako i alata za prikrivanje napadača u sustavu mnogo je jednostavnije nego razvoj programa koji rade na nižim razinama apstrakcije.
Možemo razlikovati slijedeće podtipove :
a) Alat za prikrivanje napadača na aplikacijskoj razini - može u cijelosti zamijeniti pojedinu regularnu aplikaciju ili samo izmijeniti njen kod u datoteci ili njenu sliku procesa u radnoj memoriji.
b) Alat za prikrivanje napadača na razini biblioteke - zamjenjuje ili modificira DLL biblioteku i na taj način mijenjaju ponašanje svih aplikacija i drugih biblioteka koji koriste dotičnu DLL biblioteku
Ovaj tip rootkita imaju neograničen pristup hardveru, osjetljivim strukturama operacijskog sustava i privilegiranim procesorskim instrukcijama. On je u pravilu moćniji od rootkita koji radi u korisničkom načinu rada, ali ga je i teže proizvesti.
Možemo ga podijeliti u dvije podskupine:
a) Alat za prikrivanje napadača koji modificira statičke podatkovne strukture - mijenja podatke kao što su izvršne datoteke i njihove slike u memoriji. Ti se podaci ne bi smjeli mijenjati u normalnim okolnostima, mijenjaju se samo s nadogradnjom operacijskog sustava, najčešće kroz zakrpe.
b) Alat za prikrivanje napadača koji mijenja dinamičke jezgrine objekte (eng. Dynamic kernel object manipulation, DKOM) mijenja važne podatkovne strukture koje su i dizajnirane tako da ih dinamički mijenjaju aktivni procesi sustava. Primjer dinamičkog jezgrinog objekta je lista procesa koju održava operacijski sustav.
Hipervizorski alat za prikrivanje napadača je novi tip rootkita koji su se nedavno pojavio potaknut razvojem virtualizacijske tehnologije. Rootkit koji je hipervizor (eng. hypervisor), ili kako se još naziva nadglednik/upravitelj virtualnog stroja (eng. virtual machine monitor/manager, VMM), postavlja se ispod operacijskog sustava i tako njime manipulira i kontrolira način na koji on vidi svoju okolinu u kojoj se izvodi. Postoje razni oblici virtualizacije, primjerice hipervizor može u potpunosti emulirati hardver za gostujući operacijski sustav (OS) i interpretirati sve instrukcije, može dozvoliti direktno izvođenje neprivilegiranih procesorskih instrukcija, a emulirati privilegirane instrukcije, također mogu se koristiti i posebne hardverske instrukcije za efikasnu virtualizaciju. Trenutno su poznata tri hipervizorska rootkita: SubVirt, Blue Pill i Vitriol.
a) Programski zasnovan hipervizorski alat za prikrivanje napadača - ne koriste hardverske ekstenzije za efikasniju virtualizaciju. Vjerojatno jedini takav hipervizorski rootkit nazvan SubVirt nastao je kao zajednički istraživački projekt [12] Sveučilišta u Michiganu i Microsoft Reasearch-a. Oni su svoj rootkit utemeljili na komercijalno dostupnim upraviteljima virtualnim strojevima: VMware i Virtual PC. SubVirt se pokreće prije operacijskog sustava tijekom podizanja sustava, pa se dakle radi o postojanom programski zasnovanom hipervizorskom rootkitu.
b) Sklopovski potpomognut hipervizorski alat za prikrivanje napadača. Nedavna pojava hardverskih ekstenzija za efikasnu virtualizaciju koji su razvili dva najvećih proizvođača x86 procesora Intel i AMD omogućila je razvoj tankih hipervizora koji su omogućili virtualizaciju sa malim smanjenjem performansi sustava, što je osobito pogodno za razvoj hipervizorskih rootkita. Dvoje neovisnih istraživača razvili su hipervizorske rootkite koji koriste hardverske ekstenzije: J. Rutkowska napravila je Blue Pill [10] koristeći AMD-ovu tehnologiju, D. A. D. Zovi je razvio Vitriol [11] koji koristi Intelove hardverske ekstenzije. Oba rootkita su nepostojani rootkiti, a moguće ih je pokrenuti bez isključivanja i ponovnog uključivanja sustava.
Postoje različite metode koje može koristiti rootkit da bi postao skriven odnosno da bi sakrio druge aktivnosti na računalu: on može jednostavno zamijeniti neku datoteku sustava, izmijeniti tijek izvođenja instrukcija, manipulirati jezgrinim podacima ili iskoristiti virtualizacijsku tehnologiju.
Primjer 1 - skrivanje datoteka (rootkit na razini biblioteke).
Alat za skrivanje napadača može izmijeniti API funkciju koja daje listu datoteka u mapi, npr. na način da pozove originalnu funkciju, iz dobivene liste izbaci datoteke koje želi sakriti, te takvu promijenjenu listu proslijedi kao izlaz iz funkcije.
Primjer 2 - skrivanje procesa (DKOM rootkit).
Jezgra operacijskog sustava (Windowsa) održava dvostruko povezanu listu procesa koji se izvode. Tu listu kao izvor informacija koristi između ostalih i Windows Task Manager. Kada alat za skrivanje napadača ukloni zapis iz spomenute liste (ili ga jednostavno otpoji) proces nestane s liste procesa u Task Manageru i tako postane nevidljiv. Proces se i dalje izvršava u sustavu jer raspoređivač (eng. Scheduler) koristi interne strukture i dodjeljuje procesorsko vrijeme pojedinim dretvama, a ne procesima.
Za mijenjanje toka izvođenja instrukcija koriste se brojne tehnike:
Manipulacija dinamičkim jezgrinim objektima je metoda kojom se mijenjaju unutarnji objekti sustava koje koriste razni procesi kao izvor informacija o stanjima u sustavu. Ta tehnika može se koristiti za skrivanje procesa, pogonskih programa raznih uređaja i mrežnih portova, te za podizanje razine prioriteta dretvi, ali se na taj način ne mogu skrivati datoteke. Ovom metodom nastaje rootkit koji je teško detektirati jer mijenjaju objekte koji se po svojoj namjeni i trebaju mijenjati za vrijeme rada sustava, ali naravno ne od strane rootkita. S druge strane, ti objekti su nedokumentirani, vrlo osjetljivi, a njihova struktura i način korištenja mogu se izmijeniti tijekom nadogradnje sustava bez ikakve najave.
Najnoviji pristup koji koriste rootkiti je stvaranje virtualizacijskog rootkita koji se izvodi kao hipervizor razinu ispod operacijskog sustava i tako manipulira načinom na koji se sustav ponaša.
Prevencija se postiže pažljivim dizajnom sustava koji koristi različite sigurnosne mehanizme. Za to je također potrebno da i hardver ponudi određena sredstva operacijskom sustava za postizanje prevencije. Pored toga sustav bi morao čuvati sve moguće ulazne točke koje bi rootkit mogao iskoristiti za infiltraciju u sustav i spriječiti svaki pokušaj rootkita da se instalira. Operacijski sustav (OS) bi morao biti u stanju štititi svoju jezgru i druge važne komponente sustava čak i od vlastitih korisnika, te bi morao biti u stanju na siguran način verificirati svoj integritet. Nažalost današnji operacijski sustavi uglavnom nisu u stanju verificirati integritet vlastite jezgre i drugih ključnih komponenti sustava. Neke nove tehnologije uvedene u hardverske arhitekture namijenjene za široku tržište kao i metode uključene u nove Windows operacijske sustave predstavljaju korak u pravom smjeru. Najznačajnije nove mjere koje bi trebale djelovati preventivno protiv rootkita u jezgrinom načinu rada i rootkita hipervizora su: zaštita nadogradnje jezgre (eng. kernel patch protection), obavezno potpisivanje pogonskih programa (eng. enforced driver signing) i sigurno podizanje sustava (eng. secure system loading).
Da bi se spriječilo neovlaštena modifikacija jezgre operacijskog sustava uveden je mehanizam zaštite nadogradnje jezgre (eng. kernel patch protection, KPP) u sve 64-bitne verzije operacijskih sustava Windows. Trenutno KPP prati tablicu rutina servisa sustava (SSDT), tablicu prekidnih rutina (IDT), tablicu globalnog opisnika (eng. global descriptor table, GDT). Također zabranjuje se korištenje jezgrinog stoga koji nije alociran od strane jezgre, kao i nadogradnja bilo kojeg drugog dijela jezgre. U slučaju detekcije neke od takvih aktivnosti, operacijski sustav stvara izvještaj o pogrešci (eng. bug report) i gasi sustav. Unatoč tome što su otkriveni načini kako zaobići KPP, ova metoda je sigurno korak u smjeru stvaranja sigurnijeg operacijskog sustava, a pogreške u dizajnu i implementaciji koje omogućuju zaobilaženje zaštite vjerojatno će biti ispravljene.
Oko ove zaštitne mjere postoje određene kontroverze s obzirom da su do sada određeni proizvođači sigurnosnih programa kao što su sustavi za detekciju/sprječavanje uljeza (eng. intrusion detection/prevention systems, IDS/IPS), antivirusni i slični programi koristili rootkite u jezgrinom modu, nedokumentirane jezgrine strukture i druge modifikacije jezgre da bi se uspješnije borili protiv zlonamjernog koda. Zbog toga je Microsoft napokon pristao na kolaboraciju s nezavisnim proizvođačima softvera da bi se omogućile dokumentirane i podržane metode koje bi pružale potrebnu funkcionalnost bez mijenjanja jezgre operacijskog sustava. Kao rezultat ove suradnje najavljeno je dodavanje novih API funkcija u service pack 1 za Vistu.Osobno se slažem s tim pristupom jer postoji puno razloga zašto se KPP ne bi trebalo zaobilaziti. Rootkiti u jezgrinom modu mijenjaju osjetljive interne strukture operacijskog sustava što može dovesti do nestabilnosti sustava ili smanjenja performansi, može stvoriti nove sigurnosne propuste (eng. exploit) koje zlonamjerni kod može iskoristiti. Osim toga administrator sustava nije upoznat s tim modifikacijama sustava i nema kontrole nad njima što mu može stvoriti i dodatne probleme u detekciji i rješavanju potencijalnih problema u takvom iskrivljenom sustavu. Također, korištenje rootkita u legalnim programima otežava detekciju zlonamjernih rootkita zbog pojave lažno pozitivnih detekcija. Nažalost, KPP nije ugrađen u 32-bitne verzije Windowsa.
Obavezno digitalno potpisivanje pogonskih programa je odlična metoda koja je uvedena s Windows Vista operacijskim sustavima i trebala bi spriječiti ulazak svakog nepotpisanog koda u jezgru operacijskog sustava. Ova obaveza ne može se izbjeći budući da ni administrator sustava ne može instalirati pogonski program koji nije digitalno potpisan. Za potrebe testiranja pogonskih programa koji su još u razvoju omogućeno je učitavanje nepotpisanih pogonskih programa u jezgru OS-a koji je podignut u sigurnom modu (eng. safe mode), ali njegov ostanak u jezgri traje samo do prvog sljedećeg gašenja računala.
Ova metoda trebala bi spriječiti mnoge pokušaje instaliranja rootkita u jezgu OS-a. Ipak zbog pogreške u dizajnu J. Rutkowska uspjela je izvesti pagefile napad nad Windows Vista RC1. Ona je pronašla pogonski program čija se kod nalazio u memorijskoj stranici koji je mehanizmom virtualne memorije privremeno smještena na disk. Taj pogonski program smješten na disku Rutkowska je modificirala i kada je memorijska stranica ponovo učitana u radnu memoriju njen kod je ušao u jezgru operacijskog sustava unatoč tome što nije digitalno potpisan. Ovaj oblik napada spriječen je u konačnoj verziji Viste tako što je zabranjen pristup za pisanje sirovim diskovnim sektorima iz korisničkog načina, no to u konačnici ipak ne rješava problem na adekvatan način jer je još uvijek moguće da netko napiše legalni digitalno potpisani pogonski program za uređivač diska čije usluge bi onda mogao zloupotrijebiti rootkit. Vjerojatno bi najbolje rješenje bilo u potpunosti osposobiti mogućnost da se memorijske stranice na kojima je jezgra operacijskog sustava spremaju na disk.
Ovu vrstu zaštite moguće je zaobići i u slučaju da postoji digitalno potpisani pogonski program koji sadrži neku pogrešku (eng. bug) koju napadač može iskoristiti. Spomenuti pogonski program ne mora nužno biti instaliran u sustavu, već ga može instalirati sam napadač. Još očitiji primjer zaobilaženja zaštite na sličan način je da napadač sam kreira pogonski program koji je rootkit i onda ga digitalno potpiše, a tada ga može jednostavno instalirati u sustav, no u tom slučaju njegov identitet je poznat, što bi za njega vjerojatno značilo teške pravne posljedice. Ovaj bi se oblik zloupotrebe mogao malo i izmijeniti na način da napadač namjerno napiše pogonski program s nekom pogreškom koju će kasnije zloupotrijebiti i na taj način skida sa sebe dobar dio odgovornosti jer će kasnije tvrditi da je pogreška slučajna i da on nema nikakve veze s napadačem koji ju je iskoristio. S obzirom na moguće zaobilaženje ove sigurnosne metode očito je da ona neće u potpunosti onemogućiti ulazak zlonamjernog koda u jezgru operacijskog sustava, ali će ga zasigurno otežati. Jedan od mogućih način da se onemogući zloupotreba pogonskih program za ulazak u jezgru OS bila bi i ta da ih se izolira od jezgre tj. da se krene prema arhitekturi mikrojezgre (eng. microkernel).
Da bi se spriječilo onesposobljavanje sigurnosnih zaštitnih mjera kojima raspolaže operacijski sustav na način da se zlonamjerni kod podigne prije operacijskog sustava, proizvođači hardvera kao što su AMD i Intel stvorili su hardversku osnovu za sigurno podizanje sustava. Na primjer AMD-ova arhitektura sigurnog virtualnog stroja (eng. Secure Virtual Machine, SVM) omogućava sigurno podizanje sustava koje se može verificirati pomoću programa kojemu se vjeruje, a temelji se na usporedbi hash vrijednosti. Ova mjera može spriječiti rootkite hipervizore kao što je SubVirt koji mijenja redoslijed podizanja sustava na način da se rootkit podigne prije operacijskog sustava.
Kontrola korisnikovog računa je infrastruktura ugrađena u Windows Vista operacijske sustave; ona traži eksplicitno odobrenje korisnika za svaku akciju za koju su potrebne administratorske ovlasti čak i ako se radi o administratorskom računu. Ova mjera pomaže u sprječavanju između ostalog rootkita u jezgrinom načinu rada i hipervizorskih rootkita jer je za njihovu instalaciju potrebno zadobiti administratorske ovlasti.
Randomizacija adresnog prostora (eng. Address Space Layout Randomization, ASLR) i namjerno maskiranje pokazivača na funkcije tako što se mijenjaju pomoću slučajnog broja s kojim se provodi XOR operacija rootkitu značajno otežava postavljanje kuke (eng. hook).
Postoje i neke drugi sigurnosni mehanizmi koji bi trebali pomoći u prevenciji rootkita i drugih zlonamjernih kodova: enkripcija diska (eng. BitLocker Drive Encryption), korištenje pametnih kartica i pametnih kartica u kombinaciji s lozinkom u svrhu autentifikacije i pomicanje nekih pogonskih programa (eng. drivers) u korisnički način rada.
Svi ovi sigurnosni mehanizmi nesumnjivo će pridonijeti jačoj prevenciji rootkita koji narušavaju integritet jezgre operacijskog sustava i drugih važnih komponenti sustava, no oni zasigurno neće u potpunosti blokirati napade rootkita, osobiti onih koje su dozvolili sami korisnici zbog vlastite nebrige ili neznanja.
Naravno najbolji način u borbi protiv rootkita je sprječavanje njihovog ulaska u sustav, no kada sve mjere opreza ipak zakažu, jedina preostala mogućnost je detektiranje infiltriranih rootkita te poduzimanje odgovarajućih akcija. Nažalost najbolja reakcija na detekciju, osobito u slučaju rootkita koji ulazi u jezgru operacijskog sustava je potpuna reinstalacija sustava ili još bolje obnavljanje ispravnog sustava pomoću slike diska (eng. disk image) ako takva postoji.
Postoji nekoliko različitih koncepata za metode detekcije koje alat za detekciju rootkita može koristiti: traženje jedinstvenih uzoraka, provjera integriteta, detekcija na ponašajnoj razini, unakrsna detekcija i detekcija pomoću specijaliziranog sklopovlja.
Traženje jedinstvenih uzoraka je stara i prokušana metoda koja se može koristiti protiv rootkita i drugih oblika zlonamjernog koda. Program detektor pretražuje memoriju u potrazi za rootkitima koristeći metode za traženje uzoraka (eng. pattern matching) i poznate uzorke koji kao otisak prsta jednoznačno odgovaraju zlonamjernom kodu. Nedostatak ove metode je što se pomoću nje mogu detektirati samo već poznati rootkiti, a nemoćna je i protiv samo-modificirajućih oblika zlonamjernog koda.
Provjera integriteta je metoda kod koje se koristi baza hash vrijednosti važnih komponenti operacijskog sustava. Program detektor uspoređuje pohranjene hash vrijednosti s hashem datoteka sustava i njihovim slikama u radnoj memoriji. No direktnu provjeru integriteta na razini bitova nije moguće primijeniti na dinamičke jezgrine objekte (eng. dynamic kernel object data, DKOD) , već bi se u tu svrhu trebala razviti semantička provjera integriteta. Razviti takvu semantičku provjeru osobito je teško za nezavisne proizvođače softvera jer oni nemaju dokumentiranu listu svih DKOD struktura koje operacijski sustav koristi, kao niti opis na koji način se one koriste.
Detekcija na ponašajnoj razini je heuristička metoda koja traži neka neobična stanja i tehnike koje legalni programi normalno ne bi trebali koristiti. Mnogi rootkiti mijenjaju tok izvođenja programa postavljanjem kuke (eng. hook); ako se u programu javlja nekakvo grananje kod kojega odredišna adresa skače izvan nekog prihvatljivog adresnog područja onda je to ponašanje sumnjivo. Na primjer, proces koji koristi funkcije implementiranu u nekoj dinamički povezanoj biblioteci održava tablicu uvezenih adresa (eng. import address table, IAT) i nazive modula koji sadrže uvezene funkcije. U slučaju da instrukcija grananja kao što je jump ili call vodi izvan adresnog prostora odgovarajućeg modula možemo posumnjati da je to djelo rootkita.
Također, procedure koje su izmjenjene od strane rootkita imaju drugi broj instrukcija u odnosu na izvorne procedure. Usporedbom broja izvedenih instrukcija neke važne procedure sustava, izmjerenih pomoću jednokoračnog moda CPU-a, u slučaju izvorne i izmijenjene procedure moguće je otkriti prisutnost rootkita u sustavu. Naravno broj izvedenih instrukcija fluktuira čak i u čistom sustavu u ovisnosti o ulaznim parametrima procedure, ali Rutkowskovo istraživanje [7] pokazuje da je moguće jasno razaznati čisti i zaraženi sustav korištenjem statističke metode. On je uočio da se vrh histograma pomiče u slučaju da je procedura izmjenjena.
Detekcija na ponašajnoj razini ima kao prednost to što može detektirati nove i nepoznate rootkite, a njen glavni problem je relativno visok broj lažno pozitivnih detekcija.
Unakrsna detekcija je metoda kojom jednu te istu informaciju pribavljamo koristeći različite metode odnosno izvore u potrazi za proturječjima. Ona bi se zapravo mogla svrstati i u oblik detekcije na ponašajnoj razini koji ne koristi heuristiku. Jedan način njenog provođenja je da se u već pokrenutom sustavu uspoređuju rezultati dobiveni pomoću API funkcija najviše razine apstrakcije s rezultatima nekih API funkcija vrlo niske razine ili čak direktnim pregledavanjem internih struktura sustava. Drugi način je provođenje usporedbe pokrenutog sustava i ugašenog sustava koji se pregledava iz nekog drugog u tu vrhu pokrenutog sustava (online i offline analiza). Ova metoda može otkriti i rootkite koji manipuliraju s dinamičkim jezgrinim objektima.
Detekcija potpomognuta specijaliziranim sklopovljem. Jedan od velikih problema detekcijskih metoda koje su zasnovane isključivo na programskoj osnovi je taj da oni ne posjeduju siguran mehanizam za čitanje radne memorije. Iz tog razloga postoji nekoliko različitih inicijativa da se u detekciju zlonamjernog koda uključi i specijalizirano sklopovlje. Intel provodi istraživački projekt [8] u kojem razmatra mogućnost ugradnje specijaliziranog chipa na matičnu ploču uz pomoć kojeg bi se nadzirale aktivnosti koje se odvijaju u operacijskom sustavu.
Druga mogućnost je korištenje posebno proizvedenog sklopovlja koje bi se uključilo u sustav, a koristilo bi direktan pristup memoriji (eng. Direct memory access, DMA) preko PCI ili IEEE 1394 sabirnice. Jedna takva metoda koja bi koristila uređaj na PCI sabirnici istražuje se na sveučilištu u Marylandu [9]. Uređaj ima vlastiti procesor, a za čitanje radne memorije računala koristi DMA. Uređaj se koristi za nadziranje važnih komponenti operacijskog sustava i provjeru integriteta sustava.
S druge strane Joanna Rutkowska tvrdi da se da se i memorijom koja se dobiva pomoću DMA mehanizma može manipulirati. Ona je predstavila napad na čitanje memorije uz pomoć DMA mehanizma na Black Hat 2007 konferenciji [13], koji je izvela manipulirajući NorthBridgeom matične ploče.
Pojava hipervizorskih rootkita podigli su rootkite na sasvim novu razinu. Oni rade na razini koja ima veće privilegije od samog operacijskog sustava kojeg ugošćuju i tako mogu kontrolirati sam operacijski sustav i promijeniti njegovo ponašanje, što predstavlja novi problem za detekciju rootkita iz pokrenutog operacijskog sustava. Postoje čak i tvrdnje da je hardverski potpomognute hipervizorske rootkite kao što su Blue Pill i Vitriol apsolutno nemoguće detektirati. Ta tvrdnja proširila se kao senzacija i stvorila nepotrebnu paniku. Blue Pill i Vitriol su nepostojani alati za skrivanje napadača koji ne mogu preživjeti obično gašenje računala, kada bi se radilo o postojanim oblicima hipervizorskih alata za skrivanje napadača njihova bi se prisutnost u sustavu vrlo jednostavno otkrila uz pomoć offline analize. Jedini način da se takav hipervizorski rootkit pokrene je da koristi jezgrin način rada koji ima pristup privilegiranim procesorskim instrukcijama. Onim toga implementacija hipervizorskog rootkita prilično je kompleksna, pa se niti jedan od trenutno objavljenih hipervizorskih rootkita nije ni približio obliku koji bi bio stvarno nevidljiv, već se tu radi o konceptualnim oblicima rootkita. Unatoč tome detekcija hipervizorskog rootkita koji bi bio pravilno dizajniran i pažljivo implementiran bila bi izuzetno teška, pa je stoga ključno razviti efikasnu prevenciju.
Glavni problem kod detekcije hipervizorskih rootkita je zapravo kako detektirati iz pokrenutog operacijskog sustava radi li on direktno na stvarnom stroju ili je nalazi u virtualnom stroju kojeg nadzire neki hipervizor.
Prilično poznata metoda koju je predstavila, iako ne prva, J. Rutkowska pod nazivom Red Pill [14] koristi registar adrese tablice prekida (eng. interrupt descriptor table register, IDTR) za detekciju programski zasnovanih hipervizora. Zahvaljujući spletu sretnih okolnosti čim sam započeo sa istraživanjem te njezine metode otkrio sam da ona ima neke nedostatke odn. pogreške, ali se metoda i dalje može koristiti kao heuristika. Nakon što sam pokrenuo program koji koristi Red Pill detekcijsku metodu na zaslonu računala dobio sam poruku da se moj operacijski sustav izvodi unutar virtualnog stroja. S obzirom da sam bio vrlo skeptičan na tu dijagnozu pokrenuo sam program još nekoliko puta, a njegov odgovor je alternirao između toga da OS je odnosno nije u virtualnom stroju. Ova naizgled čudna pojava dogodila se jer sam program pokrenuo na računalu koji ima procesor s više jezgri, a svaka jezgra procesora ima svoj vlastiti IDT. Postavljanjem afiniteta procesora moguće je dobiti konzistentan odgovor. Logika koju koristi ova metoda je da se IDT normalno nalazi u nižim memorijskim pozicijama, a u kada je taj memorijski raspon zauzet sa hipervizorom, onda gostujući operacijski sustav mora koristiti više memorijske pozicije. Adresa IDT je smještena u procesorski registar IDTR i može se dobiti korištenjem neprivilegirane procesorske instrukcije. Tako ako hipervizor dozvoljava gostujućem OS da direktno izvršava procese koji rade u korisničkom načinu rada, tj. ne koristi privilegirane procesorske instrukcije, onda OS može na trivijalan način detektirati prisutnost hipervizora. Osim IDT moguće je koristiti adresu tablice globalnog opisnika (eng. global descriptor table, GDT) ili tablice lokalnog opisnika (eng. local descriptor table, LDT).
Sklopovski implementirana podrška za efikasnu virtualizaciju koji sada imaju AMDovi i Intelovi procesori potpuno je anihilirala ovaj pristup. To je dovelo do ideje da bi proizvođači hardvera trebali uvesti novu nepriviligiranu instrukcije koja bi kao operand koristila lozinku vezanu za procesor, a vraćala bi vrijednost 0 ako je lozinka točna i postoji aktivan hipervizor, a inače vrijednost 1. Lozinka se zahtjeva tako da neautorizirana osoba ne bi imala korist od ove instrukcije. Korištenje takve neprivilegirane instrukcije vjerojatno bi bilo prilično efikasno no ona u ovom obliku zapravo ne rješava problem. Virtualni strojevi kod kojih se kôd gostujućeg operacijskog sustava u potpunosti prevodi i emulira ne mogu se prevariti na ovaj način, a hipervizori koji dopuštaju gostujućem OS-u da direktno izvršava instrukcije u korisničkom načinu, mogli bi pretražiti radnu memoriju u potrazi za takvom instrukcijom i onda promijeniti ponašanje procesa koji je koristi.
Ako bi se već uvodile neke nove instrukcije za tu namjenu onda predlažem da se umjesto lozinke iskoristi kriptografija, a za korisnika koji ima fizički pristup računalu jednostavna LED dioda bila bi također korisno rješenje. Ta bi nova instrukcija, nazovimo je CRYPVMCHACK, koristila tajni ključ procesora umjesto lozinke. Program detektor šifrirao bi tajni broj pomoću privatnog ključa procesora i predao ga kao operand CRYPVMCHACK instrukcije. U slučaju da nema aktivnog hipervizora instrukcija bi vratila vrijednost tajnog broja, a inače neki drugi broj. Na ovaj način hipervizor ne bi mogao manipulirati sa rezultatom instrukcije na neki generički način, a da njegova prisutnost ne bude otkrivena. Ovu metodu hipervizor bi mogao zavarati kada bi on na neki način doznao tajni broj, ali on ne može na generički način otkriti gdje je i kako je nastao taj broj. U ekstremnom primjeru korisnik bi mogao na nekom drugom stroju generirati tajni broj i kriptirati ga tajnim ključem, pa ga onda unijeti programu detektoru, a ako rezultat detektor bi mu morao vratiti broj koji vraća instrukcija. Druga mogućnost za onesposobljavanje detekcije bila bi ta da hipervizor dozna ili otkrije procesorov tajni ključ, što bi se moglo izbjeći pažljivim dizajnom. Osim korištenja opisane metode s tajnim ključem, mogla bi se ekvivalentno koristiti i metoda koja bi koristila par privatni i javni ključ, pri čemu bi javni ključ bio poznat samo vlasniku procesora odn. autoriziranom korisniku.
Bez pomoći koju bi uključivala redizajn hardvera detekcija hipervizora je puno teža, ali ne i nemoguća. Svaki proces, pa tako i proces hipervizora zauzima neke hardverske resurse: on koristi procesorovo vrijeme i radnu memoriju, a možda i neke druge resurse.
Korištenje virtualnih strojeva dovodi i do toga da neke posebne instrukcije traju znatno duže čak i kada se koriste hardverske ekstenzije. Ova činjenica može se iskoristiti za vremensku analizu. Te instrukcije bi se mogle izvesti puno puta uzastopno unutar neke petlje, ali za detekciju hipervizora bilo bi potrebno znati i koliko traje izvođenje tih instrukciju u čistom sustavu. Za mjerenje vremena morali bi koristiti vanjski sat, jer bi hipervizor mogao manipulirati sa satom unutar računalnog sustava. Također, morali bismo biti sigurni i da sustav nije pod posebno velikim opterećenjem jer bi to također moglo dovesti do toga da se spomenuta petlja vremenski duže izvršava.
Druga važna posljedica izvođenja hipervizorskog rootkita je da on zauzima određene dijelove u memoriji. Detektor bi stoga mogao poduzeti sljedeće akcije:
Prvo pretražiti radnu memoriju u potrazi za rootkitovim kodom u slučaju da je on vidljiv i da mu se može pristupiti.
Ako hipervizor zabrani pristup detektoru određenim memorijskim stranicama onda je rootkitova prisutnost detektirana.
Hipervizorski rootkit mogao bi sakriti svoju memoriju od gostujućeg operacijskog sustava kao da taj dio memorije ne postoji. U tom slučaju detektor bi uz pomoć OS-a mogao izračunati količinu radne memorije koja je OS-u na raspolaganju i pitati korisnika radi li se o pravoj vrijednosti. Na primjer, korisnik bi možda znao da je kupio 1024 MB memorije, a ne primjerice 997 MB.
Hipervizor bi mogao pokušati sakriti svoje memorijske stranice tako da detektoru podvaliti dio memorije koju je posudio od čvrstog diska. Tim bi se stranicama pristupalo znatno sporije, a na samom tvrdom disku našla bi se neočekivana datoteka ili bi "nedostajalo" dio memorije.
Hipervizor bi mogao podvaliti istu memorijsku stranicu dvaput, ali i to bi se moglo detektirati.
Ipak daleko najbolji način u borbi protiv hipervizorskih rootkita bio bi da se iskoristi sljedeća tvrdnja koja se može i dokazati (za dokaz vidi izvor [15]):
Bez obzira na tehnologiju koja je korištena za stvaranje hipervizorskih rootkita da bi se stvorio virtualni stroj unutar kojega se kontrolira i manipulira gostujući operacijski sustav, na način da se pokrene OS, a zatim se hipervizorskim rootkitom spusti ispod razine operacijskog sustava, njegova se prisutnost može ili jednostavno detektirati ili ako to nije moguće onda se može na siguran način spriječiti njegovo pokretanje. Za tu tvrdnju potrebno je jedino pretpostaviti da postoje razine privilegija koje se mogu poredati (što vrijedi za x86 procesore koje imaju prstene privilegija) i da proces može detektirati procese iste ili niže razine privilegija.
Čini se da trenutna AMD-ova i Intelova tehnologija omogućuju izradu malih hipervizora koji bi mogli efikasno spriječiti pokretanje hipervizorskih rootkita, no ako se i to pokaže neistinitim, onda se takav rootkit može detektirati.
Iako se ponekad rootkiti koriste i u dobroj namjeri moje osobno uvjerenje je da ih ne bi trebalo koristiti kao trajno rješenje u legalnim programima. Bilo bi daleko bolje dizajnirati sustav koji pruža ekvivalentne funkcionalnosti koje su potrebne sigurnosnom softveru kao podrška u borbi protiv raznih oblika zlonamjernog koda i potencijalno neželjenih programa.
Očito je da u današnjem društvu, gdje su ljudi snažno vezani uz računalne i komunikacijske tehnologije, ljudi žele da njihovi vrijedni podaci ostanu privatni i sigurni, žele koristiti računala u poslovanju i trgovini, u tom svijetu nema mjesta za rootkite. Put prema računarstvu koje je sigurno i vrijedno povjerenja trebao bi ostvariti kroz dizajn sustava koji koristi kriptografiju i pomoć sigurnosnog sklopovlja.
Danas najnapredniji alati za skrivanje napadača kao što su oni koji manipuliraju s mehanizmom virtualne memorije, hipervizorski alati za skrivanje i oni koji se skrivaju u firmwareu razvijeni su od strane istraživača kao dokazi određenih koncepata i nisu opremljeni prvom nevidljivošću. Važno je spomenuti da oni često pate i od raznih problema koje nije tako lako premostiti da bi alat za skrivanje napadača postao uistinu nevidljiv. U našoj bliskoj budućnosti vjerojatno će najveću prijetnju predstavljati alati za skrivanje koji mijenjaju dinamičke jezgrine objekte, ali da bismo bili sigurni od prijetnji potrebno je poduzeti adekvatne zaštitne mjere protiv hipervizorskih alata za skrivanje napadača koji imaju veliki potencijal.
Virtualizacijska tehnologija može omogućiti veću razinu sigurnosti uz upotrebu malih jednostavnih hipervizora koji bi bili mnogo jednostavniji od današnjih operacijskih sustava, pa bi njihova implementaciju bilo puno lakše provesti bez pojave grešaka i sigurnosnih propusta.
[1] A. D. Joseph, Rootkits, Lecture slides for Computer Security course from UC Berkley, 2005; inst.eecs.berkeley.edu/~cs161/fa05/Notes/cs161.1202.pdf
[2] M. Braverman et al., Windows Malicious Software Removal Tool: Progress Made, Trends Observed, A White Paper from the Microsoft Antimalware Team, 2006; download.microsoft.com/download/5/6/d/56d20350-afc8-4051-a0df-677b28298912/MSRT%20-%20Progress%20Made%20Lessons%20Learned.pdf
[3] McAfee, Inc, Rootkits, Part 1 of 3: The Growing Threat, White Paper, 2006; www.mcafee.com/us/local_content/ white_papers/threat_center/wp_akapoor_rootkits1_en.pdf
[4] J. Heasman, Implementing and Detecting an ACPI Rootkit, presented at Black Hat Federal, 2006; www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf
[5] J. Heasman, Implementing and Detecting a PCI Rootkit, White Paper, 2006; www.ngssoftware.com/research/ papers/Implementing_And_Detecting_A_PCI_Rootkit.pdf
[6] S. Sparks, J. Butler, "SHADOW WALKER" Raising The Bar For Rootkit Detection, Black Hat Japan, 2005; www.blackhat.com/presentations/bh-jp-05/bh-jp-05-sparks-butler.pdf
[7] Jan K. Rutkowski, Advanced Windows 2000 Rootkits detection, Black Hat Briefings, Las Vegas, July, 2003; www.blackhat.com/presentations/bh-usa-03/bh-us-03-rutkowski/bh-us-03-rutkowski-paper.pdf
[8] Intel, Inc, OS Independent Run-time System Integrity Services, 2005; www.intel.com/technology/comms/ download/system_integrity_services.pdf
[9] N. Petroni, T. Fraser, J. Molina and W. Arbaugh, Copilot-a Coprocessor-based Kernel Runtime Integrity Monitor, in Proc. Usenix Security Symposium, 2004; www.usenix.org/events/sec04/tech/full_papers/petroni/petroni_html/main.html
[10] J. Rutkowska, Subverting Vista Kernel For Fun And Profit, SyScan and Black Hat conferencies in 2006; www.blackhat.com/presentations/bh-usa-06/BH-US-06-Rutkowska.pdf
[11] D. A. D. Zovi, Hardware Virtualization Rootkits, Black Hat USA 2006; www.blackhat.com/presentations/bh-usa-06/BH-US-06-Zovi.pdf
[12] S. T. King, P. M. Chen, Y. Wang, C. Verbowski, H. J. Wang, J. R. Lorch, SubVirt: Implementing malware with virtual machines, to appear in Proc. IEEE Symposium on Security and Privacy, May 2006
[13] J. Rutkowska, Beyond The CPU: Defeating Hardware Based RAM Acquisition Tools (Part I: AMD case), Black Hat Briefings, February 2007; www.invisiblethings.org/papers/cheating-hardware-memory-acquisition-updated.ppt
[14] J. Rutkowska, Red Pill... or how to detect VMM using (almost) one CPU instruction, November 2004; www.invisiblethings.org/papers/redpill.html