Kraften I Avanserte Brukere

først publisert På TechNet Mai 01, 2006

Å Plassere Windows-brukerkontoer i Sikkerhetsgruppen Power Users er en felles tilnærming IT-organisasjoner tar FOR å få brukere til et minst privilegert miljø, samtidig som man unngår de mange smertene ved å virkelig kjøre som en begrenset bruker. Power Users-gruppen kan installere programvare, administrere strøm-og tidssoneinnstillinger og installere ActiveX-kontroller, handlinger som begrensede Brukere nektes.
det mange administratorer ikke klarer å innse, er imidlertid at denne kraften kommer til prisen av ekte begrenset brukersikkerhet. Mange artikler, inkludert Denne Microsoft Knowledge Base-artikkelen og dette blogginnlegget av Microsofts sikkerhetsspesialist Jesper Johansen, påpeker at en bruker som tilhører Gruppen Power Users, enkelt kan heve seg til fullt privilegerte administratorer, men jeg kunne ikke finne en detaljert beskrivelse av høydemekanismer de refererer til. Derfor bestemte jeg meg for å undersøke.
Før jeg kunne starte etterforskningen, måtte jeg definere problemet. I fravær av en sikkerhetsfeil, for eksempel en bufferoverflyt privilegium opptrapping er bare mulig hvis en konto kan konfigurere vilkårlig kode for å kjøre i sammenheng med en mer privilegert konto. Standardkontoene som har flere privilegier enn Avanserte Brukere, inkluderer Administratorer og Den Lokale systemkontoen, der Flere Windows – tjenesteprosesser kjører. Dermed, hvis En Power Users medlem kan endre en fil utført av en av disse kontoene, konfigurere en av sine kjør å laste en vilkårlig DLL, eller legge til en kjørbar auto-start til disse kontoene, kan de få full administrative rettigheter.
Mitt første skritt var å se hvilke filer og kataloger Som Power Users-gruppen har skrivetilgang til, men at begrensede brukere ikke gjør det. Systemene jeg vurderte var lager Windows 2000 Professional SP4, Windows XP SP2 og Windows Vista. Jeg kommer ikke til å bry meg om å se på serversystemer fordi det vanligste Strømbrukerscenariet er på en arbeidsstasjon.
brute force-metoden for å se hvilke filsystemobjekter Som Strømbrukere Kan endre, krever at du besøker hver fil og katalog og undersøker tillatelsene, noe som tydeligvis ikke er praktisk. Kommandolinjens cacls-verktøy Som Windows inneholder dumper sikkerhetsbeskrivelser, men jeg har aldri plaget meg med Å lære Security Descriptor Description Language (SDDL) og analysere utdataene ville kreve å skrive et skript. AccessEnum-verktøyet Som Bryce skrev virket lovende, og det kan også se På Registersikkerhet, men det er rettet mot å vise potensielle tillatelser svakheter, ikke tilgangene som er tilgjengelige for bestemte kontoer. Videre visste jeg at jeg også måtte undersøke sikkerheten som ble brukt På Windows-tjenester.

