athenasec16/cve-2026-29923Proof-of-Concept-Exploit für CVE-2026-29923, eine BYOVD-Privilegieneskalation in pstrip64.sys. Demonstriert physikalisches Speicher-Lesen/Schreiben über IOCTL, um das SYSTEM-Token zu stehlen und eine erhöhte Shell zu starten.
Haftungsausschluss: Dieser Code dient ausschließlich Bildungs- und Abwehrforschungszwecken. Er wurde entwickelt, um das Verständnis von Kernel-Ausnutzung zu fördern und Verteidigern zu helfen, sich vor ähnlichen Schwachstellen zu schützen. Jegliche unbefugte, illegale oder böswillige Nutzung dieses Projekts ist strengstens untersagt.
Hash: ab01485bb7c8bc1a9c86096eeea6d31d8fad557bf4d44072b46373d2203faa6e
Treibername: pstrip64.sys
CVE: CVE-2026-29923
Ein "Bring Your Own Vulnerable Driver" (BYOVD)-Angriff ist eine alte, aber hochwirksame Methode für Angreifer, moderne Windows-Sicherheitsmechanismen zu umgehen, indem sie einen Legacy-Treiber verwenden, dem das Betriebssystem noch offiziell vertraut. Sobald der Treiber geladen ist, nutzt der Angreifer seine Schwachstellen aus, um die Lücke zwischen einem standardmäßigen, nicht privilegierten Prozess und vollständiger Systemkontrolle zu schließen.
Anfang dieser Woche wurde eine neue Schwachstelle im pstrip64.sys-Treiber unter der Bezeichnung CVE-2026-29923 offengelegt. Dieser Blogbeitrag beschreibt den gesamten Lebenszyklus des Exploits: von meiner ersten Schwachstellenforschung und der Entwicklung des Proof of Concept (PoC) bis hin zu umsetzbaren Abwehrstrategien für Verteidiger, die ihre Umgebungen sichern.
Der pstrip64.sys-Treiber ist eine Legacy-Kernelmodul-Komponente, die mit EnTech Taiwan PowerStrip (bis Version 3.90.736) verbunden ist. Obwohl sein legitimer Zweck darin besteht, erweiterte Grafikkarten-Display-Anpassungen zu ermöglichen, machen seine tiefen Systemprivilegien ihn zu einem hochattraktiven Ziel für Angreifer.
Als die Schwachstelle erstmals offengelegt wurde, begann ich mit der Analyse ihrer DriverEntry-Funktion. Diese dient als Hauptinitialisierungsroutine für den Kernel-Treiber, erstellt das Geräteobjekt \Device\PSTRIP64 und stellt es Benutzermodusanwendungen über den symbolischen Link \DosDevices\PSTRIP64 zur Verfügung. Noch wichtiger ist, dass sie die Dispatch-Tabelle des Treibers konfiguriert. Der Eintrag, der mir sofort ins Auge fiel, war Index 14 (IRP_MJ_DEVICE_CONTROL), der alle benutzergesteuerten IOCTL-Anfragen direkt an die Handler-Funktion sub_11340 weiterleitet – unser primäres Interessensgebiet.
Die Funktion sub_11340 dient als primärer IOCTL-Dispatcher, der Anfragen aus dem Benutzermodus interpretiert.
Von allen verfügbaren IOCTLs ist 0x80002008 zweifellos der interessanteste. Während die Standardfälle kleinere I/O-Port-Interaktionen behandeln, fungiert 0x80002008 als Tor zu sub_11000, indem es den SystemBuffer direkt an diese Funktion übergibt.
Diese Routine sub_11000 ist der entscheidende Beweis. Zunächst verwendet sie HalTranslateBusAddress, um unsere benutzergesteuerte Adresse in eine gültige System-Physikalische-Adresse zu übersetzen. Dann öffnet sie \Device\PhysicalMemory und bildet es mit ZwMapViewOfSection ab. Durch die Hartcodierung des Zielprozess-Handles auf (HANDLE)0xFFFFFFFFFFFFFFFFLL (was ZwCurrentProcess() darstellt) bildet der Treiber diesen physischen Speicher direkt in den virtuellen Adressraum unseres aufrufenden Prozesses ab. Entscheidend ist, dass er diese neu abgebildete virtuelle Adresse dann zurück in den SystemBuffer schreibt, um sie an den Benutzer zurückzugeben – und so unserer Anwendung offiziell einen direkten Zeiger zum Lesen und Schreiben von physischem Speicher übergibt.
Nachdem die Schwachstelle vollständig verstanden und eine physische Lese-/Schreib-Primitive etabliert ist, habe ich alle benötigten Puzzleteile. Jetzt ist es Zeit, mit dem Schreiben des Proof of Concept zu beginnen.
Hinweis: Dieser PoC wurde speziell in einer Windows 10 22H2-Umgebung entwickelt und getestet. Da der Exploit auf der Manipulation von rohem physischem Speicher beruht, sind die Kernel-Struktur-Offsets und physischen Speichergrenzen derzeit für mein Setup fest codiert. Um dies auf Ihrem eigenen Rechner zu testen, müssen Sie die Windows-Kernel-Offsets aktualisieren und die physischen Adress-Scanbereiche an Ihre spezifische OS-Build- und RAM-Konfiguration anpassen.
Der erste Schritt in meinem Exploit ist die Kommunikation mit dem Treiber. Dies tat ich durch Aufruf von CreateFileA auf dem symbolischen Link des Treibers (\\.\PSTRIP64). Sobald ich ein gültiges Handle hatte, brauchte ich eine saubere Möglichkeit, den zuvor analysierten IOCTL 0x80002008 zu missbrauchen. Ich erstellte eine Wrapper-Funktion namens MapPhysicalMemory(). Diese Funktion befüllt meine benutzerdefinierte Struktur PSTRIP_MAP_REQUEST mit der Ziel-Physikalischen-Adresse und der Länge des Speicherblocks, den ich lesen möchte.
Ich sende diese Struktur dann über DeviceIoControl direkt an den Treiber. Im Erfolgsfall bildet der Treiber diesen physischen Speicher direkt in meine Benutzermodusanwendung ab und gibt die virtuelle Basisadresse im Feld OutputResult zurück. Ich kann diese zurückgegebene Adresse nun in einen standardmäßigen C++-Zeiger umwandeln, was mir rohen, nicht privilegierten Zugriff auf den physischen RAM des Systems verschafft.
Mit meiner voll funktionsfähigen physischen Lese-/Schreib-Primitive war mein Ziel, die Kernel-Datenstrukturen zu finden, die Prozessprivilegien enthalten. In Windows wird jeder laufende Prozess durch eine EPROCESS-Struktur dargestellt.
Windows weist EPROCESS-Strukturen im Kernel-Pool mit einem spezifischen 4-Byte-Identifier namens Pool-Tag zu. Für Prozesse ist dieses Tag der String Proc (was hexadezimal 0x636F7250 entspricht). Durch das Scannen des physischen RAMs des Systems konnte ich nach genau diesem String suchen.
Mein Exploit durchläuft den physischen Adressraum von 0x10000000 bis 0x140000000 und bildet Speicher in 2MB-Blöcken (STEP_SIZE = 0x200000) ab. Ich wandle jeden abgebildeten Block in ein rohes Byte-Array um und durchsuche ihn in 16-Byte-Schritten (sizeof(_POOL_HEADER)).
Allerdings reicht es nicht aus, einfach das Proc-Tag im physischen Speicher zu finden. Speicher ist unordentlich – dieses Tag könnte ein Überbleibsel eines beendeten Prozesses oder nur zufällige Daten sein, die zufällig dem Hex-Wert entsprechen. Wenn ich blind annehmen würde, dass jedes Proc-Tag eine gültige EPROCESS-Struktur ist, und Speicher modifizieren würde, würde ich sofort einen BSOD verursachen.
Um Stabilität zu gewährleisten, musste ich die Struktur mit Heuristiken validieren. Zuerst berechne ich den Start der EPROCESS-Struktur (die ein wenig vom Pool-Tag versetzt ist). Von dort aus überprüfe ich einige bekannte Konstanten für einen laufenden Prozess:
0x2 (Normale Priorität) ist.0x0 ist.