Prévention des entrées DNS non résolues et de l’acquisition de sous-domaine

  • Article

Cet article décrit la menace de sécurité courante que représente l’acquisition de sous-domaine et la procédure à suivre pour y remédier.

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

Les acquisitions de sous-domaines constituent une menace courante et de gravité élevée 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 une fois 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 routé vers la ressource de l’acteur malveillant où celui-ci contrôle le contenu.

Acquisition de sous-domaine à partir d’un site web déprovisionné

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 sur l’incapacité de votre organisation à sécuriser son contenu, ainsi que préjudice à la marque et perte de confiance.

  • Collecte de cookies à l’insu des visiteurs : il est courant que les applications web exposent les cookies de session aux sous-domaines (*.contoso.com) ; par conséquent, n’importe quel sous-domaine peut y accéder. Tout sous-domaine peut y accéder. Les auteurs de menaces peuvent utiliser l’acquisition de sous-domaine pour créer une page d’apparence authentique, inciter les utilisateurs non avertis à la visiter et collecter leurs cookies (même sécurisés). Selon une idée reçue, le recours à des certificats SSL protègerait votre site, ainsi que les cookies de vos utilisateurs, de l’acquisition. 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 d’hameçonnage – Les acteurs malveillants exploitent souvent des sous-domaines d’apparence authentique dans les campagnes d’hameçonnage. Le risque s’étend à la fois aux sites web malveillants et aux enregistrements MX, qui pourraient permettre à des acteurs de la menace de recevoir des courriels dirigés vers des sous-domaines légitimes associés à des marques de confiance.

  • Autres risques : les sites malveillants peuvent servir de base à d’autres attaques classiques (XSS, CSRF, contournement CORS, etc.).

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 aide les clients Azure à répertorier tous les domaines avec un enregistrement CNAME associé à une ressource Azure existante qui a été créée sur leurs 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.

Service Type FQDNproperty Exemple
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Stockage Blob Azure microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Adresses IP publiques microsoft.network/publicipaddresses properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Azure Traffic Manager microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instance microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Gestion des API Azure microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Azure App Service microsoft.web/sites properties.defaultHostName abc.azurewebsites.net
Azure App Service – Emplacements microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Prérequis

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

  • au moins l’accès de niveau lecteur aux abonnements Azure
  • accès en lecture au graphe des ressources Azure

Si vous êtes administrateur(-trice) global(e) du locataire de votre organisation, suivez les instructions de la section Élever l’accès pour gérer tous les abonnements Azure et les groupes de gestion afin d’accéder à tous les abonnements de votre organisation.

Conseil

Azure Resource Graph présente des limitations et des limites de pagination que vous devez prendre en compte si vous disposez d’un environnement Azure volumineux.

En savoir plus sur la gestion de gros jeux de données de ressources Azure.

L’outil utilise un traitement par lot d’abonnements pour éviter ces limitations.

Exécuter le script

En savoir plus sur le script PowerShell, Get-DanglingDnsRecords. ps1, et le télécharger à partir de GitHub : https://aka.ms/Get-DanglingDnsRecords.

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 non résolus ou dont vous avez perdu le contrôle, supprimez les sous-domaines vulnérables et atténuez les risques en procédant comme suit :

  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 permettre le routage du trafic vers des ressources dont vous avez le contrôle, approvisionnez des ressources supplémentaires avec les FQDN spécifiés dans les enregistrements CNAME des sous-domaines non résolus.

  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. Examinez si une compromission s’est produite, et prenez des mesures conformément aux procédures de réponse aux incidents de votre organisation. Conseils et meilleures pratiques en matière d’enquête :

    Si la logique de votre application entraîne l’envoi de secrets, tels que les identifiants OAuth, à des sous-domaines pendants ou si des informations sensibles en matière de confidentialité sont transmises à ces sous-domaines, il est possible que ces données soient exposées à des tiers.

  5. Comprenez pourquoi l’enregistrement CNAME n’a pas été supprimé de votre zone DNS lorsque la ressource a été déprovisionnée, et prenez les mesures nécessaires pour garantir que les enregistrements DNS seront mis à jour de manière appropriée lors du déprovisionnement de ressources Azure à l’avenir.

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

Il est crucial, dans le cadre du programme de sécurité d’une organisation, d’implémenter des processus visant à empêcher les entrées DNS non résolues et les acquisitions de sous-domaines résultantes.

Certains services Azure offrent des fonctionnalités pour vous aider à mettre en place des mesures préventives. Ils sont détaillés ci-dessous. D’autres méthodes pour éviter ce problème doivent être établies par le biais des meilleures pratiques de votre organisation ou de procédures d’exploitation 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. Avec ce plan activé, vous recevez des alertes de sécurité si vous désactivez un site web App Service, mais ne supprimez pas son domaine personnalisé de votre bureau d’enregistrement DNS.

