Windows Agere Modem Treiber (ltmdm64.sys). Dieser Treiber ist sehr alt und wird auf meinem Testrechner standardmäßig nicht geladen, daher werde ich ihn in einem BYOVD-Szenario ausnutzen. Interessanterweise existiert dieser Treiber laut meiner Recherche seit Windows 7 und hat mindestens einen Fehler. hier

Zu dieser Zeit hat MSRC keine Maßnahmen ergriffen 🤡

Schwachstellen

Einige IOCTLs in diesem Treiber verwenden METHOD_NEITHER, prüfen jedoch nicht, ob der vom Aufrufer bereitgestellte Adresspuffer aus dem Benutzermodus oder Kernelmodus stammt. Hier ist ein Beispiel-IOCTL-Code, den ich mit OSR dekodiert habe:

Das bedeutet, Sie können eine Kernel-Adresse an die DeviceIoControl-API übergeben und der Treiber verarbeitet sie normal.

Beachten Sie, dass Sie zuerst kASLR umgehen müssen, um die Kernel-Adresse zu leaken. Ich werde EnumDeviceDrivers verwenden (Unter Windows 24h2 benötigen Sie SeDebugPriv dafür).

Null-Dereferenzierung

Das Problem liegt im IOCTL 0x802b200f (ud_response). Auch hier validiert dieser IOCTL-Dispatch die Adresse, die ich aus dem Benutzermodus bereitstelle, nicht, aber ich werde sie später nutzen.

Das ud_response ruft ll_load_diagnostics auf, und ich erreiche den folgenden Code:

Zu Beginn ist die globale Variable eeprom nicht initialisiert, sodass sie NULL enthält. Hier ist ein einfacher Code, der dies auslöst.

Ich werde dies später nutzen.

Exploit-Einstiegspunkt 0x802b2003

Dieses IOCTL konvertiert einfach die Treiberversionszeichenfolge "8.36" in die Zahl 0x836 (ein DWORD) und schreibt sie an die vom Aufrufer bereitgestellte Adresse (dank METHOD_NEITHER). Technisch gesehen kann ich diese vier Bytes (36 08 00 00) an eine beliebige Kernel-Adresse schreiben. Ich werde dies nutzen, um die globalen Variablen des Treibers zu überschreiben und den Ausführungsfluss zu ändern.

Ich nenne dieses 0x802b2003 IOCTL_GET_VERSION

Exploit

Beliebiges Null-1-Byte:

Zurück zum NULL-Dereferenzierungsfall: Ich verwende die VirtualAlloc-API, um eine feste Adresse (0x083600000000) zu allokieren. Dann verwende ich IOCTL_GET_VERSION, um an *(eeprom + 4) die oben beschriebenen vier Bytes zu schreiben. Wenn der Treiber später eeprom dereferenziert, liest er von der von mir allokierten Adresse.

Nach der Behebung der NULL-Dereferenzierung schreibt das IOCTL eine Zeichenfolge an die von mir aus dem Benutzermodus bereitgestellte Adresse, basierend auf der Puffergröße.

Dieser Code demonstriert einfach, was ich oben beschrieben habe: einen Puffer allokieren und mit 0xAA füllen, die NULL-Dereferenzierung beheben und dann den Treiber aufrufen. Beachten Sie, dass ich 11 Bytes allokiere, dem Treiber aber nur eine Puffergröße von 10 bereitstelle, um zu sehen, wie er sich verhält.

Er schreibt eine feste Bytefolge in meinen Puffer und nullt dann das letzte Byte (das 11.) aus, obwohl ich nur eine Größe von 10 bereitstelle. Es ersetzt das letzte 0xAA in meinem Puffer durch 0x00. Dies zeigt, dass der Treiber, wenn ich eine Größe von 0 bereitstelle, dennoch ein einzelnes 0x00-Byte an die Zieladresse schreibt.

Beliebige Dekrementierung

Jetzt habe ich das Null- und das beliebige Schreiben mit festen 4 Bytes, lassen Sie uns eine weitere Primitive erstellen.

Dieses IOCTL setzt das globale LtMsgEvent auf meinen Benutzerpuffer, prüft dann, ob WDM null ist, und setzt es wieder auf null.

Dann ruft es in 0x802b2207 die ObfReferenceObject-API auf.

Im Ausgangszustand ist WDM null, aber mit Hilfe von IOCTL_GET_VERSION kann ich WDM auf 0x36 setzen (es ist nur 1 Byte groß) und LtMsgEvent ist immer noch mein Puffer. Dann nullte ich WDM aus und rufe 0x802b2207 auf. Schließlich erreiche ich ObfReferenceObject. Ich nenne diese beiden IOCTLs IOCTL_SET_LtMsgEvent und IOCTL_DEREF_LtMsgEvent.

Die Exploit-Technik mit ObfReferenceObject ändert den PreviousMode unseres KTHREAD von UserMode zu KernelMode. Sie können darüber hier) lesen. Windows hat diesen Exploit jedoch behoben, sodass wir ihn nicht verwenden können.

Aber die Primitive in ObfReferenceObject existiert immer noch. Die API subtrahiert 0x30 von der von uns bereitgestellten Adresse, interpretiert das Ergebnis als 8-Byte-Ganzzahl und subtrahiert dann 1.

    *(signed long long)(LtMsgEvent-0x30) -= 1

Das Problem ist jedoch, dass geprüft wird, ob der nächste Wert 0 ist oder ob der aktuelle Wert < 1 ist (interpretiert als 8-Byte-Ganzzahl mit Vorzeichen). Wenn eine der Bedingungen zutrifft, springt es zu KeBugCheckEx und stürzt das System ab.

Beliebiges Schreiben