Otkrivanje zlonamjernih programa koji mijenjaju sustavske podatke i procese

Transcription

1 SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br Otkrivanje zlonamjernih programa koji mijenjaju sustavske podatke i procese Luka Milković Voditelj: Marin Golub, dr. sc. Zagreb, rujan 2009.

2 Sažetak U diplomskom radu opisuje se posebna vrsta zlonamjernih programa koji mijenjaju sustavske podatke i objekte kako bi na taj način izbjegli detekciju - engl. rootkit. Opisana je njihova taksonomija i cjelokupan način djelovanja tih programa: ugradnja u računalo i način skrivanja procesa, datoteka, upravljačkih programa i mreţnih veza. U praktičnom dijelu rada implementiran je sustav koji prikazuje potpuno stablo procesa s dodatnim informacijama o procesima. Sustav ima mogućnost okrivanja skrivenih procesa koristeći se strukturama operacijskog sustava na niskoj razini. Pomoću sustava se moţe ugasiti bilo koji proces u računalu. Sustav moţe nadzirati pokretanje procesa u operacijskom sustavu i onemogućiti njihovo pokretanje, ovisno o ţelji korisnika. Dodatno, sustav moţe otkriti i otkloniti izmjene u tablici sustavskih poziva operacijskog sustava. Abstract This diploma thesis deals with a special type of malicious programs - rootkits- - that alter system data and objects in order to avoid detection. The taxonomy and the details of the functioning of these programs are described: their infiltration into the computer and the way they hide processes, folders, drivers and network connections. The practical part of the thesis deals with implementing a system/program that displays a complete process tree and additional information about processes. This system is capable of discovering hidden processes using low-level structures of the operating system (OS), as well as terminating any active process. It can monitor creation/execution of all processes in the OS, and can block them at the discretion of the user. Additionally, the system can discover and remove alterations in the system call table of the OS.

3 1. Uvod 1 2. Alati za prikrivanje prisutnosti napadača - rootkiti Povijest rootkita Klasifikacija rootkita Načini zaraze računalnog sustava rootkitom 9 3. Načini djelovanja rootkita Ugradnja rootkita u računalo Općeniti načini skrivanja objekata operacijskog sustava i načini otkrivanja modifikacija Korisnički način rada Jezgrin način rada Specifičnosti pri skrivanju procesa operacijskog sustava Specifičnosti pri skrivanju upravljačkih programa Specifičnosti pri skrivanju datoteka Specifičnosti pri skrivanju mreţnog prometa i veza Praktični rad Odabir programskog jezika Struktura sustava Grafičko sučelje Lista procesa i podsustavi vezani uz dohvat informacija o procesima "Izvlačenje" metoda iz ntdll.dll datoteke Sustav za dohvat simbola i rad sa simbolima Informacije o procesima Otkrivanje skrivenih procesa Gašenje procesa Otkrivanje izmjena u tablici sustavskih poziva Nadziranje pokretanja procesa u operacijskom sustavu Sustav zakački/kuka - sustav za izmjene jezgrinih funkcija Problem zaustavljanja procesa i dojave dogaďaja korisniku Djelovanje sustava nadzora Zaključak Literatura 90

4 1. Uvod Razvoj računarskih znanosti i moderne tehnologije uvelike je promijenio ljudsku svakodnevicu. Poslovi, financije, kupovina, slobodno vrijeme pa čak i socijalni kontakti i veliki dio društvenog ţivota odvijaju se posredstvom računala povezanih u globalnu mreţu. Takva velika koncentracija aktivnosti privlači meďutim i pojedince i organizacije koji se ţele domoći informacija i sredstava na nelegalan način. Jedan od načina na koji takve skupine ispunjavaju svoje ciljeve jest razvoj i distribucija zloćudnih programa. Iako je vrlo teško odrediti točan (pa čak i pribliţan) broj računala koja su zaraţena nekom vrstom zloćudnog programa, na temelju dostupnih izvora [1] i [2] moţe se zaključiti da se broj zaraţenih računala mjeri u desetcima milijuna, čak i stotinama milijuna. Od prvog računalnog virusa [3] do danas proteklo je gotovo 40 godina. Nekada su autori virusa najčešće bili vrlo nadareni pojedinci koji su svoj talent iskorištavali na pogrešan način, no uglavnom nisu bili financijski motivirani. Danas zloćudne programe razvijaju razvojni timovi čija je osnovna motivacija profit, odnosno kraďa brojeva kreditnih kartica i ostalih informacija pomoću kojih se moţe doći do novca sa zaraţenog računala. Stupanj sloţenosti i usavršenosti današnjih zloćudnih programa usporediv je sa sloţenim komercijalnim programskim sustavima. Autorima zloćudnih programa vrlo je vaţno da njihov "upad" u računalo, kao i sam proces kraďe informacija ostane što duţe neprimijećen. Upravo zbog toga, kao osnovna komponenta brojnih zloćudnih programa pojavili su se tzv. rootkiti - programi za prikrivanje prisutnosti napadača u računalnom sustavu koji, kao što im i ime govori, skrivaju napadačevu prisutnost u korisnikovom računalu i osiguravaju napadaču obavljanje zloćudnih aktivnosti bez (gotovo) ikakvog znanja korisnika. Korisnik se teško moţe boriti protiv nečega što ne vidi, ne moţe otkriti nešto za što ne zna da postoji i neće poduzeti nikakve sigurnosne protumjere ako ne postoji sumnja u integritet i kompromitiranost sustava. Zadaća rootkita je uvjeriti korisnika da njegov sustav nije kompromitiran. Tradicionalni antivirusni programi najčešće ne otkrivaju rootkite jednom kada su oni prisutni i aktivni u sustavu, čime se dodatno povećava osjećaj laţne sigurnosti u nezaraţenost sustava. Cilj ovog rada je upozoriti na vrlo veliku opasnost koju rootkiti predstavljaju za računalnu sigurnost. U radu je dan opis rootkita, njihova klasifikacija i osnovni načini zaraze računala rootkitom. Unatoč relativno dobroj svijesti korisnika o opasnostima koje prijete na Internetu i na računalima općenito, korisnici ipak najčešće vjeruju da antivirusni program i zaštitna stijena (engl. firewall) pruţaju apsolutnu sigurnost i mali broj njih je svjestan opasnosti protiv kojih antivirusni programi nisu učinkoviti. Zbog toga se u radu posebno naglašava holistički pristup sigurnosti - prevencija zaraze nadgledanjem ključnih aktivnosti u sustavu, detekcija i uklanjanje zaraze ako do nje ipak doďe. U praktičnom dijelu rada načinjen je programski sustav za nadziranje aktivnih procesa u računalnom sustavu s Windows operacijskim sustavom. Program ima mogućnost prikaza rootkit (skrivenih) procesa i njihovog gašenja. Dodatno, program nadzire pokretanje procesa u sustavu. 1

5 2. Alati za prikrivanje prisutnosti napadača - rootkiti Današnji zloćudni programi mogu se općenito razvrstati u nekoliko kategorija. Kategorije zloćudnih programa nisu uvijek jasno odvojene jedna od druge niti se sve mogu precizno definirati pa bi zbog toga grafički prikaz klasifikacije bio vrlo sloţen i nepregledan. Neke od poznatijih kategorija zloćudnih programa čine virusi, računalni crvi, trojanski konji i špijunski programi - spyware. Virusi su računalni programi koji imaju sposobnost "rekurzivnog kopiranja potencijalno izmijenjene inačice sebe samih" [4]. Osnovna karakteristika virusa je "infekcija" drugih, zdravih datoteka u sustavu i njihova modifikacija. Prenošenje tih datoteka na druga računala putem mreţe ili prijenosnog medija uzrokuje zarazu drugih računala. Širenje virusa na druga računala izazvano je akcijom korisnika - npr. korištenje zaraţenog prijenosnog medija, pokretanje zaraţene datoteke koja je pristigla s mreţe itd. Računalni crvi se, za razliku od virusa, mogu samostalno širiti na druga računala, bez ikakve intervencije korisnika. Crvi najčešće iskorištavaju sigurnosne propuste u mreţnim servisima (npr. web posluţiteljima) i na taj se način samostalno repliciraju. Trojanski konji su naizgled bezopasni programi čija je prava namjena skrivena i najčešće zloćudna. Trojanski konj se predstavlja kao dobroćudna aplikacija (najčešće računalna igra ili drugi zabavni sadrţaj), no zapravo sadrţava zloćudnu komponentu u obliku virusa, crva ili neke druge vrste zloćudnog programa. Korisnik nije svjestan da pokretanjem takve aplikacije zapravo pokreće zloćudni program. Špijunski programi predstavljaju kategoriju zloćudnih programa koja je vrlo slična trojanskim konjima. U slobodnom prijevodu, pojam spyware označava program (engl. ware) koji obavlja nadgledanje, odnosno špijunaţu (engl. spy) korisnika. Razlika izmeďu trojanskih konja i špijunskih programa je isključivo u namjeni: dok trojanski konji najčešće sluţe napadačima za ostvarivanje neovlaštenog pristupa računalu (engl. backdoor) i za kontroliranje računala neovisno o znanju korisnika, špijunski program se najčešće koristi za praćenje Internet i drugih navika korisnika, na temelju čega autori programa dalje pokušavaju korisniku prezentirati "personalizirane" oglase u nadi da će korisnik kupiti njihov proizvod. Posebnu kategoriju zloćudnih programa čine rootkiti. Alat za prikrivanje prisutnosti napadača, odnosno rootkit, moţe se definirati kao program ili skup programa i izvornog teksta programa koji omogućava napadaču da trajno ili duže vrijeme neopaženo održi svoju prisutnost na zaraženom računalu. Riječ rootkit ne moţe se doslovno prevesti na hrvatski jezik, niti bi taj prijevod imao smisla. U engleskom jeziku pojam root označava korisnika u UNIX/Linux operacijskom sustavu koji posjeduje najviše privilegije. Rootkit bi dakle bio alat (engl. kit) ili skup alata koji napadaču omogućava zadržavanje najviših privilegija jednom kada napadač dobije pristup sustavu. Zbog jednostavnosti, ali i uvrijeţenog termina u svijetu računalne sigurnosti, u daljnjem tekstu će se češće koristiti termin rootkit, unatoč tome što nije u duhu hrvatskoga jezika. Rootkit moţemo promatrati kao jedan sloţeni program koji skriva vlastitu prisutnost na računalu, pritom obavljajući brojne druge aktivnosti: prikupljanje lozinki, brojeva 2

6 kreditnih kartica, mreţnog prometa (i njihovo slanje napadaču), korištenje računala za slanje neţeljene elektroničke pošte (engl. spam) i slično. Rootkit se moţe protumačiti i kao samo jedna komponenta zloćudnog programa - ona koja je zaduţena za skrivanje na računalu - dok ostatak zloćudnog programa obavlja prethodno navedene aktivnosti. Ovako definiran, rootkit moţe biti komponenta virusa, računalnog crva, trojanskog konja ili špijunskog programa, čime uzrokuje njihovu "nevidljivost" i dodatno povećava njihovu štetnost. Budući da rootkiti najčešće djeluju na razini jezgre operacijskog sustava (engl. kernel) i modifikacijama sustavskih podataka preuzimaju potpunu kontrolu nad sustavom, drugi način proučavanja rootkita (kao komponenta zloćudnog programa zaduţena za skrivanje) mnogo bolje opisuje samu bit rootkita, iako djelomice zasjenjuje opasnost koju on predstavlja ne razmatrajući "popratne aktivnosti" koje su uz rootkit uvijek prisutne. Kao i ostali zloćudni programi rootkiti su uglavnom platformski ovisni (o specifičnostima će biti više riječi u daljnjem tekstu): rootkit načinjen za jedan operacijski sustav neće funkcionirati ispravno u drugom operacijskom sustavu, ponekad ni na različitim verzijama iste porodice operacijskih sustava zbog razlika u njihovim jezgrama. Upravo zbog toga i tehnike prikrivanja ovise o vrsti operacijskog sustava, no općenito se mogu podijeliti u nekoliko kategorija: skrivanje procesa/dretvi unutar procesa, skrivanje direktorija/datoteka/ključeva u sustavskom registru, dijelova spremnika, mreţnog prometa i drugih objekata sustava. Često su tehnike skrivanja za različite kategorije programski vrlo slične. Veliki dio rada posvećen je upravo detaljnom opisu različitih tehnika skrivanja. 2.1 Povijest rootkita Povijest rootkita prikazana je na vremenskoj liniji na slici 2.1: Slika 2.1: Povijest i značajni događaji u razvoju rootkita 3

7 Iako je teško sa sigurnošću odrediti početak razvoja rootkita, prvim rootkitima mogu se smatrati čistači log datoteka u Linux operacijskom sustavu. Nakon što bi napadač na neki način zadobio kontrolu nad sustavom (u to vrijeme su najčešći razlozi upada napadača bili nepostojeće ili neadekvatno odabrane ili postavljene lozinke), svoju prisutnost bi sakrio brisanjem tragova koji su se sastojali od unosa u log datotekama. Brisanjem unosa u log datotekama efektivno se briše aktivnost napadača u računalu. Rootkit načinjen za SunOS v4 operacijski sustav moţe se smatrati prvim pravim rootkitom u današnjem smislu riječi: taj je rootkit skrivao tragove korisnika zamjenom programa za izlistavanje direktorija, datoteka i procesa u sustavu (naravno, uz brisanje log datoteka). Neoprezni administrator takvog računala ne bi uočio nikakve promjene u sustavu jer bi koristio modificirane verzije programa koje bi skrivale direktorije, datoteke i procese koje napadač ţeli sakriti. Sredinom devedesetih godina prošlog stoljeća počinju se intenzivno razvijati rootkiti za Linux operacijski sustav. Razvijen je čitav niz rootkita s različitom funkcionalnosti i različitom razinom djelovanja, iako većina djeluje na razini jezgre, bilo kao jezgrin modul (ekvivalent upravljačkom programu - driveru - u Windows operacijskom sustavu) ili modificiraju jezgru naprednim tehnikama pristupa [5]. Krajem devedesetih godina počinju se pojavljivati i rootkiti u Windows operacijskom sustavu. Ti rootkiti su najprije djelovali na korisničkoj razini - najpoznatiji takav "rootkit" je Back Orifice. Iako Back Orifice ima sve karakteristike trojanskog konja ili virusa, moţe se smatrati rootkitom jer je posjedovao odreďene mehanizme skrivanja prisutnosti na korisnikovom računalu. Unatoč tome što su djelovali na korisničkoj razini, takvi su alati bili vrlo moćni zbog inherentne nesigurnosti prvih inačica Windows operacijskog sustava (verzije Windows 95, 98 i ME). Popularizacija NT porodice Windows operacijskog sustava (verzije Windows 2000 i osobito Windows XP) dovele su do razvoja rootkita i za NT porodicu - prvi rootkit za Windowse koji radi u jezgrenom načinu rada bio je NT Rootkit. Sljedećih par godina u potpunosti je obiljeţeno intenzivnim razvojem rootkita za Windows operacijski sustav. Danas su dva osnovna trenda u razvoju zloćudnih programa distribuirana komunikacija izmeďu svih "klijenata" zaraţenih nekom vrstom zloćudnog programa (dakle, stvaranje velike mreţe zaraţenih računala koja komuniciraju distribuiranim načinom - botnet) i opremanje zloćudnog programa rootkit komponentom. Prema tvrtki PandaLabs, u godini uočen je porast broja zloćudnih programa koji sadrţavaju rootkit komponentu od 272% u odnosu na godinu [6]. Napadači su relativno brzo shvatili da su čak i rootkiti u jezgrinom načinu rada podloţni detekciji i "čišćenju zaraze" pa su svoj napor usmjerili prema razvoju rootkita koji se iznimno teško otkrivaju. Jedan smjer razvoja vodi prema rootkitima temeljenima na virtualizaciji, gdje je operacijski sustav samo gost unutar hipervizora kojeg predstavlja sam rootkit. TakoĎer, ponovno su se na scenu vratili i zloćudni programi koji se jednim svojim dijelom smještaju u prvi sektor tvrdog diska, pa su tako nastali MBR rootkiti. Drugi smjer razvoja vodi prema rootkitima koji svoje "utočište" pronalaze (barem djelomice) u sklopovlju - tako su nastali ACPI BIOS rootkiti i SMM rootkit koji će malo detaljnije biti objašnjeni u daljnjem tekstu. Vrlo je zanimljiv slučaj Rustock.C rootkita koji je otkriven u ljeto godine. Rustock.C drţi neslavan rekord - smatra se najduţe neotkrivenim zloćudnim programom u Windows operacijskom sustavu - ukupno je proţivio jednu i pol godinu 4

8 potpune anonimnosti tijekom koje ga nije otkrila niti jedna zaštitna aplikacija. Detaljna analiza moţe se pročitati na stranici [7]. Medijima i "neinformatičkoj populaciji" rootkiti takoďer nisu nepoznanica. Tvrtka Sony je godine na nosače zvuka i videa izvoďača koji izdaju pod njihovom etiketom počela stavljati zaštitu od neovlaštenog kopiranja [8]. Zaštita je funkcionirala tako da se bez znanja korisnika na njegovo računalo kopira upravljački program koji mijenja adrese nekih sistemskih poziva u jezgri operativnog sustava i nadgleda eventualne pokušaje kopiranja sadrţaja CD-a. Sony je sudskom nagodbom bio prisiljen povući inkriminirajuću tehnologiju, a naknadno i sve nosače zvuka i videa koji su tu tehnologiju koristili. Mnogo ozbiljniji slučaj dogodio se u proljeće godine kada je otkriven rootkit u sustavu atenskog mobilnog operatera i koji je neizravno doveo do smrti jednog od zaposlenika [9]. Radilo se o telekomunikacijskoj kompaniji Vodafone, najvećem telekomunikacijskom operateru u Grčkoj, u čijem je sustavu pronaďen rootkit koji je sve odabrane razgovore dodatno preusmjeravao na nepoznate brojeve. IzmeĎu ostalog, prisluškivani su bili mnogi ministri, pa čak i sam premijer. Rootkit je bio iznimno sofisticiran i zahtijevao je detaljno poznavanje sustava koji nije javno dostupan pa se sa velikom vjerojatnošću pretpostavlja da je rootkit postavio netko od zaposlenika. Brojevi na koje su se preusmjeravali prisluškivani razgovori nikad nisu otkriveni, kao ni počinitelji. Naţalost, prije samog otvaranja istrage, inţenjer elektrotehnike Costas Tsalikidis pronaďen je mrtav u svome stanu, a policija je zaključila da je riječ o samoubojstvu, iako sam slučaj nikada nije rasvijetljen. 2.2 Klasifikacija rootkita Općeprihvaćena klasifikacija rootkita zapravo i ne postoji, već se razlikuje od izvora do izvora. Najčešće se rootkiti dijele s obzirom na okruţenje u kojem djeluju i na vrijeme unutar kojeg su aktivni - jednu takvu klasifikaciju predloţio je kolega Nikola Ivković [10] te je na temelju te klasifikacije načinjena nešto opširnija na slici 2.2. Slika 2.2: Klasifikacija rootkita prema okruženju i vremenu aktivnosti 5

9 Rootkiti se općenito mogu podijeliti na postojane i nepostojane. Pritom se ne uzima u obzir konkretna platforma, tj. operacijski sustav, iako se radi jednostavnosti moţe pretpostaviti da se govori o rootkitima na x86 arhitekturi računala. Spremnički i sustavno postojani rootkiti su oni koji ostaju aktivni i nakon ponovnog pokretanja sustava. Nakon resetiranja, ponovnog uključivanja računala ili "buďenja" iz stanja hibernacije, rootkit nastavlja normalno djelovati kao i prije gašenja računala. Budući da takvi rootkiti moraju osigurati svoje ponovno pokretanje, mehanizmi koji im to omogućavaju mogu se nadzirati i na taj način ih je djelomice moguće otkriti. Ipak, autori rootkita konstantno razvijaju mehanizme ponovnog pokretanja kako bi izbjegli standardne metode detekcije. Ţivotni vijek nepostojanih rootkita jednak je vremenu unutar kojeg je računalo uključeno - gašenjem računala, odnosno ponovnim pokretanjem rootkit nestaje (iako sam izvorni tekst programa, odnosno ostali dijelovi rootkita mogu ostati prisutni u sustavu u neaktivnom stanju). Nepostojani rootkiti se mnogo teţe otkrivaju jer, za razliku od postojanih, ne moraju koristiti mehanizme za ponovno pokretanje koji mogu biti nadzirani. TakoĎer, naknadna pasivna (engl. offline) analiza sustava često neće pronaći nikakve tragove rootkita jer se on gašenjem računala deaktivirao i uklonio tragove svog postojanja (osim ako autor rootkita svojom nepaţnjom nije napravio pogrešku koja bi otkrila prisutnost alata u sustavu). Ipak, nepostojani rootkiti imaju potencijalno kratak ţivotni vijek: korisnička računala se u pravilu dosta često isključuju i ponovno uključuju (na posluţiteljskim računalima bi ţivotni vijek rootkita bio znatno duţi jer posluţitelji ostaju aktivni mjescima, čak i godinama). Zbog kratkog ţivotnog vijeka "razornost" i mogućnosti nepostojanih rootkita ponekad mogu biti manje od učinkovitosti postojanih. Iz slike 2.2 vidljivo je da i postojani i nepostojani rootkiti mogu biti vezani ili za spremnik ili za sklopovlje računala. Pod nazivom "spremnik" misli se na tvrdi disk, radni spremnik i u rjeďim slučajevima USB spremnički ureďaj i optičke diskove. Optički diskovi i prijenosni USB spremnički ureďaj su zbog svoje prenosivosti potencijalno zanimljivi za prenošenje zaraze, no nepraktični su sa stajališta okruţenja na kojem se rootkit nastanio i odakle se pokreće. Većina današnjih rootkita upravo su spremnički postojani ili nepostojani rootkiti vezani za spremnik i upravo će na njima biti teţište rada, uključujući i praktični dio. Kao što je spomenuto u povijesnom pregledu, sa stajališta okruţenja u kojem se izvode, rootkiti mogu biti vezani i za sklopovlje. Njihova vezanost za sklopovlje i neovisnost o operacijskom sustavu čini ih vrlo opasnima i nevidljivima. Primjer postojanog rootkita vezanog za sklopovlje je rootkit koji se ugraďuje u spremnik PCI ureďaja [11] ili rootkit koji je vezan za ACPI [12], dio BIOS-a (engl. Basic Input Output System) koji je zaduţen za kontrolu napajanja i snage i koji koristi vlastiti programski jezik AML (engl. ACPI Machine Language). Osnovna ideja takvih rootkita jest da svoj izvršivi program skrivaju u spremniku koji nije dio radnog spremnika računala - u ovom slučaju radi se o spremniku PCI ureďaja ili o ACPI tablicama. Budući da tradicionalni zaštitni alati ne provjeravaju dotična spremnička područja (razlog tome je najčešće teškoća same implementacije takvog sustava), rootkit uspješno izbjegava detekciju. U skupinu rootkita vezanih za sklopovlje moţemo ubrojiti i tzv. SMM rootkit [13]. SMM (engl. System Management Mode) je jedan od načina rada x86 porodice procesora koji se koristi za obavljanje operacija niske razine, vezanih uz hardver. 6

10 Sve aplikacije koje se izvode u SMM načinu rada imaju vlastiti spremnički prostor i okruţenje koje je gotovo u potpunosti nevidljivo od operacijskog sustava i ostalih programa koji se izvode izvan tog načina rada. Korištenjem SMM načina rada, rootkit je nevidljiv od strane operacijskog sustava i postojan je u spremniku. TakoĎer su vrlo zanimljivi i virtualizacijski rootkiti. Primjer postojanog rootkita temeljenog na virtualizaciji je SubVirt [14]. SubVirt se u ciljno računalo ugraďuje iznad (ili ispod, ako se promatra razina na kojoj rootkit djeluje i blizina sklopovlja prema rootkitu u odnosu na operacijski sustav korisnika) operacijskog sustava samog ciljnog računala. SubVirt djeluje kao nadglednik virtualnog stroja (engl. VMM - Virtual Machine Monitor) pri čemu je virtualni stroj upravo operacijski sustav ciljnog računala. Budući da u vezi "operacijski sustav - hardver" sada postoji još jedna karika (veza je oblika "operacijski sustav - VMM - hardver"), SubVirt moţe mijenjati informacije koje dobiva operacijski sustav ciljnog računala koji uopće ne vidi i nije svjestan postojanja tog dodatnog sloja. Osim za spremnik, virtualizacijski rootkiti mogu biti vezani i za sklopovlje. Primjer takvih alata su BluePill [15] i Vitriol [16]. Dotični ovise o virtualizacijskim načinima rada i naredbama samih procesora, a noviji procesori proizvoďača Intel i AMD nude takve naredbe i načine rada - AMD nudi AMD-V (engl. AMD-Virtualization), dok Intel nudi VT-x (engl. Virtualization Technology). Za razliku od SubVirt rootkita kod kojeg je VMM vrlo velik (nekoliko stotina megabajta), BluePill i Vitriol zahvaljujući virtualizacijskim načinima rada procesora imaju vrlo malen VMM - on se kod ovakvih rootkita naziva hipervizor. TakoĎer, BluePill i Vitriol pripadaju skupini nepostojanih alata, dok je SubVirt postojan. Iako su rootkiti vezani za skopovlje iznimno zanimljivi, sofisticirani i sloţeni, oni neće biti opisani u ovom radu, već je naglasak rada na "standardnim" spremnički postojanim i nepostojanim rootkitima (ne uzimajući u obzir virtualizacijske rootkite). Ovakva klasifikacija nije jedina, no dobro obuhvaća gotovo sve danas prisutne alate uzimajući u obzir njihove specifičnosti. Općenito na Intel x86 arhitekturi računala postoje ukupno četiri razine sigurnosti, odnosno privilegija pod kojima se neki program izvodi. Pojedine razine privilegija nazivaju se prsteni (engl. rings). Prsten koji je ekvivalentan jezgrinom načinu rada ima najveće privilegije i naziva se prsten 0 (engl. ring 0, ring zero). U originalnoj x86 specifikaciji sljedeća dva prstena - prsteni 1 i 2 - rezervirani su za upravljačke programe, npr. za upravljački program za grafičku karticu, mreţnu karticu, zvučnu karticu, itd. Najmanje privilegirani prsten, onaj u kojemu se nalaze sve korisničke aplikacije, nosi oznaku prsten 3. Konkretne realizacije originalne Intelove specifikacije razlikuju se u pojedinim operacijskim sustavima: u svim verzijama Windows operacijskog sustava koriste se samo prsten 0 i prsten 3, pri čemu prsten 0 označava jezgrin način rada (u njemu se izvodi sama jezgra sustava i svi upravljački programi), a prsten 3 označava korisnički način rada u kojemu se izvode korisničke aplikacije. Ista podjela prisutna je i u Linux operacijskom sustavu. Originalna x86 specifikacija prikazana je na slici

11 Slika 2.3: Razine privilegija i zaštite u x86 arhitekturi Rootkiti vezani za spremnik (i postojani i nepostojani) mogu se dakle podijeliti s obzirom na razinu na kojoj djeluju, što je prikazano na slici dolje. Slika 2.4: Podjela rootkita vezanih za spremnik s obzirom na razinu djelovanja 8

12 Rootkiti koji djeluju u korisničkom načinu rada ne mogu toliko efikasno sakriti prisutnost napadača u sustavu. Nemoguće je kontrolirati svaki aspekt sustava, na raspolaganju je ograničeni broj resursa, a jezgrini objekti (procesi, sustavske dretve, ureďaji, sinkronizacijski objekti i dr.) nisu direktno dostupni alatu. Zbog svega toga, takav rootkit je lakše otkriti i (što je mnogo vaţnije) odstraniti iz sustava. Njihova prednost je sadrţana u činjenici da je takve alate mnogo lakše napisati nego alate koji rade u jezgrinom načinu rada - to je ujedno i osnovni razlog zašto ovakva vrsta rootkita nije toliko rijetka. Mnogo više o rootkitima u korisničkom načinu rada moţe se pročitati u radu [17], prije svega o opasnosti koju oni predstavljaju, unatoč smanjenoj efikasnosti zbog relativno visoke razine djelovanja. Za razliku od rootkita u korisničkom načinu rada, rootkiti koji djeluju u jezgrinom načinu rada imaju na raspolaganju sve resurse računalnog sustava i napadač ima potpunu kontrolu nad operacijskim sustavom. Kako bi otkrili ovakve rootkite, antivirusni i drugi alati za otkrivanje zloćudnih programa moraju takoďer djelovati u jezgrinom načinu rada. Potrebno je naglasiti da su napadač i zaštitna aplikacija u tom slučaju u meďusobnom ravnopravnom položaju, što ne znači da će zaštitna aplikacija automatski otkriti rootkit i ukloniti ga iz sustava, već više označava mogućnost detekcije, pri čemu vještina napadača odnosno autora zaštitne aplikacije odreďuje konačan ishod. Posebnu skupinu čine rootkiti koji u osnovi djeluju u korisničkom načinu rada, no uspijevaju pristupiti jezgri bez korištenja upravljačkog programa. Općenito se to postiţe direktnim pristupom radnom spremniku, a time i dijelu spremnika koji zauzima jezgra. U suštini su ovakvi rootkiti vrlo bliski rootkitima koji djeluju u jezgrinom načinu rada. 2.3 Načini zaraze računalnog sustava rootkitom Budući da se u radu rootkit promatra kao komponenta zloćudnog programa zaduţena za prikrivanje prisutnosti napadača, proučavanje načina zaraze računalnog sustava rootkitom postaje zapravo proučavanje načina zaraze računalnog sustava bilo kojim zloćudnim programom. Postoje četiri osnovna načina zaraze računalnog sustava zloćudnim programom (načini zaraze poredani su pribliţno prema učestalostima pojavljivanja): iskorištavanje ranjivosti aplikacija socijalni inţenjering iskorištavanje ranjivosti operacijskog sustava fizički pristup Današnji programski sustavi izuzetno su sloţeni i bez obzira na odabir programskog jezika i platforme, čak i uz prisutnost formalnih dokaza točnosti, sadrţavat će veće ili manje pogreške. Ukoliko je namjena aplikacije interakcija s mreţom (npr. Internet preglednik ili klijent elektroničke pošte) ili aplikacija vrši bilo kakvu interakciju s 9

