5 tipů, jak se bránit rootkitům

Na TechRepublic je k dispozici 5 tipů, jak čelit rootkitům. Jsou to: 1) ochrana strojů, 2) sledování indicií, 3) vypnutí zasaženého stroje, 4) nikdy bez Tripwire, 5) dump paměti.

1.9.2010 13:05 | vencour | Zajímavý článek

Komentáře

[balic:-)]

1) instalovat vse z overenych zdroju - repositaru distributora + nekolik malo externich overenych repositaru

[tsLnox]

6) Nepřipojovat se k netu Zaručeně ochrání

[stativ]

7) Nepřipojovat do sítě.

[pc2005]

elektrické

[Bedňa]

Nezabudni s notebooku vybrať baterku

[K]

Urezat ruky a nohy, nebo rovnou radeji PREVENTIVNE spachat sebevrazdu

[mikirc]

porad slozite, nekupovat PC vubec :D

[JJ]

Kupovat ARM :)

[Jendа]

Na Linuxu na ARM rootkity nefungují?

[Bedňa]

Keď ho nezapneš

[Grunt]

Na TouchBooku (z.B.) toho spousta nefunguje, takže by nefunkčnost rootkitů ani nebyla takovým překvapením.

[Mrkva]

Co třeba nefunguje? :)

[Grunt]

Tak dlouho se hrabe v Touchbooku, až se kabel utrhne...

[Mrkva]

No co, přerval jsem kabel k touchscreenu. Ale tak 4 dráty není problém zapájet.

[Kvakor]

Na Linuxu na ARM rootkity nefungují?

Ty dělané čistě pro x86 sice nebudou fungovat, ale ty zbylé ano - díry typu race condition, slabá hesla, nesprávně nastavená práva k souborů a podobně na architektuře nezávisí. A jak útočník získá roota, tak si stejně nainstalue rootkit přeložený na míru pro dannou architekturu a verzi jádra.

[Grunt]

Jednou jsem viděl takovou mrchu (kdosi na linux@conf.netlab.cz byl tak laskav a pochlubil se – jen je mi líto, že jsem si ji nezazálohoval), která si sebou táhla nějaké zdrojáky a gcc. Fakt drsoňské.

[Jendа]

To samozřejmě vím, byla to ironická otázka.

[stativ]

Spíš než Tripwire doporučuji aide. Nastawit tripwire je černá magie a přitom se mi nezdá, že by toho uměl víc, než aide.

[omg]

a umite to aide a tripwire spravne pouzit, aby vysledek prokazatelne overil, ze neni pritomna zadna nezadouci uprava?

[stativ]

Abych se přiznal já aide nepoužívám kvůli bezpečnosti, ale protože prostě nevěřím novým diskům a chtěl bych včas vědět, kdy se něco pokazilo. Jinak nevidím sebemenší problém v použití. Prostě ve vždycky po updatu aktualizuju databázi a hlídám, kdy jsou tam změny, se kterými nemám nic společného.

[m;)]

cas na zfs ?

[Mrkva]

Když ten rootkit bude šikovný, tak vám ani tripwire ani aide nepomůže.

[Kvakor]

Ano, pokud je rootkit opravdu dobře udělaný, tak se bude maskovat tak, že ho nic nenajde (snad až na přímé debugování běžícího jádra a prohlížení disků jako zařízení). Naštestí v Linuxu stačí nabootovat z ověřeného LiveCD (např. toho insdtalačního) a zkontrolovat to z něj.

Aklternativní rešení pro ty, kteří si překládají vlastní jádro, je mít verzi jádra bez modulů* separátně drženou na nějakém bootovatelném médiu, pokud možno ještě se statickou verzí nějakého shellu, nejlépe asi BusyBoxu. Osobně na to mám starou 64MB CF kartu a CD/IDE redukci, ale optimální by asi byl USB flashdisk s mechanickou ochranou proti zápisu.

