Analyse des vulnérabilités 0day du système Windows de Microsoft : pourrait avoir un impact majeur sur l'écosystème 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 ne pas pouvoir être déclenchée sur les versions de Windows 11, mais n'existe que sur les systèmes antérieurs. Cet article analysera comment les attaquants pourraient continuer à exploiter cette vulnérabilité dans le contexte actuel où de nouvelles mesures d'atténuation sont constamment améliorées. Le processus d'analyse a été réalisé dans un environnement Windows Server 2016.
Une vulnérabilité 0day fait référence à une vulnérabilité qui n'a pas été divulguée ou corrigée, pouvant être exploitée de manière malveillante par des attaquants sans être détectée, et qui présente souvent un potentiel de destruction considérable. La vulnérabilité 0day récemment découverte se situe au niveau du système Windows, et les hackers peuvent l'utiliser pour obtenir un contrôle total sur Windows. Cela pourrait entraîner le vol d'informations personnelles, des pannes de système, la perte de données, des pertes financières, ainsi que l'injection de logiciels malveillants. Du point de vue de Web3, les clés privées des utilisateurs 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 basée sur Web2.
L'analyse du patch révèle que le problème provient d'un comptage de références d'un objet qui a été traité une fois de trop. Les commentaires dans le code source antérieur montrent que le code précédent verrouillait uniquement l'objet de la fenêtre, sans verrouiller l'objet de menu à l'intérieur de l'objet de la fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet de menu.
Pour vérifier la vulnérabilité, nous avons implémenté un proof of concept ( PoC ). En construisant des menus imbriqués spéciaux, il est possible de déclencher la vulnérabilité dans la fonction xxxEnableMenuItem. La clé est de supprimer la relation de référence entre le menu C et le menu B au bon moment, afin de libérer avec succès l'objet du menu C. Ainsi, lorsque la fonction xxxEnableMenuItem retourne, l'objet du menu C qui allait être référencé est déjà invalide.
Lors de la mise en œuvre de l'exploitation de la vulnérabilité (Exp), nous avons principalement considéré deux solutions : exécuter du code shell et utiliser des primitives de lecture/écriture pour modifier l'adresse du token. Nous avons finalement choisi la seconde solution, car cette méthode dispose encore d'explications publiques de référence au cours des deux dernières années. L'ensemble du processus d'exploitation se divise en deux étapes : d'abord, exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, puis établir des primitives de lecture/écriture stables.
En concevant soigneusement la disposition de la mémoire, nous pouvons réaliser un contrôle précis des objets cibles. En utilisant respectivement les fonctions GetMenuBarInfo() et SetClassLongPtr(), nous mettons en œuvre des primitives de lecture et d'écriture arbitraires. À part le remplacement de l'opération d'écriture de TOKEN qui dépend de l'objet de classe de la deuxième fenêtre, toutes les autres écritures utilisent l'objet de classe de la première fenêtre avec un décalage pour écrire.
Dans l'ensemble, bien que la vulnérabilité win32k soit ancienne, Microsoft essaie de reconstruire cette partie du code du noyau en utilisant Rust, ce qui pourrait éliminer de telles vulnérabilités dans les nouveaux systèmes à l'avenir. Actuellement, l'exploitation de ce type de vulnérabilité n'est pas très difficile, reposant principalement sur la fuite de l'adresse du gestionnaire de tas du bureau. Pour les systèmes anciens, cela reste un risque d'insécurité.
Du point de vue de la découverte des vulnérabilités, une détection de la couverture de code plus complète pourrait aider à identifier ce type de vulnérabilités. En ce qui concerne la détection des exploits, en plus de se concentrer sur les points clés des fonctions déclenchant les vulnérabilités, il est également nécessaire d'effectuer une détection ciblée des anomalies de mise en mémoire et des lectures/écritures d'offsets anormaux des données supplémentaires de type fenêtre, ce qui pourrait être l'une des voies efficaces pour découvrir des vulnérabilités de même type.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
7 J'aime
Récompense
7
2
Partager
Commentaire
0/400
HalfIsEmpty
· Il y a 9h
Le Huazi a encore un problème, dépêche-toi de fuir.
Voir l'originalRépondre0
SignatureCollector
· Il y a 9h
Il faut encore changer d'ordinateur, n'est-ce pas ?
La vulnérabilité 0day de Windows menace la sécurité Web3, le risque de vol de Clé privée est en hausse.
Analyse des vulnérabilités 0day du système Windows de Microsoft : pourrait avoir un impact majeur sur l'écosystème 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 ne pas pouvoir être déclenchée sur les versions de Windows 11, mais n'existe que sur les systèmes antérieurs. Cet article analysera comment les attaquants pourraient continuer à exploiter cette vulnérabilité dans le contexte actuel où de nouvelles mesures d'atténuation sont constamment améliorées. Le processus d'analyse a été réalisé dans un environnement Windows Server 2016.
Une vulnérabilité 0day fait référence à une vulnérabilité qui n'a pas été divulguée ou corrigée, pouvant être exploitée de manière malveillante par des attaquants sans être détectée, et qui présente souvent un potentiel de destruction considérable. La vulnérabilité 0day récemment découverte se situe au niveau du système Windows, et les hackers peuvent l'utiliser pour obtenir un contrôle total sur Windows. Cela pourrait entraîner le vol d'informations personnelles, des pannes de système, la perte de données, des pertes financières, ainsi que l'injection de logiciels malveillants. Du point de vue de Web3, les clés privées des utilisateurs 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 basée sur Web2.
L'analyse du patch révèle que le problème provient d'un comptage de références d'un objet qui a été traité une fois de trop. Les commentaires dans le code source antérieur montrent que le code précédent verrouillait uniquement l'objet de la fenêtre, sans verrouiller l'objet de menu à l'intérieur de l'objet de la fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet de menu.
Pour vérifier la vulnérabilité, nous avons implémenté un proof of concept ( PoC ). En construisant des menus imbriqués spéciaux, il est possible de déclencher la vulnérabilité dans la fonction xxxEnableMenuItem. La clé est de supprimer la relation de référence entre le menu C et le menu B au bon moment, afin de libérer avec succès l'objet du menu C. Ainsi, lorsque la fonction xxxEnableMenuItem retourne, l'objet du menu C qui allait être référencé est déjà invalide.
Lors de la mise en œuvre de l'exploitation de la vulnérabilité (Exp), nous avons principalement considéré deux solutions : exécuter du code shell et utiliser des primitives de lecture/écriture pour modifier l'adresse du token. Nous avons finalement choisi la seconde solution, car cette méthode dispose encore d'explications publiques de référence au cours des deux dernières années. L'ensemble du processus d'exploitation se divise en deux étapes : d'abord, exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, puis établir des primitives de lecture/écriture stables.
En concevant soigneusement la disposition de la mémoire, nous pouvons réaliser un contrôle précis des objets cibles. En utilisant respectivement les fonctions GetMenuBarInfo() et SetClassLongPtr(), nous mettons en œuvre des primitives de lecture et d'écriture arbitraires. À part le remplacement de l'opération d'écriture de TOKEN qui dépend de l'objet de classe de la deuxième fenêtre, toutes les autres écritures utilisent l'objet de classe de la première fenêtre avec un décalage pour écrire.
Dans l'ensemble, bien que la vulnérabilité win32k soit ancienne, Microsoft essaie de reconstruire cette partie du code du noyau en utilisant Rust, ce qui pourrait éliminer de telles vulnérabilités dans les nouveaux systèmes à l'avenir. Actuellement, l'exploitation de ce type de vulnérabilité n'est pas très difficile, reposant principalement sur la fuite de l'adresse du gestionnaire de tas du bureau. Pour les systèmes anciens, cela reste un risque d'insécurité.
Du point de vue de la découverte des vulnérabilités, une détection de la couverture de code plus complète pourrait aider à identifier ce type de vulnérabilités. En ce qui concerne la détection des exploits, en plus de se concentrer sur les points clés des fonctions déclenchant les vulnérabilités, il est également nécessaire d'effectuer une détection ciblée des anomalies de mise en mémoire et des lectures/écritures d'offsets anormaux des données supplémentaires de type fenêtre, ce qui pourrait être l'une des voies efficaces pour découvrir des vulnérabilités de même type.