emilc3978/cve-2022-37969pocTutoriel sur CVE-2022-37969 axé sur la méthodologie d'exploitation du noyau, et non sur les causes internes de la CVE.
Ce document a été créé pour clarifier les aspects généraux concernant l'exploitation de Windows. Il explique les concepts de base appliqués à CVE-2022-37969. Le résultat final est un PoC fonctionnel. Il ne clarifie pas tous les aspects de la CVE, mais fournit des morceaux de code réutilisables et explique des mécanismes que l'on retrouve dans de nombreux exploits généraux.
L'utilisateur cible serait un ingénieur en rétro-ingénierie débutant, un développeur d'exploits cherchant un code source de preuve de concept fonctionnel pour tester et comprendre les bases des internals Windows. Il fournit un point de référence pour approfondir l'apprentissage.
Prérequis : débogage noyau de base, rétro-ingénierie de base, internals Windows de base, compétences en programmation c/c++
Un programme est un morceau de code qui s'exécute sur une machine. Généralement, un programme reçoit des données (entrée), effectue des calculs à partir des entrées et génère des données (sortie). La plupart des programmes sont écrits par des humains et contiennent donc des bogues. Un bogue est généré par un code source qui n'a pas été écrit correctement (le programmeur voulait faire quelque chose avec l'entrée, le code résultant était différent du résultat attendu). La plupart des bogues sont corrigés avant le lancement du produit, mais certains subsistent. Cela arrive car il existe différents types de bogues, certains plus difficiles à repérer que d'autres.
Windows est un programme informatique, écrit par des humains, et contient donc des bogues. Pourquoi est-ce important ? Parce que les systèmes Windows peuvent exécuter des programmes qui traitent des données sensibles comme des comptes bancaires, des bases de données de soins de santé, etc. Certains bogues peuvent être utilisés pour accéder illégalement à des données restreintes (c'est un bon cas d'usage pour un exploit).
Il existe de nombreux types de bogues, certains utiles, d'autres non. En général, les bogues sont générés par des entrées du programme qui, combinées aux lignes de code mal écrites, produisent une sortie ou un comportement anormal du programme. Trouver cette entrée est le travail du spécialiste en sécurité (ou du hacker). L'étape suivante consiste à évaluer la sortie/le comportement anormal obtenu et à répondre à la question « Peut-il être utilisé de manière utile ? ». C'est là que les bogues sont classés en différentes catégories. Par exemple, un bogue peut provoquer un comportement qui corrompt certaines structures de données et fait redémarrer l'ordinateur cible. Son utilité est limitée. Un bogue peut faire en sorte que l'entrée soit écrite dans une zone mémoire qui contrôle les permissions d'accès à des fichiers restreints. Ce type de bogue est plus utile.
Ainsi, parmi l'ensemble des bogues possibles, le hacker recherche le sous-ensemble le plus utile à son objectif. D'une manière générale, le problème est : « Puis-je fournir au programme cible une entrée spécialement conçue pour ne pas casser le système mais pour élever mon niveau d'accès et en tirer profit ? »
Après cette introduction non technique, le périmètre du tutoriel peut être formulé : Pouvons-nous trouver un programme Windows qui accepte une entrée malformée et qui, en raison d'un code développeur incorrect, peut élever illégalement nos permissions d'utilisateur standard à administrateur ?
Programme cible : Windows CLFS (Common Log File System Driver)
Nom de l'exploit : CVE-2022-37969
Type : Élévation de privilèges locale
TÉLÉCHARGEMENT DE L'ISO VULNÉRABLE : Télécharger ici
L'espace d'adressage de Windows est grossièrement divisé entre l'espace utilisateur (exécution des programmes généraux) et l'espace noyau (exécution du système d'exploitation lui-même et des logiciels de composants matériels --> pilotes). Un utilisateur standard ne doit pas accéder à l'espace noyau, mais il existe des mécanismes par lesquels les programmes utilisateur standard peuvent accéder à certaines parties du code noyau (appels système, procédures de pilotes). Pourquoi avons-nous besoin d'y accéder ? Pour interagir avec l'OS de manière sécurisée et contrôlée, comme prévu par les concepteurs de l'OS.
Certains pilotes utilisent des données d'entrée fournies par l'utilisateur pour opérer sur des structures de données de l'espace noyau. Si l'entrée génère un bogue, le noyau peut être corrompu. Un exemple est le Common Log File System Driver. En utilisant une entrée spéciale, nous pouvons forcer le pilote à modifier les structures de données du noyau qui contiennent le niveau de privilège d'accès de l'utilisateur et remplacer utilisateur standard par administrateur.
Que faut-il modifier pour élever le privilège au niveau administrateur ?
Nous commençons avec l'objectif final en tête. Windows stocke, dans une structure de données du noyau nommée _EPROCESS, des informations pour chaque processus en cours d'exécution sur le système. Exemple de _Eprocess
Un champ important est struct _EX_FAST_REF Token. C'est une autre structure de données qui pointe vers des données référençant le niveau de privilège du processus concerné. Sur l'image suivante, le processus System possède un jeton système et le processus Explorer possède un jeton d'utilisateur standard.
Ainsi, pour élever le privilège de Explorer.exe, il faudrait copier la valeur de _EPROCESS-->Token de System vers _EPROCESS-->Token de Explorer. Nous accomplirons quelque chose de similaire en copiant le jeton de System dans le jeton de notre propre programme et en lançant une invite de commandes depuis le processus élevé (les processus enfants héritent du jeton du processus parent).
Pour mener à bien ces actions, nous avons besoin de mécanismes pour :
Introduction : la nature de Windows au fil des ans : Comme pour la découverte de nouvelles vulnérabilités, Windows a eu besoin de correctifs pour les atténuer. De plus, avec l'émergence de nouvelles technologies, Windows a eu besoin de mises à jour pour rester compétitif. Une exigence cruciale était la rétrocompatibilité avec les versions précédentes. Et parfois, la sécurité était obtenue par l'obscurité. Des structures de données, des définitions de fonctions ont été retirées des documentations, mais la fonctionnalité est restée. Grâce à la rétro-ingénierie, les chercheurs ont pu utiliser ces fonctionnalités à diverses fins.
Pour trouver l'adresse noyau de _EPROCESS, nous utiliserons une fonction non documentée : NtQuerySystemInformation (voir le lien pour les paramètres). En utilisant le paramètre SystemInformationClass, nous pouvons spécifier le type d'informations que nous voulons récupérer. Nous récupérerons les informations générales des processus en spécifiant la valeur SystemExtendedHandleInformation (#define SystemExtendedHandleInformation 0x40).
