Sociálne siete

SecIT.sk na Facebooku SecIT.sk na Google+ SecIT.sk na Twitteri

Podporte nás


V prípade, že Vám obsah nášho portálu niekedy nejakým spôsobom pomohol, či bol pre Vás prínosom prosím podporte jeho chod ľubovoľnou čiastkou. Ďakujeme!

Štítky

Vyhľadávanie

You are here

Domov
Upozornenie: Obsah je licenčne chránený a bez písomných súhlasov autora článku a vlastníka webovej stránky nesmie byť v žiadnej forme ďalej kopírovaný a šírený v pôvodnom, či v akokoľvek upravenom stave.

PatchGuard a problémy, které působí

Účel komponenty Windows PatchGuard (nebo Windows Kernel Patch Protection) pravděpodobně mnoho z vás zná. PatchGuard má chránit jádro operačního systému před jakoukoli nežádoucí modifikací, která by mohla narušit bezpečnost systému. Ale jak už to tak bývá, bezpečnost nám hází klacky pod nohy a KPP není výjimkou. V tomto článku se na tyto problémy podíváme blíže a ukážeme si, jak se je Microsoft snaží řešit.

Základní fakta

PatchGuard se skládá ze sady rutin, které při určitých událostech kontrolují integritu kódu a datových struktur jádra. To znamená, že nežádoucí modifikace nemusí být detekována hned, ale až třeba po deseti minutách. PatchGuard považuji za velmi dobrý bezpečnostní prvek (stejně jko digitálně podepsané ovladače), ačkoliv nechrání stoprocentně. Na serveru CodeProject se již před nějakou dobou objevil článek popisující, jak tuto ochranu proti malwaru vypnout. Ikdyž byli autoři článku ve své snaze úspěšní, nepodařilo se jim kompletně zmapovat podmínky, za kterých PatchGuard spouští své kontrolní rutiny.

Mezi oblasti kontrolované PatchGuardem patří:

  • Interrupt Descriptor Table (IDT) - obsahuje adresy rutin obsluhujících přerušení procesoru. Modifikace IDT lze využít například k implementaci keyloggeru, packet snifferu či rootkitu skrývajícího obsah paměti (Shadow Walker).
  • Global Descriptor Table (GDT) - tvoří část bariéry mezi uživatelským režimem a režimem jádra. Úpravou GDT lze vytvořit tzv. callgate, "bránu", která umožňuje i běžným aplikacím získat stejné výhody, jakých se dostává ovladačům.
  • System Service Descriptor Table (SSDT) - obsahuje adresy podprogramů, které mohou být skrz mechanismus systémových volání spouštěny normálními aplikacemi. Modifikace SSDT je velmi oblíbená nejen u rootkitů, ale i u bezpečnostních programů (antiviry, firewally...). Úprava SSDT umožňuje získat téměř naprostou kontrolu nad tím, co (nejen) běžné programy dělají. Příklad takové (nežádoucí) modifikace naleznete v Lodusově článku Píšeme rootkity v r0.
  • Hlavní moduly jádra a ovladače pro práci se sítí (ntoskrnl.exe, hal.dll, ndis.sys...)
  • Některé datové struktury Object Manageru - Object Manager je součást jádra, jejíž úkolem je poskytnout svému okolí obecné rozhraní pro práci s objekty jádra jako jsou otevřené soubory, procesy a vlákna. Rootkit si může úpravou těchto struktur zajistit svoji ochranu. Jedná se zejména o objekty typu ObjectType a záznamy OBJECT_TYPE_INITIALIZER (více o samotném Object Manageru napíši v příštím článku).
  • A další...

Klacky pod nohama

Z jednotlivých odrážek je patrné, že PatchGuard chrání většinu klíčových struktur operačního systému. Z hlediska bezpečnosti Windows jako takových to považuji za velmi dobré řešení. Rootity, keyloggery a jiná havěť tyto struktury upravující se ocitá ve velkých nesnázích.

