CVE-2026-66804: Cross Device Virtual Camera EoP

Ich habe das Problem, das jetzt als CVE-2026-66804 geführt wird, unabhängig entdeckt und gemeldet. MSRC bestätigte meine Einreichung als Duplikat eines früheren Berichts mit derselben zugrunde liegenden Ursache im Windows Camera FrameServer.

Ein normaler Windows-Benutzer kann einen fehlenden vertrauenswürdigen Pfad unter C:\ProgramData\CrossDevice erstellen, die registrierte COM-DLL der Cross Device Virtual Camera platzieren und bewirken, dass der Windows Camera Frame Server vom Angreifer kontrollierten Code als NT AUTHORITY\LOCAL SERVICE lädt. Die enthaltene Beweiskette nutzt das aktivierte SeImpersonatePrivilege des Diensttokens, um NT AUTHORITY\SYSTEM zu erlangen.

Primäres Fresh-VM-Video: fehlender Pfad zu SYSTEM

CVE	CVE-2026-66804
Microsoft-Titel	Sicherheitsanfälligkeit bezüglich Erhöhung von Berechtigungen im Microsoft Windows Cross Device Service
MSRC-Fall	119805
MSRC-Einreichung	VULN-192287
MSRC-Status	Abgeschlossen - Duplikat
Microsoft-Anerkennung	Daniel Wade with nadsec
Veröffentlichungsdatum	2026-08-11
Microsoft-Schweregrad	Wichtig
Microsoft-CVSS	7.8 Hoch - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Microsoft-CWE	CWE-284: Unsachgemäße Zugriffskontrolle
Fehlerklasse	DLL-Plantage über fehlenden Pfad / COM-Objekt-Hijacking
Komponente	Cross Device Virtual Camera / Windows Camera FrameServer
COM-Klasse	{E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}
Primär getesteter Build	Windows 11 Pro 25H2 Build 26200.8524
Auswirkung	Lokaler Standardbenutzer bis NT AUTHORITY\SYSTEM

TL;DR

Windows hat den COM-Server der Cross Device Virtual Camera an folgendem Pfad registriert:

%PROGRAMDATA%\CrossDevice\CrossDevice.Streaming.Source.dll

Auf der für die Validierung verwendeten frischen/Standard-Windows-11-VM existierte die maschinenweite Registrierung, bevor das zugrunde liegende Verzeichnis vorhanden war. Ein Standardbenutzer erstellte das fehlende Verzeichnis, platzierte die erwartete DLL und rief die Virtual-Camera-API auf. Der Camera Frame Server lud die DLL als LOCAL SERVICE, woraufhin die Beweiskette ein SYSTEM-Token erlangte und einen Beleg in einem geschützten Pfad schrieb.

Dies ist ein Problem mit fehlendem Pfad bzw. fehlender Initialisierung. Es ist keine Behauptung, dass ein Standardbenutzer eine vorhandene, geschützte Microsoft-DLL überschreiben kann.

Sicherheitslücke

Die relevante maschinenweite Registrierung ist:

HKLM\SOFTWARE\Classes\CLSID\{E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}\InProcServer32
  (Default) REG_EXPAND_SZ %PROGRAMDATA%\CrossDevice\CrossDevice.Streaming.Source.dll

Die demonstrierte Kette ist:

1. Ein Standardbenutzer bestätigt die maschinenweite COM-Registrierung.
2. Der Benutzer bestätigt, dass C:\ProgramData\CrossDevice nicht vorhanden ist.
3. Der Benutzer erstellt das fehlende Verzeichnis und platziert die registrierte DLL.
4. Der Benutzer startet die Cross Device Virtual Camera über Media Foundation.
5. Der Windows Camera Frame Server lädt die DLL als LOCAL SERVICE.
6. Die DLL bestätigt, dass das Diensttoken über SeImpersonatePrivilege verfügt.
7. Die angepasste Beweiskette im GodPotato-Stil erlangt ein SYSTEM-Token.
8. Der PoC schreibt einen Beleg in einen geschützten Pfad als NT AUTHORITY\SYSTEM.