13 mreţom, vrlo je velika mogućnost da će napadač pokušati iskoristiti te pogreške kako bi dobio pristup sustavu. Nekada su najbrojnije ranjivosti bile vezane uz prepunjavanje meďuspremnika (engl. buffer overflow), odnosno prepunjavanje stoga (engl. stack overflow), no popularizacijom takvih napada i podizanjem svijesti o opasnosti koju predstavljaju, sve manje programera čini takve propuste. Tome je pridonio i razvoj novih programskih jezika poput programskog jezika Java i C# u kojima sam jezik štiti programera od takvih pogrešaka. Unatoč vrlo velikom broju ljudi koji konstantno unaprjeďuju svoje proizvode, u svakome od tri najpopularnija Internet preglednika (Internet Explorer, Mozilla Firefox i Opera) konstantno se pronalaze novi sigurnosni propusti koje napadači mogu iskoristiti.ranjivosti u Internet preglednicima su meďu najopasnijima jer ih koriste gotovo svi korisnici računala na svim platformama. Često je za sam proces zaraze dovoljna minimalna interakcija korisnika - posjet stranici koja sadrţava tzv. drive-by exploit. Exploit (hrvatski prijevod ovog termina ne postoji) je program koji ciljano iskorištava ranjivosti aplikacije ili operacijskog sustava u svrhu dobivanja pristupa (najčešće administratorskih privilegija) ili u svrhu namjernog rušenja sustava (napad uskraćivanjem usluga - engl. DoS, Denial of Service). Drive-by exploit moţe se definirati kao program ili odsječak programa koji je smješten na web stranici i koji obavlja zarazu svakog računala koje ju posjeti i ima verziju preglednika za koju je exploit načinjen. Antivirusni programi i zaštitne stijene u posljednje vrijeme sve više nastoje otkriti i spriječiti ovakav način zaraze praćenjem aktivnosti preglednika, no za sada s polovičnim uspjehom. Aplikacijska sigurnost odnosno ranjivost aplikacija obuhvaća i brojne druge aspekte, npr. korištenje zastarjelih kriptografskih algoritama (npr. DES algoritam) ili neadekvatno implementiranih kriptografskih algoritama, pogreške pri obradi bilo kakvih vrsta podataka koje priprema korisnik (od običnih datoteka, do SQL upita koji se zadaju bazi podataka) i slično. Korisnici bi sve aplikacije koje imaju interakciju s mreţom, ma koliko ona mala bila, trebali drţati što je moguće aţurnijima jer je velika vjerojatnost da su u novoj verziji programa ispravljeni mnogi sigurnosni propusti iz prethodne. Donedavno dominantna metoda zaraze računalnog sustava zloćudnim programom bio je socijalni inženjering. Socijalni inţenjering moţe se definirati kao "metoda ugroţavanja sigurnosti informacijskih sustava koja se koncentrira na manipuliranje ljudima unutar sustava kako bi se od njih dobile povjerljive informacije potrebne za neovlašteno korištenje resursa informacijskog sustava" [18]. Ova se tehnika temelji na laţnom predstavljanju napadača ili na prikrivanju prave namjene zloćudnog programa. Korisnici obično putem poruke elektroničke pošte dobivaju privitak koji sadrţi maliciozni program, no sama poruka sugerira da se radi o korisnom i za korisnika "primamljivom" sadrţaju. TakoĎer, korisnika se porukom moţe potaknuti da otvori (zaraţenu) web stranicu koja sadrţava prije spomenuti drive-by exploit ili zahtijeva od korisnika da skine dodatni program potreban za pregledavanje stranice, koji je naravno zaraţen. Iako i dalje prisutan, ovakav način zaraze više nije toliko učinkovit kao prije, ponajviše zbog povećanja svijesti ljudi o opasnostima neţeljenih i sumnjivih poruka elektroničke pošte, ali i korištenja antivirusnih programa s ažuriranim virusnim definicijama. 10

14 Ako se razmatranja o aplikacijskoj sigurnosti i ranjivostima primijene na operacijski sustav koji se pojednostavljeno moţe shvatiti kao najsloţeniji program koji korisnik koristi na računalu, onda je razumljivo očekivati da operacijski sustav ima vrlo veliki broj propusta i ranjivosti. Windows porodica operacijskih sustava često se spominje u negativnom kontekstu kada se govori o računalnoj sigurnosti. Operacijski sustavi bez ikakve sigurnosti (Windows 95, Windows 98 i Windows Millenium Edition) i veliki sigurnosni propusti (ponajprije propusti u Internet Exploreru i IIS - Internet Information Services web posluţitelju) osnovni su razlog zašto se često o sigurnosti Microsoftovih proizvoda govori s podsmjehom. Ipak, brojne sigurnosne incijative unutar same kompanije, prije svega ciklus razvoja s naglaskom na sigurnost (engl. Security development lifecycle) [19], učinili su bivše i sadašnje Microsoftove proizvode mnogo sigurnijima nego ranije i uz znatno veći naglasak na sigurnost. Svaka nova inačica operacijskog sustava tvrtke Microsoft donosi sve veća poboljšanja sigurnosti, tako da se ranjivosti u operacijskim sustavima sve teţe otkrivaju - to je ujedno i osnovni razlog koncentriranja napadača na aplikacijske ranjivosti i smanjena (iako ne i ugašena) potraga za ranjivostima operacijskog sustava. MeĎutim, vrlo je vaţno spomenuti da se napadači i tehnike koje oni koriste razvijaju uvijek u jednom smjeru - napadi nikada ne postaju lošiji, već samo sofisticiraniji. Unatoč znatnim naporima razvojnih timova, i dalje se otkrivaju ranjivosti u operacijskim sustavima: početak godine obiljeţila je epidemija Conficker (Downadup) crva koji je zarazio desetke milijuna računala s Windows operacijskim sustavom. Conficker crv je za svoje širenje koristio propust [20] u samom operacijskom sustavu, a čak je i Windows 7 (operacijski sustav koji u trenutku pisanja ovog rada još uvijek nije dostupan na trţištu) bio ranjiv. Taj je propust vrlo dobar pokazatelj činjenice da se nikada u potpunosti ne moţe vjerovati u sigurnost i neranjivost sustava, bez obzira na korištenje preporučenih sigurnosnih politika i na aţurnost primjene sigurnosnih zakrpa. Ipak, sigurnosne zaštitne stijene i antivirusni programi mogu spriječiti iskorištavanje ranjivosti u pojedinim slučajevima (osobito ako imaju neki oblik proaktivne zaštite) pa ovdje imaju gotovo odlučujuću ulogu u osiguravanju integriteta i sigurnosti sustava. Kao posljednji način zaraze računalnog sustava zloćudnim programom naveden je fizički pristup. Takva vrsta napada predstavlja fizičku prisutnost napadača uz računalni sustav, najčešće bez nadzora korisnika. Općenito, ako napadač ima fizički pristup računalu, vjerojatnost da računalni sustav ostane siguran vrlo su male - fizički pristup je najveća razina pristupa koju napadač moţe imati jer uspješnost napada ovisi prije svega o vremenu kojeg napadač ima na raspolaganju, kao i o sposobnostima samog napadača. Antivirusni programi i sigurnosne zaštitne stijene su u ovom slučaju najčešće beskorisni, kao i ostale zaštite na aplikacijskoj razini jer napadač (ovisno o raspoloţivom vremenu) moţe modificirati operacijski sustav čak i prije njegovog pokretanja. Napadača se moţe usporiti lozinkama postavljenima na BIOS, ponekad i zaključavanjem cijelog tvrdog diska ili sustavske particije dok se ne upiše lozinka, no i dalje je sustav u slučaju fizičkog pristupa vrlo ranjiv. Ovaj način napada prisutan je oduvijek, no popularizacijom prijenosnih računala, slučajevi zaraze ovim putem sve su češći. Jedan od načina na koji napadač s fizičkim pristupom moţe kompromitirati sigurnost sustava je sljedeći: na Internetu su dostupne brojne "ţive" (engl. live) distribucije Linux operacijskog sustava (ili nekog drugog operacijskog sustava) koje se mogu 11

15 pokrenuti prilikom podizanja sustava i imaju sposobnost mijenjanja Windows lozinki i sustavskog registra. Primjer takve distribucije je Offline NT Password & Registry Editor [21]. Korištenjem te distribucije vrlo je jednostavno modifikacirati sustavski registar u Windows operacijskom sustavu dok operacijski sustav uopće nije ni pokrenut. U svrhu demonstracije opasnosti napravljena je snimka modifikacije sustavskog registra pomoću dotične distribucije 1. Najprije je napravljena vrlo jednostavna batch skripta koja samo ispisuje tekst "Hello world" na zaslon računala. U odgovarajućem kazalu sustavskog registra trenutno nije prisutan niti jedan program koji se pokreće nakon prijave korisnika na sustav. Korištenjem navedene distribucije se vrlo brzo, u svega dvije minute, dodaje skripta u listu programa koji se pokreću prilikom pokretanja samog sustava, nakon prijave korisnika. Pokretanje skripte vidljivo je i nakon ponovnog pokretanja sustava. Umjesto programa Notepad mogao se pokrenuti bilo koji zloćudni program. Od napada fizičkim pristupom korisnici se teško mogu obraniti, no postavljene BIOS lozinke, zaključavanje i enkripcija kompletnog tvrdog diska, onemogućavanje pisanja po prvom sektoru diska i onemogućavanje podizanja računala s vanjskih spremnika svakako će usporiti napadača. Zaključavanje i enkripcija tvrdog diska pritom su vrlo dobra zaštita. Prvi korak pri potpunom preuzimanju sustava od strane napadača često je pridobivanje administratorskih privilegija. Ne zahtijevaju svi zloćudni programi nuţno administratorske privilegije, no svi rootkiti koji djeluju u jezgrinom načinu rada za svoju ugradnju u sustav moraju imati administratorske dozvole. Administratorski korisnički račun je korisnički račun s najvišim privilegijama - pomoću njega (i najčešće jedino pomoću njega) je moguće ugraditi upravljački program u jezgru sustava, a ugradnjom upravljačkog programa moguća je kompletna kontrola nad svim dijelovima sustava. Jasno je da se pod svaku cijenu napadača mora spriječiti u dobivanju administratorskih privilegija jer jednom kada su privilegije pridobivene kompromitacija cjelokupnog sustava postaje vrlo vjerojatna, a proces otklanjanja zaraze vrlo sloţen, ponekad i nemoguć. Linux operacijski sustav ima vrlo dobro definiranu odvojenost pojedinih korisničkih računa, kao i kompletnu (poprilično restriktivnu) sigurnosnu politiku korištenja tih korisničkih računa. U Windows operacijskom sustavu separacija korisničkih računa nije toliko jasno definirana i korisnika se "ne prisiljava" da za svakodnevne poslove koristi ograničeni korisnički račun - štoviše, računi dodani prilikom instalacije sustava imaju administratorske privilegije za Windows 2000 i XP. U operacijskim sustavima Windows Vista i Windows 7 u slučaju standardnih postavki koristi se ograničeni korisnički račun, a za sve radnje "većeg rizika" poput ugradnje upravljačkih programa ili korištenja administratorskih alata potreban je eksplicitni unos administratorske lozinke (Vista) ili samo potvrda akcije (Windows 7). Sam mehanizam nazvan je UAC (engl. User Account Control). 1 Primjer ureďivanja sustavskog registra pomoću posebnog "boot" CD-a - watch?v=um_eugn4u0w 12

16 Naţalost, korisnici u velikoj mjeri ne shvaćaju opasnosti koje proizlaze iz korištenja privilegiranih korisničkih računa kao što je administratorski korisnički račun. Anketa provedena prošle godine meďu kolegama FERa i ostalih studenata Sveučilišta pokazala je zabrinjavajuće rezultate o korištenim korisničkim računima. Na slici 2.5 prikazana je raspodijeljenost korisničkih računa kod običnih korisnika. 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 96% 2% 2% 0% Administrator Power User User Ostalo Slika 2.5: Raspodijeljenost korisničkih računa kod običnih korisnika Raspodijeljenost korisničkih računa u poslovnom okruţenju prikazana je na slici 2.6. Kao uzorak za poslovno okruţenje odabrani su većinom zaposlenici jedne kompanije koja se bavi IT djelatnošću. 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 43,48% 43,48% 13,04% 0,00% Administrator Power User User Ostalo Slika 2.6: Raspodijeljenost korisničkih računa u poslovnom okruženju Unatoč malom ispitnom uzorku, rezultati ankete daju zadovoljavajući uvid u stvarnu situaciju raspodjele korisničkih računa u Windows operacijskom sustavu. U skupini od 45 ispitanika, njih 45 koristi administratorske račune, s time da neki povremeno koriste i nešto ograničenije račune u svakodnevnom radu. U poslovnom okruţenju, 13

17 od ukupno 23 ispitanika, 10 ispitanika koristi administratorski račun u svakodnevnom radu, 10 ih koristi račun naprednog korisnika (engl. Power User), a postoje samo 3 obična korisnika s ograničenim privilegijama. Unatoč agresivnijem pristupu Microsofta u novijim inačicama Windows operacijskog sustava i nametanju korištenja ograničenih korisničkih računa, obični korisnici UAC i ostale mehanizme doţivljavaju prije svega kao smetnju, a ne kao zaštitu i vrlo brzo ih isključuju. Rješenje tog problema vrlo je teško, moţda i teţe od eliminacije sigurnosnih propusta u operacijskom sustavu i aplikacijama jer obuhvaća mijenjanje navika korisnika i njihovu edukaciju. Korisnici su danas mnogo svjesniji opasnosti i vaţnosti računalne sigurnosti nego što su bili prije desetak godina, no antivirusni alati i sigurnosne zaštitne stijene često pruţaju laţnu sigurnost, a mistificiranje računalne sigurnosti i napadača te nedostatak temeljne edukacije razlog su za zabrinutost. Needucirani korisnik nije prijetnja samo sebi odnosno vlastitom računalu, već i organizaciji u kojoj radi i upravo je zbog toga edukacija o računalnoj sigurnosti vrlo vaţna. Korištenje administratorskih privilegija za svakodnevni rad vrlo je opasno, analogno ostavljanju otvorenih kućnih vrata i prozora u opasnoj četvrti - nije pitanje hoće li netko to iskoristiti, već kada će se to dogoditi. 14

18 3. Načini djelovanja rootkita U nastavku rada opisani su prije svega rootkiti u Windows operacijskom sustavu. Slučajevi u kojima se neki mehanizam djelovanja moţe primijeniti i na ostale operacijske sustave bit će posebno istaknuti u tekstu. TakoĎer, posebno će se naglasiti situacije kada se neki mehanizam rootkita ne moţe primijeniti na pojedine verzije Windows operacijskog sustava. Podrazumijevani operacijski sustav kada drugačije nije navedeno je 32-bitna inačica Windows XP operacijskog sustava, iako se većina tehnika moţe primijeniti i na Vistu i vrlo vjerojatno i na Windows 7. Vaţno je naglasiti da 64-bitne inačice operacijskih sustava nisu razmatrane, zbog brojnih sigurnosnih specifičnosti jezgre o kojima će biti riječi u daljnjem tekstu. Radi preglednosti, paralelno opisima djelovanja rootkita i mehanizmima skrivanja objekata operacijskog sustava, bit će dani načini otkrivanja tih objekata i sprječavanja rootkita da obave svoj posao. 3.1 Ugradnja rootkita u računalo U posebnom poglavlju razmatrani su načini (djelomice i uzroci) zaraze računalnog sustava rootkitom, no potrebno je nešto detaljnije proučiti uobičajeni postupak ugradnje rootkita, odnosno bilo kojeg zloćudnog programa u sustav. Iako se zloćudni programi meďusobno razlikuju, postupak njihove ugradnje u sustav uvijek se sastoji od nekoliko faza koje su često gotovo identične. Neka je zloćudni program (spremnički i sustavno postojan) prisutan na računalu kao izvršna datoteka koja još nije pokrenuta i neka korisnik koristi administratorski korisnički račun (što nije nerealna pretpostavka, sudeći prema prethodnom poglavlju). Pojedina stanja prilikom ugradnje zloćudnog programa prikazana su na slici 3.1. Sama izvršna datoteka zloćudnog programa gotovo uvijek je "zaštićena" - izvorni ili izvršivi tekst programa enkriptiran je ili saţet (kompresiran) ili namjerno nerazumljiv (engl. obfuscated code). Cilj takve zaštite je oteţavanje otkrivanja prijetnje za antiviruse i druge zaštitne alate, ali i oteţavanje analize samog zloćudnog programa od strane sigurnosnog stručnjaka. Ovakvu vrstu zaštite izvornih datoteka ne koriste samo autori zloćudnih programa već se ona vrlo često koristi u računalnim igrama i velikim programskim sustavima u svrhu sprječavanja neovlaštenog analiziranja i eventualnog kopiranja koda (engl. code disassembling). Zaštite koje su danas u upotrebi iznimno su sofisticirane i potrebna je znatna sposobnost da ih se zaobiďe i ukloni. Jasno je meďutim da se takav "izmijenjeni" izvorni tekst programa ne moţe sam po sebi izvoditi na procesoru, već ga je potrebno pretvoriti u oblik koji procesor razumije. U slučaju jednostavne zaštite, izvoďenje programa zapravo započinje s petljom za dekripciju ili otpakiravanje (dekompresiju) koja početni enkriptirani ili saţeti izvršivi program pretvara u izvršivi program u razumljivom obliku i smješta u unaprijed zauzeti prostor u spremniku. Nakon što petlja završi, izvoďenje se nastavlja od prve naredbe tog spremljenog programa u spremniku. Sloţene zaštite imaju brojne dodatne slojeve sigurnosti pa nikad ne smještaju kompletan program u spremnik (jer 15

19 on tada postaje "dostupan" svima - sigurnosnim aplikacijama i stručnjacima koji vrše analizu), već vrše dekripciju ili dekompresiju po dijelovima programa. TakoĎer, imaju brojne zaštitne mehanizme koji detektiraju prisutnost "programa za traţenje pogrešaka" ili debuggera kojima sigurnosni stručnjaci pokušavaju shvatiti način djelovanja programa. Samo područje zaštite aplikacija od neovlaštenog analiziranja iznimno je zanimljivo i vrlo dinamično, no daleko izvan opsega ovog rada. Slika 3.1: Ugradnja zloćudnog programa u računalo po stupnjevima (fazama) Na slici se pretpostavlja da je korištena jednostavna zaštita i da se cijeli zloćudni program u "otpakiranom" obliku smješta u spremnik. Sljedeći korak je stvaranje novih datoteka. Sam zloćudni program u svojoj izvršnoj datoteci sadrţi zapravo izvršive programe više datoteka - najčešće se radi o izvršivom tekstu upravljačkog programa i izvršivom tekstu DLL datoteke. Razlog stvaranja višestrukih datoteka je dvojak: sam zloćudni program ne moţe sam sebe ugraditi u jezgru sustava (točnije, moţe, no takav korak bio bi nepotrebno oteţavanje zaraze) pa zbog toga stvara datoteku koja predstavlja upravljački program i koju ugraďuje u jezgru sustava. Drugi razlog je što se nakon pokretanja zloćudnog programa originalna datoteka samog zloćudnog programa briše, što je prikazano u koraku 4. Izvršnu datoteku pokrenutog programa u Windows operacijskom sustavu sam operacijski sustav "zaključava" za pisanje pa program ne moţe izbrisati sam sebe (postoje tehnike i za to, no poprilično su nestabilne) - mnogo jednostavnije je da zloćudni program na disk smjesti tzv. batch skriptu s izvornim tekstom programa koji vrši brisanje originalnog zloćudnog programa kao i same batch skripte (batch skripta 16

20 predstavlja samo naredbe komandne linije i nije klasičan program pa zbog toga moţe izbrisati sama sebe). Na taj način napadač dodatno uklanja tragove postojanja zaraze. Osim stvaranja datoteke upravljačkog programa, zloćudni program stvara i DLL datoteku. DLL datoteka predstavlja korisnički dio zloćudnog programa, dok upravljački program predstavlja dio zloćudnog programa u jezgri. Slanje lozinki i brojeva kreditnih kartica obavlja se upravo preko korisničkog dijela zloćudnog programa, dok upravljački program (sama rootkit komponenta) skriva mreţni promet i općenito prisutnost zaraze. DLL datoteka se sama po sebi ne moţe pokrenuti, već ju je potrebno "ubaciti" u neki drugi, najčešće legitiman program. Zloćudni programi to najčešće rade na način da najprije u adresnom prostoru drugog procesa zapišu izvršivi tekst programa pozivom funkcija VirtualAllocEx() i WriteProcessMemory() koji će u proces uključiti zloćudnu DLL datoteku, a zatim stvaraju udaljenu dretvu u legitimnom programu pozivom funkcije CreateRemoteThread() pri čemu novostvorena dretva pokreće upisani izvršivi tekst programa i uključuje zloćudnu DLL datoteku u adresni prostor procesa. U svrhu demonstracije, na slici 3.2 prikazano je ubacivanje DLL datoteke u adresni prostor calc.exe procesa (Windows kalkulator), pri čemu izvorni tekst DLL datoteke prikazan na slici 3.3 ispisuje poruku na zaslon. // puna putanja do DLL datoteke koja se ubacuje (radi jednostavnosti ovdje fiksna) TCHAR *szdllname = TEXT("C:\\inject.dll"); // pronađi prozor kalkulatora HWND hcalcwindow = FindWindow(TEXT("SciCalc"), TEXT("Calculator")); if(hcalcwindow == NULL) { return 1; } // dohvati PID calc.exe procesa DWORD dwcalcpid = 0; GetWindowThreadProcessId(hCalcWindow, &dwcalcpid); // otvori ručicu prema calc.exe procesu uz potrebne dozvole HANDLE hprocess = OpenProcess(PROCESS_VM_WRITE PROCESS_VM_OPERATION PROCESS_CREATE_THREAD PROCESS_QUERY_INFORMATION PROCESS_VM_READ, FALSE, dwcalcpid ); if(hprocess == NULL) { return 1; } // alociraj memoriju u adresnom prostoru calc.exe procesa potrebnu za smještanje // imena DLL datoteke koja će se uključiti u proces PVOID paddress = VirtualAllocEx(hProcess, NULL, strlen(szdllname), MEM_RESERVE MEM_COMMIT, PAGE_READWRITE ); if(paddress == NULL) { 17

21 return 1; } // zapiši ime DLL datoteke u adresni prostor calc.exe procesa na prethodno // dobavljenu adresu if(!writeprocessmemory(hprocess, paddress, (PVOID) szdllname, strlen(szdllname), NULL ) ) { return 1; } // dohvati ručicu na kernel32.dll modul koji sadržava LoadLibrary metodu HMODULE hmodule = GetModuleHandle(TEXT("kernel32")); // dohvati adresu LoadLibrary metode - u svim aplikacijama koje imaju uključenu // kernel32.dll biblioteku, ova je adresa ista FARPROC ploadlibrary = GetProcAddress(hModule, TEXT("LoadLibraryA")); // stvori udaljenu dretvu u calc.exe procesu koja će putem LoadLibrary metode // uključiti inject.dll datoteku u adresni prostor CreateRemoteThread(hProcess, NULL, 0, (PTHREAD_START_ROUTINE) ploadlibrary, (PTCHAR) paddress, 0, NULL ); Slika 3.2: Stvaranje udaljene dretve u calc.exe procesu BOOL APIENTRY DllMain(HINSTANCE hinstance, DWORD ul_reason_for_call, LPVOID lpreserved) { TCHAR szmsg[512]; switch(ul_reason_for_call) { case DLL_PROCESS_ATTACH: // sastavi poruku za ispis na zaslon - ispisujemo PID sprintf_s(szmsg, 512, "Pozdrav iz kalkulatora, moj PID je %d", GetProcessId(GetCurrentProcess())); } // ispisi poruku na zaslon MessageBox(NULL, szmsg, TEXT("Poruka iz kalkulatora"), MB_OK); break; case DLL_PROCESS_DETACH: break; } return TRUE; Slika 3.3: Ulazna metoda inject.dll datoteke Prikazani izvorni tekst programa je demonstracijski i ne vodi se računa o greškama koje se pritom mogu pojaviti. Jasno je da je umjesto jednostavne poruke na zaslonu inject.dll datoteka mogla obavljati bilo kakvu zloćudnu radnju u kontekstu bilo kojeg 18

22 procesa u koji se ubacila, a ne samo calc.exe procesa. Rezultat izvoďenja programa prikazan je na slici 3.4. Sami primjeri vrlo su jasni i ne zahtijevaju dodatna objašnjenja. Slika 3.4: Rezultat ubacivanja inject.dll datoteke u calc.exe proces 3.2 Općeniti načini skrivanja objekata operacijskog sustava i načini otkrivanja modifikacija Bez obzira na platformu na kojoj djeluju i bez obzira na objekt koji pokušavaju sakriti, rootkiti obavljaju skrivanje na način da funkcije operacijskog sustava koje se koriste za pregled tih objekata "prevare" i uklone objekt iz liste objekata koju funkcija vraća odnosno "vidi". Osim tog mehanizma, rootkiti mogu "prevariti" i korisnika funkcije i ostaviti ga u uvjerenju da koristi ispravnu verziju funkcije, dok se zapravo koristi verzija koju je modificirao rootkit. Primjerice, ako aplikacija za pregled procesa operacijskog sustava koristi zamišljenu funkciju DohvatiListuProcesa() koja vraća listu procesa, rootkit moţe ukloniti proces koji ţeli sakriti na dva načina - stvarnim uklanjanjem objekta iz liste, na vrlo niskoj razini u jezgri operacijskog sustava (dakle promjenom same strukture podataka), ili zamjenom funkcije DohvatiListuProcesa() nekom vlastitom funkcijom (promjenom adrese funkcije). Druga metoda je znatno jednostavnija pa će biti opisana prije sloţenije. Prvo pitanje koje napadač prirodno postavlja jest kako pronaći funkcije koje aplikacija koristi kako bi doznala podatke o procesima u sustavu. TakoĎer, kako promijeniti te funkcije jednom kada ih se pronaďe? Korisnički način rada Načini na koje rootkiti u korisničkom načinu rada skrivaju procese i datoteke objašnjeni su u radu [17] pa će naglasak biti na rootkite koji djeluju u jezgrinom načinu rada. Ipak, potrebno je razumijeti osnovne koncepte djelovanja rootkita u 19

23 korisničkom načinu rada jer se mnogi mehanizmi skrivanja (ne samo procesa, već i ostalih objekata sustava) mogu preslikati i u jezgru. Niti jedna korisnička aplikacija u Windows operacijskom sustavu nije samostalna i potpuno izolirana cjelina, već sa sustavom, odnosno jezgrom, komunicira pozivajući API funkcije koje pruţaju DLL biblioteke. S tim DLL bibliotekama aplikacije se povezuju implicitno (za vrijeme prevoďenja izvornog u izvršivi tekst programa) ili eksplicitno (za vrijeme rada). Pojednostavljena interakcija pojedinih elemenata sustava prikazana je na slici 3.5 koja se temelji na [22]. Slika 3.5: Pojednostavljena arhitektura Windows operacijskog sustava Način na koji korisničke aplikacije pozivaju metode iz DLL biblioteka definiran je standardom, a za njegovo razumijevanje potrebno je dobro vladanje strukturom svake izvršne datoteke u Windows operacijskom sustavu, tzv. PE formatom (engl. Portable Executable). Više o PE formatu moţe se doznati u bibliografiji [17], kao i iz slike razvijene za isti rad i prisutne na Internet stranici. Sve strukture koje se navode u nastavku najbolje je pratiti putem navedene slike (sama slika je prevelika za smještanje u rad pa zbog toga dolazi odvojeno). Kao primjer moţe se uzeti Task Manager aplikacija koja informacije o procesima dobiva pozivom metode NtQuerySystemInformation() koju pruţa, odnosno izvozi (engl. export) DLL datoteka ntdll.dll. Metode koje pruţa ntdll.dll datoteka su takozvane native metode i predstavljaju tanak omotač (engl. wrapper) oko poziva jezgrinih metoda - točnije, većina ntdll.dll metoda ima unaprijed definiranu strukturu 20

