LDAP anonyme et « accès compatible pré-Windows 2000 » : fermer les lectures sans authentification
Un attaquant qui arrive sur le réseau sans aucun identifiant cherche d'abord à savoir ce que l'annuaire veut bien lui dire. Dans un domaine récent et bien tenu, presque rien. Mais les forêts qui ont traversé plusieurs générations de Windows conservent souvent des réglages de compatibilité qui permettent d'énumérer comptes et groupes de façon anonyme.
Pourquoi l'accès anonyme compte
La liste des comptes, des groupes et de leurs membres, les descriptions qui contiennent parfois des mots de passe, la stratégie de mot de passe du domaine : ces informations permettent de préparer une attaque par pulvérisation de mots de passe ou de repérer les comptes à cibler. Les obtenir sans aucun identifiant fait gagner un temps précieux à un attaquant et le dispense de compromettre d'abord un compte. Fermer les accès anonymes ne bloque pas une attaque déterminée, mais retire une première marche.
LDAP anonyme : dSHeuristics
Depuis Windows Server 2003, les contrôleurs de domaine refusent par défaut les opérations LDAP anonymes, à l'exception de la lecture du rootDSE, nécessaire au fonctionnement des clients. Ce comportement peut être modifié par l'attribut dSHeuristics de l'objet CN=Directory Service dans la partition de configuration : lorsque son septième caractère vaut 2, les opérations anonymes sont autorisées, sous réserve des permissions accordées sur les objets.
Nous trouvons encore cette valeur dans des forêts où une application ancienne, parfois disparue depuis, l'avait exigée. L'attribut dSHeuristics porte d'autres réglages sous forme de caractères positionnels : toute modification doit donc être faite avec précaution, en ne changeant que le caractère concerné et en documentant la valeur initiale.
Le groupe « Accès compatible pré-Windows 2000 »
Ce groupe intégré, « Pre-Windows 2000 Compatible Access », reçoit des droits de lecture étendus sur les utilisateurs, les groupes et l'objet domaine. Il existe pour les services hérités de Windows NT qui interrogeaient l'annuaire sans contexte d'utilisateur. Ce qui compte, c'est sa composition :
- s'il contient Ouverture de session anonyme (Anonymous Logon), ces droits de lecture sont accordés à des connexions non authentifiées ;
- s'il contient Tout le monde (Everyone), l'effet est similaire si le paramètre qui fait s'appliquer les permissions de « Tout le monde » aux utilisateurs anonymes est activé ;
- s'il contient Utilisateurs authentifiés, la situation est différente : il s'agit de la configuration courante des domaines récents, qui n'ouvre rien aux anonymes.
La présence d'Anonymous Logon ou d'Everyone dans ce groupe vient généralement d'une promotion du premier contrôleur de domaine avec l'option de compatibilité avec les serveurs antérieurs à Windows 2000. Plus de vingt ans après, elle n'a pratiquement jamais de justification.
Conjonction dangereuse. C'est la combinaison qui crée l'exposition : des opérations LDAP anonymes autorisées par dSHeuristics et des droits de lecture accordés à Anonymous Logon, directement ou via ce groupe. Nous vérifions toujours les deux ensemble.
Les sessions nulles et l'énumération par RPC
LDAP n'est pas le seul canal. Les sessions SMB anonymes, dites sessions nulles, permettent sur des systèmes mal configurés d'interroger les services SAM et LSA à distance pour énumérer comptes, groupes et partages, ou traduire des identifiants de sécurité en noms. Plusieurs paramètres de stratégie de sécurité encadrent ces accès :
- ne pas autoriser l'énumération anonyme des comptes et partages SAM ;
- restreindre l'accès anonyme aux canaux nommés et aux partages, et vider les listes d'exceptions ;
- ne pas autoriser la traduction anonyme SID/nom ;
- ne pas laisser les permissions de « Tout le monde » s'appliquer aux utilisateurs anonymes.
Ces réglages doivent être appliqués sur les contrôleurs de domaine comme sur les serveurs membres, par stratégie de groupe, et non laissés à des valeurs héritées d'anciens modèles de sécurité.
Faire le ménage sans surprise
Les dépendances réelles sont rares, mais il vaut mieux les identifier avant de couper. Avant toute modification, activez temporairement la journalisation de diagnostic de l'interface LDAP sur les contrôleurs, ou effectuez des captures réseau ciblées, pour repérer les clients qui se connectent sans authentification. Retirez ensuite Anonymous Logon et Everyone du groupe pré-Windows 2000, rétablissez la valeur par défaut du caractère concerné de dSHeuristics, puis durcissez les paramètres de sessions nulles. Enfin, vérifiez depuis une machine hors domaine qu'aucune énumération anonyme n'aboutit plus.
Ce qu'un audit vérifie
- La valeur de
dSHeuristicset en particulier l'autorisation des opérations anonymes. - La composition du groupe « Accès compatible pré-Windows 2000 ».
- Les permissions accordées directement à Anonymous Logon ou Everyone sur les objets de l'annuaire.
- Les paramètres de stratégie relatifs à l'accès anonyme sur les contrôleurs et les serveurs.
- Un test réel d'énumération anonyme LDAP et RPC depuis une machine non jointe.