Alerte sur les détournements de sous-domaines Azure
Dans Microsoft Azure, des attaquants peuvent exploiter des sous-domaines actifs mais non utilisés, à des fins malveillantes. Voici comment identifier et supprimer les sous-domaines vulnérables et éviter de les exposer à des attaques potentielles.
Avez-vous créé un domaine et pointé vers une ressource cloud, puis supprimé le site ? Avez-vous laissé l'enregistrement de nom canonique (CNAME) dans les paramètres de vos services de noms de domaine ? C'est en tout cas ce que font de nombreux administrateurs, et les attaquants le savent... Ces défaillances leurs permettent de créer un site dans les enregistrements de vos sous-domaines et de s'emparer de ces sites. Les prises de contrôle de sous-domaines sont trop fréquentes, surtout dans les grandes entreprises qui créent et suppriment de nombreuses ressources. Les enregistrements de nom canonique, en particulier, sont une voie d'accès de choix aux prises de contrôle. Les acteurs malveillants utilisent souvent ces sites pour rediriger le trafic et l'activité vers différents autres sites. Même Microsoft n'est pas à l'abri de ce problème. Le service de noms de domaine (DNS) est un élément largement mal compris de l'infrastructure réseau. Trop souvent, une mauvaise configuration du DNS peut entraîner des problèmes massifs sur votre réseau. Elle peut donner l'impression que votre site web a été piraté alors que seuls les enregistrements ont été modifiés. Elle peut également permettre à des attaquants d'utiliser vos actifs pour mener des attaques.
Comment les attaquants exploitent-ils les sous-domaines ?
Comme le fait remarquer Microsoft, le risque de prise de contrôle d'un sous-domaine par un attaquant commence à partir du moment où vous créez et fournissez une ressource Azure. Supposons que le nom de la ressource Azure soit app-on-azure001.azurewebsites.net. Vous attribuez alors un enregistrement CNAME dans votre zone DNS actuelle avec un sous-domaine qui achemine le trafic vers la ressource Azure. Plutôt que d'envoyer les utilisateurs à app-on-azure001.azurewebsites.net, vous pouvez les envoyer à easierurl.domain.com. Plus tard, quand vous n'aurez plus besoin du sous-domaine, vous déprovisionnerez ou supprimerez le site web. Vous supprimerez alors le sous-domaine .votredomaine.com de la zone de services des noms de domaine. Mais si le CNAME reste en place, il se signalera comme domaine actif mais n'acheminera pas le trafic par une ressource Azure active. C'est ce que l'on appelle un « enregistrement DNS non résolu ».
Les attaquants utilisent divers outils et scripts pour rechercher et trouver ces sous-domaines. Une recherche DNS de base indique facilement à un attaquant les enregistrements CNAME non résolus. L'attaquant fournit alors une ressource Azure avec le même nom que celui que vous avez attribué à votre ressource Azure désormais manquante. Le site web de l'attaquant s'appelle maintenant app-on-azure001.azurewebsites.net et votre sous-domaine .votredomain.com achemine désormais son site par l'intermédiaire de vos ressources de nom de domaine. Ces attaques peuvent se traduire par la perte de contrôle sur le contenu du sous-domaine et la collecte de cookies et d'informations à l'insu des visiteurs du site de l'attaquant, ou par l'utilisation des faux sous-domaines pour des campagnes d'hameçonnage.
Empêcher la prise de contrôle d'un sous-domaine
Pour identifier les problèmes potentiels, examinez les CNAME associés aux ressources Azure en utilisant des outils personnalisés ou à l'aide de l'outil PowerShell Get-DanglingDnsRecords hébergé sur GitHub de Microsoft. Une fois que vous avez identifié tous les CNAME vulnérables ou ceux qui pointent vers des ressources qui ne sont pas les vôtres, rendez-vous à l'endroit où vos zones DNS sont hébergées et supprimez tous les enregistrements CNAME pointant vers des noms de domaine pleinement qualifiés de ressources qui ne sont plus approvisionnées. Vous devez également rechercher des sous-domaines spécifiques dans tout site web ou code d'application et mettre à jour toute référence de sous-domaine incorrecte ou périmée. Si des références provenant de processus d'authentification de tiers tels que OAuth ou d'autres informations sensibles ont été transmises au sous-domaine, vous devrez peut-être effectuer une réponse aux incidents afin de déterminer votre niveau d'exposition. Les attaquants peuvent intégrer des iframes provenant d'autres domaines et faire en sorte que ces sous-domaines paraissent fiables. Ils les utilisent ensuite pour des campagnes d'hameçonnage en interne et en externe auprès des clients. Passez toujours en revue les processus à l'origine de l'incident et mettez en place des processus pour vous assurer que cela ne se reproduira pas à l'avenir.
Azure dispose de processus natifs pour s'assurer que ces enregistrements non résolus ne se produisent dans votre réseau. L'un de ces processus consiste à utiliser l'enregistrement TXT asuid.(subdomain) avec l'ID de vérification du domaine d'Azure App Service. Cela garantit qu'aucun autre abonnement Azure ne peut valider et prendre le contrôle du domaine. Vous pouvez également mettre en place des processus de codage qui permettent une plus grande interaction entre les développeurs et les services opérationnels afin de vous assurer que vous ne créez pas de sites web susceptibles d'être détournés. La sensibilisation des développeurs au problème et l'ajout manuel de contrôles aux entrées DNS restantes dans les listes de contrôle ou les processus permettent aussi de vous protéger contre les prises de contrôle de sous-domaines. Mettez en place des processus normaux pour examiner les enregistrements DNS afin de vous assurer que toute ressource pointe vers *.azurewebsites.net ou *.cloudapp.azure.com.
Un problème de sécurité interne
Lors de la RSA Conference organisée en février 2020, Alun Jones, ingénieur en sécurité des applications, avait fait une présentation sur la vulnérabilité des contrôles de sous-domaines. Celui-ci a expliqué que, souvent, le déclassement des serveurs web n'était pas réalisé par l'entreprise qui avait mis en place les enregistrements DNS, et que les CNAME étaient donc laissés en l'état dans le DNS. Il a aussi déclaré que les entreprises ne pouvaient pas attendre des fournisseurs de cloud qu'ils fournissent les mêmes processus de sécurité et que finalement, il s'agissait d'un problème interne, parce que les développeurs ne comprenaient pas totalement la façon dont l'infrastructure avait été mise en place. M. Jones a également ajouté que la solution du script, souvent utilisée, pour passer en revue les enregistrements DNS à heure fixe et trouver les enregistrements CNAME non résolus, ne résolvait pas le problème de manière proactive car les pirates pouvaient trouver les sous-domaines vulnérables en moins d'une heure. Enfin, selon lui, la simple suppression d'un groupe de ressources préalablement à la suppression d'un site web ne suffit pas à garantir que les sites web sont sécurisés, et elle ne dépend pas non plus du niveau de compétence des développeurs. Alun Jones recommande d'augmenter la fréquence des scans automatisés. De même, il conseille de ne pas se fier à l'ajustement des enregistrements DNS, car le DNS a une durée de vie (TTL) d'environ 24 heures. Cela signifie que le sous-domaine peut rester actif et dans divers caches web pendant trop longtemps.
L'outil Open Web Application Security Project (OWASP) Amass permet de cartographier efficacement les sous-domaines et Sublist3r de trouver les sous-domaines vulnérables. SubOver peut être utilisé comme outil de reprise automatique de contrôle, mais pas avec Azure. Plusieurs fournisseurs de cloud proposent des processus permettant de mieux protéger les clients et de faire en sorte que les sites web restent la propriété de l'entreprise concernée. M. Jones a invité les entreprises à mieux comprendre leur environnement DNS et insisté pour que les développeurs reçoivent une formation sur les concepts de base du DNS, notamment en matière de TTL. Enfin, une bonne source d'information consiste aussi à demander à ses fournisseurs de cloud ce qu'ils font pour éviter ce problème.
