Prévention des entrées DNS orphelines et éviter l'usurpation de sous-domaine

Cet article décrit la menace de sécurité courante liée à la prise de contrôle de sous-domaines et les mesures que vous pouvez prendre pour la mitiger.

Qu’est-ce qu’une acquisition de sous-domaine ?

Les prises de contrôle de sous-domaines représentent une menace courante et de grande gravité pour les organisations qui créent et suppriment régulièrement de nombreuses ressources. Une prise de contrôle de sous-domaine peut se produire quand un enregistrement DNS pointe vers une ressource Azure déprovisionnée. Ces enregistrements DNS sont également appelés entrées « DNS non résolues ». Les enregistrements CNAME sont particulièrement vulnérables à cette menace. Les prises de contrôle de sous-domaines permettent à des acteurs malveillants de rediriger le trafic destiné au domaine d’une organisation vers un site effectuant une activité malveillante.

Voici un cas de figure courant d’acquisition de sous-domaine :

1. CRÉATION :

   1. Vous approvisionnez une ressource Azure avec un nom de domaine complet (FQDN) de app-contogreat-dev-001.azurewebsites.net.

   2. Vous attribuez un enregistrement CNAME dans votre zone DNS avec le sous-domaine greatapp.contoso.com qui route le trafic vers votre ressource Azure.

2. DÉPPROVISIONNEMENT :

   1. La ressource Azure est déprovisionnée ou supprimée après qu'elle n'est plus nécessaire.

      À ce stade, l’enregistrement CNAME greatapp.contoso.comdevrait être supprimé de votre zone DNS. Si l’enregistrement CNAME n’est pas supprimé, il est publié en tant que domaine actif, mais ne route pas le trafic vers une ressource Azure active. Vous disposez maintenant d’un enregistrement DNS « flottant ».

   2. Le sous-domaine non résolu, greatapp.contoso.com, est désormais vulnérable, et il est possible d’en prendre le contrôle en l’attribuant à une autre ressource de l’abonnement Azure.

3. PRISE DE CONTRÔLE :

   1. À l’aide de méthodes et d’outils couramment disponibles, un acteur de menace découvre le sous-domaine non résolu.

   2. L’acteur de menace configure une ressource Azure avec le nom de domaine complet de la ressource que vous avez précédemment contrôlée. Dans cet exemple : app-contogreat-dev-001.azurewebsites.net.

   3. Le trafic envoyé au sous-domaine greatapp.contoso.com est désormais dirigé vers la ressource de l’acteur malveillant où il contrôle le contenu.

Les risques de l’acquisition de sous-domaine

Lorsqu’un enregistrement DNS pointe vers une ressource qui n’est pas disponible, l’enregistrement lui-même doit être supprimé de votre zone DNS. S’il n’est pas supprimé, il s’agit d’un enregistrement « DNS flottant » qui permet la prise de contrôle d’un sous-domaine.

Les entrées DNS non résolues permettent aux auteurs de menaces de prendre le contrôle du nom DNS associé pour héberger un service ou un site web malveillant. La présence de pages et de services malveillants sur le sous-domaine d’une organisation pourrait avoir les répercussions suivantes :

• Perte de contrôle sur le contenu du sous-domaine : Mauvaise presse concernant l’incapacité de votre organisation à sécuriser son contenu, atteinte à la marque et perte de confiance.

• Récolte de cookies auprès de visiteurs sans méfiance : il est courant que les applications web exposent les cookies de session à des sous-domaines (*contoso.com). Tout sous-domaine peut y accéder. Les acteurs malveillants peuvent utiliser la prise de contrôle de sous-domaines pour créer une page à l’apparence authentique, tromper des utilisateurs sans méfiance pour qu’ils la visitent, et récolter leurs cookies (même sécurisés). Une idée reçue courante est que les certificats SSL protègent votre site et les cookies de vos utilisateurs contre une prise de contrôle. Or, un auteur de menace peut utiliser le sous-domaine détourné pour demander et recevoir un certificat SSL valide. Celui-ci lui accorde l’accès aux cookies sécurisés et peut augmenter encore la légitimité perçue du site malveillant.

• Campagnes de phishing : Les acteurs malveillants exploitent souvent des sous-domaines à apparence authentique dans les campagnes de phishing. Le risque s’étend à la fois aux sites web malveillants et aux enregistrements MX. Les enregistrements MX pourraient permettre aux acteurs malveillants de recevoir des e-mails dirigés vers des sous-domaines légitimes associés à des marques de confiance.

• Autres risques : Les sites malveillants peuvent évoluer vers d’autres attaques classiques telles que XSS, CSRF, CORS BYPASS, et plus encore.

Identifier les entrées DNS non résolues

Pour identifier les entrées DNS au sein de votre organisation qui pourraient être non résolues, utilisez l’outil PowerShell hébergé sur GitHub de Microsoft « Get-DanglingDnsRecords ».

Cet outil vous aide à lister tous les domaines dont un CNAME est associé à une ressource Azure existante que vous avez créée sur vos abonnements ou locataires.

