DNS pendant : comment le repérer et le corriger avant une prise de contrôle

Le DNS pendant est l'un de ces problèmes faciles à créer et véritablement difficiles à détecter. Un enregistrement continue de pointer vers une ressource cloud après la disparition de cette ressource, et à moins que quelque chose ne surveille la situation, personne ne s'en aperçoit avant que cela ne devienne un problème. La bonne nouvelle, c'est que vous n'avez pas besoin de partir de zéro. Deux des sources les plus crédibles en matière de sécurité, OWASP et AWS, documentent pourquoi le DNS pendant se produit et ce qu'il faut faire. Ce blog aborde le risque, ce que chacun en dit, comment mettre leurs recommandations en pratique, et où se situent les lacunes des outils qui laissent la plupart des équipes exposées.

Résumé exécutif : Les enregistrements DNS pendants permettent aux attaquants de prendre le contrôle d'un sous-domaine sans compromettre quoi que ce soit. OWASP et AWS documentent tous deux le problème et la solution, et les recommandations mises à jour du NIST le nomment désormais directement. La correction est simple par enregistrement. La partie difficile consiste à trouver en continu les enregistrements pendants sur un véritable parc composé de plusieurs registraires et clouds, ce qui est précisément la lacune que Red Sift peut combler.

Points clés à retenir :

• Un enregistrement DNS pendant pointe vers une ressource cloud qui a été supprimée. Si le nom de la ressource peut être récupéré, un attaquant peut diffuser son propre contenu sur votre sous-domaine.
• Ce n'est pas le signe d'une équipe négligente. C'est un effet secondaire structurel de la rapidité avec laquelle les ressources cloud sont créées et retirées.
• OWASP et AWS documentent tous deux le problème, il existe donc des recommandations claires et crédibles à suivre.
• AWS reconnaît franchement que sa plateforme ne comble pas cette lacune pour vous : des noms de ressources réutilisables, aucun mécanisme universel de vérification de domaine, et des attaquants qui scannent déjà activement les enregistrements pendants.
• La correction est simple par enregistrement. La partie difficile est la découverte continue sur un parc multi-registraires et multi-cloud, c'est là que Red Sift Attack Surface Management vous aide.

Un enregistrement DNS pendant est une entrée DNS, généralement un CNAME (Canonical Name, qui associe un nom à un autre), qui continue de pointer vers une ressource cloud après la suppression de cette ressource. Le service a disparu. L'enregistrement, non. Sur de nombreuses plateformes cloud, le nom de la ressource retourne alors dans un pool partagé que tout client peut revendiquer. Un attaquant qui recrée une ressource portant ce nom hérite de votre sous-domaine, car votre DNS continue d'y envoyer du trafic.

Aucune violation, aucun mot de passe volé. L'enregistrement survit simplement à la ressource, et la brèche qu'il laisse peut être revendiquée.

Ce qui rend cela plus grave qu'une simple page cassée, c'est la confiance que votre domaine porte déjà. Un sous-domaine que vos clients, navigateurs et systèmes de messagerie considèrent comme le vôtre devient sous contrôle d'un attaquant. Cela ouvre la voie au phishing sur un domaine reconnu, au vol de cookies de session valables sur le domaine parent, au détournement des flux de connexion OAuth et SSO, et à l'émission de certificats TLS valides à votre nom via des vérifications de validation de domaine. Si la chaîne d'enregistrements touche la messagerie, cela peut aussi signifier l'interception de réinitialisations de mot de passe. C'est le mode de défaillance de la « prise de contrôle ».

OWASP, la communauté de normes neutre vis-à-vis des fournisseurs, considère la prise de contrôle de sous-domaine comme un problème opérationnel plutôt qu'un bug logiciel, et son point le plus utile est aussi le plus simple. La plupart des organisations n'ont aucun moyen de détecter quand la cible d'un enregistrement DNS cesse discrètement d'exister. C'est l'état par défaut, pas un manque de vigilance. L'enregistrement et la ressource s'éloignent l'un de l'autre, rien ne les réconcilie, et la brèche reste ouverte jusqu'à ce que quelqu'un tombe dessus.

Les recommandations de prévention d'OWASP sont claires et pratiques : tenez un inventaire de ce vers quoi pointent vos enregistrements, supprimez les enregistrements avant les ressources dont ils dépendent, et surveillez les messages d'erreur du fournisseur qu'une ressource morte renvoie avant que quiconque ne la revendique. C'est un conseil pertinent, applicable, et gratuit.

AWS documente cela dans ses propres recommandations de sécurité, et cette franchise mérite d'être saluée. AWS reconnaît d'emblée que la plateforme ne comble pas cette lacune pour vous, et cite trois raisons à cela :

• De nombreux services AWS permettent à un nouveau client de revendiquer un nom d'hôte ou un nom de ressource précédemment utilisé.
• AWS n'offre actuellement aucun mécanisme universel de vérification de domaine à travers ses services.
• Les équipes de réponse aux incidents d'AWS constatent que des attaquants scannent activement le DNS public à la recherche d'enregistrements CNAME pointant vers des ressources qui n'existent plus.

Ce dernier point compte. Ce n'est pas un risque théorique qui dort dans un backlog. C'est un comportement de scan actif, qui se produit en ce moment même.

Voici la distinction utile entre les deux voix. OWASP n'est pas AWS, il peut donc conseiller mais ne peut pas changer le fonctionnement du cloud. AWS pourrait ajouter des contrôles universels, comme une vérification de domaine qui neutraliserait la plupart de ces problèmes, mais pour l'instant, ce choix n'a pas été fait. Cela laisse un véritable écart entre ce que les fournisseurs vous donnent et ce dont vous avez besoin pour rester protégé. Ce n'est pas un écart que vous avez créé, et le combler ne nécessite pas d'attendre qu'un fournisseur agisse. Cela nécessite de la visibilité, et la visibilité est quelque chose que vous pouvez ajouter dès aujourd'hui.

Suivre ce conseil pour un enregistrement auquel vous pensez activement est facile. L'appliquer sur un parc que vous ne pouvez pas voir entièrement est la partie difficile. Le cloud a changé l'usage du DNS, et les parcs ont grandi avec lui. Dans une entreprise réelle, un seul domaine apex a révélé plus de 25 000 sous-domaines, dont la propriété était répartie entre l'infrastructure, le marketing, les développeurs, les fournisseurs SaaS et les fournisseurs cloud. Aucune équipe, seule, ne peut tout voir manuellement.

La réponse n'est donc pas un nettoyage ponctuel. C'est un modèle opérationnel reproductible. Ces cinq étapes, alignées sur les thématiques du NIST, transforment ces recommandations en quelque chose que vous pouvez réellement exécuter.

1. Inventaire. Découvrez chaque domaine, chaque zone, chaque enregistrement, quel que soit le gestionnaire : plusieurs registraires, plusieurs fournisseurs DNS, multi-cloud, et plusieurs autorités de certification. Vous ne pouvez pas protéger ce que vous n'avez pas trouvé.
2. Référence. Caractérisez à quoi ressemble une situation saine : les registraires et fournisseurs DNS que vous approuvez, vos plages cloud et autorités de certification agréées, votre posture d'authentification des e-mails, et où vous signez avec DNSSEC. Sans référence, chaque changement se ressemble et rien ne semble suspect.
3. Détecter et classer. Faites remonter les changements inattendus et supprimez le bruit attendu. Environ 1 % des noms changent quotidiennement, ce qui représente environ 375 événements par jour. La classification est la seule chose qui rend cela exploitable.
4. Évaluer en continu. Passez le parc au crible des thématiques du NIST SP 800-81r3 : protection du service DNS, menaces liées aux transferts de zone, contenu et cohérence des zones, minimisation de la fuite d'informations, intégrité des domaines externes, et signature et validation DNSSEC.
5. Prioriser. Segmentez le parc en niveaux pour que le modèle reste soutenable. Tout ne nécessite pas la même attention.

Faites cela, et le conseil d'inventaire d'OWASP ainsi que le conseil d'AWS de « supprimer l'enregistrement avant la ressource » cessent d'être des aspirations. Ils deviennent des étapes que vous pouvez mesurer et répéter.

L'étape qui met tout le monde en difficulté est la première, car vous ne pouvez ni inventorier ni surveiller ce que vous ne voyez pas, et ni les fournisseurs ni les outils gratuits ne vous donnent une vue complète. Les vérifications de configuration natives au cloud sont utiles mais conçues pour un seul compte et un seul cloud à la fois. Les scanners open source couvrent davantage de terrain mais ne s'exécutent que lorsque vous vous souvenez de les lancer. Les enregistrements qui finissent par être détournés sont rarement ceux auxquels vous pensez. Ce sont ceux que vous avez oubliés, hérités lors d'une acquisition, ou dont vous ignoriez même l'existence.

Red Sift ASM (Attack Surface Management) comble les lacunes que les plateformes laissent ouvertes. Il découvre les domaines et sous-domaines sur l'ensemble de votre empreinte externe, inspecte les configurations DNS, web et cloud, et signale les enregistrements pendants et les ressources revendicables dès qu'ils apparaissent, sur chaque registraire et cloud plutôt qu'un compte à la fois. En pratique, il vous offre la couche de vérification continue qu'AWS n'offre pas, appliquée à l'ensemble de votre parc.

Une bonne hygiène DNS, en supprimant l'enregistrement avant la ressource, constitue la première ligne de défense, et OWASP comme AWS vous fournissent un plan d'action solide pour cela. La découverte continue est ce qui permet d'attraper les enregistrements qui passent malgré tout entre les mailles du filet. Vous n'avez pas besoin d'attendre qu'un fournisseur comble la lacune pour prendre les devants.

Découvrez vers quoi pointe votre DNS avec Red Sift ASM ou parcourez l'ensemble des guides Red Sift pour en savoir plus sur la gestion des risques liés au DNS et aux certificats.