Pravda je ale taková, že bezpečnostní software často využívá podobných praktik jako malware. Například AntiVir od společnosti Avira modifikuje SSDT za účelem ochrany svých procesů a vláken. Firewally a systémy HIPS krom SSDT přepisují kód rutin jádra (inline hooking) a nabourávají se do síťových ovladačů. Program SandboxIE za účelem ochrany modifikuje struktury OBJECT_TYPE_INITIALIZER (technika známá jako Direct Kernel Object Hooking). Modifikace kódu jádra se též často používaly při implementaci monitorování aktivity běžných aplikací. A mohl bych pokračovat ještě docela dlouho.

Pravděpodobně již vidíte, jaké komplikace PatchGuard výrobcům bezpečnostních aplikací přináší. Drtivá většina osvědčených technik nefunguje. Výrobci si tyto problémy samozřejmě nenechali pro sebe, a tak Vista (ale hlavně první service pack) přináší mechanismy, které by měly firmám pomoci. Některé z nich si nyní popíšeme.

Ochrana a monitorování registru

Již od Windows XP mohou ovladače jádra dokumentovanou cestou monitorovat práci s registry a blokovat přístup ke klíčům a hodnotám. Slouží k tomu trojice rutin CmRegisterCallback, CmRegisterCallbackEx a CmUnRegisterCallback, jejichž prostřednictvím ovladač systému sdělí, že chce být informován o každém přístupu do registru. Přičemž systém informuje ovladač těsně před provedením dané operace a dává mu možnost operaci zablokovat. Ovladač je dále informován těsně po provedení dané operace a může změnit její výsledky ještě předtím, než budou doručeny kódu, který danou operaci vyvolal. Pod změnou výsledků si představte například vymazání záznamu ze seznamu podklíčů, o který požádal nedůvěryhodný program. Tuto úpravu výsledků podporuje až Windows Vista.

Ochrana procesů a vláken - OB filtering model

Jak jsme si řekli výše, struktury OBJECT_TYPE_INITIALIZER jsou chráněny proti nežádoucí změně, takže je není možné využít k ochraně důležitých objektů, například procesů a vláken. Vývojaři Microsoftu však definici těchto struktur rozšířili a vymysleli koncept, který ochranu procesů a vláken umožňuje. Mechanismus se jmenuje (podle některých zdrojů) OB filtering model a jeho použití je podobné jako při monitorování a cohraně registrů - párové funkce ObRegisterCallbacks a ObUnRegisterCallbacks umožňují zaregistrovat do systému rutinu (tzv. zpětně volanou funkci), která bude volána, kdykoliv se někdo pokusí o přístup k nějakému procesu či vláknu.

Pokud taková situace nastane, zpětně volaná funkce krom informací o cílovém procesu a vlákně a údajů o původci operace dostane i masku přístupu, o který volající proces žádá. Přístupová maska určuje, co s cílovým objektem může být provedeno, pokud byla operace získání přístupu úspěšná. Například přístupová maska procesu umožňuje specifikovat tato oprávnění:

  • Ukončit cílový proces
  • Pozastavit cílový proces
  • Vytvořit v cílovém procesu nové vlákno
  • Získat různé informace o procesu, např. prioritu či celý název souboru
  • Upravit některé informace (priorita)
  • Provádět operace s pamětí (čtení, zápis, alokace, uvolnění, změna ochrany stránek)

Samozřejmě platí, že pokud příslušné oprávnění nezískáte, nemůžete s cílovým procesem či vláknem danou akci provést (to neznamená, že by nebylo možné cílový proces ukončit, ikdyž na to nezískáte oprávnění - zničit běh procesu lze mnoha způsoby).

