NotSecDrv - Ein PoC-Code für CVE-2018-7249

Allgemeine Beschreibung

Ein Problem wurde im Treiber secdrv.sys entdeckt, wie er in Microsoft Windows Vista, Windows 7, Windows 8 und Windows 8.1 vor KB3086255 ausgeliefert wurde, sowie in Macrovision SafeDisc. Zwei sorgfältig abgestimmte Aufrufe von IOCTL 0xCA002813 können eine Race-Condition verursachen, die zu einem Use-After-Free führt. Bei Ausnutzung kann ein unprivilegierter Angreifer beliebigen Code im Kernel ausführen.

Die Schwachstelle wurde Microsoft gemeldet, und da sie keinen aktuellen Windows-Rechner betrifft (nur Versionen vor KB3086255), werden sie keine Maßnahmen ergreifen. Wurde erfolgreich unter Windows 7 x86 getestet und ausgenutzt.

Auch verwandt mit CVE-2018-7250.

Screenshot

Details

Dies dokumentiert meine kleine Forschung zum Treiber secdrv.sys. Alle beschriebenen Verhaltensweisen des Treibers wurden durch Reverse Engineering ermittelt und könnten falsch / ungenau sein.

Offset 0x4 des Eingabepuffers zum IOCTL (0x0CA002813) enthält eine Zahl, die ich als TYP bezeichnen werde. Die Hauptbehandlungsfunktion dieses IOCTL (0x0CA002813), sub_11A88, empfängt 3 verschiedene Typen: 0x96, 0x97 und 0x98.

• 0x96 weist einen PagedPool-Chunk zu, speichert ihn in einem Array der Größe 0x64, initialisiert ihn (sozusagen :)) und kopiert einen Teil davon an Offset 0x10 in den vom Benutzer bereitgestellten Puffer.
• 0x97 verwendet einen zuvor mit 0x96 zugewiesenen Chunk (er findet den richtigen Chunk im genannten Array anhand eines Tags) und verwendet ihn, um den Benutzereingabepuffer mit einer Art modifizierter XOR-Verschlüsselungsroutine zu verschlüsseln. Anschließend ruft es eine Funktion auf, die in einer anderen Struktur gespeichert ist, auf die ein Feld im zugewiesenen Chunk zeigt.
• 0x98 gibt einen mit 0x96 zugewiesenen Chunk frei. Es findet den richtigen Chunk, indem es nach dem Tag sucht, der ihm im Zuordnungsprozess gegeben wurde.

Info Leak (CVE-2018-7250)

Nachdem IOCTL-Typ 0x96 einen neuen Chunk zugewiesen und initialisiert, aber nicht vollständig, hat, kopiert es den Chunk in den Benutzermodus. 16 Bits im neu zugewiesenen Chunk wurden nicht initialisiert und enthalten Daten von vorherigen PagedPool-Zuweisungen. Die nicht initialisierten Bits werden dann mit der REP MOVSD-Anweisung in den Benutzermodus kopiert (im Code bei .text:00011BE9). PoC-Code hier.

Beliebige Codeausführung (CVE-2018-7249)

Wenn IOCTL-Typ 0x97 aufgerufen wird, findet er den benötigten Chunk, der zuvor mit Typ 0x96 zugewiesen wurde, anhand seines Tags. Wenn die Zuweisung bereits durch IOCTL-Typ 0x97 freigegeben wurde, gibt DeviceIoControl einen Fehler zurück. Die Schwachstelle besteht darin, dass die von Typ 0x97 verwendete Zuweisung WÄHREND ihres Betriebs freigegeben werden kann (da keine Synchronisationsmechanismen verwendet werden), was zu einem Use-After-Free führt, wenn die Race gewonnen wird. Wenn es einem Angreifer gelingt, den Chunk während des Betriebs von IOCTL-Typ 0x97 (mit Typ 0x98) freizugeben und einen neuen, von ihm kontrollierten Chunk an derselben Speicherstelle zuzuweisen, kann er einen Zeiger auf eine andere Struktur überschreiben, die einen Funktionszeiger enthält, der verwendet werden kann, um schließlich den Ausführungsfluss des Treibers zu kapern und beliebigen Code in Ring 0 auszuführen. Da die Verschlüsselungsroutine auf einem vom Benutzer bereitgestellten Puffer durchgeführt wird, der enorm groß sein kann, kann die Verschlüsselung viel Zeit in Anspruch nehmen, wodurch ein perfektes Zeitfenster für IOCTL-Typ 0x98 entsteht, um den Chunk freizugeben, während er noch in Gebrauch ist. Die Zeitfenster können so lang sein (mehr als 1 Sekunde!), dass die Race zuverlässig beim ersten Versuch gewonnen werden kann. Der Use-After-Free beginnt bei .text:00011B68, und der tatsächliche Aufruf, der gekapert wird, um zum Shellcode zu springen, erfolgt bei .text:00011B86.

Die Schritte zur erfolgreichen Ausnutzung dieser Schwachstelle sind wie folgt:

• Alle vorherigen Chunks mit dem Tag, den wir später verwenden möchten, freigeben, um sicherzustellen, dass alle IOCTLs auf demselben PagedPool-Chunk arbeiten.
• Den PagedPool sprayen und Löcher erzeugen, die der Größe der Zuweisungen in IOCTL-Typ 0x96 (0x30 Bytes) entsprechen. Dies ist notwendig, um später zuverlässig einen gefälschten Ersatz anstelle des freigegebenen zuweisen zu können.
• Einen Chunk mit IOCTL-Typ 0x96 zuweisen. Dieser Chunk wird in einem der zuvor erstellten Löcher zugewiesen.
• Einen großen Bereich des Benutzerspeichers zuweisen und IOCTL-Typ 0x97 aufrufen. Der große Speicherbereich stellt sicher, dass der Thread, der die Zuweisung freigibt, genügend Zeit hat, die Race zu gewinnen.
• Einen neuen Thread starten, der IOCTL-Typ 0x98 aufruft und den Chunk freigibt, mit dem der andere Thread arbeitet.
• Aus dem neuen Thread erneut den Pool sprayen (nachdem der Chunk freigegeben wurde), um den freigegebenen Chunk durch eine vom Angreifer kontrollierte Zuweisung zu ersetzen. Dieser gefälschte Chunk sollte gültige Zeiger auf die notwendigen Strukturen enthalten.
• Die Adresse des Shellcodes am korrekten Offset des Funktionszeigers in der erstellten gefälschten Struktur platzieren und darauf warten, dass sie aufgerufen wird (sie wird von IOCTL-Typ 0x97 aufgerufen, nachdem die Verschlüsselung abgeschlossen ist).
• Genießen!

Testumgebung

Betriebssystem: Windows 7 Kernel Version 7600 MP (1 procs) Free x86 compatible Built by: 7600.16385.x86fre.win7_rtm.090713-1255 VM: 4GB RAM, 1 CPU Hardware: Windows 10 Pro 64 bit, Motherboard Gigabyte Z370 HD3, 16GB RAM, Intel i5-8400 2.80GHz (6 CPUs)