Rootkity na platformě x64

64bitové verze Windows Vista a Windows 7 se objevují stále častěji. Tento trend je logickým důsledkem většího množství paměti RAM na nových (i stávajících) počítačích. 32bitové verze Windows nemohou plnohodnotně využít většího množství fyzické paměti než 4 GB. Takové omezení u platformy x64 neplatí.

Vzhledem k tomuto trendu se dalo očekávat, že autoři malware se vydají podobným směrem – začnou psát škodlivý kód určený přímo pro 64bitová Windows. V tomto článku se však zaměříme na to, jak se na platformu x64 přesouvají tvůrci rootkitů, tedy programů, které se snaží zamaskovat svoji přítomnost v systému.

Nové překážky

64bitové verze Windows přináší oproti verzím 32bitovým několik překážek, které musí autoři malware operujícího v jádře systému překonat. Nebudu se o nich příliš dlouze rozepisovat, protože se jedná o velmi staré a stále dokola omílané téma.

První překážkou při vstupu do kernelu je nutnost používat pouze ovladače digitálně podepsané některou z malého množství certifikačních autorit. Ostatní ovladače se ve výchozím nastavení systému do jádra nedostanou. Existuje několik způsobů, jak toto bezpečnostní opatření obejít, obvykle ale vyžadují restart počítače, což však v případě domácích uživatelů nepředstavuje pro malware příliš velký problém.

Druhou překážku tvoří PatchGuard - modul, který kontroluje, zda se škodlivý kód nesnaží narušit správný chod jádra pomocí modifikací jeho kódu a důležitých datových struktur. Tato překážka tedy představuje problém až ve chvíli, kdy se škodlivý kód dostane do prostoru jádra. Podle mého názoru však v dnešní době PatchGuard pro malware tak velký problém nepředstavuje. Ne že by bylo tak snadné jej vypnout, ale není příliš obtížné se mu vyhnout – tím myslím neporušovat pravidla, na jejichž dodržování dohlíží.

Jak tyto překážky obejít

Překonat obě výše jmenované překážky je sice možné, ale škodlivý kód k tomu potřebuje administrátorské oprávnění. Z tohoto pohledu lze jako další překážku uvést i Kontrolu uživatelských účtů (User Account Control – UAC). V tomto textu ale předpokládáme, že se škodlivému programu tuto ochranu překonat podařilo a disponuje již dostatečnými právy.

Digitální podpis

Ve výchozím nastavení pouštějí 64bitové verze Windows Vista a Windows 7 do jádra pouze ovladače podepsané některou z důvěryhodných certifikačních autorit. Toto nastavení lze však ovlivnit, například utilitou bcdedit. Pro použití tohoto prográmku potřebujete administrátorská práva.

Jedna možnost zeslabení „podpisového“ bezpečnostního opatření spočívá v příkazu

bcdedit /set TESTSIGNING on

Tím se systém přepne do stavu, kdy dovoluje vstoupit do jádra i ovladačům podepsanými vlastními certifikáty. Tato volba usnadňuje vývojářům testování jejich produktů. Pokud ale malware získá dostatečná oprávnění, může pomocí programu bcdedit toto nastavení zapnout, nainstalovat vlastní certifikát do sekce Důvěryhodné kořenové certifikační autority (Trusted Root Certificate Authorities) a následně načítat ovladače do jádra dle libosti. Po přepnutí do režimu TESTSIGNING je nutné restartovat počítač. Do té doby nemá příkaz žádný efekt.

PatchGuard

Pro malware nejjednodušší cesta (ale také cesta snadno detekovatelná) vypnutí technologie PatchGuard spočívá v přepnutí systému do režimu ladění. Režim ladění (Debug Mode) je speciální režim, který mohou vývojáři používat pro ladění svých ovladačů, případně i ladění celého jádra operačního systému. Operační systém v tomto režimu sice nedovoluje načítat do jádra nepodepsané ovladače, ale vypíná technologii PatchGuard, takže lze modifikovat kód a datové struktury jádra dle libosti. Režim ladění lze zapnout opět pomocí utility bcdedit a aby se změna projevila, je nutné počítač restartovat. Příkaz vypadá následovně:

bcdedit /set DEBUG on

Existují však i jiné způsoby. Na serveru CodeProject před několika lety vyšel článek o tom, jak tuto ochranu pomocí modifikací kódu jádra úplně vyřadit z činnosti. Tento postup však podle mého názoru může vést k zvýšené nestabilitě systému. Myslím si, že ideální je obejít se bez modifikací kódu a struktur jádra úplně. Navíc, legitimní programy by neměly za žádných okolností porušovat pravidla, která PatchGuard hlídá.

Na serveru Uninformed je také možné nalézt článek, který analyzuje, co přesně tato ochrana dělá. Je sice velmi starý, ale pokud byste se jej drželi při procházení dnešních kernelů Windows, určitě by vám mnohé usnadnil. Klíčové je totiž zjistit, které věci PatchGuard hlídá a které ne.

Podle mého názoru je nejlepším řešením používat dokumentovaná rozhraní, která Microsoft zavedl právě z toho důvodu, aby programátoři ovladačů „nehackovali“ PatchGuard. A pokud už musíte nějakou modifikaci jádra provést, je nutné ověřit, že PatchGuard ji nebude považovat za porušení pravidel a nezpůsobí modrou obrazovku smrti.

Nová rozhraní dovolují například:

• kontrolovat operace nad souborovým systémem (filtry souborového systému),
• kontrolovat operace nad registrem (Registry Callbacks),
• monitorovat a měnit síťovou komunikaci (Windows Filtering Platform),
• monitorovat (a omezovat) přístup k procesům a vláknům (OB filtering model),
• monitorovat (a blokovat) vznik nových procesů, vláken a načítání ovldačů a knihoven DLL do paměti

Myslím si, že schopnosti těchto rozhraní jsou pro rootkity celkem dostatečné. Navíc pro 64bitové platformy zatím neexistují žádné pořádné nástroje, které by dokázaly přítomnost pokročilejšího rootkitu odhalit. Není tedy nutné nasazovat tak složité techniky skrývání přítomnosti.

Rootkity a „rootkity“

Nyní tedy víte, jak malware může jednotlivé překážky na 64bitových verzích Windows obcházet. Zůstává tedy vyřešit následující otázku: „Kdo se o to již pokusil?“

TDL4

Pokud si dobře vzpomínám, TDL4 je zatím nejpokročilejším rootkitem fungujícím na 64bitových systémech. Jelikož žádným zakázaným způsobem nemodifikuje kód ani datové struktury jádra, nemusí řešit žádné problémy s technologií PatchGuard. Jediným problémem zůstává kontrola digitálních podpisů během bootování operačního systému.

TDL4 pracuje jako Sinoval či jiné škodlivé kódy přežívající restart počítače tím, že infikují hlavní zaváděcí sektor (Master Boot Record – MBR) pevného disku, ze kterého systém startuje. Stejně jako ony, i tento rootkit modifikuje obsluhu přerušení 13h tak, aby věděl o každém sektoru načteném během prvních fází bootování do disku do paměti. Na tomto vektor přerušení vede na služby BIOSu určené pro práci s pevnými disky.

Modifikace obsluhy přerušení 13h rootkitu umožní zjistit, kdy se do paměti načítá knihovna kdcom.dll, která implementuje část rozhraní pro podporu debuggeru jádra. Rootkit tuto knihovnu během načítání modifikuje, aby vykonala také kód potřebný pro jeho vlastní inicializaci. Tím je ale porušena její integrita, což zavaděč později kontroluje. Této kontrole ale rootkit musí, chce-li se vyhnout odhalení, zabránit, čehož dociluje opět využitím modifikované obsluhy přerušení 13h.

Modifikovaná obslužná rutina dále čeká, až se zavaděč Windows pokusí načíst obsah BCD (Boot Configuration Database), což je datová struktura, která obsahuje spoustu nastavení ohledně dalšího procesu bootování. Obsah této struktury upraví tak, že si program winload.exe, který v této fázi zavádí další části operačního systému, bude myslet, že se jedná o start prostředí WinPE, WinPE je velmi osekané prostředí Windows, které používají například instalační média Windows Vista a Windows 7. Důležité je, že v takovém případě winload.exe neprovádí žádnou kontrolu digitálních podpisů zaváděných ovladačů a součástí jádra.

