fortra/cve-2024-30051Analyse technique détaillée et preuve de concept pour CVE-2024-30051, un dépassement de tampon basé sur le tas dans la bibliothèque principale DWM de Windows permettant une élévation de privilèges locaux au niveau Integrity System.
Dans ce billet de blog, je vais expliquer une vulnérabilité dans la bibliothèque DWM Core de Microsoft Windows que j'ai analysée lors du développement de l'exploit pour Core Impact. Elle permet à un attaquant non privilégié d'exécuter du code en tant qu'utilisateur DWM avec des privilèges Integrity System (CVE-2024-30051).
Comme il n'y avait pas suffisamment d'informations publiques à l'époque pour développer l'exploit, j'ai dû faire beaucoup de rétro-ingénierie. Je vais donc montrer ici comment rétro-concevoir le correctif KB5037771 pour Windows 23H2 en utilisant IDA PRO, j'utiliserai BINDIFF pour effectuer une comparaison binaire entre dwmcore.dll version 10.0.22621.3447 et version 10.0.22621.3593, montrerai comment le débordement de tas est produit, puis l'exploiterai en élevant les privilèges, et enfin créerai un PoC fonctionnel.
Index :
[Windows DWM Core Library Elevation of Privilege Vulnerability (CVE-2024-30051) 1](#windows-dwm-core-library-elevation-of-privilege-vulnerability-cve-2024-30051)
[Vulnerability details : 2](#vulnerability-details)
[Diffing to find the bug : 3](#diffing-to-find-the-bug)
[Analysis of the PoC exploiting CVE-2024-30051 : 8](#analysis-of-the-poc-exploiting-cve-2024-30051)
[1)Initialization 8](#initialization)
[2)Hooking 8](#hooking)
[3)Creating the window 16](#creating-the-window)
[4)Create Device 16](#create-device)
[5) Create Factory 22](#create-factory)
[6) Create Device Context 28](#create-a-device-context)
[7)Create Composition Device 29](#create-a-composition-device)
[8)Calling hook3 function 31](#calling-dcompositioncreatedevice-function)
[9)Creating target for HWND 32](#creating-a-target-for-handle-hwnd)
[10)Creating Surface 33](#creating-surface)
[11)Calling BeginDraw, EndDraw, and CreateVisual. 34](#calling-begindraw-enddraw-and-createvisual)
[11)Calling Visual SetContent 36](#calling-visual-setcontent)
[12)Release objects 38](#release-objects)
[13)Commit Composition Device 38](#commit-composition-device)
[14)Calling hook2 39](#calling-hook2)
[15)Calling 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)Calling hook4 41](#calling-the-function-hook4)
[17)Performing Heap Spray 49](#performing-heap-spray)
[18)Modifying the base chunk previous to send. 51](#modifying-the-base-chunk-before-send)
[19)Debugging the process DWM 52](#debugging-the-dwm-process)
[20)Elevating Privileges to Integrity System level 62](#elevating-privileges-to-integrity-system-level)
Windows DWM Core Library Elevation of Privilege Vulnerability CVE-2024-30051
Date de publication : 14 mai 2024
CNA d'attribution : Microsoft CVE-2024-30051
Impact : Élévation de privilège
Sévérité maximale : Important
Faiblesse :
CWE-122 : Débordement de tampon basé sur le tas
CVSS : 3.1 7.8 / 7.2
La vulnérabilité existe en raison d'une erreur de calcul de taille dans une division entière au sein de la bibliothèque principale Windows DWM appelée dwmcore.dll. Un utilisateur local peut provoquer un débordement de tampon sur le tas dans la méthode CCommandBuffer::Initialize de dwmcore.dll et peut exécuter du code arbitraire avec l'utilisateur DWM disposant de privilèges Integrity System. L'exploit effectuera un Heap Spray dans le processus DWM pour préparer la mémoire et produit finalement un débordement de tas dans dwmcore.dll qui sera déclenché en libérant certaines parties du Heap Spray.
Une fois l'exploit réussi, le processus DWM chargera notre DLL conçue qui exécute notre code ou notre exécutable (dans notre cas un CMD) en tant qu'utilisateur DWM, lequel possède des privilèges Integrity System.
Parcourons cette vulnérabilité et voyons comment elle nous permet de s'exécuter en tant qu'utilisateur DWM avec le niveau d'intégrité SYSTEM. Notez que, comme il ne s'agit pas d'un utilisateur appartenant au groupe Administrateur, il a certaines restrictions de privilèges.
Le correctif pour Windows 11 23H2 peut être téléchargé depuis :
https://www.catalog.update.microsoft.com/Search.aspx?q=KB5037771
windows11.0-kb5037771-x64_19a3f100fb8437d059d7ee2b879fe8e48a1bae42.msu
La version vulnérable de dwmcore.dll est : 10.0.22621.3447
La version corrigée de dwmcore.dll est : 10.0.22621.3593
En analysant les fonctions modifiées, il est clair que la version corrigée de CCommandBuffer::Initialize a beaucoup de blocs ajoutés, ce qui la rend assez différente de la version non corrigée.
Après une rétro-ingénierie statique de cette fonction, il y a deux appels à CD2DSharedBuffer::GetBufferSize.
Le premier appel obtient la taille à allouer dans le new et le second appel obtient la même taille pour le memcpy.
Tout semble correct au départ. Cependant, avant l'allocation, elle effectue certaines opérations avec la taille.
Elle obtient buffer_size et buffer_size2 en appelant la même fonction CD2DSharedBuffer::GetBufferSize, les deux renvoient la même valeur. Mais dans le new, elle effectue une pré-opération, une division entière de buffer_size par 0x90 puis multiplication par 0x90, tandis que dans le memcpy, elle utilise la valeur retournée buffer_size2 sans opération.
Avec ces opérations, j'ai découvert que la taille finalement utilisée dans le new et dans le memcpy peut être différente.
buffer_size = buffer_size2 (tailles retournées)
size_new = buffer_size / 0x90 * 0x90
size_memcpy = buffer_size2
Par exemple, si buffer_size est 0x91
buffer_size = buffer_size2 = 0x91
size_new = buffer_size / 0x90 * 0x90 = 0x90
size_memcpy = buffer_size2 = 0x91
Cet exemple prouve qu'il y a un débordement de tas. Il copie plus d'octets que ce qui a été alloué, et la taille est contrôlable.
Par exemple, si buffer_size est 0x23f comme utilisé dans le POC.
buffer_size = buffer_size2 = 0x23F