Reproduktion mit frischer VM

Führen Sie diesen Proof of Concept nur in einer wegwerfbaren, verwundbaren Labor-VM aus, die Ihnen gehört oder für deren Test Sie ausdrücklich autorisiert sind. Erstellen Sie vor der Verwendung einen Snapshot der VM.

Aus einer Eingabeaufforderung eines Standardbenutzers:

cd /d path\to\fresh-vm-repro
Run-CrossDevicePoC.cmd

Das Runner-Skript validiert die erwartete Registrierung und weigert sich, ein bereits vorhandenes Cross-Device-Verzeichnis oder eine unerwartete Hilfsbinary anzufassen. Eine erfolgreiche Ausführung erzeugt LOCAL-SERVICE-, Privilegien- und SYSTEM-Belege.

Alle Voraussetzungen, erwarteten Ergebnisse, Hashes, Build-Befehle und Aufräumschritte finden Sie in fresh-vm-repro/README.md.

Video-Beweise

Beide Aufnahmen wurden aufbewahrt, da sie komplementäre Teile des Falls dokumentieren.

Video	Rolle
fresh-vm-missing-path-to-system.mp4	Primäre Neuvalidierung mit frischer/Standard-VM, die das Platzieren durch einen Standardbenutzer, die Ausführung als LOCAL SERVICE und SYSTEM-Belege zeigt. Die Aufnahme prüft den früheren Zustand des fehlenden Pfads über den Terminal-Scrollback; das Transkript bewahrt die explizite Ausgabe vor der Erstellung.
guided-full-chain-standard-user-to-system.mp4	Begleitender Walkthrough aus der ursprünglichen Einreichung. Zeigt die Ausnutzungs- und Impersonationskette detaillierter. Der Payload ist zu Beginn bereits vorhanden, daher liefert diese Aufnahme Kontext zur Kette und keinen unabhängigen Nachweis des frischen Zustands.

Die erfasste Konsolenausgabe der Fresh-VM ist in fresh-vm-transcript.txt gespeichert.

Original-Fallmaterial

• Detaillierte Analyse: docs/technical-report.md
• Dem MSRC vorgelegte Klarstellung zum fehlenden Pfad: docs/msrc-fresh-vm-clarification.md
• Originale Befehlsnotizen und Legacy-Kompatibilitäts-Wrapper: docs/archive/

Zeitleiste

Datum	Ereignis
2026-06-01	Erster Bericht als VULN-192287 an MSRC übermittelt; MSRC-Fall 119805 eröffnet
2026-06-04	Klarstellung zum fehlenden Pfad/Vorinitialisierung und sauberes Reproduktionsarchiv übermittelt
2026-06-05	MSRC bestätigte die Klarstellung
2026-07-27	MSRC bestätigte das Verhalten und stellte fest, dass die Einreichung ein früheres Problem mit derselben zugrunde liegenden Ursache im Windows Camera FrameServer duplizierte; eine Anerkennung war geplant, es wurde jedoch keine Prämie vergeben
2026-08-11	Microsoft veröffentlichte CVE-2026-66804 und stellte Sicherheitsupdates bereit
2026-08-13	Die Anerkennungsformulierung Daniel Wade with nadsec wurde bestätigt

Namensnennung Dritter

Teile der OXID-Auflösung, der Named-Pipe-Impersonation, der OBJREF-Konstruktion und der Logik zur Erlangung von SYSTEM-Tokens wurden aus GodPotato von BeichenDream und Mitwirkenden übernommen und nach C übersetzt.

Siehe THIRD_PARTY_NOTICES.md und LICENSES/Apache-2.0.txt für Details zu Urhebern und Lizenz.

---

Ressourcen