Rootkity a skrývání souborů

V nedávném článku jsme si vysvětlili základní pojmy ohledně rootkitů, jejich chování a jak lze z obecného hlediska rozdělit techniky, které k dosažení svých cílů používají. Dnes se zaměříme na způsoby, kterými rootkit může skrývat soubory a složky na pevném disku.

Skrývání souborů nepatří mezi časté praktiky rootkitů. Důvodem je asi značná obtížnost tohoto úkolu. Efektivně skrýt soubor je o řád těžší než jej ochránit před "nepovolaným" přístupem - například proti čtení, zápisu či smazání. Ať se autor rootkitu rozhodne pro jednu či druhou variantu (nebo případně pro obě), implementace může mít podobné rysy. Například místo útoků může být společné.

Místa, na která zaútočí

Výběr místa útoku je velmi důležitý, protože má velký vliv jak na složitost implementace rootkitu, tak i na jeho efektivnost a obtížnost jeho detekce. Útok na "vyšší" vrstvy (dále od ovladačů hardwaru) znamená jednodušší implementaci, a tedy menší riziko nestability (pravý rootkit se musí nejen umět skrývat, ale také být dostatečně stabilní, aby jeho přítomnost nebyla prozrazena neočekávanými pády operačního systému). Obtížnost detekce však není nijak závratná a efektivita také ne, protože z vyšších vrstev se velmi špatně ovlivňují vrstvy nižší.

Na diagramu vidíme některá z míst vhodných k útoku. Tento diagram rozhodně nepokrývá všechny možnosti, ani si neklade za cíl přesně odrážet strukturu ovladačů v jádře operačního systému. Poslouží nám jako pomůcka k dalšímu výkladu, ve kterém se podrobněji zaměříme na jednotlivé oblasti.

Rozbor případů

Prvním místem, na které může padnout oko programátora rootkitu, je samotná aplikace, před kterou chce soubory skrýt. Toto místo autoři rootkitů ke skrývání souborů prakticky nevyužívají, protože efektivita se blíží nule a implementace může být náročná, protože vyžaduje porozumění fungování cílovému programu. Většinou se takto implementují techniky na "obranu" proti antivirovým programům, firewallům, antirootkitům a jiným utilitám. Pokud rootkit (či obecněji škodlivý kód) zjistí přítomnost bezečnostního softwaru, který by mohl znamenat riziko odhalení, může se jej pokusit deaktivovat. Sem patří i technika někdy známá pod souslovím útok na uživatelské rozhraní (GUI attack), jejíž cílem je zabránit funkčnosti bezpečnostních utilit zásahem do jejich uživatelského rozhraní.

Snad všechny souborové funkce jsou implementovány v dynamické knihovně kernel32.dll. Modifikace kódu této knihovny za účelem skrývání souborů je vcelku triviální a proti běžnýnm aplikacím (a některým antivirům) efektivní. Protože však není nijak modifikováno jádro, detekovat soubor takto skrytý je velmi snadné a dokáže to snad každý antirootkit, který disponuje příslušnými funkcemi. Problém také tkví v tom, že je neutné modifikovat knihovnu v každém procesu. Ano, paměť obsahující kernel32.dll může být sdílená mezi procesy, ale pravděpodobně mechanismem copy-on-write. Tím se záležitost komplikuje, protože je nutné sledovat vytváření nových procesů.

Odstavec o kernel32.dll lze aplikovat i na ntdll.dll. Rozhraní této knihovny je však mnohem méně přátelské, než je tomu u kernel32.dll a navíc i málo dokumentované. Prostoru pro skrytí modifikace kódu do hloubky nějaké složité funkce také příliš není, protože mnoho rutin obsahue jen tolik instrukcí, že byste je spočítali na prstech jedné ruky. Z toho vyplývá trošku vyšší obtížnost implementace, lehce vyšší efektivita a možná trošku nižší obtížnost detekce modifikací. Navíc si musíme uvědomit, že bezpečnostní aplikace jako antirootkity (ale mohou tak fungovat i úplně obyčejné programy při troše snahy) mohou volat přímo jádro systému a žádnou ze jmenovaných knihoven nepoužívat.

