dis0rder0x00/trustedhiveLPE-Proof-of-Concept für Windows 11, das das COM-Objekt der Component Based Servicing (CBS)-Sitzung von TrustedInstaller und Junctions für beliebiges Schreiben von Dateien missbraucht.
Lokale Rechteausweitung über eine ungeschützte CBS-COM-Methode - beliebiges Schreiben von Dateien von Medium-IL zu SYSTEM unter Windows 11
| Datum | Ereignis |
|---|---|
| 22. Juli 2026 | Schwachstelle an MSRC gemeldet |
| 8. September 2026 | Microsoft patcht den Windows Update Servicing Stack (September Patch Tuesday) |
| 29. Oktober 2026 | MSRC antwortet (siehe unten) |
Das COM-Objekt der Component Based Servicing (CBS)-Sitzung läuft innerhalb von TrustedInstaller.exe als SYSTEM und kann von jedem interaktiven Benutzer aktiviert werden. Nahezu jede Methode der Sitzungsschnittstelle ruft vor der Ausführung EnsureCallerIsAdministrator auf, mit Ausnahme von CreateExternalTransformerExecutor, das einen CSI-Store-Transformer-Executor auf niedriger Ebene ohne Autorisierungsprüfung zurückgab.
Die Initialize()-Methode dieses Executors läuft als SYSTEM ohne Impersonation. Ein Aufrufer mit mittlerer Integritätsstufe kann TrustedInstaller dazu bringen, eine Registrierungsstruktur-Logdatei an einem vom Angreifer kontrollierten Pfad zu erstellen, indem er NTFS-Junctions und Objektmanager-Symbolic Links ausnutzt, deren Erstellung keinerlei besondere Berechtigungen erfordert.
CreateExternalTransformerExecutor aufrufenErgebnis: Beliebiges Schreiben von Dateien in jedes existierende Verzeichnis als SYSTEM, aus einem normalen Benutzerkonto heraus. Keine Administratorrechte, keine besonderen Berechtigungen, keine Benutzerinteraktion erforderlich.
MSRC bewertete meinen Bericht als geringe Schwere / Defense in Depth und erklärte, dass die „bewerteten Proofs of Concept keine Dateischreibvorgänge an nicht autorisierte Orte nachweisen". Der Fall wurde als unterhalb der Schwelle für eine sofortige Behebung eingestuft und geschlossen; es wurde keine zusätzliche CVE vergeben, kein Bug-Bounty gewährt, und MSRC wird das Problem nicht weiter verfolgen, was Sinn ergibt, falls es sich um ein Duplikat handelt.
Das PoC schreibt vom Angreifer kontrollierten Inhalt nach C:\Windows\System32 aus einem Prozess mit mittlerer Integritätsstufe (Medium-IL), der kein Administrator ist, und tat dies zuverlässig auf jedem ungepatchten Build, auf dem es getestet wurde.
Die wahrscheinlichste Erklärung für die Bewertung von MSRC ist der Zeitablauf: Der Bericht wurde im Juli eingereicht, der Servicing-Stack-Fix wurde im September ausgeliefert, und die Antwort von MSRC kam im Oktober, zu welchem Zeitpunkt das PoC auf jedem aktuellen System tatsächlich mit E_ACCESSDENIED fehlschlagen würde.
Ich wurde allerdings auf die Seite der besonderen Erwähnungen von MSRC aufgenommen, das ist zumindest etwas :)
Ich vermute, dass die hier gemeldete Schwachstelle durch CVE-2026-81963 („Windows Update Stack Elevation of Privilege Vulnerability") abgedeckt ist, die im genannten Update behoben wurde und dieselbe Schwachstellenklasse beschreibt (CWE-59 / CWE-284, Link-Following + unsachgemäße Zugriffskontrolle im CBS-Servicing-Stack). Diese CVE wurde Romain Deperne (Airbus Helicopters) und dem Microsoft Threat Intelligence Center (MSTIC) zugeschrieben und wurde als aktiv in freier Wildbahn ausgenutzt bestätigt, bevor der Patch veröffentlicht wurde. ABER: Ich habe keine offizielle Bestätigung, dass mein Bericht dasselbe Problem abdeckt.
Beide PoCs müssen als normaler Benutzer ohne Administratorrechte (mittlere Integritätsstufe) ausgeführt werden und enthalten denselben Basis-Exploit. Wenn Sie sie mit erhöhten Rechten ausführen, gelingt der Exploit trivial, weil Sie bereits Administratorrechte besitzen – was den eigentlichen Sinn völlig verfehlt.
PoC_Fun/Der vollständige Proof-of-Concept mit einer Benutzeroberfläche. Ein vibecodiertes grafisches Harness, das die Exploit-Technik in eine interaktive Oberfläche einbettet. Gut für Demos und alle, die keine langweiligen reinen Terminal-PoCs mögen (MAKE POCS FUN AGAIN!)
Die in Überschriften und im Banner verwendete Monospace-Gothic-Pixel-Art-Schrift wurde in meinem Auftrag von nico_n_art erstellt.
Build:
$ cd PoC_Fun
$ dotnet clean -c Release && dotnet publish -c Release
$ .\bin\Release\net8.0-windows\win-x64\publish\TrustedHive.exe
Verwendung: Doppelklicken Sie einfach auf das Release, und die Benutzeroberfläche sollte Sie führen, oder verwenden Sie das „?“, um das Hilfemenü zu öffnen.
PoC_Boring/Die eigenständige C-Datei für den Exploit. Keine UI und keine Abhängigkeiten außer ole32.lib und advapi32.lib. Mit MSVC kompilieren (cl /O2 ...), auf eine Eingabedatei und einen Ausgabepfad zeigen lassen, und schon erledigt sie ihren Job.
Build:
$ cd PoC_Boring
$ cl /nologo /W3 /O2 TrustedHive_PoC.c ole32.lib advapi32.lib /link
$ .\TrustedHive_PoC.exe
Verwendung:
$ .\TrustedHive_BoringPoC.exe <input_file> <output_path> [/keep]
<input_file> : file whose bytes are written to the target
<output_path> : destination (its parent directory must exist),
e.g. C:\Windows\System32\poc.dll
/keep : keep the Hidden+System attributes the Configuration Manager
stamps on the created hive-log file (default: clear them)
EvaluateApplicability) unter derselben CVE