the Power in Power Users

voor het eerst gepubliceerd op TechNet in mei 01, 2006

het plaatsen van Windows – gebruikersaccounts in de Power Users security group is een gemeenschappelijke aanpak IT-organisaties nemen om gebruikers in een minst-privilege omgeving, terwijl het vermijden van de vele pijnen van echt draaien als een beperkte gebruiker. De groep Power Users Kan software installeren, energie-en tijdzoneinstellingen beheren en ActiveX-besturingselementen installeren, acties die beperkte gebruikers worden geweigerd.
wat veel beheerders echter niet beseffen, is dat deze kracht ten koste gaat van echte beveiliging met beperkte gebruikers. Veel artikelen, met inbegrip van deze Microsoft Knowledge Base artikel en deze blog post van Microsoft security specialist Jesper Johansen, wijzen erop dat een gebruiker die behoort tot de Power Users groep kan zich gemakkelijk verheffen tot volledig geprivilegieerde beheerders, maar ik was niet in staat om een gedetailleerde beschrijving van de hoogte mechanismen ze verwijzen naar te vinden. Daarom besloot ik het te onderzoeken.
voordat ik met het onderzoek kon beginnen, moest ik het probleem definiëren. Bij afwezigheid van een beveiligingslek, zoals een buffer overflow privilege escalatie is alleen mogelijk als een account willekeurige code kan configureren om uit te voeren in de context van een meer bevoorrechte account. Tot de standaardaccounts met meer bevoegdheden dan Hoofdgebruikers behoren beheerders en het lokale systeemaccount, waarin verschillende Windows-serviceprocessen worden uitgevoerd. Dus als een lid van Power Users een bestand kan wijzigen dat door een van deze accounts wordt uitgevoerd, een van hun uitvoerbare bestanden kan configureren om een willekeurige DLL te laden, of een uitvoerbaar automatisch starten aan deze accounts kan toevoegen, kunnen ze volledige beheerdersrechten verkrijgen.
mijn eerste stap was om te zien welke bestanden en mappen de Power Users groep schrijftoegang heeft, maar dat beperkte gebruikers dat niet hebben. De systemen die ik beschouwd waren voorraad Windows 2000 Professional SP4, Windows XP SP2, en Windows Vista. Ik ben niet van plan om de moeite te kijken naar server systemen, omdat de meest voorkomende Power Users scenario is op een werkstation.
de brute force methode om te zien welke bestandssysteem objecten Power Users kunnen wijzigen vereist een bezoek aan elk bestand en Map en het onderzoeken van de rechten, iets dat duidelijk niet praktisch is. De command-line Cacls hulpprogramma dat Windows bevat dumps security descriptors, maar ik heb nooit de moeite genomen om te leren Security Descriptor Descriptor Language (SDDL) en het ontleden van de uitvoer zou vereisen het schrijven van een script. Het AccessEnum hulpprogramma dat Bryce schreef leek veelbelovend en het kan ook kijken naar de beveiliging van het register, maar het is gericht op het tonen van potentiële machtigingen zwakheden, niet de toegangen beschikbaar voor bepaalde accounts. Verder, Ik wist dat ik zou ook nodig hebben om de beveiliging toegepast op Windows-services te onderzoeken.

