Pourquoi vous devriez maintenir votre zone DNS propre

16 Nov, 2020  - écrit par  dans Noms de domaine

J’avoue que mon espace numérique n’est pas toujours aussi ordonné qu’il pourrait l’être. Il m’arrive de laisser des onglets non lus ouverts dans la précipitation, ou des documents texte inachevés empilés les uns sur les autres. Quand je suis généreux avec moi-même, je vois cela comme le chaos d’où naît ma créativité. Quand je le suis moins, je vois cela comme du laisser-aller (et cela conduit à généralement a un grand ménage).

De tous ces espaces numériques, je dois admettre que ma zone DNS est généralement dans le bas dans la liste des endroits auxquels je pense quand je nettoie mon désordre. Cependant, il est extrêmement important que vous le fassiez, car un fichier de zone encombré avec des enregistrements de zone DNS que vous n’utilisez pas peut constituer une menace sérieuse.

Quelle est la pire chose qui puisse arriver ?

La célèbre société de covoiturage Uber a créé un sous-domaine sur son nom de domaine saostatic.uber.com. Elle a utilisé Amazon Cloudfront, un réseau de diffusion de contenu avec ce sous-domaine pendant son utilisation.

À un moment donné, Uber a cessé d’utiliser le sous-domaine saostatic.uber.com et a supprimé le point de terminaison de son Amazon Cloudfront.

Cependant, personne n’a jamais retiré le CNAME « saostatique » pointant vers Cloudfront. Il est resté en place.

Puis un beau jour, un chasseur de bug (lien en anglais) a découvert le sous-domaine saostatique, et a vu qu’il pointait toujours vers Cloudfront, même s’il a reçu une erreur « Bad Request » de la part de Cloudfront lorsqu’il a essayé d’y naviguer.

Ensuite, il ne lui restait qu’à ajouter saostatic.uber.com comme point de terminaison à partir de son propre compte Cloudfront et il a pu prendre le contrôle total de saostatic.uber.com.

Pire encore, le système d’authentification unique de Uber, qui venait d’être mis en place, ayant émis un cookie de session pour *.uber.com, dans un éventuel scénario d’attaque, le fait d’amener un utilisateur authentifié à naviguer sur saostatic.uber.com pourrait permettre à l’éventuel attaquant de détourner la session de celui-ci et d’accéder au compte d’un utilisateur sur une multitude de services de Uber.

Je n’essaie évidemment pas de m’en prendre à Uber. Les bugs arrivent. Nous voulons mettre en valeur le fait qu’oublier de supprimer un CNAME de votre zone DNS, ce qui semble être dérisoire, pourrait potentiellement créer un casse-tête majeur en matière de sécurité s’il est découvert par quelqu’un qui cherche à vous nuire ou à nuire à vos utilisateurs.

Pire encore, comme rien ne change de votre côté et qu’aucun de vos réseaux n’est compromis, ce type d’attaque est pratiquement impossible à détecter !

De même, les services SSL gratuits peuvent permettre à un pirate d’obtenir facilement un certificat SSL pour le sous-domaine, de sorte qu’il peut également être difficile pour vos clients de le remarquer.

Que pourraient-ils faire de plus ?

Dans l’exemple d’Uber, le chasseur de bugs a décrit l’utilisation de cookies pour exploiter ce problème. Cependant, certaines technologies, comme Oauth, ont un mécanisme de sous-domaine d’autorisation de liste qui permet aux développeurs d’indiquer les URI de rappel à accepter. Si un sous-domaine autorisé peut être détourné, alors le jeton Oauth d’un utilisateur pourrait être divulgué.

Il existe d’autres façons pour les attaquants d’utiliser les listes blanches liées à la prise de contrôle des sous-domaines.

Certains gestionnaires de mots de passe enregistrent également des mots de passe basés sur des sous-domaines, ainsi, un site de phishing pourrait récupérer les identifiants des utilisateurs depuis les gestionnaires de mots de passe.

Comment cela peut se produire ?

Ce que nous avons décrit ci-dessus est un exemple et Amazon Cloudfront est un service courant, mais ce n’est pas le seul service sur lequel cela pourrait fonctionner.

Il n’est pas nécessaire d’avoir une application de covoiturage à succès pour que cela vous arrive.

Prenons un exemple fictif et disons que votre site web est structuré de manière à ce que shop.example.com se dirigevers votre site de e-commerce. Supposons maintenant que vous déplaciez votre boutique vers le site example.com/shop et que vous supprimiez shop.example.com de votre hébergement. Si vous ne supprimez pas également l’enregistrement CNAME qui dirige shop.example.com vers votre fournisseur d’hébergement, quelqu’un d’autre pourrait potentiellement créer l’hôte de shop.example.com et détourner votre sous-domaine.

Vous devez prendre en compte le fait que tout service d’hébergement peut potentiellement permettre la création d’un nouvel hôte sur un sous-domaine que vous pointez vers eux via un enregistrement CNAME et agir en conséquence.

Le chasseur de bugs qui a trouvé l’ancien enregistrement CNAME d’Uber utilisait probablement un outil qui scanne les sous-domaines, ou il a pu simplement Googler le domaine et trouver un sous-domaine indexé quelque part. Ne supposez donc pas que vous n’êtes pas vulnérable simplement parce qu’il ne s’agit pas d’un sous-domaine évident comme admin.example.com ou mail.example.com.

Comment pouvez-vous empêcher les prises de contrôle de sous-domaines ?

La seule façon d’éviter une prise de contrôle des sous-domaines est de garder votre zone DNS propre. Cela ne signifie pas seulement que lorsque vous cessez d’utiliser un service d’hébergement pour la vente, le courrier électronique, l’assistance technique, etc., vous devez retirer de votre zone DNS l’enregistrement CNAME qui lui correspond.

Votre meilleure option estde mettre en place une redirection web [ lien ] sur le sous-domaine, soit vers votre page d’accueil, soit vers le service qui remplace celui que vous supprimez.

Cependant, ce n’est bien sûr pas comme ça que le flux de travail fonctionne dans certaines organisations et c’est normal. C’est pourquoi, indépendamment de l’interruption de certains services, vous devez vérifier régulièrement la zone DNS et vous assurer qu’il n’y a pas d’anciens CNAME qui y circulent.

Cela peut être une corvée, comme pour tout type de ménage, surtout si votre domaine est lié à un grand nombre de services différents, mais au bout du compte, cela en vaut la peine.