Darren Mar-Elia, vice-président des produits

Si vous suivez ce blog, vous savez qu'il y a environ deux ans et demi, j'ai commencé à parler du rôle précaire de la stratégie de groupe dans le dispositif de sécurité de l'entreprise type. De nombreux, voire la plupart des ateliers AD utilisent la stratégie de groupe pour renforcer la sécurité de leurs ordinateurs de bureau et serveurs Windows. Cela va du réglage des paramètres du système d'exploitation à la désactivation de NTLMv1 ou à la manipulation du contrôle des comptes d'utilisateurs (UAC), en passant par le contrôle des personnes autorisées à se connecter à certaines machines et des groupes AD ayant un accès privilégié à certains postes de travail et serveurs. Tout cela est stocké dans des GPO qui, par défaut, sont "lisibles dans le monde entier" par tout utilisateur authentifié. Ce fait est avéré depuis longtemps - en fait depuis 2000, année de livraison d'AD et de GP - mais il n'est devenu plus visible en tant que problème potentiel d'InfoSec que ces dernières années, en grande partie grâce à des outils tels que Bloodhound, PowerView et Grouper qui mettent en évidence le fait que ces informations peuvent être utilisées pour commettre toutes sortes de méfaits.

Depuis, je me suis surtout concentré sur l'aspect défensif de l'équation, et principalement sur les recommandations visant à réduire la lisibilité des GPO relatives à la sécurité afin d'empêcher un attaquant de découvrir facilement le dispositif de sécurité d'une organisation. Cependant, plus récemment, j'ai réfléchi aux possibilités d'utilisation plus destructrice des GPO, en exploitant les paramètres existants dans les GPO modifiables pour effectuer diverses tâches malveillantes au sein d'un environnement. Étant donné que les GPO ont souvent un impact sur la plupart, voire la totalité, des utilisateurs et des ordinateurs d'une organisation, il s'agit d'un mécanisme de distribution de logiciels malveillants très efficace, comme je l'ai illustré dans un billet de blog il y a quelque temps. Ces types d'attaques qui injectent des paramètres malveillants dans une GPO reposent sur la capacité de l'attaquant à obtenir des droits d'écriture sur une GPO, à savoir la partie SYSVOL de la GPO où la plupart (mais pas toutes) des extensions côté client (CSE) de GP stockent leurs paramètres. Bien entendu, vous devez également comprendre le format des paramètres du domaine de stratégie sur lequel vous souhaitez avoir un impact afin de le détourner, et pour une fois, la façon dont Microsoft a abordé le développement des CSE est un avantage ici, puisque pratiquement chaque domaine de stratégie utilise un schéma et une structure de données différents pour stocker ses paramètres. Un point pour l'incohérence architecturale !

Trois façons de créer des problèmes

En réfléchissant à la généralisation et à ses faiblesses, j'en suis venu à la conclusion qu'il existe (au moins) trois voies principales permettant à un attaquant d'utiliser la généralisation à des fins malveillantes. A savoir,

  • Tirer parti d'un accès en lecture trop permissif sur les GPO pour connaître le niveau de sécurité d'une organisation (qui a un accès privilégié, où, etc.). Comme je l'ai mentionné, j'ai déjà publié de nombreux articles sur ce sujet et j'ai proposé des solutions pour l'atténuer.
  • Tirer parti d'un accès en écriture trop permissif sur les GPO pour injecter des paramètres malveillants dans les GPO existantes. J'en parle plus bas dans la section intitulée "Délégation de GPO". Le New-GPOImmediateTaskcmdletde PowerView est un parfait exemple de cette approche qui consiste à injecter une tâche programmée dans un GPO afin d'exécuter un code arbitraire.
  • Exploiter les chemins externes qui sont référencés dans les GPO et qui ont un accès en écriture trop permissif. Il s'agit d'une variante du point 2 et j'ai vraiment compris la puissance de cette idée en testant et en collaborant avec @mikeloss sur son excellent utilitaire Grouper2 référencé ci-dessus. Grouper2 recherche des éléments "intéressants" dans les GPO, ce qui peut aller de la politique des groupes restreints accordant un accès privilégié aux mots de passe GPP persistants à, plus intéressant pour moi, des références à des exécutables, des scripts ou des installateurs externes. Je passe plus de temps à parler de ces chemins externes dans la section intitulée "Chemins externes", mais @mikeloss mérite vraiment d'être félicité pour m'avoir fait prendre conscience de ce problème.

Délégation du GPO

