Blog

Privilege Escalation für Administratoren

15.7.2021 | 10 minutes read
Share this:

Tags: Windows 10, Hardening

Note: Für alle hier genannten Tools gilt wie immer, Verwendung unter eigener Gefahr.

Einführung

Wie in meinem letzten Beitrag bereits erwähnt wurde, gehört zu einem sicheren Client mehr als nur das Ausrollen der Security Baseline von Microsoft oder einem Äquivalent von einem der anderen Stellen wie CIS oder BSI. In diesem Blogbeitrag möchte ich einmal die einfachsten bzw. häufigsten Wege aufzeigen, wie ein normaler Benutzer seine Rechte auf einem System erweitern kann.

Diese Rechteausweitung oder im englischen auch Privilege Escalation genannt, ist in der Regel die erste Aktivität, die ein Angreifer/Pentester durchführt, wenn er in einem Unternehmen auf einem System landet. Dazu stehen einer willigen Person in der Regel zahlreiche Möglichkeiten offen.

In diesem Blog Post werde ich die häufigsten Wege aufzeigen in der Hoffnung das Administratoren oder Mitarbeiter diesen Weg gehen, bevor es ein anderer tut.

Wege zur Rechteerweiterung

Patch

Der nach wie vor häufigste Weg, die Rechte auf einem System zu erweitern, besteht in der Ausnutzung bekannter Schwachstellen, sei es im Betriebssystem oder einer darauf installierten Anwendung. Neben den bekannten Schwachstellen-Scanner gibt es einige wenige Tools im Internet, die dabei helfen sollen, fehlende Sicherheitspatches aufzuspüren. Ich bin von deren Qualität nicht überzeugt und würde mich hier eher auf Reports aus den eingesetzten Verwaltungstools wie SCCM verlassen oder einen Schwachstellenscanner von einem etablierten Hersteller nehmen.

Falls doch jemand das Bedürfnis verspürt, eines der Tools, die es im Internet gibt einzusetzen, so sind wohl diese beiden Anwendungen gute Kandidaten:

Aber nun zu Schwachstellen, die nicht durch (oder nicht immer) durch einen Patch geschlossen werden können.

Klartext Passwörter

Ein weiterer Weg wie zur Rechteerweiterung sind Klartext Passwörter für höher privilegierte Accounts. Diese werden zum einen auf dem System selbst, beispielsweise in Konfig-Files, oder in größeren Umgebungen auf File-Shares leider noch zu häufig für alle lesbar abgespeichert.

Für eine schnelle Suche nach dem Keyword passw können Admins folgende Befehle verwenden:

findstr /si passw *.txt
findstr /si passw *.xml
findstr /si passw *.config
findstr /si passw *.ini

Um in der Registry nach nach passw zu suchen, können folgende Befehle verwendet werden:

reg query HKLM /f passw /t REG_SZ /s
reg query HKCU /f passw /t REG_SZ /s

Auch finden sich hin und wieder, wenn auch heute deutlich seltener als früher Passwortüberreste in den Dateien wie unattend.xml oder sysprep.inf. Eine nicht vollständige Liste mit Dateien, die Admins einmal nach Passwörtern absuchen sollten ist:

  • unattend.xml
  • web.config
  • sysprep.inf
  • sysprep.xml
  • vnc.ini

Eine größere Liste kann hier gefunden werden.

Ein Problem, mit dem Admins häufiger konfrontiert sind, ist, dass sie gar nicht wissen, welche File-Shares es im Unternehmen eigentlich gibt. Eine mögliche Lösung bietet hier das Skript PowerView an. PowerView wird zwar von den ursprünglichen Entwickler nicht mehr weiter entwickelt, dies hat nun BS-SECURITY im Rahmen der Weiterentwicklung von Empire übernommen. Eine aktuellere Version von Powerview findet ihr hier. Falls jemand eine noch aktuellere Version kennt, bitte melden.

DomainShare

Ein weiteres Tool zum Auffinden von File-Shares ist SharpShares.

SharpShares

