Comment les transferts de zone ouverts exposent votre réseau interne

Résumé exécutif : Un transfert de zone DNS (AXFR) est censé rester entre le serveur de noms primaire d'un domaine et ses serveurs secondaires. Lorsqu'il est laissé ouvert à tous, une seule requête renvoie la liste complète de chaque hôte de cette zone. Lors de revues récentes, Red Sift a découvert des zones, dans plusieurs patrimoines, révélant des noms d'hôtes internes, une infrastructure VoIP non chiffrée, et des cartes réseau complètes à quiconque en faisait la demande. Aucune de ces organisations n'avait l'intention d'exposer cela. C'est simplement le résultat d'une accumulation.

À ne pas manquer : Le premier article de cette série sur la gestion d'un DNS orphelin.

• Un transfert de zone ouvert renvoie chaque nom d'hôte d'une zone en une seule requête, sans nécessiter de scan ni de déduction
• Les domaines parents sont souvent verrouillés alors qu'un sous-domaine délégué, fréquemment détenu par une équipe différente, reste grand ouvert
• Ce qui est exposé n'est pas abstrait. Il s'agit de points de terminaison SIP, d'environnements de développement et de conventions de nommage interne sur lesquels un attaquant peut agir immédiatement
• Red Sift ASM découvre et surveille ces actifs en continu, y compris ceux dont votre équipe ignore l'existence

Un transfert de zone DNS, ou AXFR, est le mécanisme qu'un serveur de noms primaire utilise pour répliquer son fichier de zone complet vers un serveur de noms secondaire. C'est une pratique normale et nécessaire à l'exploitation du DNS. Deux serveurs doivent disposer des mêmes enregistrements, donc l'un copie la totalité de la zone vers l'autre.

Le problème, c'est que l'AXFR n'a pas été conçu en tenant compte de l'internet moderne. Sauf configuration explicite pour restreindre les transferts aux adresses IP de confiance, un serveur de noms répondra à une demande de transfert émanant de n'importe qui. Exécutez dig axfr @nameserver domain.com contre un serveur mal configuré, et vous récupérez chaque enregistrement de cette zone. Chaque sous-domaine. Chaque nom d'hôte interne. Chaque adresse IP associée à ces hôtes.

Vous n'avez pas besoin de forcer des sous-domaines ou de scanner des plages d'IP pour dresser une carte de l'infrastructure de quelqu'un. Il suffit de la demander.

La plupart des équipes de sécurité qui ont réfléchi à cette question ont verrouillé les transferts sur leur domaine primaire. C'est la zone que tout le monde pense à vérifier.

Ce qui est souvent oublié, c'est la délégation. Lorsqu'un domaine délègue un sous-domaine à un serveur de noms différent, peut-être pour un produit spécifique, un bureau régional, ou une plateforme détenue par une autre équipe, cette zone déléguée fonctionne avec sa propre configuration. Personne ne la revérifie selon les standards du domaine parent, car personne ne la considère comme une zone distincte. C'est simplement « une partie du domaine ».

L'échelle est le véritable problème ici. Notre analyse a révélé le même schéma d'exposition dans plusieurs organisations. Prenons l'exemple d'une entreprise de télécommunications. Leurs serveurs de noms parents étaient propres : transferts restreints, enregistrements à jour, rien à signaler. Mais un sous-domaine délégué, mis en place des années auparavant pour une plateforme de vidéoconférence, autorisait encore des transferts de zone ouverts sur six noms d'hôtes.

Personne ne l'a placé là intentionnellement. Un sous-domaine est délégué pour un projet, l'équipe qui en était propriétaire passe à autre chose, et la configuration n'est jamais révisée. Les choses ont simplement fini ainsi.

Un seul dig axfr contre cette zone déléguée a renvoyé :

• Les noms d'hôtes internes de Session Border Controllers fonctionnant sur deux sites distincts, communiquant via SIP non chiffré
• Un ensemble de noms d'hôtes internes correspondant directement à des fonctions métier spécifiques, rendant la convention de nommage interne immédiatement lisible
• Un environnement de développement situé au sein de ce qui était par ailleurs une zone de production
• Un numéro de série SOA montrant que la zone n'avait pas été modifiée depuis 2019