S takovým médiem je pak možné nabootovat více méně normálně, ale s jistotou, že jakýkoliv běžící škodlivý kód bude viditelný (minimálně v /proc, protože jak ps, tak top mohou být podvržené) a pozměněné soubory budou viditelné a rozpoznatelné. Napadnutí běžícího statického jádra, obzlášť se zapnutým filtrováním přístupu k /dev/mem, je totiž tak komplikované, že pokud útočník nemá oravdu eminentní zájem o váš stroj, nejspíš se na takovouto alternativu nepřipravil.

*Jsou sice části jádra, které musí být přeloženy jako moduly, aby dobře fungovaly (hlavně rozličné multimédiální ovladače), ale to základní jako ovladače k disku a souborovému systému mezi ně naštěstí nepatří. Nefunkčnost zvukové karty nebo TV tuneru nebývá prioritou v okamžiku, když zjišťujete, jestli a jak moc byl váš systém poskvrněn ...

[Grunt]

minimálně v /proc, protože jak ps, tak top mohou být podvržené

Počkat, to jsem nějak nepobral. Neříká se tomu čirou náhodou rootkit, protože to běží v prostoru jádra, bootladeru nebo něčeho takového nadřazeného. IMHO pokud to běží v user-space, tak jde o klasický virus, červa nebo podobné svinstvo. No ne?

[Kvakor]

Jasně že ano, ale když už si někdo dá práci a upraví jádro tak, že určité procesy (např. s jistým UID) nebyly vidět, tak proč pro jistotu neupravit i programy, co procesy zobrazují, obzvlášť když takovéto podvržené verze základních programů jsou běžně dostupné. I za běžných okolností se může stát, že uživatel nabootuje s jiným jádrem, takže útočník by byl hlupák, kdyby se nepojistil.

[Mrkva]

snad až na přímé debugování běžícího jádra a prohlížení disků jako zařízení

A to by nešlo podvrhnout proč?

Naštestí v Linuxu stačí nabootovat z ověřeného LiveCD (např. toho insdtalačního) a zkontrolovat to z něj.

Jo, to jo - pokud není nabořené už to instalační CD.

Napadnutí běžícího statického jádra, obzlášť se zapnutým filtrováním přístupu k /dev/mem, je totiž tak komplikované, že pokud útočník nemá oravdu eminentní zájem o váš stroj, nejspíš se na takovouto alternativu nepřipravil.

No, Grsecurity patche dokážou zachránit den, to jo. Ale stejně je lepší se na to nespoléhat.

[Kvakor]

snad až na přímé debugování běžícího jádra a prohlížení disků jako zařízení

A to by nešlo podvrhnout proč?

No, nejspíš by šlo upravit jádro tak, aby vracelo nevinně vypadající data i při přímém prohlížení paměti a přímém čtení diskového zařízení, například pomocí virtualizace celého stroje, ale něco takového by bylo nejen extrémně komplikované a i s hardwarovou podporou virtualizace by se to projeviovalo zpomalením systému.

BTW: Maskovat se na disku uměly už staré dobré DOSovské stealth viry

Naštestí v Linuxu stačí nabootovat z ověřeného LiveCD (např. toho insdtalačního) a zkontrolovat to z něj.

Jo, to jo - pokud není nabořené už to instalační CD.

Instalační CD většinou mají kontrolu integrity jedtoltivých balíčků. Je tu i možnost zkontolvat kontrolní součet ceklého média, ale na to je třeba nezkompromitovaný stroj a navíc i fingerprint na webu distribuce může být podvržený MitM útokem. Takže je třeba mít stroj, který je zaručeně čistý, např. notebook se systémem obnoveným z Recovery CD, napíchnout se do náhodně vybrané volně dostupné WiFi sítě, stáhnou nějaké minimalistické Live CD a zkontrolovat fingerprint odtamtud. Pokud se to celé zopakuje vícekrát, s různými notebooky, sítěmi a verzemi Live CD, tak je vysoce pravděpodobné, že instalační médium je nepodvržené. Což bohužel neznamená, že na něm není žádný škodlivý kód ...

