Die Macht der Power-User

Erstmals im Mai auf TechNet veröffentlicht 01, 2006

Das Platzieren von Windows-Benutzerkonten in der Sicherheitsgruppe Hauptbenutzer ist ein gängiger Ansatz von IT-Organisationen, um Benutzer in eine Umgebung mit den geringsten Berechtigungen zu bringen und gleichzeitig die vielen Probleme zu vermeiden, die mit der tatsächlichen Ausführung als eingeschränkter Benutzer verbunden sind. Die Gruppe Hauptbenutzer kann Software installieren, Energie- und Zeitzoneneinstellungen verwalten und ActiveX-Steuerelemente installieren, Aktionen, die eingeschränkten Benutzern verweigert werden.
Was viele Administratoren jedoch nicht erkennen, ist, dass diese Macht auf den Preis einer echten eingeschränkten Benutzersicherheit geht. Viele Artikel, darunter dieser Microsoft Knowledge Base-Artikel und dieser Blogbeitrag des Microsoft-Sicherheitsspezialisten Jesper Johansen, weisen darauf hin, dass ein Benutzer, der zur Gruppe der Hauptbenutzer gehört, sich leicht zu vollberechtigten Administratoren erheben kann. Ich beschloss daher, zu untersuchen.
Bevor ich mit der Untersuchung beginnen konnte, musste ich das Problem definieren. In Ermangelung einer Sicherheitslücke, z. B. eines Pufferüberlaufs, ist eine Eskalation von Berechtigungen nur möglich, wenn ein Konto beliebigen Code für die Ausführung im Kontext eines privilegierteren Kontos konfigurieren kann. Zu den Standardkonten mit mehr Berechtigungen als Hauptbenutzern gehören Administratoren und das lokale Systemkonto, in dem mehrere Windows-Dienstprozesse ausgeführt werden. Wenn ein Hauptbenutzermitglied eine von einem dieser Konten ausgeführte Datei ändern, eine seiner ausführbaren Dateien zum Laden einer beliebigen DLL konfigurieren oder diesen Konten einen ausführbaren Autostart hinzufügen kann, kann es vollständige Administratorrechte erhalten.
Mein erster Schritt bestand darin, zu sehen, auf welche Dateien und Verzeichnisse die Gruppe der Hauptbenutzer Schreibzugriff hat, die eingeschränkten Benutzer jedoch nicht. Die Systeme, die ich in Betracht zog, waren Windows 2000 Professional SP4, Windows XP SP2 und Windows Vista. Ich werde mir nicht die Mühe machen, Serversysteme zu betrachten, da sich das häufigste Power-User-Szenario auf einer Workstation befindet.
Die Brute-Force-Methode, um zu sehen, welche Dateisystemobjekte Power-User ändern können, erfordert den Besuch jeder Datei und jedes Verzeichnisses und die Prüfung ihrer Berechtigungen, was eindeutig nicht praktikabel ist. Das Befehlszeilen-Cacls-Dienstprogramm, das Windows enthält, gibt Sicherheitsdeskriptoren aus, aber ich habe mir nie die Mühe gemacht, Security Descriptor Description Language (SDDL) zu lernen, und das Analysieren der Ausgabe würde das Schreiben eines Skripts erfordern. Das AccessEnum-Dienstprogramm, das Bryce geschrieben hat, schien vielversprechend zu sein und es kann auch die Registrierungssicherheit betrachten, aber es zielt darauf ab, potenzielle Berechtigungsschwächen aufzuzeigen, nicht die Zugriffe, die für bestimmte Konten verfügbar sind. Außerdem wusste ich, dass ich auch die Sicherheit für Windows-Dienste untersuchen musste.

