ACL dangereuses dans Active Directory : les délégations oubliées qui mènent aux Admins du domaine
Les groupes privilégiés sont généralement surveillés. Les permissions qui permettent d'y entrer, beaucoup moins. Au fil des migrations, des installations applicatives et des délégations ponctuelles, les listes de contrôle d'accès de l'annuaire accumulent des droits que plus personne ne comprend. Ce sont souvent eux qui forment le chemin le plus court vers le contrôle du domaine.
Une permission peut valoir une appartenance
Chaque objet de l'annuaire porte un descripteur de sécurité : un propriétaire et une liste de contrôle d'accès discrétionnaire (DACL) composée d'entrées (ACE). Certaines de ces entrées donnent, directement ou en une étape, le contrôle complet de l'objet. Lorsqu'elles portent sur un groupe privilégié, un compte d'administration, l'objet domaine ou un contrôleur de domaine, leur titulaire est de fait un administrateur, même s'il n'apparaît dans aucun groupe sensible.
Les droits à surveiller
| Droit | Ce qu'il permet |
|---|---|
| GenericAll (Contrôle total) | Tout faire sur l'objet : modifier ses attributs, réinitialiser un mot de passe, ajouter des membres. |
| WriteDACL | Modifier la liste de contrôle d'accès, donc s'octroyer n'importe quel autre droit. |
| WriteOwner | Devenir propriétaire de l'objet ; le propriétaire peut ensuite modifier la DACL. |
| GenericWrite / écriture de propriétés | Modifier des attributs sensibles : membres d'un groupe, SPN, attributs de délégation, script d'ouverture de session. |
| Réinitialiser le mot de passe | Changer le mot de passe d'un compte sans connaître l'ancien et en prendre le contrôle. |
Ajout de membres (écriture de member) | S'ajouter ou ajouter un complice à un groupe. |
| Droits de réplication sur le domaine | Demander la réplication des secrets, dont les hachages de mots de passe de tous les comptes. |
Il faut y ajouter les droits sur les objets de stratégie de groupe liés à des OU sensibles et sur les OU elles-mêmes : contrôler une GPO appliquée aux contrôleurs de domaine revient à contrôler le domaine.
Penser en chemins, pas en permissions isolées
Une permission isolée paraît souvent anodine : le support peut réinitialiser les mots de passe d'une OU, un groupe applicatif peut modifier un autre groupe. Le danger naît de l'enchaînement. Un compte du support réinitialise le mot de passe d'un compte de service ; ce compte dispose de GenericWrite sur un groupe ; ce groupe a WriteDACL sur l'objet domaine. Trois étapes, et un technicien de niveau 2 devient administrateur du domaine.
C'est pourquoi l'analyse repose sur des graphes : chaque objet est un nœud, chaque droit exploitable une arête, et l'on recherche les chemins qui aboutissent aux objets de niveau 0. Les outils d'analyse de chemins d'attaque, y compris ceux utilisés par les attaquants, fonctionnent ainsi. Les défenseurs ont tout intérêt à mener cette analyse avant eux.
AdminSDHolder. Les comptes et groupes protégés voient leur DACL réécrite périodiquement à partir de l'objet AdminSDHolder. Une ACE ajoutée sur AdminSDHolder se propage donc à tous les objets protégés : c'est un mécanisme de persistance classique, à contrôler en priorité.
Les sources habituelles de délégations dangereuses
- des produits installés avec des droits étendus sur le domaine, dont certaines anciennes versions de messagerie ou de synchronisation d'annuaire ;
- des délégations faites via l'assistant de délégation sur la racine du domaine plutôt que sur une OU ciblée ;
- des propriétaires d'objets restés des comptes personnels, parce qu'un administrateur a créé le groupe ou le compte ;
- des héritages non maîtrisés : une permission large posée sur une OU parente s'applique aux comptes sensibles déplacés dessous ;
- des comptes supprimés dont il ne reste que le SID dans les ACE, souvent le signe d'une délégation jamais revue.
Nettoyer méthodiquement
- Cartographiez les chemins menant aux objets de niveau 0 et classez-les par nombre d'étapes.
- Traitez d'abord les droits directs sur l'objet domaine, AdminSDHolder, les groupes privilégiés, les contrôleurs de domaine et leurs GPO.
- Rétablissez un propriétaire cohérent (Admins du domaine) sur les objets sensibles.
- Remplacez les délégations larges par des délégations sur OU dédiées, accordées à des groupes et limitées aux attributs nécessaires.
- Documentez chaque délégation conservée et relancez l'analyse pour vérifier que les chemins ont disparu.
Testez les retraits sur un périmètre restreint : certaines applications dépendent réellement d'un droit, et il vaut mieux le réduire que le supprimer brutalement.
Ce qu'un audit vérifie
- les ACE non standard sur l'objet domaine, AdminSDHolder et les conteneurs sensibles ;
- les détenteurs des droits de réplication des secrets ;
- les propriétaires des objets privilégiés ;
- les chemins d'attaque menant aux groupes de niveau 0 et leur longueur ;
- les droits de modification sur les GPO liées aux contrôleurs de domaine.