ik concludeerde dat ik een nieuw hulpprogramma voor de taak moest schrijven, dus heb ik AccessChk aangemaakt . U passeert een account-of groepsnaam en een bestandssysteem-pad, registersleutel of Windows-servicenaam en het rapporteert de effectieve toegang die het account of de groep heeft voor het object, rekening houdend met de groepslidmaatschappen van het account. Bijvoorbeeld, als het Mark-account toegang had tot een bestand, maar Mark behoort tot de Ontwikkelaarsgroep die expliciet toegang wordt geweigerd, dan zou AccessChk Mark tonen als geen toegang.
om de uitvoer gemakkelijk te kunnen lezen drukt AccessChk ‘ W ‘ af naast De objectnaam als een account machtigingen heeft die het mogelijk maken om een object te wijzigen, en ‘R’ als een account de gegevens of status van het object kan lezen. Verschillende schakelaars veroorzaken AccessChk te recurse in submappen of register subsleutels en de-v switch heeft het rapport van de specifieke toegangen beschikbaar voor de rekening. Een schakelaar die ik speciaal heb toegevoegd om objecten te zoeken waarvoor een account schrijftoegang heeft, is –w.
gewapend met deze nieuwe tool die ik klaar was om te onderzoeken. Mijn eerste doel was een Windows XP SP2 VMware installatie die geen geïnstalleerde applicaties anders dan de VMware Tools heeft. Het eerste commando dat ik uitvoerde was:
accesschk-ws “power users” c:\windows
dit toont alle bestanden en mappen onder de \ Windows-map die de groep Power Users kan wijzigen. Natuurlijk, veel van de bestanden onder \Windows zijn onderdeel van het besturingssysteem of Windows-services en daarom uit te voeren in de lokale systeemaccount. AccessChk meldde dat Power Users de meeste mappen onder \ Windows kunnen wijzigen, waardoor leden bestanden in die mappen kunnen maken. Zo kan een lid van de groep Power Users bestanden maken in de map \Windows en \Windows\System32, wat een veel voorkomende vereiste is voor slecht geschreven oudere toepassingen. Daarnaast moeten Power Users in staat zijn om bestanden te maken in de map\Windows \ Gedownloade programmabestanden, zodat ze ActiveX-besturingselementen kunnen installeren, omdat Internet Explorer ze opslaat in die map. Het eenvoudig aanmaken van een bestand in deze mappen is echter geen pad naar privilege elevation.
ondanks het feit dat ervaren gebruikers bestanden onder \Windows en de meeste submappen kunnen aanmaken, configureert Windows de standaard beveiligingsmachtigingen voor de meeste bestanden in deze mappen, zodat alleen leden van de groep Administrators en het lokale systeemaccount schrijftoegang hebben. Uitzonderingen zijn de lettertypebestanden (.fon), veel systeem logbestanden (.log), een aantal help-bestanden (.chm), foto ‘ s en audio clips (.jpg, .gif, en .wmv) en installatiebestanden (.inf), maar geen van deze bestanden kan worden gewijzigd of vervangen om beheerdersrechten te krijgen. De stuurprogramma ‘ s in \Windows\System32\Drivers zou gemakkelijk escalatie mogelijk te maken, maar Power Users heeft geen schrijftoegang tot een van hen.

ik zag een aantal .exe ‘ s en .dll staat in de lijst, dus ik heb ze onderzocht op mogelijke exploits. De meeste uitvoerbare bestanden waarvoor Power Users schrijftoegang heeft zijn interactieve hulpprogramma ‘ s of draaien met verminderde privileges. Tenzij je een beheerder kunt misleiden om interactief in te loggen op het systeem, kunnen deze niet worden gebruikt om te verheffen. Maar er is één opvallende uitzondering: ntoskrnl.exe:

dat klopt, Power Users kunnen vervangen of wijzigen Windows ‘ core Besturingssysteem bestand. Vijf seconden nadat het bestand is gewijzigd, echter, Windows File Protection (WFP) zal het vervangen door een back-up te halen, in de meeste gevallen, van \Windows\System32\Dllcache. Power Users heeft geen schrijftoegang tot bestanden in Dllcache, zodat het de back-up niet kan ondermijnen. Maar leden van de Power Users group kunnen WFP omzeilen door een eenvoudig programma te schrijven dat het bestand vervangt, de gewijzigde gegevens naar de schijf spoelt en het systeem opnieuw opstart voordat WFP actie onderneemt.
ik heb geverifieerd dat deze aanpak werkt, maar de vraag bleef hoe deze kwetsbaarheid kan worden gebruikt om privileges te verhogen. Het antwoord is net zo eenvoudig als het gebruik van een disassembler om de functie te vinden die Windows gebruikt voor privilege checks, SeSinglePrivilegeCheck , en het patchen van het ingangspunt in de on-disk image zodat het altijd TRUE retourneert, wat de resultaatcode is die aangeeft dat een gebruiker de privilege heeft waarop wordt gecontroleerd. Zodra een gebruiker draait op een kernel die op deze manier is aangepast, zullen ze alle privileges lijken te hebben, inclusief Load Driver, Take Ownership, en Create Token, om maar een paar van de privileges te noemen die ze gemakkelijk kunnen gebruiken om volledige administratieve controle over een systeem te nemen. Hoewel 64-bit Windows XP voorkomt dat de kernel knoeien met PatchGuard, weinig ondernemingen draaien op 64 – bit Windows.
Ter Vervanging Van Ntoksrnl.exe is niet de enige manier om punch door naar administratieve privileges via de \Windows-map, echter. Ten minste een van de DLL ‘ s waarvoor standaardmachtigingen wijziging door de hoofdgebruiker toestaan, Schedsvc.dll, wordt uitgevoerd als een Windows-service in het lokale systeemaccount. Schedsvc.dll is de DLL die de Windows Taakplanner service implementeert. Windows kan met succes werken zonder de service, zodat ervaren gebruikers de DLL kunnen vervangen door een willekeurige DLL, zoals een die gewoon hun account toevoegt aan de lokale groep Administrators. Natuurlijk, WFP beschermt dit bestand ook, dus het vervangen van het vereist het gebruik van de WFP-bypass techniek die ik heb beschreven.

