kraften i kraftanvändare

publicerades först på TechNet i maj 01, 2006

att placera Windows-användarkonton i Power Users security group är ett vanligt tillvägagångssätt som organisationer tar för att få användare till en minst privilegierad miljö samtidigt som man undviker de många smärtorna att verkligen köra som en begränsad användare. Gruppen Power Users kan installera programvara, Hantera inställningar för ström och tidszon och installera ActiveX-kontroller, åtgärder som begränsade användare nekas.
vad många administratörer misslyckas med att inse är dock att denna kraft kommer till priset av sann begränsad användarsäkerhet. Många artiklar, inklusive den här Microsoft Knowledge Base-artikeln och det här blogginlägget av Microsoft-säkerhetsspecialisten Jesper Johansen, påpekar att en användare som tillhör gruppen Power Users lätt kan höja sig till fullt privilegierade administratörer, men jag kunde inte hitta en detaljerad beskrivning av de höjdmekanismer de hänvisar till. Jag bestämde mig därför för att undersöka.
innan jag kunde börja utredningen var jag tvungen att definiera problemet. I avsaknad av ett säkerhetsfel som ett buffertspill är det bara möjligt att eskalera privilegier om ett konto kan konfigurera godtycklig kod för att köras i samband med ett mer privilegierat konto. Standardkonton som har mer behörighet än avancerade användare inkluderar administratörer och det lokala systemkontot, där flera Windows-serviceprocesser körs. Således, om en Power Users-medlem kan ändra en fil som körs av ett av dessa konton, konfigurera en av sina körbara filer för att ladda en godtycklig DLL eller lägga till en körbar automatisk start till dessa konton, kan de få full administratörsbehörighet.
mitt första steg var att se vilka filer och kataloger som Power Users-gruppen har skrivåtkomst till, men att begränsade användare inte gör det. Systemen jag ansåg var lager Windows 2000 Professional SP4, Windows XP SP2 och Windows Vista. Jag kommer inte att bry sig om att titta på serversystem eftersom det vanligaste Användarscenariot är på en arbetsstation.
brute force-metoden för att se vilka filsystemobjekt som strömanvändare kan ändra kräver att man besöker varje fil och katalog och undersöker dess behörigheter, något som helt klart inte är praktiskt. Kommandoraden cacls verktyg som Windows innehåller dumpar säkerhetsbeskrivningar, men jag har aldrig brytt lära Security Descriptor Description Language (SDDL) och analysera utdata skulle kräva att skriva ett skript. AccessEnum-verktyget som Bryce skrev verkade lovande och det kan också titta på Registersäkerhet, men det syftar till att visa potentiella behörighetssvagheter, inte åtkomsterna som är tillgängliga för vissa konton. Vidare visste jag att jag också skulle behöva undersöka säkerheten som tillämpas på Windows-tjänster.

jag drog slutsatsen att jag var tvungen att skriva ett nytt verktyg för jobbet, så jag skapade AccessChk . Du skickar AccessChk ett konto – eller gruppnamn och en filsystemsökväg, registernyckel eller Windows-servicenamn, och det rapporterar de effektiva åtkomsterna som kontot eller gruppen har för objektet, med hänsyn till kontots gruppmedlemskap. Om Mark-kontot till exempel hade tillgång till en fil, men Mark tillhör gruppen utvecklare som uttryckligen nekas åtkomst, skulle AccessChk visa Mark som ingen åtkomst.
för att göra utmatningen lättläst skriver AccessChk ‘ W ‘ bredvid objektnamnet om ett konto har några behörigheter som gör det möjligt att ändra ett objekt och ‘R’ om ett konto kan läsa objektets data eller status. Olika omkopplare gör att AccessChk återkommer till underkataloger eller Registerundernycklar och –v-omkopplaren rapporterar de specifika åtkomsterna som är tillgängliga för kontot. En switch som jag lade till specifikt för att söka efter objekt för vilka ett konto har skrivåtkomst är –w.
beväpnad med det här nya verktyget var jag redo att börja undersöka. Mitt första mål var en Windows XP SP2 VMWare-installation som inte har några andra installerade applikationer än VMWare-verktygen. Det första kommandot jag utförde var:
accesschk-ws “power users” c:\windows
detta visar alla filer och kataloger under \Windows-katalogen som gruppen avancerade användare kan ändra. Naturligtvis är många av filerna under \Windows en del av operativsystemet eller Windows-tjänsterna och körs därför i det lokala systemkontot. AccessChk rapporterade att avancerade användare kan ändra de flesta katalogerna under \Windows, vilket gör att medlemsanvändare kan skapa filer i dessa kataloger. Således kan en medlem i gruppen Power Users skapa filer i katalogen \Windows och \Windows\System32, vilket är ett vanligt krav på dåligt skrivna äldre applikationer. Dessutom måste avancerade användare kunna skapa filer i katalogen \Windows\nedladdade programfiler så att de kan installera ActiveX-kontroller, eftersom Internet Explorer sparar dem i den katalogen. Att bara skapa en fil i dessa kataloger är dock inte en väg till privilegiehöjning.
trots att avancerade användare kan skapa filer under \Windows och de flesta av dess underkataloger, konfigurerar Windows standardbehörigheter för de flesta filer som finns i dessa kataloger så att endast medlemmar i gruppen Administratörer och det lokala systemkontot har skrivåtkomst. Undantag inkluderar teckensnittsfilerna (.fon), många systemloggfiler (.log), några hjälpfiler (.chm), bilder och ljudklipp (.jpg,.gif, och .WMV) och installationsfiler (.inf), men ingen av dessa filer kan ändras eller ersättas för att få administrativ behörighet. Enhetsdrivrutinerna i \ Windows \ System32 \ drivrutiner skulle möjliggöra enkel eskalering, men avancerade användare har inte skrivåtkomst till någon av dem.