Parlons plus en détail du point 2 ci-dessus. Le fonctionnement de la délégation de GPO est le suivant : vous accordez à des utilisateurs, des ordinateurs ou des groupes, différents niveaux d'accès à une GPO, généralement dans GPMC à partir de l'onglet "Délégation" d'une GPO donnée, ou en utilisant PowerShell, et ces permissions (qui incluent Read, ReadApply, "Edit Settings" et "Edit Settings, Delete and Modify Security") sont estampillées sur l'objet correspondant du conteneur de stratégie de groupe (GPC) basé sur AD et le dossier nommé GUID dans le modèle de stratégie de groupe (GPT) (c.-à-d. SYSVOL). Il est évident que les autorisations AD ne correspondent pas à 1-1 aux autorisations du système de fichiers NTFS, mais si vous examinez les deux parties d'une GPO dans l'éditeur ACL, vous constaterez que les autorisations sont très similaires (voir ci-dessous).

Ainsi, en tant qu'attaquant, vous devez être en mesure d'obtenir un accès en écriture au GPT (ou dans certains cas au GPC) d'un GPO donné afin de compromettre ce GPO. Ce n'est évidemment pas impossible, surtout si l'attaquant est capable de s'élever à un rôle d'administrateur qui pourrait avoir des permissions d'édition sur un GPO. Mais, du point de vue du défenseur, cela souligne l'importance d'un contrôle rigoureux des délégations de GPO. Les droits d'édition ou de création de GPO ne devraient être délégués qu'à une poignée d'administrateurs système, et ces responsables de la sécurité devraient être traités comme des administrateurs de "niveau 0", compte tenu de l'impact potentiel d'une modification malveillante des GPO sur l'ensemble de l'environnement. Plus inquiétant encore, si un attaquant obtient un accès en écriture, par exemple, au GPT, il peut être très difficile de détecter ces changements malveillants si l'attaquant modifie directement les fichiers de paramètres, plutôt que de passer par des outils de gestion des changements de GPO tels que l'Éditeur de GP. Vous devez essentiellement rechercher les modifications du système de fichiers sur le GPT pour pouvoir repérer la plupart de ces modifications indésirables, mais étant donné que les modifications de GPO légitimes génèrent des notifications de modification du GPT, vous devez également être en mesure de passer au crible les modifications de GPO malveillantes et valides pour trouver celles qui peuvent vous causer des maux de tête. La bonne nouvelle, c'est que si un attaquant doit ajouter de nouveaux paramètres nets de zone de stratégie (c'est-à-dire qu'il doit appeler un CSE autre que celui qui a déjà été déployé) à un GPO, ses chances d'être détecté augmentent. En effet, pour qu'un client (serveur ou poste de travail) puisse traiter un nouveau paramètre de domaine de stratégie d'une GPO, plusieurs modifications doivent être apportées au GPC (par exemple, le numéro de version est incrémenté et les CSE ExtensionGUID sont ajoutés correctement au GPC) pour que le client soit informé de ces paramètres, ce qui fait qu'il est plus difficile pour un administrateur disposant d'un niveau décent d'audit GP de ne pas remarquer la falsification. En ce qui concerne les domaines de stratégie les plus propices à ce type de manipulation, consultez l'excellent article de @_wald0 intitulé "A Red Teamer's Guide to GPOs and OUs" pour obtenir des exemples de chemins de stratégie qui peuvent être manipulés à bon escient. Ce point plaide également en faveur d'un verrouillage supplémentaire des GPO qui mettent en œuvre des domaines de stratégie hautement "exploitables". En résumé, verrouillez les personnes autorisées à modifier ces GPO !

Voies externes

