fortra/cve-2024-30051Detaillierte technische Analyse und Proof-of-Concept-Exploit für CVE-2024-30051, einen Heap-basierten Pufferüberlauf in der Windows DWM Core Library, der eine lokale Privilegienausweitung auf Integrity System level ermöglicht.
In diesem Blogbeitrag erkläre ich eine Sicherheitslücke in der Microsoft Windows DWM Core-Bibliothek, die ich analysiert habe, als der Exploit für Core Impact entwickelt wurde. Sie ermöglicht es einem nicht privilegierten Angreifer, Code als DWM-Benutzer mit Integritätssystemrechten auszuführen (CVE-2024-30051).
Da zum Zeitpunkt der Entwicklung des Exploits nicht genügend öffentliche Informationen vorhanden waren, musste ich viel reverse engineering betreiben. Ich werde hier zeigen, wie das KB5037771-Patch für Windows 23H2 mit IDA PRO zurückentwickelt wird. Ich werde BINDIFF verwenden, um einen binären Vergleich zwischen dwmcore.dll Version 10.0.22621.3447 und Version 10.0.22621.3593 durchzuführen. Ich zeige, wie der Heap-Überlauf entsteht, und werde ihn dann durch Rechteausweitung ausnutzen und schließlich einen funktionsfähigen PoC erstellen.
Index:
[Windows DWM Core Library Sicherheitslücke bezüglich Rechteausweitung (CVE-2024-30051) 1](#windows-dwm-core-library-elevation-of-privilege-vulnerability-cve-2024-30051)
[Details zur Sicherheitslücke: 2](#vulnerability-details)
[Diffing, um den Fehler zu finden: 3](#diffing-to-find-the-bug)
[Analyse des PoC, der CVE-2024-30051 ausnutzt: 8](#analysis-of-the-poc-exploiting-cve-2024-30051)
[1)Initialisierung 8](#initialization)
[2)Hooking 8](#hooking)
[3)Erstellen des Fensters 16](#creating-the-window)
[4)Gerät erstellen 16](#create-device)
[5) Factory erstellen 22](#create-factory)
[6) Gerätekontext erstellen 28](#create-a-device-context)
[7)Kompositionsgerät erstellen 29](#create-a-composition-device)
[8)Aufrufen der hook3-Funktion 31](#calling-dcompositioncreatedevice-function)
[9)Ziel für HWND erstellen 32](#creating-a-target-for-handle-hwnd)
[10)Oberfläche erstellen 33](#creating-surface)
[11)Aufrufen von BeginDraw, EndDraw und CreateVisual. 34](#calling-begindraw-enddraw-and-createvisual)
[11)Aufrufen von Visual SetContent 36](#calling-visual-setcontent)
[12)Objekte freigeben 38](#release-objects)
[13)Kompositionsgerät committen 38](#commit-composition-device)
[14)Aufrufen von hook2 39](#calling-hook2)
[15)Aufrufen von hook 39](#remember-that-the-vulnerable-function-can-be-reached-using-some-methods-of-the-cprimitivegroup-class.-at-this-point-it-creates-a-heap-then-hook2-captures-and-saves-the-corresponding-heaphandle.)
[16)Aufrufen von hook4 41](#calling-the-function-hook4)
[17)Durchführen von Heap Spray 49](#performing-heap-spray)
[18)Ändern des Basis-Chunks vor dem Senden. 51](#modifying-the-base-chunk-before-send)
[19)Debuggen des DWM-Prozesses 52](#debugging-the-dwm-process)
[20)Erhöhen der Privilegien auf Integrity System-Ebene 62](#elevating-privileges-to-integrity-system-level)
Windows DWM Core Library Sicherheitslücke bezüglich Rechteausweitung CVE-2024-30051
Veröffentlicht: 14. Mai 2024
Zuweisende CNA: Microsoft CVE-2024-30051
Auswirkung: Rechteausweitung
Maximaler Schweregrad: Important
Schwachstelle:
CWE-122: Heap-basierter Pufferüberlauf
CVSS: 3.1 7.8 / 7.2
Die Sicherheitslücke besteht aufgrund eines Größenberechnungsfehlers in einer Integer-Division innerhalb der wichtigsten Windows DWM-Bibliothek namens dwmcore.dll. Ein lokaler Benutzer kann einen Pufferüberlauf auf dem Heap in der Methode CCommandBuffer::Initialize in dwmcore.dll verursachen und beliebigen Code mit dem DWM-Benutzer mit Integritätssystemrechten ausführen. Der Exploit führt einen Heap Spray im DWM-Prozess durch, um den Speicher vorzubereiten, und erzeugt schließlich einen Heap-Überlauf in dwmcore.dll, der durch das Freigeben bestimmter Teile des Heap-Sprays ausgelöst wird.
Sobald der Exploit erfolgreich ist, lädt der DWM-Prozess unsere präparierte DLL, die unseren Code oder unsere ausführbare Datei (in unserem Fall eine CMD) als DWM-Benutzer mit Integritätssystemrechten ausführt.
Gehen wir diese Sicherheitslücke durch und sehen, wie sie uns erlaubt, als DWM-Benutzer mit Integrity Level SYSTEM zu laufen. Beachten Sie, dass dieser Benutzer nicht zur Administratorgruppe gehört und daher einige Rechteeinschränkungen hat.
Das Patch für Windows 11 23H2 kann heruntergeladen werden von:
https://www.catalog.update.microsoft.com/Search.aspx?q=KB5037771
windows11.0-kb5037771-x64_19a3f100fb8437d059d7ee2b879fe8e48a1bae42.msu
Die anfällige Version von dwmcore.dll ist: 10.0.22621.3447
Die gepatchte Version von dwmcore.dll ist: 10.0.22621.3593
Bei der Analyse der geänderten Funktionen wird deutlich, dass die gepatchte Version von CCommandBuffer::Initialize viele hinzugefügte Blöcke hat, was sie ganz anders aussehen lässt als die ungepatchte Version.
Nach statischem Reverse Engineering dieser Funktion gibt es zwei Aufrufe an CD2DSharedBuffer::GetBufferSize.
Der erste Aufruf erhält die Größe für die Zuweisung im new und der zweite Aufruf erhält dieselbe Größe für den memcpy.
Zunächst scheint alles korrekt zu sein. Allerdings führt es vor der Zuweisung einige Operationen mit der Größe durch.
Es erhält buffer_size und buffer_size2 durch Aufruf derselben CD2DSharedBuffer::GetBufferSize-Funktion, die beide denselben Wert zurückgibt. Aber im new führt es eine Voroperation durch, eine Integer-Division von buffer_size durch 0x90 und dann Multiplikation mit 0x90, während im memcpy das zurückgegebene buffer_size2 ohne Operation darauf verwendet wird.
Mit diesen Operationen habe ich festgestellt, dass die schließlich im new und im memcpy verwendete Größe unterschiedlich sein kann.
buffer_size = buffer_size2 (zurückgegebene Größen)
size_new= buffer_size/0x90 x 0x90
size_memcpy=buffer_size2
Zum Beispiel, wenn buffer_size 0x91 ist
buffer_size = buffer_size2=0x91
size_new= buffer_size/0x90 x 0x90 =0x90
size_memcpy= buffer_size2= 0x91
Dieses Beispiel beweist, dass es einen Heap-Überlauf gibt. Es werden mehr Bytes kopiert als zugewiesen, und die Größe ist kontrollierbar.