Ein weiteres Hindernis beim Auffinden von Passwörtern sind Datei-Typen wie Excel oder Word, sie ihre Daten nicht im Klartext speichern und damit mit einfachen Befehlen durchsucht werden können. Ein Tool, das die Suche nach Passwörtern in verschiedenen Dateiarten erlaubt, ist SaunronsEye. Hier muss nur auf dem System mit dem gesucht wird Excel und Co vorhanden sein.

SauronsEye

Ein weiterer Ort an dem Angreifer wertvolle Informationen finden können, sind VHDX und VMDK Dateien. Diese Dateien enthalten die Festplatten von virtuellen Maschinen. Häufig lassen sich darin die Hashes vom lokalen Admin oder anderen lokalen Konten finden und anschließend auch verwenden. Mein persönliches Highlight war einmal die Festplatte von einem Domain Controller.

Zu guter Letzt seien noch Group Policy Preferences (GPP) zu erwähnen. Mithilfe dieser Art von Gruppenrichtlinien konnte unter anderem das Passwort vom lokalen Administrator Konto gesetzt werden. Das Problem ist, dass das so gesetzte Passwort mit einem bekannten AES Schlüssel verschlüsselt wurde. Damit ist das über GPP gesetzte Passwort für jeden Benutzer in der Domäne lesbar. Um ein über GPP gesetztes Passwort zu finden, kann folgende Suche verwendet werden.

findstr /S /I cpassword \\<DOMÄNE>\sysvol\<DOMÄNE>\policies\*.xml

Mithilfe eines Skripts, das auf Github zur Verfügung steht, kann das Passwort entschlüsselt werden. Weitere Informationen dazu findet ihr hier. Obwohl die Schwachstelle schon 2014 geschlossen wurde und seit dem es nicht mehr möglich ist Passwörter mit diesem Mechanismus zu verteilen, können die Überreste immer noch in so mancher Umgebung gefunden werden. Manchmal (sehr selten) sind die Passwörter auch noch gültig. Und wenn nicht für den ursprünglichen Benutzer, vielleicht für einen anderen.

Nach Passwörtern im Unternehmen zu suchen, ist auch eine schöne Aufgabe für Praktikaten und Azubis. Die werden hier erstaunlich kreativ.

Windows Dienste

Seid Anbeginn von Windows (zumindest seit der NT-Kernel verwendet wird) gibt es die Windows-Dienste. Nicht nur, dass sie im Hintergrund nützliche Dienste verrichten können, sie sind auch immer wieder ein Herd für Fehlkonfiguration. Dies kann in sofern fatal sein, als dass Dienste in Windows meist mehr Berechtigungen haben, als normaler Benutzer. Trotzdem möchte ich hier Anmerken, dass fehlerhafte Dienste immer seltener werden.

Diese Fehlkonfiguration kann von einem Angreifer oder auch einem Mitarbeiter, der mehr Rechte haben möchte, zu seinem Vorteil genutzt werden.

Schreibbare Servicekonfiguration

Der wohl häufigste Fehler sind nach wie vor die schreibbare Dienstekonfigurations-Objekte. Wie alles in Windows werden auch Dienste als Objekte repräsentiert, auf die ACLs angewendet werden können. Wenn hier bestimmte Berechtigungen an normale Benutzer vergeben werden, so können sie die Dienste nach ihren Bedürfnissen anpassen.

Berechtigung Auswirkung
SERVICE_ALL_ACCESS Vollzugriff
SERVICE_CHANGE_CONFIG Kann das Service Binary setzen
WRITE DAC Kann die Berechtigungen anpassen, siehe SERVICE_ALL_ACCESS
WRITE_OWNER Kann Besitzer werden und dadurch Berechtigungen anpassen
GENERIC_WRITE Gleich wie SERVICE_CHANGE_CONFIG
GENERIC_ALL Gleich wie SERVICE_CHANGE_CONFIG

Eine manuelle Suche nach problematischen Berechtigungen kann mit Accesschk aus den Windows Sysinternals durchgeführt werden.

accesschk.exe -uwcqv <Username> *

Tipp: Statt wie in vielen Anleitungen oder Guides Accesschk mit allerhand Gruppen auszuführen, nehmt einfach einen exemplarischen Benutzer, wie er bei euch in der Domäne “normal” vorkommt.

