Analyse des vulnérabilités 0day du système Microsoft Windows : accès complet au contrôle du système

Le mois dernier, un correctif de sécurité de Microsoft a réparé une vulnérabilité d'escalade de privilèges dans le noyau Windows qui était exploitée par des hackers. Cette vulnérabilité existe principalement dans les versions antérieures de Windows et ne peut pas être déclenchée sur Windows 11. Cet article analysera comment les attaquants pourraient continuer à exploiter cette vulnérabilité dans le contexte d'un renforcement constant des mécanismes de sécurité. Notre environnement d'analyse est Windows Server 2016.

Les vulnérabilités 0day désignent des failles logicielles qui n'ont pas encore été découvertes et corrigées. Une fois exploitées par des hackers, elles peuvent causer des dommages graves. La vulnérabilité 0day récemment découverte dans Windows permet aux attaquants d'obtenir un contrôle total du système, leur permettant ainsi de voler des informations personnelles, d'implanter des logiciels malveillants et de dérober des cryptomonnaies. Dans une perspective plus large, cette vulnérabilité pourrait même affecter l'ensemble de l'écosystème Web3 basé sur l'infrastructure Web2.

L'analyse du patch montre que le problème provient du traitement du comptage de références d'un objet dans le module win32k. Des commentaires dans le code source antérieur indiquent que le code précédent ne verrouillait que l'objet fenêtre, sans verrouiller l'objet menu dans la fenêtre, ce qui pourrait entraîner une référence incorrecte à l'objet menu.

Nous avons construit une structure de menu imbriqué multicouche spéciale pour déclencher une vulnérabilité. L'essentiel est de supprimer la référence à un sous-menu et de la libérer lorsque la fonction xxxEnableMenuItem retourne au niveau utilisateur. Ainsi, lorsque la fonction entre à nouveau en mode noyau, l'objet de menu référencé précédemment est déjà devenu invalide.

Lors de l'exploitation d'une vulnérabilité, nous avons principalement envisagé deux scénarios : exécuter du shellcode et utiliser des primitives de lecture/écriture pour modifier le token. Compte tenu des mécanismes de sécurité des versions récentes de Windows, nous avons choisi la seconde option. L'ensemble du processus d'exploitation se déroule en deux étapes : d'abord contrôler la valeur de cbwndextra, puis établir des primitives de lecture/écriture stables.

Pour écrire les premières données, nous avons utilisé un point d'écriture dans la fonction xxxRedrawWindow. En disposant soigneusement la mémoire, nous pouvons contrôler les données mémoire des objets adjacents, permettant ainsi une vérification à travers les indicateurs dans la fonction.

En ce qui concerne la disposition de la mémoire, nous avons conçu trois objets HWND consécutifs, libérant le celui du milieu et utilisant l'objet HWNDClass pour l'occuper. Les deux objets HWND à l'avant et à l'arrière sont respectivement utilisés pour vérifier et réaliser les primitives de lecture/écriture. Nous avons également utilisé les adresses de gestionnaires de noyau divulguées dans la mémoire du tas pour déterminer avec précision si l'agencement des objets correspond aux attentes.

Enfin, nous utilisons GetMenuBarInfo() pour réaliser des lectures arbitraires, et SetClassLongPtr() pour réaliser des écritures arbitraires. À part les opérations de modification du TOKEN, toutes les écritures sont réalisées en utilisant l'objet de classe du premier objet de fenêtre.

En général, bien que les vulnérabilités du module win32k existent depuis longtemps, Microsoft essaie de reconstruire le code pertinent avec Rust, ce qui pourrait éliminer ce type de vulnérabilité dans les nouveaux systèmes à l'avenir. Le processus d'exploitation actuel n'est pas particulièrement difficile, reposant principalement sur la fuite des adresses des handles de tas de bureau. Améliorer la détection de la couverture du code et effectuer des vérifications ciblées des opérations mémoire anormales pourraient être des moyens efficaces de découvrir ce type de vulnérabilités.