Si vos CNAME se trouvent dans d’autres services DNS et pointent vers des ressources Azure, fournissez les CNAME à l’outil dans un fichier d’entrée.

L’outil prend en charge les ressources Azure répertoriées dans le tableau suivant. L’outil extrait, ou prend en entrée, tous les CNAME du locataire.

Prérequis

Exécutez la requête en tant qu’utilisateur disposant des privilèges suivants :

• Au moins l’accès du rôle Reader aux abonnements Azure.
• Accès en lecture à Azure Resource Graph.

Si vous êtes administrateur global du locataire de votre organisation, suivez les conseils d'Elevate Access pour gérer tous les abonnements Azure et les groupes de gestion afin d'accéder à tous les abonnements de votre organisation.

Exécuter le script

Pour plus d’informations sur le script PowerShell, voir Get-DanglingDnsRecords.ps1.

Corriger les entrées de DNS non-résolu

Examinez vos zones DNS et identifiez les enregistrements CNAME non résolus ou dont vous n’avez plus le contrôle. Si vous trouvez des sous-domaines suspendus ou repris, supprimez les sous-domaines vulnérables et réduisez les risques en utilisant les étapes suivantes :

1. À partir de votre zone DNS, supprimez tous les enregistrements CNAME qui pointent vers des FQDN de ressources qui ne sont plus approvisionnées.

2. Pour acheminer le trafic vers les ressources que vous contrôlez, fournissez plus de ressources avec les FQDN spécifiés dans les enregistrements CNAME des sous-domaines suspendus.

3. Examinez le code de votre application pour voir s’il contient des références à des sous-domaines spécifiques, puis mettez à jour toute référence à un sous-domaine incorrecte ou obsolète.

4. Enquêtez sur la possibilité qu’une compromission ait eu lieu et agissez conformément aux procédures de réponse aux incidents de votre organisation. Pour des conseils et des bonnes pratiques d’enquête :

   Si la logique de votre application entraîne l’envoi de secrets, tels que des identifiants OAuth, à des sous-domaines suspendus ou si des informations sensibles à la vie privée sont transmises à ces sous-domaines, ces données pourraient être exposées à des tiers.

5. Comprenez pourquoi l'enregistrement CNAME n'a pas été retiré de votre zone DNS lors du déprovisionnement de la ressource et prenez des mesures pour vous assurer que les enregistrements DNS sont mis à jour correctement lors du déprovisionnement des ressources Azure à l'avenir.

Empêcher les entrées de DNS non résolu

Faites des processus qui empêchent les saisies DNS suspendues et les prises de contrôle de sous-domaines qui en résultent une partie cruciale de votre programme de sécurité.

Les sections suivantes décrivent les fonctionnalités des services Azure qui peuvent aider à créer des mesures préventives. Établissez d’autres méthodes pour prévenir ce problème grâce aux meilleures pratiques de votre organisation ou aux procédures opérationnelles standard.

Activer Microsoft Defender pour App Service

La plateforme de protection des charges de travail cloud intégrée (CWPP), propose une gamme de plans pour protéger vos ressources et charges de travail Azure, hybrides et multi-cloud.

Le plan Microsoft Defender pour App Service comprend la détection de DNS non résolu. Lorsque vous activez ce plan, vous recevez des alertes de sécurité si vous mettez hors service un site web App Service sans supprimer son domaine personnalisé auprès de votre registrar DNS.

La protection DNS en suspension de Microsoft Defender for Cloud est disponible que vous gériez vos domaines avec Azure DNS ou un registraire de domaine externe, et s'applique à App Service sur Windows et Linux.

Pour plus d’informations sur cette fonctionnalité et d’autres avantages de ces plans Microsoft Defender, voir Introduction à Microsoft Defender for App Service.

Enregistrements d’alias Azure DNS

Les enregistrements d’alias d’Azure DNS empêchent les références non résolues en associant le cycle de vie d’un enregistrement DNS à une ressource Azure. Prenons l'exemple d'un enregistrement DNS qualifié en tant qu'enregistrement d'alias et pointant vers une adresse IP publique ou un profil Traffic Manager. Si vous supprimez ces ressources sous-jacentes, l’enregistrement d’alias DNS devient un jeu d’enregistrements vide. L’enregistrement DNS alias ne fait plus référence à la ressource supprimée. Les enregistrements d’alias ont des limites quant à ce qu’ils peuvent protéger. La liste se limite actuellement à :

• Azure Front Door
• Profils de responsables du trafic
• Points de terminaison du réseau de distribution de contenu Azure (CDN)
• Adresses IP publiques

Malgré les offres de services limitées aujourd’hui, utilisez des enregistrements d’alias pour vous défendre contre une prise de contrôle de sous-domaines dès que possible.

Pour plus d’informations, consultez les capacités des enregistrements d’alias Azure DNS.

Vérification du domaine personnalisé Azure App Service

Lorsque vous créez des entrées DNS pour Azure App Service, créez un asuid.{subdomain} enregistrement TXT avec l’identifiant de vérification du domaine. Lorsqu’un tel enregistrement TXT existe, aucun autre abonnement Azure ne peut valider le domaine personnalisé ni le reprendre.

