Analyse et exploitation des vulnérabilités 0day du système Windows de Microsoft
Récemment, un correctif de sécurité publié par Microsoft a réparé une vulnérabilité d'élévation de privilèges win32k qui était exploitée. Cette vulnérabilité n'existe que dans les anciennes versions des systèmes Windows et ne peut pas être déclenchée sur Windows 11. Cet article analysera comment les attaquants continuent d'exploiter ce type de vulnérabilités dans le contexte actuel d'amélioration continue de la sécurité.
Contexte de la vulnérabilité
Une vulnérabilité 0day désigne une faille de sécurité qui n'a pas encore été rendue publique et qui n'a pas été corrigée, similaire au concept de transaction T+0 sur le marché financier. Une fois qu'une telle vulnérabilité est découverte, elle peut être exploitée de manière malveillante sans être détectée, causant des dommages considérables.
La vulnérabilité 0day découverte dans le système Windows permet aux attaquants de prendre le contrôle total du 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. Du point de vue de Web3, cela pourrait entraîner le vol de clés privées, le transfert d'actifs numériques, et même affecter l'ensemble de l'écosystème Web3 basé sur une infrastructure Web2.
Analyse des correctifs
L'analyse du code du correctif révèle que le problème réside dans le traitement multiple du comptage des références d'objets. En regardant les commentaires du code source antérieur, on peut comprendre que le code précédent ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet du menu dans la fenêtre, ce qui pourrait entraîner une mauvaise référence de l'objet du menu.
Reproduction de la vulnérabilité
En analysant le contexte de la fonction de vulnérabilité, il a été constaté que le menu passant xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Une analyse plus approfondie a révélé que le menu renvoyé par la fonction MenuItemState peut être le menu principal de la fenêtre, ou bien un sous-menu ou un sous-sous-menu.
Pour déclencher la vulnérabilité, une structure de menu spéciale à quatre niveaux a été construite, avec les caractéristiques suivantes :
L'ID du menu de niveau inférieur D doit être de type menu système.
Le menu principal A doit également être un menu système, mais il doit supprimer le type de menu système correspondant.
Supprimer la référence du menu C dans le menu B
La présence du menu B semble aider à la libération du menu C.
Lors du retour de xxxRedrawTitle à la couche utilisateur, supprimez la relation de référence entre les menus C et B et libérez le menu C. Ainsi, au moment où la fonction xxxEnableMenuItem retourne, l'objet de menu C référencé est déjà invalidé.
Exploitation de vulnérabilité
L'exploitation des vulnérabilités considère principalement deux directions :
Exécution du code shellcode : référence à des vulnérabilités antérieures telles que CVE-2017-0263, mais dans les versions plus récentes de Windows, des problèmes de mécanismes de sécurité tels que les points d'entrée et SMEP peuvent survenir.
Modifier l'adresse du token en utilisant des primitives de lecture/écriture : ces dernières années, plusieurs exp publics peuvent être consultés, qui sont généraux concernant la disposition de la mémoire sur le bureau et les primitives de lecture/écriture. La clé est d'analyser comment contrôler pour la première fois cbwndextra comme une valeur très grande lors de la réutilisation de la mémoire UAF.
Cette fois, nous utilisons la deuxième solution, en divisant l'ensemble du processus en deux étapes :
Contrôler la valeur cbwndextra en exploitant la vulnérabilité UAF
Contrôler cbwndextra pour réaliser des primitives de lecture et d'écriture stables.
Première écriture de données
Après le déclenchement de la vulnérabilité, le système peut utiliser de manière incorrecte les données de l'objet de fenêtre contrôlé dans MNGetPopupFromMenu() et xxxMNUpdateShownMenu(). Nous utilisons l'objet de nom de fenêtre de la classe de fenêtre WNDClass pour occuper et libérer l'objet de menu.
La clé est de trouver un emplacement dans une structure d'adresse que nous pouvons construire où nous pouvons écrire des données de manière arbitraire, même si ce n'est qu'un octet. Nous avons finalement choisi la solution dans la fonction xxxRedrawWindow, en contrôlant les données mémoire de l'objet précédent à travers la mise en page pour déterminer l'objet dans la fonction.
disposition de mémoire stable
Concevez au moins trois objets HWND de 0x250 octets consécutifs, libérez le milieu et occupez-le avec un objet HWNDClass. Les données de la queue du premier objet HWND sont utilisées pour vérifier à l'aide des drapeaux dans xxxRedrawWindow, tandis que l'objet de menu du dernier objet HWND et l'objet HWNDClass servent de support pour les opérations de lecture et d'écriture finales.
Déterminer avec précision si les objets de fenêtre demandés sont disposés dans l'ordre prévu grâce à l'adresse du handle de noyau révélée dans la mémoire.
Lire et écrire des primitives
Utilisez GetMenuBarInfo() pour la lecture de n'importe quel langage d'origine, et utilisez SetClassLongPtr() pour l'écriture de n'importe quel langage d'origine. À l'exception de l'écriture de remplacement de TOKEN, toutes les autres écritures sont effectuées en utilisant l'objet de classe du premier objet de fenêtre avec un décalage.
Résumé
La vulnérabilité win32k a une longue histoire, mais Microsoft essaie de refondre le code associé en Rust, et à l'avenir, de tels problèmes pourraient être éliminés dans les nouveaux systèmes.
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. Cela dépend fortement de la fuite de l'adresse du gestionnaire de tas de bureau, ce qui reste un risque de sécurité pour les anciens systèmes.
La découverte de cette vulnérabilité peut être attribuée à une détection de couverture de code plus complète.
En ce qui concerne la détection des exploits, en plus de se concentrer sur les points clés des fonctions déclenchées, il est également important de prêter attention aux dispositions anormales de la mémoire et aux décalages de lecture/écriture des données de la fenêtre.
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.
6 J'aime
Récompense
6
4
Partager
Commentaire
0/400
ChainSauceMaster
· 08-05 20:25
Qu'est-ce qui se passe encore avec le vieux win ? Il y a des failles tous les jours.
Voir l'originalRépondre0
FloorPriceWatcher
· 08-05 20:23
win11 a échappé à un danger!
Voir l'originalRépondre0
MEVSandwichVictim
· 08-05 20:21
Vulnérabilité, qui est le plus rusé, qui prend les gens pour des idiots.
Analyse des vulnérabilités 0day des premières versions de Microsoft Windows : du privilège élevé à l'exploitation complète
Analyse et exploitation des vulnérabilités 0day du système Windows de Microsoft
Récemment, un correctif de sécurité publié par Microsoft a réparé une vulnérabilité d'élévation de privilèges win32k qui était exploitée. Cette vulnérabilité n'existe que dans les anciennes versions des systèmes Windows et ne peut pas être déclenchée sur Windows 11. Cet article analysera comment les attaquants continuent d'exploiter ce type de vulnérabilités dans le contexte actuel d'amélioration continue de la sécurité.
Contexte de la vulnérabilité
Une vulnérabilité 0day désigne une faille de sécurité qui n'a pas encore été rendue publique et qui n'a pas été corrigée, similaire au concept de transaction T+0 sur le marché financier. Une fois qu'une telle vulnérabilité est découverte, elle peut être exploitée de manière malveillante sans être détectée, causant des dommages considérables.
La vulnérabilité 0day découverte dans le système Windows permet aux attaquants de prendre le contrôle total du 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. Du point de vue de Web3, cela pourrait entraîner le vol de clés privées, le transfert d'actifs numériques, et même affecter l'ensemble de l'écosystème Web3 basé sur une infrastructure Web2.
Analyse des correctifs
L'analyse du code du correctif révèle que le problème réside dans le traitement multiple du comptage des références d'objets. En regardant les commentaires du code source antérieur, on peut comprendre que le code précédent ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet du menu dans la fenêtre, ce qui pourrait entraîner une mauvaise référence de l'objet du menu.
Reproduction de la vulnérabilité
En analysant le contexte de la fonction de vulnérabilité, il a été constaté que le menu passant xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Une analyse plus approfondie a révélé que le menu renvoyé par la fonction MenuItemState peut être le menu principal de la fenêtre, ou bien un sous-menu ou un sous-sous-menu.
Pour déclencher la vulnérabilité, une structure de menu spéciale à quatre niveaux a été construite, avec les caractéristiques suivantes :
Lors du retour de xxxRedrawTitle à la couche utilisateur, supprimez la relation de référence entre les menus C et B et libérez le menu C. Ainsi, au moment où la fonction xxxEnableMenuItem retourne, l'objet de menu C référencé est déjà invalidé.
Exploitation de vulnérabilité
L'exploitation des vulnérabilités considère principalement deux directions :
Exécution du code shellcode : référence à des vulnérabilités antérieures telles que CVE-2017-0263, mais dans les versions plus récentes de Windows, des problèmes de mécanismes de sécurité tels que les points d'entrée et SMEP peuvent survenir.
Modifier l'adresse du token en utilisant des primitives de lecture/écriture : ces dernières années, plusieurs exp publics peuvent être consultés, qui sont généraux concernant la disposition de la mémoire sur le bureau et les primitives de lecture/écriture. La clé est d'analyser comment contrôler pour la première fois cbwndextra comme une valeur très grande lors de la réutilisation de la mémoire UAF.
Cette fois, nous utilisons la deuxième solution, en divisant l'ensemble du processus en deux étapes :
Première écriture de données
Après le déclenchement de la vulnérabilité, le système peut utiliser de manière incorrecte les données de l'objet de fenêtre contrôlé dans MNGetPopupFromMenu() et xxxMNUpdateShownMenu(). Nous utilisons l'objet de nom de fenêtre de la classe de fenêtre WNDClass pour occuper et libérer l'objet de menu.
La clé est de trouver un emplacement dans une structure d'adresse que nous pouvons construire où nous pouvons écrire des données de manière arbitraire, même si ce n'est qu'un octet. Nous avons finalement choisi la solution dans la fonction xxxRedrawWindow, en contrôlant les données mémoire de l'objet précédent à travers la mise en page pour déterminer l'objet dans la fonction.
disposition de mémoire stable
Concevez au moins trois objets HWND de 0x250 octets consécutifs, libérez le milieu et occupez-le avec un objet HWNDClass. Les données de la queue du premier objet HWND sont utilisées pour vérifier à l'aide des drapeaux dans xxxRedrawWindow, tandis que l'objet de menu du dernier objet HWND et l'objet HWNDClass servent de support pour les opérations de lecture et d'écriture finales.
Déterminer avec précision si les objets de fenêtre demandés sont disposés dans l'ordre prévu grâce à l'adresse du handle de noyau révélée dans la mémoire.
Lire et écrire des primitives
Utilisez GetMenuBarInfo() pour la lecture de n'importe quel langage d'origine, et utilisez SetClassLongPtr() pour l'écriture de n'importe quel langage d'origine. À l'exception de l'écriture de remplacement de TOKEN, toutes les autres écritures sont effectuées en utilisant l'objet de classe du premier objet de fenêtre avec un décalage.
Résumé
La vulnérabilité win32k a une longue histoire, mais Microsoft essaie de refondre le code associé en Rust, et à l'avenir, de tels problèmes pourraient être éliminés dans les nouveaux systèmes.
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. Cela dépend fortement de la fuite de l'adresse du gestionnaire de tas de bureau, ce qui reste un risque de sécurité pour les anciens systèmes.
La découverte de cette vulnérabilité peut être attribuée à une détection de couverture de code plus complète.
En ce qui concerne la détection des exploits, en plus de se concentrer sur les points clés des fonctions déclenchées, il est également important de prêter attention aux dispositions anormales de la mémoire et aux décalages de lecture/écriture des données de la fenêtre.