Schreibbare Servicepfade

Weitere Schwachstellen bei Diensten können die Dateien enthalten, die die Dienste starten. Hier treten in der Regel 2 Schwachstellen auf:

  1. Das Service-Binary selbst ist schreibbar
  2. Der Ordner in dem das Service-Binary liegt ist schreibar

Bei Ersterem kann ein Angreifer einfach das Service-Binary durch ein eigenes austauschen. Bei Zweiterem kann der Service anfällig sein für DLL Hijacking.
Bei der Suche nach derartigen Schwachstellen würde ich mich auf die Service konzentrieren, die nicht von Microsoft kommen.

Diese können beispielsweise mit folgendem PowerShell-Skript gefunden werden:

Get-wmiobject win32_service | where { $_.Caption -notmatch "Windows" -and $_.PathName -notmatch "Windows" -and
$_.PathName -notmatch "policyhost.exe" -and $_.Name -ne "LSM" -and $_.PathName -notmatch "OSE.EXE" -and 
$_.PathName -notmatch "OSPPSVC.EXE" -and $_.PathName -notmatch "Microsoft Security Client" -and 
$_.Name -notmatch "edgeupdate" -and $_.Name -notmatch "MicrosoftEdgeElevationService" -and
$_.Name -notmatch "NetSetupSvc" -and $_.Name -notmatch "uhssvc"} | select name, pathname

Das Skript ist von hier und wurde von mit angepasst auf Windows 10. Im Anschluss können die übrig gebliebene Pfade beispielsweise mittels Accesschk geprüft werden.

accesschk.exe -uw <Username> <Pfad>

Schreibbare Registry Keys

Windows speichert die Informationen über Dienste wie fast alles andere auch in der Registry. Die Dienste befinden sich unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Hier ist für jeden Dienst ein eigener Schlüssel abgelegt, zusammen mit den notwendigen Informationen wie ImagePath (PFad zur Exe/DLL) oder den Start-Modus. Wenn ein normaler Benutzer hier schreiben kann, so kann er analog zu oben, die Service-Binarys gegen eigenes Programm austauschen und damit seine Rechte erweitern. Für einen Check, ob hier alles in Ordnung ist, kann wieder Accesschk eingesetzt werden.

accesschk <Username> -kwsu hklm\SYSTEM\CurrentControlSet\Services

Unquoted Servicepaths

Unquoted Servicepaths habe ich in der Praxis schon häufig gesehen, allerdings konnte ich sie noch nie ausnutzten. Dabei geht es darum, ob der Binary-Pfad für einen Dienst in Hochkomma geschrieben ist oder nicht. Warum ist das relevant? Annahme der Servicepath ist: C:\Program Files\Some service\service.exe. Wenn dieser Wert nicht in Hochkomma geschrieben ist dann wird Windows versuchen den Dienst mit folgenden Befehlen zu starten:

  1. C:\Program.exe
  2. C:\Program Files\Some.exe
  3. C:\Program Files\Some service\service.exe

Wenn jetzt ein normaler Benutzer die Program.exe anlegen könnte, so würde diese ausgeführt werden. Zum Auffinden von Unquoted Servicepaths kann folgendes Skript verwendet werden.

gwmi -class Win32_Service -Property Name, DisplayName, PathName, StartMode | Where {$_.PathName -notlike "C:\Windows*" -and $_.PathName -notlike '"*'} | select PathName,DisplayName,Name

Das Skript stammt von hier.

Hinweise Dienste

Wenn ihr verhindern wollt, dass normale Benutzer Dienste enumerieren können, so müsst ihr den Zugriff auf den Pseudo-Dienst SCManager verhindern. Absolut ohne Gewähr, dass ihr dadurch keine Nachteile habt, aber eine Möglichkeit den Zugriff zu verhindern, ist mit folgendem Befehl:

sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-3698730060-278077788-3990600205)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Die original ACL vom SCMananger sieht wie folgt aus:

D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CC;;;S-1-15-3-1024-528118966-3876874398-709513571-1907873084-3598227634-3698730060-278077788-3990600205)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Ich habe den zweiten Access Control Entry aus der ACL entfernt, die den “Interactive Users” leserechte auf den SCManager gibt.