Ich kam zu dem Schluss, dass ich ein neues Dienstprogramm für den Job schreiben musste, also erstellte ich AccessChk . Sie übergeben AccessChk einen Konto- oder Gruppennamen und einen Dateisystempfad, Registrierungsschlüssel oder Windows-Dienstnamen, und es werden die effektiven Zugriffe des Kontos oder der Gruppe auf das Objekt unter Berücksichtigung der Gruppenmitgliedschaften des Kontos gemeldet. Wenn das Mark-Konto beispielsweise Zugriff auf eine Datei hatte, Mark jedoch zu der Entwicklergruppe gehört, der der Zugriff explizit verweigert wurde, würde AccessChk Mark als keinen Zugriff anzeigen.
Um die Ausgabe lesbar zu machen, druckt AccessChk ‘W’ neben dem Objektnamen, wenn ein Konto über Berechtigungen verfügt, die es ihm ermöglichen, ein Objekt zu ändern, und ‘R’, wenn ein Konto die Daten oder den Status des Objekts lesen kann. Verschiedene Schalter bewirken, dass AccessChk in Unterverzeichnisse oder Registrierungsunterschlüssel zurückkehrt, und der Schalter –v meldet die spezifischen Zugriffe, die dem Konto zur Verfügung stehen. Ein Schalter, den ich speziell hinzugefügt habe, um Objekte zu suchen, für die ein Konto Schreibzugriff hat, ist –w.
Bewaffnet mit diesem neuen Tool war ich bereit, mit der Untersuchung zu beginnen. Mein erstes Ziel war eine Windows XP SP2 VMware-Installation, auf der außer den VMware Tools keine anderen Anwendungen installiert sind. Der erste Befehl, den ich ausgeführt habe, war:
accesschk -ws “power users” c:\windows
Hier werden alle Dateien und Verzeichnisse im Verzeichnis \Windows angezeigt, die von der Gruppe Hauptbenutzer geändert werden können. Natürlich sind viele der Dateien unter \ Windows Teil des Betriebssystems oder der Windows-Dienste und werden daher im lokalen Systemkonto ausgeführt. AccessChk berichtete, dass Hauptbenutzer die meisten Verzeichnisse unter \ Windows ändern können, sodass Mitgliedsbenutzer Dateien in diesen Verzeichnissen erstellen können. Daher kann ein Mitglied der Gruppe Hauptbenutzer Dateien im Verzeichnis \ Windows und \ Windows \ System32 erstellen, was eine häufige Anforderung schlecht geschriebener Legacy-Anwendungen ist. Darüber hinaus müssen Hauptbenutzer in der Lage sein, Dateien im Verzeichnis \ Windows \ Downloaded Program Files zu erstellen, damit sie ActiveX-Steuerelemente installieren können, da Internet Explorer sie in diesem Verzeichnis speichert. Das einfache Erstellen einer Datei in diesen Verzeichnissen ist jedoch kein Pfad zur Erhöhung von Berechtigungen.
Obwohl Hauptbenutzer Dateien unter \Windows und den meisten seiner Unterverzeichnisse erstellen können, konfiguriert Windows Standardsicherheitsberechtigungen für die meisten Dateien in diesen Verzeichnissen, sodass nur Mitglieder der Gruppe Administratoren und des lokalen Systemkontos Schreibzugriff haben. Ausnahmen sind die Schriftdateien (.fon), viele System-Log-Dateien (.log), einige Hilfedateien (.chm), Bilder und Audioclips (.jpg, .gif, und .wmv) und Installationsdateien (.inf), aber keine dieser Dateien kann geändert oder ersetzt werden, um Administratorrechte zu erhalten. Die Gerätetreiber in \ Windows \ System32 \ Drivers würden eine einfache Eskalation ermöglichen, aber Power-User haben keinen Schreibzugriff auf einen von ihnen.

Ich habe einige gesehen .exe’s und .dlls in der Liste, also habe ich sie auf mögliche Exploits untersucht. Die meisten ausführbaren Dateien, für die Hauptbenutzer Schreibzugriff haben, sind interaktive Dienstprogramme oder werden mit reduzierten Berechtigungen ausgeführt. Sofern Sie einen Administrator nicht dazu verleiten können, sich interaktiv am System anzumelden, können diese nicht zum Erhöhen verwendet werden. Aber es gibt eine eklatante Ausnahme: ntoskrnl.exe:

Richtig, Power-User können die Kernbetriebssystemdatei von Windows ersetzen oder ändern. Fünf Sekunden nach der Änderung der Datei ersetzt Windows File Protection (WFP) sie jedoch durch eine Sicherungskopie, die in den meisten Fällen aus \ Windows \ System32 \ Dllcache abgerufen wird. Hauptbenutzer haben keinen Schreibzugriff auf Dateien in Dllcache, sodass die Sicherungskopie nicht untergraben werden kann. Mitglieder der Gruppe der Hauptbenutzer können WFP jedoch umgehen, indem sie ein einfaches Programm schreiben, das die Datei ersetzt, die geänderten Daten auf die Festplatte leert und das System neu startet, bevor WFP Maßnahmen ergreift.
Ich habe überprüft, dass dieser Ansatz funktioniert, aber es blieb die Frage, wie diese Sicherheitsanfälligkeit zum Erhöhen von Berechtigungen verwendet werden kann. Die Antwort ist so einfach wie die Verwendung eines Disassemblers, um die Funktion zu finden, die Windows für Berechtigungsprüfungen verwendet, SeSinglePrivilegeCheck , und den Einstiegspunkt im Image auf der Festplatte so zu patchen, dass immer TRUE zurückgegeben wird. Sobald ein Benutzer auf einem auf diese Weise modifizierten Kernel ausgeführt wird, scheint er über alle Berechtigungen zu verfügen, einschließlich Load Driver, Take Ownership und Create Token, um nur einige der Berechtigungen zu nennen, die er leicht nutzen kann, um die vollständige administrative Kontrolle über ein System zu übernehmen. Obwohl 64-Bit-Windows XP Kernel-Manipulationen mit PatchGuard verhindert , laufen nur wenige Unternehmen auf 64-Bit-Windows.
Ersetzen Ntoksrnl.exe ist jedoch nicht die einzige Möglichkeit, über das Verzeichnis \ Windows auf Administratorrechte zuzugreifen. Mindestens eine der DLLs, für die Standardberechtigungen Änderungen durch Hauptbenutzer zulassen, Schedsvc.dll, läuft als Windows-Dienst im lokalen Systemkonto. Schedsvc.dll ist die DLL, die den Windows Task Scheduler-Dienst implementiert. Windows kann ohne den Dienst erfolgreich ausgeführt werden, sodass Hauptbenutzer die DLL durch eine beliebige DLL ersetzen können, z. B. eine, die ihr Konto einfach der lokalen Administratorengruppe hinzufügt. Natürlich schützt WFP auch diese Datei, so dass das Ersetzen die Verwendung der von mir beschriebenen WFP-Bypass-Technik erfordert.

Ich hatte bereits mehrere Höhenvektoren identifiziert, setzte meine Untersuchung jedoch fort, indem ich mir den Zugriff von Hauptbenutzern auf das Verzeichnis \ Programme ansah, in dem ich Standardberechtigungen ähnlich denen im Verzeichnis \ Windows fand. Hauptbenutzer können Unterverzeichnisse unter \ Programme erstellen, die meisten vorinstallierten Windows-Komponenten jedoch nicht ändern. Auch hier die Ausnahmen, wie Windows Messenger (\ Programme \ Messenger\Msmgs.exe) und Windows Media Player (\ Programme\Windows Media Player\Wmplayer.exe) interaktiv ausführen.
Das bedeutet nicht, dass \Program Files keine potenziellen Löcher hat. Als ich die neueste Ausgabe untersuchte, sah ich, dass Hauptbenutzer jede Datei oder jedes Verzeichnis ändern können, die in \Program Files nach denen erstellt wurden, die während der Windows-Basisinstallation erstellt wurden. Auf meinem Testsystem \ Programme \ Vmware \ Vmware Tools \ Vmwareservice.exe, die Image-Datei für den Vmware Windows-Dienst, der im lokalen Systemkonto ausgeführt wird, war eine solche Datei. Ein weiteres etwas ironisches Beispiel ist Microsoft Windows Defender Beta 2, das seine ausführbare Dienstdatei in \ Programme \ Windows Defender mit Standardsicherheitseinstellungen installiert. Das Ersetzen dieser Dienstabbilddateien ist ein schneller Pfad zu Administratorrechten und noch einfacher als das Ersetzen von Dateien im Verzeichnis \ Windows, da WFP sich nicht in Ersetzungen einmischt.
Als nächstes wandte ich meine Aufmerksamkeit der Registrierung zu, indem ich diesen Befehl ausführte:
accesschk –swk “power users” hklm
Die Ausgabeliste war enorm, da Power Users Schreibzugriff auf die überwiegende Mehrheit des HKLM \ Software-Schlüssels hat. Der erste Bereich, den ich auf mögliche Erhöhungen untersucht habe, war der Schlüssel HKLM \ System , da der Schreibzugriff auf viele darunter liegende Einstellungen, z. B. die Windows-Dienst- und Treiberkonfigurationsschlüssel in HKLM \ System \ CurrentControlSet \ Services, eine triviale Subversion des lokalen Systems ermöglichen würde Konto. Die Analyse ergab, dass Power-User unter diesem Schlüssel keinen Schreibzugriff auf etwas Wesentliches haben.
Die meisten Power-User-beschreibbare Bereiche unter dem anderen großen Zweig der HKLM, Software, im Zusammenhang mit Internet Explorer, Explorer und seine Dateizuordnungen und Power-Management-Konfiguration. Hauptbenutzer haben auch Schreibzugriff auf HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, sodass sie beliebige ausführbare Dateien so konfigurieren können, dass sie ausgeführt werden, wenn sich jemand interaktiv anmeldet. Und genau wie für das Verzeichnis \ Programme hat Power-User standardmäßig Schreibzugriff auf Nicht-Windows-Unterschlüssel von HKLM \ Software, was bedeutet, dass Anwendungen von Drittanbietern, die ausführbare Codepfade in ihren systemweiten Registrierungsschlüsseln konfigurieren, Sicherheitslücken öffnen können. VMware, die einzige auf dem System installierte Anwendung, nicht.