Rien de tout cela n'exige d'un attaquant de faire preuve d'ingéniosité. C'est une liste de cibles, offerte gratuitement. Un SIP non chiffré indique exactement où intercepter un appel. Un environnement de développement dans une zone de production indique exactement où les contrôles sont probablement plus faibles. Un enregistrement mis à jour pour la dernière fois en 2019 indique que personne ne vérifie plus rien.

Une autre revue, cette fois dans une entreprise SaaS, a révélé une variante de la même cause profonde. Un ingénieur réseau avait récemment repris une infrastructure qui s'était développée pendant des années sous différents propriétaires. Il connaissait certains des problèmes présents dans la partie de la zone dont il avait hérité. Il ne les connaissait pas tous.

Un seul dig axfr a renvoyé près de 55 hôtes, chacun avec une adresse IP résolvable, en une seule réponse. Ce n'est pas une image partielle. C'est une carte quasi complète d'une portion significative de l'environnement de l'entreprise, livrée en une seule requête à quiconque a pensé à la demander.

Aucun de ces deux cas n'impliquait une attaque sophistiquée. Les deux impliquaient une requête DNS standard qui aurait dû être refusée et ne l'a pas été.

Un transfert de zone ouvert n'est pas un risque théorique confiné à une feuille de calcul de conformité. C'est de la reconnaissance, effectuée pour l'attaquant, sans aucun coût pour lui.

Une fois qu'une personne dispose de la liste complète de vos noms d'hôtes et de vos adresses IP, elle ne devine plus où chercher. Elle sait quel hôte exécute quoi. Elle sait où un environnement de développement pourrait avoir un correctif moins rigoureux. Elle sait quelle infrastructure gère le trafic vocal et si celui-ci est chiffré. Chaque mode de défaillance évoqué dans cet article, un transfert non restreint, une délégation non surveillée, un enregistrement obsolète que personne n'a revérifié, oriente un attaquant vers l'actif exact qui mérite d'être visé ensuite.

C'est aussi pourquoi les contrôles ponctuels ne suffisent pas. La zone de l'opérateur télécom avait probablement passé une revue à un moment donné. La délégation n'a simplement jamais été réexaminée par la suite. Les patrimoines DNS ne restent pas figés. De nouveaux sous-domaines sont délégués, de nouvelles équipes en prennent la responsabilité, et les configurations dérivent sans que personne ne décide qu'elles devraient le faire.

Testez tout serveur de noms dont vous êtes responsable avec :

Si la requête renvoie une liste de zone complète au lieu d'un refus, ce serveur autorise des transferts non restreints. Corrigez cela en limitant explicitement les transferts à une liste nommée d'adresses IP secondaires de confiance dans la configuration de votre serveur DNS, qu'il s'agisse de BIND, PowerDNS, ou du paramètre équivalent chez votre fournisseur DNS.

Puis allez au-delà du domaine parent. Dressez la liste de chaque sous-domaine ayant été délégué à un serveur de noms différent, et testez-les tous de la même manière. Si vous ne disposez pas d'une liste actualisée de ce qui a été délégué et à qui, c'est là le véritable constat. Vous n'avez pas encore un problème de transfert de zone, vous avez un problème de visibilité, et le transfert de zone n'est que l'endroit où il se manifeste en premier.

Il est difficile de détecter ce type de problème en vérifiant occasionnellement son propre domaine, car l'exposition ne se situe généralement pas sur le domaine que votre équipe gère activement. Elle se trouve sur celui qui a été délégué il y a trois ans et qui a discrètement disparu des radars de tout le monde.

Red Sift ASM découvre et inventorie en continu vos actifs exposés à l'extérieur, y compris ceux dont votre équipe ne sait pas encore qu'ils existent, en se connectant directement à vos bureaux d'enregistrement et à vos fournisseurs DNS gérés plutôt qu'en s'appuyant sur une liste manuelle. Il surveille la configuration DNS sur l'ensemble de votre patrimoine de manière continue, et non lors d'un audit ponctuel, afin qu'un sous-domaine délégué qui dérive hors politique soit signalé plutôt qu'oublié. Et parce qu'il vous montre ce qu'un attaquant voit depuis l'extérieur, l'infrastructure tierce et déléguée bénéficie du même niveau de contrôle que les actifs directement mis en place par votre équipe.