jeg konkluderte med at jeg måtte skrive et nytt verktøy for jobben, så jeg opprettet AccessChk . Du sender AccessChk et konto – eller gruppenavn og en filsystembane, Registernøkkel eller Windows – tjenestenavn, og den rapporterer den effektive tilgangen kontoen eller gruppen har for objektet, med tanke på kontoens gruppemedlemskap. Hvis Mark-kontoen for eksempel hadde tilgang til en fil, men Mark tilhører Utviklergruppen som eksplisitt nektes tilgang, vil AccessChk vise Mark som ikke har tilgang.
For å gjøre utgangen lett å lese AccessChk skriver’ W ‘Ved siden av objektnavnet hvis en konto har noen tillatelser som vil tillate det å endre et objekt, Og’ R ‘ hvis en konto kan lese objektets data eller status. Ulike brytere føre AccessChk å rekursere i underkataloger eller Registerundernøkler og-v bryteren har det rapportere spesifikke tilganger tilgjengelig for kontoen. En bryter jeg la til spesielt for å oppsøke objekter som en konto har skrivetilgang til, er-w.
Bevæpnet med dette nye verktøyet var jeg klar til å begynne å undersøke. Mitt første mål var En Windows XP SP2 VMWare-installasjon som ikke har andre installerte programmer enn VMWare-Verktøyene. Den første kommandoen jeg utførte var:
accesschk-ws “power users” c:\windows
dette viser alle filene og katalogene under \ Windows-katalogen Som Gruppen Avanserte Brukere kan endre. Selvfølgelig er mange av filene under \Windows en del av operativsystemet eller Windows-tjenestene og kjører derfor i Den Lokale Systemkontoen. AccessChk rapporterte At Avanserte Brukere kan endre de fleste katalogene under \ Windows, som tillater medlemsbrukere å lage filer i disse katalogene. Dermed kan et medlem av Gruppen Power Users opprette filer i katalogen \Windows Og \Windows\System32, som er et vanlig krav til dårlig skrevet eldre programmer. I Tillegg Må Strømbrukere kunne opprette filer i Mappen\Windows \ Nedlastede programfiler slik at De kan installere ActiveX-kontroller, Siden Internet Explorer lagrer dem i den katalogen. Men bare å lage en fil i disse katalogene er ikke en bane til privilegiet høyde.
Til Tross For At Avanserte Brukere kan opprette filer under \Windows og de fleste underkatalogene, konfigurerer Windows standard sikkerhetstillatelser på de fleste filene i disse katalogene, slik at bare medlemmer av Administratorgruppen og Den Lokale Systemkontoen har skrivetilgang. Unntak inkluderer skriftfiler (.fon), mange system loggfiler (.logg), noen hjelpefiler (.chm), bilder og lydklipp (.jpg, .gif og .wmv) og installasjonsfiler (.inf), men ingen av disse filene kan endres eller erstattes for å få administrative rettigheter. Enhetsdriverne i\Windows \ System32 \ Drivers vil tillate enkel eskalering, Men Strømbrukere har ikke skrivetilgang til noen av dem.

jeg så en rekke .exe og .dll er på listen, skjønt, så jeg undersøkte dem for mulige utnyttelser. De fleste kjørbare filer Som Avanserte Brukere har skrivetilgang for, er interaktive verktøy eller kjører med reduserte rettigheter. Med mindre du kan lure en administrator til å logge inn i systemet interaktivt, kan disse ikke brukes til å heve. Men det er ett grell unntak: ntoskrnl.exe:

Det er riktig, Kan Avanserte Brukere erstatte Eller endre Windows ‘ kjerne operativsystem fil. Fem sekunder etter at filen er endret, Vil Windows File Protection (WFP) erstatte Den med en sikkerhetskopi den henter, i de fleste tilfeller, fra \Windows\System32\Dllcache. Strømbrukere har ikke skrivetilgang til filer i Dllcache, slik at den ikke kan undergrave sikkerhetskopien. Men Medlemmer Av Power Users-gruppen kan omgå WFP ved å skrive et enkelt program som erstatter filen, spyler de endrede dataene til disk, og starter deretter systemet på nytt før WFP tar tiltak.
jeg bekreftet at denne tilnærmingen fungerer, men spørsmålet gjenstår om hvordan dette sikkerhetsproblemet kan brukes til å heve privilegium. Svaret er like enkelt som å bruke en disassembler for å finne funksjonen Som Windows bruker for privilegeringskontroller, SeSinglePrivilegeCheck og patching av inngangspunktet i diskbildet slik at DET alltid returnerer TRUE, som er resultatkoden som indikerer at en bruker har privilegiet som kontrolleres for. Når en bruker kjører på en kjerne som er modifisert på denne måten, ser de ut til å ha alle privilegier, inkludert Last Driver, Ta Eierskap og Opprett Token, for å nevne noen av de privilegiene de enkelt kan utnytte for å ta full administrativ kontroll over et system. Selv om 64-biters Windows XP forhindrer kernel tukling Med PatchGuard, er det få bedrifter som kjører på 64-biters Windows.
Bytte Ntoksrnl.exe er ikke den eneste måten å slå gjennom til administrativt privilegium via \ Windows-katalogen, men . Minst en Av Dllene som standardtillatelser tillater endring Av Strømbruker, Schedsvc.dll, kjører Som En Windows-tjeneste I Den Lokale Systemkontoen. Schedsvc.dll er DLL som implementerer Windows Task Scheduler tjenesten. Windows kan fungere uten tjenesten, slik At Strømbrukere kan erstatte DLL MED en vilkårlig DLL, for eksempel en som bare legger til kontoen sin I Den Lokale Administratorgruppen. SELVFØLGELIG beskytter WFP også denne filen, så erstatning av den krever BRUK AV wfp-bypass teknikken jeg har beskrevet.
jeg hadde allerede identifisert flere høydevektorer,men fortsatte undersøkelsen min ved å se På Power Users tilgang til \ Program Files-katalogen der jeg fant standardtillatelser som ligner på de i \Windows-katalogen. Avanserte Brukere kan opprette underkataloger under \Programfiler, men kan ikke endre de fleste Av de forhåndsinstallerte windows-komponentene. Igjen, unntakene, Som Windows Messenger (\Program Files \ Messenger \ Msmgs.exe) Og Windows Media Player (\Programfiler \ Windows Media Player \ Wmplayer.exe) kjøre interaktivt.

