Analyse des vulnérabilités 0day de Microsoft : pourrait représenter une menace majeure pour l'infrastructure Web3

Le mois dernier, le correctif de sécurité de Microsoft contenait une vulnérabilité d'élévation de privilèges win32k exploitée dans la nature. Cette vulnérabilité semble n'exister que dans les anciennes versions de Windows et ne peut pas être déclenchée sur Windows 11.

L'exploitation de ce type de vulnérabilité existe depuis longtemps. Cet article analysera comment les attaquants pourraient continuer à exploiter cette vulnérabilité dans le contexte actuel d'amélioration continue des nouvelles mesures d'atténuation. Nous avons complété l'ensemble du processus d'analyse dans un environnement Windows Server 2016.

Les vulnérabilités 0day désignent des failles qui n'ont pas été divulguées ni corrigées, et qui peuvent être exploitées de manière malveillante sans être détectées, présentant un grand potentiel de destruction. La vulnérabilité 0day récemment découverte se situe au niveau du système Windows, permettant aux hackers d'obtenir un contrôle total sur Windows.

Le contrôle du système par des hackers peut entraîner des fuites d'informations personnelles, des pannes système, des pertes de données, des pertes financières, et l'insertion de logiciels malveillants. Pour les utilisateurs de Web3, les clés privées peuvent être volées et les actifs numériques transférés. À une échelle plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 fonctionnant sur une infrastructure Web2.

Analyse des correctifs

Après analyse du patch, il semble que le problème ne soit qu'un comptage de références d'un objet ayant été traité une fois de trop. Étant donné que le code win32k est relativement ancien, nous pouvons trouver certaines anciennes annotations de code source, indiquant que l'ancien code ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet de menu dans cet objet de fenêtre, où l'objet de menu pourrait avoir été référencé par erreur.

Preuve de concept d'exploitation de vulnérabilité ( PoC )

Nous avons découvert que le menu xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Une analyse plus approfondie a révélé que la fonction MenuItemState dans xxxEnableMenuItem renvoie deux possibilités de menu : le menu principal de la fenêtre ou un sous-menu dans le menu(, voire un sous-sous-menu).

Dans le PoC, nous avons construit une structure de menu à quatre niveaux spéciale et défini des attributs spécifiques pour chaque niveau de menu, afin de détecter et de juger via la fonction xxxEnableMenuItem. Les étapes clés comprennent la suppression de certaines relations de référence de menu, et la libération d'objets de menu spécifiques lorsque xxxRedrawTitle retourne à la couche utilisateur, etc.

Exploitation de la vulnérabilité ( Exp) réalisation

Idée générale

Nous avons principalement considéré deux directions d'exploitation : l'exécution de code shellcode et l'exploitation des primitives de lecture/écriture pour modifier l'adresse du token. En tenant compte de divers facteurs, nous avons choisi la seconde.

L'ensemble de l'exp peut être décomposé en deux problèmes clés : comment exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, et comment réaliser des primitives de lecture/écriture stables après avoir contrôlé la valeur de cbwndextra.

Réaliser la première écriture de données

Nous utilisons l'objet de nom de fenêtre dans la classe de fenêtre WNDClass pour occuper et libérer l'objet de menu. La clé est de trouver un emplacement dans la structure d'adresse que nous pouvons construire où des données peuvent être écrites arbitrairement.

Finalement, nous avons choisi de réaliser l'écriture via un drapeau AND 2 dans la fonction xxxRedrawWindow. Nous écrivons dans le cb-extra de HWNDClass plutôt que dans le cb-extra de l'objet fenêtre, afin de mieux contrôler la disposition de la mémoire.

disposition de mémoire stable

Nous avons conçu la disposition de la mémoire de trois objets HWND de 0x250 octets consécutifs, en libérant le milieu et en occupant un objet HWNDClass de 0x250 octets. Les objets HWND avant et après sont utilisés respectivement pour vérifier les paramètres et comme intermédiaire pour les opérations de lecture/écriture.

Nous déterminons avec précision si l'objet de fenêtre demandé est disposé comme prévu grâce à l'adresse de gestionnaire de noyau divulguée dans la mémoire de la pile.

Modification des primitives de lecture et d'écriture

Nous utilisons GetMenuBarInfo() pour réaliser des lectures arbitraires, et SetClassLongPtr() pour réaliser des écritures arbitraires. À l'exception de l'opération d'écriture qui remplace le TOKEN, toutes les autres écritures sont effectuées en utilisant l'objet de classe de l'objet fenêtre principal avec un décalage.

Résumé

1. Bien que la vulnérabilité win32k existe depuis longtemps, Microsoft essaie de reconstruire le code du noyau associé en utilisant Rust, et à l'avenir, ce type de vulnérabilité pourrait être éradiqué dans les nouveaux systèmes.

2. Le processus d'exploitation de cette vulnérabilité est relativement simple, la principale difficulté résidant dans la manière de contrôler la première écriture. La vulnérabilité dépend toujours de la fuite de l'adresse du gestionnaire de tas de bureau, ce qui demeure un risque de sécurité pour les anciens systèmes.

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

4. Pour la détection d'exploitation de vulnérabilités, en plus de se concentrer sur les points clés des fonctions déclencheuses de vulnérabilités, il convient également de détecter de manière ciblée les mises en page de mémoire anormales et les opérations de lecture/écriture des données de fenêtres.