24 koja vrši prijelaz iz korisničkog načina rada u jezgrin i pozivanje jezgrine metode koja obavlja stvarni posao. Metode iz ntdll.dll datoteke najčešće nisu dokumentirane i nisu namijenjene izravnom pozivanju, već ih pozivaju metode iz ostalih DLL datoteka koje su u potpunosti dokumentirane i namijenjene korisniku. Primjerice, korištenjem dokumentiranih metoda Process32First() i Process32Next() iz kernel32.dll datoteke takoďer se mogu dobiti svi procesi u sustavu, iako uz nešto manje informacija. Unatoč tome, Task Manager aplikacija koristi nedokumentiranu (točnije, poludokumentiranu) metodu kako bi obavila svoju zadaću. Dok program još nije pozvan, na odreďenim mjestima u izvršivom tekstu Task Manager aplikacije postoje pozivi metode NtQuerySystemInformation() - postavlja se pitanje na koji se način ta metoda moţe pozivati kada njezina adresa tada još nije poznata, budući da se metoda nalazi u ntdll.dll datoteci. Prilikom pokretanja programa, windows "punitelj" (engl. loader) ima zadaću ispraviti sve adrese u izvršivom tekstu aplikacije koje se odnose na funkcije iz DLL datoteka. Budući da takvih mjesta u izvšivom tekstu čak i minimalnih aplikacija ima vrlo mnogo, a prolaţenje kroz sam izvršivi tekst bilo bi vrlo dugotrajno i teško, svi pozivi DLL funkcija u izvršivom tekstu nisu zapravo izravni pozivi, već najčešće bezuvjetni skokovi na posebni odjeljak u adresnom prostoru aplikacije. Taj posebni odjeljak naziva se IAT - Import Address Table, tablica uvoznih adresa. Paralelno uz IAT postoji i INT - Import Name Table, tablica uvoza po imenu koja sadrţi imena uvezenih funkcija. Iako u samom nazivu kratice IAT postoji engleska riječ za tablicu, bit će korišten termin IAT tablica radi jednostavnijih konstrukcija na hrvatskom jeziku. Isto će vrijediti i za ostale slične kratice. Prilikom učitavanja aplikacije, Windows punitelj najprije pronalazi DataDirectory[1] strukturu koja pokazuje na polje IMAGE_IMPORT_DESCRIPTOR struktura, pri čemu svaki element polja označava jednu DLL datoteku iz koje se uvoze pojedine funkcije. Punitelj za svaki element polja najprije ispituje je li DLL datoteka odreďena IMAGE_IMPORT_DESCRIPTOR strukturom već učitana u spremnik i ako nije, obavlja učitavanje (rekurzivno se ponavlja postupak koji se ovdje opisuje). Ako je DLL datoteka učitana, punitelj pronalazi tablicu uvoznih adresa (polje IMAGE_THUNK_DATA struktura, po jedna struktura za svaku funkciju koja se uvozi) i mijenja polje Function u stvarnu adresu u spremniku dotične uvezene funkcije. Na taj način, kada Task Manager aplikacija poziva funkciju NtQuerySystemInformation(), zapravo se poziva adresa navedena u Function polju odgovarajuće IMAGE_THUNK_DATA strukture, a Windows punitelj u to polje zapisuje pravu adresu funkcije prilikom pokretanja. To je prikazano na slici 3.6. Slika 3.6: Poziv funkcije NtQuerySystemInformation() u Task Manager aplikaciji 21

25 Sve što napadač treba napraviti jest pretraţiti IAT tablicu ţeljene aplikacije i (u kombinaciji s INT tablicom, kako bi pronašao odgovarajuću funkciju) zamijeniti stvarnu adresu s adresom vlastite, "rootkit" funkcije. Rootkit funkcija pritom nužno mora biti u adresnom prostoru procesa - najčešće je prisutna u obliku DLL datoteke ubačene u aplikaciju udaljenom dretvom. Primjer modifikacije IAT tablice zajedno s izvornim tekstom moguće je pronaći u radu [17]. Shematski prikaz pozivanja NtQuerySystemInformation() metode u Task Manager aplikaciji prikazan je na slici 3.7: Slika 3.7: Shematski prikaz "otimanja" NtQuerySystemInformation() metode Jedan od načina otkrivanja modifikacija IAT tablice (i brojnih drugih modifikacija) koji nije često korišten jest upotreba WinDBG debuggera [23] tvrtke Microsoft. WinDBG debugger iznimno je moćan alat koji je neophodan za razvijanje upravljačkih programa za Windows operacijski sustav, traţenje pogrešaka u običnim aplikacijama, neizostavna pomoć pri proučavanju nedokumentiranih struktura operacijskog sustava, no često moţe pomoći i u otkrivanju rootkita. Debugger ima svoj naredbeni redak koji kao unos prima brojne naredbe koje se mogu proučiti u sluţbenoj dokumentaciji. Prvi korak je povezivanje s Task Manager aplikacijom, što se postiţe pritiskom na tipku F6 i odabirom taskmgr.exe procesa. Drugi korak je pronalaţenje tablice uvoznih adresa - IAT tablice u adresnom prostoru procesa. To se postiţe naredbom!dh (engl. display headers) koja prikazuje kompletno zaglavlje PE datoteke taskmgr.exe i ispisuje adrese pojedinih struktura: 22

