rootkit

Virginijus Data 2006-09-14 20:11

nufirinta iš system-admins.net, kad neprapultų...

2 Analizės dalis
2.1 Rootkit tipai
2.1.1 Rootkit. Bendrai
Dabartiniu metu turime tris pagrindines rootkit grupes:
• Vartotojo lygio (įkuriami (paslepiami) aplikacijų sluoksnyje)
• Branduolio lygio (įkuriami (paslepiami) branduolio lygyje)
• Bibliotekos (library kits)

Rootkit veikimas:
Rootkit – tai rinkinys įrankių, skirtas įsilaužimo į sistemą fakto paslėpimui ir tam tikrų veiksmų sistemoje atlikimui. Paprastai rootkit turi šiuos įrankius:
• Backdoor programos – sukuria paslėptas galimybes pakartotinam įėjimui į sistemą.
• Paketų šniukštinėtojai (sniffer) – perima ir analizuoja tinklu perduodamus duomenis, gaudo slaptažodžius
• Registravimo žurnalų valymo įrankiai
• DDoS programos – sistema paverčiama DDoS klientu. Įsilaužus į daugiau sistemų, galima galinga DoS ataka.
• Keylogger – programos registruojančios visus klaviatūros paspaudimus.
Rootkit diegimas:
Rootkit įdiegiamas įsilaužėliui patekus į sistemą ir perėmus vartotojo arba administratoriaus teises.
Instaliavimo metu išjungiamas registravimo demonas syslogd. Tada pakeičiami originalūs dvejetainiai failai suklastotais. Po to seka šniukštinėtojo, telnetd, rsh ir finger įjungimas, inetd perkrovimas, ir galiausiai įjungiamas syslogd.
Rootkit paslėpimas:
Sukompiliuotas rootkit gali būti laikomas paslėptame (hidden) kataloge, esančiame ten, kur paprastai vartotojas ar administratorius „neužeina“ (tarkim /var/tolyn/toliau), o pačiam failui suteikiamas įtarimo nekeliantis vardas. Kompiliuojant rootkit, dažnai leidžiama įsilaužėliui pačiam pasirinkti unikalią slaptą direktoriją.
Sniferis naudojamas atsargiai – dauguma IDS pastebi tinklo kortos pervedimą į promiscious būseną, tačiau tai nebus pastebėta jei rootkit yra branduolio lygio.
Tinklo sujungimų slėpimas. Branduolio lygio rootkit, modifikuodamas sys_read() sisteminį kreipinį, nuslepia tinklo aktyvumą “/proc/net/tcp” ir “/proc/net/udp” failuose. T.y. skaitant šiuos failus, sisteminis kreipinys nerodys eilučių bylojančių apie rootkit naudojimąsi tinklu.
Aukščiau paminėti metodai gali paslėpti ir backdoor priėjimą. Ši programa paprastai klausosi tam tikro porto. Ši informacija yra registruojama “/proc/net/tcp” ir “/proc/net/udp” failuose, taigi sys_read() redagavimas leidžia nuslėpti ir backdoor egzistavimą.
2.1.2 Vartotojo lygio rootkit
Vartotojo lygio rootkit paprastai pakeičia originalius sisteminius dvejetainius failus (binaries), tokius kaip ps, ls, netstat ir t.t. perdirbtais dvejetainiais failais. Sukompromituoti sisteminiai failai padeda paslėpti įsilaužėlio buvimą, perduoda suklastotą informaciją sistemos administratoriui, suteikia backdoor priėjimą įsilaužėliui. Kad būtų aiškiau, yra pateikiamas sąrašas pavyzdžių, kaip originalios komandos yra pakeičiamos perdirbtomis, ir kaip tai išnaudojama:

"ls", "find", "du" – šie pakeisti sisteminiai failai paslepia atakuotojo failus, direktorijas ir visą kitką, kas buvo įsilaužėlio įnešta į sistemą.
"ps", "top", "pidof" – šios programos išveda vykdomų procesų sąrašą. Perdirbtos programos paslepia įsilaužėlio vykdomus procesus.
"netstat" - netstat įrankis naudojamas tinklo darbui tikrinti. Pvz., matomi atidaryti portai, sujungimai. Pakeistas netstat paslepia įsilaužėlio instaliuotus servisus tokius kaip SSH demonas ar kiti servisai.
"killall" – pakeista "killall" negalės nutraukti įsilaužėlio paleistų procesų.
"ifconfig" – Jei yra paleistas snifferis, tinklo korta yra pervedama į promiscious būseną. "ifconfig" – patogus įrankis tinklo plokštės parametrų peržiūrai ir keitimui, tačiau pakeistas "ifconfig" neparodys promisc vėliavėlės, kai yra paleistas snifferis.
"crontab" - užkrėstas "crontab" paslėps atakuotojo įvestus „crontab“ įrašus.
"tcpd", "syslogd" - Užkrėsti "tcpd" ir "syslog" neregistruos jokių atakuotojo įvykdytų sujungimų.
2.1.3 Branduolio lygio rootkit
Branduolio lygio rootkit tūno giliai branduolyje. Tai jį padaro itin sunkiai pastebimu ir pašalinamu. Branduolio lygio rootkit yra pažangesni už vartotojo lygio rootkit – jie veikia išnaudodami branduolį ir puikiai juo manipuliuodami.
Branduolio lygio rootkit paprastai veikia naudodamiesi LKM (Loadable Kernel Modules – užkraunami branduolio moduliai). LKM yra skirti įtaisų draiverių (tvarkyklių) užkrovimui. Šie rootkit yra pavojingesni, kadangi jų aptikimas yra žymiai sudėtingesnis. Jei vartotojo lygio rootkit pakeičia failų ps, ls turinį ar pačius failus, tai branduolio lygio rootkit braunasi į patį branduolį ir keičia sisteminius kreipinius (system-calls) tokius kaip read() ar open(). Tokiu būdu ps, ls struktūra ir turinys lieka visiškai nepakitę, tačiau pakeičiamas programos veikimas, taigi taip apsunkinimas rootkit aptikimas.
Taigi branduolio lygio rootkit veikia dviem metodais:
• Instaliuojama įtaiso tvarkyklė, LKM ar kita programa dirbanti branduolio lygyje ir keičiamas kitų sisteminių procesų vykdymo kodas.
• Keičiant branduolio atmintinę – (/dev/kmem ar /dev/mem) ir keičiant procesoriaus vykdomas instrukcijas branduolyje.

Tam, kad detaliau išnagrinėti branduolio lygio rootkit naudojamus metodus, galima juos suskirstyti į tris grupes ir nagrinėt po vieną rootkit iš kiekvienos grupės.
Adore BSD 0.34
Adore tai vienas pirmųjų branduolio lygio rootkit, tačiau jis vis dar aptinkamas įsibrautose sistemose. Adore leidžia įsilaužėliui paslėpti failus, procesus ir tinklo sujungimus. Nėra nei priemonės paleidimui rootkit po sistemos paleidimo iš naujo, nei backdoor programos. Atakuotojas tuo turi pasirūpinti pats.
Rootkit yra įkraunamas į sistemą kaip modulis (adore.o) ir naudojasi įprastiniu operacinės sistemos suteiktu interfeisu. Antrasis modulis (cleaner.o) yra skirtas adore.o modulio paslėpimui. LKM cleaner.o ištrina Adore iš tų duomenų struktūrų, kuriose branduolys laiko informaciją apie modulius. Tokiu būdu įprastiniai sistemos administravimo įrankiai (lsmod) nematys šio rootkit.
Rootkit manipuliuoja sisteminių kreipinių lentele, kad 15 sisteminių kreipinių vykdymą nukreiptų į savo programą.