Ces enregistrements n'empêchent pas quelqu'un de créer une instance Azure App Service portant le même nom que dans votre entrée CNAME. Sans la possibilité de prouver la propriété du nom de domaine, les acteurs malveillants ne peuvent pas recevoir de trafic ni contrôler le contenu.

Pour plus d’informations, voir Mapper un nom DNS personnalisé existant à Azure App Service.

Création et automatisation de processus pour atténuer la menace

Les développeurs et les équipes opérationnelles devraient exécuter des processus de nettoyage pour éviter les menaces DNS en suspens. Les pratiques suivantes aident votre organisation à éviter cette menace.

• Créer des procédures de prévention :

  • Apprenez à vos développeurs d’applications à réacheminer les adresses chaque fois qu’ils suppriment des ressources.

  • Placez « Supprimer l’entrée DNS » dans la liste des vérifications requises lors de la désactivation d’un service.

    • Ajoutez des verrous de suppression à toutes les ressources qui ont une entrée DNS personnalisée. Un verrou de suppression indique que le mappage doit être supprimé avant le déprovisionnement de la ressource. Des mesures comme celle-ci ne fonctionnent qu’en combinaison avec des programmes d’éducation interne.

• Créer des procédures de découverte :

  • Vérifiez régulièrement vos enregistrements DNS pour contrôler que vos sous-domaines sont tous mappés à des ressources Azure qui remplissent les conditions suivantes :

    • Exister : Interrogez vos zones DNS pour des ressources pointant vers Azure sous-domaines tels que *.azurewebsites.net ou *.cloudapp.azure. com (voir la liste de références des domaines Azure).
    • Vous possédez : Confirmez que vous possédez toutes les ressources que vos sous-domaines DNS ciblent.

  • Gérez un catalogue de services de vos points de terminaison de nom de domaine complet (FQDN) Azure et des propriétaires d’applications. Utilisez Azure Resource Graph, le portail Azure ou un autre processus d’inventaire des actifs pour exporter régulièrement les informations du point de terminaison FQDN pour les ressources accessibles. Si vous avez accès à tous les abonnements de votre locataire, incluez tous les abonnements dans l’inventaire. Si ce n’est pas le cas, documentez les abonnements couverts par l’inventaire.

• Créer des procédures de correction :

  • Lorsque votre équipe trouve des entrées DNS en suspens, vérifiez si une compromission a eu lieu.
  • Recherchez la raison pour laquelle l’adresse n’a pas été redirigée lorsque la ressource a été retirée.
  • Supprimez l’enregistrement DNS s’il n’est plus utilisé ou faites-le pointer vers la bonne ressource (FQDN) Azure détenue par votre organisation.

Nettoyez les pointeurs DNS ou récupérez le DNS

Lorsque vous supprimez une ressource classique de service cloud, Azure réserve le nom DNS correspondant selon les politiques Azure DNS. Pendant la période de réservation, seuls les abonnements appartenant au locataire Microsoft Entra de l’abonnement qui possédait initialement le nom DNS peuvent le réutiliser. Après l’expiration de la réservation, tout abonnement Azure peut réclamer le nom DNS. Les réservations DNS vous donnent le temps de nettoyer les associations ou les pointeurs vers le nom DNS, ou de récupérer le nom DNS dans Azure. Supprimez les entrées DNS non désirées dès que possible. Vous pouvez dériver le nom DNS réservé en ajoutant le nom du service cloud à la zone DNS de ce cloud.

• Public : cloudapp.net
• Gâteau de lune : chinacloudapp.cn
• Fairfax : usgovcloudapp.net
• ForêtNoire : azurecloudapp.de

Par exemple, un service hébergé dans Public nommé test porte le nom test.cloudapp.netDNS .

Exemple : Les abonnements A et B sont les seuls abonnements qui appartiennent au locataire Microsoft Entra AB. L’abonnement A contient un service cloud classique nommé test avec le nom test.cloudapp.netDNS . Lorsque vous supprimez le service cloud, Azure réserve le nom test.cloudapp.netDNS . Pendant la période de réservation, seuls l’abonnement A ou l’abonnement B peuvent revendiquer le nom DNS test.cloudapp.net en créant un service cloud classique nommé test. Aucun autre abonnement ne peut le réclamer. Après la période de réservation, n’importe quel abonnement Azure peut bénéficier de test.cloudapp.net.

Étapes suivantes

Pour plus d’informations sur les services connexes et les fonctionnalités Azure que vous pouvez utiliser pour vous défendre contre l’acquisition de sous-domaine, consultez les pages suivantes.

• Activez Microsoft Defender pour App Service - Recevez des alertes lorsque des entrées DNS suspendues sont détectées.

• Empêcher les enregistrements DNS non résolus avec Azure DNS

• Utiliser un ID de vérification du domaine lors de l’ajout de domaines personnalisés dans Azure App Service

• Démarrage rapide : Exécution d’une requête Resource Graph à l’aide d’Azure PowerShell