det betyr ikke at \Programfiler ikke har potensielle hull. Da jeg undersøkte den siste utgangen, så jeg At Strømbrukere kan endre hvilken som helst fil eller katalog som er opprettet i \ Programfiler etter de som er opprettet under windows-installasjonen. På min test system \ Programfiler\Vmware\Vmware Tools\Vmwareservice.exe, bildefilen For Vmware Windows-tjenesten som kjører I Den Lokale Systemkontoen, var en slik fil. Et annet noe ironisk eksempel Er Microsoft Windows Defender Beta 2, som installerer sin tjeneste kjørbar i \ Program Files \ Windows Defender med standard sikkerhetsinnstillinger. Erstatte disse tjenesten bildefiler er en rask bane til administratorrettigheter og er enda enklere enn å erstatte filer i \ Windows-katalogen fordi WFP ikke blande seg med erstatninger.
neste jeg viste min oppmerksomhet Til Registeret ved å kjøre denne kommandoen:
accesschk-swk” power users ” hklm
output listen var enorm fordi Strømbrukere har skrivetilgang til det store flertallet AV hklm \ Software key. DET første området jeg studerte for mulige høyder var hklm \ System-nøkkelen, fordi skrivetilgang til mange innstillinger under Den, for Eksempel Windows-tjenesten og driverkonfigurasjonstastene I HKLM \ System \ CurrentControlSet \ Services, ville tillate trivial subversion Av Den Lokale Systemkontoen. Analysen viste at Strømbrukere ikke har skrivetilgang til noe som er viktig under den nøkkelen.
De Fleste Av De Avanserte Brukerne-skrivbare områder under den andre store grenen AV HKLM, Programvare, relatert Til Internet Explorer, Explorer og dets filtilknytninger, og strømstyringskonfigurasjon. Avanserte Brukere har også skrivetilgang TIL HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, slik at de kan konfigurere vilkårlige kjørbare filer til å kjøre når noen logger på interaktivt, men å utnytte dette krever en bruker med administrativt privilegium å logge på systemet interaktivt (som, avhengig av systemet, kan aldri skje, eller skje sjelden). Og akkurat som for \Program Files-katalogen, Har Power Users standard skrivetilgang til ikke-Windows-undernøkler AV HKLM \ Software, noe som betyr at tredjepartsprogrammer som konfigurerer kjørbare kodebaner i Systemomfattende Registernøkler, kan åpne sikkerhetshull. VMWare, det eneste programmet som er installert på systemet, gjorde det ikke.
det gjenværende området for utforskning var Windows services. Den eneste tjenesten tillatelser AccessChk anser for å være skrivetilgang ER SERVICE_CHANGE_CONFIG og WRITE_DAC. EN bruker MED SERVICE_CHANGE_CONFIG kan konfigurere en vilkårlig kjørbar å starte når en tjeneste starter og gitt WRITE_DAC de kan endre tillatelsene på en tjeneste for å gi SEG SELV SERVICE_CHANGE_CONFIG tilgang. AccessChk avslørte følgende På mitt lager Windows XP SP2 system:

jeg kjørte Neste PsService for å se kontoen Der dcomlaunch-tjenesten utfører:

dermed kan Medlemmer Av Power Users-gruppen bare endre bildebanen Til DComLauncher for å peke på sitt eget bilde, starte systemet på nytt og nyte administrative rettigheter.
det kan potensielt være andre tjenester som introduserer utnyttelser i deres sikkerhet. Standard tillatelser Windows-sett på tjenester som er opprettet av tredjepartsprogrammer tillater Ikke Avanserte brukere skrivetilgang, men noen tredjepartsprogrammer kan konfigurere egendefinerte tillatelser for å tillate dem å gjøre det. Faktisk, på min produksjon 64-bit Windows XP installasjon AccessChk avslører et hull som ikke Bare Strømbrukere kan bruke til å heve seg, men at begrensede brukere kan også:

jeg hadde nå avsluttet den store fasen av undersøkelsen min og bekreftet bare hva alle har sagt: et bestemt medlem av Power Users-gruppen kan ganske enkelt gjøre seg full administrator ved hjelp av utnyttelser i operativsystemet og de som er opprettet av tredjepartsprogrammer.
mitt siste skritt var å se Hvordan Microsofts tilnærming til Power Users-kontoen har utviklet seg over tid. Denne Microsoft Knowledge Base-artikkelen fra 1999 dokumenterer den berømte skjermsparer-sårbarheten som eksisterte i Windows Nt 4, Men Microsoft lukket det hullet før utgivelsen Av Windows 2000. KB-artikkelen viser også At Microsoft tilsynelatende ikke var klar over andre sårbarheter som sannsynligvis eksisterte. Windows 2000 SP4 inneholder også hull, men er faktisk litt sikrere enn standard Windows XP SP2-konfigurasjon: Strømbrukere har ikke skrivetilgang til Ntoskrnl.exe eller Task Scheduler image file, men i stedet for skrivetilgang til dcomlauncher-tjenesten, kan DE undergrave wmi-tjenesten, som også kjører I Den Lokale Systemkontoen.
Windows XP SP1 lagt til Flere Strømbrukere svakheter, inkludert skrivetilgang til kritiske systemfiler som Svchost.exe, windows service hosting prosessen, og tilleggstjenester, WMI og SSDPSRV, med utnyttbare tillatelser. Flere tjenester tillot selv begrensede brukere å heve som beskrevet i Denne MICROSOFT KB-artikkelen Fra Mars i år.
Microsofts nyeste operativsystem, Windows Vista, lukker alle sårbarhetene jeg har beskrevet av neutering Power-Brukere, slik at den oppfører seg identisk med begrensede Brukere. Microsoft har dermed lukket døren På Strømbrukere for å tvinge IT-staber til å sikre sine systemer ved å flytte brukere til begrensede Brukerkontoer eller til administrative kontoer der de må erkjenne sluttbrukerkontroll over sine systemer.
bunnlinjen Er At Mens Microsoft kunne fikse sårbarhetene jeg fant i undersøkelsen, kan De ikke forhindre at tredjepartsprogrammer introduserer nye, samtidig som De beholder Muligheten Til Avanserte Brukere til å installere programmer og ActiveX-kontroller. Leksjonen er AT SOM IT-administrator bør DU ikke lure deg selv til å tro At Power Users-gruppen er et sikkert kompromiss på vei til å kjøre som begrenset bruker.

Opprinnelig Av Mark Russinovich på 5/1/2006 11:01: 00 am
Migrert fra original Sysinternals.com/Blog