Pav. 2.1.3 Adore BSD 0.34 modifikuoja sisteminių kreipinių lentelę. IDT parinkus sisteminį kreipinį sys_open, sisteminių kreipinių lentelė iškviečia ne sys_open, o perdirbtą sisteminį kreipinį.
SucKIT 1.3b
Rootkit SucKIT yra plačiai naudojamas dėl savo vartojimo paprastumo, turi backdoor programą ir automatiškai pasileidžia po sistemos perkrovimo. Pateiksiu, kaip veikia šis automatinis rootkit paleidimas. Sistemai startuojant yra vykdomas /sbin/init. SucKIT paleidimo metu šis failas pakeičiamas suklastotu init failu, o originalas pervardinamas ir paslėpiamas (standartiškai pervadinamas initsk12, tačiau rootkit kompiliavimo metu galima duoti savo sugalvotą galūnę). Paleidėjas įterpia rootkit į branduolį ir nuo tada vykdomas originalus init, kuris yra pervardintas. Be to, bet koks priėjimas prie /sbin/init yra nukreipiamas į pervardintą ir paslėptą originalą. Taigi, jei sistemos administratorius tikrina šio failo kontrolinę sumą, ji bus teisinga.

Viena priežasčių, kodėl SucKIT yra populiarus, yra tai, kad nereikia žinoti, kokioje operacinėje sistemoje jis bus diegiamas. Sukompiliuotas SucKIT gali būti instaliuojamas sistemose turinčiose 2.2.x ar 2.4.x versijos branduolius.
Rootkit perkelia save į branduolį pasinaudodamas branduolio atmintimi - /dev/kmem. Šis būdas yra sudėtingesnis, tačiau negali būti taip lengvai užblokuotas, lyginant su pvz., rootkit veikiančiais pasinaudojant branduolio moduliais. Rootkit įterpiamas keliais etapais:
• Pagal tam tikrą šabloną yra surandami sisteminių kreipinių lentelės ir funkcijos kmalloc() adresai branduolio atmintyje.
• Funkcija kmalloc() yra branduolio viduje ir naudojama atminties rezervavimui branduolyje. kmalloc() adresas yra patalpinamas nepanaudotoje sisteminių kreipinių lentelės vietoje.
• kmalloc() yra įvykdomas kaip sisteminis kreipinys ir atmintis branduolyje yra išskiriama (allocated).
• Rootkit įrašomas į ką tik paskirtą vietą branduolyje.
• Rootkit adresas yra perkeliamas į nepanaudotą vietą sisteminių kreipinių lentelėje pakeičiant kmalloc() adresą.
• Rootkit yra iškviečiamas kaip sisteminis kreipinys ir galiausiai veikia branduolio lygyje.

Rootkit SucKIT manipuliuoja sisteminių kreipinių lentele ir nukreipia 24 sisteminius kreipinius į save. Priešingai nei Adore atveju, sisteminių kreipinių lentelė pirma yra nukopijuojama ir tik tada modifikuojama. Tokiu būdu originalas lieka nepaliestas, ir tikrinant sisteminių kreipinių lentelę, nebus rasta jokių rootkit veiklos žymių. Pertraukčių doroklė (interrupt handler) sisteminiams kreipiniams yra pakeičiama, kad kreiptųsi į pakeista sisteminių kreipinių lentelę.

Virginijus Data 2006-09-14 20:11

Pav. 2.1.3 Visų pirma rootkit nukopijuoja sisteminių adresų lentelę ir tik tada ją modifikuoja. Pertraukimų doroklė yra modifikuojama taip, kad sisteminiai kreipiniai būtų imami iš užkrėstos sisteminių kreipinių lentelės.
Adore-NG 0.41
Adore-NG 0.41 – tai perdirbtas Adore rootkit. Šis rootkit naudoja pažangesnius metodus, tačiau dar nėra paplitęs. Kaip ir Adore atveju, taip ir Adore-NG 0.41 neturi nei backdoor programos, nei automatino pasileidimo po sistemos perkrovimo. Šalia įprastinių savybių, Adore-NG automatiškai filtruoja nematomų procesų registravimo pranešimus. Tai labai palengvina naudojimą, ir atakuotojas taip lengvai neišsiduos darydamas nedideles klaidas. Vaikų procesai yra slepiami automatiškai, jei jų tėvas irgi buvo nematomas. Taipogi patobulintas failų ir procesų slėpimas.
Rootkit pakraunamas į sistemą kaip branduolio modulis naudojant operacinės sistemos suteiktą interfeisą. Išjungus modulių palaikymą, toksai rootkit pakrovimas yra negalimas. Adore-NG turi priemonių branduolio modulių ir paties branduolio užkrėtimui. O jei užkrėstas branduolio modulis yra laikomas sveiku, tai atakuotojui net nereikia jo ir slėpti.
Adore-NG visą vykdymo srautą nukreipia į virtualų failų sistemos sluoksnį (VFS) ir nežaidžia su centriniais resursais kaip sisteminių kreipinių lentelė ar IDT. Kadangi UNIX sistemose praktiškai viskas yra apdorojama kaip failas, tai Adore-NG kontroliuodama VFS gali atlikti viską ką atlieką įprastiniai rootkit. Tokio rootkit aptikimas yra sudėtingesnis, kadangi nepakanka stebėti vien pagrindinius resursus.
2.1.4 Bibliotekos
Šie rootkit pasislėpimui naudoja pakeistas bibliotekas. Pvz., t0rn8 naudoja specialią biblioteką (libproc.a), kuri pakeičia standartinę sistemos biblioteką naudojamą proceso informacijos perdavimui iš branduolio į vartotojo lygio įrankius (tokius kaip top, /bin/ps). Tokiu būdu vartotoją pasiekia klaidingi duomenys, tačiau patys įrankiai (top, /bin/ps) lieka neliesti.
2.1.5 Tendencijos
Dabar faktiškai visi nauji rootkit yra branduolio lygio rootkit. Šiuo metu pastebėtos tokios ateities tendencijos:
• Geresnė apsauga prieš HIDS (Host based intrusion detection system). Vis daugiau rootkit turi įrankius padedančius apeiti ar įveikti IDS.
• Rootkit grįsti ne užkraunamais branduolio moduliais (LKM). Yra sekama SucKIT pavyzdžiu.
• Geresnė LKM apsauga nuo aptikimo. Kiekvienai priemonei skirtai aptikti kenkėjiškus LKM, yra sukuriama priemonė, kaip to patikrinimo išvengti. Pvz., KIS rootkit apeina StMichael aptikimo modulį.
• Backdoor slėpimas. Dėl ypatingo slaptumo pasyvūs backdoor tampa vis dažnesni įrankiai rookituose.
• Vis daugiau programų lygio backdoor. Nors kuo daugiau dėmesio skiriama programų saugumui, vis daugiau rootkit lindi pačiose programose.
• Jau dabar rootkit naudojami kenkėjiškų CGI programų (script) patalpinimui.