Modifikovat hlavní modul jádra (budu jej nazývat ntoskrnl, ač jméno souboru odpovídat nemusí - záleží na podpoře PAE a počtu procesorů) s sebou přináší vyšší "programátorskou" složitost (je nutné znát základy psaní ovladačů), ale i větší efektivitu. Každý proces má pro sebe svůj vlastní adresový prostor, ve kterém si může žít a dělat, co se mu zlíbí. Jádro operačního systému je namapováno do každého procesu, ale nejedná se o sdílení copy-on-write - modifikace jádra se projeví ve všech procesech. Modifikace ntoskrnl se celkem snadno detekují (záleží však na důvtipnosti a píli autora rootkitu) a antirootkitový program nemusí souborových funkcí tohoto modulu vůbec využívat.

Ovladač souborového systému je poslední vrstva, na které lze hovořit o práci se soubory a adresáři. Jedná se o nejnižší vrstvu tohoto druhu, a proto je mezi pokročilejšími rootkity oblíbená. Implementovat takový rootkit není o mnoho složitější než modifikovat hlavní modul jádra. Drobný problém může spočívat ve faktu, že každý typ souborového systému používá jiný ovladač. Opět se musí dát pozor na to, že antirootkit se může nejen zaměřovat na odhalování skrytých souborů, ale i na hledání modifikací ovladačů jádra - takže pokud rootkit modifikuje kód, je dobré pro rootkit, aby tyto modifikace neukazovaly na toho, kdo je provedl. Adresářovou položku skrytou rootkitem tohoto druhu, lze odhalit využitím služeb z nižších vrstev jádra, například ovladače disku. Tento princip platí obecně - kdo se dostane na nižší úroveň, vyhrává.

Jen velmi málo autorů rootkitů se odhodlá zaútočit na nižších úrovních, než jsou ovladače souborového systému. Obecný ovladač disku (disk.sys) totiž neví, co je to soubor či adresář. Jeho úkolem je zrpostředkovat komunikaci mezi diskem a ovladači souborového systému - a to nezávisle na hardwaru diskového média. Rozeznává pouze bloky, umí zrpostředkovat jejich čení a zápis. Pokud se autor rootkitu rozhodne skrýt soubor tím, že modifikuje obecný ovladač disku, musí překonat řadu překážek. Jednou z největších je nutnost porozumět souborovému systému "až na plech". Implementace musí býti odlišná pro souborové systémy FAT a NTFS. Vezmeme-li v úvahu, že NTFS je obchodním tajemstvím a jeho dokumentace není veřejně přístupná, stává se problém ještě složitějším. Dalším problémem mohou být vyrovnávací paměti (cache) implementované v ovladačích souborového systému. Odměnou po splnění takto náročného úkolu je, že takto skrytý soubor může být velmi obtížné odhalit. Ale jeho skrytí opravdu není jednoduché, což pochopíte, pokud si najdete podrobnější informace o implementaci nějakého souborového systému, který nepatří do rodiny FAT a není moc zastaralý.

Rootkit může jít ještě níž. Obtížnost prudce vzrůstá. Nyní již záleží i na tom, jaké povahy disk je. Jedná-li se o USB flashku, SATA či ATA disk. Zařízení různých druhů jsou obsluhována různými ovladači (atapi.sys, usbstor.sys, iaStor.sys...). Pro antirootkit už může být extrémně těžké odhalit modifikace disku skrývané na této úrovni.

Je možné jít ještě hlouběji? Myslím si, že ano. Musíme však brát v potaz jeden fakt - programování je také o penězích. Napsat rootkit pracující téměř na úrovni hardwaru je velmi obtížný úkol, který vyžaduje mnoho času a studia. A není mnoho lidí s dostatečnými předpoklady a znalostmi, kteří by měli dost chuti se takovému úkolu věnovat ve svém volném čase. Tím netvrdím, že možnost vzniku takového rootkitu je nemožná. Jen tvrdím, že takových rootkitů bude extrémně málo, o to však mohou být nebezpečnější.

