{"id":598,"date":"2019-09-28T11:08:15","date_gmt":"2019-09-28T09:08:15","guid":{"rendered":"http:\/\/pentester.blog\/?p=598"},"modified":"2020-05-21T19:49:52","modified_gmt":"2020-05-21T17:49:52","slug":"windows-tuto-exploitation-dun-driver-vulnerable-1","status":"publish","type":"post","link":"https:\/\/hacktarus.fr\/?p=598","title":{"rendered":"Windows – [TUTO] Exploitation d’un driver vuln\u00e9rable [1]"},"content":{"rendered":"\n

On a vu dans les pr\u00e9c\u00e9dents posts [1<\/a>] [2<\/a>] que depuis l’espace Kernel il est possible (sous certaines conditions) d’\u00e9lever ses privil\u00e8ges utilisateurs en modifiant son propre Access Token. Dans la d\u00e9mo c’\u00e9tait facile car on disposait d’une VM en mode debug Kernel et on avait le contr\u00f4le total de la VM utilisateur mais dans la vrai vie c’est diff\u00e9rent. Il va falloir trouver un autre moyen de se retrouver dans l’espace Kernel depuis l’espace utilisateur. Et m\u00eame si (par bonheur) on y arrive il va falloir faire la m\u00eame chose que ce qu’on avait fait sous WinDbg [1] mais cette-fois en programmation. <\/p>\n\n\n\n

Premi\u00e8re \u00e9tape (et non des moindres), passer de l’espace utilisateur \u00e0 l’espace Kernel<\/strong><\/p>\n\n\n\n

C’est un vaste sujet et apr\u00e8s r\u00e9flexion je me suis dis que le plus simple est de montrer l’exploitation d’un driver volontairement vuln\u00e9rable. Je m’explique. Comme vous le savez les drivers sont charg\u00e9s dans l’espace Kernel donc si on tombe sur un driver un peu bugg\u00e9 et qu’on arrive \u00e0 le faire planter via un d\u00e9bordement m\u00e9moire (un beau Stack Overflow) et \u00e0 y ex\u00e9cuter notre propre code alors on aura atteint notre premier objectif. Parfait mais plut\u00f4t que de prendre un vrai driver du commerce vuln\u00e9rable (on verra \u00e7a dans un prochain post), on va commencer plus simple, par un driver volontairement bugg\u00e9 dont on dispose du code source. Cela tombe bien y a un gars qui a fait \u00e7a, il est disponible ici : https:\/\/github.com\/hacksysteam\/HackSysExtremeVulnerableDriver<\/a> <\/p>\n\n\n\n

Je vous passe les d\u00e9tails de l’installation du driver, interressons-nous directement \u00e0 la programmation. Quel est notre objectif ? Charger le driver, faire quelques appels et si possible le faire planter. Pour charger le driver, cela para\u00eet b\u00eate mais il faut conna\u00eetre son nom, attention on ne parle pas du nom du fichier mais de son petit nom connu par le syst\u00e8me. Y a plusieurs fa\u00e7on de le r\u00e9cup\u00e9rer mais un moyen simple est d’utiliser un outil de Sysinternals bien connu, WinObj. Voici par exemple le nom du driver vuln\u00e9rable que l’on cherche \u00e0 charger :<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

On obtient le m\u00eame r\u00e9sultat avec un autre outil, Dos Device Inspector :<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Bon maintenant qu’on sait que le driver s’appelle HackSysExtremeVulnerableDriver il va falloir qu’on s’interesse aux IOCTL. Hein ? Ben oui il faut bien qu’on puisse interagir avec le driver, faire des appels pour qu’il fasse des choses, et bien cela passe justement par les IOCTL. En fait c’est simple. C\u00f4t\u00e9 driver, il y a un point d’entr\u00e9e responsable de la r\u00e9ception des appels clients et du dispatch en fonction du code de contr\u00f4le envoy\u00e9 par le client. C’est la fonction Windows DeviceIoControl qui nous permet de communiquer avec le driver, https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/api\/ioapiset\/nf-ioapiset-deviceiocontrol<\/a> <\/p>\n\n\n\n

Ok, on a compris qu’avec cette fonction on va pouvoir faire des appels au driver mais comment on sait quel \u00ab\u00a0Control Code\u00a0\u00bb on pourra envoyer au driver ? C’est l\u00e0 o\u00f9 \u00e7a se corse, dans la vrai vie on n’a pas acc\u00e8s au code source. Il faudra donc faire autrement via du reverse engineering, via un monitoring des appels, et j’en passe mais dans notre cas d’\u00e9cole c’est plus simple car on dispose du code source. Tous les codes de contr\u00f4le sont d\u00e9finis dans le fichier hevd_common.h, ils commencent \u00e0 0x800 et se terminent \u00e0 0x80D.<\/p>\n\n\n\n

Avec le nom du driver et les codes de contr\u00f4le on a ce qui faut pour d\u00e9marrer la programmation. On va charger le driver puis s’amuser \u00e0 lui envoyer des cha\u00eenes de caract\u00e8res de plus en longues pour finalement le faire planter (au passage \u00e7a s’appelle du fuzzing).<\/p>\n\n\n\n

Vu qu’on sait que le driver est vuln\u00e9rable, \u00e0 un moment il va planter, mais comme on est dans l’espace Kernel on aura droit \u00e0 un bel \u00e9cran bleu. Le mieux est de repartir sur la plateforme vue dans le premier post avec les 2 VM, l’une \u00e9tant le d\u00e9bugger et la seconde le debuggee. Ce n’est pas anodin, on aura acc\u00e8s \u00e0 la m\u00e9moire, \u00e0 la stack et aux registres AVANT le crash.<\/p>\n\n\n\n

Ok, allons-y pour le code. Commen\u00e7ons par charger le driver. Je vous renvoie \u00e0 la doc Microsoft https:\/\/docs.microsoft.com\/en-us\/windows-hardware\/drivers\/kernel\/introduction-to-ms-dos-device-names<\/a> qui dit ceci :<\/p>\n\n\n\n

To access the <\/em>DosDevices<\/em><\/strong> namespace from user mode, specify <\/em>\\\\.\\<\/em><\/strong> when you open a file name. You can open a corresponding device in user mode by calling <\/em>CreateFile()<\/em><\/strong>. <\/em><\/p>\n\n\n\n

OK mais comme on est en langage C et qu’il faut doubler les antislashs \u00ab\u00a0\\\u00a0\u00bb il faut coder quelque chose comme ceci :<\/p>\n\n\n\n

HANDLE device = CreateFileA(\"\\\\\\\\.\\\\HackSysExtremeVulnerableDriver\",\n         GENERIC_READ | GENERIC_WRITE,\n         NULL,\n         NULL,\n         OPEN_EXISTING,\n         NULL,\n         NULL\n     );<\/code><\/pre>\n\n\n\n
Ok maintenant on va \u00e9crire la fonction qui envoie des buffers de donn\u00e9es au driver.  Comme dit plus haut on va utiliser la fonction DeviceIoControl. Regardons d’un peu plus pr\u00e8s les param\u00e8tres de cette fonction,  https:\/\/docs.microsoft.com\/en-us\/windows\/win32\/api\/ioapiset\/nf-ioapiset-deviceiocontrol<\/a> <\/p>\n\n\n\n
 BOOL DeviceIoControl(\n  HANDLE       hDevice,\n  DWORD        dwIoControlCode,\n  LPVOID       lpInBuffer,\n  DWORD        nInBufferSize,\n  LPVOID       lpOutBuffer,\n  DWORD        nOutBufferSize,\n  LPDWORD      lpBytesReturned,\n  LPOVERLAPPED lpOverlapped\n); <\/code><\/pre>\n\n\n\n