Rootkit išeities kodai paprastai skelbiami viešai, tai lemia daugybės skirtingų vieno rootkit versijų atsiradimą. Dabartiniu metu dauguma rootkit remiasi sisteminių programų keitimu arba LKM. Ateityje laukiama daugiau rootkit veikiančių atakuojant branduolio atmintį. Rootkit daugiausiai šansų išlikti turės Linux sistemose, nes kitose UNIX šeimos sistemose yra geresnė branduolio apsauga.
2.2 Rootkit aptikimas
2.2.1 Vartotojo lygio rootkit aptikimas
Kontrolinės sumos tikrinimas

Vartotojo lygio rootkit pakeitus dvejetainių failų turinį nauju turiniu, failui paliekama buvusi, originali sukūrimo data, bei dydis, tačiau šio failo kontrolinė suma bus skirtinga kaip ir failo turinys. Tokios programos kaip Tripware ar aide sudaro sisteminių dvejetainių ir konfigūracinių failų kontrolinių sumų duomenų bazę, ir vėliau lygina turimų failų kontrolines sumas su įrašais duomenų bazėje. Tai leidžia administratoriui aptikti pakeistus failus.
Šio metodo trūkumas yra tas, kad kontrolinių sumų sudarymas ir tikrinimas trunka nemažai laiko, taigi šis metodas daugumai sistemos administratorių yra netinkamas. Be to, yra sunku sudaryti tikslų failų sąrašą, kurie turi būti tikrinami, bei reikia apgalvoti, kokius konkrečius parametrus reikia įtraukti į duomenų bazę – failo dydis, sukūrimo data, priėjimo teisės (access), md5, sha1 kontrolinės sumos. Paprastai yra netikrinami katalogai, kuriuose informacija pastoviai kinta - /var, /proc, tačiau tai žinodamas įsilaužėlis kaip tik ir gali patalpinti rootkit šiose netikrinamose direktorijose. Pvz., rootkit Knark, direktorija pagal nutylėjimą ir yra /proc/knark. Įsilaužėlis po rootkit įdiegimo gali paleisti aide, kad ji sukurtų naują duomenų bazę, pagal dabartinę sistemos būsena. Tokiu atveju, kitą kartą tikrinant sistemą, aide lygins sistemą su sistema kurioje jau yra įdiegtas rootkit, taigi nebus rasta jokių pakitimų. Vadinasi, svarbu laikyti duomenų bazę neprieinamą tinklu (offline), arba tik skaitomoje (read only) laikmenoje.
Specialūs rootkit ieškikliai
Tokios programos kaip chkrootkit, Rootkit Hunter ieško joms žinomų rootkit požymių. Paprastai yra ieškoma tam tikrų standartinių direktorijų arba tam tikrų eilučių dvejetainiuose failuose. Pvz., jei egzistuoja direktorija /usr/src/.puta, tai greičiausiai sistemoje yra t0rnkit rootkit. Tačiau šie požymiai nebus rasti, jei įsilaužėlis naudoja labai naują ar šiek tiek pakeistą rootkit. Tam kad išspręsti šia problemą, yra ieškoma ir bendrų rootkit paliekamų požymių. Pvz., tikrinami sisteminiai failai (kaip ir aide atveju), ieškoma įtartinių failų sisteminėse direktorijos, ieškoma LKM, tikrinamas tinklo aktyvumas, atidaryti portai.
Savarankiška paieška
Rootkit galima ieškoti ir nenaudojant papildomų priemonių.
Pvz., direktorijos turinys gali būti patikrinamas keliais būdais (ls, echo).
Naudojant strace įrankį, galima peržiūrėti sisteminius kreipinius. Juose gali matytis visi ls iškviesti sisteminiai kreipiniai. Juose atsispindės tai, kad buvo kreipiamasi į tam tikras direktorijas.
Paieška pagal inode numerius, naudojant komandą ls –li. Sistemos programos, tokios kaip ps, ls ir panašiai, yra įrašomos sistemos instaliavimo metu, todėl programų, esančių vienoje direktorijoje, inode numeriai turėtų rikiuotis iš eilės. Radus failų su paeiliui einančiais inode numeriais, kurie išsiskiria iš kitų numerių, galima įtarti, kad tie failai yra suklastoti, o sistemoje yra įdiegtas rootkit.
Pavyzdžiai pateikiami 2.4 skyriuje - Eksperimentai su rootkit ir jų aptikimo priemonėmis.
2.2.2 Branduolio lygio rootkit aptikimas
Nedideli nesklandumai dažnai sukelia administratoriaus įtarimą, ir jis siekia patikrinti, ar sistemoje nėra instaliuotas rootkit. Neturint tikslios informacijos, serverio atjungimas nuo tinklo nėra geras ir priimtinas administratoriaus sprendimas. Be to, paprastai ilgesniems tyrimams nėra pakankamai laiko. Šie apribojimai labai suvaržo tyrinėjimo galimybes. Žemiau yra pateikiami pagrindiniai branduolio lygio rootkit aptikimo metodai.
Kontrolinės sumos ir specialūs rootkit tikrintojai
Programos generuojančios ir tikrinančios kontrolines sumas jau buvo aprašytos kalbant apie vartotojo lygio rootkit aptikimą. Šios priemonės yra naudingos ir ieškant branduolio lygio rootkit. Šio metodo minusai branduolio lygio rootkit atveju yra tai, kad rootkit gali nukreipti tikrintojus į bet kokius (t.y. originalius) failus. Vis dėlto metodas yra naudotinas, kadangi dauguma atakuotojų nėra labai gerai nusimanantys, o be to, net ir tinkamai naudojamas rootkit niekada nesukurs nepriekaištingos sistemos imitacijos.
Specialūs rootkit ieškikliai, apie kuriuos jau pasakota skyriuje apie vartotojo lygio rootkit ieškiklius, taipogi gali būti naudojami ir branduolio lygio rootkit požymių paieškai, tačiau, tirdami sistemą, jie labai remiasi žinomų rootkit žymėmis.
Svarbios branduolio struktūros
Daug branduolio lygio rootkit galima aptikti lyginant iš anksto pasidarytas sveikos sistemos svarbiausiųjų branduolio struktūrų (critical kernel structure) kopijas su turimomis struktūromis. Šiam darbui Linux sistemose yra skirti tokie įrankiai kaip kern_check, KSTAT, determine. Rootkit aptinkamas nesutapus pvz., sisteminių kreipinių lentelės įrašų adresams, nesutapus pačios lentelės adresams.
Šių programų minusas yra tai, kad, ieškant rootkit reikia turėti patikimų šaltinių, pavyzdžiui – kstat turi būti instaliuojamas švarioje sistemoje, kern_check remiasi System.map failu. Išimtis būtų determine, kuris daugiausia skirtas ieškoti Adore rootkit, taipogi remiasi požymių duomenų baze, tačiau pastaroji yra pateikiama kartu su determine išeities failais.
Sisteminių kreipinių parametrų matavimai
Kad paslėptų atakuotoją daugelis rootkit atlieka sudėtingus veiksmus. Dėl to gali ženkliai skirtis instrukcijų skaičius pakeistame sisteminiame kreipinyje lyginant jį su originaliu. Instrukcijų skaičiaus matavimas kiekvienam sisteminiam kreipiniui yra tinkamas metodas rootkit aptikimui. Šiuo metodu pagrįstas patchfinder programos veikimas. Ši programa vykdo sisteminius kreipinius ir skaičiuoja jų atliekamų instrukcijų skaičių. Tam kad palyginti su originaliais duomenimis, reikia būti atlikus matavimus ir švarioje sistemoje. Kadangi sisteminio kreipinio algoritmas paprastai yra pakankamai sudėtingas, turintis pvz., kelias „if“ atšakas, instrukcijų skaičius tam pačiam kreipiniui gali skirtis, tiesa, paprastai šis skirtumas nebus didesnis nei 10 (ypatingais atvejais gali siekti 200), o rootkit paveiktose sistemose šie skirtumai išauga iki kelių šimtų.
Panašus į jau paminėtą būdą yra sistemino kreipinio trukmės matavimas. Šis metodas yra paprastas, tačiau jis efektyvus tik su lėtesniais procesoriais, kadangi sistemose su galingais procesoriais (virš 1GHz) vykdymo laikai tampa labai trumpi ir neįmanoma tiksliai nustatyti ar sisteminis kreipinys yra originalus, ar ne.
„Teisminė“ (forensic) analizė
Teisminė analizė teoriškai gali rasti ir nagrinėti viską, kas yra įrašyta į diską ar atmintinę. Bet koks rašymas į diską/atmintinę yra nepageidautinas, kadangi tai gali sunaikinti įsilaužėlio ištrintus failus, apsunkinti įsilaužėlio atliktų veiksmų išsiaiškinimą. Kad išvengti rašymo į atmintį/diską reikia pasidaryti disko ir atmininės kopijas (dump). Dėl didelių laiko ir resursų kaštų, ir kadangi sistema bent trumpam turi būti atjungta nuo tinklo, tokia analizė negali būti priskirta, kaip priemonė rootkit aptikimui. Analizė gali būti vykdoma greičiau ir paprasčiau, jei turimos švarios sistemos kontrolinės sumos.
Tinklo kontrolė
Rootkit užkrėsta sistema greičiausiai atlikinės veiksmus, generuojančius interneto srautą. Šį srautą gali aptikti pasyvus tinklo stebėjimas. Atvirų prievadų (port) skanavimas gali aptikti kai kurias backdoor programas. Įsilaužimo aptikimo sistemos (intrusion detection system - IDS) gali pastebėti rootkit atsiradimą arba jo veiklą.
Rankinė paieška
Nėra tobulo rootkit, o ir patys atakuotojai daro klaidas. Rankinė pėdsakų paieška registracijos žurnaluose ir pačioje sistemoje gali visada duoti naudingų įkalčių. Pvz., rootkit SucKIT naudoja pažangias savęs slėpimo technologijas, tačiau jį paprasta aptikti jei tikrinsim /sbin/init failą, kurį rootkit perdirbo tam, kad galėtų pasileisti po sistemos perkrovimo. Šis failas buvo paprasčiausiai pervardintas naudojant mv komandą, kuri naudoja sisteminį kreipinį rename(). Rename() nėra vienas iš tų 24 kreipinių, kuriais manipuliuoja rootkit, taigi jis nėra nukreipiamas į originalų ir pakeistą failą. Dar vienas naudingas metodas yra kruopšti /proc direktorijos peržiūra. Šis metodas dažnai atidengia paslėptus procesus.
Taipogi, naudojant GDB įrankį, rankiniu būdu galima tirti ir sisteminių adresų lentelę, joje esančius sisteminių kreipinių adresus, jų išeities kodą (asm).
Visi pavyzdžiai pateikiami trečiame skyriuje – Eksperimentai su rootkit ir jų aptikimo priemonėmis.

