Analyse des vulnérabilités zero-day du système Windows de Microsoft : pouvant avoir un impact majeur sur l'écosystème Web3
Le mois dernier, une mise à jour de sécurité de Microsoft a corrigé une vulnérabilité d'escalade de privilèges dans le noyau Windows qui était exploitée de manière malveillante. Cette vulnérabilité affecte principalement les versions antérieures de Windows, tandis que Windows 11 semble ne pas être affecté. Cet article analysera comment les attaquants pourraient continuer à exploiter ce type de vulnérabilité dans le contexte actuel de renforcement des mesures de sécurité.
Nous avons terminé toute l'analyse dans un environnement Windows Server 2016.
Une vulnérabilité zero-day désigne une faille système qui n'a pas encore été découverte et corrigée, similaire au concept de trading T+0 sur les marchés financiers. Une fois qu'une vulnérabilité zero-day est exploitée de manière malveillante, elle peut généralement causer des dommages considérables. La vulnérabilité zero-day récemment découverte dans le système Windows permet à un attaquant d'obtenir un contrôle total sur le système.
Les conséquences de la prise de contrôle d'un système par un attaquant sont graves, y compris, mais sans s'y limiter, la fuite de la vie privée des individus, la perte de données due à un effondrement du système, des pertes financières, l'injection de logiciels malveillants, etc. Pour les utilisateurs individuels, cela peut entraîner le vol de clés privées de cryptomonnaie et le transfert d'actifs numériques ; à une échelle plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur l'infrastructure Web2.
Analyse des correctifs
En analysant le patch, nous avons constaté que le problème semblait être simplement un comptage de références d'objet qui avait été traité une fois de trop. Étant donné que win32k est un code plus ancien, nous pouvons trouver quelques anciens commentaires dans le code source qui indiquent que le code précédent ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet de menu dans l'objet de la fenêtre, ce qui pourrait entraîner une référence incorrecte de l'objet de menu.
Preuve de concept d'exploitation de vulnérabilités ( PoC ) mise en œuvre
En analysant le contexte de la fonction de vulnérabilité, nous avons découvert que le menu passé en xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Alors, quel objet de menu doit-on protéger ici ?
En analysant plus en détail le processus de traitement des objets de menu dans xxxEnableMenuItem, nous avons constaté que la fonction MenuItemState retourne deux possibilités de menus : le menu principal de la fenêtre ou le sous-menu, même le sous-sous-menu (.
Dans le PoC, nous avons construit une structure de menu spéciale à quatre niveaux, où les menus adjacents ont une relation parent-enfant. Ces menus ont certaines caractéristiques spécifiques, détectées et évaluées par la fonction xxxEnableMenuItem.
Lors du retour de xxxRedrawTitle à la couche utilisateur, nous avons supprimé la relation de référence entre le menu C et le menu B, libérant ainsi avec succès le menu C. Finalement, lorsque la fonction xxxEnableMenuItem dans le noyau retourne à la fonction xxxRedrawTitle, l'objet de menu C référencé est déjà invalide.
![Numen exclusif : la vulnérabilité 0day de Microsoft peut renverser le jeu Web3 sur les niveaux système et physique])https://img-cdn.gateio.im/webp-social/moments-171ea7cb7c6f7190c3f49a2b914eed04.webp(
Exploitation de la vulnérabilité ) Exploit ( réalisation
Avant de déterminer l'idée d'exploitation, nous effectuons généralement quelques jugements théoriques préliminaires pour éviter de perdre du temps sur des solutions non viables. Cette exploitation de vulnérabilité considère principalement deux directions :
Exécuter le code shellcode : se référer aux anciennes CVE-2017-0263 et CVE-2016-0167. Mais dans les versions Windows supérieures, cette méthode peut rencontrer des problèmes difficiles à résoudre.
Modifier l'adresse du token en utilisant des primitives de lecture et d'écriture : des méthodes publiques sont déjà disponibles pour référence ces dernières années. La disposition de la mémoire sur le bureau et les primitives de lecture et d'écriture ont une utilité à long terme. Nous devons principalement analyser comment contrôler cbwndextra à une valeur extrême lors de la réutilisation de la mémoire UAF pour la première fois.
Nous divisons l'ensemble du processus d'exploitation en deux questions : comment exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, et comment réaliser des primitives de lecture et d'écriture stables après avoir contrôlé la valeur de cbwndextra.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 au niveau système et physique])https://img-cdn.gateio.im/webp-social/moments-66af34ab04bec21e27be99bbe29c552a.webp(
Finalement, nous avons choisi d'écrire dans le cb-extra de HWNDClass dans la fonction xxxRedrawWindow en utilisant l'opération AND 2 sur le drapeau. Cela est dû au fait que le décalage cb-extra de HWNDClass est relativement petit, nous pouvons contrôler les données mémoire de l'objet précédent via la mise en page de la mémoire, permettant ainsi de juger du drapeau de l'objet dans la fonction xxxRedrawWindow.
Pour réaliser une disposition de mémoire stable, nous avons conçu au moins trois objets HWND de 0x250 octets consécutifs. Après avoir libéré l'objet intermédiaire, un objet HWNDClass de 0x250 octets occupe cette position. Les données de queue du précédent objet HWND sont utilisées pour vérifier à l'aide du drapeau xxxRedrawWindow, tandis que l'objet de menu du suivant objet HWND et l'objet HWNDClass servent de médiateurs pour les primitives de lecture et d'écriture finales.
![Numen Exclusif : la vulnérabilité 0day de Microsoft peut renverser la scène Web3 au niveau système + physique])https://img-cdn.gateio.im/webp-social/moments-1cc94ddafacec491507491eef9195858.webp(
Nous essayons de garder la taille des objets de fenêtre et des objets HWNDClass cohérente, et nous nous assurons que les données d'extension de l'objet de fenêtre sont suffisamment grandes. Grâce à l'adresse du handle de noyau qui fuit dans la mémoire du tas, nous pouvons déterminer avec précision si les objets de fenêtre demandés sont disposés dans l'ordre prévu.
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 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 via un décalage.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 sur le plan système et physique])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
Résumé
État de win32k : Microsoft essaie de réécrire le code du noyau concerné dans la version préliminaire de Windows 11 en utilisant Rust, et le nouveau système pourrait à l'avenir éliminer ce type de vulnérabilités.
Le processus d'exploitation des vulnérabilités est relativement simple : à part la nécessité d'essayer avec soin comment contrôler la première écriture, il n'est généralement pas nécessaire d'utiliser de nouvelles techniques d'exploitation. Ce type de vulnérabilité dépend fortement de la fuite des adresses des poignées de tas de bureau.
Découverte de vulnérabilités : On suppose qu'elle pourrait dépendre d'une détection de couverture de code plus complète. Une fois que l'API du système peut atteindre le point de vulnérabilité le plus profond dans le chemin d'exécution de la fonction cible, et que l'objet de la fenêtre est dans un état de références imbriquées multiples, cette vulnérabilité pourrait être découverte par des tests de fuzz.
Autres méthodes de découverte : En plus de la détection des points clés des fonctions déclencheuses de vulnérabilités, la détection des dispositions de mémoire inhabituelles et des décalages anormaux de lecture/écriture de données supplémentaires dans les fenêtres ou les classes de fenêtres pourrait également être l'une des méthodes pour découvrir des vulnérabilités similaires.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser la situation de Web3 au niveau système + physique])https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 à la fois au niveau système et au niveau physique])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
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.
12 J'aime
Récompense
12
2
Partager
Commentaire
0/400
AltcoinHunter
· Il y a 19h
Voir sans dire, vieux pigeons de l'univers de la cryptomonnaie.
Analyse des vulnérabilités zero-day de Windows : l'écosystème Web3 pourrait être gravement affecté
Analyse des vulnérabilités zero-day du système Windows de Microsoft : pouvant avoir un impact majeur sur l'écosystème Web3
Le mois dernier, une mise à jour de sécurité de Microsoft a corrigé une vulnérabilité d'escalade de privilèges dans le noyau Windows qui était exploitée de manière malveillante. Cette vulnérabilité affecte principalement les versions antérieures de Windows, tandis que Windows 11 semble ne pas être affecté. Cet article analysera comment les attaquants pourraient continuer à exploiter ce type de vulnérabilité dans le contexte actuel de renforcement des mesures de sécurité.
Nous avons terminé toute l'analyse dans un environnement Windows Server 2016.
Une vulnérabilité zero-day désigne une faille système qui n'a pas encore été découverte et corrigée, similaire au concept de trading T+0 sur les marchés financiers. Une fois qu'une vulnérabilité zero-day est exploitée de manière malveillante, elle peut généralement causer des dommages considérables. La vulnérabilité zero-day récemment découverte dans le système Windows permet à un attaquant d'obtenir un contrôle total sur le système.
Les conséquences de la prise de contrôle d'un système par un attaquant sont graves, y compris, mais sans s'y limiter, la fuite de la vie privée des individus, la perte de données due à un effondrement du système, des pertes financières, l'injection de logiciels malveillants, etc. Pour les utilisateurs individuels, cela peut entraîner le vol de clés privées de cryptomonnaie et le transfert d'actifs numériques ; à une échelle plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur l'infrastructure Web2.
Analyse des correctifs
En analysant le patch, nous avons constaté que le problème semblait être simplement un comptage de références d'objet qui avait été traité une fois de trop. Étant donné que win32k est un code plus ancien, nous pouvons trouver quelques anciens commentaires dans le code source qui indiquent que le code précédent ne verrouillait que l'objet de la fenêtre, sans verrouiller l'objet de menu dans l'objet de la fenêtre, ce qui pourrait entraîner une référence incorrecte de l'objet de menu.
Preuve de concept d'exploitation de vulnérabilités ( PoC ) mise en œuvre
En analysant le contexte de la fonction de vulnérabilité, nous avons découvert que le menu passé en xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Alors, quel objet de menu doit-on protéger ici ?
En analysant plus en détail le processus de traitement des objets de menu dans xxxEnableMenuItem, nous avons constaté que la fonction MenuItemState retourne deux possibilités de menus : le menu principal de la fenêtre ou le sous-menu, même le sous-sous-menu (.
Dans le PoC, nous avons construit une structure de menu spéciale à quatre niveaux, où les menus adjacents ont une relation parent-enfant. Ces menus ont certaines caractéristiques spécifiques, détectées et évaluées par la fonction xxxEnableMenuItem.
Lors du retour de xxxRedrawTitle à la couche utilisateur, nous avons supprimé la relation de référence entre le menu C et le menu B, libérant ainsi avec succès le menu C. Finalement, lorsque la fonction xxxEnableMenuItem dans le noyau retourne à la fonction xxxRedrawTitle, l'objet de menu C référencé est déjà invalide.
![Numen exclusif : la vulnérabilité 0day de Microsoft peut renverser le jeu Web3 sur les niveaux système et physique])https://img-cdn.gateio.im/webp-social/moments-171ea7cb7c6f7190c3f49a2b914eed04.webp(
Exploitation de la vulnérabilité ) Exploit ( réalisation
Avant de déterminer l'idée d'exploitation, nous effectuons généralement quelques jugements théoriques préliminaires pour éviter de perdre du temps sur des solutions non viables. Cette exploitation de vulnérabilité considère principalement deux directions :
Exécuter le code shellcode : se référer aux anciennes CVE-2017-0263 et CVE-2016-0167. Mais dans les versions Windows supérieures, cette méthode peut rencontrer des problèmes difficiles à résoudre.
Modifier l'adresse du token en utilisant des primitives de lecture et d'écriture : des méthodes publiques sont déjà disponibles pour référence ces dernières années. La disposition de la mémoire sur le bureau et les primitives de lecture et d'écriture ont une utilité à long terme. Nous devons principalement analyser comment contrôler cbwndextra à une valeur extrême lors de la réutilisation de la mémoire UAF pour la première fois.
Nous divisons l'ensemble du processus d'exploitation en deux questions : comment exploiter la vulnérabilité UAF pour contrôler la valeur de cbwndextra, et comment réaliser des primitives de lecture et d'écriture stables après avoir contrôlé la valeur de cbwndextra.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 au niveau système et physique])https://img-cdn.gateio.im/webp-social/moments-66af34ab04bec21e27be99bbe29c552a.webp(
Finalement, nous avons choisi d'écrire dans le cb-extra de HWNDClass dans la fonction xxxRedrawWindow en utilisant l'opération AND 2 sur le drapeau. Cela est dû au fait que le décalage cb-extra de HWNDClass est relativement petit, nous pouvons contrôler les données mémoire de l'objet précédent via la mise en page de la mémoire, permettant ainsi de juger du drapeau de l'objet dans la fonction xxxRedrawWindow.
Pour réaliser une disposition de mémoire stable, nous avons conçu au moins trois objets HWND de 0x250 octets consécutifs. Après avoir libéré l'objet intermédiaire, un objet HWNDClass de 0x250 octets occupe cette position. Les données de queue du précédent objet HWND sont utilisées pour vérifier à l'aide du drapeau xxxRedrawWindow, tandis que l'objet de menu du suivant objet HWND et l'objet HWNDClass servent de médiateurs pour les primitives de lecture et d'écriture finales.
![Numen Exclusif : la vulnérabilité 0day de Microsoft peut renverser la scène Web3 au niveau système + physique])https://img-cdn.gateio.im/webp-social/moments-1cc94ddafacec491507491eef9195858.webp(
Nous essayons de garder la taille des objets de fenêtre et des objets HWNDClass cohérente, et nous nous assurons que les données d'extension de l'objet de fenêtre sont suffisamment grandes. Grâce à l'adresse du handle de noyau qui fuit dans la mémoire du tas, nous pouvons déterminer avec précision si les objets de fenêtre demandés sont disposés dans l'ordre prévu.
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 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 via un décalage.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 sur le plan système et physique])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
Résumé
État de win32k : Microsoft essaie de réécrire le code du noyau concerné dans la version préliminaire de Windows 11 en utilisant Rust, et le nouveau système pourrait à l'avenir éliminer ce type de vulnérabilités.
Le processus d'exploitation des vulnérabilités est relativement simple : à part la nécessité d'essayer avec soin comment contrôler la première écriture, il n'est généralement pas nécessaire d'utiliser de nouvelles techniques d'exploitation. Ce type de vulnérabilité dépend fortement de la fuite des adresses des poignées de tas de bureau.
Découverte de vulnérabilités : On suppose qu'elle pourrait dépendre d'une détection de couverture de code plus complète. Une fois que l'API du système peut atteindre le point de vulnérabilité le plus profond dans le chemin d'exécution de la fonction cible, et que l'objet de la fenêtre est dans un état de références imbriquées multiples, cette vulnérabilité pourrait être découverte par des tests de fuzz.
Autres méthodes de découverte : En plus de la détection des points clés des fonctions déclencheuses de vulnérabilités, la détection des dispositions de mémoire inhabituelles et des décalages anormaux de lecture/écriture de données supplémentaires dans les fenêtres ou les classes de fenêtres pourrait également être l'une des méthodes pour découvrir des vulnérabilités similaires.
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser la situation de Web3 au niveau système + physique])https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
![Numen Exclusif : La vulnérabilité 0day de Microsoft peut renverser le jeu Web3 à la fois au niveau système et au niveau physique])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(