Nos espaces numériques ne sont pas toujours aussi ordonnés qu’ils pourraient l’être. Onglets non lus laissés ouverts dans la précipitation, documents texte inachevés empilés les uns sur les autres.
De tous ces espaces numériques, mon 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 de nettoyer sa zone DNS car un fichier de zone encombré avec des enregistrements de zone DNS que vous n’utilisez pas peut constituer une menace sérieuse.
La pire chose qui peut arriver si je ne nettoie pas ma zone DNS
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 » de la zone DNS 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 en utilisant votre zone DNS ?
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 à cause de votre zone DNS ?
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 dirige vers 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 de la zone DNS 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 de la zone DNS et agir en conséquence.
Le chasseur de bugs qui a trouvé l’ancien enregistrement CNAME de la zone DNS 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 avec la zone DNS ?
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 mail, l’assistance technique, etc., vous devez retirer de votre zone DNS l’enregistrement CNAME qui lui correspond.
Votre meilleure option est de mettre en place une redirection web sur le sous-domaine, soit vers votre page d’accueil, soit vers le service qui remplace celui que vous supprimez.
Cependant, ce n’est 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’aucun ancien CNAME n’y circule.
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. Garder mon DNS propre est nécessaire en matière de sécurité !
Tagged in DNSNom de domaineSécurité