jag såg ett antal .exe och .dll är dock i listan, så jag undersökte dem för möjliga utnyttjanden. De flesta körbara filer för vilka strömanvändare har skrivåtkomst är interaktiva verktyg eller kör med reducerade behörigheter. Om du inte kan lura en administratör att logga in i systemet interaktivt, kan dessa inte användas för att höja. Men det finns ett skarpt undantag: ntoskrnl.exe:

det är rätt, avancerade användare kan ersätta eller ändra Windows kärnoperativsystemfil. Fem sekunder efter att filen har ändrats kommer dock Windows File Protection (WFP) att ersätta den med en säkerhetskopia som den hämtar i de flesta fall från \Windows\System32\Dllcache. Avancerade användare har inte skrivåtkomst till filer i Dllcache så det kan inte undergräva säkerhetskopian. Men medlemmar i gruppen Power Users kan kringgå WFP genom att skriva ett enkelt program som ersätter filen, spolar den modifierade data till disken och startar sedan om systemet innan WFP vidtar åtgärder.
jag verifierade att detta tillvägagångssätt fungerar, men frågan kvarstod om hur denna sårbarhet kan användas för att höja privilegiet. Svaret är lika enkelt som att använda en disassembler för att hitta den funktion som Windows använder för behörighetskontroller, SeSinglePrivilegeCheck , och lappa sin ingångspunkt i skivavbilden så att den alltid returnerar TRUE, vilket är resultatkoden som indikerar att en användare har privilegiet som kontrolleras för. När en användare körs på en kärna som modifierats på detta sätt verkar de ha alla privilegier, inklusive Lastdrivrutin, Ta äganderätt och skapa Token, för att bara nämna några av de privilegier som de enkelt kan utnyttja för att ta full administrativ kontroll över ett system. Även om 64-bitars Windows XP förhindrar kärnhantering med PatchGuard, körs få företag på 64-bitars Windows.
Ersätter Ntoksrnl.exe är dock inte det enda sättet att slå igenom till administrativt privilegium via \Windows-katalogen. Minst en av de dll-filer för vilka standardbehörigheter tillåter modifiering av Power User, Schedsvc.dll, körs som en Windows-tjänst i det lokala systemkontot. Schedsvc.dll är DLL som implementerar tjänsten Windows Task Scheduler. Windows kan fungera framgångsrikt utan tjänsten så avancerade användare kan ersätta DLL med en godtycklig DLL, till exempel en som helt enkelt lägger sitt konto till den lokala administratörsgruppen. Naturligtvis skyddar WFP den här filen också, så att ersätta den kräver användning av WFP-bypass-tekniken som jag har beskrivit.

jag hade redan identifierat flera höjdvektorer, men fortsatte min undersökning genom att titta på avancerade användare tillgång till katalogen \Program Files där jag hittade standardbehörigheter som liknar dem i katalogen \Windows. Avancerade användare kan skapa underkataloger under \ Program Files, men kan inte ändra de flesta av de förinstallerade Windows-komponenterna. Återigen, undantagen, som Windows Messenger (\Program Files\Messenger\Msmgs.exe) och Windows Media Player (\programfiler\Windows Media Player\Wmplayer.exe) kör interaktivt.
det betyder inte att \Program Files inte har potentiella hål. När jag undersökte den senaste utmatningen såg jag att strömanvändare kan ändra alla filer eller kataloger som skapats i \Programfiler efter de som skapades under Windows-installationen. På mitt testsystem \ Program Files\Vmware \ VMware Tools\Vmwareservice.exe, bildfilen för Vmware Windows-tjänsten som körs i det lokala systemkontot, var en sådan fil. Ett annat något ironiskt exempel är Microsoft Windows Defender Beta 2, som installerar sin tjänst körbar i \Program Files\Windows Defender med standard säkerhetsinställningar. Att ersätta dessa servicebildfiler är en snabb sökväg till administratörsbehörighet och är ännu enklare än att ersätta filer i \Windows-katalogen eftersom WFP inte blandar sig med ersättare.
nästa jag vände min uppmärksamhet till registret genom att köra detta kommando:
accesschk –swk “power users” hklm
utgångs listan var enorm eftersom strömanvändare har skrivåtkomst till den stora majoriteten av HKLM\Software key. Det första området jag studerade för möjliga höjningar var HKLM \ System-tangenten, eftersom skrivåtkomst till många inställningar under den, till exempel Windows service och driver configuration keys i HKLM\System\CurrentControlSet\Services, skulle tillåta trivial subversion av det lokala systemkontot. Analysen avslöjade att kraftanvändare inte har skrivåtkomst till något som är viktigt under den nyckeln.
de flesta av de avancerade användarna-skrivbara områden under den andra stora grenen av HKLM, programvara, relaterade till Internet Explorer, Explorer och dess filassociationer och energihanteringskonfiguration. Avancerade användare har också skrivåtkomst till HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, så att de kan konfigurera godtyckliga körbara filer att köra när någon loggar in interaktivt, men att utnyttja detta kräver en användare med administrativ behörighet att logga in på systemet interaktivt (vilket, beroende på systemet, aldrig kan hända eller hända sällan). Och precis som För katalogen \Program Files har Power Users standard skrivåtkomst till icke-Windows-undernycklar till HKLM\Software, vilket innebär att tredjepartsprogram som konfigurerar körbara kodvägar i sina systemövergripande registernycklar kan öppna säkerhetshål. VMWare, den enda applikationen installerad på systemet, gjorde det inte.

