I. Présentation
Dans un tutoriel précédent, nous avons découvert la vulnérabilité "Broken owner" de l'Active Directory liée aux délégations d’administration et de manipulations que nous effectuons au quotidien sur les objets de l'annuaire Active Directory.
Nous allons poursuivre l'aventure et voir dans cet article comment corriger cette vulnérabilité en ajustant les propriétaires des objets, puis nous verrons dans un troisième article, qui clôturera cette série, comment éviter que cela se produise.
II. Retour sur la vulnérabilité "Broken owner"
A. Rappel
D'après l'article précédent, cette vulnérabilité se produit lorsqu’un objet est créé dans l’AD par un compte à non-privilège (à l’issue d’une délégation) ou créé par un compte à privilège qui ne l’est plus (après le retrait de ce dernier des groupes à privilèges).
B. Recommandations
D'après l’ANSSI et Microsoft, il est recommandé de mettre en place un groupe à privilèges comme propriétaire des objets, parmi ceux-ci: Administrateurs du domaine, Administrateur de l’entreprise, Administrateurs. Il s'agit d'éléments natifs, que vous connaissez probablement.
C. Pourquoi faut-il corriger le propriétaire ?
Il est indispensable de corriger l’objet afin d'ajuster le propriétaire dans l'objectif d'atténuer la surface d’attaque et les chemins d'accès. Pour rappel, une personne malveillante ne cherche pas absolument à être admin du domaine, mais plutôt à compromettre les données ou les extraire. De ce fait, garder les objets sans propriétaire (owner) ou avec un owner sensible expose votre entreprise à des risques de sécurité permanent, en plus d'alourdir la tâche de l’équipe SOC.
Dans le schéma ci-dessous, après la correction, la personne malveillante ne pourra plus se procurer les objets dont le HelpDesk est propriétaire, ce qui l'empêchera de s'octroyer les droits et d'accéder aux ressources de l’objet (Utilisateur RSI ou Secrétaire dans notre cas).
D. Comment corriger le propriétaire de l'objet ?
Deux méthodes s’offrent à nous : faire le changement manuellement à partir de l’onglet "Sécurité" et choisir un groupe à privilège par défaut (par exemple "Admin du domaine"), ou utiliser un script. Cette seconde option sera traitée dans un second temps, dans cet article.
Voici un exemple de modification sur le compte "Florian". Actuellement le propriétaire est "helpdesk1".
On le change pour définir le groupe "Admins du domaine" à la place.
Note : Si vous choisissez un groupe étant membre d’un groupe à privilèges, mais qu’il n’est pas natif (exemple "GG_admins" membre de admins du domaine), la correction sur les objets Owner ne se fera pas automatiquement, et c’est ce groupe qui résidera comme Owner. Dans le cas où il ne fera plus partie du groupe à privilèges ("Admin du domaine"), les objets seront une nouvelle fois vulnérables.
Après correction, nous constatons qu’il n’est plus possible à l’utilisateur "HelpDesk1" de faire des modifications sur l'objet "Florian". Les ACLs sont grisées :
E. Les Exceptions
Avant de faire tout changement, prenez le temps d’analyser le résultat du premier script, dont on a déjà parlé dans l'article précédent. En effet, certaines applications manipulent des objets AD au cours de leur cycle de vie, devenant ainsi propriétaire de certains. Le changement de propriétaire sur les objets dont elles sont propriétaires pourrait les empêcher de réaliser totalement leurs tâches.
Pour cette raison, il convient d'auditer votre configuration avant de réaliser la correction.
F. Persistance
Bien que la correction constitue un premier remède, cela n’est pas suffisant. Si le propriétaire s'est déjà procuré les droits "Contrôle total" (CT) ou de modification des permissions sur un objet, la correction n’apportera pas grande chose au niveau de la sécurité. Cette subtilité sera abordée dans le prochain article.
III. Corriger les propriétaires avec un script PowerShell
Pour automatiser la correction des propriétaires des objets, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche ! Voici le lien du script PowerShell : Script CABOO (Correct Broken Owner)
Le projet porte le nom de CABOO (Correct-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.
L'exécution de ce script nécessite les prérequis ci-dessous :
- Une machine membre du domaine
- Un compte utilisateur membre du groupe "Administrateur du domaine"
Pourquoi faut-il l'exécuter en mode administrateur ? Cela se justifie par le fait que les deux commandes pour remplacer le propriétaire ne passent pas avec les droits standards.
$ownerinfo.PsBase.ObjectSecurity.SetOwner($NewOwner)
$ownerinfo.PsBase.CommitChanges()
Le script utilise le même principe que le script d’audit SCABOO.
A. Corriger les propriétaires sur une OU
Lancez le script et choisissez l’option "2". Ensuite indiquez votre OU et valider par OK.
1 - Sélectionnez l’OU
2 - Choisissez le nouveau propriétaire (pour suivre les recommandations, cochez "Admins du domaine")
3 - Vérifiez que le bon groupe est sélectionné, puis appuyez sur OK
Le traitement est alors lancé ! En cas d’erreur, cela sera affiché sur le résultat final ou en cours du scan. De toute façon, il est possible d'arrêter le script à tout moment.
Une fois l'exécution terminée, une page HTML s'affiche en guise de rapport pour indiquer indiquer les objets changés, ainsi que l’ancien propriétaire. Le nouveau, vous le connaissez.
B. Exclure un utilisateur ou un groupe
Si vous voulez exclure un compte ou un groupe du processus de correction, il suffit d’ajouter ce dernier à la variable "$skipdefaultgroups" présente à la ligne 50 du script. Indiquez bien le nom du groupe, sans le nom du domaine.
Exemple : pour ne pas corriger les objets ayant "SCCM$" ou "Exchange" comme propriétaire, faites ceci :
C. Scanner sur un type d’objet
Si votre OU contient des utilisateurs, groupes et machines, et que vous ne souhaitez faire la correction que sur les utilisateurs, il suffit de commenter la ligne "$newowner" sur le type que vous souhaitez ignorer. Dans notre cas, nous allons ignorer le traitement sur les types "OU" et "groupes".
Si vous obtenez une erreur lors du traitement, c’est que le script n’est pas lancé en mode admin. Sinon, lisez le code d’erreur afficher sur la console PowerShell ISE (ou VSCode) lors du traitement. Dans notre cas "error" signifie que le traitement n’est pas abouti, et aucune modification n’a été faite. Vous pouvez contribuer à ce script ou le modifier à votre convenance !
Rendez-vous prochainement pour la suite de cet article, où nous verrons comment éviter de se retrouver avec des propriétaires inadaptés sur les objets de l'Active Directory.
The post
Active Directory : comment corriger les propriétaires inadaptés sur les objets ? first appeared on
IT-Connect.
