the Power in Power Users

poprvé publikováno na Technetu v květnu 01, 2006

umístění uživatelských účtů systému Windows do skupiny zabezpečení uživatelů je běžným přístupem, který organizace používají k tomu, aby uživatele dostaly do prostředí s nejmenšími oprávněními a zároveň se vyhnuly mnoha bolestem skutečného běhu jako omezený uživatel. Skupina Power Users je schopna instalovat software, spravovat nastavení napájení a časového pásma a instalovat ovládací prvky ActiveX, akce, které jsou omezeným uživatelům odepřeny.
mnoho správců si však neuvědomuje, že tato síla přichází za cenu skutečné omezené bezpečnosti uživatelů. Mnoho článků, včetně tohoto článku znalostní báze společnosti Microsoft a tohoto blogu od bezpečnostního specialisty společnosti Microsoft Jespera Johansena, poukazuje na to, že uživatel, který patří do skupiny Power Users, se může snadno povýšit na plně privilegované administrátory, ale nebyl jsem schopen najít podrobný popis výškových mechanismů, na které odkazují. Rozhodl jsem se proto prošetřit.
než jsem mohl zahájit vyšetřování, musel jsem definovat problém. Při absenci bezpečnostní chyby, jako je eskalace oprávnění přetečení vyrovnávací paměti, je možná pouze v případě, že účet může nakonfigurovat libovolný kód, který má být spuštěn v kontextu více privilegovaného účtu. Výchozí účty, které mají více oprávnění než výkonní Uživatelé, zahrnují správce a místní systémový účet, ve kterém běží několik procesů služby Windows. Pokud tedy člen Power Users může upravit soubor provedený jedním z těchto účtů, nakonfigurovat jeden ze svých spustitelných souborů tak, aby načetl libovolnou DLL nebo přidal spustitelný automatický start k těmto účtům, může získat plná oprávnění správce.
mým prvním krokem bylo zjistit, jaké soubory a adresáře, ke kterým má skupina Power Users přístup k zápisu, ale to omezené uživatele ne. Systémy, které jsem považoval, byly skladem Windows 2000 Professional SP4, Windows XP SP2 a Windows Vista. Nebudu se obtěžovat při pohledu na serverové systémy, protože nejběžnější scénář uživatelů energie je na pracovní stanici.
metoda hrubé síly, která vidí, jaké objekty systému souborů mohou uživatelé upravovat, vyžaduje návštěvu každého souboru a adresáře a zkoumání jeho oprávnění, což zjevně není praktické. Nástroj cacls příkazového řádku, který systém Windows obsahuje, vypíše deskriptory zabezpečení, ale nikdy jsem se neobtěžoval učit jazyk popisu deskriptoru zabezpečení (SDDL)a analýza výstupu by vyžadovala psaní skriptu. Nástroj AccessEnum, který Bryce napsal, vypadal slibně a může se také podívat na zabezpečení registru,ale jeho cílem je ukázat potenciální slabiny oprávnění, nikoli přístupy dostupné pro konkrétní účty. Dále jsem věděl,že budu muset také prozkoumat zabezpečení aplikované na služby Windows.

