l3cr0f/dccwbypassuacWindows 8.1 und 10 UAC-Bypass durch Missbrauch von WinSxS in "dccw.exe".
Dieser Exploit missbraucht die Art und Weise, wie "WinSxS" von "dccw.exe" verwaltet wird, mithilfe einer abgeleiteten Methode von Leo Davidsons "Bypass UAC"-Methode, um eine Administratorshell zu erhalten, ohne zur Zustimmung aufzufordern. Er unterstützt die Architekturen "x86" und "x64". Darüber hinaus wurde er erfolgreich auf Windows 8.1 9600, Windows 10 14393, Windows 10 15031 und Windows 10 15062 getestet.
Wenn Sie sehen möchten, wie das Skript ausgeführt wird, werfen Sie einen Blick auf den Abschnitt Verwendung. Sie können es auch in Metasploit ausführen und eine Meterpreter-Sitzung mit Administratorrechten erhalten.
Um einen neuen Bypass UAC zu entwickeln, müssen wir zunächst eine Schwachstelle auf dem System finden und, genauer gesagt, eine Schwachstelle in einem Auto-Elevate-Prozess. Um eine Liste solcher Prozesse zu erhalten, verwendeten wir das Sysinternals-Tool namens Strings. Danach konnten wir einige Auto-Elevate-Prozesse wie "sysprep.exe", "cliconfig.exe", "inetmgr.exe", "consent.exe" oder "CompMgmtLauncher.exe" sehen, die Schwachstellen aufwiesen (einige von ihnen weisen sie immer noch auf), die die Ausführung eines "Bypass UAC" ermöglichen. Also begannen wir zu untersuchen, wie andere Auto-Elevate-Prozesse mit der Sysinternals-Anwendung namens Process Monitor (ProcMon) funktionierten, wobei wir uns auf den Prozess "dccw.exe" konzentrierten.
Bevor wir jedoch mit ProcMon begannen, überprüften wir zunächst das Manifest solcher Anwendungen mit einer anderen Sysinternals-Anwendung namens Sigcheck, und in unserem Fall ist "dccw.exe" natürlich ein Auto-Elevate-Prozess.
Dann konnten wir damit beginnen, den Ausführungsfluss von "dccw.exe" mit ProcMon zu verfolgen, um zu sehen, ob etwas Seltsames passiert, was wir sofort überprüften. Ab einem bestimmten Punkt sucht der Prozess, wenn wir "dccw.exe" als 64-Bit-Prozess auf einer 64-Bit-Windows-Maschine ausgeführt haben, im Verzeichnis "C:\Windows\System32\dccw.exe.Local\" nach einer bestimmten DLL namens "GdiPlus.dll", genauso als ob er auf einer 32-Bit-Windows-Maschine ausgeführt würde, während der Prozess, wenn wir ihn als 32-Bit-Prozess auf derselben Maschine ausführen, im Verzeichnis "C:\Windows\SysWOW64\dccw.exe.Local\" sucht. Da dieses Verzeichnis nicht existiert, sucht der Prozess immer nach einem Ordner im Pfad "C:\Windows\WinSxS\", um die gewünschte DLL zu erhalten. Dieser Ordner hat einen Namen mit der folgenden Struktur:
[architecture]_microsoft.windows.gdiplus_[sequencial_code]_[Windows_version]_none_[sequencial_number]
Wenn wir in das Verzeichnis "WinSxS" schauen, sehen wir mehr als einen Ordner, der dieser Struktur entspricht. Das bedeutet, dass "dccw.exe" die gewünschte DLL aus jedem dieser Ordner laden kann. Das Einzige, dessen wir uns sicher sind, ist, dass der Ordnername mit der Zeichenfolge "x86" beginnt, wenn die Anwendung als x86-Prozess aufgerufen wird, während er mit der Zeichenfolge "amd64" beginnt, wenn wir sie als x64-Prozess ausführen.
Diese Situation kann ausgenutzt werden, um DLL-Hijacking durchzuführen und anschließend Code mit hoher Integrität auszuführen, ohne zur Zustimmung aufzufordern.
Sobald wir einen Fehler während der Ausführung eines Auto-Elevate-Prozesses gefunden haben, müssen wir überprüfen, ob er ausgenutzt werden kann oder nicht. Dazu haben wir einfach den Ordner "dccw.exe.Local" im gewünschten Pfad erstellt und in diesem Ordner die Ordner aus "WinSxS" angelegt, die vom Prozess zum Laden von "GdiPlus.dll" aufgerufen werden könnten, jedoch ohne diese DLL.
Wenn wir nun "dccw.exe" ausführen, sehen wir, dass der Prozess den Ordner "dccw.exe.Local" und einen der "WinSxS"-Ordner gefunden hat, aber nicht die gewünschte DLL, was einen Fehler auslöst. Das haben wir erwartet, da diese Situation von einem Angreifer ausgenutzt werden kann, wie wir bereits erwähnt haben.
An diesem Punkt wissen wir bereits, dass wir mit dem Missbrauch von "dccw.exe" einen Bypass UAC auf Windows 10 durchführen können, aber wie?
Die am häufigsten verwendete Methode zur Umgehung von UAC ist die von Leo Davidson entwickelte. Sie führt jedoch eine Prozessinjektion durch, um das COM-Objekt IFileOperation aufzurufen, was von einigen Antivirenprogrammen erkannt werden kann. Ein besserer Ansatz ist die von Cn33liz in seinem eigenen Bypass UAC verwendete Methode namens Masquerade PEB.
Außerdem müssen wir die Art und Weise ändern, wie IFileOperation in neueren Windows-10-Versionen aufgerufen wird, da die Methode von Leo Davidson ab Build 15002 UAC auslöst. Die Art und Weise, wie wir diesen Vorgang aufrufen müssen, ist also dieselbe wie im Original, jedoch ohne die Operationsflags "FOF_SILENT", "FOFX_SHOWELEVATIONPROMPT" und "FOF_NOERRORUI".
Bevor wir den Exploit ausführen, ist es wichtig, einige Aspekte zu überprüfen, um ihn nicht erfolglos auszuführen und dadurch Alarme auszulösen. Als Erstes überprüfen wir die Windows-Build-Version, da einige Versionen nicht anfällig für unseren Exploit sind (diejenigen mit einer Build-Version niedriger als 7600). Danach stellen wir sicher, dass wir noch keine Administratorrechte haben; falls dies nicht der Fall ist, gibt es keinen Grund, das Skript auszuführen. Dann überprüfen wir die UAC-Einstellungen, um zu bestätigen, dass sie nicht auf "Always notify" gesetzt sind, denn wenn sie auf diesen Wert gesetzt wären, wäre unser Exploit nutzlos. Schließlich überprüfen wir, ob der Benutzer zur Gruppe der Administratoren gehört, denn wenn nicht, wäre der Exploit erfolglos.
Wenn ein Exploit entwickelt wird, ist es wichtig, dass er auf möglichst vielen Systemen funktioniert; das schließt 32-Bit-Windows-Systeme ein. Um dies zu erreichen, müssen wir unseren Exploit für solche Systeme kompilieren, da wir ihn auch auf 64-Bit-Systemen ausführen können.
Wenn unser 32-Bit-Exploit auf einer 64-Bit-Windows-Maschine ausgeführt wird, funktioniert "dccw.exe" etwas anders, da WOW64 aufgerufen wird (das Windows-Subsystem, das es 64-Bit-Maschinen ermöglicht, 32-Bit-Anwendungen auszuführen). Das bedeutet, dass der Ordner "dccw.exe.Local" im Verzeichnis "C:\Windows\SysWOW64\" gesucht wird, anstatt in "C:\Windows\System32\", aber auch die anvisierte "GdiPlus.dll" wird eine 32-Bit-DLL sein, was zur Folge hat, dass in einem Ordner gesucht wird, der dem Namensmuster "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" entspricht. Wird der Exploit jedoch auf einem 32-Bit-Windows-System ausgeführt, funktioniert er wie erwartet.
Schließlich ist es wichtig zu erwähnen, dass wir beim DLL-Hijacking alle Pfade berücksichtigen müssen, die dem Muster "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" entsprechen, um eine 100%ige Wirksamkeit sicherzustellen.
Um einen Prozess mit hoher Integrität auszuführen, müssen wir eine DLL entwickeln, die per DLL-Hijacking aufgerufen wird. Das ist jedoch nicht so einfach, wie es aussieht, denn wenn wir nur das tun, werden weder "dccw.exe" noch unser Code ausgeführt. Das liegt daran, dass "dccw.exe" von einigen Funktionen der "GdiPlus.dll" abhängt. Daher müssen wir die Ausführung dieser Funktionen entweder implementieren oder an die legitime DLL weiterleiten.
Die beste Option ist, die Ausführung an die legitime DLL weiterzuleiten, da auf diese Weise die Größe unserer DLL geringer ist. Dazu haben wir das Programm ExportsToC++ verwendet, um alle Exporte der "GdiPlus.dll" in die Sprache C++ zu portieren. Nun besteht das Problem in der großen Anzahl von Exporten, die "GdiPlus.dll" besitzt, um genau zu sein 631. Dennoch importiert "dccw.exe" nicht alle, sondern nur einige. Um herauszufinden, welche Funktionen von "dccw.exe" aus "GdiPlus.dll" importiert werden, haben wir sie mit "IDA Pro" per Reverse Engineering analysiert. Letztendlich werden nur 15 Funktionen aus "GdiPlus.dll" importiert, sodass wir nur diese in unsere DLL aufnehmen müssen.
Nun scheint das Problem gelöst zu sein, aber wenn wir die Ausführung an eine bestimmte "GdiPlus.dll" in C:\Windows\WinSxS\" weiterleiten, funktioniert die DLL nur auf einigen Systemen, da sich der Name der internen Ordner von "WinSxS" bei jedem Windows-Build ändert. Um dieses Problem zu überwinden, kamen wir auf die Idee, die Ausführung an "C:\Windows\System32\GdiPlus.dll" weiterzuleiten, da dieser Pfad auf allen Windows-10-Systemen derselbe ist.
Das Letzte, was wir tun müssen, ist, die Ausführung von "dccw.exe" nach der Ausführung unseres schädlichen Codes zu stoppen, um das Öffnen des Fensters dieses Prozesses zu vermeiden.
Sobald wir unsere schädliche DLL entwickelt haben, müssen wir sie auf der Zielmaschine ablegen. Dazu wurde unsere DLL komprimiert und "base64"-kodiert in den Exploit eingebettet, sodass sie zur Laufzeit dekodiert und dekomprimiert werden kann, um sie wie erwartet abzulegen.
Schließlich wird unsere manipulierte "GdiPlus.dll" mithilfe des COM-Objekts IFileOperation an den Zielort kopiert, wie bereits erwähnt.
Wenn ein Angreifer ein System kompromittiert, möchte er so lange wie möglich unentdeckt bleiben; das bedeutet, jede Spur seiner Aktionen zu entfernen. Aus diesem Grund werden alle temporären Dateien, die während der Ausführung des Exploits erstellt werden, entfernt, sobald sie nicht mehr benötigt werden.
Schließlich müssen wir festlegen, welchen Prozess wir mit hoher Integrität ausführen möchten. In unserem Fall haben wir die Anwendung "cmd.exe" gewählt, da sie es uns ermöglicht, so viele Operationen mit hoher Integrität auszuführen, wie wir möchten, sobald wir Administratorrechte haben. Tatsächlich können wir jedoch jede beliebige Anwendung ausführen.
Um den Exploit auszuführen, müssen Sie sicherstellen, dass die Zielmaschine die Anforderungen erfüllt. Danach müssen Sie den Exploit einfach wie jedes andere Befehlszeilenskript ausführen:
C:\Users\L3cr0f> DccwBypassUAC.exe
Das Metasploit-Modul dieses PoC verwendet DLL-Injection anstelle von Masquerading PEB und ist verfügbar unter:
- Metasploit Framework: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbDieser Exploit wurde entwickelt, um zu zeigen, wie ein Angreifer Privilegien in einem System erlangen könnte, nicht um ihn für böswillige Zwecke zu verwenden. Das bedeutet, dass ich keinerlei Verantwortung übernehme, wenn jemand ihn für kriminelle Aktivitäten nutzt.
User Access Control (UAC) ist eine mit Windows Vista eingeführte Technologie, die eine Methode zur Trennung von Standardbenutzerrechten und -aufgaben von solchen bereitstellt, die Administratorzugriff erfordern. Wenn ein Standardbenutzer das System verwendet und versucht, eine Aktion auszuführen, für die er keine Autorisierung besitzt, erscheint eine Eingabeaufforderung von Windows und fragt nach dem Passwort des Administratorkontos. Wenn ein Administrator das System verwendet und versucht, dieselbe Aufgabe auszuführen, erscheint nur eine Warnmeldung. Diese Aufforderung ist als "Consent Prompt" bekannt, da der Administrator nur gebeten wird, der Aktion vor dem Fortfahren zuzustimmen. Eine Schwachstelle, die es erlauben würde, den "Consent Prompt" zu umgehen, gilt nicht als Sicherheitslücke, da diese nicht als Sicherheitsgrenze betrachtet wird.
Microsoft stellt außerdem fest, dass "User Account Control (UAC) eine grundlegende Komponente der gesamten Sicherheitsvision von Microsoft ist".
Quellen:
- Definition einer Sicherheitslücke.
- So funktioniert die Benutzerkontensteuerung.