Analyse et exploitation des vulnérabilités 0day au niveau système de Microsoft
Introduction
Récemment, un correctif de sécurité de Microsoft a réparé une vulnérabilité d'élévation de privilèges win32k exploitée par des pirates informatiques. Cette vulnérabilité affecte principalement les versions antérieures du système Windows, et semble sans effet sur Windows 11. Cet article analysera en profondeur comment, dans le contexte de l'amélioration continue des nouvelles mesures de protection, les attaquants pourraient continuer à exploiter ce type de vulnérabilités. Notre environnement d'analyse est Windows Server 2016.
Contexte de la vulnérabilité
Une vulnérabilité 0day fait référence à une faille de sécurité non divulguée et non corrigée, similaire au concept de transaction T+0 sur le marché financier. Une fois que ce type de vulnérabilité est exploité malicieusement, il peut souvent causer d'énormes dommages. La vulnérabilité 0day de niveau système Windows récemment découverte 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, notamment la fuite d'informations personnelles, les pannes de système, la perte de données, les pertes financières et l'injection de logiciels malveillants. Pour les utilisateurs de cryptomonnaies, les clés privées 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 basé sur l'infrastructure Web2.
Analyse de patch
L'analyse du code de patch montre que le problème semble provenir du fait qu'un compte de référence d'objet a été traité plusieurs fois. En consultant les commentaires du code source antérieur, nous avons constaté 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 référence incorrecte de l'objet du menu.
Vérification des vulnérabilités
En analysant le contexte de la fonction de vulnérabilité, nous avons constaté que le menu passé à xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Alors, quel objet de menu doit être protégé spécifiquement ? En analysant plus en détail le traitement de l'objet menu dans xxxEnableMenuItem, nous découvrons que la fonction MenuItemState retourne deux possibilités pour le menu : le menu principal de la fenêtre ou le sous-menu(, y compris les sous-sous-menus).
Pour vérifier la vulnérabilité, nous avons construit une structure de menu spéciale à quatre niveaux et défini certaines conditions spécifiques pour contourner la détection dans la fonction xxxEnableMenuItem. Lorsque xxxRedrawTitle renvoie au niveau utilisateur, nous supprimons la relation de référence entre les menus C et B, libérant ainsi avec succès le menu C. Enfin, lorsque la fonction xxxEnableMenuItem dans le noyau retourne à la fonction xxxRedrawTitle, l'objet de menu C qui était sur le point d'être référencé est devenu invalide.
Exploitation de vulnérabilité
approche globale
Avant de déterminer les solutions d'exploitation, nous effectuons généralement une analyse théorique afin d'éviter de perdre du temps sur des solutions non viables. Cette exploitation de vulnérabilité a principalement considéré deux directions :
Exécution de shellcode : se référer à des vulnérabilités similaires antérieures, mais pourrait rencontrer des problèmes difficiles à résoudre dans des versions plus récentes de Windows.
Utiliser des primitives de lecture/écriture pour modifier le token : même dans les deux dernières années, il existe encore des cas publics de référence. Nous devons nous concentrer sur la façon de contrôler pour la première fois cbwndextra à une valeur très élevée lorsque la mémoire UAF est réutilisée.
Ainsi, nous avons divisé l'ensemble du processus d'exploitation en deux parties : comment exploiter la vulnérabilité UAF pour contrôler la valeur cbwndextra, et comment, après avoir contrôlé cette valeur, réaliser des primitives de lecture et d'écriture stables.
première écriture de données
Après avoir déclenché une vulnérabilité, le système ne s'effondrera pas nécessairement immédiatement. L'utilisation incorrecte des données d'objet de fenêtre en mémoire contrôlée se produit principalement dans les fonctions MNGetPopupFromMenu() et xxxMNUpdateShownMenu().
Nous utilisons l'objet de nom de fenêtre dans la classe WNDClass pour occuper la mémoire de l'objet de menu libéré. La clé est de trouver un emplacement dans la 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 trouvé deux solutions viables dans la fonction xxxRedrawWindow. Compte tenu de certaines contraintes, nous avons choisi la solution qui repose sur l'opération de drapeau AND 2, et avons décidé d'écrire dans le cb-extra de HWNDClass plutôt que dans le cb-extra de l'objet fenêtre.
disposition de mémoire stable
Nous avons conçu une disposition mémoire pour au moins trois objets HWND de 0x250 octets consécutifs. Libérer les objets intermédiaires, en utilisant un objet HWNDClass de 0x250 octets. Les données de queue de l'objet HWND précédent sont utilisées pour la vérification via le drapeau xxxRedrawWindow, tandis que l'objet de menu de l'objet HWND suivant et l'objet HWNDClass servent de support médian pour les opérations de lecture et d'écriture finales.
Nous essayons de contrôler la taille des objets de fenêtre et des objets HWNDClass pour qu'ils soient cohérents, et nous nous assurons que les données d'extension de l'objet de fenêtre sont suffisamment grandes. En utilisant l'adresse des poignées de noyau divulguées 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.
mise en œuvre des primitives de lecture et d'écriture
Pour lire n'importe quel langage source, utilisez GetMenuBarInfo(). Pour écrire n'importe quel langage source, utilisez SetClassLongPtr(). À l'exception 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 être réalisées.
Résumé
La vulnérabilité win32k existe depuis longtemps, mais Microsoft est en train de reconstruire le code du noyau associé avec Rust, et les futurs systèmes pourraient éviter ce type de vulnérabilité.
Le processus d'exploitation de cette vulnérabilité n'est pas difficile, la principale difficulté réside dans la façon de contrôler le premier écriture. La vulnérabilité dépend encore gravement de la fuite d'adresse du gestionnaire de tas de bureau, ce qui reste une menace pour la sécurité des anciens systèmes.
La découverte de cette vulnérabilité pourrait être attribuée à 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érence imbriquée multiple, les tests de fuzz pourraient alors découvrir cette vulnérabilité.
Pour la détection d'exploitation des vulnérabilités, en plus de se concentrer sur les points clés des fonctions de déclenchement des vulnérabilités, il convient également de prêter attention à la disposition de la mémoire anormale et à la lecture/écriture d'offsets non conventionnels sur des données supplémentaires de fenêtres ou de classes de fenêtres, ce qui peut aider à découvrir des vulnérabilités de même type.
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.
23 J'aime
Récompense
23
3
Partager
Commentaire
0/400
OnChainDetective
· 08-01 09:21
ah classique win32k... le modèle correspond aux précédents exploits APT à vrai dire
Analyse approfondie et techniques d'exploitation des vulnérabilités 0day au niveau système Windows
Analyse et exploitation des vulnérabilités 0day au niveau système de Microsoft
Introduction
Récemment, un correctif de sécurité de Microsoft a réparé une vulnérabilité d'élévation de privilèges win32k exploitée par des pirates informatiques. Cette vulnérabilité affecte principalement les versions antérieures du système Windows, et semble sans effet sur Windows 11. Cet article analysera en profondeur comment, dans le contexte de l'amélioration continue des nouvelles mesures de protection, les attaquants pourraient continuer à exploiter ce type de vulnérabilités. Notre environnement d'analyse est Windows Server 2016.
Contexte de la vulnérabilité
Une vulnérabilité 0day fait référence à une faille de sécurité non divulguée et non corrigée, similaire au concept de transaction T+0 sur le marché financier. Une fois que ce type de vulnérabilité est exploité malicieusement, il peut souvent causer d'énormes dommages. La vulnérabilité 0day de niveau système Windows récemment découverte 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, notamment la fuite d'informations personnelles, les pannes de système, la perte de données, les pertes financières et l'injection de logiciels malveillants. Pour les utilisateurs de cryptomonnaies, les clés privées 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 basé sur l'infrastructure Web2.
Analyse de patch
L'analyse du code de patch montre que le problème semble provenir du fait qu'un compte de référence d'objet a été traité plusieurs fois. En consultant les commentaires du code source antérieur, nous avons constaté 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 référence incorrecte de l'objet du menu.
Vérification des vulnérabilités
En analysant le contexte de la fonction de vulnérabilité, nous avons constaté que le menu passé à xxxEnableMenuItem() est généralement verrouillé dans la fonction supérieure. Alors, quel objet de menu doit être protégé spécifiquement ? En analysant plus en détail le traitement de l'objet menu dans xxxEnableMenuItem, nous découvrons que la fonction MenuItemState retourne deux possibilités pour le menu : le menu principal de la fenêtre ou le sous-menu(, y compris les sous-sous-menus).
Pour vérifier la vulnérabilité, nous avons construit une structure de menu spéciale à quatre niveaux et défini certaines conditions spécifiques pour contourner la détection dans la fonction xxxEnableMenuItem. Lorsque xxxRedrawTitle renvoie au niveau utilisateur, nous supprimons la relation de référence entre les menus C et B, libérant ainsi avec succès le menu C. Enfin, lorsque la fonction xxxEnableMenuItem dans le noyau retourne à la fonction xxxRedrawTitle, l'objet de menu C qui était sur le point d'être référencé est devenu invalide.
Exploitation de vulnérabilité
approche globale
Avant de déterminer les solutions d'exploitation, nous effectuons généralement une analyse théorique afin d'éviter de perdre du temps sur des solutions non viables. Cette exploitation de vulnérabilité a principalement considéré deux directions :
Exécution de shellcode : se référer à des vulnérabilités similaires antérieures, mais pourrait rencontrer des problèmes difficiles à résoudre dans des versions plus récentes de Windows.
Utiliser des primitives de lecture/écriture pour modifier le token : même dans les deux dernières années, il existe encore des cas publics de référence. Nous devons nous concentrer sur la façon de contrôler pour la première fois cbwndextra à une valeur très élevée lorsque la mémoire UAF est réutilisée.
Ainsi, nous avons divisé l'ensemble du processus d'exploitation en deux parties : comment exploiter la vulnérabilité UAF pour contrôler la valeur cbwndextra, et comment, après avoir contrôlé cette valeur, réaliser des primitives de lecture et d'écriture stables.
première écriture de données
Après avoir déclenché une vulnérabilité, le système ne s'effondrera pas nécessairement immédiatement. L'utilisation incorrecte des données d'objet de fenêtre en mémoire contrôlée se produit principalement dans les fonctions MNGetPopupFromMenu() et xxxMNUpdateShownMenu().
Nous utilisons l'objet de nom de fenêtre dans la classe WNDClass pour occuper la mémoire de l'objet de menu libéré. La clé est de trouver un emplacement dans la 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 trouvé deux solutions viables dans la fonction xxxRedrawWindow. Compte tenu de certaines contraintes, nous avons choisi la solution qui repose sur l'opération de drapeau AND 2, et avons décidé d'écrire dans le cb-extra de HWNDClass plutôt que dans le cb-extra de l'objet fenêtre.
disposition de mémoire stable
Nous avons conçu une disposition mémoire pour au moins trois objets HWND de 0x250 octets consécutifs. Libérer les objets intermédiaires, en utilisant un objet HWNDClass de 0x250 octets. Les données de queue de l'objet HWND précédent sont utilisées pour la vérification via le drapeau xxxRedrawWindow, tandis que l'objet de menu de l'objet HWND suivant et l'objet HWNDClass servent de support médian pour les opérations de lecture et d'écriture finales.
Nous essayons de contrôler la taille des objets de fenêtre et des objets HWNDClass pour qu'ils soient cohérents, et nous nous assurons que les données d'extension de l'objet de fenêtre sont suffisamment grandes. En utilisant l'adresse des poignées de noyau divulguées 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.
mise en œuvre des primitives de lecture et d'écriture
Pour lire n'importe quel langage source, utilisez GetMenuBarInfo(). Pour écrire n'importe quel langage source, utilisez SetClassLongPtr(). À l'exception 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 être réalisées.
Résumé
La vulnérabilité win32k existe depuis longtemps, mais Microsoft est en train de reconstruire le code du noyau associé avec Rust, et les futurs systèmes pourraient éviter ce type de vulnérabilité.
Le processus d'exploitation de cette vulnérabilité n'est pas difficile, la principale difficulté réside dans la façon de contrôler le premier écriture. La vulnérabilité dépend encore gravement de la fuite d'adresse du gestionnaire de tas de bureau, ce qui reste une menace pour la sécurité des anciens systèmes.
La découverte de cette vulnérabilité pourrait être attribuée à 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érence imbriquée multiple, les tests de fuzz pourraient alors découvrir cette vulnérabilité.
Pour la détection d'exploitation des vulnérabilités, en plus de se concentrer sur les points clés des fonctions de déclenchement des vulnérabilités, il convient également de prêter attention à la disposition de la mémoire anormale et à la lecture/écriture d'offsets non conventionnels sur des données supplémentaires de fenêtres ou de classes de fenêtres, ce qui peut aider à découvrir des vulnérabilités de même type.