Pokus o přístup k procesu či vláknu není možné tímto způsobem zablokovat. Existují oprávnění, která zakázat nemůžete. Zajímavé je, že se volající proces o tom, že mu bylo pro přístup k jinému procesu či vláknu povoleno méně, než žádal, nedozví. Z jeho pohledu operace proběhne úspěšně. Překvapení nastává v okamžiku, kdy se pokusí domněle nabytých oprávěnní využít.

OB filtering model v současné době umožňuje chránit pouze procesy a vlákna. Je ale pravděpodobné, že se tento koncept rozšíří i na další typy objektů. Díky obecnosti Object Manageru by se z implementačního hlediska nemělo jednat o zásadní problém.

"Chráněné" (protected) procesy

Windows Vista také zavádí koncept tzv. chráněného procesu. Tento koncept však nebyl zaveden kvůli výrobcům bezpečnostních aplikací, ale pro ochranu DRM. Idea je taková, že chráněný obsah (video a audio) bude přehráván v procesu speciálního typu, pro který byl zaveden termín protected process. Přístup k těmto zvláštním procesům bude striktně omezen.

Stupeň ochrany těchto speciálních procesů je velmi podobný, jakého lze dosáhnout pomocí konceptu OB filtering model. Rozdíly jsou následující:

  • Chráněný proces lze ukončit
  • Paměť chráněného procesu nelze číst
  • Chráněný proces lze pozastavit
  • Vlákna chráněného procesu lze pozastavit
  • Pro chráněné procesy žádná tato přístupová omezení neplatí. Mohou libovolně přistupovat k ostatním procesům stejného typu

Obdobně jako u OB filtering modelu se při pokusu o přístup k chráněnému procesu volající nedozví, že získaná přístupová práva jsou případně nižší, než požadoval.

Chráněný proces se pro bezpečnostní účely nehodí zejména z toho důvodu, že jej lze ukončit. Navíc protože byl zaveden kvůli DRM, jej mohou vytvářet jen programy se speciálním digitálním podpisem.

Ochranu chráněného procesu lze samozřejmě zvýšit použitím mechanismu OB filtering model. O tom, zda proces je chráněného typu, rozhoduje jeden bit ve struktuře EPROCESS (pro přesné informace použijte ve WinDbg příkaz dt nt!_EPROCESS). Důlsledek jeho změny se projeví okamžitě a zdá se, že tato změna není hlídána PatchGuardem.

Blokování spuštění nežádoucích procesů

Detekce spouštění nového procesu nepatřila na Windows řady NT k úplně triviálním úkonům. Jádro systému sice poskytuje funkci PsSetCreateProcessNeotifyRoutine, která řekne systému, ať ovladač upozorní na nově vzniklý či právě ukončený proces. Nevýhodou tohoto konceptu je, že se hodí jen pro monitorovací účely - když vás systém notifikuje, nedává vám možnost běh procesu zablokovat. Proto se používaly metody jako úprava rutin volaných při spouštění procesu (NtCreateProcess, NtCreateProcessEx) či nabourání se do programu csrss.exe.

Techniky modifikace kódu na Vistách použít kvůli PatchGuardu nejde, vyjma snad modifikace v csrss.exe, ale to je málo dokumentovaná záležitost a navíc u chování csrss.exe došlo mezi XP a Vista ke změně. Windows Vista SP1 tento problém řeší přidáním nové funkce PsSetCreateNotifyRoutineEx. Princip je velmi podobný jako u funkce, které v názvu chybí sufix Ex - když se vytváří nebo ukončuje nějaký proces, systém zavolá ovladačem definovanou funkci. Při oznamování vytváření nového procesu navíc tato funkce dostane jméno souboru a může nový proces elegantně zablokovat změnou jediné hodnoty.

Ochrana souborů

Ochranu svých souborů bezpečnostní software většinou řeší pomocí filtrů souborového systému - ovladačů, které se navěsí na zařízení reprezentující diskové oddíly a monitorují či blokují operace, které se s těmito zařízeními dějí. Napsat takový filtr souborového systému není vůbec lehké a ani ne moc dokumentované, a tak se Microsoft rozhodl vytvořit nadstavbu, která by filtrování operací nad souborovým systémem usnadnila.