ik had al een aantal elevatievectoren geà dentificeerd, maar zette mijn onderzoek voort door te kijken naar de toegang van ervaren gebruikers tot de map \Program Files waar ik standaardmachtigingen vond die vergelijkbaar zijn met die in de map \Windows. Power Users kunnen submappen maken onder \ programmabestanden, maar kan de meeste van de vooraf geïnstalleerde Windows-componenten niet wijzigen. Nogmaals, de uitzonderingen, zoals Windows Messenger (\Program Files\Messenger \ Msmgs.exe) en Windows Media Player (\programmabestanden\Windows Media Player \ Wmplayer.exe) interactief uitvoeren.
dat betekent niet dat \ Program Files geen potentiële gaten heeft. Toen ik de meest recente uitvoer onderzocht zag ik dat Power Users elk bestand of map gemaakt in \programma bestanden na die gemaakt tijdens de basis windows installeren kunnen wijzigen. Op mijn test systeem \ programmabestanden \ Vmware \ VMware Tools \ Vmwareservice.exe, het imagebestand voor de VMware Windows-service die wordt uitgevoerd in het lokale systeemaccount, was zo ‘ n bestand. Een ander enigszins ironisch voorbeeld is Microsoft Windows Defender Beta 2, die zijn dienst uitvoerbaar installeert in \ Program Files \ Windows Defender met standaard beveiligingsinstellingen. Het vervangen van deze service image bestanden is een snel pad naar administrator privilege en is nog gemakkelijker dan het vervangen van bestanden in de \Windows directory omdat WFP niet bemoeien met vervangingen.
vervolgens richtte ik mijn aandacht op het register door het volgende commando uit te voeren:
accesschk –swk “power users” hklm
de uitvoerlijst was enorm omdat Power Users schrijftoegang hebben tot het overgrote deel van de HKLM\Software key. Het eerste gebied dat ik bestudeerde voor mogelijke verhogingen was de HKLM \ System key, omdat schrijftoegang tot vele instellingen eronder, zoals de Windows service en driver configuration keys in HKLM \ System \ CurrentControlSet \ Services, triviale subversie van het lokale systeem account mogelijk zou maken. Uit de analyse bleek dat Power Users geen schrijftoegang hebben tot iets belangrijks onder die sleutel.
de meeste van de Power Users-schrijfbare gebieden onder de andere grote tak van HKLM, Software, gerelateerd aan Internet Explorer, Explorer en zijn bestand verenigingen, en energiebeheer configuratie. Power Users heeft ook schrijftoegang tot HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, waardoor ze willekeurige uitvoerbare bestanden kunnen configureren om te draaien wanneer iemand interactief inlogt, maar om dit te exploiteren moet een gebruiker met beheerdersrechten interactief inloggen op het systeem (wat, afhankelijk van het systeem, nooit of zelden gebeurt). En net als voor de map \Program Files, Power Users heeft standaard schrijftoegang tot niet-Windows-subsleutels van HKLM \ Software, wat betekent dat applicaties van derden die uitvoerbare code paden configureren in hun systeembrede registersleutels kunnen gaten in de beveiliging te openen. VMWare, de enige toepassing geïnstalleerd op het systeem, niet.

het resterende gebied van exploratie was Windows services. De enige service permissies die access beschouwt als schrijftoegang zijn SERVICE_CHANGE_CONFIG en WRITE_DAC. Een gebruiker met SERVICE_CHANGE_CONFIG kan een willekeurig uitvoerbaar bestand configureren om te starten wanneer een service start en gegeven WRITE_DAC kunnen ze de rechten op een service wijzigen om zichzelf SERVICE_CHANGE_CONFIG toegang te verlenen. AccessChk onthulde het volgende op mijn voorraad Windows XP SP2-systeem:

vervolgens liep ik psservice om het account te zien waarin de dcomlaunch-service wordt uitgevoerd:

leden van de groep Power Users kunnen dus eenvoudig het afbeeldingspad van DComLauncher wijzigen om naar hun eigen afbeelding te wijzen, het systeem opnieuw op te starten en beheerdersrechten te genieten.
er kunnen mogelijk andere diensten zijn die exploits in hun beveiliging introduceren. De standaardmachtigingen die Windows instelt op services die zijn gemaakt door toepassingen van derden staan niet toe dat ervaren gebruikers schrijftoegang hebben, maar sommige toepassingen van derden kunnen aangepaste machtigingen configureren om hen in staat te stellen dit te doen. In feite, op mijn productie 64-bit Windows XP installatie AccessChk onthult een gat dat niet alleen de macht gebruikers kunnen gebruiken om zichzelf te verheffen, maar dat beperkte gebruikers kunnen ook:

ik was nu klaar met de belangrijkste fase van mijn onderzoek en bevestigde net wat iedereen heeft gezegd: een vastberaden lid van de groep Power Users kan vrij gemakkelijk zichzelf volledig beheerder maken met behulp van exploits in het besturingssysteem en die gemaakt door applicaties van derden.
mijn laatste stap was om te zien hoe Microsoft ‘ s aanpak van de Power Users account is geëvolueerd in de tijd. Deze 1999 Microsoft Knowledge Base artikel documenteert de beroemde Screensaver hoogte kwetsbaarheid die bestond op Windows NT 4, maar Microsoft sloot dat gat voor de release van Windows 2000. Het KB artikel laat ook zien dat Microsoft blijkbaar niet op de hoogte was van andere kwetsbaarheden die waarschijnlijk bestonden. Windows 2000 SP4 bevat ook gaten, maar is eigenlijk iets veiliger dan de standaard Windows XP SP2 configuratie: Power Users hebben geen schrijftoegang tot Ntoskrnl.exe of het imagebestand van de Taakplanner, maar in plaats van schrijftoegang tot de dcomlauncher-service kunnen ze de WMI-service ondermijnen, die ook in het lokale systeemaccount wordt uitgevoerd.
Windows XP SP1 heeft meer zwakke punten voor Power Users toegevoegd, waaronder schrijftoegang tot kritieke systeembestanden zoals Svchost.exe, het Windows-servicehostproces en aanvullende services, WMI en SSDPSRV, met exploiteerbare machtigingen. Verschillende diensten zelfs toegestaan beperkte gebruikers te verheffen zoals beschreven in dit Microsoft KB artikel van maart van dit jaar.
Microsoft ‘ s nieuwste besturingssysteem, Windows Vista, sluit alle kwetsbaarheden die ik heb beschreven door het castreren van Power Users, zodat het zich identiek gedraagt aan beperkte gebruikers. Microsoft heeft dus de deur gesloten voor Power Users om te dwingen IT-medewerkers in het beveiligen van hun systemen door het verplaatsen van gebruikers in beperkte gebruikersaccounts of in administratieve accounts waar ze moeten erkennen eindgebruiker controle over hun systemen.
de bottom line is dat hoewel Microsoft de kwetsbaarheden die ik vond in mijn onderzoek kon oplossen, ze niet kunnen voorkomen dat toepassingen van derden van de invoering van nieuwe, terwijl tegelijkertijd het behoud van de mogelijkheid van ervaren gebruikers om applicaties en ActiveX-besturingselementen te installeren. De les is dat je als IT-beheerder jezelf niet voor de gek moet houden door te denken dat de groep Power Users een veilig compromis is op de weg naar het uitvoeren als beperkte gebruiker.

oorspronkelijk door Mark Russinovich op 5/1/2006 11:01:00 am
gemigreerd van origineel Sysinternals.com/Blog