strømmen i strømbrugere

først offentliggjort på TechNet den maj 01, 2006

placering af brugerkonti i Superbrugersikkerhedsgruppen er en almindelig tilgang, som organisationer tager for at få brugere ind i et mindst privilegeret miljø, samtidig med at man undgår de mange smerter ved virkelig at køre som en begrænset bruger. Gruppen superbrugere er i stand til at installere programmer, administrere strøm-og tidsindstillinger og installere activeks-kontroller, handlinger, som begrænsede brugere nægtes.
hvad mange administratorer undlader at indse, er imidlertid, at denne magt kommer til prisen for ægte begrænset brugersikkerhed. Mange artikler, herunder denne Microsoft-vidensbase-artikel og dette blogindlæg af Microsoft-sikkerhedsspecialist Jesper Johansen, påpeger, at en bruger, der hører til Superbrugergruppen, let kan hæve sig til fuldt privilegerede administratorer, men jeg kunne ikke finde en detaljeret beskrivelse af de højdemekanismer, de henviser til. Jeg besluttede derfor at undersøge.
før jeg kunne starte undersøgelsen, måtte jeg definere problemet. I mangel af en sikkerhedsfejl, såsom et bufferoverløb, er rettighedsforøgelse kun mulig, hvis en konto kan konfigurere vilkårlig kode til at udføres i forbindelse med en mere privilegeret konto. Standardkontiene, der har mere privilegium end strømbrugere, inkluderer administratorer og den lokale systemkonto, hvor flere serviceprocesser kører. Hvis et Superbrugermedlem således kan ændre en fil, der udføres af en af disse konti, konfigurere en af deres eksekverbare filer til at indlæse en vilkårlig DLL eller tilføje en eksekverbar automatisk start til disse konti, kan de få fulde administrative rettigheder.
mit første skridt var at se, hvilke filer og mapper, som Superbrugergruppen har skriveadgang til, men at begrænsede brugere ikke gør det. De systemer, jeg overvejede, var lagervinduer 2000 Professional SP4, vinduer SP2 og Vinduer Vista. Jeg vil ikke gider at se på serversystemer, fordi det mest almindelige Strømbrugerscenarie er på en arbejdsstation.
brute force-metoden til at se, hvilke filsystemobjekter, som strømbrugere kan ændre, kræver at besøge hver fil og mappe og undersøge dens tilladelser, noget der tydeligvis ikke er praktisk. Kommandolinjens cacls-værktøj, som vinduer indeholder lossepladser sikkerhedsbeskrivere, men jeg har aldrig generet at lære Sikkerhedsbeskrivelsessprog (SDDL) og analysere output ville kræve at skrive et script. AccessEnum-værktøjet, som Bryce skrev, syntes lovende, og det kan også se på Registreringssikkerhed, men det sigter mod at vise potentielle tilladelsessvagheder, ikke de tilgængelige adgang til bestemte konti. Desuden vidste jeg, at jeg også skulle undersøge den sikkerhed, der anvendes til vinduer.

