Analyse des vulnérabilités graves du système Windows de Microsoft : pourrait mettre en péril la sécurité de l'écosystème Web3
Le mois dernier, un correctif de sécurité publié par Microsoft a corrigé une vulnérabilité d'escalade de privilèges de Windows exploitée par des pirates. Cette vulnérabilité affecte principalement les anciennes versions du système Windows, et Windows 11 semble ne pas être affecté.
Cet article analysera comment les attaquants continuent d'exploiter ce type de vulnérabilités dans le contexte de renforcement constant des mesures de sécurité. Notre analyse est basée sur Windows Server 2016.
Contexte de la vulnérabilité
Il s'agit d'une vulnérabilité 0day, c'est-à-dire d'une vulnérabilité qui n'a pas encore été rendue publique ni corrigée. Les hackers peuvent l'exploiter à l'insu des utilisateurs, ce qui peut causer des dommages considérables.
Grâce à cette vulnérabilité au niveau du système Windows, les hackers peuvent obtenir un contrôle total sur le système. Cela peut entraîner des fuites d'informations personnelles, des pannes de système, des pertes de données, des pertes financières et d'autres conséquences graves. Pour les utilisateurs de Web3, les clés privées et les actifs numériques peuvent être volés. D'un point de vue plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur une infrastructure Web2.
Analyse des correctifs
L'analyse du code du patch indique que le problème semble provenir d'un comptage des références d'un objet qui a été mal géré une fois de trop. En examinant les commentaires du code antérieur, nous découvrons que le code précédent ne verrouillait que l'objet fenêtre, sans verrouiller l'objet menu dans la fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet menu.
Reproduction de la vulnérabilité
En analysant le contexte de la fonction de vulnérabilité, nous avons découvert que le menu passé à xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure, il y a donc une question sur quel objet de menu doit être protégé.
Une analyse plus approfondie révèle que la fonction MenuItemState dans xxxEnableMenuItem retourne deux types de menus : le menu principal de la fenêtre ou un sous-menu (, voire un sous-sous-menu ).
Nous avons construit une structure de menu spéciale à quatre niveaux pour déclencher des vulnérabilités. Ces menus doivent répondre à certaines conditions spécifiques pour passer les vérifications dans la fonction. La clé est de supprimer certaines relations de référence entre les menus lorsque xxxRedrawTitle retourne au niveau utilisateur, libérant ainsi des objets de menu spécifiques. De cette façon, au moment où la fonction xxxEnableMenuItem retourne, l'objet de menu référencé sera déjà invalide.
Exploitation de vulnérabilité
Lors du développement d'un exploit (exp), nous avons principalement envisagé deux options :
Exécution du code shell: se référer à des vulnérabilités similaires antérieures, mais il pourrait y avoir certains obstacles dans les nouvelles versions de Windows.
Modifier l'adresse du token en utilisant des primitives de lecture/écriture : cette méthode a récemment encore des exemples publics disponibles, et elle a une bonne universalité en ce qui concerne la disposition de la mémoire en tas sur le bureau et les primitives de lecture/écriture.
Nous avons choisi la deuxième option, qui divise l'ensemble du processus d'exploitation en deux étapes : comment exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, et comment réaliser de manière stable les primitives de lecture et d'écriture.
La clé est de trouver un emplacement dans une structure d'adresse que nous pouvons construire, où des données peuvent être écrites librement. Nous avons finalement choisi de le réaliser par une opération AND sur un indicateur dans la fonction xxxRedrawWindow.
Pour réaliser une disposition mémoire stable, nous avons conçu au moins trois objets HWND consécutifs de 0x250 octets, en libérant l'objet du milieu, qui est remplacé par un objet HWNDClass. Les objets HWND aux deux extrémités sont utilisés respectivement pour vérifier par fonction et réaliser les primitives de lecture et d'écriture finales.
Nous déterminons également avec précision si les objets sont disposés comme prévu en utilisant les adresses des handles de noyau divulguées. En ce qui concerne les primitives de lecture et d'écriture, nous utilisons GetMenuBarInfo() pour réaliser des lectures arbitraires, et SetClassLongPtr() pour réaliser des écritures arbitraires.
Conclusion
Microsoft essaie de refondre le code lié à win32k en Rust, à l'avenir, ce type de vulnérabilités pourrait être éliminé dans le nouveau système.
L'exploitation de ce type de vulnérabilité est relativement simple, reposant principalement sur la divulgation de l'adresse du gestionnaire de tas de bureau. Si ce problème n'est pas résolu de manière exhaustive, les anciens systèmes continueront à faire face à des risques de sécurité.
La découverte de cette vulnérabilité pourrait être attribuée à des techniques de détection de couverture de code plus avancées.
Pour la détection des exploitations de vulnérabilités, en plus de surveiller les fonctions clés, il convient également de prêter attention aux dispositions de mémoire anormales et aux comportements de lecture et d'écriture des données.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
9 J'aime
Récompense
9
6
Reposter
Partager
Commentaire
0/400
rug_connoisseur
· Il y a 1h
Encore une faille de Windows, on s'y habitue !
Voir l'originalRépondre0
rekt_but_not_broke
· 08-12 05:14
Gagner de l'argent ne peut pas attendre, protégez d'abord votre Portefeuille !
Voir l'originalRépondre0
MetaLord420
· 08-12 05:02
Jouer à Windows, c'est oser toucher au web3 ?!
Voir l'originalRépondre0
SighingCashier
· 08-12 05:00
Ce vieux système a ce problème, il aurait dû être remplacé depuis longtemps.
Voir l'originalRépondre0
ForkMaster
· 08-12 04:59
prendre les gens pour des idiots ne fonctionne plus ? exploitation de failles pour Mining ?
Les vulnérabilités du système Windows menacent la sécurité de l'écosystème Web3 Analyse approfondie des mécanismes d'exploitation par des experts
Analyse des vulnérabilités graves du système Windows de Microsoft : pourrait mettre en péril la sécurité de l'écosystème Web3
Le mois dernier, un correctif de sécurité publié par Microsoft a corrigé une vulnérabilité d'escalade de privilèges de Windows exploitée par des pirates. Cette vulnérabilité affecte principalement les anciennes versions du système Windows, et Windows 11 semble ne pas être affecté.
Cet article analysera comment les attaquants continuent d'exploiter ce type de vulnérabilités dans le contexte de renforcement constant des mesures de sécurité. Notre analyse est basée sur Windows Server 2016.
Contexte de la vulnérabilité
Il s'agit d'une vulnérabilité 0day, c'est-à-dire d'une vulnérabilité qui n'a pas encore été rendue publique ni corrigée. Les hackers peuvent l'exploiter à l'insu des utilisateurs, ce qui peut causer des dommages considérables.
Grâce à cette vulnérabilité au niveau du système Windows, les hackers peuvent obtenir un contrôle total sur le système. Cela peut entraîner des fuites d'informations personnelles, des pannes de système, des pertes de données, des pertes financières et d'autres conséquences graves. Pour les utilisateurs de Web3, les clés privées et les actifs numériques peuvent être volés. D'un point de vue plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur une infrastructure Web2.
Analyse des correctifs
L'analyse du code du patch indique que le problème semble provenir d'un comptage des références d'un objet qui a été mal géré une fois de trop. En examinant les commentaires du code antérieur, nous découvrons que le code précédent ne verrouillait que l'objet fenêtre, sans verrouiller l'objet menu dans la fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet menu.
Reproduction de la vulnérabilité
En analysant le contexte de la fonction de vulnérabilité, nous avons découvert que le menu passé à xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure, il y a donc une question sur quel objet de menu doit être protégé.
Une analyse plus approfondie révèle que la fonction MenuItemState dans xxxEnableMenuItem retourne deux types de menus : le menu principal de la fenêtre ou un sous-menu (, voire un sous-sous-menu ).
Nous avons construit une structure de menu spéciale à quatre niveaux pour déclencher des vulnérabilités. Ces menus doivent répondre à certaines conditions spécifiques pour passer les vérifications dans la fonction. La clé est de supprimer certaines relations de référence entre les menus lorsque xxxRedrawTitle retourne au niveau utilisateur, libérant ainsi des objets de menu spécifiques. De cette façon, au moment où la fonction xxxEnableMenuItem retourne, l'objet de menu référencé sera déjà invalide.
Exploitation de vulnérabilité
Lors du développement d'un exploit (exp), nous avons principalement envisagé deux options :
Exécution du code shell: se référer à des vulnérabilités similaires antérieures, mais il pourrait y avoir certains obstacles dans les nouvelles versions de Windows.
Modifier l'adresse du token en utilisant des primitives de lecture/écriture : cette méthode a récemment encore des exemples publics disponibles, et elle a une bonne universalité en ce qui concerne la disposition de la mémoire en tas sur le bureau et les primitives de lecture/écriture.
Nous avons choisi la deuxième option, qui divise l'ensemble du processus d'exploitation en deux étapes : comment exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, et comment réaliser de manière stable les primitives de lecture et d'écriture.
La clé est de trouver un emplacement dans une structure d'adresse que nous pouvons construire, où des données peuvent être écrites librement. Nous avons finalement choisi de le réaliser par une opération AND sur un indicateur dans la fonction xxxRedrawWindow.
Pour réaliser une disposition mémoire stable, nous avons conçu au moins trois objets HWND consécutifs de 0x250 octets, en libérant l'objet du milieu, qui est remplacé par un objet HWNDClass. Les objets HWND aux deux extrémités sont utilisés respectivement pour vérifier par fonction et réaliser les primitives de lecture et d'écriture finales.
Nous déterminons également avec précision si les objets sont disposés comme prévu en utilisant les adresses des handles de noyau divulguées. En ce qui concerne les primitives de lecture et d'écriture, nous utilisons GetMenuBarInfo() pour réaliser des lectures arbitraires, et SetClassLongPtr() pour réaliser des écritures arbitraires.
Conclusion
Microsoft essaie de refondre le code lié à win32k en Rust, à l'avenir, ce type de vulnérabilités pourrait être éliminé dans le nouveau système.
L'exploitation de ce type de vulnérabilité est relativement simple, reposant principalement sur la divulgation de l'adresse du gestionnaire de tas de bureau. Si ce problème n'est pas résolu de manière exhaustive, les anciens systèmes continueront à faire face à des risques de sécurité.
La découverte de cette vulnérabilité pourrait être attribuée à des techniques de détection de couverture de code plus avancées.
Pour la détection des exploitations de vulnérabilités, en plus de surveiller les fonctions clés, il convient également de prêter attention aux dispositions de mémoire anormales et aux comportements de lecture et d'écriture des données.