došel jsem k závěru, že jsem musel napsat nový nástroj pro práci, a tak jsem vytvořil AccessChk . Předáte AccessChk účet nebo název skupiny a cestu k systému souborů, klíč registru, nebo název služby Windows, a hlásí efektivní přístupy účet nebo skupina má pro objekt, s přihlédnutím k členství ve skupině účtu. Například, pokud účet Mark měl přístup k souboru, ale Mark patří do skupiny vývojářů, která je explicitně odepřen přístup, pak AccessChk ukáže Mark jako nemá přístup.
aby byl výstup snadno čitelný, vytiskne AccessChk vedle názvu objektu “W”, pokud má účet nějaká oprávnění, která by mu umožnila Upravit objekt, a “R”, Pokud účet dokáže číst data nebo stav objektu. Různé přepínače způsobují, že se AccessChk rekurzuje do podadresářů nebo podklíčů registru a přepínač-v má nahlásit konkrétní přístupy dostupné pro účet. Přepínač, který jsem přidal speciálně pro vyhledávání objektů, pro které má účet přístup k zápisu, je-w.
vyzbrojen tímto novým nástrojem jsem byl připraven začít vyšetřovat. Mým prvním cílem byla instalace systému Windows XP SP2 VMWare, která nemá nainstalované jiné aplikace než nástroje VMWare. První příkaz, který jsem provedl, byl:
accesschk-ws “power users” c:\windows
zobrazí se všechny soubory a adresáře v adresáři \Windows, které může skupina Power Users upravit. Mnoho souborů pod \Windows je samozřejmě součástí operačního systému nebo služeb Windows, a proto se spouští v místním systémovém účtu. AccessChk oznámil, že uživatelé moci mohou upravit většinu adresářů pod \Windows, což umožňuje uživatelům členských vytvářet soubory v těchto adresářích. Člen skupiny Power Users tak může vytvářet soubory v adresáři \Windows a \Windows\System32, což je běžný požadavek špatně napsaných starších aplikací. Kromě toho musí uživatelé moci vytvářet soubory v adresáři\Windows \ stažené programové soubory, aby mohli instalovat ovládací prvky ActiveX, protože Internet Explorer je ukládá do tohoto adresáře. Jednoduché vytvoření souboru v těchto adresářích však není cestou k elevaci oprávnění.
navzdory skutečnosti, že silní uživatelé mohou vytvářet soubory pod \Windows a většina z jeho podadresářů, Windows nakonfiguruje výchozí oprávnění zabezpečení na většině souborů obsažených v těchto adresářích tak, že pouze členové skupiny administrátorů a místní systémový účet mají přístup k zápisu. Výjimky zahrnují soubory písem (.fon), mnoho souborů protokolu systému (.log), některé soubory nápovědy (.chm), obrázky a zvukové klipy (.jpg, .gif, a .wmv) a instalační soubory (.inf), ale žádný z těchto souborů nemůže být změněn nebo nahrazen, aby získal oprávnění správce. Ovladače zařízení v \Windows\System32\Drivers by umožnily snadnou eskalaci, ale výkonní uživatelé nemají přístup k zápisu k žádnému z nich.

viděl jsem řadu .exe a .dll je v seznamu, ačkoli, tak jsem je zkoumal na možné zneužití. Většina spustitelných souborů, pro které mají mocní uživatelé přístup k zápisu, jsou interaktivní nástroje nebo běží se sníženými oprávněními. Pokud nemůžete administrátora přimět k interaktivnímu přihlášení do systému, nelze je použít ke zvýšení. Ale je tu jedna do očí bijící výjimka: ntoskrnl.exe:

to je pravda, výkonní uživatelé mohou nahradit nebo upravit základní soubor operačního systému Windows. Pět sekund po úpravě souboru však systém Windows File Protection (WFP) nahradí záložní kopii, kterou načte ve většině případů z \Windows\System32\Dllcache. Výkonní uživatelé nemají přístup k zápisu do souborů v Dllcache, takže nemohou podvracet záložní kopii. Členové skupiny Power Users však mohou WFP obejít napsáním jednoduchého programu, který nahradí soubor, propláchne upravená data na disk a poté restartuje systém dříve, než WFP podnikne kroky.
Ověřil jsem, že tento přístup funguje, ale otázkou zůstává, jak lze tuto chybu zabezpečení použít ke zvýšení oprávnění. Odpověď je stejně snadná jako použití disassembleru k nalezení funkce, kterou Windows používá pro kontroly oprávnění, SeSinglePrivilegeCheck, a oprava jeho vstupního bodu v obrazu na disku tak, aby vždy vrátil TRUE, což je výsledný kód, který označuje, že uživatel má oprávnění, které je kontrolováno. Jakmile uživatel běží na takto upraveném jádře, zdá se, že má všechna oprávnění, včetně načtení ovladače, převzetí vlastnictví a vytvoření tokenu, aby pojmenoval jen několik oprávnění, která mohou snadno využít k plné administrativní kontrole systému. Přestože 64bitový systém Windows XP zabraňuje manipulaci jádra s Patchguardem, na 64bitovém systému Windows běží jen málo podniků.
Nahrazení Ntoksrnl.exe však není jediný způsob, jak projít správním oprávněním prostřednictvím adresáře \Windows. Alespoň jeden z DLL, pro které výchozí oprávnění umožňují modifikaci Power User, Schedsvc.dll, běží jako služba Windows v místním systémovém účtu. Schedsvc.dll je DLL, která implementuje službu Plánovač úloh systému Windows. Systém Windows může úspěšně fungovat bez služby, takže výkonní uživatelé mohou nahradit DLL libovolnou DLL, například takovou, která jednoduše přidá svůj účet do skupiny místních správců. Samozřejmě, WFP chrání tento soubor stejně, takže jeho nahrazení vyžaduje použití techniky WFP-bypass, kterou jsem popsal.
už jsem identifikoval několik elevačních vektorů, ale pokračoval jsem ve svém vyšetřování tím, že jsem se podíval na přístup uživatelů k adresáři \Program Files, kde jsem našel výchozí oprávnění podobná těm v adresáři \Windows. Výkonní uživatelé mohou vytvářet podadresáře pod \Program Files, ale nemohou upravovat většinu předinstalovaných komponent systému Windows. Opět platí výjimky, jako je Windows Messenger (\Program Files \ Messenger\Msmgs.exe) a Windows Media Player (\Program Files\Windows Media Player \ Wmplayer.exe) spustit interaktivně.

to neznamená, že \Program Files nemá potenciální díry. Když jsem zkoumal nejnovější výstup, viděl jsem, že výkonní uživatelé mohou upravit libovolný soubor nebo adresář vytvořený v programových souborech po souborech vytvořených během základní instalace systému Windows. Na mém testovacím systému \Program Files \ Vmware \ Vmware Tools \ Vmwareservice.exe, obrazový soubor pro službu Vmware Windows, který běží v místním systémovém účtu, byl takový soubor. Dalším poněkud ironickým příkladem je Microsoft Windows Defender Beta 2, který nainstaluje spustitelný soubor služby do \Program Files\Windows Defender s výchozím nastavením zabezpečení. Nahrazení těchto obrazových souborů služby je rychlá cesta k oprávnění správce a je ještě jednodušší než nahrazení souborů v adresáři \Windows, protože WFP se nezasahuje do náhrad.
dále jsem obrátil svou pozornost k registru spuštěním tohoto příkazu:
accesschk-swk” power users ” hklm
výstupní seznam byl obrovský, protože uživatelé moci mají přístup k zápisu k drtivé většině softwarového klíče HKLM. První oblastí, kterou jsem studoval pro možné zvýšení, byl HKLM\system key, protože přístup k zápisu do mnoha nastavení pod ním, jako jsou Windows service a konfigurační klíče ovladačů v HKLM\System\CurrentControlSet\Services, by umožnil triviální subversion místního systémového účtu. Analýza odhalila, že výkonní uživatelé nemají přístup k zápisu k ničemu významnému pod tímto klíčem.
většina uživatelů energie-zapisovatelné oblasti pod jiným hlavním odvětvím HKLM, Software, související s Internet Explorer, Explorer a jeho asociacemi souborů a konfigurací správy napájení. Výkonní uživatelé mají také přístup pro zápis do HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, což jim umožňuje konfigurovat libovolné spustitelné soubory, které se mají spouštět, kdykoli se někdo přihlásí interaktivně, ale jeho využití vyžaduje, aby se uživatel s oprávněním správce přihlásil do systému interaktivně (což se v závislosti na systému nemusí nikdy stát nebo se může stát zřídka). A stejně jako pro adresář \Program Files, uživatelé s výkonem mají výchozí přístup k zápisu do podklíčů HKLM\Software, které nejsou Windows, což znamená, že aplikace třetích stran, které konfigurují cesty spustitelného kódu ve svých klíčích registru v celém systému, by mohly otevřít bezpečnostní díry. VMWare, jediná aplikace nainstalovaná v systému, ne.
zbývající oblastí průzkumu byly služby Windows. Jediné oprávnění služby AccessChk považuje za přístup k zápisu jsou SERVICE_CHANGE_CONFIG a WRITE_DAC. Uživatel s SERVICE_CHANGE_CONFIG může nakonfigurovat libovolný spustitelný soubor, který se spustí při spuštění služby, a vzhledem k tomu, že WRITE_DAC může upravit oprávnění ke Službě a udělit si přístup SERVICE_CHANGE_CONFIG. AccessChk odhalil následující informace o mém systému Windows XP SP2:

dále jsem spustil PsService, abych viděl účet, ve kterém služba DcomLaunch provádí:

členové skupiny Power Users tak mohou jednoduše změnit cestu obrazu DComLauncher tak, aby ukazovali na svůj vlastní obrázek, restartovali systém a užívali si oprávnění správce.
potenciálně mohou existovat další služby, které zavádějí exploity v jejich zabezpečení. Výchozí oprávnění, která systém Windows nastavuje na služby vytvořené aplikacemi třetích stran, neumožňují výkonným uživatelům přístup k zápisu, ale některé aplikace třetích stran mohou nakonfigurovat vlastní oprávnění, aby jim to umožnily. Ve skutečnosti na my production 64-bit Windows XP instalace AccessChk odhaluje díru, kterou mohou nejen uživatelé moci použít k povýšení, ale také omezeni uživatelé:

nyní jsem dokončil hlavní fázi svého vyšetřování a právě jsem potvrdil, co všichni říkali: odhodlaný člen skupiny Power Users group se může poměrně snadno stát úplným správcem pomocí exploitů v operačním systému a těch vytvořených aplikacemi třetích stran.
mým posledním krokem bylo zjistit, jak se přístup společnosti Microsoft k účtu Power Users v průběhu času vyvíjel. Tento 1999 Microsoft Knowledge Base článek dokumentuje slavný screen-saver elevation zranitelnost, která existovala v systému Windows NT 4, ale Microsoft uzavřel tuto díru před vydáním systému Windows 2000. Článek KB také ukazuje, že Microsoft zjevně nevěděl o dalších zranitelnostech, které pravděpodobně existovaly. Windows 2000 SP4 také obsahuje díry, ale je ve skutečnosti o něco bezpečnější než výchozí konfigurace systému Windows XP SP2: výkonní uživatelé nemají přístup k zápisu do Ntoskrnl.exe nebo soubor s obrázkem Plánovače úloh, ale místo přístupu k zápisu do služby DComLauncher mohou podvracet službu WMI, která také běží v místním systémovém účtu.
Windows XP SP1 přidal více slabých stránek uživatelů, včetně přístupu k zápisu do kritických systémových souborů, jako je Svchost.exe, proces hostování služeb Windows a další služby, WMI a SSDPSRV, s využitelnými oprávněními. Několik služeb dokonce umožnilo omezeným uživatelům povýšit, jak je popsáno v tomto článku Microsoft KB od března tohoto roku.
nejnovější operační systém společnosti Microsoft, Windows Vista, uzavírá všechny chyby zabezpečení, které jsem popsal kastrací uživatelů, takže se chová stejně jako omezené uživatele. Microsoft tak zavřel dveře pro výkonné uživatele, aby přinutil it štáby k zabezpečení svých systémů přesunutím uživatelů do účtů omezených uživatelů nebo do administrativních účtů, kde musí uznat kontrolu koncových uživatelů nad svými systémy.
pointa je, že zatímco Microsoft mohl opravit chyby zabezpečení, které jsem našel v mém vyšetřování, nemohou zabránit aplikacím třetích stran v zavádění nových a zároveň zachovat schopnost uživatelů moci instalovat aplikace a ovládací prvky ActiveX. Poučení je, že jako správce IT byste se neměli oklamat, abyste si mysleli, že skupina Power Users je bezpečným kompromisem na cestě k běhu jako omezený uživatel.

původně Mark Russinovich na 5/1/2006 11:01: 00 AM
migroval z originálu Sysinternals.com/Blog