jeg konkluderede, at jeg var nødt til at skrive et nyt værktøj til jobbet, så jeg oprettede AccessChk . Du videregiver AccessChk et konto-eller gruppenavn og en filsystemsti, registreringsdatabasenøgle eller et servicenavn, og det rapporterer de effektive adganger, kontoen eller gruppen har for objektet, under hensyntagen til kontoens gruppemedlemskaber. For eksempel, hvis Mark-kontoen havde adgang til en fil, men Mark tilhører Udviklergruppen, der udtrykkeligt nægtes adgang, ville AccessChk vise Mark som uden adgang.
for at gøre outputtet let at læse, udskriver AccessChk ‘V’ ved siden af objektnavnet, hvis en konto har tilladelser, der gør det muligt at ændre et objekt, og ‘R’, hvis en konto kan læse objektets data eller status. Forskellige kontakter får AccessChk til at gentage sig i undermapper eller undernøgler i registreringsdatabasen, og –v-kontakten får den til at rapportere de specifikke adganger, der er tilgængelige for kontoen.
bevæbnet med dette nye værktøj var jeg klar til at begynde at undersøge. Mit første mål var en installation af SP2, der ikke har andre installerede applikationer end værktøjerne. Den første kommando, jeg udførte, var:
accesschk-vs. “strømbrugere” c:\windows
dette viser alle de filer og mapper under mappen \vinduer, som Superbrugergruppen kan ændre. Selvfølgelig er mange af filerne under \vinduer en del af operativsystemet eller vinduer tjenester og udføres derfor på den lokale systemkonto. AccessChk rapporterede, at strømbrugere kan ændre de fleste mapper under \vinduer, hvilket giver medlemsbrugere mulighed for at oprette filer i disse mapper. Således kan et medlem af Superbrugergruppen oprette filer i mappen \vinduer og \vinduer\System32, hvilket er et almindeligt krav til dårligt skrevne ældre applikationer. Derudover skal superbrugere være i stand til at oprette filer i mappen \vinduer\hentede programfiler, så de kan installere activeks-kontroller, da Internetudforsker gemmer dem i den pågældende mappe. Men blot at oprette en fil i disse mapper er ikke en sti til privilegium elevation.
på trods af at superbrugere kan oprette filer under \vinduer og de fleste af dens undermapper, konfigurerer vinduer standardsikkerhedstilladelser på de fleste filer indeholdt i disse mapper, så kun medlemmer af gruppen Administratorer og den lokale systemkonto har skriveadgang. Undtagelser omfatter Skrifttypefiler (.fon), mange system logfiler (.log), nogle hjælpefiler (.chm), billeder og lydklip (.jpg, .gif, og .installationsfiler (.inf), men ingen af disse filer kan ændres eller erstattes for at få administrativt privilegium. Enhedsdriverne i\vinduer\System32 \ drivere ville tillade let eskalering, men strømbrugere har ikke skriveadgang til nogen af dem.
jeg så en række .eks og .dll er dog på listen, så jeg undersøgte dem for mulige udnyttelser. De fleste af de eksekverbare filer, som strømbrugere har skriveadgang til, er interaktive værktøjer eller kører med reducerede privilegier. Medmindre du kan narre en administrator til at logge ind på systemet interaktivt, kan disse ikke bruges til at hæve. Men der er en skarp undtagelse: ntoskrnl.eks:

det er rigtigt, kan superbrugere erstatte eller ændre vinduer’ core operativsystem fil. Fem sekunder efter, at filen er ændret, erstatter den dog med en sikkerhedskopi, den henter i de fleste tilfælde fra \vinduer\System32\dllcache. Strømbrugere har ikke skriveadgang til filer i Dllcache, så det kan ikke undergrave sikkerhedskopien. Men medlemmer af Superbrugergruppen kan omgå VFP ved at skrive et simpelt program, der erstatter filen, skyller de ændrede data til disken og genstarter derefter systemet, før VFP griber ind.
jeg bekræftede, at denne tilgang fungerer, men spørgsmålet forblev om, hvordan denne sårbarhed kan bruges til at hæve privilegiet. Svaret er lige så let som at bruge en disassembler til at finde den funktion, som vinduer bruger til privilegiekontrol , SeSinglePrivilegeCheck og lappe dets indgangspunkt i diskbilledet, så det altid returnerer TRUE, hvilket er resultatkoden, der angiver, at en bruger har det privilegium, der kontrolleres for. Når en bruger kører på en kerne, der er ændret på denne måde, ser de ud til at have alle privilegier, herunder Load Driver, tage ejerskab og oprette Token, for blot at nævne nogle få af de privilegier, som de let kan udnytte til at tage fuld administrativ kontrol over et system. Selvom 64-bit vinduer forhindrer kerne manipulation med PatchGuard, kører få virksomheder på 64-bit vinduer.
Udskiftning Ntoksrnl.det er dog ikke den eneste måde at slå igennem til administrativt privilegium via mappen \vinduer. Mindst en af de DLL ‘ er, for hvilke standardtilladelser tillader ændring af strømbruger, Schedsvc.dll, kører som en vinduer tjeneste i det lokale system konto. Schedsvc.dll er den DLL, der implementerer tjenesten vinduer Task Scheduler. Vinduer kan fungere med succes uden tjenesten, så strømbrugere kan erstatte DLL med en vilkårlig DLL, såsom en, der blot tilføjer deres konto til den lokale administratorgruppe. Selvfølgelig beskytter VFP også denne fil, så udskiftning af den kræver brug af den VFP-bypass-teknik, jeg har beskrevet.
jeg havde allerede identificeret flere højdevektorer, men fortsatte min undersøgelse ved at se på Strømbrugernes adgang til \Program Files-mappen, hvor jeg fandt standardtilladelser svarende til dem i \vinduer-mappen. Strømbrugere kan oprette undermapper under \ Program Files, men kan ikke ændre de fleste af de forudinstallerede vinduer komponenter. Igen undtagelserne, som vinduer Messenger (\Program Files\Messenger \ Msmgs.medieafspiller (\programfiler \ vinduer medieafspiller\Mmplayer.Kør interaktivt.
det betyder ikke, at \Program Files ikke har potentielle huller. Da jeg undersøgte den seneste udgang, så jeg, at strømbrugere kan ændre enhver fil eller mappe oprettet i \Programfiler efter dem, der blev oprettet under basevinduernes installation. På min test system \Program Files\Vmware\Vmware Tools\Vmwareservice.F. eks, billedfilen for tjenesten, der kører på den lokale systemkonto, var sådan en fil. Et andet lidt ironisk eksempel er Microsoft Defender Beta 2, som installerer sin service eksekverbar i \Program Files\Defender med standard sikkerhedsindstillinger. Udskiftning af disse servicebilledfiler er en hurtig vej til administratorrettigheder og er endnu nemmere end at erstatte filer i mappen, fordi VFP ikke blander sig med udskiftninger.
næste jeg vendte min opmærksomhed til registreringsdatabasen ved at køre denne kommando:
accesschk –sk “strømbrugere” hklm
outputlisten var enorm, fordi strømbrugere har skriveadgang til langt størstedelen af HKLM\ – programnøglen. Det første område, jeg studerede for mulige højder, var HKLM\systemnøgle, fordi skriveadgang til mange indstillinger under den, f.eks. Analysen afslørede, at strømbrugere ikke har skriveadgang til noget væsentligt under denne nøgle.
de fleste af de superbrugere-skrivbare områder under den anden store gren af HKLM, program, relateret til internet opdagelsesrejsende, opdagelsesrejsende og dens fil foreninger, og strømstyring konfiguration. Kør, så de kan konfigurere vilkårlige eksekverbare filer til at køre, når nogen logger på interaktivt, men at udnytte dette kræver en bruger med administrativt privilegium at logge ind på systemet interaktivt (hvilket afhængigt af systemet måske aldrig sker eller sker sjældent). Og ligesom for \Program Files-mappen har superbrugere standardskrivningsadgang til undernøgler, der ikke er vinduer, hvilket betyder, at tredjepartsapplikationer, der konfigurerer eksekverbare kodestier i deres systemdækkende registreringsdatabasenøgler, kunne åbne sikkerhedshuller. Det eneste program, der er installeret på systemet, gjorde det ikke.
det resterende område af udforskning var vinduer tjenester. De eneste servicetilladelser, AccessChk anser for at være skriveadgang, er SERVICE_CHANGE_CONFIG og SKRIVE_DAC. En bruger med SERVICE_CHANGE_CONFIG kan konfigurere en vilkårlig eksekverbar til at starte, når en tjeneste starter og givet SKRIVE_DAC de kan ændre tilladelserne på en tjeneste til at give sig selv SERVICE_CHANGE_CONFIG adgang. AccessChk afslørede følgende på mit lager vinduer SP2 system:

jeg kørte næste PsService for at se den konto, hvor dcomlaunch-tjenesten udfører:

således kan medlemmer af Superbrugergruppen simpelthen ændre billedstien til DComLauncher for at pege på deres eget billede, genstarte systemet og nyde administrative privilegier.
der kan potentielt være andre tjenester, der introducerer udnyttelser i deres sikkerhed. Standardtilladelsesvinduessættene på tjenester, der er oprettet af tredjepartsapplikationer, tillader ikke strømbrugere skriveadgang, men nogle tredjepartsapplikationer konfigurerer muligvis brugerdefinerede tilladelser, så de kan gøre det. Faktisk afslører 64-bit installation AccessChk på min produktion et hul, som ikke kun strømbrugere kan bruge til at hæve sig selv, men som begrænsede brugere også kan:

jeg var nu færdig med den store fase af min undersøgelse og bekræftede lige, hvad alle har sagt: et bestemt medlem af Superbrugergruppen kan forholdsvis let gøre sig fuld administrator ved hjælp af udnyttelser i operativsystemet og dem, der er oprettet af tredjepartsapplikationer.
mit sidste skridt var at se, hvordan Microsofts tilgang til Superbrugerkontoen har udviklet sig over tid. Denne 1999 Microsoft vidensbase artikel dokumenterer den berømte pauseskærm elevation sårbarhed, der eksisterede på vinduer NT 4, men Microsoft lukkede hullet før udgivelsen af vinduer 2000. KB-artiklen viser også, at Microsoft tilsyneladende ikke var opmærksom på andre sårbarheder, der sandsynligvis eksisterede. Vinduer 2000 SP4 inkluderer også huller, men er faktisk lidt mere sikker end standardvinduernes SP2-konfiguration: strømbrugere har ikke skriveadgang til Ntoskrnl.i stedet for skriveadgang til dcomlauncher-tjenesten kan de undergrave VMI-tjenesten, som også kører på den lokale systemkonto.
SP1 tilføjede flere Strømbrugeres svagheder, herunder skriveadgang til kritiske systemfiler som Svchost.der er også mulighed for at benytte sig af de tjenester, der kan udnyttes. Flere tjenester tillod endda begrænsede brugere at hæve som beskrevet i denne Microsoft KB-artikel fra marts i år.
Microsofts nyeste operativsystem, Vinduer Vista, lukker alle de sårbarheder, jeg har beskrevet ved at neutralisere strømbrugere, så det opfører sig identisk med begrænsede brugere. Microsoft har således lukket døren for strømbrugere for at tvinge IT-medarbejdere til at sikre deres systemer ved at flytte brugere til begrænsede brugerkonti eller til administrative konti, hvor de skal anerkende slutbrugerkontrol over deres systemer.
den nederste linje er, at mens Microsoft kunne løse de sårbarheder, jeg fandt i min undersøgelse, kan de ikke forhindre tredjepartsapplikationer i at introducere nye, samtidig med at de bevarer Strømbrugernes evne til at installere applikationer og activeks-kontroller. Lektionen er, at du som IT-administrator ikke bør narre dig selv til at tro, at Superbrugergruppen er et sikkert kompromis på vej til at køre som begrænset bruger.

oprindeligt af Mark Russinovich den 5/1/2006 11: 01: 00
migreret fra original Sysinternals.com/Blog