det återstående prospekteringsområdet var Windows-tjänster. De enda servicebehörigheter AccessChk anser vara skrivåtkomst är SERVICE_CHANGE_CONFIG och WRITE_DAC. En användare med SERVICE_CHANGE_CONFIG kan konfigurera en godtycklig körbar att starta när en tjänst startar och med tanke på WRITE_DAC kan de ändra behörigheterna för en tjänst för att ge sig själva SERVICE_CHANGE_CONFIG-åtkomst. AccessChk avslöjade följande på mitt lager Windows XP SP2-system:

jag körde nästa PsService för att se det konto där dcomlaunch-tjänsten körs:

således kan medlemmar i gruppen Power Users helt enkelt ändra bildvägen för DComLauncher för att peka på sin egen bild, starta om systemet och njuta av administrativa behörigheter.
det kan potentiellt finnas andra tjänster som introducerar exploater i deras säkerhet. Standardbehörigheterna som Windows anger för tjänster som skapats av tredjepartsapplikationer tillåter inte avancerade användare att skriva åtkomst, men vissa tredjepartsapplikationer kan konfigurera anpassade behörigheter så att de kan göra det. I själva verket, på min produktion 64-bitars Windows XP installation AccessChk avslöjar ett hål som inte bara avancerade användare kan använda för att höja sig, men att begränsade användare kan också:

jag hade nu avslutat den stora fasen av min undersökning och bara bekräftat vad alla har sagt: en bestämd medlem av Power Users-gruppen kan ganska enkelt göra sig full administratör med hjälp av exploater i operativsystemet och de som skapats av tredjepartsapplikationer.
mitt sista steg var att se hur Microsofts inställning till Power Users-kontot har utvecklats över tiden. Denna Microsoft Knowledge Base-artikel från 1999 dokumenterar den berömda skärmsläckarhöjdssårbarheten som fanns på Windows NT 4, men Microsoft stängde det hålet innan Windows 2000 släpptes. KB-artikeln visar också att Microsoft uppenbarligen inte kände till andra sårbarheter som sannolikt fanns. Windows 2000 SP4 innehåller också hål, men är faktiskt något säkrare än standard Windows XP SP2-konfiguration: avancerade användare har inte skrivåtkomst till Ntoskrnl.exe eller Task Scheduler-bildfilen, men istället för skrivåtkomst till dcomlauncher-tjänsten kan de undergräva WMI-tjänsten, som också körs i det lokala systemkontot.
Windows XP SP1 lagt till fler avancerade användare svagheter, inklusive skrivåtkomst till kritiska systemfiler som Svchost.exe, Windows Service hosting-processen och ytterligare tjänster, WMI och SSDPSRV, med exploaterbara behörigheter. Flera tjänster tillät till och med begränsade användare att höja som beskrivs i denna Microsoft KB-artikel från Mars i år.
Microsofts senaste operativsystem, Windows Vista, stänger alla sårbarheter som jag har beskrivit genom att kastrera strömanvändare så att det beter sig identiskt med begränsade användare. Microsoft har därmed stängt dörren för kraftanvändare för att tvinga IT-Personal att säkra sina system genom att flytta användare till begränsade användarkonton eller till administrativa konton där de måste erkänna slutanvändarens kontroll över sina system.
summan av kardemumman är att medan Microsoft kunde åtgärda de sårbarheter som jag hittade i min undersökning, de kan inte hindra tredjepartsprogram från att införa nya samtidigt bevara möjligheten för avancerade användare att installera program och ActiveX-kontroller. Lektionen är att du som IT-administratör inte ska lura dig själv att tro att Power Users-gruppen är en säker kompromiss på vägen till att köra som begränsad användare.

ursprungligen av Mark Russinovich på 5/1/2006 11:01: 00 am
migrerat från originalet Sysinternals.com/Blog