Nové rozhraní bylo implementováno jako ovladač fltmgr.sys. Tento ovladač se sám navěsí na všechna zařízení diskových oddílů a poskytuje relativně jednoduché funkce, jak operace nad těmito zařízeními monitorovat a blokovat. Vše je provedeno velmi podobně jako u filtrování přístupu k registrům - ovladač si zaregistruje sadu funkcí, které pak fltmgr.sys volá při různých operacích se soubory. Kód zpětně volaných funkcí může operace blokovat či úplně odemulovat. Mezi operace, které je možné monitorovat či blokovat, patří i mapování souboru do paměti. Protože se soubor mapuje do paměti například při načítání ovladače do jádra, lze blokováním této operace zakázat běh nežádoucích ovladačů a dalších spustitelných souborů.

Nevýhody těchto nových mechanismů

Z hlediska pisatele kódu jsou všechny popsané mechanismy velmi hezké - jednoduše se implementují a jsou dobře dokumentovány. Nevýhodou je, že některé z nich (PsSetCreateProcessNotifyEx, OB filtering model) může použít jen digitálně podepsaný ovladač - to platí i pro 32bitové verze Windows Vista.

Tyto techniky jsou efektivní převážně proti útočníkům z řad programů běžících v uživatelském režimu. Ovladač jádra zlé povahy může některé koncepty (chráněný proces, OB filtering model) snadno obejít či vypnout. Tady samozřejmě namítnete, že do jádra se dostanou jen ovladače digitálně podepsané, což by měla být jistá záruka kvality. Bohužel lze teoreticky (prakticky jsem to ještě nezkoušel) do jádra dostat i ovladače v praktickém slova smyslu nepodepsané (podepsané testovacím certifikátem, který si ale může vyrobit každý a nikdo jej nekontroluje).

Další vaše námitka může ukazovat na PatchGuard - ten přece hlídá výskyt nežádoucích změn jádra a při zjištění libovolné z nich vynutí pád do modré obrazovky. PatchGuard je vašk (jako každý jiný program) tvořen kódem a daty - a obě tyto složky mohou být modifikovány tak, aby byl výsledek zcela nefunkční. U PatchGuardu se to již podařilo. A jakmile je vypnut PatchGuard, můžeme se pomalu vrátit ke starým osvědčeným technikám. Zajímavé je, že bepečnostní software by těžit z možnosti vypnutí PatchGuardu neměl, protože PatchGuard sám o sobě je dobrý bezpečnostní mechanismus.

Závěr

Řekli jsme si pár základních fakt o PatchGuardu a problémech, které přinesl a nastínili jsme, jak tyto se nesnáze Microsoft snaží řešit. Řešení jsou to podle mého názoru vcelku elegantní, ale měla být v systému zabudována již dávno. Bohužel některé z nových konceptů vynucují digitální podpis, což je z pohledu Microsoftku krok logický, ale druhou stranu (a teď nemyslím "zlé hochy") příliš nepotěší.

Vše můžeme shrnout jednou větou: Microsoft vytvořil dobrý systém kontroly nežádoucích modifikací jádra a nyní se jej pokouší postupně celý podkopat.

Odkazy a zdroje

Bypassng Patchguard (CodeProject) File system filter drivers Kernel Data Structures filtering (pdf) Malý trik se SSDT Píšeme rootkity v r0 (SECIT) Playing with Windows /dev/kmem Protected processes (pdf) Registry filtering Shadow Walker SSDT - System Service Descriptor Table (SECIT)

Podporte nás


Páčil sa Vám tento článok? Ak áno, prosím podporte nás ľubovoľnou čiastkou. Ďakujeme!


ITC manažer Security-portal.cz Soom.cz
Hoax.cz Crypto-world.info