26 0:000>!dh taskmgr File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (i386) 3 number of sections 41107C91 time date stamp Wed Aug 04 08:05: [ 0] address [size] of Export Directory [ F0] address [size] of Import Directory [ C6D0] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 0 [ 0] address [size] of Base Relocation Directory 1470 [ 1C] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 25E0 [ 40] address [size] of Load Configuration Directory 248 [ EC] address [size] of Bound Import Directory 1000 [ 464] address [size] of Import Address Table Directory 134A8 [ C0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory SECTION HEADER #1.text name 13EEE virtual size 1000 virtual address size of raw data 400 file pointer to raw data Slika 3.8: Ispis zaglavlja Task manager procesa i adresa IAT tablice Iz slike 3.8 vidljivo je da se IAT tablica nalazi 0x1000 okteta dalje od početka procesa u spremniku (sve adrese su relativne virtualne adrese), dok je njezina veličina 0x464 okteta. Za ispis sadrţaja tablice u pogodnom formatu u kojem se odmah mogu prepoznati pojedine uvezene metode, moţe se koristiti naredba dps (engl. display pointer-sized values with symbols) koja prikazuje sve vrijednosti u navedenom adresnom opsegu kao pokazivače, povezujući ih s debug simbolima, odnosno koristeći ispravna "imena" tih spremničkih lokacija. U ovom slučaju to znači da će biti prikazana imena svih funkcija u IAT tablici zajedno s njihovim adresama. Prije bilo kakvih modifikacija, izgled IAT tablice je sljedeći: 0:000> dps taskmgr+1000 l464/ e1a3b4 ADVAPI32!RegCloseKey e1d53a ADVAPI32!RegQueryValueExW e1a95d ADVAPI32!RegOpenKeyExW c90253a ntdll!memmove c90e1aa ntdll!zwquerysysteminformation c90de62 ntdll!ntpowerinformation c 7c9622ed ntdll!rtltimetoelapsedtimefields Slika 3.9: IAT tablica Task Manager aplikacije prije modifikacija 23

27 Iz slike je vidljivo da je metoda NtQuerySystemInformation() smještena na indeksu 275 u IAT tablici ( (ZwQuerySystemInformation() je istoimena metoda, u korisničkom načinu rada pokazuje na istu adresu kao i Nt* verzija. Razlika postoji samo u jezgrinom načinu rada i bit će spomenuta kasnije). Nakon modifikacije situacija je sljedeća: 0:000> dps taskmgr+1000 l464/ e1a3b4 ADVAPI32!RegCloseKey e1d53a ADVAPI32!RegQueryValueExW e1a95d ADVAPI32!RegOpenKeyExW c90253a ntdll!memmove IATMethod+0x c90de62 ntdll!ntpowerinformation c 7c9622ed ntdll!rtltimetoelapsedtimefields Slika 3.10: IAT tablica Task Manager aplikacije nakon modifikacija Na gornjoj slici vidljivo je da je element IAT tablice s indeksom 275 promijenjen te da umjesto NtQuerySystemInformation() metode, vodi na nepoznatu metodu unutar IATMethod.dll datoteke. Popravak upotrebom WinDBG debuggera vrlo je jednostavan i svodi se na direktan upis ispravne adrese u spremniku koja odgovara elementu IAT tablice. Problem pritom moţe predstavljati činjenica da je situacija koju korisnik vidi upravo ona prikazana na slici 3.10, bez informacija o situaciji prije modifikacija - korisnik zapravo ne zna koja je funkcija modificirana, već vidi da je neka funkcija promijenjena. Postoji više načina na koje se moţe doći do imena konkretne funkcije koja je promijenjena - jedan od načina je prolazak kroz vrlo sloţen PE format u spremniku i traţenje odgovarajuće IMAGE_THUNK_DATA strukture koja sadrţava funkciju na zadanom indeksu. Taj je postupak prilično dugotrajan i mukotrpan, no srećom postoji drugačiji trik koji znatno ubrzava posao. Dotična se funkcija sigurno negdje poziva u izvršivom tekstu aplikacije - potrebno je dakle pretraţiti izvršivi tekst Task Manager aplikacije u potrazi za pozivom funkcije iz IAT tablice. Iz slike 3.8 vidljivo je da segment s izvršivim tekstom Task Manager aplikacije počinje na adresi 0x1000 udaljenoj od početka aplikacije (ujedno i početak IAT tablice koja je gotovo uvijek smještena u odsječku izvršivog teksta -.text odsječku - unutar PE datoteke) i da je veličina tog segmenta 0x13EEE okteta. Na slici 3.6 moţe se vidjeti format poziva bilo koje funkcije iz IAT tablice - operacijski kôd naredbe CALL se ne mijenja, potrebno je samo promijeniti adresu poziva pri čemu treba paziti na činjenicu da x86 arhitektura koristi little endian poredak okteta. Samu pretragu obavljamo naredbom s (engl. search): 0:000> s taskmgr+1000 l13eee ff ff c0-7c 14 8b 45 d8 a3 4c 61..H....E..La Slika 3.11: Pojavljivanja poziva sumnjive funkcije iz IAT tablice Na gornjoj slici prikazana je naredba kojom se mogu doznati sva pojavljivanja dotične funkcije u izvršivom tekstu Task Manager aplikacije. Do odgovora na pitanje o kojoj 24

28 se funkciji radi ostao je samo još jedan korak - ispis izvršivog teksta na bilo kojoj gore navedenoj lokaciji, što se postiţe naredbom u (engl. unassemble): 0:000> u taskmgr!initperfinfo+0x16: ff call dword ptr [taskmgr!_imp NtQuerySystemInformation ( )] c0 test eax,eax a 7c14 jl taskmgr!initperfinfo+0x34 ( ) Slika 3.12: Ispis izvršivog teksta koji sugerira da se radi o funkciji NtQuerySystemInformation() Sav teţak posao pronalaţenja imena stvarne funkcije riješio je sam WinDBG debugger i korisnik sada ima dovoljno informacija da riješi problem: 0:000> ln ntdll!ntquerysysteminformation (7c90e1aa) ntdll!zwquerysysteminformation (7c90e1bf) 0:000> ed c90e1aa 0:000> dps c90e1aa ntdll!zwquerysysteminformation Slika 3.13: Popravak modifikacija IAT tablice Najprije se naredbom ln (engl. list nearest symbols) doznaje stvarna adresa funkcije NtQuerySystemInformation() u spremniku. Zatim se naredbom ed (engl. edit doubleword values) dotična adresa upisuje na odgovarajuću lokaciju u IAT tablici. Posljednja naredba sluţi samo kao potvrda izvršenih izmjena. Programski se pronalaţenje i ispravak modifikacija u IAT tablici svodi na posao koji obavlja WinDBG, a algoritam je prikazan sljedećim pseudokôdom: pronađi IAT tablicu u adresnom prostoru procesa za(svaku IMAGE_IMPORT_DESCRIPTOR strukturu) { za(svaku IMAGE_THUNK_DATA strukturu) { dohvati ime i adresu funkcije ako(adresa funkcije nije ispravna) { zapiši ispravnu adresu funkcije } } } Slika 3.14: Pseudkôd pretrage IAT tablice za modifikacijama i uklanjanje modificiranih unosa Dva kritična i najteţa koraka u gornjem pseudokôdu svakako su pronalazak IAT tablice procesa i odreďivanje ispravne adrese funkcije. Način pronalaţenja i prolaska kroz IAT tablicu moţe se pronaći u programima razvijenima za rad [17] (IATMethod). Pronalazak ispravne adrese funkcije teţi je problem. Odgovor koji se sam nameće je korištenje metode GetProcAddress() (metoda za dohvat adrese bilo koje funkcije u zadanoj DLL datoteci, koristi se u primjeru s udaljenom dretvom) - meďutim, ne postoje nikakve garancije da i unos te metode u IAT tablici nije modificiran i da 25

29 pozivom te metode zapravo pozivamo rootkit funkciju koja moţe "filtrirati" odreďene adrese i vraćati ponovo adrese rootkit funkcija! Isto tako, adresa GetProcAddress() metode ne mora čak ni biti izmijenjena u IAT tablici, a da svejedno vraća adrese rootkit funkcija - IAT tablica uopće ne mora biti modificirana, već modifikacije mogu biti provedene u EAT tablici (tablici izvoznih adresa/funkcija) modula čije se funkcije ţele oteti (modificirati). Modifikacija EAT tablice DLL biblioteke manje je efikasna od IAT modifikacije aplikacije jer modifikacija EAT tablice utječe samo na buduće pozive GetProcAddress() metode, a ne na već postojeće unose u IAT tablici. Ipak, modifikacija EAT tablice upravo na ovaj način moţe prevariti jednostavne sigurnosne aplikacije koje se osnivaju na pozivu GetProcAddress() metode. Stvarna adresa funkcije iz IAT tablice nikada se ne bi smjela traţiti pomoću GetProcAddress() metode, niti bilo koje native metode koju GetProcAddress() poziva (npr. LdrGetProcedureAddress() metoda iz ntdll.dll biblioteke). Ispravan način za pronalazak stvarne adrese funkcije je imitiranje Windows punitelja, odnosno "samostalno" obavljanje postupka kojeg obavlja GetProcAddress() metoda: prolazak kroz samu DLL datoteku na disku, točnije kroz EAT tablicu, računanje svih potrebnih relativnih odmaka i pronalazak prave adrese. Ovakav postupak koristi se u praktičnom radu za nešto drugačiju svrhu, pa će sam algoritam tamo biti detaljnije opisan. Naţalost, niti ova metoda nije u potpunosti sigurna od modifikacija koje moţe provesti rootkit. Rootkit moţe promijeniti samu DLL biblioteku na disku na način da doda novi odsječak u samoj datoteci koji će označiti kao izvršiv (engl. executable). Zatim mijenja unose u EAT tablici te datoteke tako da oni pokazuju na dodani odsječak s rootkit funkcijama, umjesto na uobičajene lokacije u izvršivom tekstu DLL biblioteke. Još jedan način modifikacije DLL biblioteke na disku jest da se AddressOfEntryPoint polje PE zaglavlja koje označava ulaznu točku programa ("main" funkciju) preusmjeri na novi odsječak koji sadrţava rootkit izvršivi tekst, a zatim taj rootkit izvršivi tekst poziva stvarnu ulaznu točku. Jedan način rješavanja tog problema je traţenje "sumnjivih" dodatnih odsječaka u DLL datoteci koji imaju dozvolu izvršavanja. Uobičajeno samo.text odsječak ima dozvolu izvršavanja pa prisutnost drugih izvršivih odsječaka moţe značiti prisutnost rootkita. MeĎutim, rootkit ne mora nuţno stvarati novi odsječak, već izvršivi tekst moţe smjestiti u bilo koje praznine unutar izvršivog teksta aplikacije (engl. code cavities) kojih ima mnogo zbog raznih optimizacija (npr. poravnanje odsječaka na višekratnik veličine spremničke stranice). Ipak, u Windows operacijskom sustavu sustavske datoteke poput DLL datoteka iz Windows/system32 direktorija zaštićene su zaštitom pod imenom WFP - Windows File Protection 2. Kada WFP uoči izmjenu bilo koje sustavske datoteke, sve izmjene odbacuje i osigurava da je DLL biblioteka upravo ona koja je originalno došla uz operacijski sustav (WFP je aktivan isključivo u korisničkom načinu rada i izmjene u jezgri nisu pod kontrolom WFP-a). Ni WFP naţalost nije potpuno rješenje i vrlo ga je jednostavno zaobići: dvije DLL datoteke koje sadrţe implementaciju same zaštite 2 WPF na stranicama tvrke Microsoft

30 pod imenom sfc_os.dll i sfc.dll sadrţavaju nedokumentirane funkcije pomoću kojih se zaštita moţe isključiti. Potrebno je samo pronaći adrese tih funkcija (npr. pomoću GetProcAddress() metode) i privremeno ili trajno (do sljedećeg pokretanja sustava) isključiti zaštitu. Pritom je nuţno imati administratorske dozvole. Iz navedenog je vidljivo da postoji konstantno nadmudrivanje izmeďu napadača i autora sigurnosnih aplikacija - napadači smišljaju sve naprednije metode skrivanja i zaraze, a sigurnosne aplikacije primjenjuju sve sloţenije metode otkrivanja modifikacija u sustavu. Jednom kada se rootkit ili zloćudni program ugradi na računalo, postupak njegovog otkrivanja moţe biti vrlo sloţen, kao što je vidljivo i iz ovih uvodnih razmatranja o skrivanju objekata sustava. Zbog toga autori sigurnosnih aplikacija trebaju teţiti sprječavanju zaraze, umjesto da se ona otkriva naknadno. Osim modifikacija IAT i EAT tablica vrlo često korištena tehnika modifikacije funkcija takozvane su inline ili umetnute modifikacije (podjednako ju koriste rootkiti u korisničkom i jezgrinom načinu rada). Te modifikacije poznate su i pod imenom dinamička instrumentacija, odnosno mijenjanje izvršivog teksta pri izvođenju (engl. runtime code patching). Osnovna ideja inline modifikacija koje moţe provesti rootkit je izmjena (najčešće) prvih nekoliko okteta ţeljene funkcije na način da se tijek programa preusmjeri na rootkit funkciju koja, nakon svog izvoďenja, preusmjerava tijek nazad na originalnu funkciju. Prilikom preusmjeravanja tôka izvoďenja, najprije se prvih pet okteta originalne funkcije prepisuje naredbom bezuvjetnog skoka na korisnički (rootkit) definiranu funkciju koja se zove detour ili zaobilazna funkcija. Broj okteta proizlazi iz činjenice da operacijski kôd naredbe JMP zauzima jedan oktet, dok preostala četiri okteta čine (najčešće relativnu) adresu na koju se preusmjerava izvoďenje (32-bitna arhitektura ima 32-bitne adrese, odnosno adresa je duljine četiri okteta). Nakon što je izvoďenje rootkit funkcije završilo, potrebno je vratiti tijek izvoďenja programa na originalnu funkciju i to upravo 5 okteta od početka funkcije. MeĎutim, prebrisane naredbe ne smiju se zanemariti jer mogu sadrţavati vaţne informacije, najčešće vezane uz postavljanje kazala stoga. Zbog toga prije samog prepisivanja originalne funkcije i prije preusmjeravanja tijeka izvoďenja na rootkit funkciju, prvih 5 okteta pohranjujemo u prostor koji se naziva trampoline ili odskočnica. Na taj način tijek izvoďenja programa prilikom poziva funkcije koja sadrţi umetnute modifikacije teče na sljedeći način: 1. Pozvana je originalna funkcija 2. Prvih 5 okteta originalne funkcije smješta se u odskočnicu i zamjenjuje skokom na zaobilaznicu 3. Poziva se zaobilazna (rootkit) funkcija koja obavlja neku aktivnost 4. Zaobilazna funkcija skače na odskočnicu i izvodi naredbe odskočnice 5. Zadnja naredba odskočnice je skok na originalnu funkciju, 5 okteta od početka funkcije - nastavlja se s normalnim izvoďenjem programa 27

31 Postupak je vidljiv na slici Slika 3.15: Prikaz umetnute modifikacije funkcije FindFirstFileW() Sam primjer modifikacije funkcije FindFirstFileW() kojom se skrivaju datoteke od Windows Explorer aplikacije, takoďer je moguće pronaći u radu [17]. Na gornjoj slici vidljivo je da prvih 5 okteta originalne funkcije čine sljedeće naredbe: 1. mov edi,edi 2. push ebp 3. mov ebp, esp Naredbe 2. i 3. su prisutne u svakoj funkciji koja nije posebno označena dodatnim specifikatorom (npr. specifikatorom naked) i koju generiraju današnji prevoditelji na x86 arhitekturi - dotične naredbe nazivaju se prolog funkcije i uspostavljaju okvir stoga (engl. stack frame). Naredba 1. na prvi pogled ne radi ništa - premješta sadrţaj registra u taj isti registar. MeĎutim, ta je naredba umetnuta upravo zato da bi zajedno sa prologom činila cjelinu od 5 okteta. Microsoftovi prevoditelji namjerno umeću tu dodatnu naredbu ispred prologa kako bi sam Microsoft mogao vršiti umetnute modifikacije! Sluţbene zakrpe (engl. patch) za Windows operacijski sustav vrlo često koriste umetnute modifikacije kako bi promijenile pogrešnu/ranjivu verziju funkcije ispravnom. Pritom se računalo ne mora ponovno pokrenuti, kao što je bio slučaj sa starim zakrpama koje nisu koristile umetnute modifikacije. Velika većina funkcija u Windows operacijskom sustavu ima prvih pet okteta upravo gore navedenog oblika, 28

32 čime je tvrtka Microsoft čak olakšala zadatak napadačima - u x86 arhitekturi naredbe nisu iste duljine i napadač bi morao paziti na duljinu pojedinih naredbi. Ipak, što ako se u prvih 5 okteta ne nalaze diskretne naredbe, već je neka naredba "prelomljena"? Takva situacija prikazana je na slici Slika 3.16: Umetnute modifikacije uz promjenjivu duljinu naredbi x86 arhitekture Nakon umetanja naredbe bezuvjetnog skoka na prvih 5 okteta izvorne funkcije, druga push naredba je "prelomljena", tj. zaostali su neki njeni dijelovi - prilikom izvoďenja, ti dijelovi bi se mogli sasvim drugačije protumačiti i vrlo je vjerojatno da će doći do pogreške, odnosno rušenja programa. Drugi dio push naredbe spremljen je u odskočnici i takoďer predstavlja pogrešnu naredbu koja će dovesti do rušenja programa. 29

33 Rješenje ovog problema nije jednostavno i svodi se na upotrebu determinističkog konačnog automata koji odreďuje duljinu naredbe. Prije nego što se naredbe izvorne funkcije prenesu u odskočnicu i prepišu umetnutom modifikacijom (bezuvjetnim skokom), računa se minimalni broj okteta veći od 5 koji sadrţava diskretne naredbe: broj_okteta = 0 dok je(broj_okteta < 5) { tren_duljina = računaj duljinu trenutne naredbe broj_okteta += tren_duljina pomakni se na sljedeću naredbu (pomakni se za tren_duljina) } Slika 3.17: Pseudokôd petlje za računanje broja okteta koji se spremaju u odskočnicu U slučaju na slici 3.16, najprije bi se odredila duljina prve push naredbe (2), a zatim druge push naredbe (5). To znači da je u odskočnicu potrebno prepisati prvih 7 okteta, prebrisati prvih 5 okteta originalne funkcije naredbom bezuvjetnog skoka na rootkit funkciju, a iz odskočnice se vratiti na adresu 7 okteta od početka originalne funkcije. Na taj način se mogu vršiti umetnute modifikacije bilo koje funkcije jer automat za računanje duljine naredbi točno odreďuje broj naredbi koje se spremaju u odskočnicu i odmak od početka funkcije na koji se potrebno vratiti iz odskočnice. Za demonstraciju moţe posluţiti program IATMethod razvijen za rad [17] koji skriva datoteke od Windows Explorer aplikacije. Korištenjem WinDBG debuggera moguće je pronaći neke umetnute modifikacije prisutne u funkcijama koje aplikacija uvozi: 0:000>.foreach (address {dd explorer+1000 l964/4}) {.if(${address} > ) {# jmp ${address} L1} } kernel32!getuserdefaultlangid: 7c80bf94 e9a7dfffff jmp kernel32!getuserdefaultlcid (7c809f40) kernel32!findnextfilew: 7c80ef6a e96128cf85 jmp IATMethod!MakniTaskHook+0x760 (025017d0) kernel32!findfirstfilew: 7c80ef11 e94a28cf85 jmp IATMethod!MakniTaskHook+0x6f0 ( ) SHELL32!ShellMessageBoxW: 7cb9c558 ff25e41b9c7c jmp dword ptr [SHELL32!Ordinal517+0x1be4 (7c9c1be4)] Slika 3.18: Pronalaženje umetnutih modifikacija nad funkcijama u IAT tablici pomoću WinDBG aplikacije Sintaksa naredbi WinDBG aplikacije nije jednostavna niti intuitivna početnicima, no dokumentacija je vrlo dobra i zainteresirani čitatelj moţe u dokumentaciji pronaći više informacija. Ukratko, naredba koja je zadana debuggeru za svaku (foreach) adresu iz IAT tablice explorer procesa (njegova IAT tablica počinje 0x1000 okteta od početne adrese explorer procesa u spremniku, a veličine je 0x964 okteta), ukoliko je ta adresa veća od 0x pregledava da li je prva naredba funkcije iz IAT tablice jmp naredba. Uzimaju se samo adrese veće od 0x jer su svi DLL moduli u adresni prostor procesa uključeni na adresama većima od te adrese. Na slici 3.18 vidljivo je da postoje ukupno četiri unosa s umetnutim modifikacijama. MeĎutim, prvi i zadnji unos nisu sumnjivi jer pokazuju na standardne Windows datoteke i adrese. Drugi i treći unos pokazuju na "rootkit" biblioteku IATMethod čime su otkrivene umetnute modifikacije. Postupak otklanjanja modifikacija sličan je postupku otklanjanja modifikacija IAT tablice - pritom je potrebno slijediti skokove 30

34 kako bi se otkrila lokacija odskočnice koja sadrţava naredbe koje je potrebno zapisati umjesto bezuvjetnog skoka. Pronalaţenje umetnutih modifikacija pomoću WinDBG aplikacije (ali i programski) nije nimalo jednostavan zadatak. Modifikacije ne moraju biti provedene nad funkcijama iz IAT tablice, već mogu biti provedene nad EAT tablicom DLL biblioteke. Osim toga, i funkcije iz IAT tablice aplikacije i one iz EAT tablice datoteke mogu biti bez umetnutih modifikacija - modifikacije mogu biti prisutne u nekoj internoj funkciji koju DLL biblioteka ne izvozi! TakoĎer, u potrazi za umetnutim modifikacijama ne smije se zanemariti činjenica da umetnute modifikacije (naredba bezuvjetnog skoka) ne moraju biti prisutne na početku funkcije već bilo gdje u tijelu funkcije (iako ju napadači zbog jednostavnosti najčešće smještaju na sam početak). Dodatno, naredba bezuvjetnog skoka moţe se zamijeniti push/ret kombinacijom koja ima isti učinak, ili se moţe koristiti call naredba. Zainteresirani čitatelj moţe proučiti i!chkimg naredbu WinDBG debuggera kojom je takoďer moguće otkriti umetnute modifikacije. Programsko rješenje umetnutih modifikacija moţe se zasnivati na dva postupka. Prvi postupak sličan je otkrivanju modifikacija IAT tablice i svodi se na usporeďivanje cjelokupnog "odsječka izvršivog teksta" (.text odsječak) DLL biblioteke na disku s tim istim odsječkom iste DLL biblioteke učitane u adresni prostor nekog procesa - sve razlike vrlo vjerojatno upućuju na djelovanje rootkita. Prednost ove metode jest u tome što se istovremeno mogu otkriti i IAT/EAT modifikacije ako se područje pretrage proširi na EAT tablicu (IAT tablica je uobičajeno u odsječku izvršivog teksta). Nedostatak su moguće modifikacije koje su provedene u samoj DLL datoteci na disku, kao što je objašnjeno ranije. Drugi način pronalaţenja umetnutih modifikacija zasniva se na prolasku kroz EAT tablice svih DLL biblioteka učitanih u adresni prostor procesa i usporedbom prvih nekoliko naredbi izvezenih funkcija s naredbama skoka, poziva ili push/ret kombinacijom. Ako je takva naredba prisutna i ako je adresa odredišta izvan modula, tada se radi o umetnutoj modifikaciji. Pritom je potrebno dohvatiti početnu i završnu adresu modula (kako bi se odredilo da li je odredište skoka izvan modula), što se najčešće radi čitanjem procesnog bloka okruženja - PEB (engl. Process Environment Block). Ova metoda se ne zasniva na datotekama s diska što je prednost u slučaju kada postoji sumnja u modifikacije datoteke na disku. Nedostatak metode jest u tome što umetnute modifikacije ne moraju biti prisutne samo u funkcijama iz EAT bloka već u bilo kojoj internoj funkciji - metoda pronalaţenja se zbog toga treba proširiti na cjelokupan odsječak izvršivog teksta. TakoĎer, nedostatak predstavlja i način dohvata početne i završne adrese modula kroz PEB blok - PEB blok se takoďer može modificirati, a ta se činjenica vrlo rijetko spominje i rijetko uzima u obzir u sigurnosnim aplikacijama prilikom traţenja umetnutih modifikacija. Zbog toga bi se početne i završne adrese modula trebale odreďivati u upravljačkom programu koji te podatke prosljeďuje korisničkom dijelu zaštitne aplikacije. Prije nego što se objasne općeniti mehanizmi skrivanja objekata u jezgrinom načinu rada, potrebno je još objasniti mehanizam prijelaza iz korisničkog u jezgrin način rada jer taj mehanizam sadrţava vaţne informacije koje napadač moţe zloupotrijebiti. 31

35 Prethodno je spomenuto kako su metode iz ntdll.dll datoteke tzv. native metode, odnosno da predstavljaju tanki omotač oko poziva funkcije koja obavlja prijelaz iz korisničkog u jezgrin način rada. Kao primjer moţe se ponovno razmotriti NtQuerySystemInformation() metoda. Ta metoda u različitim inačicama operacijskog sustava Windows ima različit izvorni i izvršivi tekst, no na svim je inačicama taj tekst vrlo kratak i predstavlja prijelaz iz korisničkog u jezgrin način rada. Na 32-bitnom Windows XP operacijskom sustavu metoda ima sljedeći oblik: b8ad mov eax,0adh ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300) ff12 call dword ptr [edx] c21000 ret 10h 90 nop Slika 3.19: NtQuerySystemInformation() metoda u ntdll.dll datoteci Prije detaljnijeg razjašnjenja mehanizma, za primjer se moţe uzeti i bilo koja druga metoda iz ntdll.dll datoteci, npr. NtTerminateProcess(): b mov eax,101h ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300) ff12 call dword ptr [edx] c20800 ret 8 90 nop Slika 3.20: NtTerminateProcess() metoda u ntdll.dll datoteci Iz gornjih dviju slika vidljivo je da se "Nt" metode u ntdll.dll datoteci jako malo razlikuju, točnije razlikuju se po vrijednosti koja se smješta u eax registar u prvoj naredbi. Nakon smještanja te zasad "nejasne" vrijednosti u registar, čita se vrijednost na adresi pod nazivom SystemCallStub i potom se poziva funkcija koja se nalazi na adresi koja odgovara vrijednosti pročitanoj sa SystemCallStub adrese: SystemCallStub sadržava vrijednost 7c90eb8b 7c90eb8b - ntdll!kifastsystemcall: 8bd4 mov edx,esp 0f34 sysenter Slika 3.21: KiFastSystemCall() funkcija Na adresi pod nazivom SystemCallStub nalazi se vrijednost koja odgovara adresi KiFastSystemCall() funkcije. Upravo je KiFastSystemCall() funkcija ona koja obavlja prijelaz iz korisničkog u jezgrin način rada, točnije sam prijelaz obavlja naredba sysenter. U prijašnjim inačicama Windows operacijskog sustava za tu svrhu koristila se naredba prekida int 0x2e, dok se u 64-bitnim verzijama koristi naredba syscall. Specifičnosti tih naredbi mogu se proučiti u odgovarajućim Intel priručnicima 3. Jasno je da i KiFastSystemCall() funkcija iz ntdll.dll datoteke moţe biti modificirana na način koji je prethodno opisan (ili modifikacijom unosa u EAT tablici ntdll.dll datoteke na disku ili u spremniku ili umetnutim modifikacijama, takoďer na disku ili u 3 Intel priručnici

36 spremniku). Dotična funkcija je vrlo primamljiva za napadača jer njezinom modifikacijom napadač moţe nadzirati sve prijelaze iz korisničkog u jezgrin način rada i vršiti odgovarajuće modifikacije. Zbog toga bi sigurnosna aplikacija trebala pretraţiti postoje li modifikacije KiFastSystemCall() funkcije (to standardno čini ako pretraţuje cjelokupne odsječke izvršivog teksta ntdll.dll datoteke kao što je prethodno navedeno). Ipak, napadačev posao prilikom "otimanja" KiFastSystemCall() funkcije nije tako jednostavan jer ne zna koja je zapravo funkcija pozvana. Odgovor na to pitanje moţe mu dati "tajanstvena" konstanta u prvoj naredbi svake "Nt" funkcije iz ntdll.dll datoteke - značenje te konstante objašnjeno je u sljedećem potpoglavlju Jezgrin način rada U jezgrinom načinu rada općenito se koriste modifikacije analogne onima iz korisničkog načina rada, postoji jedino razlika u tablicama odnosno lokacijama gdje se modifikacije obavljaju. Nakon što je izvršena naredba sysenter (int 0x2e ili syscall), poziva se jezgrina funkcija KiSystemService() koja predstavlja dispečera sustavskih usluga (engl. system service dispatcher). Dotična funkcija preslikava argumente s korisničkog stoga na jezgrin stog i pokreće odgovarajuću jezgrinu funkciju koja je pozvana (npr. funkciju NtQuerySystemInformation()). U slučaju 32-bitne inačice operacijskog sustava Windows XP, argumenti predani funkciji se zapravo nalaze na adresi na koju pokazuje edx registar (to je vidljivo i iz prve instrukcije KiFastSystemCall() funkcije). MeĎutim, na koji način dispečer sustavskih usluga zna koju jezgrinu funkciju treba pozvati? Jezgra sadrţi tzv. dispečersku tablicu - SSDT (engl. System Service Dispatch Table) koja sadrţava adrese svih jezgrinih funkcija koje se pozivaju iz korisničkog načina rada ("Nt" funkcije iz ntdll.dll datoteke zapravo su omotači oko stvarnih funkcija u jezgri). Na vrlo pojednostavljeni način moţemo SSDT tablicu smatrati EAT tablicom jezgre, no tu analogiju nikako ne treba shvaćati doslovno. Tajanstvena konstanta koja se pojavljuje u prvoj instrukciji svih "Nt" funkcija u ntdll.dll datoteci zapravo je index u SSDT tablici - upravo ta konstanta odreďuje koja će se jezgrina funkcija pozvati. Iz slike 3.19 vidljivo je da je adresa "stvarne" (jezgrine) NtQuerySystemInformation() funkcije smještena na indeksu 0xAD SSDT tablice, dok je adresa NtTerminateProcess() funkcije, prema slici 3.20, na indeksu 0x101 SSDT tablice. Dotične konstante nisu jednake u pojedinim inačicama Windows operacijskog sustava - čak i zakrpe često mijenjaju vrijednosti tih konstanti, tako da se niti napadač niti sigurnosna aplikacija ne smiju oslanjati na očuvanost tih vrijednosti u različitim inačicama operacijskog sustava. To je ujedno i problem za napadača koji je prethodno spomenut kod "otimanja" funkcije KiFastSystemCall(): da bi mogao ispravno razlučiti koja je funkcija pozvana, napadač mora povezati konstante (koje se mijenjaju u pojedinim inačicama) s nazivima funkcija koje su pozvane. Napadačevo djelovanje u SSDT tablici moţe biti istovjetno onome opisano u prethodnom potpoglavlju - odgovarajući unos u SSDT tablici moţe biti zamijenjen adresom rootkit funkcije (analogno izmjeni IAT/EAT tablice), ili sama tablica moţe biti netaknuta, no nad odgovarajućom funkcijom čija je adresa u SSDT tablici, mogu biti provedene umetnute modifikacije. 33

37 Tijek poziva NtQuerySystemInformation() funkcije iz korisničkog u jezgrin način rada, zajedno uz moguće rootkit modifikacije prikazan je na sljedećoj slici: Slika 3.22: Tijek prijelaza NtQuerySystemInformation() funkcije iz korisničkog u jezgrin način rada uz prisutnost modifikacija i bez modifikacija Na slici je prikazana situacija kada je modificiran unos u SSDT tablici (ekvivalentno modifikaciji unosa u IAT/EAT tablici i slici 3.7), no umetnute modifikacije bi izgledale vrlo slično - nakon koraka 4, prva instrukcija NtQuerySystemInformation() funkcije bila bi instrukcija bezuvjetnog skoka na rootkit funkciju, koja bi zatim skočila na odskočnicu, a odskočnica nazad na originalnu funkciju. Treba spomenuti da i sama KiSystemService() funkcija moţe biti modificirana na dva načina. Prvi način je korištenjem umetnutih modifikacija (na taj način moţe se modificirati svaka funkcija), a drugi način je korištenjem registara specifičnih za x86 arhitekturu - više o njima moţe se doznati u priručnicima tvrtke Intel. Unose SSDT tablice moţe se provjeriti WinDBG debuggerom koristeći se opcijom lokalnog povezivanja na jezgru (engl. local kernel debugging). Ta opcija onemogućava neke uobičajene funkcije koje se koriste u radu s debuggerom, no prisutna je mogućnost čitanja i pisanja u spremnik. SSDT tablicu moguće je pronaći preko jezgrine javno dostupne varijable KeServiceDescriptorTable (koristi se naredba dd - display double word values): 34

38 kd> dd nt!keservicedescriptortable b c c Slika 3.23: Pronalaženje SSDT tablice u jezgri Adresa označena brojem 1 predstavlja upravo adresu SSDT tablice, dok je broj unosa u tablici naveden pod 2. Prije modifikacija izgled tablice je sljedeći (prikazan samo dio tablice): kd> dps l11c a3490 nt!ntacceptconnectport c 805ef7b2 nt!ntaccesscheck dc 8060fcce nt!ntquerysysteminformation ca61a nt!ntqueryportinformationprocess Slika 3.24: SSDT tablica prije modifikacija Iz gornje slike vidljive su dvije činjenice: tablica nije modificirana i NtQuerySystemInformation() funkcija zaista se nalazi na indeksu 0xAD ( ). Broj 3 na slici je pokazivač na tablicu argumenata - dotična tablica na indeksu sadrţava broj okteta argumenata funkcije s indeksom u SSDT tablici (za napadača i sigurnosne aplikacije nije toliko vaţna). Kao primjer za modifikacije posluţit će upravljački program razvijen uz rad koji mijenja unos funkcije NtQuerySystemInformation() u SSDT tablici vlastitom inačicom koja skriva proces calc.exe. Sam izvorni tekst programa izmjene SSDT tablice prikazan je na sljedećoj slici: typedef struct ServiceDescTableElem { unsigned int *SSDTbase; unsigned int *ServiceCounterTableBase; unsigned int ProcNum; unsigned int *ParamTableBase; } SSDT_Elem; PMDL g_pmdlsyscall; PVOID *SysCallTable; _declspec(dllimport) SSDT_Elem KeServiceDescriptorTable; #define SYSTEMSERVICE(_function) KeServiceDescriptorTable.SSDTbase[ *(PULONG)((PUCHAR)_function+1)] #define SYSCALL_INDEX(_Function) *(PULONG)((PUCHAR)_Function+1) #define HOOK_SYSCALL(_Function, _Hook, _Orig ) \ _Orig = (PVOID) InterlockedExchange( (PLONG) &SysCallTable[SYSCALL_INDEX(_Function)], (LONG) _Hook) #define UNHOOK_SYSCALL(_Function, _Hook, _Orig ) \ InterlockedExchange( (PLONG) &SysCallTable[SYSCALL_INDEX(_Function)], (LONG) _Hook) 35

39 // stvori memory descriptor list - potrebno za mapiranje SSDT tablice u našu domenu g_pmdlsyscall = MmCreateMdl( NULL, KeServiceDescriptorTable.SSDTbase, KeServiceDescriptorTable.ProcNum*4); if(!g_pmdlsyscall) return STATUS_UNSUCCESSFUL; // alociraj memoriju u prostoru memorije u kojem nije dozvoljeno straničenje // tu se smješta naša SSDT tablica MmBuildMdlForNonPagedPool(g_pmdlSysCall); // dozvoli pisanje po alociranom prostoru g_pmdlsyscall->mdlflags = g_pmdlsyscall->mdlflags MDL_MAPPED_TO_SYSTEM_VA; // zaključaj alocirane stranice - time je postupak mapiranja gotov SysCallTable = MmMapLockedPages(g_pmdlSysCall, KernelMode); // obavi modifikacije unosa u SSDT tablici (zamijeni funkciju našom verzijom) HOOK_SYSCALL( ZwQuerySystemInformation, NewZwQuerySystemInformation, OldZwQuerySystemInformation ); Slika 3.25: Modifikacija unosa funkcije NtQuerySystemInformation() u SSDT tablici Na početku su najprije definirane makro-naredbe kojima se vrši sama izmjena adrese u SSDT tablici, kao i pomoćne makro-naredbe za dohvat indeksa funkcije u SSDT tablici. Nakon toga se vrši mapiranje SSDT tablice u posebno alocirano područje spremnika - to je nuţno jer u području spremnika u kojem se izvorno nalazi SSDT tablica nije dozvoljeno pisanje. Mapiranjem tablice u posebno alocirano područje i omogućavanjem pisanja po tom području omogućena je izmjena unosa u SSDT tablici. Isto se moţe postići modifikacijom CR0 registra procesora (više u Intel priručniku) Nakon što je postupak mapiranja proveden, potrebno je samo izmijeniti konkretne unose u tablici što se obavlja upotrebom prethodno definiranih makronaredbi. Nakon modifikacija, SSDT tablica ima sljedeći izgled: kd> dps l11c a3490 nt!ntacceptconnectport c 805ef7b2 nt!ntaccesscheck dc faf4a610 IDT_DRIVE+0x ca61a nt!ntqueryportinformationprocess Slika 3.26: SSDT tablica nakon modifikacija Vidljivo je da je unos na indeksu 0xAD u tablici modificiran i da pokazuje na nepoznati modul. Korisnik se susreće s istim problemom kao i IAT tablice - odrediti koja je funkcija zapravo modificirana. Srećom zadatak je ovdje još jednostavniji - potrebno je samo pronaći funkciju koja u sebi ima naredbu spremanja konstante 0xAD u eax registar: kd> # eax,0adh nt nt!zwquerysysteminformation: 80500a90 b8ad mov eax,0adh Slika 3.27: Pronalazak funkcije čiji je unos u SSDT tablici modificiran 36

40 Korištena je naredba # koja pretraţuje zadani spremnički prostor za traţenim izrazom (u ovom slučaju od početka adrese jezgre pa sve dok se traţeni izraz ne pronaďe). Traţeni izraz je ovdje upravo smještanje konstante u registar. WinDBG debugger pronašao je funkciju ZwQuerySystemInformation(), a ne NtQuerySystemInformation(). Bez ulaţenja u nepotrebne detalje o razlikama (zainteresirani čitatelj se upućuje na izvrsno objašnjenje na OSR Online web stranici 4 ), unosi u SSDT tablici moraju pokazivati na Nt* vezije, a ne na Zw* verzije! Uklanjanje modifikacija svodi se na istovjetan postupak koji je objašnjen za uklanjanje IAT modifikacija. Programsko rješenje pretrage SSDT tablice za modifikacijama relativno je jednostavno i svodi se na provjeru unosa u tablici koji mora biti unutar granica jezgre. Svaka funkcija koja ima unos u SSDT tablici je jezgrina funkcija i samim time, mora biti unutar granica jezgre, tj. unutar nt modula kako je jezgra označena u WinDBG debuggeru (jezgrina datoteka nalazi se u system32 direktoriju i ima različite nazive ovisno o broju procesora i inačici Windows operacijskog sustava no počinje slovima nt). Ako unos pokazuje na neki drugi modul, tada je sigurno riječ o modifikaciji, zloćudnoj ili dobroćudnoj (mnogi antivirusni alati i sigurnosne zaštitne stijene vrše modifikaciju unosa u SSDT tablici). Pseudokôd je prikazan na sljedećoj slici: pronađi adresu SSDT tablice (preko javne varijable jezgre KeServiceDescriptorTable) jezgra_start = dohvati početnu adresu procesa jezgre jezgra_kraj = jezgra_start + dohvati veličinu procesa jezgre za(svaki unos u SSDT tablici) { ako(unos <= jezgra_start unos >= jezgra_kraj) { modifikacija pronađena } } Slika 3.28: Pseudokôd programa za pretragu modifikacija u SSDT tablici Postupak uklanjanja modifikacija mnogo je sloţeniji. Temelji se na činjenici da SSDT tablica postoji i u datoteci jezgre na disku - ta se tablica u gotovo nepromijenjenom obliku prilikom podizanja sustava zapisuje u spremnik. Teškoće postoje prilikom pronalaţenja tablice u datoteci jer ona nije prisutna u EAT tablici niti je lako do nje doći preko nekih struktura. Taj je problem riješen u praktičnom dijelu. Sigurnosna aplikacija ne smije se ograničiti samo na provjeru unosa SSDT tablice - za svaki unos treba se provjeriti postoje li umetnute modifikacije u funkciji na koju unos pokazuje. TakoĎer, treba spomenuti da operacijski sustav Windows ne sadrţi samo jednu SSDT tablicu već je moguće imati ukupno 4 SSDT tablice u sustavu. U svim inačicama aktivne su samo dvije: upravo opisana SSDT tablica i tzv. sjenčana SSDT tablica (engl. shadow SSDT) koja sadrţava pokazivače na jezgrine funkcije koje su 4 Razlika Zw* i Nt* funkcija

41 vezane za rad s grafičkim sučeljem operacijskog sustava. Zbog toga sjenčana tablica nije toliko zanimljiva napadaču, iako postoje rootkiti koji iskorištavaju i tu tablicu. Osim SSDT tablice napadači su prije često koristili IDT tablicu - tablicu prekidnih vektora (engl. interrupt descriptor table). Budući da je u operacijskom sustavu Windows 2000 prijelaz iz korisničkog načina rada u jezgrin način rada koristio upravo prekid 0x2E, to je bio dodatan razlog za česte modifikacije ove tablice. IDT tablicu su napadači često koristili i za implementaciju programa koji prikupljaju unos s tipkovnice (engl. keylogger) jer je samo bilo potrebno izmijeniti prekidnu rutinu tipkovnice u tablici. TakoĎer, nekada se IDT tablica koristila za preuzimanje kontrole nad upraviteljem virtualnog spremnika jer se straničenje obavlja upravo prekidom. Modifikacije IDT tablice prisutne su i u operacijskom sustavu Linux, u kojem su jednostavnije za provesti jer tablica sadrţava same prekidne vektore (adrese prekidnih rutina), dok u operacijskom sustavu Windows unose IDT tablice čine opisnici prekidnih vektora (strukture koje sadrţavaju pokazivač na prekidnu rutinu). Za dohvat IDT tablice moţe se koristiti naredba!idt WinDBG debuggera ili (programski) x86 naredba lidt. Za pohranu eventualnih izmjena (nakon uklanjanja modifikacija) programski se koristi naredba sidt. Postoji nekoliko razloga zašto se IDT tablica sve manje koristi: najveći nedostatak leţi u činjenici da se ne moţe koristiti tehnika "filtriranja" prisutna kod "preotetih" (engl. hooked) funkcija - rootkit funkcija zove originalnu funkciju, filtrira rezultate i vraća kontrolu pozivatelju. Prekidne rutine nikada se ne vraćaju pozivatelju u klasičnom smislu riječi, tako da rootkit funkcija ne moţe pozvati prekidnu rutinu, filtrirati rezultate i nastaviti posao jer se kontrola nikada neće vratiti na rootkit funkciju jednom kad je prekidna rutina pozvana. TakoĎer, svaki procesor ima vlastitu IDT tablicu i da bi napadač preuzeo kontrolu nad nekim unosom u tablici, mora ga promijeniti u IDT tablicama svih procesora. IDT modifikacije se otkrivaju nešto teţe od SSDT modifikacija jer je dozvoljena situacija u kojoj prekidni vektor nije unutar adresnog prostora jezgrinog procesa, već u adresnom prostoru bilo kojeg upravljačkog programa. U jezgri postoji još mnogo tablica koje su privlačne napadačima. Tablice lokalnih opisnika (LDT - engl. Local Descriptor Table) i globalnih opisnika (GDT - engl. Global Descriptor Table) sluţe za pohranu opisnika segmenata u x86 arhitekturi i utječu na viďenje sustavskog adresnog prostora [24]. Detalji o namjeni tih tablica mogu se pročitati u Intelovim priručnicima, no modifikacijom tih tablica napadač moţe ostvariti komunikaciju izmeďu korisničkog i jezgrinog načina rada koja ne ide kroz dispečera sustavskih usluga - točnije, zloćudni program tom tehnikom moţe izravno pozivati jezgrine funkcije, bez obzira na dozvole. Primjene ovakve tehnike su dosta ograničene pa neće biti dalje razmatrane. Na sličan način djeluju i modifikacije u sustavu straničenja: modifikacijom tog sustava napadač moţe aplikaciji u korisničkom načinu rada dozvoliti pristup spremničkom prostoru jezgre kojem inače aplikacija ne bi mogla pristupiti. Modifikacije ovakvog tipa, zajedno s modifikacijama cjelokupnog upravitelja spremnikom (engl. memory manager) operacijskog sustava Windows, mogu biti vrlo skrivene i najčešće se teško otkrivaju. 38

42 Još jedna vrlo često korištena tehnika je modifikacija funkcijske tablice samog upravljačkog programa. Svaki upravljački program sadrţava tablicu pokazivača na funkcije koje se pozivaju u ovisnosti o primljenom ulazno-izlaznom zahtjevu (IRP - engl. Input/Output Request Packet). Sam upravljački program zaduţen je za popunjavanje te tablice odgovarajućim funkcijama. Primjerice, kada korisnička aplikacija šalje podatke upravljačkom programu, ili ţeli primiti neke informacije od upravljačkog programa, jezgra operacijskog sustava takve zahtjeve korisničke aplikacije pretvara u "IRP pakete" koji dolaze do upravljačkog programa. Ovisno o primljenom zahtjevu, upravljački program će na temelju pokazivača iz tablice pozvati odgovarajuću funkciju. Slično modifikacijama bilo koje tablice koja je do sada spomenuta (IAT/EAT/SSDT), na istovjetan način napadač moţe modificirati tablicu funkcijskih pokazivača i učiniti da pokazivač pokazuje na rootkit funkciju. To je prikazano na slici 3.29, djelomice preuzetoj iz [25]. Slika 3.29: Komunikacija korisničke aplikacije s upravljačkim programom bez modifikacija i uz rootkit modifikacije u tablici funkcijskih pokazivača U ulaznoj funkciji upravljačkog programa (tzv. DriverEntry rutina), upravljački program stvara "ureďaj" odnosno objekt ureďaja - DeviceObject. Taj ureďaj moţe koristiti korisnička aplikacija za komunikaciju s upravljačkim programom. Objekt ureďaja u svojoj strukturi sadrţi pokazivač na DriverObject strukturu koja sadrţava prethodno spomenutu tablicu funkcijskih pokazivača. Indeksi te tablice označeni su simboličkim konstantama IRP_MJ_*. Primjerice, na poziciju tablice s indeksom 39

43 IRP_MJ_READ potrebno je staviti pokazivač na funkciju koja će se pozvati kada se u korisničkom programu pozove funkcija za čitanje iz upravljačkog programa, kao što je prikazano na gornjoj slici. Ukoliko napadač zamijeni pokazivač na originalnu funkciju pokazivačem na vlastitu, rootkit funkciju, moţe modificirati odreďene podatke (npr. moţe modificirati IRP tablicu upravljačkog programa za datotečni sustav ili upravljačkog programa za mreţni TCP/IP protokol). MeĎutim, kao i kod IDT tablice, nemoguće je da rootkit funkcija preuzme kontrolu, pozove izvornu funkciju iz tablice i zatim filtrira rezultate i vrati kontrolu pozivatelju. Tok programa moguć je isključivo na način prikazan na slici - nakon što rootkit funkcija obavi svoj zadatak, ona mora pozvati originalnu funkciju koja neće vratiti kontrolu natrag na rootkit funkciju. Jedina mogućnost djelovanja nakon što je izvorna funkcija obavila svoj posao jest registriranje takozvane ulaznoizlazne rutine ponovnog poziva (engl. Input-output callback routine) koju će pozvati U/I upravitelj operacijskog sustava nakon što je originalna funkcija pripremila sve potrebne podatke koje treba vratiti pozivatelju. Napadač do ţeljenog objekta ureďaja moţe doći vrlo jednostavno, koristeći se metodom IoGetDeviceObjectPointer() iz vlastitog upravljačkog programa. Primjer modifikacije IRP tablice upravljačkog programa bit će naveden u potpoglavlju o specifičnostima skrivanja mreţnih veza. Programski način otkrivanja modifikacija IRP tablice vrlo je sličan načinu otkrivanja modifikacija SSDT tablice - nakon što se dohvati IRP tablica odgovarajućeg upravljačkog programa, svaki pokazivač mora pokazivati na funkciju koja se nalazi u adresnom prostoru dotičnog upravljačkog programa. Ako postoji pokazivač koji pokazuje izvan adresnog prostora upravljačkog programa, tada se sigurno radi o modificiranom unosu IRP tablice i vrlo vjerojatno o djelovanju rootkita. U nastavku će biti opisane specifične metode skrivanja pojedinih objekata sustava: procesa, upravljačkih programa, datoteka i mreţnih veza. 3.3 Specifičnosti pri skrivanju procesa operacijskog sustava Na temelju saznanja iz prethodnih poglavlja moţe se zaključiti da je procese moguće skrivati modifikacijama IAT/EAT tablice u korisničkom načinu rada, odnosno modifikacijom SSDT tablice u jezgrinom načinu rada. U korisničkom načinu rada najčešće se modificira funkcija NtQuerySystemInformation() u EAT tablici ntdll.dll datoteke ili korištenjem umetnutih modifikacija. Dotičnu funkciju koriste i sve ostale API funkcije na višem nivou koje su zaduţene za dohvat informacija o procesima. U jezgrinom načinu rada takoďer se modificira ista funkcija, tj. njen unos u SSDT tablici ili se vrše umetnute modifikacije nad samom funkcijom u jezgri. MeĎutim, navedene modifikacije otkrivaju se relativno jednostavno pa su napadači krenuli u detaljnije istraţivanje podatkovnih struktura vezanih za procese u operacijskom sustavu. Svaki proces u bilo kojem operacijskom sustavu opisan je svojim procesnim informacijskim blokom [26]. Taj blok sadrţava sve informacije potrebne za odvijanje 40

44 procesa: informacije o zauzetim resursima (spremničkim i ostalim), prisutna je informacija o procesu roditelju, lista dretvi procesa i druge vaţne informacije. U operacijskom sustavu Windows procesni informacijski blok opisan je EPROCESS strukturom. EPROCESS struktura nije dokumentirana i razlikuje se meďu pojedinim inačicama operacijskog sustava, no moguće je doznati članove te strukture koristeći se WinDBG debuggerom i naredbom za pregled korisničkih tipova - dt (engl. display types). Na slici 3.30 dani su neki članovi EPROCESS strukture operacijskog sustava Windows XP, zajedno s relativnim odmacima prema početku strukture: kd> dt nt!_eprocess +0x000 Pcb : _KPROCESS +0x06c ProcessLock : _EX_PUSH_LOCK +0x080 RundownProtect : _EX_RUNDOWN_REF +0x084 UniqueProcessId : Ptr32 Void +0x088 ActiveProcessLinks : _LIST_ENTRY +0x000 Flink : Ptr32 _LIST_ENTRY +0x004 Blink : Ptr32 _LIST_ENTRY +0x0c4 ObjectTable : Ptr32 _HANDLE_TABLE +0x14c InheritedFromUniqueProcessId : Ptr32 Void +0x174 ImageFileName : [16] UChar +0x1b0 Peb : Ptr32 _PEB Slika 3.30: Važniji članovi EPROCESS strukture operacijskog sustava Windows XP (SP2) Svi procesi u operacijskom sustavu (njihovi EPROCESS blokovi) povezani su u dvostruko povezanu listu - listu aktivnih procesa. Unutar svakog EPROCESS bloka postoji pokazivač na sljedeći proces u listi i pokazivač na prethodni proces u listi - ti pokazivači sadrţani su u ActiveProcessLinks članu (Flink je pokazivač na sljedeći član liste, a Blink na prethodni član). TakoĎer, lista procesa ima svoju "glavu" - glava liste je nedokumentirana i privatna varijabla jezgre pod imenom PsActiveProcessHead. PsActiveProcessHead.Flink član pokazuje na ActiveProcessLinks član prvog procesa u listi, dok PsActiveProcessHead.Blink član pokazuje na ActiveProcessLinks član zadnjeg procesa u listi. TakoĎer, ActiveProcessLinks.Flink zadnjeg procesa u listi pokazuje na glavu, čime se ostvaruje dvostruko povezana lista. Napadačeva ideja mogla bi biti uklanjanje EPROCESS bloka procesa koji ţeli sakriti iz liste. Kako bi to učinio, mora osvjeţiti pokazivače procesa koji prethodi procesu koji ţeli sakriti i pokazivače sljedećeg procesa u listi. Pokazivač ActiveProcessLinks.Flink prethodnog procesa mora pokazivati na ActiveProcessLinks član sljedećeg procesa u listi, dok ActiveProcessLinks.Blink pokazivač sljedećeg procesa mora pokazivati na ActiveProcessLinks član prethodnog procesa. 41

45 Objašnjenje moţda zvuči kompleksno, no vizualno je vrlo jednostavno. Na slici 3.31 prikazana je takva modifikacija, uz ilustraciju općenitog izgleda liste procesa u operacijskom sustavu Windows. Slika 3.31: Lista aktivnih procesa u Windows operacijskom sustavu i uklanjanje procesa iz te liste Napadač ţeli ukloniti Proces 2 na gornjoj slici iz liste procesa. Zbog toga modificira vrijednosti pokazivača EPROCESS blokova prethodnog i sljedećeg procesa na način na koji je prikazan na slici. Isti postupak uklanjanja procesa iz liste vrši i funkcija za uništavanje procesa, npr. NtTerminateProcess() funkcija (uz pomoć privatnih funkcija jezgre). MeĎutim, nije li napadač uklanjanjem procesa iz liste zapravo uništio proces, tj. uskratio mu procesorsko vrijeme? Odgovor leţi u činjenici da se na računalu ne izvode procesi, već dretve - svaki proces mora imati barem jednu dretvu kako bi se mogao izvoditi. Sve dok je dretva procesa aktivna, proces će se normalno izvoditi jer se o izvoďenju dretve brine dio operacijskog sustava koji se naziva raspodjelitelj poslova/dretvi (engl. thread scheduler). Sve dokumentirane funkcije koje dohvaćaju informacije o aktivnim procesima dotične informacije dobivaju upravo prolaskom kroz listu aktivnih procesa - uklanjanjem procesa iz te liste proces će se dalje nastaviti izvoditi (jer postoji aktivna dretva), no neće biti vidljiv korisniku koji koristi dokumentirane funkcije! Slična tehnika koristi se i u operacijskom sustavu Linux, naravno, uz drugačije strukture podataka. Postoje dva osnovna načina pomoću kojih je moguće otkriti ovako skriven proces. Prvi način moguć je čak iz korisničkog načina rada. Naime, procesima se (kao i većinom drugih objekata operacijskog sustava) moţe "rukovati" otvaranjem ručice (engl. handle) na njega. Ručice na sve objekte spremljene su u sasvim drugim podatkovnim strukturama, praktički neovisnima o listi procesa, tzv. tablicama ručica (engl. handle table). Iako je proces skriven, ručica na njega moţe se dobiti i iz korisničkog načina rada jer on kao objekt postoji u tablici ručica. Na taj način moţe se iz korisničkog načina rada pokušati otvoriti sve procese s početnim identifikatorom 0, do krajnje, proizvoljno odabrane, vrijednosti. Ako je ručica uspješno dohvaćena, 42

46 znači da proces postoji u operacijskom sustavu. Usporedbom svih ručica (odnosno procesa) dobivenih tom metodom sa svim procesima koji su dobiveni korištenjem API funkcija (npr. funkcijama Process32First/Next() ili pomoću NtQuerySystemInformation() funkcije), moţe se zaključiti koji su procesi skriveni. Metoda bi se mogla opisati kao traženje procesa grubom silom jer se linearno po svim identifikatorima ispituje da li proces postoji, odnosno moţe li se dohvatiti njegova ručica. Nedostatak ove metode prije svega predstavlja činjenica da se izvodi u korisničkom načinu rada. Bilo koja "razina" funkcije za otvaranje procesa moţe biti modificirana od strane napadača (npr. OpenProcess() funkcija, NtOpenProcess() funkcija ili neka privatna i interna funkcija jezgre) i za rootkit proces moţe vratiti poruku o nepostojećoj ručici. MeĎutim, metoda je vrlo jednostavna za provesti i svakako bi trebala biti dio sigurnosne aplikacije koja pretraţuje skrivene procese. Drugi način otkrivanja ovako skrivenih procesa takoďer se zasniva na tablici ručica. Svaki proces sadrţi vlastitu tablicu ručica, no tablice ručica svih procesa meďusobno su povezane u dvostruko povezanu listu, baš kao i sami procesi. Na slici 3.30 sama tablica ručica nalazi se u EPROCESS bloku (član ObjectTable), a sama struktura u operacijskom sustavu Windows XP ima sljedeći oblik: kd> dt nt!_handle_table +0x004 QuotaProcess : Ptr32 _EPROCESS +0x008 UniqueProcessId : Ptr32 Void +0x00c HandleTableLock : [4] _EX_PUSH_LOCK +0x01c HandleTableList : _LIST_ENTRY +0x03c HandleCount : Int4B Slika 3.32: Važniji članovi tablice ručica Iz slike je vidljivo da je HandleTableList član istovjetan ActiveProcessLinks članu EPROCESS strukture, dakle radi se o dvostruko povezanoj listi. TakoĎer, tablica ručica ima pokazivač na EPROCESS blok procesa kojem pripada - na taj način prolaskom kroz tablicu ručica moţemo odrediti sve procese u sustavu! Unatoč tome što je napadač sakrio proces iz liste aktivnih procesa, tablica ručica procesa i dalje je povezana s tablicama ručica ostalih procesa pa je skriveni proces i dalje vidljiv. Nedostatak ove metode je korištenje nedokumentiranih struktura - EPROCESS blok i HANDLE_TABLE struktura (tablica ručica) podatkovne su strukture koje nisu namijenjene za "općenito" korištenje, već su rezervirane za Microsoftove programere. U bilo kojem trenutku oblik tih podatkovnih struktura moţe se promijeniti, tj. one u sljedećim inačicama operacijskog sustava ne moraju ni postojati. Sigurnosne aplikacije pristupaju tom problemu na tri načina. Prvi i najjednostavniji način je izbjegavanje nedokumentiranih struktura i korištenje preporučenih sučelja. Naravno, na taj se način veliki broj rootkita ne moţe otkriti jer, kao što je i vidljivo, rootkiti se ugraďuju vrlo duboko u sustav. Drugi način predstavlja korištenje fiksnih struktura koje ovise o inačici operacijskog sustava - tako se npr. upravljački program za jednu inačicu prevede s jednim oblikom strukture, za drugu inačicu s drugim oblikom itd. Treći način je heuristička pretraga i heurističko odreďivanje odmaka pojedinih članova strukture. Svaki proces zna vlastito ime i vlastiti identifikator. Dohvatom EPROCESS bloka (PsGetCurrentProcess() naredbom) i pretraţivanjem te strukture u 43

47 potrazi za imenom i identifikatorom (i nekim dodatnim poznatim poljima), mogu se izračunati odmaci odreďenih polja u strukturi. Ova metoda je relativno nepouzdana i sloţena te moţe izazvati niz negativnih učinaka. Zbog toga ju sigurnosne aplikacije vrlo rijetko upotrebljavaju, za razliku od rootkita koji se često koriste ovom metodom. Autor se odlučio za jednu sasvim drugu metodu koju rootkiti ne mogu koristiti zbog imperativa nevidljivosti. Ta metoda zasniva se na debug simbolima koje koristi i WinDBG aplikacija i autor nije uočio niti jednu sigurnosnu aplikaciju koja se koristi tom metodom, unatoč tome što je dotična metoda znatno bolja i moćnija od dosad opisanih. Pretraga liste tablica ručica koristi se i kao metoda otkrivanja skrivenih procesa u praktičnom radu. Naţalost, analogno modifikacijama aktivne liste procesa, moţe se modificirati i lista tablica ručica: napadač tablicu ručica vlastitog procesa jednostavno briše iz liste na isti način kao što se iz tablice aktivnih procesa miče proces na slici Pritom je nuţno da napadač proces ukloni iz obje liste: liste aktivnih procesa i liste tablice ručica. Zaštitne aplikacije koje pretraţuju skrivene procese metodom prolaska kroz listu tablica ručica neće otkriti skriveni proces koji će i dalje biti aktivan jer se aktivnost temelji na postojanju dretve, a ne procesa. Napadač se pritom susreće s jednim problemom: prilikom otvaranja ili zatvaranja bilo kojeg objekta u skrivenom procesu, doći će do pokušaja spremanja ručice na taj objekt u tablicu ručica, no budući da je ta tablica izolirana, objekt se neće moći spremiti i vrlo vjerojatno će doći do rušenja cjelokupnog sustava. Napadač taj problem moţe riješiti tako da sve potrebne objekte otvori prije nego što sakrije proces i da nikad ne otvara nove niti zatvara stare ili da prije dobavljanja objekta nakratko ponovno ubaci tablicu ručica procesa u listu tablica ručica. Srećom za autore sigurnosnih aplikacija, operacijski sustav Windows usporedno pamti dvije strukture podataka u kojima se nalaze ručice objekata sustava. Prva podatkovna struktura je već opisana lista tablice ručica na koju pokazuje "glava" pod nazivom HandleTableListHead (analogno PsActiveProcessHead). Druga podatkovna struktura je globalna tablica svih ručica na procese i dretve koja je opisana privatnom varijablom jezgre PspCidTable. Budući da je varijabla privatna, nije lako doći do njezine adrese. Prvi način jest pretraga tijela funkcije PsLookupProcessByProcessId() za adresom te varijable, budući da dotična funkcija koristi PspCidTable tablicu kako bi vratila EPROCESS blok procesa opisanog identifikatorom: kd> u nt!pslookupprocessbyprocessid+0x12 nt!pslookupprocessbyprocessid+0x12: 805d1d94 ff8ed dec dword ptr [esi+0d4h] 805d1d9a ff35c push dword ptr [nt!pspcidtable (805629c0)] 805d1da0 e817ad0300 call nt!exmaphandletopointer (8060cabc) Slika 3.33: Pronalazak PspCidTable varijable pretragom metode PsLookupProcessByProcessId() Ova metoda relativno je nepouzdana jer u sljedećim inačicama operacijskog sustava moţe biti promijenjena struktura i mehanizam funkcije - npr. funkcija ne mora koristiti globalnu tablicu ručica nego listu tablice ručica iz EPROCESS bloka. Drugu metodu predloţio je Edgar Barbosa [27], a temelji se na korištenju debug podataka iz posebnog odjeljka, tzv. PCR bloka (engl. Processor Control Region). 44

48 PCR blok ovisi o procesoru na kojemu se program trenutno izvodi, no ta činjenica nije bitna za napadača. Do PCR bloka moguće je doći naredbom!pcr WinDBG debuggera ili programski naredbom mov eax, fs:[0x1c]. Vaţnija polja u PCR bloku prikazana su na sljedećoj slici: kd> dt nt!_kpcr +0x000 NtTib : _NT_TIB +0x020 Prcb : Ptr32 _KPRCB +0x034 KdVersionBlock : Ptr32 Void +0x038 IDT : Ptr32 _KIDTENTRY +0x03c GDT : Ptr32 _KGDTENTRY Slika 3.34: Važnija polja PCR bloka u operacijskom sustavu Windows XP Član KdVersionBlock predstavlja pokazivač na debug podatke koji su definirani KDDEBUGER_DATA32/64 strukturom - ta struktura moţe se pronaći u datoteci wdbgexts.h samog debuggera. Struktura sadrţava adrese mnogih privatnih jezgrinih varijabli, izmeďu ostalog i adresu PspCidTable varijable. Vaţno je spomenuti da KdVersionBlock član PCR bloka ne postoji na Windows 2000 operacijskom sustavu pa se ova metoda ne moţe koristiti. Treći način dohvata adrese ove varijable izravno je korištenje Microsoftovih debug podataka iz sigurnosne aplikacije - to je metoda koja se koristi u praktičnom radu. Sama globalna tablica PspCidTable ima relativno sloţenu višerazinsku strukturu koja podsjeća na x86 mehanizam straničenja. Objašnjavanje cjelokupne tablice zahtijevalo bi puno prostora pa struktura ovdje neće biti objašnjena - više o samom mehanizmu straničenja moţe se pročitati u Intelovim priručnicima ili literaturi [26], dok se o samoj strukturi PspCidTable tablice moţe pročitati u knjizi [28] (Object Manager poglavlje). Struktura same tablice nešto je izmijenjena u novijim inačicama operacijskog sustava u odnosu na onu opisanu u prethodno navedenoj literaturi pa bi čitatelj sam trebao istraţiti razlike, ovisno o inačici operacijskog sustava. Globalna tablica ručica sadrţava strukture pod nazivom HANDLE_TABLE_ENTRY. Ta struktura u operacijskom sustavu Windows XP ima sljedeći oblik: kd> dt nt!_handle_table_entry +0x000 Object : Ptr32 Void +0x000 ObAttributes : Uint4B +0x000 InfoTable : Ptr32 _HANDLE_TABLE_ENTRY_INFO +0x000 Value : Uint4B +0x004 GrantedAccess : Uint4B +0x004 GrantedAccessIndex : Uint2B +0x006 CreatorBackTraceIndex : Uint2B +0x004 NextFreeTableEntry : Int4B Slika 3.35: HANDLE_TABLE_ENTRY struktura Prvi član te strukture je upravo pokazivač na objekt pa na taj način sigurnosna aplikacija moţe pronaći sve procese (EPROCESS blokove) koji su aktivni u sustavu prolaskom kroz globalnu tablicu ručica. MeĎutim, napadači su doskočili i toj tehnici pa (osim iz liste aktivnih procesa i liste tablice ručica), uklanjaju EPROCESS blok i iz globalne tablice ručica! Napadač pritom ima iste probleme vezane za ručice koji su spomenuti i ranije. Dodatno, prije 45

49 uništavanja skrivenog procesa, EPROCESS blok mora biti prisutan u globalnoj tablici ručica. Ukoliko to nije slučaj, doći će do rušenja sustava jer će se referencirati pokazivač na proces koji ne postoji. Napadači to rješavaju na način da prijave rutinu povratnog poziva koja će se pozvati prije nego što će proces biti uništen - to realiziraju metodom PsSetCreateProcessNotifyRoutine() [29]. Čini se da otkrivanje ovakvih rootkita nije jednostavno. Proces ne postoji u listi aktivnih procesa, u listi tablica ručica niti u globalnoj tablici ručica. Prisutnost rootkita moţe se otkriti eventualno provjerom registriranih rutina povratnog poziva, no to nije sigurna metoda - rootkit ne mora registrirati tu rutinu ako nije spremnički postojan (to će dovesti do rušenja sustava prilikom njegovog gašenja, no to će se dogoditi samo jednom pa korisnik vjerojatno neće posumnjati na zloćudni program). Odgovor na pitanje kako se takvi skriveni procesi otkrivaju ponovno je sadrţan u činjenici da se u sustavu ne izvode procesi, već dretve. U radu [30] autori spominju kako se u PspCidTable tablici čuvaju ručice svih dretvi u sustavu i da brisanjem svih dretvi nekog procesa iz te tablice proces ne moţe ostati aktivan - točnije da je nemoguće sakriti dretve iz PspCidTable tablice na isti način kao i procese jer dretve procesa neće dobivati potrebno procesorsko vrijeme. Autor smatra da ta tvrdnja nije točna (barem za operacijske sustave Windows 2000 i Windows XP, vrlo vjerojatno i za ostale). O izvoďenju dretvi brine se raspodjelitelj dretvi koji sve dretve u sustavu čuva u nekoliko različitih lista. Te liste podloţne su velikim promjenama izmeďu pojedinih inačica operacijskog sustava, no u inačicama Windows 2000 i XP (s velikom vjerojatnošću i u ostalim inačicama) nemaju veze s PspCidTable tablicom. Kako bi se ta tvrdnja dokazala, za demonstraciju je korišten FUTo rootkit [29] koji ima mogućnost skrivanja svih dretvi zadanog procesa u PspCidTable tablici. Načinjen je iznimno jednostavan program koji u petlji u datoteku zapisuje trenutno vrijeme, a zatim čeka 3 sekunde prije nastavka izvoďenja. Dotični program je pokrenut, a zatim skriven FUTo rootkitom uz opciju skrivanja svih dretvi. Ako su autori rada [30] u pravu, u datoteci ne bi trebalo pisati ništa od trenutka kada je proces skriven. MeĎutim, u datoteci su prisutni svi zapisi koji su nastali nakon skrivanja procesa, što je znak da je dretva i dalje aktivna. Činjenica se moţe provjeriti i direktnom "šetnjom" kroz liste raspodjelitelja dretvi uz pomoć WinDBG debuggera. Jedino ograničenje koje nameće FUTo rootkit uz opciju skrivanja svih dretvi jest da program nema grafičko sučelje - tu je činjenicu moguće objasniti time što upravitelj grafičkim sučeljem vjerojatno treba ručicu na dretvu koja ţeli koristiti grafičke objekte ("grafičke dretve" se tretiraju posve drugačije od normalnih), no to nema veze s raspodjeliteljem dretvi. Dretve u sustavu mogu se otkriti na tri načina. Prvi je način već spomenuto korištenje listi raspodjelitelja dretvi. Te su liste podloţne znatnim promjenama u pojedinim inačicama operacijskog sustava Windows, no zasad sve inačice sadrţavaju listu (točnije polje od 32 liste) čija je glava u operacijskim sustavima Windows 2000 i Windows XP opisana privatnom varijablom KiDispatcherReadyListHead. U operacijskim sustavima Windows 2003, Windows Vista, Windows 2008 Server i najnovijem Windows 7, adresa polja lista moţe se pronaći u PRCB bloku (engl. Processor Control Block) koji se, prema slici 3.34, nalazi u PCR bloku. Dotični blok ima sljedeći oblik (za Windows 7): 46

50 kd> dt nt!_kprcb +0x004 CurrentThread : Ptr32 _KTHREAD +0x008 NextThread : Ptr32 _KTHREAD +0x00c IdleThread : Ptr32 _KTHREAD +0x1aa0 WaitListHead : _LIST_ENTRY +0x1ab4 DeferredReadyListHead : _SINGLE_LIST_ENTRY +0x1ae0 DispatcherReadyListHead : [32] _LIST_ENTRY Slika 3.36: Važniji članovi PRCB bloka vezani za strukture raspodjelitelja dretvi Osim polja od 32 liste, potrebno je uočiti i listu dretvi koje čekaju - na tu listu pokazuje WaitListHead član u KPRCB bloku. U novijim inačicama operacijskog sustava znatno je lakše doći do adresa svih struktura raspodjelitelja dretvi jer je do adrese PCR bloka moguće doći izravno, dok se u starijim inačicama mora pretraţivati spremnik u potrazi za privatnom varijablom. Sve te liste mogu se prolaziti na isti način kao i liste procesa ili liste tablice ručica, jer se u oba slučaja radi o dvostruko povezanim listama koje u ovom slučaju sadrţavaju sve dretve prisutne u sustavu. Drugi način za otkrivanje dretvi ne koristi strukture samog raspodjelitelja dretvi. Dretve su, kao i procesi, opisani vlastitim blokom koji se naziva ETHREAD blok. Slično procesima, dretve su takoďer povezane u listu - odnosno 3 liste (u operacijskom sustavu Windows XP) - listu čekanja (engl. wait list), listu dretvi u redu čekanja na sinkronizacijski objekt (engl. queue list) i "normalnu" listu svih dretvi u sustavu. Pokazivači na dotične liste prisutni su u KTHREAD bloku koji se nalazi na samom početku ETHREAD bloka: kd> dt nt!_kthread +0x000 Header : _DISPATCHER_HEADER +0x010 MutantListHead : _LIST_ENTRY +0x020 Teb : Ptr32 Void +0x024 TlsArray : Ptr32 Void +0x060 WaitListEntry : _LIST_ENTRY +0x118 QueueListEntry : _LIST_ENTRY +0x1b0 ThreadListEntry : _LIST_ENTRY Slika 3.37: Važniji članovi KTHREAD bloka Strukture raspodjelitelja dretvi uglavnom su samo "glave" - pokazivači na početak ovih lista. Dostupna literatura jednoglasna je u činjenici da uklanjanjem dretve iz struktura samog raspodjelitelja napadačev program sigurno ne dobiva potrebno procesorsko vrijeme. MeĎutim, literatura nije toliko detaljna niti precizna oko lista koje povezuju dretve. Autor je mišljenja da je nemoguće ukloniti dretvu iz ovih lista a da se ona i dalje normalno izvodi na procesoru jer se radi o istim listama, tj. strukture raspodjelitelja uglavnom su pokazivači na te liste. Preciznije, ako napadač ukloni dretvu iz upravo navedenih lista, ta dretva više neće dobivati procesorsko vrijeme i napadačev zloćudni program neće raditi nikakav posao. 47

51 Još jedan način "prolaska" kroz sve dretve u sustavu jest umetnuta modifikacija funkcije KiSwapContext() (ovoga puta dobroćudna, umetnuta od strane sigurnosne aplikacije). Dotična funkcija poziva se svaki put kada neka druga dretva u sustavu treba nastaviti ili započeti svoje izvoďenje i zaduţena je za samu promjenu konteksta dretve. Budući da se napadačeve dretve kad-tad moraju izvesti, dobroćudna će modifikacija funkcije za zamjenu konteksta "uhvatiti" napadačevu dretvu. Funkcija je privatna i rezervirana za jezgru pa je opet prisutan problem pronalaska njene adrese. Prolaskom kroz sve dretve sigurnosna aplikacija moţe utvrditi koji su procesi aktivni jer ETHREAD (točnije, KTHREAD) blok sadrţava pokazivač na EPROCESS blok procesa kojem dretva pripada. Napadač ne moţe ukloniti dretvu na način na koji je mogao ukloniti proces iz liste jer program ne bi dobivao procesorsko vrijeme. Ipak, vrlo vješti napadači uspješno su izbjegli i taj problem! Umjesto da prepuste izvršavanje dretvi vlastitog zloćudnog programa operacijskom sustavu, iznimno talentirani napadači odlučili su implementirati vlastiti raspodjelitelj dretvi. Originalni raspodjelitelj dretvi ne zna za dodatni kojeg je postavio napadač, a dretve koje je stvorio napadač izvode se isključivo na "privatnom" raspodjelitelju dretvi. Novi raspodjelitelj se ugraďuje vrlo duboko u sustav, no modifikacije koje vrši vrlo su "plitke" jer su načinjene najčešće na jednom mjestu. Primjer takvog rootkita je phide2 rootkit 5. Phide2 iznimno je sofisticiran rootkit koji koristi tehniku "izvlačenja izvršivog teksta" iz jezgre kako bi došao do odgovarajućih struktura, ali i izvršivog teksta raspodjelitelja dretvi. Modifikacije koje vrši phide2 rootkit vrlo su male i prisutne su u NtYieldExecution() metodi, ili (u nekim verzijama) duboko u samom raspodjelitelju. Autor nije siguran na koji način se phide2 rootkit otkriva jer u dostupnoj literaturi postoji vrlo malo informacija o samom otkrivanju dotičnog rootkita. Za pretpostaviti je da se radi o implementacijsko-specifičnom djelovanju sigurnosne aplikacije - eksplicitno se traţe modifikacije u NtYieldExecution() metodi ili u raspodjelitelju dretvi za koje je poznato da ih vrši phide2 rootkit, iako to nipošto nije sveobuhvatna metoda. Jedna od metoda koja bi se moţda mogla koristiti je "šetnja" kroz spremnička zauzeća - svaki program neminovno koristi spremnik, a strukture tih alokacija su djelomično poznate, iako nimalo jednostavne. Ipak, skrivanje alokacija se ne čini kao jednostavan pothvat za napadača pa bi se vrlo sofisticirane rootkite moţda moglo traţiti tim pristupom. Danas najnapredniji rootkiti su oni koji uopće ne koriste procese! Nakon ugradnje rootkita u sustav, stvara se sustavska dretva koja se izvodi u kontekstu System procesa - rootkit proces uopće ne postoji pa ga nije potrebno ni skrivati. TakoĎer, teško je razlikovati zloćudnu dretvu koja se izvodi u okruţenju procesa u kojem postoji velik broj ostalih (dobroćudnih) dretvi. Izolacija zloćudne dretve bez procesa roditelja u tako velikom skupu dretvi problem je koji je i dalje prisutan za autore sigurnosnih aplikacija. 5 Phide2 rootkit

52 3.4 Specifičnosti pri skrivanju upravljačkih programa Za razliku od metoda skrivanja procesa, napadači su mnogo manje maštoviti kada je skrivanje upravljačkih programa u pitanju. U korisničkom načinu rada upravljački programi skrivaju se na isti način kao i procesi: IAT/EAT modifikacijama ili umetnutim modifikacijama funkcije NtQuerySystemInformation() koja se koristi i za dohvat upravljačkih programa prisutnih u sustavu. U jezgrinom načinu rada nekada najčešće korištena metoda bila je modifikacija unosa iste funkcije u SSDT tablici, no takva modifikacija lako se otkriva pa ju napadači danas rijetko koriste. Slično procesima, upravljački programi su takoďer vezani u dvostruko povezanu listu. Na slici 3.29 vidljiv je dio DRIVER_OBJECT strukture do koje se moţe doći ili korištenjem IoGetDeviceObjectPointer() metode i upotrebom pokazivača na DRIVER_OBJECT strukturu ili se ta struktura koristi automatski iz ulazne rutine upravljačkog programa. Sama struktura u operacijskom sustavu Windows XP ima sljedeći oblik: kd> dt nt!_driver_object +0x004 DeviceObject : Ptr32 _DEVICE_OBJECT +0x014 DriverSection : Ptr32 Void +0x038 MajorFunction : [28] Ptr32 long Slika 3.38: Važniji članovi DRIVER_OBJECT strukture DriverSection član te strukture zapravo pokazuje na potpuno nedokumentiranu strukturu nazvanu MODULE_ENTRY koja prema [25] (dopunjena uz samostalno istraţivanje) ima sljedeći oblik: typedef struct _MODULE_ENTRY { LIST_ENTRY ModuleListEntry; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID ModuleBaseAddress; PVOID ModuleEntryAddress; ULONG_PTR ModuleSize; UNICODE_STRING ModulePath; UNICODE_STRING ModuleName; } MODULE_ENTRY, *PMODULE_ENTRY; Slika 3.39: MODULE_ENTRY struktura Upravo MODULE_ENTRY strukture vezane su u dvostruko povezanu listu, pri čemu glavu te liste predstavlja još jedna privatna varijabla jezgre - PsLoadedModuleList. Sama lista prikazana je na slici

53 Slika 3.40: Lista MODULE_ENTRY struktura koja povezuje upravljačke programe Na potpuno isti način kao i kod skrivanja procesa, napadač moţe sakriti upravljački program uklanjanjem odgovarajuće MODULE_ENTRY strukture iz gornje liste jer se sve funkcije za dohvat informacija o upravljačkim programima temelje na prolasku kroz tu listu. Za razliku od procesa, upravljački programi nemaju vlastitu tablicu ručica (tablica ručica im ne treba jer im je dostupna bilo koja ručica u sustavu) pa se ne moţe koristiti metoda prolaska kroz listu tablica ručica za otkrivanje skrivenih upravljačkih programa. MeĎutim, u operacijskom sustavu Windows postoji podatkovna struktura koja se naziva direktorij objekata (engl. Object Directory) i opisana je privatnom strukturom jezgre OBJECT_DIRECTORY. Sam direktorij objekata sadrţava većinu objekata koji su podrţani operacijskim sustavom, npr. ureďaje, upravljačke programe, dijeljeni spremnički prostor, sinkronizacijske mehanizme, pristupne točke i druge objekte. Direktorij objekata podatkovna je struktura koja je potpuno neovisna od gore navedene liste upravljačkih programa pa upravljački program koji je uklonjen iz gornje liste svejedno ostaje vidljiv u direktoriju objekata. Direktorij objekata organiziran je kao stablo koje sadrţava unose organizirane u pretince (engl. hash buckets), tako da prolaţenje kroz samu strukturu nije nimalo trivijalno. Mnogo više o samoj podatkovnoj strukturi moţe se pročitati u knjizi [28] (takoďer Object Manager poglavlje). U istoj literaturi moţe se pronaći i cjelokupan izvorni tekst aplikacije koja ispisuje sve objekte u sustavu koristeći se direktorijem 50

54 objekata. Kao već gotovu i mnogo dotjeraniju aplikaciju za pregled direktorija objekata, korisnik moţe koristiti WinObj aplikaciju 6. Naravno, napadači su vrlo brzo počeli modificirati direktorij objekata na način da uklanjaju unos o upravljačkom programu kojeg ţele sakriti. Primjer skrivanja dostupan je na web stranici [31]. Ispitivanjem te metode skrivanja, autor nikako nije uspio postići da upravljački program zaista bude skriven - upravljački program bio je vidljiv pomoću WinObj aplikacije, iako je bio uklonjen iz direktorija objekata i liste upravljačkih programa. Činjenica da je upravljački program ipak bio vidljiv, više se moţe pripisati autorovoj nepaţnji nego nedjelotvornosti dotične metode. U dostupnoj literaturi ne spominje se metoda otkrivanja ovako skrivenih upravljačkih programa, a ni autor ne zna na koji način se ovakve modifikacije otkrivaju jer se ispitivanja nisu mogla provesti. Pretraţivanje jezgrinog prostora ili nekog podskupa spremničkog prostora jezgre u potrazi za potpisom upravljačkog programa (npr. zaglavlje PE formata) uvijek je moguće provesti, no ta je metoda vrlo nepouzdana. TakoĎer, u novije vrijeme autori rootkita uopće ne skrivaju upravljačke programe na ovako navedene načine. Jedan od načina na koje se skrivanje upravljačkog programa moţe izbjeći jest da se modificira neki standardni upravljački program kojeg koristi Windows operacijski sustav, a koji ne sadrţi "vaţan" izvršivi tekst. Idealni kandidat je Beep upravljački program, zaduţen za zvučnu signalizaciju korisniku da se neka radnja ne moţe obaviti. Zloćudni program pritom ili prepisuje cjelokupni izvršivi tekst Beep upravljačkog programa, ili stvara novi odsječak u datoteci i djelomice preusmjerava tijek izvoďenja na taj odsječak. Primjer rootkita koji vrši takve modifikacije je Rustock [7]. Drugi način nešto je sloţeniji - nakon što se upravljački program napadača pokrene, on zauzima spremnički prostor potreban za smještanje cjelokupne vlastite datoteke u taj odsječak spremnika, prepisuje vlastiti izvršivi tekst u taj spremnik (pazeći pritom na relokacije i "popravke" relativnih odmaka) i zatim briše vlastitu datoteku s diska i odstranjuje sam upravljački program. Na taj način ne postoji potreba za skrivanjem upravljačkog programa jer on zapravo i ne postoji. Problem predstavlja gašenje računala ili stanje hibernacije jer se "upravljački program" pritom uklanja iz spremnika. Napadači tom problemu doskaču na način da osluškuju dogaďaje poput gašenja sustava ili ulaska u stanje hibernacije i u slučaju takvih dogaďaja prebacuju izvršivi tekst natrag u neku datoteku (čak i datoteku same jezgre) i prilikom ponovnog podizanja ponovno ga smještaju u spremnik i pokreću. Takve akcije zahtijevaju mnogo modifikacija i podloţne su otkrivanju pa tehniku premještanja cjelokupnog rootkita u spremnik koriste uglavnom nepostojani rootkiti. 6 WinObj aplikacija tvrtke Microsoft

55 3.5 Specifičnosti pri skrivanju datoteka Datoteke i direktoriji u datotečnom sustavu u korisničkom načinu rada skrivaju se najčešće IAT/EAT modifikacijama ili umetnutim modifikacijama funkcija FindFirstFile(), FindNextFile(), CreateFile(), ReadFile() i OpenFile() u kernel32.dll datoteci, odnosno NtQueryDirectoryFile(), NtCreateFile(), NtOpenFile() i NtReadFile() funkcija u ntdll.dll datoteci. Iste funkcije kao u ntdll.dll datoteci skrivaju se i u jezgrinom načinu rada, modifikacijom unosa u SSDT tablici. Budući da je za skrivanje datoteka i direktorija potrebno modificirati mnogo unosa, a mnoštvo modifikacija povećava vjerojatnost da zloćudni program bude otkriven, napadači su gotovo u potpunosti napustili ovakav način skrivanja datoteka i direktorija. Tome pridonosi i činjenica da se modifikacije SSDT tablice jednostavno otkrivaju. Napadači za skrivanje direktorija i datoteka danas gotovo isključivo koriste tri metode i sve su vezane za IRP pakete. Prva metoda već je opisana u potpoglavlju o općenitom skrivanju objekata u jezgrinom načinu rada - modifikacija tablice funkcijskih pokazivača upravljačkog programa koji je zaduţen za datotečni sustav. Primjer takve modifikacije naveden je na slici Modificiraju se najčešće upravljački programi ntfs.sys (zaduţen za NTFS datotečni sustav) i fastfat.sys (zaduţen za FAT(32) datotečni sustav). U oba slučaja nastoji se modificirati što manje pokazivača kako bi modifikacije bile što neprimjetnije. Dostupna literatura nije precizna o vrstama i broju modifikacija koje su potrebne, no autor pretpostavlja da su dovoljne samo dvije modifikacije, tj. zamjena pokazivača na funkcije na dva indeksa označena sljedećim simboličkim konstantama: IRP_MJ_CREATE IRP_MJ_DIRECTORY_CONTROL Slika 3.41: Indeksi IRP funkcija koje napadači mijenjaju Funkcija na elementu tablice s indeksom IRP_MJ_CREATE poziva se svaki puta kada se stvara neka datoteka ili direktorij u operacijskom sustavu, ali i prilikom otvaranja postojeće datoteke ili direktorija. Napadačeva funkcija najčešće zabranjuje otvaranje datoteke ili direktorija koji se ţeli sakriti. IRP_MJ_DIRECTORY_CONTROL element tablice pokazuje na funkciju koja se poziva svaki put kada se zatraţi lista direktorija ili datoteka. Jasno je da modifikacijom ovog unosa napadač nastoji ukloniti vlastitu datoteku ili direktorij iz liste. Način otkrivanja ovakvih modifikacija spomenut je u potpoglavlju o općenitom skrivanju objekata u jezgrinom načinu rada. Druga često korištena metoda za skrivanje datoteka i direktorija proizlazi iz slojevite strukture upravljačkih programa. Svaki ureďaj u operacijskom sustavu Windows moţe imati više upravljačkih programa zaduţenih za njegov rad. Svi upravljački programi tvore stog - upravljački program na najniţem nivou poznaje sam protokol 52

56 komunikacije s ureďajem (npr. tvrdim diskom) ili sabirnicom i u potpunosti je sklopovski usmjeren (poznaje sve osobine ureďaja, npr. njegove registre i slično). Upravljački program na najvišem nivou više je usmjeren korisniku odnosno aplikaciji, pruţa oblikovane podatke za korisnika, vraća eventualne informacije o greškama i slično. Svi podaci usmjereni od aplikacije prema ureďaju ili od ureďaja prema aplikaciji prolaze kroz cijeli stog upravljačkih programa koji su zaduţeni za taj ureďaj. Bilo koji upravljački program u stogu moţe modificirati podatke za upravljački program koji je neposredno ispod njega ili neposredno iznad njega. Takav način uslojavanja prisutan je primjerice u OSI modelu mreţne arhitekture 7. Dodatno, bilo koji upravljački program u stogu moţe prekinuti "propagaciju" IRP paketa prema ureďajima koji se nalaze ispod njega. Slojevitost upravljačkih programa vrlo je primamljiva za napadače - potrebno je samo napisati upravljački program i umetnuti ga u stog ciljnog ureďaja. Taj upravljački program modificira podatke i šalje tako modificirane podatke korisniku ili ureďaju. U pogledu skrivanja direktorija i datoteka, napadači umeću vlastiti upravljački program iznad upravljačkog programa datotečnog sustava (ntfs.sys ili fastfat.sys) i šalju modificirane podatke ako su primljeni zahtjevi za čitanje/otvaranje datoteka ili direktorija koje napadač ţeli sakriti. Ovakav tip upravljačkog ureďaja naziva se filtrirajući upravljački uređaj datotečnog sustava (engl. file system filter driver). Takvi upravljački programi nisu jednostavni kao neke druge vrste upravljačkog programa. Više o stvaranju takvih upravljačkih programa, ali i vlastitih upravljačkih programa za datotečni sustav moţe se pročitati u knjizi [32]. Primjer upravljačkog programa kakvog bi mogao koristiti napadač nalazi se u knjizi [25]. Najčešće se otkrivaju prolaskom kroz stog upravljačkih programa - upravljački programi vezani su pokazivačem u DEVICE_OBJECT strukturi - član se naziva AttachedDevice. Treća metoda takoďer je vezana uz IRP pakete. Kako bi se objasnila, potrebno je detaljnije razmotriti način slanja IRP paketa i "prolaska" IRP paketa kroz stog upravljačkih programa. Prilikom stvaranja IRP paketa, dio jezgre operacijskog sustava koji je zaduţen za taj zadatak automatski zna koliko je upravljačkih programa u stogu ureďaja za koji je dotični IRP paket namijenjen. Zbog toga nastaje "veliki" IRP paket s poljem tzv. IO_STACK_LOCATION struktura, pri čemu je svaka struktura (svaki element polja) namijenjena jednom upravljačkom programu u stogu. Upravljačkom programu koji je najbliţi korisniku (na vrhu stoga) odgovara zadnji element tog polja, odnosno zadnja IO_STACK_LOCATION struktura. Najniţem upravljačkom programu, onome koji je najbliţi ureďaju (na dnu stoga) odgovara prvi element polja u IRP paketu, odnosno prva IO_STACK_LOCATION struktura. U samom IRP paketu čuva se podatak o trenutnoj IO_STACK_LOCATION strukturi, tako da upravljački program ne mora znati ništa o ostalim upravljačkim programima ispod ili iznad njega - dovoljno je pozvati metodu IoGetCurrentIrpStackLocation(). Način propagacije IRP paketa kroz upravljačke programe prikazan je na slici OSI model

57 Slika 3.42: Propagacija IRP paketa kroz stog upravljačkih programa Na gornjoj slici upravljački program 1 prvi je na stogu i njemu pripada zadnja IO_STACK_LOCATION struktura. Upravljački program 3 posljednji je na stogu (najbliţi ureďaju) i on "završava" (prihvaća) IRP paket pozivom metode IoCompleteRequest(). Vidljivo je da se upravljanje s jednog na drugi upravljački program, odnosno propagacija IRP paketa obavlja pozivom funkcije IoCallDriver(). Upravo modifikacijom te metode (ili interne IofCallDriver() metode) rootkiti mogu preusmjeriti slanje IRP paketa na vlastiti upravljački program koji vrši skrivanje odgovarajućih datoteka i direktorija. Takvom metodom koristi se Neprodoor rootkit 8. Otkrivanje ovakvih modifikacija temelji se zapravo na otkrivanju modifikacija Io(f)CallDriver() metode. Najčešće se radi o umetnutim modifikacijama pa se mogu primijeniti svi mehanizmi za otkrivanje takvih modifikacija spomenuti ranije. Popularnu metodu za skrivanje datoteka i direktorija predstavljaju i takozvani alternativni podatkovni tokovi (engl. ADS - Alternate Data Streams) koji su svojstvo samog datotečnog sustava NTFS. ADS je tehnika koja omogućava da se unutar već postojećih datoteka umetne novi sadrţaj bez (vidljivog) povećanja veličine datoteke, njene funkcionalnosti i slično. Ta funkcionalnost prisutna je prije svega zbog ostvarivanja kompatibilnosti s Macintosh HFS datotečnim sustavom, ali u samom operacijskom sustavu koristi se vrlo rijetko. Ne postoji mogućnost isključivanja ADS funkcionalnosti - ona je uvijek prisutna u datotečnom sustavu NTFS i ne moţe se izbjeći. Za otkrivanje alternativnih 8 Neprodoor rootkit

58 podatkovnih tokova moţe se koristiti LADS alat [33], a programski se zasniva na korištenju programskom sučelju za stvaranje sigurnosne kopije (engl. backup API). Općeniti način za otkrivanje skrivenih datoteka je usporedba liste datoteka koja je dobivena preko programskog sučelja (npr. FindFirst/NextFile() funkcijama) s listom datoteka koja je dobivena metodama niske razine. Kao metoda niske razine koristi se direktni prolazak kroz strukture datotečnog sustava - u slučaju NTFS datotečnog sustava, prolazi se izravno kroz glavnu tablicu datoteka (engl. MFT - Master File Table). Više o strukturi NTFS datotečnog sustava moţe se pročitati u literaturi [26], a posebno u dokumentaciji Linux-NTFS projekta 9 koja vrlo detaljno objašnjava strukturu datotečnog sustava. 3.6 Specifičnosti pri skrivanju mrežnog prometa i veza Skrivanje mreţnog prometa i veza vrlo je slično skrivanju datoteka. U korisničkom načinu rada napadači najčešće ne pokušavaju sakriti mreţne veze jer sve funkcije za dohvat informacija o mreţnim vezama koriste komunikaciju s tcpip.sys upravljačkim programom. U korisničkom načinu rada postoji previše funkcija koje bi se morale modificirati (GetIpStatistics(), GetIpStatisticsEx(), GetUdpStatistics(), GetUdpStatisticsEx(), GetUdpTable() i mnoge druge). Modifikacije SSDT tablice takoďer nisu pretjerano korisne jer je teško odrediti kada je točno pozvana neka metoda za dohvat mreţnih informacija. Dvije najčešće metode za skrivanje mreţnog prometa i veza identične su skrivanju datoteka i direktorija - modifikacija tablice funkcijskih pokazivača samog tcpip.sys upravljačkog programa i umetanje filtrirajućeg upravljačkog programa iznad tcpip.sys upravljačkog programa. Za demonstraciju modifikacije tablice funkcijskih pokazivača korišten je program prisutan u literaturi [25]. Prije ugradnje zloćudnog upravljačkog programa koji mijenja tablicu funkcijskih pokazivača upravljačkog programa tcpip.sys, dotična tablica ima sljedeći oblik: kd>!drvobj tcpip Driver object (ffbcbda0) is for: \Driver\Tcpip kd> dt nt!_driver_object ffbcbda0 +0x01c DriverName : _UNICODE_STRING "\Driver\Tcpip" +0x038 MajorFunction : [28] 0xf8fccdd1 long tcpip!tcpdispatch+0 kd> dps ffbcbda0+38 l28 ffbcbdd8 f8fccdd1 tcpip!tcpdispatch ffbcbe10 f8fccdd1 tcpip!tcpdispatch ffbcbe44 f8fccdd1 tcpip!tcpdispatch Slika 3.43: Dohvat i pregled tablice funkcijskih pokazivača tcpip.sys upravljačkog programa prije modifikacija 9 Dokumentacija Linux-NTFS projekta

59 Nakon ugradnje zloćudnog upravljačkog programa tablica ima sljedeći oblik: kd> dps ffbcbda0+38 l28 ffbcbdd8 f8fccdd1 tcpip!tcpdispatch ffbcbe10 faf7f560 irphook!hookeddevicecontrol ffbcbe44 f8fccdd1 tcpip!tcpdispatch Slika 3.44: Tablica nakon modifikacija Iz gornje slike jasno je vidljivo da je funkcijski pokazivač promijenjen u tablici i da pokazuje na rootkit funkciju iz upravljačkog programa irphook. Način otklanjanja ovakvih modifikacija već je opisan. Neki napadači odlučili su ići još dublje u sustav i umjesto modifikacije upravljačkog programa samog protokola (npr. tcpip.sys), zloupotrebljavaju samo programsko sučelje prema mreţnom sklopovlju, tzv. NDIS sučelje (engl. Network Driver Interface Specification). Sama tehnika najčešće se sastoji u modifikacijama EAT tablice ili umetnutim modifikacijama funkcija ndis.sys upravljačkog programa. Funkcije koje se modificiraju su Ndis(De)RegisterProtocol() i NdisOpen(Close)Adapter(). Mnogo više o ovakvim modifikacijama moţe se pročitati u radu jednog od najpoznatijih rootkit istraţivača, Alexandera Tereshkina [34]. 56

60 4. Praktični rad Uz diplomski rad razvijen je i programski sustav s odgovarajućim grafičkim sučeljem koji prikazuje listu trenutno aktivnih procesa u sustavu, ima mogućnost otkrivanja rootkit procesa te mogućnost njihovog uklanjanja/gašenja. Lista procesa sadrţava mnoge bitne informacije o procesu, poput imena procesa, identifikatora, zauzeća spremnika i procesorskog vremena i dr. Sustav posjeduje mogućnost pretraţivanja SSDT tablice u potrazi za njenim modifikacijama i mogućnost uklanjanja tih modifikacija na početne postavke operacijskog sustava. TakoĎer, program aktivno nadzire procese u sustavu. 4.1 Odabir programskog jezika Prije izrade praktičnog rada bili su postavljeni kriteriji koje je programski jezik u kojemu bi rad bio ostvaren morao zadovoljiti. Kriteriji su sljedeći: objektna orijentiranost (OO) prenosivost (P) minimalno zauzeće resursa (MZ) jednostavnost povezivanja sa upravljačkim programom i općenito jednostavnost interakcije sa sustavom (JP) sigurnost (S) jednostavnost izrade grafičkog sučelja i općenito jednostavnost rada u jeziku (JS) Razmatrajući navedene kriterije, sljedeća tablica pokazuje programske jezike koji su bili mogući odabir, kao i njihovo ispunjavanje zadanih kriterija: Programski jezik OO P MZ JP S JS C C C# Java Tablica 4.1: Razmatrani programski jezici i njihovo zadovoljavanje zadanih kriterija Iz gornje tablice vidljivo je da svi jezici podjednako ispunjavaju kriterije, no ne na jednak način. Programski jezik Java eliminiran je prvi zbog nedostatka dobrog alata 57

61 za povezivanje s upravljačkim programom i općenitu interakciju sa sustavom. Dostupno je Java JNI programsko sučelje, no ono je prilično nespretno za učestalo korištenje pa je iz tog razloga odbačeno. TakoĎer, programski jezik Java nije najbolje rješenje za izradu aplikacija s iole sloţenijim grafičkim sučeljima zbog brojnih nelogičnosti prilikom izrade istih. Usprkos tome, prenosivost i sigurnost programskog jezika Java na višoj su razini od svih razmatranih programskih jezika. Upravljački program koji je sastavni dio praktičnog rada ostvaren je u programskom jeziku C, iako se koriste neke rudimentarne mogućnosti jezika C++. Ipak, programski jezik C nije nipošto bio pogodan za razvoj čitavog sustava jer nema nikakvu podršku za izgradnju grafičkog sučelja, a dostupne biblioteke (npr. GTK biblioteka) nisu sasvim jednostavne za korištenje. TakoĎer, jezik nije objektno orijentiran, a objektna orijentiranost bila je nuţan kriterij koji je jezik morao zadovoljiti. Programski jezik C# zadovoljava mnoge kriterije, vrlo je siguran, ima izvrsnu podršku za brzi razvoj grafičkog sučelja i vrlo dobro sučelje prema samom sustavu. MeĎutim, kao i programski jezik Java, programski jezik C# zauzima relativno mnogo računalnih resursa i u brzini zaostaje za programskim jezicima C i C++. Prenosivost programskog jezika C# vrlo je osjetljiva i diskutabilna tema - iako postoje alati koji omogućavaju izvoďenje programa u programskom jeziku C# u drugim okruţenjima, širenje na druge platforme s jedne strane zaustavlja sama tvrtka Microsoft, a s druge strane korisnici tih operacijskih sustava koji tvrde da na taj način Microsoft ţeli preuzeti vlast i primat nad njihovim sustavima. Primjer takvog alata je Mono konceptualni okvir 10 (engl. Mono framework). Kao implementacijski programski jezik na kraju je odabran jezik C++. Jezik C++ objektno je orijentiran jezik, vrlo je brz, standardno se dobro povezuje sa sustavom i uz dodatne biblioteke relativno lako se oblikuje grafičko sučelje. Kao konceptualni okvir za razvoj grafičkog sučelja, ali i kao podrška drugim standardnim zadacima, korišten je wxwidgets konceptualni okvir [35]. Korištenjem wxwidgets konceptualnog okvira postignuta je prenosivost grafičkog sučelja na operacijske sustave Linux i Mac OS X, uz operacijski sustav Windows koji je standardno podrţan. Sigurnost programskog jezika C++, odnosno njegova otpornost na pogreške, sigurno nije njegova jača strana. Korištenje jezika niske razine, poput jezika C i C++ povećava vjerojatnost postojanja sigurnosnih propusta, no kako se radi prije svega o demonstracijskoj aplikaciji, taj aspekt sustava nije toliko značajan. Sveukupno, u radu su korištena dva programska jezika uz jedan konceptualni okvir: za izradu grafičkog sučelja korišten je jezik C++ i wxwidgets konceptualni okvir, za izradu DLL biblioteka korišten je jezik C++, dok se za izradu upravljačkog programa koristio jezik C (uz rudimentarne mogućnosti jezika C++, poput deklaracije varijabli bilo gdje u programu, ne nuţno na početku funkcija, kao što to propisuje jezik C). Velika većina komponenata izraďena je samostalno. Sve grafičke komponente osim komponente za prikaz stabla procesa [36] izradio je sam autor. Uz vlastite ikone, korištene su i Tulliana 2 [37] i Aesthetica 2 [38] ikone. Pri izradi sustava zakački/kuka u upravljačkom programu, uvelike je pomogao izvorni tekst ProcessHacker aplikacije [39], kao i automat za odreďivanje duljina instrukcija koji će biti spomenut kasnije. 10 Mono konceptualni okvir

62 4.2 Struktura sustava Struktura cjelokupnog sustava prikazana je na slici 4.1. Slika 4.1: Konceptualna struktura sustava razvijenog kao praktični rad 59

63 Osnovna ideja prilikom oblikovanja sustava bila je razdvajanje cjelokupnog sustava u više slojeva/razina, na sličan način na koji je oblikovan i sam operacijski sustav Windows. Na slici 4.1 uočljive su 3 istaknute razine: razina grafičkog sučelja, razina DLL datoteka/biblioteka i razina upravljačkog programa. Razdvajanje sustava u razine omogućilo je lakši razvoj sustava, ali i povećalo njegovu prenosivost: grafičko sučelje moţe se pokrenuti u bilo kojem operacijskom sustavu u kojem postoji podrška za wxwidgets konceptualni okvir. Budući da je nemoguće u potpunosti odvojiti platformsko-specifične detalje od grafičkog sučelja, takvi dijelovi grafičkog sučelja izolirani su na najbolji mogući način i "skriveni" iza potpuno apstraktnih klasa koje je potrebno implementirati u konkretnom operacijskom sustavu. Primjer platformsko-specifičnog dijela grafičkog sučelja je komunikacija s dijeljenim bibliotekama, odnosno DLL datotekama u operacijskom sustavu Windows. Umjesto izravne komunikacije izmeďu grafičkog sučelja i upravljačkog programa, dodan je meďusloj DLL datoteka. To je omogućilo odvajanje prikaza (engl. view) od samih podatkovnih struktura i informacija koje se prikazuju (engl. model) pa bi se iste DLL datoteke i isti upravljački program mogli koristiti i sa konzolnom aplikacijom koja bi mogla prikazivati iste informacije kao i grafičko sučelje. Na slici su istaknuta tri osnovna podsustava - podsustav za dohvat listu procesa, podsustav za ispitivanje i uklanjanje modifikacija SSDT tablice i podsustav za nadzor procesa. Svi ostali podsustavi sluţe kao potpora ovim podsustavima, no iznimno su vaţni u njihovom funkcioniranju, ponekad ih čak nadmašuju svojom sloţenošću. Primjer takvih vrlo vaţnih potpornih podsustava su podsustav za rad sa simbolima, podsustav za "izvlačenje" sustavskih metoda i svi sustavi u upravljačkom programu. U nastavku će se opisati tri osnovna podsustava, a ostali podsustavi spomenut će se prema potrebi. 60

64 4.3 Grafičko sučelje Grafičko sučelje ima sljedeći izgled: Slika 4.2: Grafičko sučelje praktičnog rada Sučelje je podijeljeno u dva osnovna dijela: na lijevoj strani nalazi se navigacijska ploča s tipkama koje korisnika usmjeravaju na odgovarajuću kategoriju programa, dok desnu stranu sučelja i ujedno najveći dio površine cjelokupnog sučelja uzima površina za prikaz informacija. Grafičko sučelje je programski organizirano tako da svaka kategorija (do koje se dolazi pritiskom tipke na navigacijskoj ploči) nasljeďuje od razreda ContentPageImpl. Sve što je potrebno učiniti za dodavanje nove kategorije u program jest naslijediti taj razred i implementirati sve potrebne metode, dodati tipku i odgovarajuću handler funkciju u razred NavigationPanel i dodati dogaďaj promjene u razred GUIFrame. Dodavanje nove kategorije relativno je jednostavno i zbog toga se program brzo moţe proširiti novim kategorijama ako je to potrebno. 61

65 4.4 Lista procesa i podsustavi vezani uz dohvat informacija o procesima Prikaz liste (točnije, stabla) procesa i ostalih informacija vezanih uz procese, centralni je dio rada i predstavlja najveći podsustav u cjelokupnom praktičnom dijelu. Primjer dijela stabla trenutno aktivnih procesa, prikazan je na slici 4.3. Slika 4.3: Prikaz dijela stabla trenutno aktivnih procesa u sustavu Stupci koji odreďuju vrstu informacija o procesima koja se prikazuje, mogu se mijenjati u postavkama aplikacije (engl. application settings): Slika 4.4: Odabir stupaca s dodatnim informacijama o procesima Odabirom novih stupaca automatski se dodatni stupci prikazuju u sučelju za prikaz stabla procesa. Prilikom gašenja aplikacije, svi trenutno odabrani stupci za prikaz informacija spremaju se u sustavski registar i pri ponovnom pokretanju aplikacije ponovno se čitaju - na taj način sve korisničke postavke ostaju spremljene. Naţalost, 62

66 wxwidgets konceptualni okvir nema podršku za jednostavno mijenjanje poretka stupaca od strane korisnika pa je zbog toga poredak stupaca uvijek isti. Sustav za dohvat procesa ima tri načina rada. Prije nego što se dohvate trenutno aktivni procesi u sustavu, najprije se (pomoću DLL datoteke RkPSysInfoComm.dll) provjerava prisutnost upravljačkog programa. Ako upravljački program nije prisutan, program ne moţe normalno funkcionirati - nije dostupna funkcionalnost otkrivanja skrivenih procesa (barem onih koji se skrivaju modifikacijama u jezgri), ne moţe se provjeriti ispravnost SSDT tablice, niti nadzirati procese. Program pokušava prijeći u "ograničeniji" način rada gdje se informacije o procesima ne dobivaju putem upravljačkog programa, ali ni putem programskog sučelja operacijskog sustava Windows, već putem metoda iz ntdll.dll datoteke (na sličan način na koji to obavlja i aplikacija Task Manager). Pritom se te metode pozivaju na netipičan način koji će biti opisan dalje u tekstu. Ako niti te metode nisu mogle biti pripremljene za pozivanje, aplikacija prelazi u još ograničeniji način rada gdje se za dohvat procesa i informacija o procesima koristi isključivo programsko sučelje operacijskog sustava. U ovakvom načinu rada aplikacija nema nikakvu mogućnost okrivanja skrivenih procesa niti bilo kakve naprednije mogućnosti. Ipak, takav način rada omogućava korisniku da vidi barem osnovne informacije o procesima, makar oni moţda bili modificirani. Mogućnosti aplikacije u tom osnovnom načinu rada pribliţno su jednake aplikaciji Task Manager. Korištenjem tri načina rada spriječila se nemogućnost pokretanja aplikacije - aplikacija ne moţe obaviti svoj zadatak jedino u iznimno rijetkim slučajevima poput velikog nedostatka resursa. Iako u svojoj najograničenijoj inačici aplikacija ne otkriva nikakvu prisutnost rootkita, svejedno moţe posluţiti korisniku "Izvlačenje" metoda iz ntdll.dll datoteke Osnovna pretpostavka pri razvoju ovog podsustava bila je postojanje rootkita u korisničkom načinu rada koji se u sustav ugradio prije nego što je pokrenuta aplikacija razvijena kao praktični rad. Jednom kada je rootkit prisutan u sustavu, sigurnosna aplikacija ima mnogo manju vjerojatnost za njegovo otkrivanje, što se moţe zaključiti ih svih dosadašnjih razmatranja. Osnovni cilj je prevencija, odnosno prisutnost zaštitne aplikacije u sustavu prije nego što se u sustav ugradi rootkit. MeĎutim, ako pretpostavimo da je u sustavu prisutan rootkit u korisničkom načinu rada, njegove modifikacije mogu se izbjeći korištenjem sljedeće tehnike. Komunikacija s upravljačkim programom, ali i dohvat informacija o procesima u slučaju kada upravljački program nije dostupan, odvija se putem posebno "pripremljenih" metoda iz ntdll.dll datoteke. Ntdll.dll datoteka prisutna je u adresnom prostoru svakog procesa u operacijskom sustavu Windows i predstavlja "vrata" prema jezgrinom načinu rada. Iz poglavlja 3 vidljivo je da metode iz te DLL datoteke često koriste rootkiti u korisničkom načinu rada, kako bi od korisnika sakrili brojne objekte sustava. 63

67 Umjesto da "vjeruje" samim metodama ntdll.dll datoteke i poziva ih direktno iz spremnika, aplikacija čita ntdll.dll datoteku s tvrdog diska i direktno "izvlači" potrebne metode u prethodno stvorene meďuspremnike koji imaju dozvolu izvršavanja. U trenutku kada se ţeli pozvati npr. metoda NtQuerySystemInformation(), izvršava se izvršivi tekst metode spremljen u meďuspremnik. Prije nego što se metoda "izvuče" iz ntdll.dll datoteke, provjerava se njezina "ispravnost". Kao što je prethodno objašnjeno, sve Nt* metode iz navedene datoteke imaju gotovo identičan oblik pa se na taj način moţe provjeriti njihova ispravnost. Struktura tih metoda razlikuje se u pojedinim inačicama operacijskog sustava, no prilikom provjere ispravnosti uzete su u obzir sve razlike, tako da je tehnika prenosiva na sve verzije operacijskog sustava, čak i 64-bitne (grafičko sučelje i DLL datoteke rade ispravno na 32-bitnim i 64-bitnim inačicama, no upravljački program načinjen je isključivo za 32-bitnu inačicu). Način izvlačenja metoda preopširan je za navoďenje izvornog teksta, no radi se o prolasku kroz PE strukturu ntdll.dll datoteke, pronalasku odgovarajućih metoda u EAT tablici i "izvlačenju" izvršivog teksta odgovarajuće metode iz.text odsječka datoteke. Zainteresirani čitatelj izvorni tekst moţe pronaći u razredima NativeMethodLoader i NativeMethodVerifier DLL datoteke RkPSysInfoComm. Sustav moţe učitati bilo koju Nt* metodu iz ntdll.dll datoteke no ne moţe se koristiti za općenito "izvlačenje" bilo koje metode iz bilo koje DLL datoteke - razlog je vrlo jednostavan, a proizlazi iz činjenice da je u općenitom slučaju nemoguće razlikovati izvršivi tekst od podataka. S tim problemom susreću se i najbolji komercijalni alati za rastavljanje izvršivog teksta programa (engl. disassembly, disassembler). Zbog jednostavne i stalne strukture izvršivog teksta Nt* metoda, njihovo "izvlačenje" uvijek je moguće. Ovako "izvučene" metode koriste se u aplikaciji za komunikaciju s upravljačkim programom (metoda NtDeviceIoControlFile()), za gašenje procesa kada upravljački program nije prisutan (metoda NtTerminateProcess()) te za listu procesa i dodatnih informacija o procesu (NtQuerySystemInformation() i NtQueryInformationProcess()). 64

68 4.4.2 Sustav za dohvat simbola i rad sa simbolima Ako je upravljački program prisutan u sustavu, aplikacija nastavlja s uobičajenim načinom rada. U poglavlju 3, često puta bilo je spomenuto kako rootkiti, ali i sigurnosne aplikacije, imaju problema prilikom rada s nedokumentiranim strukturama. TakoĎer, navedena su tri općenita načina rješavanja tog problema: izbjegavanje korištenja nedokumentiranih struktura, korištenje struktura specifičnih za pojedinu inačicu ili heuristička pretraga i heurističko odreďivanje pojedinih polja struktura. Niti jedan način nije prikladan za suvremenu sigurnosnu aplikaciju pa je zbog toga odabran sasvim drugačiji pristup, temeljen na debug simbolima, za kojeg autor nije uočio da se koristi u bilo kojoj aplikaciji ovakvog tipa. Prilikom prevoďenja programa iz izvornog teksta u oblik koji se moţe izvršiti, prevoditelj ima mogućnost stvaranja tzv. debug simbola, odnosno datoteka koje sadrţavaju informacije o svim podatkovnim strukturama koje se koriste u programu, o funkcijama i tijeku izvoďenja pa čak i o pojedinim linijama izvornog teksta programa. Tvrtka Microsoft javno nudi debug simbole svih vaţnijih datoteka u operacijskom sustavu, izmeďu ostalog i cjelokupne jezgre operacijskog sustava zajedno s velikim brojem nedokumentiranih i privatnih funkcija i objekata jezgre. Debug simbole jezgre prije svega koriste autori upravljačkih programa jer su informacije o funkcijama i objektima jezgre od ključnog značaja prilikom razvoja upravljačkih programa. Debug simboli namijenjeni su prvenstveno korištenju kroz WinDBG debugger, iako simbole koriste i druge aplikacije (npr. Process Explorer 11 aplikacija). Biblioteka potrebna za njihovo korištenje (dbghelp.dll) dostupna je u svim inačicama operacijskog sustava, no verzija koja dolazi s Windows XP operacijskim sustavom u potpunosti je zastarjela i gotovo beskorisna (najnoviju verziju uvijek je moguće preuzeti s web stranice [23]). Nije sasvim jasno moţe li se najnovija inačica biblioteke dbghelp.dll distribuirati zajedno s aplikacijom koju nije razvila tvrtka Microsoft. Unatoč tome što je autor poprilično uvjeren da se biblioteka moţe koristiti i distribuirati, za to nije pronašao jasnu potvrdu, osim sljedećeg odjeljka na web stranicama tvrtke Microsoft 12 : The DbgHelp library is implemented by DbgHelp.dll. This DLL is included in the operating system. To use this DLL on earlier systems, you can distribute the DLL with your application. To obtain the latest version of DbgHelp.dll, go to and download Debugging Tools for Windows. Iz tamnije otisnutog dijela moţe se zaključiti da je distribucija dotične datoteke dozvoljena uz bilo koju korisničku aplikaciju pa sam razvijeni sustav ne narušava pravila legalnosti. Osim dbghelp.dll datoteke, za ispravan rad aplikacije potrebna je i symsrv.dll datoteka koja obavlja samo povezivanje s web posluţiteljem koji sadrţava potrebne simbole. 11 Process Explorer Potvrda o mogućnosti distribucije dbghelp.dll datoteke - ms679294%28vs.85%29.aspx 65

69 Budući da se te dvije datoteke razlikuju za 32-bitnu i 64-bitnu inačicu operacijskog sustava, postojao je problem distribucije dotičnih datoteka za konkretnu procesorsku arhitekturu. Problem je riješen pomoću dodatne DLL datoteke pod nazivom RkPDebugUnpacker.dll. Dotična DLL datoteka u svome tijelu sadrţi 32-bitne i 64- bitne inačice datoteka dbghelp.dll i symsrv.dll. U trenutku kada treba započeti slanje simbola upravljačkom programu, ispituje se postoje li navedene DLL datoteke u direktoriju aplikacije. Ako datoteke ne postoje, RkPDebugUnpacker.dll datoteka ispituje na kojoj se procesorskoj arhitekturi program izvodi (32-bitnoj ili 64-bitnoj) i u skladu s time vrši "otpakiravanje" odgovarajućih inačica DLL datoteka dbghelp.dll i symsrv.dll u trenutni direktorij. Ako datoteke postoje, prethodni postupak već je proveden pa nema potrebe za njegovim ponavljanjem. DLL datoteke su u RkPDebugUnpacker.dll datoteku smještene kao "resursi", a način njihovog izvlačenja i smještanja na disk moţe se pronaći u RkPDebugUnpacker datoteci. Nakon što su navedene DLL datoteke smještene u direktorij aplikacije, moţe započeti dohvat potrebnih simbola s web stranice tvrtke Microsoft (stranici se ne moţe pristupiti putem preglednika). Budući da dohvat potrebnih simbola (u zasebnoj dretvi) moţe potrajati, korisniku se daje vizualna informacija o napretku dohvata: Slika 4.5: Dohvat simbola sa poslužitelja tvrtke Microsoft Dohvat simbola sa posluţitelja obavlja se isključivo prvi put prilikom pokretanja aplikacije - pri svakom sljedećem pokretanju, svi potrebni simboli bit će prisutni u direktoriju Symbols smještenom u direktoriju u kojem se nalazi aplikacija. Na ovaj način dohvaćene su sve potrebne datoteke s debug simbolima jezgre operacijskog sustava u kojem se aplikacija izvodi. Nakon što su simboli dohvaćeni, potrebno je programsko sučelje za njihovo korištenje. Programsko sučelje pod nazivom DbgHelp tvrtka Microsoft nudi kroz već spomenutu dbghelp.dll datoteku. Iako se u radu spominju i koriste vrlo sloţene strukture, proučavaju detalji operacijskog sustava dobiveni rastavljanjem izvršivog teksta što je vrlo mukotrpan zadatak, autor se do susreta s DbgHelp programskim sučeljem nije susreo s toliko nepotrebno zakompliciranim, nejasnim i neobičnim sučeljem. Sluţbena dokumentacija vrlo je loša, mnoge stvari objašnjene su nedovoljno precizno, funkcije koje tvore sučelje loše su dizajnirane, a korištene 66

70 strukture nepotrebno su velike i nejasne. Izrada sustava za rad sa simbolima išla je čak toliko daleko da je u jednom trenutku autor WinDBG debuggerom vršio analizu (obavljao debuggiranje) samog WinDBG debuggera kako bi shvatio na koji se način DbgHelp programsko sučelje koristi! Ipak, uspješno je načinjen sustav koji korištenjem debug simbola moţe doznati adresu bilo koje funkcije ili varijable u jezgri, odnosno odmak bilo kojeg člana unutar bilo koje strukture u jezgri pa čak i bitovnu poziciju pojedinog polja unutar varijable. Za dohvat adrese funkcije ili varijable jezgre dovoljno je samo dodati novi unos u InitializeSymbolNames() metodu SymbolHelper razreda unutar RkPSysInfoComm DLL datoteke. Za dohvat odmaka bilo kojeg člana ili bitovne pozicije unutar neke strukture potrebno je najprije stvoriti instancu SymbolUDT razreda koja će sadrţavati ime člana i tip (oznaku traţi li se bitovna pozicija ili samo odmak člana unutar strukture). Navedenu instancu potom je potrebno umetnuti u mapu koja kao prvi član sadrţi naziv strukture unutar koje se traţi odmak ili bitovna pozicija, a drugi član predstavlja upravo instancu SymbolUDT razreda. U oba slučaja nužno je povećati brojač ukupnog broja simbola koji se nalazi u datoteci CommonTypesDLL-Drv. Ta činjenica pomalo je nespretna, no prisutna je prvenstveno zbog povećane sigurnosti - prilikom slanja adresa svih potrebnih varijabli, funkcija i odmaka članova struktura (odnosno simbola, ta dva termina bit će korišteni kao sinonimi), upravljački program mora primiti jednak broj simbola koji su pripremljeni u korisničkom dijelu aplikacije. Tu informaciju dijele upravo putem ovog brojača. U slučaju dohvata adresa funkcija i varijabli, djelovanje sustava korištenjem DbgHelp funkcija moţe se opisati sljedećim pojednostavljenim pseudokôdom: // započni rad s DbgHelp sučeljem SymInitialize(); // pronađi i učitaj datoteku jezgre j_datoteka = FindExecutableImage(); // učitaj tablicu simbola za jezgru SymLoadModule64(); // registriraj rutinu povratnog poziva koja će se pozvati za svaki simbol SymEnumSymbols(Callback); // otpusti sve zauzete resurse SymUnloadModule64(); SymCleanup(); Callback funkcija { ako(ime simbola == traženo ime) { zapamti adresu simbola } } Slika 4.6: Pseudokôd dohvata adresa funkcija i varijabli jezgre 67

71 U slučaju dohvata odmaka člana ili bitovne pozicije, postupak je sloţeniji: // inicijalizacijski dio (sve do SymEnumSymbols) jednak je kao na slici 4.6 za(svaki željeni član) { // dohvati informacije o strukturi u kojoj se član nalazi informacije_o_strukturi = NULL; SymGetTypeFromName(ime_strukture, &informacije_o_strukturi); // dohvati broj članova strukture SymGetTypeInfo(informacije_o_strukturi.index_tipa, TI_GET_CHILDRENCOUNT); // dohvati indekse svih članova strukture - sve u DbgHelpu zasniva se na // indeksima polje_indeksa = NULL; SymGetTypeInfo(informacije_o_strukturi.index_tipa, &polje_indeksa); za(svaki indeks člana strukture) { // dohvati ime člana na trenutnom indeksu ime_člana = NULL; SymGetTypeInfo(index, TI_GET_SYMNAME, &ime_člana); ako(ime_člana == željeni_član) { ako(potreban odmak) { odmak = 0; SymGetTypeInfo(index, TI_GET_OFFSET, &odmak); } inače ako(potrebna bitovna pozicija) { pozicija = 0; SymGetTypeInfo(index, TI_GET_BITPOSITION, &pozicija); } } } } spremi odmak ili bitovnu poziciju; Slika 4.7: Pseudokôd dohvata odmaka i bitovnih pozicija članova jezgrinih struktura Cijeli izvorni tekst moţe se pronaći u razredu SymbolHelper datoteke RkPSysInfoComm. Nakon što su dohvaćene sve potrebne adrese i odmaci, oni se spremaju u polje (lineariziraju se) i šalju upravljačkom programu koji ih sprema u jednostruko povezanu listu u kojoj se pojedini simboli pretraţuju po imenu. Početna ideja uključivala je hash tablicu, no zbog vremenskih ograničenja ta ideja nije realizirana. Budući da je broj simbola vrlo malen (manji od 20), ne postoji nikakva prednost u performansama hash tablice naprema jednostruko povezanoj listi. Dio sustava za upravljanje simbolima u upravljačkom programu moţe se naći u "razredu" SymbolHelper (ne radi se o stvarnom C++ razredu, već o tako strukturiranim C datotekama). Sustav za dohvat simbola moţda je najvaţniji sustav u cijelom radu. Zahvaljujući njemu, program je prenosiv na bilo koju verziju operacijskog sustava (počevši od operacijskog sustava Windows 2000) jer će se bilo koja promjena u samoj jezgri 68

72 očitovati u debug simbolima, a time i u aplikaciji. Ne postoji potreba za nepouzdanim heurističkim pretraţivanjem struktura, niti za stvaranjem struktura za pojedine inačice operacijskog sustava - sve potrebne adrese i odmaci dostupni su jednostavnim dodavanjem unosa u navedene metode SymbolHelper razreda. Činjenica da ovakav sustav nije uočen niti u jednoj drugoj sigurnosnoj aplikaciji ovakvog tipa još više povećava njegovu vaţnost i vrijednost, iako sam sustav trenutno nije idealan i postoji još mnogo mjesta za napredak i promjene Informacije o procesima Informacije o procesima dobivaju se na različite načine, ovisno o jednom od tri načina rada u kojem aplikacija djeluje. U slučaju kada nije dostupan upravljački program, ali ni metode "izvučene" iz ntdll.dll datoteke, većina informacija dobiva se korištenjem tzv. ToolHelp programskog sučelja, točnije metoda Process32First() i Process32Next(). Informacije o procesorskom zauzeću dobivaju se pozivom funkcije GetProcessTimes(), dok se informacije o zauzeću spremničkog prostora dobivaju pozivom funkcije GetProcessMemoryCounters(). Ostale informacije poput informacija o autoru datoteke koja pripada procesu, tvrtki koja je napravila tu datoteku i slično, dobivaju se korištenjem GetFileVersionInfo() i pripadnih metoda. Ikona procesa koja je vidljiva u stablu procesa dobiva se funkcijom SHGetFileInfo(). U slučaju kada upravljački program nije dostupan, no koriste se metode "izvučene" iz ntdll.dll datoteke, većina informacija dobiva se pozivom metode NtQuerySystemInformation(). Informacije o procesorskom zauzeću, autoru datoteke i ikona procesa dobivaju se na isti način kao i kod ograničene inačice aplikacije. Statičke informacije, poput sjednice u kojoj je proces pokrenut, korisnika koji je pokrenuo proces, putanje do datoteke koja pripada procesu i slično, dobivaju se korištenjem PEB bloka. PEB blok u korisničkom načinu ekvivalentan je EPROCESS bloku u jezgrinom načinu rada. Jedini problem predstavlja čitanje PEB bloka drugog procesa. To je riješeno korištenjem metode NtQueryInformationProcess() kojom se najprije doznaje adresa PEB bloka u odgovarajućem procesu, a zatim se metodom ReadProcessMemory() čitaju odgovarajući članovi PEB bloka. Implementacija je prisutna u PEBReader razredu RkPSysInfoComm DLL datoteke. Iako je i PEB blok nedokumentirana struktura, on se mijenja mnogo rjeďe od jezgrinih nedokumentiranih struktura pa je zbog toga korištena "fiksna" struktura koja ima različite članove ovisno o inačici operacijskog sustava. Mnogo bolje rješenje bilo bi korištenje sustava simbola i za PEB blok, no to trenutno nije implementirano. U slučaju kada upravljački program postoji i uspješno je izvršena razmjena simbola, koristi se ista metoda dohvata informacija kao i u prethodno opisanom slučaju (čitanje PEB bloka i NtQuerySystemInformation() funkcija). Jedina razlika prisutna je u otkrivanju skrivenih procesa. 69

73 4.4.4 Otkrivanje skrivenih procesa U ograničenom načinu rada, kada nije prisutan upravljački program, niti metode iz ntdll.dll datoteke, aplikacija nema nikakvu mogućnost otkrivanja skrivenih procesa. Inače, dohvat skrivenih procesa pokreće se označavanjem sljedeće kućice: Slika 4.8: Kućica za pokretanje dohvata skrivenih procesa U slučaju kada upravljački program nije dostupan, no prisutne su "izvučene" metode iz ntdll.dll datoteke, omogućeno je otkrivanje skrivenih procesa koje skrivaju rootkiti u korisničkom načinu rada. Otkrivanje skrivenih procesa temelji se na usporedbi svih identifikatora procesa (engl. PID - process IDs) dobivenih metodom EnumProcesses() (metoda programskog sučelja operacijskog sustava, metoda visoke razine) s identifikatorima dobivenima korištenjem NtQuerySystemInformation() metode. Razlike će biti označene crvenom bojom na stablu procesa i označavaju procese koje je vrlo vjerojatno sakrio rootkit u korisničkom načinu rada. Kao primjer otkrivanja procesa ovom metodom koristit će se HackerDefender 13 rootkit. Dotični rootkit koristio se i u radu [17] kao primjer jednog od najpoznatijih i najraširenijih rootkita u korisničkom načinu rada. Za skrivanje procesa, HackerDefender rootkit koristi umetnute modifikacije u funkciji NtQuerySystemInformation(). Budući da se funkcija u praktičnom radu "izvlači" iz same datoteke i poziva iz vlastitog izvršivog meďuspremnika, HackerDefender rootkit ne moţe spriječiti otkrivanje skrivenog procesa: Slika 4.9: Otkrivanje procesa skrivenog HackerDefender rootkitom 13 Opis HackerDefender rootkita

74 Na gornjoj slici korišten je obični korisnički račun i zbog toga nisu dostupni opisi pojedinih datoteka jer korisnik nema dozvole za otvaranje ručica na te procese. Taj "problem" moţe se vrlo jednostavno riješiti u upravljačkom programu, no taj pristup namjerno nije korišten zbog otvaranja sigurnosne rupe - korisničke privilegije moraju biti definirane operacijskim sustavom i bilo kakva "zloupotreba" ili zaobilaţenje moţe imati samo štetne posljedice. U slučaju kada je upravljački program prisutan, za otkrivanje skrivenih procesa koristi se metoda prolaska kroz listu tablica ručica svih trenutno aktivnih procesa. Upravljačkom programu se najprije u posebnoj dretvi šalje polje identifikatora svih aktivnih procesa. Upravljački program potom prolazi kroz listu tablica ručica svih aktivnih procesa (počevši od trenutnog procesa) i sprema identifikatore tih procesa. Ukoliko postoji razlika u identifikatorima, vrlo vjerojatno se radi o procesu kojeg je sakrio rootkit. Prilikom prolaska kroz listu tablica ručica, potrebno je voditi računa o vrlo vaţnom problemu koji dosad nije spomenut - riječ je o sinkronizaciji. Prilikom dohvata EPROCESS bloka trenutnog procesa moţe se dogoditi da neka druga aplikacija ugasi taj proces. Svako daljnje rukovanje dotičnim EPROCESS blokom prouzrokovat će rušenje sustava (engl. BSOD - Blue Screen Of Death). Zbog toga je potrebno zaključati trenutni proces i spriječiti akciju druge aplikacije - to se postiţe korištenjem varijable unutar EPROCESS bloka, do koje se moţe doći zahvaljujući poznavanju odmaka preko sustava simbola. Na jednak način potrebno je zaključati i trenutnu tablicu ručica po kojoj se prolazi - to se takoďer postiţe zaključavanjem varijable koja se nalazi unutar HANDLE_TABLE strukture. Vidljivo je da korištenje sustava simbola uvelike pridonosi stabilnosti aplikacije jer bi se inače zaključavanja vjerojatno zanemarila zbog poteškoća pri pronalaţenju varijabli koje je potrebno zaključati. Nakon što su prikupljeni svi skriveni procesi, njihov identifikator i naziv šalje se natrag u korisnički način rada gdje se prikazuju u grafičkom sučelju. U principu su se mogle vraćati i brojne druge informacije o procesu zbog prisutnosti njegovog EPROCESS bloka u kojem su prisutne gotovo sve vaţne informacije, no to nije učinjeno jer bi se inače morale prenositi relativno velike strukture podataka (sve dok je aktivirana kućica za prikaz skrivenih procesa). MeĎutim, proširenje strukture na dodatne članove nije nikakav problem. Izvorni tekst otkrivanja procesa prolaskom kroz listu tablica ručica nalazi se u ProcessEngine "razredu" upravljačkog programa. Metoda prolaska kroz listu tablica ručica odabrana je prije svega zbog ponajboljeg omjera jednostavnosti i "kvalitete". Pod kvalitetom podrazumijeva se teškoća izbjegavanja metode od strane rootkita, odnosno vjerojatnost otkrivanja skrivenih procesa. U početku se trebala koristiti metoda umetnutih modifikacija metode KiSwapContext(), no tada još nisu bili razvijeni sustavi zakački (engl. hook), niti sustav za rad sa simbolima. Autor se pribojavao nestabilnosti prilikom odreďivanja adrese i, još više, zbog modifikacija same funkcije pa je iz tog razloga odabrana trenutna, jednostavnija metoda. 71

75 Iako relativno jednostavna, metoda pruţa potpunu zaštitu od svih rootkita koji djeluju u korisničkom načinu rada (npr. prethodno spomenuti HackerDefender), od svih rootkita koji procese skrivaju modifikacijama SSDT tablice (mnogobrojni rootkiti stvoreni prije nekoliko godina) i od svih rootkita koji uklanjaju proces iz liste aktivnih procesa (npr. već spomenuti FU rootkit). Metoda ne može otkriti rootkite koji procese skrivaju uklanjanjem iz liste tablica ručica, modifikacijama PspCidTable unosa ili izradom vlastitog raspodjelitelja dretvi, naravno, uz pretpostavku da su rootkiti dodatno otklonili proces u listi aktivnih procesa i u listi tablica ručica. TakoĎer, aplikacija ne može otkriti sofisticirane rootkite koji ne stvaraju procese već dretve. Primjer otkrivanja FU rootkita prikazan je na sljedećoj slici: Slika 4.10: Otkrivanje procesa skrivenog FU rootkitom Radi usporedbe, na gornjoj slici dan je i rezultat izvršavanja poznate anti-rootkit aplikacije GMER GMER anti-rootkit

76 4.4.5 Gašenje procesa Prilikom gašenja procesa, korisniku se nudi mogućnost gašenja pojedinačnog procesa i mogućnost gašenja cijelog stabla procesa (gašenje procesa roditelja i svih procesa koji su njegova djeca). U osnovnom načinu rada gašenje procesa odvija se pozivom funkcije TerminateProcess() koja je dio kernel32.dll biblioteke. Jasno je da čak i rootkiti u korisničkom načinu rada mogu spriječiti ovakav način gašenja procesa modificiranjem funkcije NtTerminateProcess() koju funkcija TerminateProcess() poziva. U načinu rada bez upravljačkog programa, no uz "izvučene" ntdll.dll metode, gašenje procesa obavlja se upravo pozivom funkcije NtTerminateProcess(). Budući da su metode "izvučene" izravno s diska, bilo koja spremnička modifikacija funkcija iz ntdll.dll datoteke ne moţe spriječiti gašenje procesa. Čak i u ovakvom oslabljenom načinu rada, aplikacija moţe ugasiti sve procese koje skrivaju rootkiti u korisničkom načinu rada. Kontekstni izbornik za gašenje procesa koji se dobiva desnim klikom na proces ima sljedeći izgled: Slika 4.11: Kontekstni izbornik za gašenje procesa Na gornjoj slici proces nije prikazan crveno (oznaka da je skriven) jer se klikom na proces on "selektira" pa je aktivna boja selekcije. Nakon odabira tipke za gašenje procesa, korisnika se još jednom pita za potvrdu akcije: Slika 4.12: Upit za potvrdom akcije gašenja procesa Ukoliko ţeli, korisnik moţe isključiti ovo upozorenje (postavke se čuvaju u sustavskom registru). Mnogo zanimljivije riješenje predstavlja gašenje procesa u upravljačkom programu. Osnovna ideja bila je izbjeći sve modifikacije koje je rootkit mogao postaviti i koristiti funkciju za koju postoji velika vjerojatnost da ju rootkit nije modificirao. NtTerminateProcess() funkcija iz ntdll.dll datoteke poziva istoimenu funkciju u jezgri. Dotična funkcija u jezgri koristi privatnu funkciju jezgre pod nazivom PsTerminateProcess() koja je samo omotač oko još jedne jezgrine privatne funkcije - 73

77 PspTerminateProcess(). Napredniji rootkiti vrše umetnute modifikacije dotične funkcije, iako se radi o privatnoj funkciji jezgre. Budući da sustav rada sa simbolima omogućava dohvat adrese bilo koje funkcije u jezgri, postojala je sloboda realizacije vlastite funkcije za gašenje procesa. Upravo zbog toga je analiziran sam izvršivi tekst (provedeno je rastavljanje izvršivog teksta) funkcije PspTerminateProcess() i načinjena je vlastita verzija dotične funkcije. Analizi je, ne samo na ovom mjestu već općenito, uvelike pomogao izvorni tekst operacijskog sustava ReactOS [40] (klon operacijskog sustava Windows). Izvorni tekst te metode moţe se pronaći u ProcessEngine "razredu" upravljačkog programa, a pseudokôd ima sljedeći oblik: // ispitaj da li se radi o kritičnom procesu nakon kojeg treba srušiti sustav // informacija o tome krije se u zastavici EPROCESS bloka ako(proces kritičan) { BSOD; } // signaliziraj da se proces briše postavljanjem zastavice u EPROCESS bloku postavi zastavicu brisanja // dohvati prvu dretvu procesa dretva = DohvatiDretvuProcesa(); // ubijaj jednu po jednu dretvu procesa dok(dretva!= NULL) { UništiDretvu(dretva); dretva = DohvatiDretvuProcesa(); } Slika 4.13: Pseudokôd funkcije za gašenje procesa iz upravljačkog programa Izvorni tekst funkcije vrlo je jednostavan i svodi se na gašenje svih dretvi procesa. Funkcije koje se koriste za dohvat dretvi procesa i uništavanje dretvi takoďer su privatne i nedokumentirane funkcije jezgre operacijskog sustava - PsGetNextProcessThread() i PspTerminateThreadByPointer(). Naravno, postoji mogućnost da rootkiti modificiraju i navedene funkcije, no tijekom izrade rada nije pronaďen niti jedan rootkit koji modificira navedene funkcije - prije svega zbog činjenice da do tih funkcija nije lako doći. Pritom treba napomenuti da je način pozivanja nekih funkcija jezgre promijenjen u operacijskom sustavu Vista u odnosu na operacijski sustav Windows XP. Bilo bi idealno kada bi sustav za rad sa simbolima mogao znati broj argumenata funkcije i njihov tip, no autor to nije uspio pronaći i mišljenja je da takva podrška u samim debug simbolima ne postoji. Problem je riješen eksplicitnim pretvaranjem parametara za različite verzije operacijskog sustava - to nije teţak posao, no zahtijeva detaljno rastavljanje izvršivog teksta svake privatne jezgrine funkcije koja se ţeli koristiti u programu, što moţe biti dugotrajno. Cjelokupni sustav za prikaz stabla procesa i gašenje rootkit procesa dostupan je za sve ispitane operacijske sustave: Windows XP, Windows Vista i Windows 7. 74

78 4.5 Otkrivanje izmjena u tablici sustavskih poziva U praktičnom dijelu načinjena je i podrška za otkrivanje izmjena u tablici sustavskih poziva (SSDT tablica u operacijskom sustavu Windows) te mogućnost otklanjanja izmjena u tablici. Budući da je za pristup SSDT tablici potreban upravljački program, mogućnost otkrivanja i otklanjanja izmjena prisutna je isključivo uz postojanje upravljačkog programa - ako upravljački program nije prisutan ili mu se ne moţe pristupiti, korisnik neće moći otkriti i otkloniti izmjene u SSDT tablici. Za razliku od otkrivanja modifikacija SSDT tablice, uklanjanje modificiranih unosa u SSDT tablici moţe uzrokovati nestabilnosti u radu operacijskog sustava ili pojedinih aplikacija i zahtijeva veliki oprez. Korisnik mora imati odreďena znanja o operacijskom sustavu i mora sâm razlučiti koji je unos u SSDT tablici štetan, a koji bi mogao biti legitiman. Sigurnosne aplikacije vrlo često modificiraju SSDT tablicu i na taj način prate rad sustava. Otklanjanjem takvih modifikacija sigurnosna aplikacija više neće moći obavljati svoj posao, no neće doći do rušenja sustava. Opasnost od rušenja sustava općenito je vrlo mala, no poznat je slučaj u kojem se rušenje sustava ipak moţe dogoditi. Neka je upravljački program A modificirao unos N u SSDT tablici. Općenito se modifikacije SSDT tablice provode tako da se na odgovarajuću poziciju u tablicu zapiše adresa nove funkcije, a stara se vrijednost čuva sve do trenutka kada upravljački program prestaje s radom (tada se ponovno vraća stara vrijednost). Neka se nakon upravljačkog programa A u sustav ugradio upravljački program B koji je modificirao isti unos N SSDT tablice. Upravljački program B kao staru vrijednost unosa N sprema adresu funkcije iz upravljačkog programa A. Sve dok su upravljački programi A i B prisutni u jezgri, ne postoji opasnost od rušenja sustava zbog modifikacija SSDT tablice. Ako se pretpostavi da najprije upravljački program A završava s radom (npr. korisnik ga uklanja iz jezgre), on vraća početnu vrijednost unosa SSDT tablice, tj. onu vrijednost koja je bila prisutna prije ugradnje upravljačkih programa A i B. Sve dok je upravljački program B prisutan, takoďer ne dolazi do rušenja sustava (iako B više ne djeluje ispravno), no ako upravljački program B završi s radom, on će na odgovarajuću poziciju u tablicu upisati pohranjenu vrijednost koja odgovara funkciji iz upravljačkog programa A koji više ne postoji! Prvi sljedeći poziv te funkcije izazvat će rušenje sustava. Opisani slučaj ne moţe biti prouzrokovan funkcionalnošću koja je razvijena u praktičnom radu, no pokazuje da prilikom otklanjanja modifikacija SSDT tablica treba biti vrlo oprezan. Prije nego što se pokrene postupak otklanjanja izmjena u SSDT tablici, korisniku se prikazuje upozorenje: Slika 4.14: Upozorenje prije otklanjanja modifikacija SSDT tablice 75

79 Izgled sučelja za otkrivanje i otklanjanje izmjena prikazan je na sljedećoj slici: Slika 4.15: Pregled modifikacija SSDT tablice Na gornjoj slici vidljive su brojne modifikacije SSDT tablice. Sam prikaz podijeljen je na tri stupca: prvi stupac predstavlja naziv funkcije u SSDT tablici čiji je unos modificiran, drugi stupac predstavlja adresu modificiranog unosa (adresu nove funkcije u spremniku, za koju postoji odreďena vjerojatnost da je zloćudna), dok treći stupac sadrţi naziv upravljačkog programa koji je izvršio modifikacije, odnosno u kojem se nalazi nova funkcija. Većina modifikacija na gornjoj slici pripada upravljačkom programu procguard.sys koji je dio ProcessGuard 15 sigurnosne aplikacije za nadzor nad pokretanjem procesa. Dotična aplikacija nadzor nad pokretanjem procesa vrši modifikacijama SSDT tablice, što nije najbolji način za obavljanje nadzora jer, kao što je vidljivo, neka druga aplikacija te modifikacije moţe relativno lako ukloniti. Preostala dva unosa u tablici pripadaju "zloćudnom" upravljačkom programu koji je razvijen u okviru diplomskoga rada i koji modificira unose funkcija NtQuerySystemInformation() i NtTerminateProcess(). Korisnik ima mogućnost otkloniti sve prisutne modifikacije pritiskom na tipku u donjem dijelu ekrana ili se modifikacije mogu brisati pojedinačno, odabirom pojedinih unosa i pritiskom desne tipke miša, pri čemu se pojavljuje kontekstni izbornik s opcijom za uklanjanje modifikacija: 15 ProcessGuard sigurnosna aplikacija

80 Slika 4.16: Uklanjanje pojedinačnih modifikacija u SSDT tablici Korisnik je odlučio ukloniti modifikacije koje je proveo upravljački program IDT_DRIVE, razvijen u okviru ovog rada. Nakon uklanjanja modifikacija, ovisno o tome da li je uklanjanje uspjelo ili se dogodila neka pogreška, korisniku se ispisuje odgovarajuća poruka. Primjerice, u slučaju uspješnog uklanjanja modifikacija, prikazuje se sljedeća poruka: Slika 4.17: Poruka u slučaju uspješno uklonjenih modifikacija SSDT tablice Kao što je vidljivo na slici 4.15, svakom unosu pridruţen je odgovarajući naziv funkcije. Naziv funkcije pribavljen je na sličan način na koji se obavlja "izvlačenje" metoda iz ntdll.dll datoteke. Prilikom otkrivanja modifikacija u SSDT tablici, upravljački program vraća listu struktura u kojima je, izmeďu ostalog, prisutan indeks funkcije u SSDT tablici čiji je unos modificiran. Prolazeći kroz EAT tablicu ntdll.dll datoteke na identičan način kao i prilikom "izvlačenja" funkcija, ispituje se započinje li navedena funkcija iz EAT tablice sljedećom naredbom naredbom: mov eax, _index_ Slika 4.18: Početak svake Nt metode u datoteci ntdll.dll U trećem poglavlju na više je mjesta objašnjeno da je navedena instrukcija početak svake Nt metode u ntdll.dll datoteci, pri čemu _index_ mora odgovarati indeksu dobivenom od upravljačkog programa. Ako je unos pronaďen, ime metode čita se izravno iz odgovarajućeg polja EAT tablice. Samo otkrivanje modifikacija SSDT tablice nije sloţen postupak i objašnjeno je u trećem poglavlju: potrebno je samo utvrditi je li svaki unos SSDT tablice unutar adresnog prostora jezgre. Ukoliko je adresa unosa u adresnom prostoru nekog drugog upravljačkog programa, tada je sigurno riječ o modificiranom unosu. Dakako, osim samih unosa, potrebno je provjeriti i moguće umetnute modifikacije koje su prisutne na adresama ispravnih unosa. U praktičnom radu ne provjerava 77

81 se postojanje umetnutih modifikacija, već samo jesu li modificirani pojedini unosi u SSDT tablici. Uklanjanje modifikacija znatno je sloţenije od njihovog otkrivanja. Problem predstavlja činjenica da stvarne adrese modificiranih unosa više nisu prisutne u tablici i do njih nije jednostavno doći. Korištenjem sustava simbola, ispravne (početne) adrese mogu se relativno jednostavno doznati - potrebno je najprije odrediti naziv funkcije koja je modificirana, adresa se potom jednostavno dobiva putem sustava simbola. Budući da je sustav otkrivanja i otklanjanja modifikacija SSDT tablice razvijen ranije od sustava simbola, korištena je druga metoda koju je predloţio Alexander Tereshkin [41]. A. Tereshkin uočio je da se SSDT tablica, osim u spremniku, nalazi i u datoteci jezgre na disku. Jedini problem predstavlja činjenica da do tablice u datoteci nije jednostavno doći. A. Tereshkin dalje je primijetio da se prilikom podizanja sustava cijela tablica iz datoteke smješta u spremnik i da je tablica na disku i u spremniku opisana privatnom varijablom jezgre KiServiceTable, uz prije spomenutu KeServiceDescriptorTable varijablu kojom je SSDT tablica takoďer opisana. MeĎutim, KeServiceDescriptorTable varijabla na disku nije inicijalizirana, već se tijekom podizanja sustava inicijalizira upravo adresom KiServiceTable varijable. Ako je napadač proveo modifikacije SSDT tablice u spremniku, tablica na disku i dalje je netaknuta i korištenjem tablice s diska SSDT tablica u spremniku moţe se vratiti u prvobitan oblik. Potrebno je najprije pronaći adresu KeServiceDescriptorTable varijable - to se moţe postići na jednostavan način ako se datoteka jezgre u adresni prostor učita kao DLL biblioteka - na taj se način pozivom funkcije GetProcAddress() moţe doći do ţeljene adrese. Potom je potrebno pronaći.reloc odsječak u datoteci jezgre. Prolazeći kroz sve relokacije izvršivog teksta, potrebno je pronaći one relokacije koje pokazuju na adresu KeServiceDescriptorTable varijable jer se jedna od tih relokacija odnosi na sljedeću instrukciju: c705xxxxxxxx mov KeServiceDescriptorTable.Base, offset KiServiceTable Slika 4.19: Instrukcija u datoteci jezgre u kojoj se koristi KiServiceTable varijabla Dotičnu relokaciju moguće je prepoznati po operacijskom kôdu instrukcije - 0x05C7. Sljedeća 4 okteta predstavljaju upravo adresu (i to relativnu adresu u odnosu na početnu adresu datoteke u spremniku, jednom kada se jezgra učita u spremnički prostor) KiServiceTable varijable. Poznavanjem adrese KiServiceTable varijable moguće je doći do početnih unosa SSDT tablice pomoću kojih je moguće ukloniti prisutne modifikacije. Izvorni tekst relativno je sloţen i velik pa zbog toga nije prikazan u radu, no moţe se pronaći u razredu SystemCallTableHelper DLL datoteke RkPSysInfoComm, zajedno s detaljnim komentarima. Funkcionalnost otkrivanja i uklanjanja modifikacija SSDT tablica prisutna je za sve ispitane operacijske sustave: Windows XP, Windows Vista i Windows 7. 78

82 4.6 Nadziranje pokretanja procesa u operacijskom sustavu Potpuni nadzor korisnika nad svim procesima koji se pokreću u računalnom sustavu temeljna je pretpostavka očuvanja integriteta računalnog sustava i sprječavanja zaraze. Nadzor mora biti realiziran na način da se niti jedan proces ne moţe pokrenuti nezamijećeno od korisnika, ali da istodobno korisnik neometano moţe obavljati svoj posao na računalu, bez učestalih intervencija sustava nadzora. Sustav nadzora pokretanja procesa najsloţeniji je sustav u praktičnom dijelu s programerskog stajališta. Prilikom pokretanja procesa, potrebno je pokretanje (stvaranje) procesa privremeno zaustaviti i dojaviti korisniku da se dotični proces ţeli pokrenuti. Ovisno o korisnikovoj odluci (dozvola pokretanja ili zabrana pokretanja), proces nastavlja s izvoďenjem ili se stvaranje procesa zabranjuje. Postupak zaustavljanja procesa i čekanje na akciju korisnika tehnički je vrlo zahtjevan i postoji mnogo mogućnosti za pojavu potpunog zastoja (engl. deadlock), no ipak je riješen na zadovoljavajući način. Prije no što se opiše samo djelovanje sustava, potrebno je opisati podsustav neophodan za uspostavu samog nadzora - sustav zakački/kuka Sustav zakački/kuka - sustav za izmjene jezgrinih funkcija Operacijski sustav Windows ima izrazito malo mehanizama pomoću kojih korisnici mogu nadgledati procese koji se pokreću u sustavu. U svim verzijama operacijskog sustava Windows postoji tzv. sigurnosni dnevnik 16 (engl. security log) u kojeg se (ovisno o postavkama korisničke i grupne sigurnosne politike) mogu zapisivati dogaďaji poput stvaranja i gašenja procesa. MeĎutim, korisnik nema nikakvu mogućnost sprječavanja pokretanja procesa, već samo moţe vidjeti zapis o tome da je pojedini proces stvoren ili ugašen. U novijim inačicama operacijskog sustava (Windows Vista i Windows 7) tvrtka Microsoft razvila je mehanizam UAC o kojemu je već bilo riječi ranije. UAC mehanizam dozvoljava korisniku da sam odluči smije li se neki proces pokrenuti ili ne. UAC mehanizam ipak nema jasnu sigurnosnu politiku (pogotovo u operacijskom sustavu Windows Vista) pa se ne mogu definirati pojedini procesi kojima se uvijek dozvoljava pokretanje i izvršavanje, odnosno procesi kojima se nikada ne dozvoljava pokretanje. Naţalost, sa stajališta autora sigurnosnih aplikacija situacija je znatno gora jer operacijski sustav Windows ne pruža niti jedan službeni način nadzora nad pokretanjem procesa. Za nadzor nad pokretanjem procesa u korisničkom načinu rada moţe se koristiti sustav Windows zakački (engl. Windows hooks). Windows zakačke nisu sluţbeno namijenjene za nadzor nad pokretanjem procesa, no korištenjem globalne WH_CBT zakačke moguće je nadzirati pokretanje bilo kojeg procesa koji koristi DLL datoteku user32.dll na način na koji je to učinjeno u radu [17]. Globalne Windows zakačke mogu usporiti obavljanje uobičajenih zadataka u operacijskom sustavu, a vidljivo je i da se ne mogu primijeniti na sve procese u sustavu. 16 Windows sigurnosni dnevnik

83 Jedini sluţbeni način za obavještavanje o stvaranju novog procesa i gašenju postojećeg procesa, no ne i za nadzor nad stvaranjem procesa, predstavlja metoda PsSetCreateProcessNotifyRoutine() koja je dostupna upravljačkim programima. Korištenjem PsSetCreateProcessNotifyRoutine() metode moguće je predbiljeţiti rutinu povratnog poziva koja će se pozivati svaki put kada se stvara novi proces u operacijskom sustavu, odnosno kada se postojeći proces gasi. Nemoguće je stvoriti novi proces koji će izbjeći pozivanje rutine povratnog poziva. Nedostatak ove tehnike predstavlja činjenica da se nakon pozivanja rutine povratnog poziva novostvoreni proces nastavlja normalno izvoditi, tj. u samoj metodi nuţno je privremeno zaustaviti stvaranje procesa, dojaviti korisniku o novostvorenom procesu i potom nastaviti sa stvaranjem procesa ili zabraniti stvaranje, ovisno o odluci korisnika. Problem privremenog zaustavljanja procesa koji se stvara prisutan je i pri korištenju drugih tehnika pa će biti objašnjen u daljnjem tekstu. Dodatni nedostatak PsSetCreateProcessNotifyRoutine() tehnike mogućnost je predbiljeţbe samo osam rutina povratnog poziva, pri čemu se sve rutine čuvaju u polju (tablici) koje je opisano privatnom varijablom jezgre pod nazivom PspCreateProcessNotifyRoutine - moguće je načiniti upravljački program koji će se pokrenuti prilikom pokretanja sustava i koji će prepisati svih osam rutina svojim vlastitim rutinama, čime će zaštita biti zaobiďena. Modifikaciju ove vrste uvijek je moguće provesti, no pri korištenju PsSetCreateProcessNotifyRoutine() tehnike ono je znatno olakšano činjenicom da je unaprijed poznato mjesto koje je potrebno modificirati kako bi se zaštita zaobišla. Stvaranje novih procesa moţe se nadzirati izmjenama u SSDT tablici - npr. modifikacija unosa funkcija NtCreateProcess() i NtCreateThread(). Tom metodom koristi se većina antivirusnih programa i sigurnosnih zaštitnih stijena. Problemi zaustavljanja procesa i dalje su prisutni kao i kod prethodno opisane tehnike. Dodatno, izmjene u SSDT tablici relativno se lako otkrivaju (i nešto teţe otklanjaju), kao što je opisano u prethodnom poglavlju pa se zaobilaţenje zaštite svodi na uklanjanje modifikacija SSDT tablice. Sloţenije sigurnosne aplikacije provode umetnute modifikacije funkcija iz SSDT tablice ili privatnih funkcija jezgre. Budući da NtCreateProcess() funkcija poziva PspCreateProcess() funkciju, najčešće se modificira upravo ta funkcija (točnije, stvara se zakačka kojom će se tijek izvoďenja prenijeti na novu funkciju). Budući da se radi o privatnoj funkciji jezgre, do njene adrese nije jednostavno doći. U praktičnom radu nije korištena niti jedna prethodno opisana metoda. Zahvaljujući sustavu simbola postojala je mogućnost da se zakačka u sustavu postavi još dublje, na bilo koju privatnu funkciju jezgre koja sudjeluje pri stvaranju procesa. Pri odabiru takve funkcije vrlo vaţan kriterij bio je postojanje odreďenih informacija o procesu koji se stvara, tj. dio procesa do tog trenutka već je morao biti stvoren. Postojanje informacija vaţno je isključivo zbog korisnika - korisnik mora jasno vidjeti koji proces se stvara, moraju biti dostupne informacije o procesu roditelju, o datoteci koja pripada procesu koji se stvara i slično. Kao idealan kandidat pokazala se privatna funkcija MmCreatePeb(), zaduţena za stvaranje PEB bloka procesa. U trenutku poziva dotične funkcije, dio EPROCESS bloka već je popunjen i dostupne su informacije o identifikatoru procesa roditelja, o identifikatoru procesa koji se stvara, kao i o putanji do datoteka koje pripadaju procesu roditelju i procesu koji se stvara. 80

84 ProvoĎenje umetnutih modifikacija u svrhu stvaranja zakački nije trivijalan zadatak, kao što je opisano u trećem poglavlju. U jezgrinom načinu rada situacija je dodatno oteţana činjenicom da bilo koju metodu u bilo kojem trenutku moţe pozvati bilo koja dretva na bilo kojem procesoru i to baš u trenutku dok se modifikacija provodi. Takva situacija nije nimalo rijetka, pogotovo za metode koje se često pozivaju (npr. metode za rad s dretvama). Stvaranje zakački i modifikacija jezgrinih funkcija zahtijevalo je razvoj robusnog sustava koji će otkloniti ovakve probleme i koji će se moći koristiti za modifikaciju bilo koje jezgrine funkcije. Sustav načinjen u praktičnom dijelu uspješno rješava gore spomenuti problem sinkronizacije. Taj dio sustava oblikovan je na temelju vrlo dobrog izvornog teksta upravljačkog programa aplikacije ProcessHacker [39], uz dodatne modifikacije. Osnovna ideja pri rješavanju problema sinkronizacije zabrana je izvoďenja bilo koje dretve na bilo kojem procesoru osim dretve koja izvodi izmjene, odnosno stvara zakačku. Jedino se na taj način izmjene sigurno mogu postaviti i ukloniti. U operacijskom sustavu Windows postoji nekoliko razina prekida. Najniţa razina naziva se PASSIVE_LEVEL i na toj razini izvode se sve korisničke aplikacije. Sljedeća razina prekida naziva se APC_LEVEL i na njoj se obavljaju asinkroni pozivi procedura (engl. Asynchronous Procedure Call) koji omogućavaju izvoďenje korisničkim i upravljačkim programima u kontekstu bilo koje dretve. Razina na kojoj djeluje raspodjelitelj dretvi u sustavu (na toj razini se odvija promjena konteksta) naziva se DISPATCH_LEVEL/DPC_LEVEL i viša je od APC_LEVEL razine. IzvoĎenje nekog odsječka programa moţe biti prekinuto isključivo prekidom razine koja je strogo veća od one na kojoj se program trenutno izvodi. Ukoliko se razina prekida postavi na DISPATCH_LEVEL, raspodjelitelj dretvi neće moći obavljati zamjenu dretvi (jer zamjena dretvi/konteksta izaziva prekid iste razine) sve dok se razina prekida ne postavi na vrijednost niţu od DISPATCH_LEVEL. Budući da su razine prekida vezane za pojedini procesor, potrebno je na svim procesorima postaviti razinu prekida na DISPATCH_LEVEL. Izvorni tekst sinkronizacije prisutan je u "razredu" SynchronizationProvider upravljačkog programa, a temelj tog "razreda" predstavljaju metode SyncAcquireCPULock() koja se poziva prije provoďenja modifikacija i SyncReleaseCPULock() koja se poziva nakon što su modifikacije obavljene. Pojednostavljeni pseudokôd metode SyncAcquireCPULock() koja se izvodi na procesoru koji će biti označen kao glavni, prikazan je na donjoj slici: broj_procesora = DohvatiBrojProcesora(); ako(broj_procesora == 1) { prijasnja_razina = PostaviRazinuPrekida(DISPATCH_LEVEL); izlaz; } prijasnja_razina = PostaviRazinuPrekida(DISPATCH_LEVEL); trenutni_procesor = DohvatiIndexTrenutnogProcesora(); za(i do broj_procesora) { ako(i!= trenutni_procesor) 81

85 } { } // ne smijemo pokrenuti rutinu cekanja na glavnom procesoru - to bi // izazvalo potpuni zastoj PokreniDPCRutinuNaProcesoru(i, PovecajRazinuICekaj); dok(svi procesori nisu na DISPATCH_LEVEL) { radno cekaj; } Slika 4.20: Pseudokôd metode SyncAcquireCPULock() "Glavni" procesor nareďuje ostalima da izvode odreďenu proceduru putem mehanizma odgođenog poziva procedura (engl. Deferred procedure call) kojim se moţe odrediti procesor na kojem će se izvoditi zadana metoda i to na DISPATCH_LEVEL razini prekida. Izvorni tekst DPC metode PovecajRazinuICekaj() koja je spomenuta u gornjem pseudokôdu vrlo je jednostavan: // sama funkcija izvodi se na DISPATCH_LEVEL razini prekida jer je to razina // izvođenja DPC rutina dok(nisi dobio signal za spustanje razine prekida) { radno cekaj; } Slika 4.21: Pseudokôd metode koja se izvodi na svakom procesoru, osim "glavnog" Svi ostali procesori izvode radno čekanje sve dok ne prime signal za spuštanje razine prekida koji im šalje "glavni" procesor. Nakon što je izvršena metoda SyncAcquireCPULock() svi procesori su na DISPATCH_LEVEL razini prekida i moţe se provesti postavljanje zakačke. Nakon što je zakačka postavljena, potrebno je svim procesorima poslati signal da mogu spustiti razinu prekida na onu koja je ranije bila postavljena, pri čemu "glavni" procesor takoďer spušta razinu prekida. Dotični posao obavlja funkcija SyncReleaseCPULock() koju takoďer poziva "glavni" procesor: SaljiSignalSvimProcesorima(); dok(svi procesori nisu spustili razinu) { radno cekaj; } PostaviRazinuPrekida(prijasnja_razina); Slika 4.22: Pseudokôd SyncReleaseCPULock() Ovakvom vrstom sinkronizacije sigurno je postavljanje zakački na sve jezgrine funkcije koje se pozivaju na PASSIVE_LEVEL ili APC_LEVEL razini. Budući da se većina (moţda čak i sve) za sigurnosne aplikacije zanimljivih jezgrinih funkcija poziva upravo na PASSIVE_LEVEL razini, ovo ograničenje ne umanjuje funkcionalnost sustava zakački. 82

86 Postavljanje zakački provodi se umetnutom modifikacijom ţeljene funkcije. Mehanizam umetnutih modifikacija objašnjen je u trećem poglavlju pa ovdje neće biti detaljnije razmatran. Potrebno je spomenuti da se za odreďivanje duljine instrukcija koristi automat za određivanje duljine instrukcija (engl. length disassembler engine) kojeg je izradio autor s nadimkom z0mbie 17. Najprije se pomoću tog automata odredi broj okteta potrebnih za zaobilaznicu, dotični broj okteta na početku originalne funkcije sprema se u spremnik, a na njihovo mjesto zapisuje se naredba bezuvjetnog skoka na početak ţeljene, vlastite funkcije. Originalna (izvorna) funkcija poziva se na specifičan način, skokom na prethodno pripremljeni meďuspremnik koji uvijek sadrţava sljedeće naredbe: b8 XX XX XX XX mov eax, adresa_originalne_funkcije 83 c0 XX add eax, broj_okteta_zaobilaznice broj_okteta_zaobilaznice izvorno spremljeni okteti ff e0 jmp eax Slika 4.23: Međuspremnik s naredbama poziva izvorne funkcije Prilikom pozivanja izvorne funkcije, najprije se skače na meďuspremnik s gore navedenim naredbama. U tom meďuspremniku najprije se izvode sve naredbe s početka izvorne funkcije koje su prepisane zaobilaznicom, a zatim se skače na izvornu funkciju, tj. na prvu sljedeću instrukciju koja nije prepisana zaobilaznicom. Postupak je isti kao i na slici 3.15 u trećem poglavlju, pri čemu u 2. koraku ulogu odskočnice preuzima gornji meďuspremnik. Izvorni tekst sustava zakački moguće je pronaći u "razredu" HookEngine upravljačkog programa Problem zaustavljanja procesa i dojave dogaďaja korisniku Osim razvoja sustava zakački, privremeno zaustavljanje procesa koji se stvara i dojava korisniku da se proces pokušava stvoriti predstavlja najveći izazov u izgradnji sustava za nadzor pokretanja procesa. U radu [42] koji se bavi razvojem sustava za nadzor pokretanja procesa (procesne zaštitne stijene), kolega Martin Grmek zaustavljanje procesa provodi zaustavljanjem svih dretvi procesa koji se pokušava stvoriti. Istu funkcionalnost ima i nedokumentirana funkcija NtSuspendProcess(). U praktičnom dijelu ova tehnika se nije mogla koristiti jer proces u trenutku pozivanja metode MmCreatePeb() nije u potpunosti stvoren (njegov EPROCESS blok je nepotpun). Nedostatak te metode naveo je i kolega Grmek: zaustavljanje svih dretvi nekog procesa nije sigurno djelovanje i moţe dovesti do potpunog zastoja i do brojnih drugih nepredviďenih posljedica. Kao tehniku dojave dogaďaja korisniku, kolega Grmek odabrao je asinkroni poziv procedura (APC) kojim upravljački program moţe zatraţiti izvoďenje u kontekstu bilo 17 XDE - extended disassembler engine

87 koje dretve (a time i u adresnom prostoru bilo kojeg procesa). Ovakva vrsta dojave ima dva istaknuta nedostatka - sam APC mehanizam relativno je sloţen i, mnogo vaţnije, nedokumentiran i tvrtka Microsoft ga službeno ne podržava. TakoĎer, APC mehanizmom dretvi/aplikaciji moguće je prenijeti vrlo ograničene količine podataka - APC rutina povratnog poziva koju definira aplikacija ima ograničeni broj argumenata, a svi pokazivači moraju biti u adresnom prostoru procesa, čime sam mehanizam pomalo gubi smisao. U praktičnom radu za potrebe zaustavljanja procesa i dojave dogaďaja korisniku korišten je postupak temeljen isključivo na mehanizmima sinkronizacije - prije svega uvjetnim varijablama (u operacijskom sustavu Windows nazivaju se događaji, engl. event). Djelovanje ovog sustava nije jednostavno i moţe se podijeliti na tri razine: 1. razina korisničke aplikacije (grafičko sučelje) 2. razina DLL datoteke 3. razina upravljačkog programa Sve tri razine podjednako sudjeluju u ostvarivanju sustava. Na razini korisničke aplikacije najprije se stvaraju dvije uvjetne varijable: uvjetna varijabla pristiglih podataka i uvjetna varijabla korisničkog odgovora. Njihova namjena bit će jasnija iz daljnjeg teksta. Korisnička aplikacija se zatim prijavljuje (registrira) kao slušatelj (engl. listener) dogaďaja koje će odašiljati upravljački program. Korisnička aplikacija potom stvara novu dretvu - ta dretva bit će zaduţena isključivo za prikazivanje dijaloga o stvaranju novog procesa i za zapis odgovora korisnika (dozvoljava li se stvaranje procesa ili ne) na odgovarajuću spremničku lokaciju. Dotična dretva najprije čeka (blokira) na uvjetnoj varijabli pristiglih podataka. Nakon što započne stvaranje novog procesa, ispunjen je uvjet opisan tom varijablom i dretva prikazuje dijalog. Nakon što korisnik donese odluku, dretva zapisuje odgovor na odgovarajuću spremničku lokaciju i "otključava" uvjetnu varijablu korisničkog odgovora kao znak da je korisnik donio odluku. Čitav posao dretve ponavlja se u beskonačnoj petlji. Time je opisana prva razina djelovanja. Izvorni tekst prisutan je u WinDriverEventSubscriber razredu GUI dijela praktičnog rada. Prilikom registriranja korisničke aplikacije kao slušatelja, glavni posao obavlja se na razini DLL datoteke. DLL datoteka prosljeďuje zahtjev za registracijom upravljačkom programu, a potom takoďer stvara novu dretvu koja će osluškivati dogaďaje direktno iz upravljačkog programa. Dotična dretva u beskonačnoj petlji najprije stvara novu uvjetnu varijablu i prosljeđuje ju upravljačkom programu. Upravo na tom pozivu (pozivu funkcije za komunikaciju s upravljačkim programom) dretva blokira, zbog posebnog djelovanja od strane upravljačkog programa. Nakon što je novi proces stvoren, dretva se otpušta i u meďuspremnicima navedenima u pozivu spremljeni su podaci koje je pripremio upravljački program. Dretva zatim oslobaďa dretvu korisničke aplikacije koja čeka na uvjetnoj varijabli pristiglih podataka, kao znak da su podaci pristigli, a sama čeka na uvjetnoj varijabli korisničkog odgovora. Nakon što je uvjet opisan tom varijablom ispunjen (korisnik je donio odluku), dretva se otpušta i čita spremničku lokaciju na koju je dretva korisničke aplikacije upisala odluku korisnika. Dotičnu odluku dretva kopira na spremničku lokaciju koja se dijeli izmeďu DLL dijela aplikacije i upravljačkog programa i potom "otključava" uvjetnu varijablu koju je proslijedila upravljačkom programu, a potom cijeli postupak ponavlja u petlji. 84

88 DLL dretva predstavlja drugu razinu djelovanja koja je u suštini jednaka kao i prva, samo što je djelovanje "na niţoj razini", tj. bliţe upravljačkom programu. Izvorni tekst druge razine prisutan je u DriverEventListener razredu DLL dijela praktičnog rada. Na razini upravljačkog programa najprije se obavlja registriranje slušatelja: zauzima se odreďena količina spremničkog prostora i taj se spremnički prostor označava kao dijeljen izmeďu DLL datoteke i upravljačkog programa. Upravo preko tog spremničkog prostora upravljačkom programu će se "dojaviti" odluka korisnika, kao što je opisano za prethodne dvije razine. U trenutku kada primi uvjetnu varijablu od dretve na razini DLL datoteke, upravljački program sprema tu uvjetnu varijablu i označava IRP paket koji se koristio za komunikaciju kao nezavršen (engl. pending), što uzrokuje blokiranje dretve u DLL datoteci. Dotični IRP paket sprema se u posebnu listu. U trenutku kada se "presretne" stvaranje novog procesa umetnutom modifikacijom funkcije MmCreatePeb(), upravljački program najprije čita IRP paket iz liste, u izlazne meďuspremnike IRP paketa postavlja informacije o procesu koji se ţeli stvoriti i završava ga, tj. otpušta dretvu koja je blokirala na pozivu - to je signal za dretvu DLL datoteke da se pokušava stvoriti novi proces. Upravljački program potom čeka na uvjetnoj varijabli koju je primio od dretve iz DLL datoteke - upravo je ovim čekanjem ostvareno zaustavljanje procesa jer postupak stvaranja stoji sve dok se dotična uvjetna varijabla "ne otključa"! Nakon što je DLL dretva dojavila dretvi iz razine korisničke aplikacije da se stvara novi proces, ta dretva prikazuje dijalog korisniku, a odgovor korisnika sprema na spremničku lokaciju koju čita DLL dretva i kopira u dijeljenu spremničku lokaciju i otključava uvjetnu varijablu predanu upravljačkom programu. U ovom trenutku upravljački program čita odluku korisnika i ovisno o odluci dozvoljava pokretanje procesa (poziva originalnu funkciju MmCreatePeb()) ili vraća poruku o greški funkciji koja je pozvala funkciju MmCreatePeb() čime zabranjuje pokretanje procesa. Cjelokupna treća razina sustava prisutna je u "razredu" UsermodeListenersManager upravljačkog programa. Prilikom obavještavanja svih slušatelja od strane upravljačkog programa, najprije je potrebno provjeriti je li lista slušatelja, tj. lista nezavršenih IRP paketa, prazna. Ako je lista prazna, znači da ne postoji niti jedan slušatelj (nitko se nije prijavio kao slušatelj ili se trenutno obraďuje prethodni zahtjev). U takvom slučaju potrebno je čekati dok ne postoji barem jedan slušatelj jer bi inače stvaranje procesa moglo proći bez dojave korisniku, tj. proces bi bio stvoren bez nadzora! Takva konstrukcija sustava uvjetovala je prikazivanje samo jednog dijaloga korisniku u bilo kojem trenutku. Ukoliko korisnik ţeli pokrenuti novi proces dok još nije odlučio o dozvoljavanju pokretanja prethodnog procesa (prisutan je dijalog odluke), stvaranje novog procesa će takoďer biti blokirano sve dok se ne donese odluka o stvaranju starog procesa. Prilikom gašenja aplikacije potrebno je voditi računa o oslobaďanju svih zauzetih resursa (npr. dijeljenog spremničkog prostora) i "uništavanju" svih postojećih nezavršenih IRP paketa. Ukoliko se taj postupak izostavi, postojat će procesi koji se nikada neće pokrenuti, no pri postupku stvaranja ostat će blokirana dretva roditelja, a to je najčešće Windows Explorer aplikacija. Takva situacija rezultirat će zamrzavanjem sustava. Zbog toga je posebna paţnja posvećena oslobaďanju resursa koja se u praktičnom dijelu obavlja na adekvatan način. 85

89 4.6.3 Djelovanje sustava nadzora Izgled sučelja za pokretanje sustava nadzora (u aplikaciji se koristi naziv proaktivna zaštita - engl. proactive defense) prikazan je na sljedećoj slici: Slika 4.24: Sučelje za upravljanje sustavom proaktivne zaštite Početna ideja prilikom razvoja ovog sustava bila je implementacija kompletne sigurnosne politike koja bi bila slična onoj koju je implementirao kolega Grmek, iako to nije bilo definirano zadatkom. Iako je osnovna implementacija načinjena, ona se pokazala relativno nestabilnom u radu i s mnogobrojnim nedostacima. Zbog nedostatka vremena naţalost se nije mogla usavršiti, no kontrola za prikaz politike je i dalje prisutna u aplikaciji kao podsjetnik da je sigurnosna politika u aplikaciji ovakve vrste vrlo vaţna i da će zasigurno biti razvijena tijekom daljnjeg ţivotnog vijeka ove aplikacije (autor namjerava i dalje usavršavati aplikaciju). Zbog nepostojanja sigurnosne politike, korisniku će se dojaviti pokretanje svakog procesa što svakako moţe biti naporno za korisnika čime se riskira isključivanje sustava zaštite. Proaktivna zaštita, odnosno sustav za nadzor pokretanja procesa, pokreće se klikom na tipku "Enable defense" vidljivu u donjem dijelu slike Nakon što je sustav za nadzor pokrenut, pokretanje bilo kojeg procesa bit će presretnuto i korisniku će se prikazati sljedeći dijalog: 86

90 Slika 4.25: Dijalog odluke o pokretanju procesa Na gornjoj slici vidljivo je da korisnik pokušava pokrenuti notepad.exe aplikaciju. Proces roditelj je explorer.exe, a dani su i identifikatori oba procesa. Više informacija o procesu koji se pokreće korisnik moţe dobiti pritiskom na tipku Details: Slika 4.26: Detalji o procesu koji se pokreće U detaljnom opisu procesa moguće je naći informacije o datoteci koja pripada procesu (njenoj lokaciji i ostalim informacijama). Ime procesa (u rubrici Process name) zapravo je poveznica na Google pretraţivač u kojem se kao termin pretrage koristi upravo ime procesa. Klikom na poveznicu dogaďa se pomalo nezgodna situacija: ako korisnik nema trenutno pokrenut web preglednik, klikom će se dotični htjeti pokrenuti, što naravno 87

91 uzrokuje stvaranje novog procesa. Budući da sustav nadzora djeluje, taj se proces neće stvoriti sve dok korisnik ne odluči o stvaranju početnog procesa (u ovom slučaju procesa notepad.exe). Na taj način klikom na poveznicu korisnik prvotno ima dojam da se ništa nije dogodilo jer ne postoji nikakva vizualna povratna informacija. Tek se odlukom o stvaranju početnog procesa stvara novi dijalog u kojemu se vidi da se pokušava stvoriti proces web preglednika. Naravno, stvaranje procesa dozvoljava se pritiskom na tipku Yes, odnosno zabranjuje pritiskom na tipku No. U slučaju zabranjivanja pokretanja, korisniku će se pojaviti sljedeća poruka o greški (ta se poruka iznimno teško moţe izbjeći): Slika 4.27: Poruka o greški prilikom zabrane stvaranja procesa Sustav nadzora prestaje s djelovanjem nakon pritiska na tipku Disable Protection (tipka na istoj poziciji kao i Enable Protection, postaje aktivna nakon pokretanja zaštite). Kako bi se izbjeglo rušenje sustava ili moguće nestabilnosti, sustav nadzora prestaje s djelovanjem i kada se aplikacija ugasi. 88