Analyse des vulnérabilités 0day de Microsoft : pourrait compromettre la sécurité des infrastructures Web3
Le mois dernier, le patch 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 versions système antérieures et ne peut pas être déclenchée sur Windows 11. L'exploitation de ce type de vulnérabilités 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 réalisé l'ensemble du processus d'analyse dans un environnement Windows Server 2016.
Les vulnérabilités 0day désignent des failles non divulguées et non corrigées, qui peuvent être exploitées de manière malveillante par des hackers sans être détectées, et qui sont souvent extrêmement destructrices. 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. Une fois contrôlé, cela peut entraîner le vol d'informations personnelles, des pannes de système, la perte de données, des pertes financières et l'injection de logiciels malveillants. À petite échelle, cela peut entraîner le vol de clés privées et le transfert d'actifs numériques ; à grande échelle, cela pourrait menacer l'ensemble de l'écosystème Web3 fonctionnant sur une infrastructure Web2.
L'analyse du patch montre qu'il semble s'agir simplement d'un problème de comptage de références d'objets traité plusieurs fois. Mais en examinant les commentaires dans le code source antérieur, on constate que le code précédent ne verrouillait que l'objet de fenêtre, sans verrouiller l'objet de menu dans l'objet de fenêtre, ce qui pourrait entraîner une référence incorrecte de l'objet de menu.
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. Alors, quel objet de menu devons-nous protéger ici ? Une analyse plus approfondie révèle que le menu retourné dans xxxEnableMenuItem peut être de deux types : le menu principal de la fenêtre ou un sous-menu du menu(, voire un sous-sous-menu).
Pour construire le POC, nous avons conçu une structure de menu spéciale en quatre niveaux et avons effectué des réglages spéciaux sur chaque menu pour permettre la détection par fonction. Lorsque xxxRedrawTitle retourne le niveau utilisateur, nous avons supprimé la relation de référence entre le menu C et le menu B, libérant avec succès le menu C. Ainsi, lorsque la fonction xxxEnableMenuItem retourne au point, l'objet de menu C référencé est déjà invalide.
Pour la réalisation d'EXP, nous avons principalement considéré deux directions : l'exécution de code shell et l'utilisation de primitives de lecture/écriture pour modifier l'adresse du token. Compte tenu des mécanismes de sécurité des versions récentes de Windows, nous avons choisi cette dernière. L'ensemble du processus d'exploitation peut être divisé en deux parties : comment exploiter la vulnérabilité UAF pour contrôler la valeur cbwndextra, et comment établir des primitives de lecture/écriture stables.
Nous avons conçu une disposition de mémoire soigneusement conçue, utilisant les objets de nom de fenêtre de la classe fenêtre pour occuper et libérer des objets de menu, et avons trouvé le moment propice pour écrire des données dans la fonction xxxRedrawWindow. Pour réaliser une disposition de mémoire stable, nous avons conçu une structure de trois objets HWND consécutifs, et nous avons déterminé avec précision l'ordre d'arrangement des objets en utilisant les adresses des poignées de noyau qui fuient dans la mémoire de tas.
En ce qui concerne la lecture et l'écriture des primitives, nous utilisons GetMenuBarInfo() pour réaliser une lecture arbitraire, et SetClassLongPtr() pour réaliser une écriture arbitraire. À part le remplacement de l'opération d'écriture TOKEN qui dépend de l'objet class de la deuxième fenêtre, toutes les autres écritures utilisent l'objet class de la première fenêtre via un offset.
Dans l'ensemble, bien que la vulnérabilité win32k soit ancienne, Microsoft a tenté de refondre cette partie du code du noyau avec Rust dans la version préliminaire de Windows 11, et à l'avenir, de telles vulnérabilités pourraient être éliminées. Le processus d'exploitation de cette vulnérabilité est relativement simple, la principale difficulté résidant dans la façon de contrôler la première écriture. La découverte de cette vulnérabilité pourrait dépendre d'une détection de couverture de code plus complète. En ce qui concerne la détection des vulnérabilités, en plus de se concentrer sur les points clés de la fonction déclencheuse, la détection des mises en page de mémoire anormales et des lectures et écritures de décalage de données est également une voie possible pour découvrir des vulnérabilités similaires.
Voir l'original
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.
16 J'aime
Récompense
16
5
Partager
Commentaire
0/400
TopBuyerBottomSeller
· Il y a 15h
Une autre raison de mettre à niveau vers Windows 11~
Voir l'originalRépondre0
FlatTax
· 07-20 03:35
Scandale, ne fais pas de tours, ancien Microsoft.
Voir l'originalRépondre0
SurvivorshipBias
· 07-20 03:34
De qui est ce système qui utilise encore win32k ?
Voir l'originalRépondre0
just_another_wallet
· 07-20 03:33
J'ai failli exploser mon vieux jeton, ça me donne des frissons.
Voir l'originalRépondre0
MrRightClick
· 07-20 03:14
La seule version du système que même les chiens ne peuvent pas apprécier est Windows 11.
Une vulnérabilité 0day de Microsoft révélée, la sécurité des infrastructures Web3 pourrait être menacée
Analyse des vulnérabilités 0day de Microsoft : pourrait compromettre la sécurité des infrastructures Web3
Le mois dernier, le patch 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 versions système antérieures et ne peut pas être déclenchée sur Windows 11. L'exploitation de ce type de vulnérabilités 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 réalisé l'ensemble du processus d'analyse dans un environnement Windows Server 2016.
Les vulnérabilités 0day désignent des failles non divulguées et non corrigées, qui peuvent être exploitées de manière malveillante par des hackers sans être détectées, et qui sont souvent extrêmement destructrices. 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. Une fois contrôlé, cela peut entraîner le vol d'informations personnelles, des pannes de système, la perte de données, des pertes financières et l'injection de logiciels malveillants. À petite échelle, cela peut entraîner le vol de clés privées et le transfert d'actifs numériques ; à grande échelle, cela pourrait menacer l'ensemble de l'écosystème Web3 fonctionnant sur une infrastructure Web2.
L'analyse du patch montre qu'il semble s'agir simplement d'un problème de comptage de références d'objets traité plusieurs fois. Mais en examinant les commentaires dans le code source antérieur, on constate que le code précédent ne verrouillait que l'objet de fenêtre, sans verrouiller l'objet de menu dans l'objet de fenêtre, ce qui pourrait entraîner une référence incorrecte de l'objet de menu.
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. Alors, quel objet de menu devons-nous protéger ici ? Une analyse plus approfondie révèle que le menu retourné dans xxxEnableMenuItem peut être de deux types : le menu principal de la fenêtre ou un sous-menu du menu(, voire un sous-sous-menu).
Pour construire le POC, nous avons conçu une structure de menu spéciale en quatre niveaux et avons effectué des réglages spéciaux sur chaque menu pour permettre la détection par fonction. Lorsque xxxRedrawTitle retourne le niveau utilisateur, nous avons supprimé la relation de référence entre le menu C et le menu B, libérant avec succès le menu C. Ainsi, lorsque la fonction xxxEnableMenuItem retourne au point, l'objet de menu C référencé est déjà invalide.
Pour la réalisation d'EXP, nous avons principalement considéré deux directions : l'exécution de code shell et l'utilisation de primitives de lecture/écriture pour modifier l'adresse du token. Compte tenu des mécanismes de sécurité des versions récentes de Windows, nous avons choisi cette dernière. L'ensemble du processus d'exploitation peut être divisé en deux parties : comment exploiter la vulnérabilité UAF pour contrôler la valeur cbwndextra, et comment établir des primitives de lecture/écriture stables.
Nous avons conçu une disposition de mémoire soigneusement conçue, utilisant les objets de nom de fenêtre de la classe fenêtre pour occuper et libérer des objets de menu, et avons trouvé le moment propice pour écrire des données dans la fonction xxxRedrawWindow. Pour réaliser une disposition de mémoire stable, nous avons conçu une structure de trois objets HWND consécutifs, et nous avons déterminé avec précision l'ordre d'arrangement des objets en utilisant les adresses des poignées de noyau qui fuient dans la mémoire de tas.
En ce qui concerne la lecture et l'écriture des primitives, nous utilisons GetMenuBarInfo() pour réaliser une lecture arbitraire, et SetClassLongPtr() pour réaliser une écriture arbitraire. À part le remplacement de l'opération d'écriture TOKEN qui dépend de l'objet class de la deuxième fenêtre, toutes les autres écritures utilisent l'objet class de la première fenêtre via un offset.
Dans l'ensemble, bien que la vulnérabilité win32k soit ancienne, Microsoft a tenté de refondre cette partie du code du noyau avec Rust dans la version préliminaire de Windows 11, et à l'avenir, de telles vulnérabilités pourraient être éliminées. Le processus d'exploitation de cette vulnérabilité est relativement simple, la principale difficulté résidant dans la façon de contrôler la première écriture. La découverte de cette vulnérabilité pourrait dépendre d'une détection de couverture de code plus complète. En ce qui concerne la détection des vulnérabilités, en plus de se concentrer sur les points clés de la fonction déclencheuse, la détection des mises en page de mémoire anormales et des lectures et écritures de décalage de données est également une voie possible pour découvrir des vulnérabilités similaires.