Virginijus Data 2006-09-14 20:12

2.2.3 Išvados

Kaip matyti, kiekvienai rootkit rūšiai esama įvairių priemonių jų aptikimui. Dėl rootkit įvairovės negalime pasikliauti vienu ar dviem metodais. Svarbiausi aptikimo metodų kokybės parametrai yra metodo tikslumas, savarankiškumas ir paprastumas. Metodo tikslumas – kaip tiksliai galima aptikti rootkit, savarankiškumas – ar reikia remtis švarios sistemos duomenimis, paprastumas – ar metodas yra paprastas realizavimui.
Taip pat matyti, kad vartotojo lygio rootkit galime aptikti pakankamai lengvai lyginant su branduolio lygio rootkit.
2.3 Prevencija
2.3.1 Užkraunamų modulių išjungimas

Daugybė rootkit tiesiog neveikia, jei yra išjungtas dinaminis tvarkyklių pakrovimas per modulio interfeisą. Tačiau jei veikimo metu nebegali būti užkraunamos tvarkyklės, padidėja administracinis krūvis. Serveriuose, kuriuose retai diegiama nauja aparatūrinė įranga, tai nesukelia didelių sunkumų, tačiau sistemose su daugialypės terpės (multimedia) aparatūrine įranga ši prevencinė priemonė yra netinkama. Be to, kai kurie rootkit (SucKIT, Adore-NG) veikia ir ne kaip LKM.

2.3.2 Branduolio atminties apsaugojimas

Kadangi yra daugybė būdų, kaip prieiti prie branduolio atminties /dev/kmem, vienintelė efektyvi apsauga yra privaloma priėjimo kontrolė (mandatory access control). Ji gali net apriboti priėjimą root vartotojui. Linux operacinėse sistemose ši priemonė yra instaliuojama sistemoje taisant (patch) branduolį, ir jau yra įtraukta keliose distribucijose. Labai mažai programų priklauso nuo leidimo rašyti į /dev/kmem. Priklausomai nuo aparatinės įrangos konfigūracijos, X-serveris XFree86 gali būti būti viena iš jų.
Užkraunamų modulių išjungimas kartu su privaloma priėjimo kontrole /dev/kmem failui daugumai rootkit užkerta kelią link branduolio.

2.3.3 Anti-rootkit moduliai

Keletas branduolio modulių buvo sukurti tik tam, kad neleistų užsikrauti branduolio tipo rootkit. Tuo tikslu manipuliuojama sisteminiais kreipiniais taip, kaip tai daro patys rootkit. Be to įtraukiami ir integralumo tikrintojai, kurie žiūri, ar anti-rootkit modulis vis dar dirba, ar jis buvo išjungtas dėl branduolio rootkit. Vienas šios metodikos pavyzdžių yra Linux branduolio modulis StMichael. Tačiau kai kurie rootkit jau prisitaikė prie StMichael modulio.
2.3.4 Išvados

Privaloma priėjimo kontrolė bei LKM uždraudimas gali užkirsti kelią daugumai branduolio lygio rootkit, tačiau šios priemonės tinkamos ne visoms sistemoms. Be to dažnai nauji rootkit prisitaiko prie egzistuojančių apsaugos priemonių. Iš kitos pusės, kadangi rootkit gali būti įdiegtas tik nulaužtoje sistemoje, reikia pirmiausia pasirūpinti jos apsauga.
2.4 Eksperimentai su rootkit ir jų aptikimo priemonėmis

Virginijus Data 2006-09-14 20:13

2.4.1 T0rn
T0rn veikimas
T0rn – gerai žinomas vartotojo lygio rootkit, kurio veikimo principas – sisteminių dvejetainių failų pakeitimas. Pagal tai šis rootkit nesunkiai demaskuojamas.
T0rn paieška
Aide. Tikrinant sistemos integralumą su aide programa, buvo aptikti pakeisti sisteminiai dvejetainiai failai.

AIDE, version 0.10

AIDE found differences between database and filesystem!!
Start timestamp: 2005-03-25 14:04:26
Summary:
Total number of files=1005,added files=3,removed files=0,changed files=7

Added files:
added:/etc/rc.d/rc.sysinit
added:/etc/ttyhash
added:/sbin/xlogin
Changed files:
changed:/bin
changed:/bin/ls
changed:/bin/ps
changed:/bin/login
changed:/bin/netstat
changed:/etc/inetd.conf
changed:/sbin
Detailed information about changes:

File: /bin/ps
Size : 57184 , 39415
Bcount : 112 , 80
Uid : 0 , 711
Gid : 1 , 100
Ctime : 2005-03-24 11:25:41 , 2005-03-25 13:55:10
Inode : 14777 , 73736
MD5 : mNvPw7pFRvcWLmf/nv45Iw== , 8zjSboJtpQZtwagKMx1xiA==
SHA1 : N4AdMl/SV19sAf6UWlE/4xRetTM= , YFqByeoBApdETLRL7AXeCo7q4Gk=
Toliau pateikiama detali informacija apie kiekvieną pakeistą failą, kaip ir apie pavyzdyje pateiktą /bin/ps.

Chkrootkit. Tikrinant su chkrootkit taip pat aptikti pakeisti sisteminiai dvejetainiai failai.

Checking `login'... INFECTED
Checking `ps'... INFECTED
Checking `rshd'... INFECTED
...

Paieškai apsunkinti buvo pakeistas rootkit išeities kodas, tuo pakeičiant defaultines rootkit direktorijas į /dev/sdc0/.aahoi/, tačiau rootkit vistiek buvo aptiktas:

Checking `aliens'...
/dev/sdc0/.aahoi/.1addr /dev/sdc0/.aahoi/.1proc

Rkhunter. Rkhunter negalėjo nustatyti konkretaus rootkit, kadangi torn požymis - standartinė direktorija, buvo pakeistas. Tačiau buvo atrastas faktas, jog pakeisti sisteminiai dvejetainiai failai, bei nebuvo rastas syslog demonas.

Checking binaries

* System tools
Performing 'known good' check...
/bin/login BAD
/bin/ls BAD
/bin/netstat BAD
..
Check rootkits
* Default files and directories

Rootkit 'T0rn Rootkit'... [ OK ]
...
Checking for running syslog slave... [Warning!]
Info: Cannot find syslog/syslog-ng daemon

Patchfinder. Patchfinder rootkit neaptiko, nes ši priemonė skirta tik branduolio lygio rootkit paieškai.

Virginijus Data 2006-09-14 20:14

Rankinė paieška.

Tai, ką automatiškai atlieka aide, galima atlikti ir rankomis.

root@pieva:~# ls -li /bin /usr/bin/ /usr/sbin/ /sbin/ | sort –n

172034 -rwxr-xr-x 1 root root 16504 Jul 16 2004 cat
172035 lrwxrwxrwx 1 root root 4 Mar 30 02:33 sh -> bash
...
172117 -rwxr-xr-x 1 root root 12216 Jul 16 2004 sync
172118 -rwxr-xr-x 1 root root 30360 Jul 16 2004 touch
172119 -rwxr-xr-x 1 root root 11640 Jul 16 2004 true
172120 -rwxr-xr-x 1 root root 13848 Jul 16 2004 uname
602302 -rwxr-xr-x 1 root root 53364 Apr 23 2004 netstat
602305 -rwxr-xr-x 1 root root 39484 Jul 16 2004 ls
602307 -rwxr-xr-x 1 root root 31336 Apr 13 2004 ps

Dėmesį iš karto atkreipia sąrašo pabaigoje esantys failai.
Kaip matome išsiskiria inode numeriai. Jie eina iš eiles, nors failai skirtingu paskirčių, yra skirtingose direktorijose, sistemos instaliavimo metu buvo instaliuoti ne iš eilės.
Turėdami sistemos kopija, galime palyginti gautus parametrus su originaliais ir įsitikinti tuo, kad dabartinėje sistemoje turimi failai yra suklastoti.

Nagrinėdami suklastotus failus, galime juose ieškoti kelių į rootkit direktorijas:

root@pieva:~# strings /bin/ps|grep /
/lib/ld-linux.so.1
/usr/src/.puta/.1proc
%s/.psdevtab
/tmp/psdevtab

Matome paslėptas direktorijas. jas ir reikėtų patikrinti atidžiau.

Branduolio struktūrų tikrintojai.

Determine, kern_chec. Kadangi t0rn rootkit nieko nedaro su branduoliu, šios programos rootkit neaptinka.

Virginijus Data 2006-09-14 20:15

Išvados

Rootkit aptikimo priemonės atlieka savo darbą ir randa faktą, kad pakeisti sisteminiai dvejetainiai failai. Reikia išskirti chkrootkit pranašumą, kuris aptiko rootkit direktorijas, nors jos ir buvo pakeistos.
Rankiniu būdu aptikti t0rn rootkit nėra labai sunku, be to šis metodas turi didelį privalumą – norint aptikti rootkit, nereikia turėti jokių atsarginių kopijų – pakanka sistemą tikrinti jos neliečiant, - pvz., iš CD..
2.4.2 SucKIT 1.3a
SuckIT veikimas
//įjungus file hiding, nematome .sk12 direktorijos
root@pieva:/usr/share/locale/sk# ls -ali
total 3
10587 drwxr-xr-x 4 root root 104 Mar 24 15:16 .
10541 drwxr-xr-x 71 root root 1768 Feb 28 2003 ..
10588 drwxr-xr-x 2 root root 488 Feb 28 2003 LC_MESSAGES

//išjungus file hiding, direktorija .sk12 matosi
root@pieva:/usr/share/locale/sk# ls -ali
total 4
10587 drwxr-xr-x 4 root root 104 Mar 24 15:16 .
10541 drwxr-xr-x 71 root root 1768 Feb 28 2003 ..
74467 drw-r--r-- 2 root root 72 Mar 24 15:17 .sk12
10588 drwxr-xr-x 2 root root 488 Feb 28 2003 LC_MESSAGES
SuckIT paieška
Aide. Tikrinant sistemą su aide įrankiu, buvo aptiktas pakeistas /sbin/init failas.

debian:/home/aurimas/sk-1.3a# aide -C
Added files:
added:/sbin/initsk12
Changed files:
changed:/sbin/init
Detailed information about changes:

Directory: /sbin
Mtime : 2005-03-31 23:58:40 , 2005-05-22 22:20:20
Ctime : 2005-03-31 23:58:40 , 2005-05-22 22:20:20

File: /sbin/init
Size : 31432 , 29852
Bcount : 64 , 62
Mtime : 2005-01-05 00:43:09 , 2005-05-22 22:20:20
Ctime : 2005-03-30 02:33:12 , 2005-05-22 22:20:20
Inode : 217111 , 217224
MD5 : EJFbPd8AhPJH2EeQpXJpug== , Peq7Mc5mD+umrJc/SOOQPQ==
SHA1 : XkgbGl+j1QS+psxg1bWh2dyfykM= , V1OEdFA2x9GRJsJkY6bVz5RTgj4=

Rkhunter. Rkhunter atrado paslėptą rootkit direktoriją.

[15:54:34] *** Start scan Suckit Rootkit ***
[15:54:34] - File /sbin/initsk12... OK. Not found.
......
[15:54:34] - Directory /usr/share/locale/sk/.sk12... WARNING! Exists.

Chkrootkit. Chkrootkit tikrinimo metu buvo aptikta tiek rootkit direktorija, tiek pakeistas /sbin/init failas bei faktas, kad yra paslėptų procesų.

