Le mois dernier, Microsoft a publié un avis pour CVE-2020-1317 qui décrit une vulnérabilité d'escalade des privilèges dans Group Policy. Cette vulnérabilité a été décrite plus en détail par son auteur sur le site web Cyberark. La nature de ce problème est intéressante et mérite d'être comprise. Pendant des années, la stratégie de groupe a intégré cette dichotomie dans sa conception. Il s'agit de la nécessité de fournir une politique par utilisateur à des utilisateurs non privilégiés, par le biais d'un mécanisme qui fonctionne comme un processus privilégié, à savoir le moteur de la stratégie de groupe. Microsoft a traité ce problème de différentes manières. Par exemple, la stratégie des modèles d'administration par utilisateur a été transmise à un ensemble de deux clés de registre dans HKEY_CURRENT_USER qui ont été autorisées de telle sorte qu'un utilisateur ne pouvait pas écrire dessus, même s'il pouvait écrire sur pratiquement n'importe quelle autre clé de cette ruche. Mais dans le cas de ce CVE, il y avait quelques lacunes flagrantes. La première d'entre elles a été décrite en détail dans le billet de blog de Cyberark. Le concept de fichiers d'historique a toujours existé dans les préférences de GP. Ces fichiers ont été créés pour annuler l'état de certaines préférences GP lorsque ces paramètres ne s'appliquaient plus. Ces fichiers d'historique étaient essentiellement des copies du fichier de paramètres réel stocké dans SYSVOL pour la GPO fournissant les paramètres, et étaient stockés dans le profil de l'utilisateur sous %appdata%LocalMicrosoftGroup Policy, comme vous pouvez le voir ici :
Lecture associée
L'emplacement de ce fichier est la clé de cette vulnérabilité. Les fichiers eux-mêmes sont stockés dans le profil de l'utilisateur, dans une zone à laquelle un utilisateur normal, non privilégié, a tous les droits. Cependant, les fichiers sont écrits ici chaque fois qu'un nouveau paramètre GPP est traité, ou que le paramètre est modifié, par le moteur GP, qui s'exécute lui-même en tant que localSystem. Nous avons donc un processus localSystem qui écrit des données dans l'espace utilisateur non privilégié, et c'est là que le plaisir commence.
Pour cet exploit particulier, l'auteur a utilisé les liens symboliques du gestionnaire d'objets pour rediriger n'importe quel fichier GPP XML arbitraire vers un emplacement dans c:windowsystem32, où il peut être exploité par un autre processus pour ouvrir essentiellement un processus s'exécutant sous le nom de localSystem. Les détails du code d'escalade réel vers localSystem ne sont pas montrés, mais l'utilisation des liens symboliques OM (et l'exploitation d'autres types de liens symboliques Windows) est décrite dans cette excellente vidéo de James Forshaw, qui propose également un exemple de code pour la création de ces liens ici. Il suffit de dire que pour exploiter cela, un attaquant n'a qu'à supprimer le fichier que GPP a laissé dans son profil d'utilisateur et le remplacer par un lien symbolique OM. Le moteur GP s'exécutera alors en tant que système local et écrira un nouveau fichier XML vers la destination spécifiée dans c:windowssystem32. Il peut alors écrire le contenu qu'il souhaite dans ce fichier et l'exploiter à partir de là. Plutôt astucieux.
Chemins d'exploitation alternatifs et correctifs
Lorsque j'ai vu cet exploit décrit pour la première fois, je me suis demandé à haute voix si les fichiers d'historique GPP étaient le seul endroit où cela pouvait être exploité. Je savais pertinemment que mon bon ami, le fichier d'archives du registre (ntuser.pol), était un autre de ces fichiers GPO par utilisateur qui étaient conservés dans le profil de l'utilisateur, et qui pouvaient être écrits par l'utilisateur, mais qui étaient mis à jour par le moteur GP. Il était donc logique de supposer que ce fichier pouvait également être exploité de la même manière que les fichiers d'historique des préférences GP. Ainsi, lorsque j'ai examiné un système Windows après avoir appliqué le correctif pour cette vulnérabilité, j'ai noté quelques éléments intéressants. Tout d'abord, Microsoft a résolu le problème en déplaçant les fichiers d'historique GPP hors du profil de l'utilisateur et dans le dossier protégé %programdata% (plus précisément sous %programdata%MicrosoftGroup PolicyUsers). Ce dossier n'est pas accessible en écriture par les utilisateurs normaux, ce qui permet d'éviter l'utilisation de liens symboliques dans la version précédente. Le chemin complet vers le fichier est un peu bizarre, comme vous pouvez le voir ici :
La structure des dossiers est par utilisateur (c'est-à-dire le chemin du dossier SID), puis par GPO (le GUID de la GPO), puis à nouveau par utilisateur (un autre dossier SID), ce qui semble un peu excessif, mais je suis sûr qu'ils avaient une raison pour cela 🙂 .
The next question I was curious about, was the ntuser.pol file I mentioned above. Sure enough, Microsoft also moved that file to a location in %programdata% as well, albeit in a different folder structure from GPP history files. Namely, under %programdata%MicrosoftGroupPolicyUsers<SID of User>. I thought it was mildly funny that they have two folder structures under the Microsoft folder, one called “Group Policy” and the other called “GroupPolicy”. Oh well. This latter path is also where the per-user Group Policy Cache files are kept. See this article for a review of the Group Policy cache.
Selon l'auteur de cet exploit, il a fallu près d'un an à Microsoft pour corriger ce problème. Je peux tout à fait imaginer que ce soit le cas. Étant donné qu'entre toutes les zones de préférences de GP et toutes les zones qui utilisent ntuser.pol, y compris Admin Templates, AppLocker, Windows Firewall, Public Key Policy, et probablement d'autres qui m'échappent, cela aurait pu représenter potentiellement beaucoup de code à parcourir pour s'assurer que le déplacement de ces fichiers ne cassait pas tout. Je ne serais pas surpris que des failles apparaissent encore dans un coin obscur de la politique avant que tout ne soit terminé. Néanmoins, il s'agit d'un exploit intéressant, rendu encore plus intéressant par quelques verrues vieilles de 20 ans que GP a apportées à la fête.
Vous souhaitez en savoir plus sur la gestion de la stratégie de groupe dans une optique de sécurité ? Regardez notre webinaire qui résume les quatre années de recherche que j'ai effectuées sur les différentes façons dont les attaquants exploitent la stratégie de groupe. Plus important encore, je présenterai les étapes clés que vous pouvez suivre pour défendre votre environnement GP, et donc votre environnement Windows, contre les abus. J'espère vous y voir.