winload.exe dává zbytku zaváděného operačního systému na vědomí, že se startuje prostředí WinPE, pomocí parametru /MININT, který předá hlavnímu modulu jádra. Upravená obslužná rutina přerušení 13h vidí i tento krok – jakmile zjistí, že se zavaděč snaží z disku načíst něco s řetězcem /MININT, modifikuje tento řetězec na nesmyslnou hodnotu. Ostatní části operačního systému se tedy nedozví, že se startuje WinPE a budou pracovat zcela běžným způsobem. Jediný efekt takového „skotačení“ tedy spočívá v tom, že rootkit TDL4 unikne kontrole integrity zaváděných ovladačů. Tím je poslední překážka překonána.

Rootkit dále pomocí dokumentovaných metod skrývá pravý obsah hlavního zaváděcího sektoru. Ostatní informace potřebné pro svůj běh ukládá do vlastního virtuálního souborového systému uloženého na sektorech na konci disku.

Vidíme, že rootkit TDL4 jednu z překážek (digitální podpis) obchází velmi zajímavým a nedokumentovaným způsobem. Druhou z nich – PatchGuard, obcházet nepotřebuje, protože neprovádí žádné zakázané modifikace kódu a datových struktur jádra.

Banker rootkit

Nedávno se na některých serverech objevila zpráva o malware označovaném jako Banker rootkit. Podle mých zjištění však o žádný rootkit nejde. Tento přídomek mu byl pravděpodobně přiřazen proto, že do jádra načítá vlastní ovladač – dokonce i na 64bitové platformě. Tento ovladač však neprovádí žádné „skrývací“ manévry, pouze se snaží oslabit funkčnost známých antivirových programů a zapisuje několik záznamů do souboru hosts, čímž dociluje přesměrování některých webových stránek.

Skladba samotného „rootkitu“ je poněkud netradiční. Nejedná se totiž o program, ale o jeden soubor .reg, jeden soubor .bat, originální utilitu bcdedit, certifikát a dva soubory ovladače (pro 32bitovou a 64bitovou verzi operačního systému). Autor zřejmě předpokládá, že oběť spustí (ať již přímo či třeba následkem nějakého útoku zvenčí) soubor .reg, čímž zajistí instalaci certifikátu a spuštění dávkového souboru (.bat) po restartování počítače. Předpokládá se, že všechny komponenty malware se nacházejí v adresáři %tmp%.

Dávkový soubor nejprve pomocí utility bcdedit zapne režim TESTSINGING, čímž umožní načtení ovladačů podepsaných certifikátem nainstalovaným souborem .reg do jádra. Následně vypne kontrolu integrity (digitálních podpisů) při bootování.

Dávkový soubor dále nainstaluje služby pro oba ovladače. Nijak netestuje verzi operačního systému, předpokládá, že 64bitová Windows přijmou pouze 32bitový ovladač a naopak. Soubory obou ovladačů jsou překopírovány do složky %windir%\system32\drivers. Obě služby jsou nastaveny tak, že budou spuštěny během bootování operačního systému. Z tohoto malware vypíná kontrolu integrity (digitálních podpisů) během startu operačního systému.

K průniku do jádra tedy nedochází žádným nedokumentovaným způsobem. Ovladač „rootkitu“ ani neporušuje žádná pravidla hlídaná ochranou PatchGuard, tudíž s ní nemá žádné problémy. Zajímavé je, že malware nijak nevynucuje restarty počítače, které pro svoji instalaci potřebuje. Tím se samozřejmě stává méně viditelným.

MAX++