Checking `lkm'... You have 5 process hidden for readdir command
You have 5 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
Patchfinder. Tikrinimo su patchfinder metu, pasirodė pranešimas, kad modulis patchfider.o nebuvo užkrautas. Remiantis patchfinder dokumentacija, ši situacija yra tipiška, jei sistema užkrėsta SucKIT rootkit.

Virginijus Data 2006-09-14 20:15

oot@pieva:/tmp/detectors/patchfinder# ./patchfinder -c svaru

---== ALERT! ==--
It seems that module patchfinder.o is not loaded. However if you are
sure that it is loaded,then this situation means that with your
kernel is something wrong! Probably there is a rootkit installed!

Kern_check. Kern_check įrankis lygina branduolio atmintyje esančius sisteminės lentelės ir sisteminių kreipinių adresus su System.map failu, todėl būtina turėti patikimą System.map kopiją. Programa, pastebėjusi, jog pakeistas sisteminių adresų lentelės adresas, praneša, kad įtariamas SuckIT rootkito buvimas sistemoje.
WARNING: (kernel) 0xc0244970 != 0xd9870000 (int 80h) [sys_call_table]
WARNING: (int 80h) 0xd9870000 != 0xc0244970 (map) [sys_call_table]
WARNING: This indicates the presence of the SuckIT rootkit.
WARNING: (kernel) 0xd9871270 != 0xc0106f65 (map) [002][sys_fork]
WARNING: (kernel) 0xd987160a != 0xc01314dd (map) [003][sys_read]
WARNING: (kernel) 0xd987154d != 0xc01315c2 (map) [004][sys_write]
WARNING: (kernel) 0xd9871948 != 0xc0131061 (map) [005][sys_open]
...
WARNING: (kernel) 0xd987120b != 0xc0106f7b (map) [120][sys_clone]
WARNING: (kernel) 0xd9871337 != 0xc013d686 (map) [141][sys_getdents]

Samhain. Samhein IDS pastebėjo pakitimus branduolyje po rootkit instaliavimo.
CRIT : [2005-04-13T15:49:29+0300] msg= syscall=<000 system_call (interrupt handler)>, path=Determine. Determine įrankis nesugebėjo aptikti rootkit, netgi ir tuo atveju, jei rootkit slėpdavo procesus.

Rankinė paieška. Sisteminis kreipinys rename() nėra paveiktas rootkit'o, taigi sistema reaguoja i bandymą pervadinti paslėptą katalogą. Veiksmai atliekami įjungus "file hiding":

aurimas@pieva:/usr/share/locale/sk$ mv .sk12 /tmp/radau
mv: cannot stat `.sk12/.sniffer': Permission denied
aurimas@pieva:/usr/share/locale/sk$ mv .sk13 /tmp/radau
mv: cannot stat `.sk13': No such file or directory

init yra užkrėstas failas, tačiau atliekant veiksmus su juo, sistema mus nukreipia į pervadintą originalų init - /sbin/initsk12. nors kopijavome /sbin/init
Kopijuodami init failą, gausime analogišką failą
debian:/sbin# ./init
Usage: init 0123456SsQqAaBbCcUu //matome, kad vykdomas originalas
debian:/sbin# cp init iint.old
debian:/sbin# md5sum init
10915b3ddf0084f247d84790a57269ba init
debian:/sbin# md5sum iint.old
10915b3ddf0084f247d84790a57269ba iint.old
debian:/sbin# ./iint.old
Usage: iint.old 0123456SsQqAaBbCcUu //kopijos sutampa

Pervardinant init failą, yra pervardinamas būtent /sbin/init failas, o ne originalusis init, kadangi šiuo atveju (iškviečiant sisteminį kreipinį rename()) sistema nenukreipia į originalųjį failą.
debian:/sbin# mv init init.bak
Švarioje sistemoje gautas failas init.bak, būtų tapatus failui init, tačiau patikrinkime kontrolinę sumą:
debian:/sbin# md5sum init.bak
3deabb31ce660feba6ac973f48e3903d init.bak
md5 kontrolinė suma skiriasi, kadangi dabar tikrinamas užkrėstas failas. Paleisdami šį failą, galime įsitikinti, jog jis užkrėstas.
debian:/sbin# ./init.bak
[===== SucKIT version 1.3a, Mar 24 2005 =====]
[====== (c)oded by sd & devik , 2002 ======]
Detected version: 1.3a
use:
./init.bak [args]
u - uninstall
i - make pid invisible
v - make pid visible
f [0/1] - toggle file hiding
p [0/1] - toggle pid hiding

taipogi išsiskiria pasikeitęs inode numeris:
švarioje sistemoje:
217111 -rwxr-xr-x 1 root root 31432 Jan 5 00:43 init
užkrėstoje sistemoje, jis buvo pats aukščiausias:
debian:/sbin# ls -i | grep init
217223 init
217132 telinit

Virginijus Data 2006-09-14 20:16

Išvados
Nors SucKIT naudoja sudėtingus metodus pasislėpimui (originalios sisteminių kreipinių lentelės perkopijavimas į kitą vietą), tačiau jis nesunkiai aptinkamas dėl pakeisto pakartotinio programos /sbin/init paleidimo. Faktas, kad failas pakeistas, yra aptinkamas sistemos integralumo tikrinimo programomis, tokiomis kaip aide.
Rkhunter aptiko tik standartines SuckIT direktorijas.
Chkrootkit aptinka ir tą faktą, kad sistemoje esama paslėptų procesų.
Tikrinimo su patchfinder metu, pasirodė pranešimas, kad modulis patchfinder.o nebuvo užkrautas. Remiantis patchfinder dokumentacija, ši situacija yra tipiška, jei sistema užkrėsta SucKIT rootkit.
Reikia paminėti, kad rootkit neveikia sistemose su 2.6 branduoliais, bei nepavyko jos paleisti tiriamoje sistemoje įdiegus 2.4.29 branduolį, - rootkit nerasdavo funkcijos kmalloc() adreso.
2.4.3 KNARK
KNARK veikimas
Knark rootkit, veikia kaip užkraunamas branduolio modulis (loadable kernel module - LKM) – knark.o. Paprastas naudoti, turi įrankius failų, procesų slėpimui, vartotojo teisių pakeitimui į root teises, proceso vartotojo pakeitimui.
KNARK paieška
Aide. Tikrinant sistemos integralumą su aide programa, nebuvo pastebėta jokių neatitikimų, kadangi knark įsikuria /proc/knark direktorijoje, o /proc direktorija paprastai nėra tikrinama aide programos, dėl dažnai kintančio jos turinio.

Virginijus Data 2006-09-14 20:16

AIDE, version 0.10

### All files match AIDE database. Looks okay!

Rkhunter. Tikrinant su rkhunter, knark rootkit buvo rastas pagal standartines direktorijas, tačiau ši priemonė nerado knark LKM!!!

debian:/home/aurimas/rkhunter# rkhunter -c --createlogfile

[18:43:45] *** Start scan Knark ***
[18:43:45] - File /proc/knark/pids... WARNING! Exists.
[18:43:45] - Directory /proc/knark... WARNING! Exists
Rootkit 'Knark'... [ Warning! ]

Checking loaded kernel modules... [ OK ]

Chkrootkit. Tikrinant su chkrootkit, nebuvo rastos standartinės direktorijos, nes jos ir nebuvo tikrintos, tačiau sėkmingai buvo aptiktas knark LKM!

debian:/home/aurimas/chkrootkit-0.45# ./chkrootkit
Checking `lkm'... Warning: Knark LKM installed