Der verbleibende Erkundungsbereich waren Windows-Dienste. Die einzigen Dienstberechtigungen, die AccessChk als Schreibzugriffe betrachtet, sind SERVICE_CHANGE_CONFIG und WRITE_DAC. Ein Benutzer mit SERVICE_CHANGE_CONFIG kann eine beliebige ausführbare Datei so konfigurieren, dass sie beim Start eines Dienstes gestartet wird, und mit WRITE_DAC die Berechtigungen für einen Dienst ändern, um sich den Zugriff auf SERVICE_CHANGE_CONFIG zu gewähren. AccessChk enthüllte Folgendes auf meinem Standard-Windows XP SP2-System:

Als nächstes habe ich PsService ausgeführt, um das Konto anzuzeigen, in dem der DcomLaunch-Dienst ausgeführt wird:

So können Mitglieder der Gruppe der Hauptbenutzer einfach den Image-Pfad von DComLauncher so ändern, dass er auf ihr eigenes Image verweist, das System neu starten und Administratorrechte genießen.
Es kann möglicherweise andere Dienste geben, die Exploits in ihre Sicherheit einführen. Die Standardberechtigungen, die Windows für Dienste festlegt, die von Drittanbieteranwendungen erstellt wurden, erlauben keinen Schreibzugriff für Hauptbenutzer, aber einige Drittanbieteranwendungen konfigurieren möglicherweise benutzerdefinierte Berechtigungen, damit sie dies tun können. In der Tat, auf meiner Produktion 64-Bit-Windows XP-Installation AccessChk zeigt ein Loch, das nicht nur Power-User verwenden können, um sich zu erhöhen, aber das begrenzte Benutzer können auch:

Ich hatte jetzt die Hauptphase meiner Untersuchung abgeschlossen und gerade bestätigt, was alle gesagt haben: Ein entschlossenes Mitglied der Gruppe der Hauptbenutzer kann sich ziemlich leicht zum vollständigen Administrator machen Exploits im Betriebssystem und solche, die von Anwendungen von Drittanbietern erstellt wurden.
Mein letzter Schritt war zu sehen, wie sich Microsofts Ansatz für das Hauptbenutzerkonto im Laufe der Zeit entwickelt hat. Dieser Microsoft Knowledge Base-Artikel aus dem Jahr 1999 dokumentiert die berühmte Sicherheitsanfälligkeit bei der Erhöhung des Bildschirmschoners, die unter Windows NT 4 bestand, aber Microsoft hat diese Lücke vor der Veröffentlichung von Windows 2000 geschlossen. Der KB-Artikel zeigt auch, dass Microsoft anscheinend keine anderen Sicherheitslücken kannte, die wahrscheinlich bestanden. Windows 2000 SP4 enthält ebenfalls Löcher, ist jedoch etwas sicherer als die Standardkonfiguration von Windows XP SP2: Hauptbenutzer haben keinen Schreibzugriff auf Ntoskrnl.exe oder die Taskplaner-Image-Datei, aber anstelle des Schreibzugriffs auf den DComLauncher-Dienst können sie den WMI-Dienst untergraben, der auch im lokalen Systemkonto ausgeführt wird.
Windows XP SP1 fügte mehr Power-User-Schwachstellen hinzu, einschließlich Schreibzugriff auf kritische Systemdateien wie Svchost.exe, der Windows-Dienst-Hosting-Prozess und zusätzliche Dienste, WMI und SSDPSRV, mit ausnutzbaren Berechtigungen. Mehrere Dienste ermöglichten sogar eingeschränkten Benutzern das Erhöhen, wie in diesem Microsoft KB-Artikel vom März dieses Jahres beschrieben.
Microsofts neuestes Betriebssystem, Windows Vista, schließt alle Sicherheitslücken, die ich beschrieben habe, indem es Power-User kastriert, so dass es sich identisch mit eingeschränkten Benutzern verhält. Microsoft hat daher die Tür für Power-User geschlossen, um IT-Mitarbeiter zur Sicherung ihrer Systeme zu zwingen, indem Benutzer in Konten mit eingeschränkten Benutzern oder in Verwaltungskonten verschoben werden, in denen sie die Kontrolle des Endbenutzers über ihre Systeme anerkennen müssen.
Die Quintessenz ist, dass Microsoft zwar die Sicherheitsanfälligkeiten beheben konnte, die ich in meiner Untersuchung gefunden habe, aber nicht verhindern kann, dass Anwendungen von Drittanbietern neue einführen, während gleichzeitig die Fähigkeit von Hauptbenutzern erhalten bleibt, Anwendungen und ActiveX-Steuerelemente zu installieren. Die Lektion ist, dass Sie sich als IT-Administrator nicht vormachen sollten, dass die Gruppe der Hauptbenutzer ein sicherer Kompromiss auf dem Weg zur Ausführung als eingeschränkter Benutzer ist.

Ursprünglich von Mark Russinovich am 5/1/2006 11:01:00 AM
Migriert vom Original Sysinternals.com/Blog