Jestliže se Banker „rootkit“ snaží navodit dojem, že na 64bitové platformě používá nějaké skrývací techniky, MAX++ (též známý jako ZeroAccess) se nesnaží ani o toto. Technologie rootkitu využívá pouze na 32bitové platformě, na 64bitových Windows se chová jako malware běžící čistě v uživatelském režimu. Nepotřebuje tedy obcházet nutnost digitálně podepsaných ovladačů ani technologii PatchGuard. Jedinou zajímavou věcí je využití klíče HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems k zajištění přežití restartu počítače.

Necrus rootkit

Tento rootkit se nachází jak v podobě ovladače pro Windows 32bit i 64bit v balíku společně s „rouge“ antivirovým programem pro Mac OS. Rootkit překonává kontrolu digitálního podpisu zapnutím módu TESTSIGNING. Nejedná se tedy o žádnou nedokumentovanou metodu. PatchGuard nijak neobchází, protože se chová zcela dle pravidel; pro ochranu škodlivých procesů používá OB filtering model, operace nad soubory monitoruje přes filtr souborového systému a na registry dává pozor prostřednictvím zpětně volaných funkcí k tomuto účelu určených (Registry Callbacks). Podle mého názoru se jedná o směr, kterým se budoucí rootkity na platformě x64 vydají.

Závěr

Existence malware TDL4 dokazuje, že vytvořit fungující rootkit pro 64bitová Windows není nemožné a že se lze vypořádat se všemi překážkami, které tato platforma vytváří. Dále lze pozorovat i trend přesunu dalších rootkitů (a malware obecně) na tuto platformu. Ten je ale velmi pomalý a musíme být opatrní, abychom nepovažovali za rootkit něco, co jím ve skutečnosti není. Velkým problémem se do budoucna může stát absence kvalitních nástrojů zaměřených na detekci rootkitů pro 64bitové verze Windows.

Dále je také patrné, že se rootkity nesnaží technologii PatchGuard obcházet nějakým zakázaným způsobem (například přepnutím do režimu ladění). Výhodnější se jeví používat dokumentovaná rozhraní (Registry Callbacks, OB filtering model, filtry souborového systému, Windows Filtering Platform...) a případně provádět modifikace kódu a datových struktur na místech, která nejsou hlídána. Kdyby existoval nějaký veřejně dostupný nástroj schopný procházet interní datové struktury těchto rozhraní na 64bitové verzi Windows, nebyl by problém tyto rootkity odhalit.

Pravdou ale zůstává fakt, že získat důvěryhodný certifikát pro podepsání ovladače je záležitost několika stovek dolarů ročně (například VeriSign nabízí certifikáty kolem $500 ročně), což z programů na detekci rootkitů zrovna freeware neudělá, zvláště v případě, že je píšou jednotlivci či malé skupinky. Samozřejmě je možné přejít do režimu testovacích certifikátů, pustit detektor rootkitů a opět tento režim vypnout. Stále se ale jedná o dočasné snížení zabezpečení.

Na druhou stranu si musíme přiznat, co aplikace zaměřené na detekci rootkitů doopravdy jsou. Obvykle prochází interní datové struktury operačního systému. Myslím si, že se většina těchto programů při tomto úkonu příliš nezabývá synchronizací. To znamená, že dané aplikaci může operační systém své datové struktury měnit „pod rukama,“ čímž dochází k chybě souběhu (race condition), která může mít fatální následky v podobě modré obrazovky smrti. Pravda je, že dodržovat použití různých zámků v závislosti na procházených datových strukturách a konkrétní verzi Windows není nic lehkého. Tímto jsem pouze chtěl říci, že programy na detekci rootkitů nemusí být z tohoto pohledu dobře napsané a mohou s sebou přinášet nestabilitu.

Pokud se však nepodaří rozvoji rootkitů na 64bitových platformách zabránit, nezbude nám nic jiného, než takové aplikace vytvořit a používat. I za cenu toho, že se „nečistý“ kód dostane na bezpečnější a "čistou" platformu.

Závěrem ještě dodám, že jsem jednotlivé zde popisované rootkity příliš nezkoumal vlastníma rukama, ale spíše vycházel z nashromážděných zpráv. Výjimku tvoří Banker „rootkit,“ na jehož ovladač jsem použil disassembler.

Užitečné odkazy