Patchfinder. Tikrinant su patchfinder, buvo aptikti akivaizdūs testų metu atliekamų instrukcijų skaičiaus skirtumai.

debian:/home/aurimas/patchfinder# ./patchfinder -c svaru

test name | current | clear | diff | status
------------------------------------------------------
open_file | 1461| 1470| -9| ok
stat_file | 1271| 1278| -7| ok
read_file | 616| 589| 27| (?)
open_kmem | 1535| 1543| -8| ok
readdir_root | 3641| 2918| 723| ALERT!
readdir_proc | 3195| 2468| 727| ALERT!
read_proc_net_tcp | 10703| 10676| 27| (?)
lseek_kmem | 209| 208| 1| ok
read_kmem | 356| 328| 28| (?)

Rankinė paieška. Rankinė paieška naudojantis GDB įrankiu

Virginijus Data 2006-09-14 20:17

Rankinė paieška. Rankinė paieška naudojantis GDB įrankiu

Surandame sisteminių kreipinių lentelės adresą:

root@pieva # cat /boot/System.map-2.4.29 | grep sys_call_table
c02e18f6 R __kstrtab_sys_call_table
c02ede88 R __ksymtab_sys_call_table
c02f0cf4 D sys_call_table

GDB įrankio pagalba nuskaitome sisteminių kreipinių lentelę. Kiekvienas adresas atitinką sisteminį kreipinį. Sisteminiai kreipiniai eilės tvarka yra pateikti faile /usr/src/linux/arch/i386/kernel/entry.S

root@pieva:~# gdb /usr/src/linux/vmlinux

(gdb) x/255 0xc02f0cf4
0xc02f0cf4 : 0xc0125160 0xc011d360 0xc0105ad0 0xc013da60
0xc02f0d04 : 0xc013dbd0 0xc013d390 0xc013d550 0xc011d790
0xc02f0d14 : 0xc013d450 0xc014bb20 0xc014b650 0xc0105b60
...

Tam, kad nuskaityti dabartinę branduolio būseną, GDB paleidžiamas su parametru /proc/kcore.

root@pieva:~# gdb /usr/src/linux/vmlinux /proc/kcore

(gdb) x/255 0xc02f0cf4
0xc02f0cf4 : 0xc0125160 0xc011d360 0xe4c2a748 0xe4c2aa88
0xc02f0d04 : 0xc013dbd0 0xc013d390 0xc013d550 0xc011d790
0xc02f0d14 : 0xc013d450 0xc014bb20 0xc014b650 0xe4c2aee8
...
0xc02f0ed4 : 0xe4c2a7b0 0xc0126820 0xc0126620 0xc010ced0
...
0xc02f0f24 : 0xc013d940 0xe4c2a498 0xc014f0e0 0xc0151b40
...
0xc02f1064 : 0xe4c2a5d4 0xc014d870 0xc0125160 0xc0125160
...
0xc02f10d4 : 0xc0125160 0xc0125160 0xe4c280f9 0xc0125160
...

Sulyginę gautus duomenis, su prieš tai nuskaitytais, pastebėsime, kad keletas sisteminių kreipinių adresų nesutampa (jie paryškinti pavyzdyje). Pagal failų entry.S ar /usr/include/asm/unistd.h turinį galime nustatyti, koks sisteminis kreipinys yra pakeistas
Be to, į akis iš karto krenta ir tai, kad tie sisteminiai kreipiniai turi žymiai aukštesnės eilės adresus – tiriamoje sistemoje aukščiausias įrašas System.map faile yra c03ce28c. Tai leidžia aptikti sistemos pažeidimą be lyginimo su anksčiau padarytom kopijom.

entry.S:

.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
.long SYMBOL_NAME(sys_waitpid)
.long SYMBOL_NAME(sys_creat)
.long SYMBOL_NAME(sys_link)
.long SYMBOL_NAME(sys_unlink) /* 10 */
.long SYMBOL_NAME(sys_getpid) /* 20 */
...

Virginijus Data 2006-09-14 20:18

Įtardami, jog tai knark rootkit, galime patikrinti jo standartinę direktoriją /proc/knark. Atakuotojui įjungus jos slėpimą, ls /proc komanda neparodys jos, tačiau galime tiesiog įeiti į ją – cd /proc/knark. Atakuotojo laisvę varžo, tai, kad negalima paprastai pakeisti šios direktorijos. Ji nefigūruoja išeities koduose, - ji sukuriama tik užkrovus knark LKM. Patį knark LKM galime aptikti su komanda lsmod. Pervardinus modulį neutraliu vardu, jis ir užsikraus tuo naujuoju vardu, taip suklaidindamas administratorių, tačiau rootkit aptikimo priemonė chkrootkit, vistiek aptiks knark LKM.:
debian:/home/aurimas/knark-2.4.3-release# mv knark.o knorr.o
debian:/home/aurimas/knark-2.4.3-release# insmod knorr.o
Warning: loading knorr.o will taint the kernel: no license
See [nuoroda] for information about tainted modules
Module knorr loaded, with warnings
debian:/home/aurimas/knark-2.4.3-release# lsmod
Module Size Used by Tainted: P
knorr 8076 0 (unused)
8139too 14440 1

Modulio paslėpimui yra skirtas kitas LKM - modhide, tačiau pats knark autorius pripažįsta, kad jis nėra tobulas, gali sukelti problemų ar tiesiog neveikti. Mano tiriamoje sistemoje taip ir atsitiko, - modulis nebuvo užkrautas:
debian:/home/aurimas/knark-2.4.3-release# insmod -f modhide.o
Warning: loading modhide.o will taint the kernel: no license
See [nuoroda] for information about tainted modules
Warning: loading modhide.o will taint the kernel: forced load
modhide.o: init_module: Operation not permitted
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.
You may find more information in syslog or the output from dmesg

Virginijus Data 2006-09-14 20:18

Išvados
Pilnai pasiteisino chkrootkit, patchfinder priemonės ir rankinė paieška. Nors rkhunter aptiko rootkit tik pagal default direktorijas, galima pasikliaut ir juo, kadangi negalima paprastai pakeisti standartinių knark direktorijų.
2.4.4 Adore-0.42
Adore veikimas
Adore veikimo principas yra lygiai toks, pat, kaip ir knark rootkit, - užkraunami du LKM, kurie, skirtingai nei knark atveju, nematomi su komanda lsmod, ir redaguojama sisteminių kreipinių lentelė. Dar vienas skirtumas nuo knark, - nesukuriama jokia direktorija.
Adore paieška
Aide. Paieška su aide įrankiu buvo nesėkminga, kadangi, rootkit nesukūrė jokių nuosavų direktorijų.

AIDE, version 0.10

### All files match AIDE database. Looks okay!

