Auf einem Habr gibt es bereits
Neuigkeiten über diese Sicherheitslücke , aber leider ohne technische Details. Ich schlage vor, Sie schauen in das veröffentlichte
Archiv (Autor -
SandboxEscaper ).
Unter dem Cutter befindet sich die Übersetzung des Beschreibungsdokuments im Archiv.
Beschreibung der Sicherheitsanfälligkeit
Der Task Scheduler-Dienst verfügt über eine RPC-Schnittstelle (über den ALPC-Transport zugänglich), die die SchRpcSetSecurity-Methode unterstützt.
Dies ist der Prototyp dieser Methode:
long _SchRpcSetSecurity( [in][string] wchar_t* arg_1,
Vom Taskplaner erstellte Aufgaben erstellen das entsprechende Verzeichnis / die entsprechende Datei in c: \ windows \ system32 \ task. Wahrscheinlich ist diese Methode zum Aufzeichnen von DACL'a-Aufgaben vorgesehen, die sich dort befinden. Die Aufzeichnung erfolgt jedoch nach dem Identitätswechsel. Aus irgendeinem Grund prüft die Implementierung der Methode jedoch auch das Vorhandensein einer Jobdatei in c: \ windows \ task und schreibt eine DACL
ohne Identitätswechsel in diese . Da der Benutzer (auch der Benutzer in der Gastgruppe) Dateien in diesem Verzeichnis erstellen kann, können wir einfach einen Hardlink zu jeder anderen Datei erstellen, die wir lesen können. Mit einem solchen Hardlink können wir den Scheduler-Dienst (der mit SYSTEM-Berechtigungen ausgeführt wird) zwingen, eine beliebige DACL (siehe den zweiten SchRpcSetSecurity-Parameter) in eine Datei unserer Wahl zu schreiben.
Also: Für jede Datei, die gelesen werden kann, können Sie die DACL ändern, wodurch Sie sie vollständig überschreiben können.
Ausnutzung der Verwundbarkeit
Diese Verwundbarkeit gibt uns ein wirklich starkes Grundelement! Das Hauptproblem besteht darin, dass nach der Installation (standardmäßig) viele wichtige Dateien nur vom TrustedInstaller-Benutzer (nicht jedoch vom SYSTEM-Benutzer) geändert werden können.
Das Archiv enthält ein Powershell-Skript zum Auflisten von Dateien, die Sie steuern können. Lauf einfach:
./enumerate.ps1 >output.txtDas System hat viele Ziele. Sie können die Programmdateien steuern. Wenn Ihre Zieldatei von einem Administrator / anderen Benutzer verwendet wird, können die von Ihnen überschriebenen Dateien mit den erforderlichen Berechtigungen gestartet werden.
Das zweite Problem ist, dass wir zwar die Kontrolle über viele Dateien erlangen können, das Schreiben in diese jedoch oft unmöglich ist, da diese DLLs bereits irgendwo zur Ausführung geladen sind. Der Versuch, eine DACL für eine zur Ausführung hochgeladene Datei zu schreiben, führt zu einem Fehler beim gemeinsamen Zugriff. Die Sicherheitsanfälligkeit kann jedoch auch für andere Dateitypen verwendet werden, die möglicherweise ein besseres Ziel als eine DLL darstellen.
Für den Betrieb wurde die Datei C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll ausgewählt (der Name des Verzeichnisses kann variieren, dies wird in PoC berücksichtigt). Es sieht so aus, als ob diese Datei zum XPS-Drucker gehört und standardmäßig nicht in den Druckdienst geladen wird (es kann vorkommen, dass die Datei bereits geladen ist ... aber häufiger nicht).
Wenn wir den Druckauftrag mit dem XPS-Drucker starten, lädt der Dienst diese DLL, die wir zuvor neu schreiben können. Ein solcher Angriffsvektor (Hijacking) kann leicht für etwas Besseres angewendet werden. Ich kann versuchen, die besten Optionen zu finden ... lass es mich einfach wissen.
Hinweis : Auf einem alten Laptop, auf dem Windows 10 seit mehreren Jahren ausgeführt wird, gibt es zwei Verzeichnisse prnms003.inf_amd64_ *. Die neue Version löscht nicht die alte, was bedeutet, dass nicht garantiert werden kann, dass FindFirstFile (in PoC verwendet) das aktuelle Verzeichnis findet. Daher können Sie den Code erweitern, indem Sie alle gefundenen printconfig.dll überschreiben oder das Attribut des letzten Datensatzes in der Datei überprüfen und einen neueren auswählen.
Demo
Ein Video mit einer Demonstration finden Sie auch im Archiv: