Analyse des vulnérabilités graves du système Microsoft Windows

Récemment, un correctif de sécurité publié par Microsoft a réparé une vulnérabilité d'élévation de privilèges du noyau Windows qui était exploitée par des hackers. Cette vulnérabilité affecte principalement les anciennes versions du système Windows et ne peut pas être déclenchée sur Windows 11. Ce type de vulnérabilité existe depuis longtemps. Cet article explorera comment, dans le contexte actuel d'un renforcement constant de la sécurité, les attaquants continuent d'exploiter ce type de vulnérabilité.

Cette analyse a été réalisée dans un environnement Windows Server 2016.

Contexte de la vulnérabilité

Il s'agit d'une vulnérabilité de type zero-day, qui désigne une faille système non divulguée et non corrigée. Les hackers peuvent exploiter cette vulnérabilité zero-day pour lancer des attaques sans que les utilisateurs ne s'en aperçoivent, ce qui peut être extrêmement destructeur.

La vulnérabilité de jour zéro découverte cette fois-ci existe au niveau du noyau du système Windows, permettant aux hackers d'obtenir un contrôle complet sur Windows. Cela peut entraîner des conséquences graves telles que la fuite de la vie privée des utilisateurs, des pannes de système, des pertes de données et des pertes financières. D'un point de vue Web3, les clés privées des utilisateurs pourraient être volées, et les actifs numériques seraient exposés à un risque de transfert. Plus largement, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur une infrastructure Web2.

Analyse des vulnérabilités

En analysant le code de patch, nous avons découvert que le problème provenait d'un comptage de références d'un objet étant traité plusieurs fois. En consultant les commentaires du code source win32k antérieur, on peut comprendre que le code précédent ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet de menu au sein de l'objet de fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet de menu.

Une analyse plus approfondie révèle que le menu passé à la fonction xxxEnableMenuItem() est généralement verrouillé dans une fonction supérieure. Alors, quel objet de menu doit être protégé ici ? Après étude, il s'avère que la fonction MenuItemState dans xxxEnableMenuItem retourne deux types de menus possibles : le menu principal de la fenêtre, ou un sous-menu(, voire un sous-sous-menu).

Exploitation de vulnérabilité

Pour vérifier la vulnérabilité, nous avons construit une structure de menu spéciale à quatre niveaux et défini certaines conditions spécifiques :

1. L'ID du menu de niveau inférieur D doit être de type menu système, comme fermer le menu (0xf060)
2. Le menu supérieur A doit également être un menu système, mais il faut supprimer l'élément de menu 0xf060.
3. Supprimer la référence du menu C dans le menu B
4. La présence du menu B semble avoir un impact sur la libération du menu C.

Lorsqu'une vulnérabilité est déclenchée, supprimez l'association des menus C et B lors du retour de xxxRedrawTitle au niveau utilisateur, ce qui permet de libérer avec succès le menu C. Lorsque la fonction xxxEnableMenuItem dans le noyau retourne à xxxRedrawTitle, l'objet de menu C qui allait être référencé est déjà invalide.

Analyse des exploitations de vulnérabilités

Lors de la conception d'un plan d'exploitation des vulnérabilités, nous avons principalement considéré deux directions :

1. Exécution de shellcode : se référer aux méthodes des anciens CVE-2017-0263 et CVE-2016-0167. Cependant, dans les versions récentes de Windows, le point d'entrée d'exécution du shellcode et des mécanismes de sécurité tels que SMEP peuvent poser des obstacles.

2. Modifier l'adresse du token en utilisant des primitives de lecture-écriture : cette méthode présente une bonne polyvalence. L'essentiel est d'analyser comment contrôler pour la première fois cbwndextra en tant que valeur très grande lors de la réutilisation de la mémoire UAF.

Nous divisons l'exploitation des vulnérabilités en deux étapes : contrôler la valeur de cbwndextra et réaliser des primitives de lecture/écriture stables.

Première écriture de données

Les erreurs système liées à l'utilisation des données d'objet de fenêtre dans la mémoire contrôlée se produisent principalement dans les fonctions xxxEnableMenuItem MNGetPopupFromMenu() et xxxMNUpdateShownMenu(). Nous utilisons la mémoire des objets de menu libérés occupée par le nom de l'objet de classe de fenêtre WNDClass.

La clé est de trouver une structure d'adresse qui peut être écrite de manière arbitraire, même si ce n'est qu'un octet. Nous avons finalement choisi la solution dans la fonction xxxRedrawWindow, en écrivant dans le cb-extra de HWNDClass via l'opération AND 2.

disposition de la mémoire

Nous avons conçu la disposition mémoire de trois objets HWND de 0x250 octets consécutifs, en libérant l'objet intermédiaire et en utilisant un objet HWNDClass de 0x250 octets. Les données de la fin du précédent objet HWND sont utilisées pour la vérification via xxxRedrawWindow, et le menu de l'objet HWND suivant ainsi que l'objet HWNDClass sont utilisés pour les opérations de lecture et d'écriture finales.

Nous essayons de rendre la taille de l'objet fenêtre et de l'objet HWNDClass cohérente, et nous déterminons précisément si l'agencement des objets est conforme aux attentes grâce à l'adresse du handle noyau divulguée.

lire et écrire des primitives

Pour lire n'importe quel langage d'origine, utilisez GetMenuBarInfo(), pour écrire n'importe quel langage d'origine, utilisez SetClassLongPtr(). À l'exception de l'écriture de TOKEN, toutes les autres écritures utilisent l'objet de classe du premier objet fenêtre pour effectuer une écriture décalée.

Résumé

1. Microsoft est en train de reconstruire le code noyau lié à win32k avec Rust, à l'avenir, ce type de vulnérabilités pourrait être éliminé dans le nouveau système.

2. Le processus d'exploitation de cette vulnérabilité est relativement simple, reposant principalement sur la fuite des adresses des poignées de tas de bureau. Si ce problème n'est pas résolu de manière adéquate, les anciens systèmes continueront de présenter des risques de sécurité.

3. La découverte de cette vulnérabilité peut être attribuée à une détection de couverture de code plus complète.

4. En ce qui concerne la détection des exploits de vulnérabilité, en plus de se concentrer sur les points clés des fonctions déclenchant la vulnérabilité, il convient également de prêter attention à la détection des décalages anormaux de lecture et d'écriture des données supplémentaires liées à la disposition de la mémoire et aux classes de fenêtres.