Chkrootkit. Tikrindamas LKM, chkrootkit atrado paslėptą procesą, bei nustatė, kad sistemoje instaliuotas Adore rootkit.
Checking `lkm'... You have 1 process hidden for readdir command
You have 1 process hidden for ps command
SIGINVISIBLE Adore found
chkproc: Warning: Possible LKM Trojan installed

Tikslesniam paslėptų procesų nustatymui chkrootkit reikia leisti eksperto režimu (./chkrootkit x) , arba paleidžiant chkproc priemonę, su kuria galime detalizuoti paslėptą procesą.

./chkproc -v -v
PID 972(/proc/972): not in readdir output
PID 972: not in ps output
CWD 972: /home/aurimas
EXE 972: /usr/lib/mozilla/mozilla-bin
You have 1 process hidden for readdir command
You have 1 process hidden for ps command
SIGINVISIBLE Adore found

Virginijus Data 2006-09-14 20:19

Rkhunter. Rkhunter nerado jokių įtarimą keliančių požymių sistemoje. Nenuostabu, nes Adore rootkit nefigūruoja Rkhunter aptinkamų rootkit sąraše.

Checking loaded kernel modules... [ OK ]

Patchfinder. Tikrinant sistemą, buvo aptikti akivaizdūs testų metu atliekamų instrukcijų skaičiaus skirtumai.

test name | current | clear | diff | status
------------------------------------------------------
open_file | 7178| 1470| 5708| ALERT!
stat_file | 7245| 1278| 5967| ALERT!
read_file | 589| 589| 0| ok
open_kmem | 7195| 1543| 5652| ALERT!
readdir_root | 6736| 2918| 3818| ALERT!
readdir_proc | 18875| 2468| 16407| ALERT!
read_proc_net_tcp | 10674| 10676| -2| ok
lseek_kmem | 208| 208| 0| ok
read_kmem | 329| 328| 1| ok

Rankinė paieška. Rankinė paieška naudojant GDB įrankį. Naudojantis ta pačia metodika, kaip ir knark paieškos atveju, buvo aptikti pakitimai sisteminėj kreipinių lentelėj:

debian:/boot# gdb /usr/src/linux/vmlinux /proc/kcore

(gdb) x/255 0xc02f0cf4
0xc02f0cf4 : 0xc0125160 0xc011d360 0xe4c36830 0xc013da60
0xc02f0d04 : 0xe4c36ab0 0xe4c37a80 0xe4c36c00 0xc011d790
Išvados
Aide ir rkhunter rootkit visai nepastebėjo, o chkrootkit ir patchfinder jį aptiko. Rootkit taipogi buvo rastas nagrinėjant sisteminių kreipinių lentelę.

2.4.5 Adore-NG 0.51
Adore-NG veikimas
Adore-NG veikia VFS sluoksnyje. Adore-NG visą vykdymo srautą nukreipia į VFS ir nežaidžia su centriniais resursais kaip sisteminių kreipinių lentelė ar IDT. Tai labai komplikuoja jo aptikimą.
Rootkit yra labai paprastai instaliuojamas ir patogiai valdomas.
Adore-NG paieška
Aide. Rootkit nesukūrė jokių direktorijų, taigi paieška naudojant aide nedavė jokių rezultatų

Rkhunter. Rkhunter dokumentacijoje neužsimenama, apie šio rootkit aptikimą, taigi jis ir nėra aptinkamas.

Chkrootkit. Chkrootkit dokumentacijoje taip pat neužsimenama, apie šio rootkit aptikimą. Rootkit nėra aptinkamas, tiesa, LKM tikrinimo procesas trunka šiek tiek ilgiau nei įprasta, tokiu atveju pailgėja ir bendras tikrinimo laikas:

Švarioje sistemoje:

Užkrėstoje sistemoje: debian:/home/aurimas/chkrootkit-0.45# time ./chkrootkit -q
real 0m2.002s

debian:/home/aurimas/chkrootkit-0.45# time ./chkrootkit -q
real 0m3.475s

Patchfinder. Patchfinder programa, tikrindama sistemą užkrėstą Adore-NG rootkit, lūžta įpusėjus tikrinimui. Tai leidžia spėti apie Adore-NG rootkit buvimą sistemoje.

Rankinė paieška. Rankinė paieška su GDB įrankiu nedavė jokių teigiamų rezultatų, - gautas sisteminės kreipinių lentelės vaizdas visiškai sutapo su prieš tai padarytu vaizdu sveikoje sistemoje. Taip pat nebuvo aptikta skirtumų ir tarp sisteminių kreipinių.

Branduolio struktūrų tikrintojai.

Kern_check. Kern_check, lygindamas branduolio atmintį su System.map failu rado neatitikimų bei pagal juos nustatė sistemoje esantį rootkit.
proc_root_dir.proc_iops->lookup: 0xe4c2e220 0xc01614e0
WARNING: Adore-ng detected !!!
WARNING: You have: proc_root_iops.lookup: 0xe4c2e220
WARNING: Correct : proc_root_lookup: 0xc01614e0

Samhain. Reikėtų paminėti iki šiol nemėgintą samhein programą. Ši programa atlieka integralumo tikrinimo funkcijas, kaip ir aide, tačiau taip pat gali tikrinti ir branduolį. Po adore-ng instaliavimo, ši IDS aptiko pakitimus branduolyje.
CRIT : [2005-04-13T19:29:05+0300] msg=Determine. Adore autoriaus sukurta rootkit paieškos programėlė, sėkmingai aptinka adore-ng rootkit, bei jei rootkit slepia procesus, parodo ir jų PID.

debian:/home/aurimas/determine# ./determine

deter-mine LKM rootkit detector. (C) 2004 Stealth

Trying to detect hidden processes ...
Process with PID 826 does not have a appropriate /proc entry. Hidden?
Process with PID 870 does not have a appropriate /proc entry. Hidden?
Process with PID 919 does not have a appropriate /proc entry. Hidden?
Done.
Scanning /dev/mem for signatures. This may take a while ...
Signature of 'Adore/Adore-ng LKM' detected!

Virginijus Data 2006-09-14 20:19

Išvados
Tai buvo pirmasis mano nagrinėtas rootkit, kurio neaptiko visus iki tol rootkit aptikusi programa chkrootkit, o patchfinder apie pakitimus sistemoje pranešė tik nulūždama. Puikiai rootkit aptiko Determine programa, įvardindama rootkit ir tuo pačiu parodydama ir paslėptų procesų ID. Kern_check taipogi aptiko ir įvardino rootkit.
Samhain IDS, remdamasi švarioje sistemoje susikurta duomenų baze taipogi aptiko pakitimų branduolyje.

2.4.6 Išvados

Aide yra bevertė priemonė ieškant rootkit jei nebuvo sudaryta švarios sistemos sisteminių failų atributų duomenų bazė. Taipogi aide neaptinka rootkit, kurie nepakeičia sisteminių failų.
Chkrootkit yra pelnytai populiariausia rootkit paieškos priemonė, kadangi išveda nemažai informacijos apie rastus nesklandumus sistemoje, tačiau neparodo paslėptų PID, bei nesugebėjo aptikti Adore-NG rootkit.
Rkhunter apie rootkit egzistavimą dažniausiai spendžia tik pagal rastas standartines direktorijas, o ne branduolio struktūras, bei remiasi švarios sistemos duomenimis ir yra bevertis, jei norime tikrinti galimai užkrėstą sistemą.
Pathfinder negali aptikti vartotojo lygio rootkit, be to remiasi švarioje sistemoje sudaryta duomenų baze.
Samhein atveju nepasakomas nei konkretus rootkit pavadinimas, nei paslėpti procesai ar direktorijos.
Kern_check reikalauja švaraus system.map failo, negali aptikti vartotojo lygio rootkit, neparodo paslėptų PID, nesugebėjo įvardinti rastų rootkit.
Determine silpnoji vieta yra tai, kad jei rootkit nėra Adore ar Adore-NG, bei rootkit neslepia procesų, jis aptiktas nebus.

Matome, kad nėra vienintelės priemonės sugebančios aptikti visus nagrinėtus rootkit. Be to kai kurių rootkit aptikimo priemonių parodymai apie sistemoje esantį rootkit yra labai abstraktūs.