Scheduled Tasks

Scheduled Tasks sind automatische Aufgaben, die Windows entweder in Abhängigkeit von einer Benutzeranmeldung ausführen kann, die zeitgesteuert sind oder durch andere Trigger ausgelöst werden können. Im Grunde kann es bei Scheduled Tasks die gleichen Probleme wie bei Diensten geben. In seltenen Fällen kommt es vor, dass die Tasks entweder Programme ausführen, die nicht mehr da sind beispielsweise von einem Laufwerk, das nicht immer präsent ist oder ein Programm ausführen, dass durch den normalen Benutzer schreibbar ist.

Scheduled Tasks können mit folgendem PowerShell One-liner angezeigt werden.

Get-ScheduledTask | where {$_.TaskPath -notlike "\Microsoft*"}

Für eine umfassende Analyse bietet sich folgender Befehl an.

schtasks /query /V /FO CSV

Für diejenigen, die eine Benutzeroberfläche bevorzugen, empfehle ich autoruns aus den Sysinternals. Dies sollte als Administrator ausgeführt werden. Damit können Probleme wie verwaiste Einträge sehr leicht entdeckt werden.

Weitere CheatSheets

Für all die Administratoren die mehr über das Thema wissen wollen, hier mal eine Liste an guten CheatSheets zum Thema “Privilege Escalation” für Windows.

Tools

Ein Angreifer führt die oben genannten und weitere Prüfungen natürlich nicht manuell durch. In der Regel werden dafür extra geschrieben Skripte und Programme verwendet und ich bin der Meinung Administratoren oder auch Sicherheitsbeauftragten in einem Unternehmen sollten das auch tun. Darum hier mal eine Liste an OpenSource Projekten, ich dafür verwende und verwenden würde.

Die meisten hier genannten Tools werden von herkömmlichen AV Produkten als schadhaft markiert. Der Grund ist häufig aber mehr der Verwendungszweck als die Funktionen, die tatsächlich ausgeführt werden. Darum würde ich empfehlen einen Standard-Computer des Unternehmens zu nehmen, die Tools in ein vom AV ausgenommen Ordner zu legen und das System vom Netzwerk zu trennen. Im Anschluss können die Tools sicher verwendet werden und die ausgaben analysiert werden. Die Tools sollten dabei sowohl als Admin als auch als normaler Benutzer ausgeführt werden und die Ergebnisse verglichen werden. Das ist auch eine schöne Arbeit für interessierte Praktikanten oder Azubis.

Mutige Admins die ein wenig mehr Zeit in die Tools investieren wollen, können die Tools auch so auf ihren produktiv Systemen einsetzen. Bisher ist mir keines der genannten Tools negativ im Alltag aufgefallen. Ist aber auch nur meine Erfahrung.

WinPEAS

Das erste und meiner Meinung nach derzeit beste Tools ist WinPEAS. Es stammt von einem namenhaften Author, der auch hinter der Seite Hacktricks steht und wird aktiv entwickelt. Es gibt das Tool sowohl als BAT als auch als EXE, die allerdings selbst kompiliert werden muss. Was aber mit Visual Studio kein Problem ist. Das Tool ist für Pentester gedacht und hat einen klaren Fokus auf dem Auffinden von Schwachstellen.

Es kann hier heruntergeladen werden.

PrivescCheck

Ein weitere Skript ist PrivescCheck. Es ist meiner Meinung nach, der inoffizielle nachfolger von PowerUP und wird noch aktiv entwickelt. Auch mit diesem Skript habe ich sehr gute erfahrungen gemacht und es hilft dabei sehr viele Schwachstellen aufzudecken.

SeatBelt

Seatbelt geht etwas weiter als die beiden erst genannten Tools und gibt ein umfassendes Bild über ein System ab. Es enthält darüber hinaus weit mehr “Checks” auch wenn viele keinen direkten Weg zur Rechteerweiterung enthalten. Dennoch darf auch dieses Tool meiner Meinung nach in der Werkzeugkiste von sicherheitsbewussten Admins nicht fehlen.

Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.

Quellen