Ceci m'amène à ma dernière fascination (#3 ci-dessus), qui est l'utilisation de références de "chemins externes" dans les GPOs pour contourner la limitation imposée par les administrateurs au #2 ci-dessus. Qu'est-ce que j'entends par "chemins externes" ? En fait, toute référence trouvée dans une GPO, qui pointe vers un exécutable, un script, un package MSI ou un autre fichier qui "fait quelque chose" lorsqu'il est appelé, et qui existe en dehors des emplacements normaux GPC et GPT (Sysvol). Pourquoi ces fichiers sont-ils intéressants ? Parce que, même si vous verrouillez l'accès en écriture aux GPO comme je l'ai suggéré au point 2, vous pouvez potentiellement avoir des scripts, des exécutables et des paquets MSI qui jonchent les serveurs de fichiers sur l'ensemble de votre réseau, avec différents degrés de contrôle d'accès, et qui sont appelés et exécutés par ces mêmes GPO verrouillées que vous pensiez être si sûres. Ainsi, un attaquant qui n'obtient pas l'accès en écriture à une GPO peut utiliser son accès en lecture (comme au point 1 ci-dessus) pour rechercher ces chemins externes référencés et essayer de remplacer ces scripts, exes et MSI par leurs propres versions malveillantes (cette tâche est en effet ce que Grouper2 rend beaucoup plus facile). La prochaine fois que cette GPO est traitée par un client, ce fichier malveillant est joyeusement exécuté par la GPO, qui ne s'en aperçoit pas. Voici quelques exemples de domaines de stratégie qui peuvent typiquement référencer des chemins externes (c'est-à-dire des chemins en dehors du GPC et du GPT) :

  • Scripts de démarrage/arrêt et de connexion/déconnexion
  • Installation du logiciel GP (fichiers MSI)
  • Préférences GP Tâches planifiées
  • GP Preferences Printers (avec TCP/IP Printers, vous pouvez spécifier un chemin externe à partir duquel le client peut télécharger les pilotes d'imprimante - c'est bien !)
  • Raccourcis des préférences GP, pour les raccourcis qui existent dans les emplacements d'exécution automatique tels que le Démarrage
  • Fichiers de préférences GP, où vous avez des fichiers qui peuvent être copiés à partir d'emplacements externes arbitraires dans des emplacements de fichiers locaux d'exécution automatique ou d'autres fichiers "faciles à exécuter".

Pour être honnête, il y a probablement plus d'endroits de ce type cachés dans GP (et je continue à chercher...). Ceux mentionnés ci-dessus sont les plus évidents.

Alors pourquoi se préoccuper de ces chemins externes ? Pensez-y : le problème de la prévention de l'altération non désirée des GPO, tel qu'il est décrit au point 2 ci-dessus, est limité. Il suffit de se préoccuper de la délégation de ces GPO pour contrôler ce type de comportement. Mais lorsque vous avez des GPO qui référencent du code exécutable sur des partages de fichiers externes, vous devez maintenant étendre votre champ d'action à CHAQUE LOCATION DE FICHIER ! Combien d'entre vous peuvent être sûrs de la gestion des autorisations sur des partages de fichiers aléatoires au sein de leur environnement (sans parler de leurs GPO) ? Ainsi, si un GPO appelle un fichier exécutable ou un programme d'installation qui existe sur un partage non sécurisé, vos GPO deviennent maintenant des véhicules de distribution involontaires pour n'importe quelle merde aléatoire par laquelle un attaquant peut remplacer ces exécutables. Et bien sûr, comme il n'y a pas de contrôle CRC ou d'autre contrôle de validité dans la GPO, vous êtes à la merci de n'importe quel fichier qui se trouve là (une atténuation à cela est le fait que tous les domaines de politique n'exécutent pas automatiquement leurs charges utiles tout le temps. Par exemple, si une machine a déjà reçu un déploiement de logiciel via la politique d'installation de logiciel, elle ne redéploiera pas ce MSI malveillant dans des circonstances normales. Mais toute nouvelle machine recevra bien sûr le mauvais paquet).

Quel est donc l'essentiel ? En plus de sécuriser vos délégations de GPO, déterminez d'abord où se trouvent vos références de chemins externes dans votre environnement, puis SÉCURISEZ VOS PATHS EXTERNES !!!!

Résumé

J'espère que cela vous apportera quelques éléments de réflexion supplémentaires sur la protection de votre environnement GP, et donc de tout votre environnement Windows. Si vous comptez aujourd'hui sur GP pour configurer vos systèmes Windows, je ne saurais trop insister sur l'importance, du point de vue de l'InfoSec, de s'assurer que ces GPO sont bien verrouillés et que tout ce qu'ils appellent de l'extérieur est considéré comme faisant partie du même domaine de préoccupation et est également verrouillé. Pour résumer les mesures à prendre, voici ce qu'il faut faire :

  1. Verrouillez l'accès en lecture aux GPO critiques et liés à la sécurité pour vous assurer que vous ne divulguez pas votre position en matière de sécurité.
  2. Verrouiller l'accès en écriture à tous les GPO pour s'assurer qu'ils ne sont pas utilisés comme vecteur d'attaque.
  3. Verrouiller l'accès en écriture à tous les chemins externes référencés par les GPOs

Darren