Utilisation de l'usurpation DHCP DNS — Guide pratique
Introduction
Dans la première partie de cette série de blogs, nous avons présenté de nouvelles attaques contre les domaines Active Directory qui utilisent des serveurs DHCP (Dynamic Host Configuration Protocol) de Microsoft. Ces attaques permettent aux acteurs malveillants d'usurper des enregistrements DNS dans les zones DNS intégrées à Active Directory (ADIDNS) par l'utilisation abusive de la fonctionnalité Mises à jour dynamiques DHCP DNS. Nous avons étudié le fonctionnement de la fonctionnalité et mis en évidence des erreurs de configuration qui pourraient être exploitées par des hackers pour usurper des enregistrements DNS sensibles.
Dans ce deuxième article de blog, nous allons développer certains détails techniques qui sont nécessaires pour exploiter cette surface d'attaque. Après avoir expliqué en détail les méthodes utilisées pour collecter toutes les informations nécessaires pour créer des attaques, nous décrirons certaines limitations d'attaque et étudierons comment usurper plusieurs enregistrements DNS par l'utilisation abusive d'un comportement intéressant du serveur DHCP.
Enfin, nous présenterons un nouvel outil à ajouter à votre boîte à outils. Nous avons regroupé toutes nos connaissances pour créer DDSpoof , un outil écrit en Python qui permet aux équipes rouges et bleues d'effectuer et d'étudier les attaques DHCP DNS. Plus loin dans cet article de blog, nous décrirons comment l'outil peut être utilisé dans plusieurs scénarios d'attaque.
Clause de non-responsabilité : DDSpoof permet aux équipes de sécurité d'identifier les risques tout en les sensibilisant à cette surface d'attaque. Cependant, l'outil à lui seul ne suffit pas à causer des dommages réels, il nécessite un accès au réseau et une exploitation plus poussée pour une utilisation abusive de l'usurpation DNS primitive.
Énumération DHCP
Dans notre article précédent, nous avons partagé la théorie derrière l'usurpation DHCP DNS. Dans la pratique, plusieurs informations sont nécessaires pour exécuter de manière efficace les attaques que nous avons décrites. Par chance pour les hackers, la possibilité de découvrir les serveurs DHCP et d'étudier leur configuration fait partie du protocole DHCP, ce qui simplifie le processus de reconnaissance.
Dans les sections suivantes, nous décrirons différentes méthodes et astuces utilisées par les hackers à partir d'un contexte non authentifié pour collecter ces différentes informations.
Identification des serveurs DHCP
La principale composante d'une attaque DHCP DNS étant le serveur DHCP cible, la première étape consiste à en identifier un. L'identification des serveurs DHCP actifs dans le réseau est très simple. Un hacker peut envoyer un message de diffusion DHCP Discover et inspecter les offres fournies par les serveurs en réponse.
Pour envoyer des messages DHCP, nous pouvons exécuter la commande dhclient Linux, un client DHCP configurable qui permet d'interagir avec les serveurs DHCP. Nous pouvons configurer la commande dhclient en modifiant son fichier de configuration, qui se trouve dans /etc/dhcp/dhclient.conf.
Lorsque nous l'exécutons, la commande dhclient demande la configuration du réseau au serveur DHCP et l'applique à notre machine, en remplaçant notre adresse IP actuelle. Pour éviter cela, nous pouvons l'exécuter sur une interface virtuelle avec la syntaxe suivante :
dhclient <interface_name>:<virtual_interface_name>
Après avoir exécuté cette commande, nous constatons que notre adresse IP d'origine (172.25.14.55) reste inchangée, tandis que notre interface virtuelle a reçu une nouvelle adresse IP du serveur DHCP (Figure 1).
Figure 1 : Utilisation de dhclient sur une interface virtuelle et conservation de notre IP d'origine
Si nous enregistrons le trafic et inspectons les messages d'offre DHCP, nous serons en mesure d'identifier tous les serveurs DHCP actifs (Figure 2).
Figure 2 : Envoi d'un message DHCP Discover pour identifier les serveurs DHCP actifs sur le réseau
Obtention du domaine et du serveur DNS d'un serveur DHCP
Après avoir identifié les serveurs DHCP dans le réseau, nous devons savoir quels enregistrements peuvent être usurpés via chaque serveur. Un serveur DHCP ne peut créer des enregistrements qu'à l'intérieur de sa zone ADI associée ; un serveur associé au domaine « aka.test » ne pourra écrire que des enregistrements DNS avec le même suffixe : <hostname>.aka.test. Pour comprendre quels d'enregistrement peuvent être usurpés, nous devrons identifier ce suffixe.
De plus, nous devrons identifier le serveur DNS qui hébergera les nouveaux enregistrements, afin de pouvoir les interroger et vérifier le succès de l'attaque.
Pour trouver ces deux paramètres, les hackers peuvent utiliser l'option Liste de requêtes de paramètres, astuce qui permet d'interroger le serveur DHCP sur des paramètres spécifiques. Dans notre cas, nous pouvons interroger les options Nom de domaine et Serveur de nom de domaine.
Nous pouvons à nouveau utiliser la commande dhclient. Pour ajouter l'option Liste de requêtes de paramètres à notre message Discover, nous incluons la ligne suivante dans le fichier de configuration de dhclient :
request domain-name, domain-name-servers;
Quand nous exécutons la commande dhclient (comme précédemment, sur une interface virtuelle) et inspectons notre message Discover, nous constatons qu'il inclut l'option Liste de requêtes de paramètres avec les champs que nous avons demandés (Figure 3).
Figure 3 : Liste de requêtes de paramètres dans un message DHCP Discover
Un serveur DHCP Microsoft en écoute doit envoyer une réponse d'offre à ce message Discover avec les paramètres demandés (Figure 4).
Figure 4 : Réponse du serveur DHCP avec les paramètres demandés
Détermination de l'état de la Protection des noms
La Protection des noms est un autre paramètre important lorsque vous tentez d'abuser des Mises à jour dynamiques DHCP DNS, car ce paramètre déterminera sicertaines attaques par écrasement sont possibles. Nous ne pouvons pas interroger directement le statut de la Protection des noms, mais il existe un moyen simple en quatre étapes pour le déterminer.
Créer un enregistrement DNS à l'aide d'une Mise à jour dynamique DHCP DNS
Vérifier qu'un enregistrement A a été créé
Interroger le serveur DNS pour obtenir un enregistrement DHCID portant le même nom
Si un enregistrement DHCID est présent à côté de l'enregistrement A, la protection des noms est activée
Pour appeler une Mise à jour dynamique DHCP DNS à l'aide de la commande dhclient, nous ajoutons les lignes suivantes au fichier de configuration :
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Les deux premières lignes ajoutent l'option FQDN avec l'indicateur de serveur, qui est nécessaire pour que le serveur DHCP enregistre pour nous l'enregistrement DNS. Facultative, la troisième ligne nous permet d'ajouter une option DHCP avec l'identifiant du serveur pour cibler un serveur DHCP spécifique dans les cas où plusieurs sont présents.
Après avoir exécuté la commande dhclient, nous pouvons utiliser la commande nslookup pour interroger le serveur DNS cible et rechercher un enregistrement DHCID (Figure 5).
Figure 5 : Vérification de l'état de la Protection des noms avec nslookup
Dans ce cas, nous constatons qu'un enregistrement DHCID a été créé, ce qui indique que la Protection des noms est activée.
Détermination de la configuration des Mises à jour dynamiques DHCP DNS
Trois options permettent de déterminer les cas où le serveur DHCP créera des enregistrements DNS pour les clients (Figure 6). En identifiant le paramètre utilisé, les hackers sont en mesure de détecter les requêtes DHCP et d'identifier celles qui conduisent à la création d'un enregistrement géré. De cette façon, les cibles potentielles des écrasements d'enregistrements gérés (l'usurpation d'enregistrements créés par le serveur DHCP) peuvent être identifiées.
Les trois paramètres possibles sont les suivants :
Mise à jour dynamique uniquement à la demande du client. Il s'agit de l'option par défaut, qui ne créera un enregistrement DNS que si la requête contient une option FQDN (Nom de domaine complet) et que l'indicateur de serveur est défini.
Toujours exécuter une Mise à jour dynamique. Un enregistrement DNS est créé pour toute requête DHCP avec une option FQDN, quelle que soit la valeur de l'indicateur de serveur.
Mise à jour dynamique pour les clients qui ne demandent pas de mises à jour. Un enregistrement DNS est créé pour les clients, même en l'absence de l'option FQDN : le FQDN est basé sur l'option DHCP Hostname. L'objectif est de prendre en charge les anciens clients DHCP qui n'utilisent pas l'option FQDN.
Figure 6 : Paramètres de Mise à jour dynamique DHCP DNS
Nous pouvons déterminer ce paramètre en inspectant ses « effets secondaires » : nous déclencherons une Mise à jour dynamique DHCP DNS dans les différentes conditions et interrogerons le serveur DNS pour vérifier si un enregistrement a été créé. Pour ce faire, exécutez la commande dhclient pour louer une adresse IP et la commande nslookup pour interroger le serveur DNS.
La configuration dhclient requise pour tester pour chacun des paramètres possibles est la suivante :
Création d'enregistrements pour les clients qui ne demandent pas de mises à jour
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Toujours créer des enregistrements (lorsque l'option FQDN est présente)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Création d'enregistrements uniquement à la demande du client
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Limitations concernant l'adresse des enregistrements usurpés
Pour que notre attaque soit efficace, les enregistrements DNS usurpés doivent pointer vers la machine que nous contrôlons. Avec l'usurpation DHCP DNS, nous comptons sur le serveur DHCP pour créer ces enregistrements DNS. Malheureusement, nous ne pouvons pas choisir une adresse IP arbitraire. Ayant une étendue d'adresses IP internes définie, le serveur refusera de louer une adresse IP en dehors de cette étendue, puis de créer un enregistrement DNS associé.
Pour cette raison, l'adresse vers laquelle nous redirigeons les communications est soumise à deux limitations :
L'adresse ne peut pas se trouver en dehors du réseau : nous ne pouvons pas louer une adresse IP externe auprès du serveur DHCP, et ne pouvons donc pas en utiliser une lors de l'usurpation.
L'adresse ne peut pas être celle d'une machine ayant une adresse IP statique : si l'adresse IP d'une machine est statique, il est peu probable que cette adresse se trouve dans l'espace locatif d'un serveur DHCP et elle ne peut donc pas être utilisée lors de l'usurpation.
Comme nous avons accès à une machine interne qui peut utiliser une adresse IP dynamique, nous pouvons simplement utiliser n'importe quelle adresse proposée par le serveur DHCP pour nos enregistrements usurpés.
Pour nous assurer que nous utilisons cette même adresse lors de l'exécution d'actions supplémentaires, nous pouvons utiliser l'option Adresse IP requise . Pour ce faire, nous pouvons ajouter la ligne suivante à la configuration de la commande dhclient :
send dhcp-requested-address 172.25.14.55;
Écriture de plusieurs enregistrements DNS
Lors d'une usurpation DHCP DNS, nous souhaiterons probablement usurper plusieurs enregistrements DNS plutôt qu'un seul, dans le but de rediriger le trafic du plus grand nombre de victimes possible. Cependant, lorsque nous tentons de pointer plusieurs enregistrements DNS vers la même adresse IP de destination, nous rencontrons un problème.
Une fois qu'un serveur DHCP loue une certaine adresse IP à un hôte, elle ne peut pas être louée par d'autres clients. Ce comportement vise à éviter les conflits IP entre différents clients. Lorsque nous louons une adresse IP avec un certain nom de domaine complet pour effectuer un DDSpoof, cette adresse IP est supprimée de l'espace d'adressage du serveur. Si nous voulons louer à nouveau la même adresse IP avec un nom de domaine complet différent, le serveur propose une adresse différente (Figure 7).
Figure 7 : Processus de location DHCP lorsque l'adresse demandée est déjà utilisée
La libération de la location précédente ne suffit pas à résoudre ce problème car cela déclencherait une mise à jour dynamique DNS par le serveur DHCP pour supprimer l'enregistrement qui vient d'être publié, et supprimerait notre enregistrement précédemment usurpé (Figure 8).
Figure 8 : Le message de libération DHCP appelle la suppression de l'enregistrement DNS associé
En d'autres termes, nos objectifs sont les suivants :
Libérer l'adresse IP en supprimant son entrée de location du serveur DHCP et la renvoyer dans l'espace d'adressage (afin de pouvoir l'utiliser pour enregistrer un nouvel enregistrement DNS)
Empêcher la suppression de l'enregistrement DNS usurpé existant
Nous avons trouvé un comportement/bug intéressant qui nous permet de faire exactement cela.
Nous envoyons un paquet DHCP Request au serveur DHCP qui loue actuellement notre adresse IP, avec les paramètres suivants :
L'adresse MAC du client utilisée pour demander la location DHCP existante au serveur
L'identifiant de serveur d'un serveur différent de notre serveur ciblé
En voyant ce message de diffusion, notre serveur DHCP ciblé va « supposer » que nous demandons une nouvelle adresse IP à un autre serveur, et donc que nous n'avons plus besoin de l'adresse existante (louée). Il supprimera alors la location de l'IP sans supprimer l'enregistrement DNS associé (Figure 9). La raison de l'absence de suppression de l'enregistrement DNS n'est pas claire pour nous ; nous soupçonnons qu'il pourrait s'agir d'un bug logique.
Figure 9 : Suppression d'une entrée de location sans suppression de son enregistrement DNS associé
Voyons cela en pratique
Nous voulons créer deux enregistrements DNS qui pointent vers la même adresse IP. Nous créons le premier enregistrement à l'aide de la commande dhclient de la manière décrite précédemment. Une fois créé, notre enregistrement apparaît dans le tableau de location du serveur DHCP (Figure 10).
Figure 10 : Entrée de tableau de location DHCP
Ensuite, nous définissons l'option dhcp-server-identifier dhclient dans le fichier de configuration sur une autre adresse IP, nous exécutons la commande dhclient à nouveau et constatons que notre location a été supprimée !
Il nous suffit alors d'exécuter à nouveau la commande dhclient avec un nom de domaine complet différent, tout en demandant la même adresse IP et en créant un deuxième enregistrement (Figure 11).
Figure 11 : Plusieurs enregistrements DNS du hacker pointent vers la même adresse IP
Présentation de DDSpoof.py
Nous avons regroupé toutes les capacités et techniques que nous avons décrites dans cette série de blogs afin de concevoir DDSpoof, une boîte à outils assurant la performance des attaques DHCP DNS. Cet outil écrit en Python permet d'énumérer les serveurs DHCP, d'exécuter les commandes DHCP DNS personnalisées et d'identifier les cibles potentielles d'usurpation. La fonctionnalité de DDSpoof est documentée dans ce référentiel.
Dans les sections suivantes, nous allons examiner plusieurs scénarios d'attaque possibles avec DDSpoof.
Configuration de DDSpoof
Nous exécutons une machine Kali Linux au sein de notre réseau cible, sans aucune information d'identification de domaine. Nous allons d'abord exécuter DDSpoof pour analyser le réseau et identifier les cibles potentielles (en spécifiant l'interface à utiliser pour envoyer et recevoir des paquets ; Figure 12).
Figure 12 : Énumération initiale de DDSpoof
Nous constatons que DDSpoof effectue les opérations suivantes :
Il identifie tous les serveurs DHCP accessibles, ainsi que leurs configurations
Il détermine l'état de la Protection des noms
Il vérifie que notre adresse IP actuelle est disponible à la location sur notre serveur cible
Dans cet exemple, notre adresse IP n'est pas disponible à la location sur notre serveur cible. Par conséquent, nous devons la remplacer manuellement par celle proposée par le serveur (Figure 13).
Figure 13 : Modification de notre adresse IP en une adresse disponible sur le serveur DHCP
Nous sommes prêts à lancer l'action d'usurpation.
Usurpation DHCP DNS
Pour effectuer notre première usurpation DHCP DNS, nous allons identifier les tentatives de résolution de noms échouées et créer des enregistrements DNS pour celles-ci qui pointent vers notre machine. Pour y parvenir, nous allons exécuter la commande DDSpoof start-llmnr. Cette commande démarre un analyseur LLMNR qui détecte les requêtes LLMNR dans le réseau pouvant nous conduire vers des cibles potentielles d'usurpation (Figure 14).
Figure 14 : Utilisation de l'analyseur LLMNR de DDSpoof pour identifier les cibles d'usurpation
Nous constatons ci-dessous que l'analyseur a identifié le nom files.aka.test. Maintenant, nous pouvons exécuter la commande write-record pour tenter d'enregistrer ce nom DNS (Figure 15).
Figure 15 : Utilisation de DDSpoof pour usurper un enregistrement DNS pour le nom cible
Comme nous pouvons le voir, DDSpoof crée correctement cet enregistrement DNS, pointant vers notre adresse IP ! Nous pouvons le vérifier avec la commande nslookup (Figure 16).
Figure 16 : Utilisation de la commande nslookup pour confirmer que l'enregistrement a bien été créé
La prochaine fois qu'un hôte du réseau tente de résoudre le nom files.aka.test, il sera dirigé vers la machine que nous contrôlons.
Une fois notre attaque terminée, nous pouvons utiliser la commande delete-record pour supprimer notre enregistrement usurpé (Figure 17).
Figure 17 : Utilisation de DDSpoof pour supprimer notre enregistrement usurpé
Écrasement DHCP DNS
Nous disposons également d'une autre option, l'écrasement DHCP DNS. Si nous revenons à la Figure 12, nous constatons que notre serveur DHCP cible est également un serveur DNS. Cela signifie que le serveur peut être également un contrôleur de domaine (DC), car le serveur DNS est souvent installé sur un DC dans les environnements Active Directory. Nous pouvons vérifier cela en utilisant la commande nmap suivante :
Nmap -p389 -sV 172.25.14.123
Figure 18 : Sortie nmap confirmant que le serveur est un contrôleur de domaine
Si aucune information d'identification DNS n'a été configurée, nous pouvons écraser n'importe quel enregistrement dans la zone ADI. Disons que nous avons identifié un hôte nommé file-server.aka.test (Figure 19).
Figure 19 : Résultats de la commande nslookup pour file-server.aka.test
Nous pouvons tenter d'écraser son enregistrement DNS à l'aide de la commande write-record DDSpoof. Si la configuration des informations d'identification DNS est faible, cela devrait échouer. Mais dans notre cas, les informations d'identification DNS configurées ne sont pas faibles, et notre écrasement a donc réussi (Figure 20).
Figure 20 : Utilisation de DDSpoof pour effectuer un écrasement DHCP DNS de l'enregistrement DNS du serveur de fichiers
Fig. 21 : Utilisation de la commande nslookup pour confirmer que l'écrasement a été correctement effectué
Contournement de la fonctionnalité Protection des noms
Dans un autre scénario, nous exécutons la commande start-dhcp DDSpoof qui détecte le trafic DHCP et identifie les messages de requête DHCP (Figure 22).
Fig. 22 : Utilisation de l'analyseur DHCP de DDSpoof pour identifier les enregistrements gérés potentiels
Dans cet exemple, nous identifions une machine nommée ubuntu-server.aka.test qui a envoyé une requête DHCP contenant son nom de domaine complet. Le serveur DHCP pourrait alors être amené à créer un enregistrement DNS pour lui, ce qui permettrait d'effectuer un écrasement d'enregistrements gérés (rappelez-vous qu'un enregistrement géré est créé pour les hôtes autres que Windows, car ces derniers ne font pas partie du domaine et ne peuvent donc pas communiquer directement avec le serveur DNS).
Mais un problème se pose. Cette fois, notre serveur DHCP cible a activé la Protection des noms (Figure 23).
Fig. 23 : DDSpoof énumérant un serveur DHCP avec la Protection des noms activée
Si nous interrogeons tous les enregistrements DNS pour notre ubuntu-server.aka.testcible, nous constatons effectivement la présence d'un enregistrement DHCID (Figure 24).
Figure 24 : Sortie nslookup contenant un enregistrement DHCID
Mais pas d'inquiétude. Comme nous le savons déjà, la Protection des noms peut être facilement contournée !
Pour y parvenir, nous devons simplement envoyer un message de libération DHCP avec un ID client (CID), principalement l'adresse MAC du client, qui correspond au propriétaire de l'enregistrement d'origine. Le serveur DHCP supprimera alors l'enregistrement.
Pour ce faire, nous pouvons utiliser la commande set-cid . Nous lui fournissons le CID cible que nous avons précédemment obtenu, ce qui permet à DDSpoof d'usurper l'identité du client DHCP d'origine. Ensuite, nous pouvons exécuter la commande delete-record pour supprimer notre enregistrement cible (Figure 25).
Figure 25 : Utilisation de DDSpoof pour supprimer un enregistrement DNS protégé par la Protection des noms
Il nous suffit maintenant d'enregistrer le nom pour nous-mêmes en utilisant la commande write-record (Figure 26).
Figure 26 : Utilisation de DDSpoof pour créer un nouvel enregistrement après avoir supprimé l'original, en contournant la fonctionnalité de Protection des noms
Résumé
Dans les scénarios d'attaque étudiés dans cet article, nous démontrons comment il est possible d'usurper divers enregistrements DNS dans des domaines Active Directory à partir d'un contexte non authentifié. Très flexible, cette capacité peut être utilisée par des hackers de diverses manières, notamment pour :
Cibler les machines Windows et intercepter l'authentification NTLM ou Kerberos, permettant d'autres attaques par relais ou par force brute
Cibler les applications qui exécutent des protocoles non sécurisés et intercepter les données sensibles
Cibler les enregistrements DNS des serveurs de sécurité internes, tels que les antivirus ou les SIEM, et bloquer leur accès
Il ne s'agit là que de quelques exemples de l'utilisation abusive de cette capacité par les acteurs malveillants ; il y en a beaucoup d'autres.
À l'attention des équipes de sécurité
La surface d'attaque exposée par les Mises à jour dynamiques DHCP DNS est très puissante, et puisque Microsoft ne prévoit pas d'y remédier, elle est probablement là pour durer. Nous encourageons les équipes de sécurité à utiliser les outils suivants pour identifier et atténuer les risques d'usurpation DHCP DNS, idéalement avant que les hackers se mettent à la page :
Invoke-DHCPCheckup : pour identifier les configurations DHCP et DNS dans Active Directory
DDSpoof : pour mettre en évidence les risques et tester votre résilience à la surface d'attaque des Mises à jour dynamiques DHCP DNS
