© 2019. Tous droits réservés.
Comme on le voit sur cette capture d’écran, il est possible de créer/modifier des scripts au démarrage et à l’arrêt d’une machine, de changer les paramètres
du pare-feu, de créer des tâches planifiées, ou même d’ajouter des utilisateurs au groupe local d’administration. Ce ne sont que des exemples parmi tant d’autres pour montrer à quel point les fonctionnalités imposables via GPO sont diverses et puissantes.Composition
Une GPO est composée de deux éléments :
C’est ici que sont gérés finement les droits de création/modification des GPO, comme tout objet de l’Active Directory.
C’est grâce à l’exposition de ces fichiers aux comptes de domaine que ces derniers peuvent mettre à jour leurs GPO.
Contexte de recherche
Dans ma croisade en plein Active Directory, j’utilise de manière très intense l’outil développé par , et , que je ne remercierai jamais assez pour leur travail et leur disponibilité sur leur slack .
Après avoir regardé la de et à la conférence , j’ai commencé à me pencher sur les chemins d’attaque impliquant les GPO. Bloodhound aide énormément sur ce sujet, et propose notamment un chemin d’attaque lorsqu’un compte du domaine a les droits sur une GPO.
Sur ce schéma, on voit un utilisateur avec un crâne, correspondant à un compte compromis. Ce compte fait partie d’un groupe qui possède les droits sur une GPO. Cette GPO s’applique enfin à une unité d’organisation (OU) contenant notamment l’utilisateur en bas à droite, cible de l’attaque.
Ce droit permet aux membres du groupe de modifier les ACL (Access Control List) de la GPO concernée, c’est à dire les droits d’accès à la GPO, notamment la modification du propriétaire de l’objet. Ainsi, un utilisateur du groupe possédant ce droit peut s’auto-proclamer propriétaire, pour ensuite la modifier arbitrairement.
Par défaut, lorsqu’une GPO est créée, peu de personnes ont le droit de la modifier. Les utilisateurs peuvent la lire (obligatoire pour pouvoir l’appliquer !), mais seuls les groupes “Domain Admins” et “Enterprise Admins” ont les droits absolus dessus, c’est à dire qu’ils peuvent la modifier (Edit Settings), la supprimer (Delete), et modifier les droits d’accès (Modify Security).
Si un administrateur souhaite déléguer ces permissions à un utilisateur sans pour autant l’ajouter à l’un des deux groupes, c’est tout à fait possible via cet onglet de délégation. C’est un endroit simplifiant la gestion des droits sur une GPO. En effet, il est tout à fait possible de modifier les droits directement au niveau de la GPC, mais c’est beaucoup plus complexe.
On voit que la barre de défilement permet de lister un grand, très grand nombre de paramètres d’accès.
Il est donc plus aisé de passer par l’interface de gestion des GPO pour ajouter un utilisateur afin de lui déléguer des droits :
Puis on indique les droits qu’on lui concède :
Trois choix sont proposés, choix qui sont une préselection facilitant la vie des administrateurs, en modifiant des droits bien précis au niveau de la GPC.
Maintenant cet utilisateur fait partie des personnes/groupes à avoir les droits ultimes sur cette GPO. C’est ce contrôle total que l’on voit apparaitre dans BloodHound lorsqu’une entité a un lien “WriteDacl” vers une GPO. En effet, cette présélection ajoute les paramètres de sécurité “Modify Owner” et “Modify Permissions”.
Droit “Edit Settings”
On a vu au-dessus qu’il y avait trois niveaux de délégation :
Il n’y a que le troisième niveau qui est pris en charge dans la collecte BloodHound. Cependant, que se passe-t-il si un utilisateur ne possède que le droit de modifier la GPO, mais pas les ACL associées ? BloodHound ne remontant pas ce lien, c’est la question que je me suis posée.
Pour y répondre, j’ai créé une GPO d’exemple, appelée “TestGPO Abuse”, s’appliquant à l’ensemble des utilisateurs appartenant à l’OU “Domain Users”. Comme dans l’exemple précédant, j’ai ajouté l’utilisateur “jdoe” dans la délégation de la gestion de cette GPO, en indiquant qu’il ne pouvait que modifier les paramètres de cette GPO, mais pas les ACL associées (“Edit Settings”).
GPO appliquée à des utilisateurs
Dans ma recherche, je souhaitais également savoir ce que je pouvais faire lorsque la GPO ne s’appliquait qu’à des utilisateurs, pas à des machines. C’est pourquoi “TestGPO Abuse” ne s’applique qu’à l’OU “Domain Users”. En effet, tous les paramètres contrôlables dans la partie “Computer Configuration” de la GPO ne s’appliqueront pas si cette GPO est destinée à des utilisateurs. Seuls ceux dans “User Configuration” le seront.
Mais concrètement, qu’est-ce qui est disponible dans les paramètres de GPO appliqués à un utilisateur ? Et bien beaucoup moins de choses, mais des paramètres intéressants tout de même !
On voit qu’on peut installer des paquets, gérer encore une fois les scripts au login/logout, éditer des groupes et utilisateurs locaux et les tâches planifiées.
Exploitation via une tâche planifiée immédiate
Nous allons nous intéresser plus particulièrement aux tâches planifiées. Il est possible de créer des tâches planifiées qui s’exécuteront immédiatement, lorsque la GPO sera appliquée à l’utilisateur.
Ainsi, si nous nous connectons en tant que l’utilisateur sur une machine, nous pouvons créer cette tâche.
Elle est créée en tant que l’utilisateur , et lorsqu’elle sera appliquée, ce sera en tant que l’utilisateur à qui elle s’applique.
Dans l’onglet “Actions”, nous indiquons ce qu’il se passera à l’exécution. Ici, nous utilisons un reverse-shell en Powershell pour que lors de son exécution, l’utilisateur cible se connecte à l’attaquant en proposant un shell.
Ce code est transormé en base 64 pour le passer à la commande .
Une fois cette tâche créée, lors de la mise à jour des GPO sur un client, par exemple sur le compte qui est administrateur du domaine dans ce lab, elle est exécutée sur la machine, et l’attaquant récupère un shell en tant qu’administrateur du domaine.
Conclusion
L’idée de cet article est de montrer que les GPO sont un pilier dans l’organisation d’un Active Directory, et doivent être maitrisées tout autant que beaucoup d’autres objets. Une permission mal placée peut permettre à un attaquant d’en abuser et d’élever ses privilèges dans le système d’information.
Ici, l’exemple de la tâche planifiée a été utilisé sur une GPO appliquée à des utilisateurs, cependant il existe un grand nombre de possibilités ouvertes par les GPO qui peuvent être utilisées pour exécuter du code.