Usurpation d'enregistrements DNS par l'utilisation abusive des mises à jour dynamiques DHCP DNS
Synthèse
Les chercheurs d'Akamai ont découvert de nouvelles attaques contre les domaines Active Directory qui utilisent des serveurs DHCP (Dynamic Host Configuration Protocol) de Microsoft.
Ces attaques pourraient permettre aux hackers d'usurper des enregistrements DNS sensibles, engendrant alors diverses conséquences allant du vol d'informations d'identification à la compromission totale d'un domaine Active Directory. Les attaques ne nécessitent pas d'informations d'identification et fonctionnent avec la configuration par défaut des serveurs DHCP de Microsoft.
De nombreuses entreprises pourraient être touchées. Les serveurs DHCP de Microsoft sont très populaires. Nous avons observé que 40 % des réseaux surveillés par Akamai en utilisent.
Nous avons fait part de nos constations à Microsoft, mais aucun correctif n'est prévu.
Dans cet article de blog, nous détaillons les meilleures pratiques de configuration des serveurs DHCP de Microsoft pour atténuer ces attaques et présentons un outil conçu pour permettre aux administrateurs système et aux équipes bleues de détecter les configurations risquées.
Dans un prochain article de blog, nous partagerons des détails techniques sur la mise en œuvre de ces attaques du point de vue d'un hacker.
Introduction
La possibilité d'usurper des enregistrements DNS est très intéressante pour les hackers, car cela peut avoir des conséquences dévastatrices : exposition de données sensibles, compromission d'informations d'identification, exécution de code à distance, par exemple.
Dans cet article de blog, nous examinons une surface d'attaque du DNS qui a rarement été étudiée et qui est exposée par une fonctionnalité DHCP en apparence inoffensive. En l'utilisant, nous avons constaté que les hackers pouvaient usurper des enregistrements DNS sur des serveurs DNS de Microsoft de différentes manières, notamment en écrasant un enregistrement DNS arbitraire non authentifié.
Parallèlement aux flux d'attaque, nous décrivons également en détail le fonctionnement interne d'un serveur DHCP de Microsoft, son interaction avec le DNS et Active Directory, et comment sécuriser correctement ces interfaces. Bien qu'il existe en ligne de nombreuses ressources dispersées (et inexactes !) sur le protocole DHCP, nous pensons que cet article de blog est une ressource précise et complète sur le sujet. Les défenseurs y retrouveront toutes les informations essentielles dont ils ont besoin en un seul et même endroit.
DNS et Active Directory
Commençons avec Active Directory (AD). Le fonctionnement d'AD repose fortement sur le DNS. Chaque domaine nécessite un serveur DNS qui héberge une zone DNS spéciale appelée « zone DNS intégrée à Active Directory » (ADIDNS) (Figure 1). Cette zone permet d'héberger des enregistrements DNS pour tous les ordinateurs associés aux domaines et les différents services d'AD.
Figure 1 : zone ADIDNS par défaut
Les enregistrements figurant dans les zones ADI sont gérés à l'aide d'une fonctionnalité DNS appelée « Mises à jour dynamiques ». Cette fonctionnalité permet à chaque client d'être responsable de son propre enregistrement. Lorsqu'il doit créer ou modifier son enregistrement DNS, il envoie une requête DNS spéciale qui inclut les données à modifier sur le serveur (Figure 2). Lorsque le serveur DNS reçoit cette requête, il modifie les enregistrements du client en conséquence.
Figure 2 : exemple de contenu d'une mise à jour DNS
L'une des fonctionnalités importantes des mises à jour dynamiques DNS est « Mises à jour sécurisées ».Celle-ci est conçue pour contrôler qui peut modifier chaque enregistrement DNS de la zone. Sans mise à jour sécurisée, le serveur DNS obéit aveuglément à toute demande de mise à jour, ce qui permet aux hackers d'écraser facilement les enregistrements existants. Avec cette fonctionnalité, seules les mises à jour sécurisées sont acceptées par défaut par le serveur DNS pour les zones ADI (Figure 3).
Figure 3 : paramètres par défaut des mises à jour dynamiques DNS
Lors de l'utilisation de la fonctionnalité Mises à jour sécurisées, toutes les demandes de mise à jour reçues par le serveur sont authentifiées et autorisées. Dans les zones ADI, Kerberos est alors utilisé. Lorsqu'une mise à jour est envoyée au serveur, elle inclut un ticket Kerberos qui permet d'authentifier l'utilisateur (Figure 4). Pour plus d'informations sur le processus d'authentification Kerberos sur le DNS, reportez-vous aux recherches de Dirk-Jan Mollema en la matière.
Figure 4 : ticket Kerberos dans une mise à jour DNS
Chaque enregistrement DNS est protégé par une liste de contrôle d'accès (ACL) qui détermine les droits d'accès pour chaque entité principale. Ces droits d'accès sont déterminés lors de la création initiale de l'enregistrement : lorsqu'un client crée un enregistrement DNS en envoyant une mise à jour dynamique DNS, le compte de l'ordinateur qui a créé l'enregistrement DNS est automatiquement désigné comme propriétaire de l'enregistrement et reçoit les autorisations correspondantes. Normalement, chaque client DNS utilise le ticket de son propre compte d'ordinateur pour effectuer les mises à jour DNS. Pour autoriser une demande de mise à jour, le serveur DNS vérifie l'ACL de l'enregistrement par rapport à l'entité principale authentifiée.
Dans la Figure 5, nous pouvons voir l'ACL pour l'enregistrement DNS de l'hôte « PC.aka.test ». Cet enregistrement a été créé par le compte d'ordinateur, il dispose donc des autorisations nécessaires pour le modifier.
Figure 5 : ACL de l'enregistrement DNS par défaut
Les autres entités principales (à l'exception de certains groupes forts intégrés) ne devraient pas disposer d'autorisations pour l'enregistrement. Lorsqu'une entité principale différente tente de modifier un enregistrement DNS dont elle n'est pas propriétaire ou pour lequel elle ne possède pas d'autorisations, le serveur refuse la mise à jour.
Les zones ADIDNS peuvent s'avérer très intéressantes pour les hackers. Des recherches antérieures de Kevin Robertson de NETSPI ont mis en lumière des attaques intéressantes sur ces zones DNS. Nous voulions nous attarder sur cette surface d'attaque. Nous avons donc commencé à examiner de manière plus approfondie d'autres fonctionnalités connexes, ce qui nous a conduit à la fonctionnalité particulièrement intéressante suivante : Mises à jour dynamiques DHCP DNS.
Mises à jour dynamiques DHCP DNS
DHCP est un protocole de gestion de réseau qui permet d'attribuer automatiquement des adresses IP et autres options réseau aux clients. Lorsqu'un client rejoint un nouveau réseau, il tente d'atteindre un serveur DHCP en envoyant un message de diffusion dans lequel il demande des configurations réseau. Lorsqu'un serveur DHCP reçoit cette requête, il répond au client en lui attribuant une adresse IP.
Très courant, le protocole DHCP est utilisé dans la plupart des réseaux d'entreprise. Les serveurs DHCP de Microsoft, en particulier, sont très populaires. Nous avons observé que 40 % des réseaux de centres de données que nous surveillons utilisent un serveur DHCP de Microsoft.
Bien que les clients Windows récents (Windows 2000 et versions ultérieures) créent normalement leurs propres enregistrements en envoyant des mises à jour dynamiques DNS, ce n'est pas toujours le cas. Il est également possible de créer des enregistrements DNS à l'aide d'une fonctionnalité DHCP appelée « Mises à jour dynamiques DHCP DNS ». Le but de cette fonctionnalité est de permettre à un serveur DHCP d'enregistrer des enregistrements DNS pour le compte de ses clients. Chaque fois qu'un client reçoit une adresse IP du serveur DHCP, ce dernier peut contacter le serveur DNS et mettre à jour l'enregistrement DNS du client. Pour effectuer ces mises à jour, le serveur DHCP utilise (surprise, surprise !) la fonctionnalité Mises à jour dynamiques DNS.
La similitude des noms pouvant porter à confusion, clarifions les choses :
Fonctionnalité |
Protocole |
Objectif |
|---|---|---|
Mises à jour dynamiques DNS |
DNS |
Permettre aux clients DNS de créer ou modifier des enregistrements DNS sur le serveur DNS |
Mises à jour dynamiques DHCP DNS |
DHCP |
Permettre au serveur DHCP de créer ou modifier des enregistrements DNS pour le compte de ses clients, les mises à jour étant effectuées à l'aide de la fonctionnalité Mises à jour dynamiques DNS |
Le processus de mise à jour dynamique DHCP DNS est illustré dans la Figure 6.
Figure 6 : processus de mise à jour dynamique DHCP DNS
Le client DHCP reçoit une adresse IP du serveur DHCP et l'informe de son nom de domaine complet.
Le serveur DHCP envoie une demande de mise à jour dynamique au serveur DNS.
Le serveur DNS valide la demande, crée un enregistrement pertinent et informe le serveur DHCP du résultat dans une réponse de mise à jour dynamique.
Notez que même lorsque la fonctionnalité Mises à jour dynamiques DHCP DNS est activée, la configuration par défaut exige que le client spécifie explicitement qu'un enregistrement DNS doit être créé en son nom (Figure 7).
Figure 7 : configuration par défaut des mises à jour dynamiques DHCP DNS
Pour cela, le client doit envoyer une option DHCP dédiée. Les options DHCP (Figure 8) sont des champs supplémentaires qu'il est possible d'ajouter à un paquet DHCP et que le client et le serveur utilisent pour échanger des informations.
Figure 8 : exemple d'options DHCP
Pour notre cause, le client envoie l'option FQDN, spécifiée dans RFC 4702. Cette option permet au client DHCP d'informer le serveur de son nom de domaine complet (FQDN) et de spécifier s'il doit enregistrer un enregistrement DNS au nom du client. Pour ce faire, le client peut utiliser l'indicateur de serveur, qui fait partie de l'option FQDN. Le fait de définir ce paramètre sur 1 indique au serveur qu'il doit créer un enregistrement basé sur le nom de domaine complet (FQDN) fourni (Figure 9).
Figure 9 : requête DHCP avec l'option FQDN
Après réception de cette requête, le serveur DHCP envoie une mise à jour dynamique DNS et crée l'enregistrement demandé (Figure 10).
Figure 10 : zone ADIDNS avec notre nouvel enregistrement
Cette fonctionnalité est utile mais n'est pas couramment utilisée de nos jours (comme indiqué, la plupart des clients Windows récents créent simplement leurs propres enregistrements). Malgré cela, cette fonctionnalité est activée par défaut sur les serveurs DHCP de Microsoft, ce qui signifie que le serveur DHCP enregistrera un enregistrement DNS pour tout client qui le demande.
Notez que les mises à jour dynamiques DHCP DNS ne nécessitent aucune authentification par le client DHCP. N'importe qui sur le réseau peut louer une adresse IP d'un serveur DHCP. Ainsi, un hacker peut essentiellement utiliser le serveur DHCP pour s'authentifier auprès du serveur DNS en son nom propre. Cela permet au hacker d'accéder à la zone ADIDNS sans aucune information d'identification.
Microsoft semble au courant des risques potentiels que cette fonctionnalité pose et en reconnaît certains, mais cette surface d'attaque est encore largement inconnue des hackers et des défenseurs
Les sections suivantes détaillent les attaques susceptibles de survenir en abusant des mises à jour dynamiques DHCP DNS.
Usurpation DHCP DNS
Les attaques d'usurpation ADIDNS décrites précédemment exploitaient la zone ADIDNS pour améliorer l'attaque classique d'usurpation LLMNR/NBNS . Après avoir identifié les tentatives infructueuses de résolution de nom (« hôtes morts »), un hacker pourrait enregistrer le nom dans la zone ADI, redirigeant alors les futures tentatives de résolution de nom vers l'ordinateur du hacker.
Cette attaque pourrait avoir un impact considérable, mais requiert une condition préalable majeure : des informations d'identification de domaine valides. En utilisant le serveur DHCP, nous pouvons contourner cette exigence et poursuivre sans information d'identification. Nous pouvons simplement envoyer une mise à jour dynamique DHCP DNS pour tout nom de domaine complet qui n'existe pas dans la zone ADI, et le serveur DHCP le créera pour nous. Nous appelons cette variation de l'attaque « Usurpation DHCP DNS ». Cette technique était également abordée dans un article de blog rédigé par Hans Lakhan de TrustedSec.
Quels noms DNS pourrions-nous utiliser pour cette attaque ? Toujours selon les recherches de Robertson, certains candidats évidents ne fonctionneraient pas.
Le célèbre nom d'hôte WPAD serait bloqué par la liste de blocage des requêtes globales (GQBL) sur le serveur DNS.
L'enregistrement générique (« * ») ne peut pas être créé via des mises à jour DNS dynamiques, il ne peut donc pas être utilisé de manière abusive dans ce scénario.
Sans ces deux candidats, il nous reste plus qu'à identifier les hôtes morts spécifiques au réseau. Nous pouvons les identifier en détectant sur le réseau tout message de diffusion de résolution de noms via le protocole LLMNR (Link-Local Multicast Name Resolution) ou NBT-NS (NetBIOS Name Service). Après avoir identifié un hôte mort potentiel, nous pouvons créer un enregistrement DNS correspondant en envoyant une mise à jour dynamique DHCP DNS (Figure 11).
Figure 11 : utilisation d'une mise à jour dynamique DHCP DNS pour usurper des noms d'hôte morts
Un hôte du réseau tente de résoudre le nom « PC.aka.test » et envoie une requête au serveur DNS.
Le nom « PC.aka.test » est inconnu du serveur DNS, ce dernier renvoie donc la réponse « No such name » (Aucun nom de ce type).
L'hôte envoie ensuite une requête de multidiffusion LLMNR pour essayer de localiser le nom « PC.aka.test » dans son réseau LAN.
Le hacker identifie cette tentative et demande un bail IP au serveur DHCP, en spécifiant « PC.aka.test » comme nom de domaine complet.
Le serveur envoie une demande de mise à jour dynamique au serveur DNS et l'enregistrement est créé.
Ainsi, la prochaine fois qu'un hôte du réseau essaiera de résoudre le nom « PC.aka.test », il sera redirigé vers le hacker. Il ne reste au hacker qu'à exécuter ntlmrelayx.py et à attendre les tentatives d'authentification.
Cette approche est meilleure que la méthode d'usurpation LLMNR/NBNS standard et la variation d'usurpation ADIDNS.
L'usurpation classique LLMNR/NBNS ne nécessite aucune authentification, mais se limite aux victimes du réseau LAN (car les protocoles LLMNR/NBNS sont basés sur la diffusion).
L'usurpation ADIDNS nous a permis de cibler des victimes en dehors du réseau LAN (car le protocole DNS fonctionne d'un sous-réseau à un autre), mais a exigé un utilisateur authentifié.
Avec les mises à jour dynamiques DHCP DNS, nous bénéficions des avantages des deux méthodes : l'attaque fonctionne sur des victimes en dehors du réseau LAN et ne nécessite aucune authentification.
C'est assez cool, mais nous pouvons faire encore mieux.
Écrasement d'enregistrements existants
Créer des enregistrements DNS non existants est cool, mais cela nous a fait réfléchir à une autre option : que se passe-t-il si nous essayons de créer un enregistrement pour un nom d'hôte qui existe déjà ? Pourrions-nous l'écraser d'une manière ou d'une autre ? Idéalement, cela devrait être impossible, non ? Eh bien…
Nous avons identifié des cas où il pourrait être possible pour des hackers non authentifiés d'écraser des enregistrements existants. Nous appelons cette technique « Écrasement DHCP DNS ». Avant d'aborder ces cas, discutons de quelques détails supplémentaires concernant le processus de mises à jour dynamiques DHCP.
Types d'enregistrements DNS et leurs propriétaires
Dans le contexte d'attaques DHCP DNS, il est important de distinguer deux types d'enregistrements DNS (Figure 12). Nous utiliserons désormais les termes suivants :
Enregistrements clients : enregistrements créés directement par les clients Windows
Enregistrements gérés : enregistrements créés par le serveur DHCP pour le compte des clients
Figure 12 : types d'enregistrements DNS
La différence cruciale entre ces clients est leur propriétaire. Comme nous l'avons décrit précédemment dans cet article, lorsqu'une mise à jour DNS est effectuée, un enregistrement client est créé et l'entité principale qui a envoyé la demande de mise à jour est désignée comme propriétaire de l'enregistrement. Pour les clients Windows normaux, cette entité principale est le compte d'ordinateur du client.
On pourrait s'attendre à ce que les enregistrements gérés appartiennent également au client à l'origine de la demande, mais ce n'est pas le cas. Lorsque le serveur DHCP envoie des mises à jour DNS pour le compte de clients, il s'authentifie également à l'aide de son propre compte d'ordinateur, qui devient alors le propriétaire de l'enregistrement.
Nous pouvons voir cette différence dans la Figure 12. PC2 est un enregistrement client appartenant au client et PC1 est un enregistrement géré appartenant au serveur DHCP.
Les listes de contrôle d'accès limitent les écrasements DHCP DNS
Lorsque nous essayons d'effectuer une mise à jour dynamique DHCP DNS sur un enregistrement existant (dans ce cas, l'enregistrement « PC.aka.test »), nous échouons. On observe un comportement intéressant : le serveur DHCP envoie effectivement une mise à jour DNS avec le nom de domaine complet fourni, mais la mise à jour est ensuite refusée par le serveur (Figure 13).
Figure 13 : mise à jour DHCP DNS refusée par le serveur
Cela se produit car le serveur DHCP n'est pas autorisé à modifier l'enregistrement.
PC.aka.test est un enregistrement client appartenant à l'entité principale PC$ . Lorsque le serveur DHCP envoie la mise à jour DNS, il s'authentifie à l'aide de son propre compte d'ordinateur : DHCP$. Étant donné que ce compte ne dispose pas des autorisations nécessaires pour l'enregistrement, la mise à jour est refusée (Figure 14).
Figure 14 : échec de l'écrasement de l'enregistrement DNS
Pour résumer : il est possible pour les hackers d'utiliser le serveur DHCP pour envoyer des mises à jour DNS arbitraires, mais les enregistrements DNS devraient être protégés contre les écrasements en raison de leurs listes de contrôle d'accès.
Maintenant que nous comprenons le mécanisme qui est censé empêcher les écrasements, voyons comment il serait tout de même possible de le contourner.
Écrasement d'enregistrements gérés
Bien que les écrasements d'enregistrements clients existants ne fonctionnent pas en raison de leurs listes de contrôle d'accès restrictives, les écrasements d'enregistrements gérés (créés par le serveur DHCP) fonctionnentcar la machine d'authentification est également le propriétaire des enregistrements (Figure 15).
Ceci est possible car un serveur DHCP ne vérifie pas qui est le propriétaire des enregistrements DNS et envoie une mise à jour DNS pour tout nom de domaine complet demandé.
Figure 15 : écrasement DHCP DNS d'enregistrements appartenant au serveur DHCP
Comme nous pouvons le voir, le serveur DHCP effectue une mise à jour en utilisant le même compte à qui appartient l'enregistrement (le sien). Ainsi, la mise à jour s'effectue.
Prenons un exemple : nous démarrons un serveur Ubuntu, qui ne fait pas partie du domaine et ne peut donc pas enregistrer son propre enregistrement DNS. Il demande alors au serveur DHCP de le faire en son nom (Figure 16).
Figure 16 : le serveur DHCP enregistre un enregistrement DNS au nom du serveur Ubuntu
Cet enregistrement appartient au compte d'ordinateur du serveur DHCP. Maintenant, à partir de notre ordinateur à l'origine de l'attaque, nous demandons le même nom de domaine complet au serveur DHCP dans le processus de bail. Nous vérifions la zone DNS et voyons que notre écrasement a réussi et que l'enregistrement pointe maintenant vers l'adresse IP qui vient de nous être louée (Figure 17).
Figure 17 : enregistrement DNS du serveur Ubuntu écrasé
Cette attaque est acceptable, mais son impact est assez limité car elle n'affecte que les enregistrements gérés. Comme nous l'avons mentionné précédemment, ces enregistrements sont beaucoup moins courants que les enregistrements clients, qui ne sont pas affectés par cette attaque. Malgré cela, il est toujours possible de trouver des enregistrements gérés dans certains cas où le client est incapable d'enregistrer son propre enregistrement, notamment les suivants :
Clients autres que Windows
Anciens clients Windows
Clients Windows pour lesquels les mises à jour DNS client sont désactivées
Auto-écrasement DHCP
Pour augmenter tout impact potentiel, nous voulons être en mesure d'écraser des enregistrements présents dans n'importe quelle zone ADI, à savoir des enregistrements clients. Le problème est que ces enregistrements appartiennent aux ordinateurs qui les ont créés, et nous ne pouvons nous authentifier qu'en utilisant le compte d'ordinateur du serveur DHCP.
Mais qu'en est-il de l'enregistrement DNS du serveur DHCP ? Lorsque le serveur DHCP crée son propre enregistrement DNS, son compte d'ordinateur devient le propriétaire de l'enregistrement ! Il s'avère que nous pouvons faire en sorte que le serveur DHCP effectue un écrasement DHCP DNS sur lui-même. Si nous indiquons le nom du serveur DHCP comme nom de domaine complet, le serveur DHCP enverra une mise à jour DNS pour son propre enregistrement client. Dans ce cas, cet écrasement s'effectuera !
La Figure 18 illustre ce flux d'attaque.
Figure 18 : écrasement DHCP DNS de l'enregistrement DNS du serveur DHCP
Cette attaque est plus fiable : si un serveur DHCP de Microsoft est présent sur le réseau, un enregistrement client correspondant est garanti, tandis que les enregistrements gérés (qui sont nécessaires pour le scénario d'écrasement précédent) sont plus rares.
Quant à son impact, les hackers seraient en mesure d'intercepter toute communication destinée au serveur DHCP. La gravité de l'attaque dépendrait de la nature de ce trafic. Dans la plupart des cas, la capacité à intercepter les communications destinées au serveur DHCP pourrait être utilisée de manière abusive pour intercepter des informations d'identification et les relayer, ou capter du trafic sensible d'autres services qui pourraient être installés sur le serveur.
En parlant de services sensibles : que faire si le serveur DHCP est installé sur un contrôleur de domaine (DC) ? Pouvons-nous écraser l'enregistrement DC ? Il s'avère que oui.
Écrasement arbitraire DHCP DC
Si le serveur DHCP est installé sur un DC, nous pouvons effectuer un écrasement DHCP DNS sur le propre enregistrement du DC (pour les raisons que nous avons décrites précédemment dans cet article). Cela peut être très utile, mais nous pouvons faire plus.
Comme nous le savons déjà, si le serveur DHCP est installé sur un DC, le compte d'ordinateur du DC sera utilisé lors de l'envoi des mises à jour DNS. Fait intéressant, si nous inspectons la liste de contrôle d'accès par défaut d'un enregistrement DNS arbitraire, nous verrons que l'entité principale CONTRÔLEURS DE DOMAINE D'ENTREPRISE dispose d'une autorisation d'écriture pour chaque enregistrement DNS de la zone, peu importe qui l'a créé (Figure 19).
Figure 19 : ACL par défaut de tous les enregistrements de domaine contenant le groupe CONTRÔLEURS DE DOMAINE D'ENTREPRISE
C'est incroyable. Si le serveur DHCP est un DC, il dispose d'autorisations pour tous les enregistrements de la zone. Les hackers pourraient l'utiliser pour écraser n'importe quel enregistrement DNS A de la zone ADI et ce, en tant qu'utilisateur non authentifié ! L'attaque est illustrée dans la Figure 20.
Figure 20 : écrasement DHCP DNS arbitraire lorsque le serveur DHCP est un DC
Nos données montrent que cette configuration risquée est assez courante. Parmi les réseaux que nous avons observés et qui utilisent un serveur DHCP de Microsoft, 57 % ont un serveur DHCP installé sur un DC. Tous ces domaines sont vulnérables par défaut.
Bien que Microsoft ait reconnu ce risque dans sa documentation, nous croyons que la prise de conscience de cette mauvaise configuration est insuffisante par rapport à son impact potentiel.
Atténuations des attaques DHCP DNS et comment les contourner
Toutes les attaques décrites jusqu'à présent fonctionnent avec la configuration par défaut des serveurs DHCP de Microsoft. Cependant, il existe deux paramètres qui pourraient aider à atténuer certaines d'entre elles. Jetons-y un coup d'œil et voyons comment il est également possible de les contourner.
Protection des noms DHCP
Comme nous le savons, lorsqu'un serveur DHCP crée un enregistrement DNS, rien n'empêche d'autres clients de demander le même nom de domaine complet et de forcer le serveur à l'écraser. Le but de la fonctionnalité Protection des noms est d'éviter que cela ne se produise.
La fonctionnalité Protection des noms est mise en œuvre à l'aide d'un type d'enregistrement DNS spécial : DHCID (identifiant client DHCP). Lorsque la fonctionnalité Protection des noms est activée, chaque fois qu'un serveur DHCP enregistre un enregistrement pour le compte d'un client, un enregistrement DHCID supplémentaire est créé (Figure 21).
Fig. 21 : enregistrement DHCID créé par un serveur DHCP et pour lequel la fonctionnalité Protection des noms est activée
Comme vous pouvez le voir, la valeur d'enregistrement DHCID est un bloc de données codées en Base64. Cette valeur (que nous analyserons ultérieurement dans cet article) est une signature unique destinée à identifier le client DHCP qui a demandé la création ou la mise à jour de l'enregistrement.
Lorsqu'un client demande au serveur DHCP de modifier un enregistrement DNS, le serveur calcule la valeur DHCID du client et envoie une mise à jour DNS qui inclut les données mises à jour et la valeur DHCID.
Si l'enregistrement n'existe pas déjà sur le serveur DNS, il crée simplement l'enregistrement et l'enregistrement DHCID correspondant. Toutefois, si les enregistrements Hôte (A) et DHCID existent, la valeur DHCID existante est comparée à celle envoyée par le serveur DHCP. La mise à jour est effectuée uniquement si les valeurs correspondent.
L'enregistrement DHCID associe alors un enregistrement DNS au client qui l'a créé. Une fois cette association créée, seul ce client d'origine pourra apporter des modifications à l'enregistrement.
Contournement de la fonctionnalité Protection des noms
Nous avons trouvé un moyen de contourner la fonctionnalité Protection des noms en utilisant un message de libération DHCP. Il s'agit d'un message envoyé par les clients DHCP pour informer le serveur lorsqu'ils n'ont plus besoin de l'adresse IP qui leur a été louée. Pour garder une trace des adresses louées, le serveur DHCP tient à jour un tableau qui répertorie les différentes adresses, leurs dates d'expiration et l'identifiant unique du client qui les a louées (Figure 22).
Fig. 22 : entrée de tableau de location du serveur DHCP
L'identifiant unique est simplement l'adresse MAC du client. Lorsqu'il reçoit un message de libération de la part d'un client, le serveur DHCP recherche une entrée existante avec une adresse et un ID correspondants et la supprime s'il la trouve. Lorsque les mises à jour dynamiques DHCP DNS sont activées, en plus de libérer l'adresse IP, le serveur DHCP envoie également une mise à jour dynamique DNS pour supprimer l'enregistrement DNS associé du client.
Si nous pouvons envoyer un message de libération DHCP avec un ID unique (adresse MAC) qui correspond à l'ID de notre cible, le serveur DHCP supprime l'enregistrement, nous permettant ainsi de l'enregistrer pour nous-mêmes. Pour contourner la fonctionnalité Protection des noms, seule l'adresse MAC de la victime est nécessaire ! (Notez qu'il n'est pas nécessaire de changer notre adresse MAC réelle, la valeur provenant de l'en-tête DHCP.)
Si nous sommes sur le même réseau LAN que la cible, trouver son adresse MAC est assez facile. Par exemple, nous pouvons la trouver en envoyant une requête ARP. Mais que se passe-t-il si nous ne sommes pas sur le même réseau LAN ? Nous avons une autre option.
Attaquer en force les enregistrements DHCID pour contourner la fonctionnalité Protection des noms
Les enregistrements DHCID sont définis dans RFC 4701, et leur algorithme est assez simple :
Concaténez les valeurs suivantes :
DHCP HTYPE (type de matériel). Pour Ethernet, la valeur est 01.
Option ID client DHCP
Nom de domaine complet de l'enregistrement (au format filaire DNS)
SHA256 le résultat
Ajoutez les bits de données DHCID (dans le mise en œuvre Windows, cette valeur est constante)
Codez le résultat en Base64
La Figure 23 illustre un exemple de calcul d'un enregistrement DHCID.
Fig. 23 : exemple de calcul d'un enregistrement DHCID
Puisque nous savons que le nom de domaine complet et les bits de données sont des valeurs constantes, la seule variable est l'ID du client qui, encore une fois, est l'adresse MAC du client.
Les enregistrements DHCID sont des enregistrements DNS normaux. Ainsi, tout client peut demander leur valeur au serveur DNS. Étant donné que nous connaissons l'algorithme pour calculer un enregistrement DHCID, nous pouvons itérer toutes les adresses MAC possibles, calculer leur valeur DHCID et comparer chaque résultat avec notre enregistrement cible. Lorsque nous obtenons une correspondance, nous savons que nous avons trouvé la bonne adresse MAC. Cela permet aux hackers d'attaquer en force l'adresse MAC dans un délai raisonnable. Avec un ordinateur dédié récent, quelques jours suffiraient pour pirater 248 adresses MAC possibles. Nous pouvons réduire considérablement ce délai si nous n'utilisons que des identifiants de fournisseur courants. Un exemple de ce processus est illustré dans la Figure 24.
Figure 24 : suppression d'un enregistrement DNS protégé par la fonctionnalité Protection des noms
Le code référencé peut être utilisé pour calculer la valeur DHCID en fonction des paramètres spécifiés.
Atténuations des effets secondaires de la fonctionnalité Protection des noms
La fonctionnalité Protection des noms DHCP est destinée aux enregistrements gérés : essentiellement, le serveur DHCP protège les enregistrements qu'il a créés contre toute modification effectuée par des clients aléatoires. La fonctionnalité Protection des noms n'a rien à voir avec les enregistrements clients.
Malgré cela, dans certains cas, elle peut tout de même atténuer les attaques contre les enregistrements clients.
Lors de la mise à jour d'enregistrements DNS pour lesquels la fonctionnalité Protection des noms est activée, le serveur DHCP requiert la présence d'un enregistrement DHCID. Puisque les clients DNS normaux ne créent pas d'enregistrements DHCID, aucun n'est associé aux enregistrements clients. Par conséquent, toute tentative de mise à jour d'un enregistrement client à partir d'un serveur DHCP échouerait (Figure 25).
Figure 25 : échec d'une mise à jour DNS lorsqu'un enregistrement DHCID n'existe pas
Cela se produit en raison de la façon dont la fonctionnalité Protection des noms est mise en œuvre. Lorsqu'un serveur DHCP pour lequel la fonctionnalité Protection des noms est activée envoie une mise à jour DNS, il ajoute un champ Conditions préalables à la demande. Ce champ spécifie les conditions qui doivent être remplies sur le serveur DNS pour que la mise à jour DNS ait lieu. Dans la Figure 26, nous pouvons voir que la mise à jour DNS envoyée par le serveur DHCP inclut une condition préalable pour la valeur DHCID.
Figure 26 : conditions préalables à une mise à jour DNS
Cela signifie que la mise à jour échouerait si aucune valeur correspondante n'existe. Puisque les enregistrements clients ne doivent jamais avoir d'enregistrement DHCID, si la fonctionnalité Protection des noms est activée, les enregistrements clients devraient être protégés contre les écrasements DHCP DNS sans qu'il ne soit possible de la contourner. En tous cas, cela devrait être le cas.
Cela ne fait pas vraiment partie de la fonctionnalité Protection des noms. Il s'agit plutôt d'un sous-produit car, par définition, la fonctionnalité Protection des noms est destinée à protéger uniquement les enregistrements gérés. Néanmoins, en raison de la logique que nous venons de décrire, elle peut également protéger les enregistrements clients. Toutefois, même cette protection accidentelle peut être contournée.
Des étendues DHCP à la rescousse ?
Les serveurs DHCP peuvent définir plusieurs étendues. Une étendue est un ensemble défini d'adresses IP dans un sous-réseau spécifique que les serveurs DHCP peuvent louer (Figure 27).
Figure 27 : exemple d'étendues DHCP
La séparation en étendues permet non seulement de mieux gérer la distribution des adresses, mais aussi d'appliquer différentes stratégies à différents sous-réseaux. La fonctionnalité Protection des noms est l'une de ces stratégies et est activée au niveau des étendues. Des étendues différentes peuvent donc avoir des configurations différentes.
Comme nous l'avons mentionné précédemment dans cet article, lorsque nous avons essayé d'effectuer un écrasement DHCP DNS sur un enregistrement client, nous avons échoué car notre bail provenait d'une étendue DHCP pour laquelle la fonctionnalité Protection des noms était activée. Mais il est important de comprendre une chose : une étendue est un terme DHCP. Les enregistrements clients en n'ont pas connaissance et ne sont associés à aucune étendue.
Pour cette raison, si nous pouvons obtenir un bail d'une autre étendue pour laquelle la fonctionnalité Protection des noms est désactivée, nous pouvons « contourner » cette atténuation. (Cet article n'explique pas comment obtenir un bail d'une autre étendue pour laquelle la fonctionnalité Protection des noms est désactivée, mais vous pouvez consulter l' option Relais DHCP.)
Cela signifie que même si la fonctionnalité Protection des noms est désactivée sur une seule étendue du serveur, cela devrait suffire pour qu'un hacker puisse écraser les enregistrements clients (étant donné l'une des mauvaises configurations discutées précédemment).
Informations d'identification DNS
Un autre paramètre pourrait être configuré sur le serveur DHCP : Informations d'identification DNS. Ce paramètre nous permet de fournir les informations d'identification d'un utilisateur de domaine, que le serveur DHCP (et non le compte d'ordinateur) peut alors utiliser lors de la création et de la mise à jour d'enregistrements (Figure 28).
Figure 28 : configuration d'informations d'identification DHCP DNS
Revenons à l'exemple dans lequel un serveur DHCP a été installé sur un DC. Lors de la mise à jour d'enregistrements DNS, le compte d'ordinateur du DC a été utilisé, un compte qui dispose d'autorisations pour tout enregistrement de la zone. Avec des informations d'identification DNS configurées, un compte faible pourrait alors être utilisé et l'attaque ne fonctionnerait plus.
Il est très important de configurer des informations d'identification DNS. Cela permet de réduire la surface d'attaque exposée par le serveur DHCP. Cela devrait permettre d'atténuer les attaques les plus graves que nous avons décrites précédemment.
Cependant, vous devez tenir compte de deux détails lorsque vous utilisez cette fonctionnalité :
Les informations d'identification configurées doivent être un utilisateur faible. Si nous le configurons en tant qu'administrateur de domaine, par exemple, le serveur DHCP serait toujours en mesure d'écraser des enregistrements arbitraires.
Les enregistrements DNS créés par le serveur DHCP appartiendraient toujours aux mêmes informations d'identification et seraient toujours vulnérables à tout écrasement DHCP DNS.
Groupe DNSUpdateProxy
Au cours de notre enquête sur les serveurs DHCP de Microsoft et leur interaction avec le DNS, nous avons trouvé une autre fonctionnalité pouvant être utilisée de manière abusive : le groupe DNSUpdateProxy . Ce groupe est destiné à résoudre deux problèmes liés aux autorisations des enregistrements gérés : le problème de client mis à niveau et le problème de serveurs DHCP multiples.
Problème de client mis à niveau
Commençons par le problème de client mis à niveau : un client existant utilise initialement le serveur DHCP pour enregistrer un enregistrement DNS, puis est mis à niveau vers un système d'exploitation plus récent prenant en charge les mises à jour dynamiques DNS. Le client ne peut pas modifier son enregistrement directement, car ce dernier appartient au serveur DHCP qui l'a créé.
Pour résoudre ce problème, il est possible d'ajouter le serveur DHCP au groupe DNSUpdateProxy.
Ce groupe a deux effets. Tout d'abord, lorsque ses membres créent un enregistrement DNS, l'ACL de l'enregistrement est différente de celle des enregistrements gérés normaux. Le groupe Utilisateurs authentifiés reçoit une autorisation d'écriture pour l'enregistrement. Cela signifie que tout client du domaine peut le modifier (Figure 29).
Figure 29 : ACL de l'enregistrement DNSUpdateProxy
Le deuxième effet est une fonctionnalité de « prise de contrôle de l'enregistrement ». Le premier client qui modifie un enregistrement créé par un membre du groupe DNSUpdateProxy en devient propriétaire et supprime l'autorisation d'écriture des utilisateurs authentifiés. Cela résout le problème de client mis à niveau en permettant aux clients de modifier leur propre enregistrement et d'en prendre le contrôle lorsqu'ils sont tenus de le faire.
Problème de serveurs DHCP multiples
Le deuxième problème survient lorsque plusieurs serveurs DHCP sont nécessaires pour fonctionner ensemble. Dans cet exemple, nous avons deux serveurs DHCP ( DHCP1 et DHCP2)et un client PC1 qui enregistre un enregistrement DNS via le serveur DHCP1.
Maintenant, imaginons que le serveur DHCP1 se déconnecte pour une raison quelconque et que le serveur DHCP2 se met en marche. Le bail du client expire, il contacte donc le serveur DHCP2 pour en obtenir un nouveau. Lorsque le serveur DHCP2 loue la nouvelle adresse IP et tente de modifier l'enregistrement DNS pour le client, il échoue car l'enregistrement appartient au serveur DHCP1 (Figure 30).
Figure 30 : exemple de configuration à plusieurs serveurs DHCP
Ce problème peut à nouveau être résolu en utilisant le groupe DNSUpdateProxy grâce à une fonctionnalité supplémentaire de ce groupe. Si un membre du groupe DNSUpdateProxy tente de modifier un enregistrement appartenant à un autre membre, la mise à jour réussit grâce à la liste de contrôle d'accès. Cependant, cette fois-ci, l'ACL et le propriétaire ne changent pas. Cela permet à plusieurs serveurs de « coposséder » les enregistrements.
Un risque de sécurité et un bug
À présent, vous comprenez probablement que le groupe DNSUpdateProxy présente un risque de sécurité : Tout enregistrement créé par des membres de ce groupe pourrait être « volé » par un utilisateur authentifié. Ce n'est pas une vulnérabilité, mais seulement un abus de la conception de la fonctionnalité. Microsoft reconnaît ce risque.
En plus de ce risque, nous avons identifié un autre problème qui provient de ce qui semble être un bug dans la mise en œuvre de la fonctionnalité DNSUpdateProxy. Lorsqu'un membre du groupe crée son propre enregistrement DNS, ce dernier est créé avec la même ACL vulnérable, pour laquelle les utilisateurs authentifiés disposent d'autorisations d'écriture.
Un exemple est illustré dans la Figure 31. L'enregistrement dhcp1.aka.test de notre serveur DHCP a initialement une ACL sécurisée.
Figure 31 : ACL initiale du serveur DHCP
Nous pouvons voir que le compte d'ordinateur dispose d'autorisations pour cet enregistrement et que le groupe Utilisateurs authentifiés est introuvable. Maintenant, nous ajoutons le serveur au groupe DNSUpdateProxy et déclenchons une reconstitution de l'enregistrement DNS. Cela peut se produire pour plusieurs raisons (en cas de modification du nom du serveur, par exemple). Une fois l'enregistrement DNS recréé, nous inspectons sa nouvelle ACL (Figure 32).
Figure 32 : ACL vulnérable du serveur DHCP
Nous voyons que les utilisateurs du domaine peuvent désormais accéder en écriture au nouvel enregistrement DNS. Il est évident que cet aspect de la fonctionnalité n'est pas prévu. Les enregistrements gérés créés par le serveur sont censés avoir une ACL modifiée, mais le propre enregistrement client du serveur ne devrait pas être affecté.
Atténuation des attaques DHCP DNS
Les mises à jour dynamiques DHCP DNS présentent de nombreux risques. Résumons toutes les différentes configurations de serveur possibles et voyons comment atténuer les attaques que nous venons de décrire.
Nous ferons référence aux deux types d'enregistrements : les enregistrements gérés créés par le serveur DHCP et les enregistrements clients créés directement par les clients Windows.
En bref :
Désactivez les mises à jour dynamiques DHCP DNS si vous n'en avez pas besoin
Les enregistrements clients devraient être protégés si vous configurez un utilisateur faible comme informations d'identification DNS
Les enregistrements gérés ne peuvent pas être protégés contre l'usurpation avec n'importe quelle configuration, il faut donc utiliser des enregistrements DNS statiques pour les hôtes sensibles autres que Windows (le cas échéant)
N'utilisez pas le groupe DNSUpdateProxy, mais utilisez les mêmes informations d'identification DNS sur tous vos serveurs DHCP
Informations d'identification DNS
C'est le meilleur moyen d'atténuer les écrasements DHCP DNS sur les enregistrements clients. Configurez un utilisateur faible avec un mot de passe fort dédié à cet effet. Si vous exécutez un serveur DHCP sur votre DC, cette étape est importante. Ce paramètre n'empêchera pas les écrasements DHCP DNS sur les enregistrements gérés.
Protection des noms
En théorie, la fonctionnalité Protection des noms devrait protéger les enregistrements gérés, mais en pratique, les hackers peuvent la contourner assez facilement. Elle devrait toujours être activée pour rendre les écrasements moins faciles.
Bien que la fonctionnalité Protection des noms ne soit pas destinée à protéger les enregistrements clients, si elle est activée sur toutes les étendues du serveur, les attaques par écrasement seraient tout de même atténuées.
Lors de la configuration de la fonctionnalité Protection des noms sur un serveur DHCP de Microsoft, il existe deux façons de l'appliquer : au niveau du serveur ou au niveau des étendues. Si la fonctionnalité Protection des noms est activée au niveau du serveur, on pourrait croire qu'elle l'est également au niveau des étendues, n'est-ce pas ? Et bien, ce n'est pas vraiment le cas. L'activation de la fonctionnalité Protection des noms au niveau du serveur garantit uniquement que les nouvelles étendues sur le serveur sont créées avec le paramètre activé, mais cela ne l'active pas sur les étendues existantes. Il est important de vérifier que la fonctionnalité Protection des noms est activée au niveau de chaque étendue sur le serveur.
DNSUpdateProxy
Vous ne devriez pas utiliser ce groupe. Il présente un risque de sécurité car tous les enregistrements créés par ses membres sont susceptibles d'être écrasés.
Si vous avez plusieurs serveurs DHCP et que vous voulez qu'ils fonctionnent ensemble, vous devriez plutôt utiliser des informations d'identification DNS. Il vous suffit de configurer les mêmes informations d'identification DNS sur tous les serveurs DHCP, ce qui leur permettra de modifier les enregistrements des uns et des autres.
DNSUpdateProxy n'est utile que si vous avez des clients Windows NT 4.0 (ou plus anciens) que vous prévoyez de mettre à niveau prochainement. Et si vos clients sont si anciens, DNSUpdateProxy n'est pas le plus gros de vos problèmes.
Si, pour une raison quelconque, vous devez utiliser DNSUpdateProxy, il est recommandé de créer un enregistrement DNS statique pour chacun des membres du groupe. Un enregistrement statique appartiendrait alors à son compte créateur, qui devrait être différent des comptes d'ordinateur des différents serveurs. Cela empêchera les serveurs de créer leurs propres enregistrements avec des autorisations non sécurisées.
Usurpation DHCP DNS
Il n'existe aucun moyen d'empêcher les hackers non authentifiés de créer des enregistrements DNS non existants. La seule façon de le faire serait de désactiver les mises à jour dynamiques DHCP DNS sur tous les serveurs DHCP. En général, si la fonctionnalité Mises à jour dynamiques DHCP DNS n'est pas requise dans votre environnement, il est préférable de la désactiver. Cela éliminera certains risques et aidera à réduire la surface d'attaque.
Détection des mauvaises configuration avec Invoke-DHCPCheckup
Pour vous aider à faire face aux différentes configurations DHCP possibles, nous publions un outil PowerShell, intitulé Invoke-DHCPCheckup , pour identifier les risques liés aux mises à jour dynamiques DHCP DNS (Figure 33).
Figure 33 : exemple de sortie de l'outil Invoke-DHCPCheckup
L'outil identifie les mauvaises configuration suivantes :
Informations d'identification DNS
Aucune information d'identification DNS n'est configurée
Les informations d'identification DNS configurées sont celles d'un utilisateur fort
Protection des noms
La fonctionnalité Protection des noms n'est pas activée sur une étendue
La fonctionnalité Protection des noms n'est pas activée par défaut sur les nouvelles étendues
DNSUpdateProxy
Afficher les membres du groupe
Spécifier si les membres sont des serveurs DHCP
Listes de contrôle d'accès d'enregistrements faibles
Répertorier les enregistrements appartenant aux serveurs DHCP (enregistrements gérés)
Répertorier les enregistrements qui pourraient être écrasés par des utilisateurs authentifiés
Cet outil repose sur l'API de gestion des serveurs DHCP et nécessite un utilisateur fort pour fonctionner. Par conséquent, il est principalement destiné aux équipes bleues.
Synthèse
Nous avons fait part de toutes nos constatations à Microsoft, qui a répondu que tous les problèmes mentionnés ci-dessus sont soit des problèmes de conception, soit pas assez graves pour fait l'objet d'un correctif.
Nous ne sommes pas d'accord. Les attaques que nous avons mises en lumière peuvent avoir un impact considérable. La possibilité d'écraser les enregistrements DNS sans authentification permet aux hackers d'avoir une emprise de type « machine-in-the-middle » sur les hôtes du domaine. Cela pourrait facilement exposer des informations sensibles et des informations d'identification, mais aussi permettre des attaques de relais. Les hackers pourraient alors pénétrer dans des domaines AD et élever les privilèges. Les statistiques que nous avons partagées dans cet article démontrent à quel point la menace est solide pour de nombreux réseaux de centres de données.
Étant donné qu'aucun correctif n'est prévu pour ces problèmes, nous exhortons les défenseurs à analyser leurs environnements en utilisant l'outil Invoke-DHCPCheckup pour essayer de localiser les mauvaises configuration risquées que nous avons mises en lumière. Attention spoiler : si vous n'avez pas modifié la configuration par défaut, vous êtes vulnérable.
Restez à l'écoute
Dans un prochain article de blog, nous allons publier DDSpoof (DHCP DNS Spoof), un outil qui met en œuvre toutes les attaques décrites dans cet article. Nous allons montrer comment des hackers non authentifiés peuvent collecter les données nécessaires à partir de serveurs DHCP, identifier les enregistrements DNS vulnérables, les écraser et utiliser cette possibilité pour compromettre les domaines AD.
