(Enfin ?) Comprendre les vecteurs d’attaques Active Directory, un guide des vulnérabilités et configurations dangereuses : Partie I

CONTEXTE

La sécurité Active Directory (AD) est un domaine vaste et complexe qui soulève de nombreux défis pour les équipes techniques, et qui demande également de se maintenir au courant des nouvelles méthodologies qui émergent régulièrement de la recherche. De plus, nombreux sont les administrateurs qui se retrouvent à gérer une infrastructure AD héritée d’un administrateur précédent ou d’une intégration. En résulte souvent une connaissance plus « pratique » sur la façon d’administrer cette gigantesque boîte à outils qu’une compréhension profonde des nombreux mécanismes et protocoles qui régissent l’AD.

Dans ce contexte, un test d’intrusion n’est pas seulement un moyen d’évaluer l’état de sécurité de son AD, mais aussi une opportunité pour les équipes techniques qui recevront les rapports et les recommandations d’acquérir de nouvelles connaissances sur la sécurité AD (et la sécurité en général), et ainsi mieux protéger leurs infrastructures contre les menaces.

Cependant, il est souvent observé que le manque de temps et de connaissances spécifiques sur l’AD (et non pas de compétences, car tout s’apprend en sécurité) peut engendrer des retards significatifs dans l’élaboration des plans de sécurisation. Parfois, ce manque de connaissances peut même mener à la création de nouvelles vulnérabilités. Ou pire encore, jeter un voile sur les vulnérabilités et les configurations dangereuses déjà présentes, qu’elles aient été identifiées lors d’audits précédents ou non, laissant ainsi des portes ouvertes aux attaquants.

Cette série d’articles consistera en des explications succinctes de ces vecteurs d’attaques selon un modèle Pourquoi ce vecteur fragilise mon infrastructure ? Comment détecter ? La vocation de ces guides est d’expliquer comment ces mauvaises configurations sont décelables, en quoi elles rendent l’infrastructure vulnérable, tout en restant le plus explicite pour tous. Ces mini-guides AD ont pour but d’être consultables par les équipes techniques afin d’avoir une première compréhension des vecteurs d’attaques AD ou pour rafraîchir des points de détails, mais également par les acteurs de plus haut niveau pour se sensibiliser. Nous tenterons également d’aller crescendo dans la complexité.

Vecteur I : ms-DS-MachineAccountQuota

Ce premier vecteur est relativement simple à comprendre. Par défaut, tous les membres du groupe Utilisateurs authentifiés ont la possibilité de rajouter jusqu’à 10 comptes machines au sein du domaine. L’appartenance à ce groupe est définie comme ceci par Microsoft :

Tout utilisateur qui accède au système avec un processus de connexion à l’identité Utilisateurs authentifiés. Cette identité donne accès aux ressources partagées au sein du domaine, comme les fichiers d’un dossier partagé qui doivent être accessibles à tous les travailleurs de l’organisation.

Compte tenu de cette définition, on comprend aisément en quoi le fait que n’importe qui puisse rajouter et contrôler des comptes devient dangereux. Dans le cadre d’attaque par usurpation de comptes utilisateurs (interception puis relai d’authentification), un attaquant peut faire ajouter des comptes ordinateurs dans le domaine dont il aura le contrôle, et qui autorisera par la suite des attaques plus poussées (voire la compromission du domaine).

La détection de cette configuration est très simple : la valeur de l’attribut LDAP ms-DS-MachineAccountQuota est facilement requêtable avec la console ADSI :

ou avec Powershell :

Get-ADObject -Identity ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota | select -ExpandProperty ms-DS-MachineAccountQuota

Vecteur II : ADIDNS

ADIDNS, pour Active Directory-Integrated DNS est simplement l’implémentation des mécanismes DNS au sein d’Active Directory. Il se traduit par l’installation d’un rôle pour Windows Server.

En partant de la posture d’un administrateur, on pourrait croire que la gestion d’un serveur DNS serait fondamentalement réservée aux admins (tout comme la création des comptes machines au passage), mais il n’en est rien. Il est possible pour les utilisateurs de base d’ajouter des nouveaux enregistrements DNS (à condition qu’aucun autre enregistrement du même nom n’existe). Un attaquant sans privilèges particuliers peut ainsi faire pointer des enregistrements vers lui.

La première chose à faire pour un attaquant est donc d’ajouter un nouvel enregistrement wildcard( * ) pour faire pointer toute requête DNS pour un enregistrement n’existant pas vers son adresse IP (le record wildcardagissant comme enregistrement par défaut lorsqu’aucune réponse n’est trouvée pour une demande).

Pour vérifier si le record wildcardexiste et prendre des mesures avant qu’un attaquant ne l’ajoute lui-même, le gestionnaire DNS Active Directory est là, mais Powershell permet également de facilement voir comment les requêtes sont résolus :

Ici, l’enregistrement wildcard a été ajouté et la résolution du nom IdontExist se fait correctement

Là où une absence d’enregistrement va renvoyer une erreur, ce qui signifie qu’un attaquant pourrait répondre à cette requête pour rediriger le traffic vers lui.

Vecteur III : LLMNR & NBT-NS

Toujours à propos des vecteurs d’attaques liés à la résolution de nom, ce vecteur suivant exploite des protocoles obsolètes au sein de l’infrastructure AD pour rediriger le traffic vers la machine d’un attaquant et ainsi intercepter des authentifications dans le but de les usurper.

LLMNR(pour Link-Local Multicast Name Resolution) et NBT-NS (pour NetBIOS) sont deux mécanismes de sauvetage qui prennent le dessus dans la résolution de nom au sein du domaine AD lorsque le serveur DNS principal n’a pas pu répondre à la requête DNS envoyée. Dans ce cas de figure (si les protocoles LLMNR & NBT-NS ne sont pas explicitement désactivés) la machine qui cherche une réponse à sa requête DNS peut envoyer une requête en broadcast aux autres machines du réseau pour que l’une de ses voisines puissent y répondre au cas où l’une d’entre elles connait l’IP du nom requêté.

Les réponses LLMNR& NBT-NS ne sont soumises à aucun mécanisme de vérification concernant leur authenticité ou leur légitimité, il est possible de répondre aux sollicitations de résolution de nom passant sur le réseau avec une IP n’étant pas celle du nom requêté. Un attaquant peut donc rediriger ce traffic en répondant aux requêtes légitimes des machines du réseau.

Ce one-liner permet de vérifier si LLMNR est désactivé sur l’hôte :

reg query 'HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' /v EnableMulticast

Pour vérifier NBT-NS, un simple ipconfig /all suffit :

La cmdlet suivante permet également d’effectuer une requête de résolution en forçant l’utilisation de LLMNR& NBT-NS :

Si la requête renvoie que l’enregistrement existe, c’est que LLMNR& NBT-NS ne sont pas désactivés sur l’hôte

Ceci conclut ce premier article dédié aux vecteurs d’attaque AD et à leur détection. Il ne vous reste plus qu’à appliquer ces connaissances à votre Active Directory pour vérifier s’il présente ces configurations 👍