Tímto náš výlet po různých vhodných místech útoku končí. Podívejme se nyní na několik příkladů rootkitů, které soubory skrývají.

Několik příkladů a jak se skrývání souborů vyhnout

Typickým zástupcem rootkitů útočících na knihovnu kernel32.dll je Vanquish. Jedná se již o velmi starý prográmek, jenž skrýval soubory (a procesy) s názvem začínajícím na řetězec "vanquish". Rootkit do každého běžícícho procesu načítal knihovnu vanquish.dll, jejímž úkolem bylo modifikovat kernel32.dll.

Nelze se nezmínit o známém SONY rootkitu, jenž byl instalován do počítačů uživatelů bez jejich vědomí a skrýval soubory a složky (nutno říci, že ne příliš dobře) začínající určitým řetězcem. Rootkit byl prý lehce nestabilní.

Některé rootkity se rozhodly jít trochu jinou cestou. Hlavní myšlenka spočívala v tom, že skrýt soubor je obtížné. Díky souborovému systému NTFS to však ani není nutné. NTFS umožňuje ke každému souboru přiřadit více datových proudů - jeden bezejmenný (s ním se pracuje standardními funkcemi) a další pojmenované (pro jejich otevření je třeba za název souboru doplnit dvojtečku ":" a název datového proudu). Stačí tedy data rootkitu či škodlivého kódu uložit do pojmenovaného datového atributu a půl práce je hotovo. Není mnoho aplikací, které zobrazují alternativní datové proudy. Touto cestou se rozhodli jít autoři Rustocka B a experimentálního rootkitu Unreal A, jenž v době svého vzniku nebyl odhalen žádným tehdy známým a veřejně dostupným antirootkitem (včetně antirootkitu jeho autorů).

Rootkit Rustock C šel úplně jinou cestou. Žádné nové soubory na disku nevytvářel, ale modifikoval již existující - zaměřoval se zejména na základní systémové ovladače. Modifikace souborů se Rustock snažil důmyslně, leč s pár chybami, zakrýt, což se mu proti většině antirootkitů úspěšně dařilo. Více informací o tomto malware můžete najít také v tomto článku.

Někteří autoři rootkitů nahlédli problém ještě z jiného úhlu. Na disku je velká spousta souborů a většina uživatelů PC nepatří do skupiny lidí, jenž by každé ráno po snídani kontrolovala svůj oblíbený operační systém na přítomnost rootkitů. Jeden či dva soubory navíc se jednoduše ztratí. Zde samozřejmě nastává problém s antiviry, pokud je rootkit zaveden v databázích signatur, či má to štěstí, že jej odhalí heuristika. Tady nepomáhá ani ochrana souborů proti čtení či zápisu (ikdyž je pravda, že pokud antivirus nemůže přečíst nějaký soubor, většinou nevyhodí výstražnou hlášku). Klasické viry soubory vytvářet nemusí a mohou infikovat již existující. Úprava souboru má samozřejmě vliv na jeho velikost i na jeho otisk (ať MD5 či SHA1), který si však nikdo stejně nekontroluje. U některých systémových souborů je však jejich integrita kontrolována mechanismem SFC.

Závěr

Doufám, že vám článek pomohl nahlédnout do toho, jakým způsobem může škodlivý kód skrývat jeden z důkazů o své existenci ve vašem počítači - soubory a složky. Situace může vypadat nerůžově, ale zas tak špatné to zas není. Dnešní antirootkity jako RootRepeal či Rootkit Unhooker mají podle mého názoru detekci skrytých souborů na slušné úrovni. A to je také jedna z metod obrany proti této havěti - kontrolujte si pravidelně systém a buďte trošku paranoidní. Přítomnost rootkitu lze zjistit mnoha způsoby, často velice nepřímo. Další silnou zbraní ve vašich rukou je off-line analýza systému, která téměř všechny zde popsané způsoby skrývání souborů obrací v prach a popel.

Cílem článku nebylo poděsit čtenáře, ale podat jim informace o tom, co se děje uvnitř. Neinformovanost vede k manipulaci a manipulace k záhubě.