Napadnutí běžícího statického jádra, obzlášť se zapnutým filtrováním přístupu k /dev/mem, je totiž tak komplikované, že pokud útočník nemá oravdu eminentní zájem o váš stroj, nejspíš se na takovouto alternativu nepřipravil.

No, Grsecurity patche dokážou zachránit den, to jo. Ale stejně je lepší se na to nespoléhat.

Filtrováním přístupu k /dev/mem je naštěstí už i v normálních jádrech, mám pocit že od 2.6.35. Defaultně povoluje přístup jen k PCI konfiguračnímu prostoru a nammapovaným IOMEM oblastem, což všem běžným na hardware sahajícím programům typu Xserver musí stačit.

[Mrkva]

No, nejspíš by šlo upravit jádro tak, aby vracelo nevinně vypadající data i při přímém prohlížení paměti a přímém čtení diskového zařízení, například pomocí virtualizace celého stroje...

if(hddBlockPrefix=="TADYJEROOTKIT") 
 return fakeHddBlock;
else
 return hddBlock;

Ok, tohle je jak to rčení s Hurvínkem a válkou. Ale určitě není nutné kvůli tomu virtualizovat celý stroj. Se zbytkem se dá souhlasit.

[dustin]

Jak se takový proces schová před tripwirem nebo aidem, pokud již byly na kompu nainstalované a jejich db má dostatečně silnou passphrase? Nevím, zajímá mě to, myslel jsem, že tyto softy by to měly řešit. Snad pokud si upraví jejich binárku, aby vypisovala úplně něco jiného, atd... Díky moc.

[stativ]

Proto se u aide a nejspíš i tripwire doporučuje statická kompilace, šoupnout to na read-only médium a při kontrole používat to. Použití read-only média se doporučuje i pro samotnou databázi.

[Mrkva]

Pokud ten rootkit běží v kernelspace, tak žádný tripwire, aide nebo cokoliv podobného nemá moc šancí.

[K]

Nemáš prosimtě nějaký link na info ohledně jak jsi psal "přímé debugování běžícího jádra" ? Vím jak pustit gdb a jeho syntax a tak, moc bych ale uvítal nějaké typy co a jak a kde hledat u 2.6.. Nemáte někdo pls nějaké takové info? Například jak čeknout, že syscally nejsou hooknuté a podobně.

[K]

Omlouvám se za ty pravopisné chibi .-)

[Grunt]

Zde manuál kde je vysvětleno několik způsobů jak se na takové jádro připojit. Jde o klasickou GDB Remote session (s některými malými omezeními…kupř. mám takový pocit, že mi tam nefungoval backtrace) známou z gdbserveru, jen se nedebuguje běžící proces v user-spacu, ale jádro samotné. Jako symboly se tomu předhazuje náležící vmlinux obraz (je to klasický ELF). Prostě žádná věda. Implementace samotná v jádře též není žádná věda, ale je to jen pár modůlu a pár funckí co se dají přečíst za jeden zimní večer (nějaká interní signalizace, popis protokolu,…prostě nic moc zajímavého). Viz. Internals.

[K]

Ok ok, díky, to vypadá pěkně. Takže už umíme gdb "připojit" k běžícímu kernelu. A teď by to ještě chtělo nějaké tipy co hledat, na co se zaměřit. Vylistovat seznam syscallů a jejich adresy, zjistit jestli nejsou hooknuté, nějaké tipy jak najít seznam naloadovaných modulů a hledat podezřelé informace a podobné věci, které bych viděl v nějakém hezkém uceleném návodu.. Nenajde se nějaký takový white-hatovský checklist návod?

[Grunt]

Počkat…a k čemu že to má vůbec sloužit?

[K]

Něco jako DIY verify your kernel with gdb

[Jakub Lucký]

Já teda používám chkrootkit a rkhunter a připadám si klasicky paranoidně... na botnet to stačí a jestli mě sleduje CIA, tak už tam stejně jsou...