La protection de DNS non résolu de Microsoft Defender pour le cloud est disponible pour les domaines gérés avec Azure DNS ou un bureau d’enregistrement de domaine externe. Elle s’applique à App Service tant sur Windows que sur Linux.

Pour en savoir plus sur ce sujet et d’autres avantages de ce plan Microsoft Defender, consultez Présentation de Microsoft Defender pour App Service.

Enregistrements d’alias Azure DNS

Les enregistrements d’alias 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. Il ne fait plus référence à la ressource supprimée. Il est important de noter qu’il existe des limites à la protection offerte par les enregistrements d’alias. La liste se limite actuellement aux éléments suivants :

  • Azure Front Door
  • Profils Traffic Manager
  • Points de terminaison Azure Content Delivery Network (CDN)
  • Adresses IP publiques

Malgré les offres de service limitées à l’heure actuelle, nous vous recommandons d’utiliser des enregistrements d’alias pour vous défendre dans la mesure du possible contre les acquisitions de sous-domaines.

En savoir plus sur les fonctionnalités des enregistrements d’alias Azure DNS.

Vérification du domaine personnalisé Azure App Service

Lors de la création d’entrées DNS pour Azure App Service, créez un enregistrement TXT asuid.{sous-domaine} avec l’ID de vérification du domaine. Lorsqu’il existe un enregistrement TXT de ce type, aucun autre abonnement Azure ne peut valider le domaine personnalisé, ni donc l’acquérir.

Ces enregistrements n’empêchent pas de créer le service Azure App Service du même nom que celui qui se trouve dans votre entrée CNAME. Sans moyen de prouver la propriété du nom de domaine, les auteurs de menaces ne peuvent pas recevoir de trafic ni contrôler le contenu.

En savoir plus sur le mappage d’un nom DNS personnalisé existant à Azure App Service.

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

Il incombe souvent aux développeurs et aux équipes d’exploitation d’exécuter des processus de nettoyage pour éviter les menaces liées aux noms DNS non résolus. Les pratiques ci-dessous vous aideront à faire en sorte que votre organisation ne subisse pas 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.

    • Placez des verrous de suppression sur les ressources qui comportent une entrée DNS personnalisée. Un verrou de suppression indique que le mappage doit être supprimé avant le déprovisionnement de la ressource. Les mesures comme celles-ci ne peuvent fonctionner qu’associées à des programmes de formation internes.

  • 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 :

      • Les ressources existent : interrogez vos zones DNS pour connaître les ressources pointant vers des sous-domaines Azure tels que *.azurewebsites.net ou *.cloudapp.azure.com (voir la Liste de références des domaines Azure).
      • Vous en êtes le propriétaire : vérifiez 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. Pour créer votre catalogue de services, exécutez le script de requête Azure Resource Graph suivant. Ce script projette les informations des points de terminaison de FQDN des ressources auxquelles vous avez accès et les génère dans un fichier CSV. Si vous avez accès à tous les abonnements de votre locataire, le script les prend tous en compte, comme indiqué dans l’exemple de script suivant. Pour restreindre les résultats à un ensemble spécifique d’abonnements, modifiez le script comme indiqué.

  • Créer des procédures de correction :

    • Lorsque des entrées DNS non résolues sont trouvées, votre équipe doit déterminer si une compromission s’est produite.
    • 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.

Nettoyer les pointeurs DNS ou récupérer le DNS

Lors de la suppression de la ressource du service cloud classique, le DNS correspondant est réservé conformément aux stratégies Azure DNS. Pendant la période de réservation, la réutilisation du DNS est interdite, à l’exception des abonnements appartenant au locataire Microsoft Entra de l’abonnement initialement propriétaire du DNS. Après expiration de la réservation, le DNS peut être revendiqué par n’importe quel abonnement. En prenant des réservations de DNS, le client dispose d’un peu de temps pour 1) nettoyer des associations/pointeurs dudit DNS ou 2) récupérer le DNS dans Azure. Il est recommandé de supprimer le plus tôt possible les entrées DNS indésirables. Le nom DNS réservé peut être dérivé en ajoutant le nom du service cloud à la zone DNS de ce cloud.

  • Public - cloudapp.net
  • Mooncake - chinacloudapp.cn
  • Fairfax - usgovcloudapp.net
  • BlackForest - azurecloudapp.de

Cela signifie qu’un service hébergé dans Public nommé « test » aura un DNS « test.cloudapp.net »

Exemple : l’abonnement « A » et l’abonnement « B » sont les seuls abonnements appartenant à un locataire Microsoft Entra « AB ». L’abonnement A contient un service cloud classique, test, portant le nom DNS test.cloudapp.net. Lors de la suppression du service Cloud, une réservation est prise sur le nom DNS test.cloudapp.net. 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 n’est autorisé à le revendiquer. Après la période de réservation, tout abonnement dans Azure peut revendiquer « 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.