Verhindern verwaister DNS-Einträge und Vermeiden von Unterdomänenübernahmen

Dieser Artikel beschreibt die häufige Sicherheitsbedrohung durch Subdomain-Übernahme und die Maßnahmen, die Sie unternehmen können, um sie zu mindern.

Was ist eine Unterdomänenübernahme?

Subdomain-Übernahmen sind eine häufige, schwerwiegende Bedrohung für Organisationen, die regelmäßig viele Ressourcen erstellen und löschen. Eine Unterdomänenübernahme kann auftreten, wenn Sie über einen DNS-Eintrag verfügen, der auf eine nicht bereitgestellte Azure-Ressource verweist. Solche DNS-Einträge werden auch als „verwaiste DNS“-Einträge bezeichnet. CNAME-Einträge sind besonders anfällig für diese Bedrohung. Durch die Übernahme von Unterdomänen können böswillige Akteure Datenverkehr, der für die Domäne eines Unternehmens bestimmt ist, an eine Website für schädliche Aktivitäten umleiten.

Ein häufiges Szenario für eine Unterdomänenübernahme:

  1. ERSTELLUNG:

    1. Sie stellen eine Azure-Ressource mit dem folgenden vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) bereit: app-contogreat-dev-001.azurewebsites.net.

    2. Sie weisen einen CNAME-Eintrag in Ihrer DNS-Zone mit der Unterdomäne greatapp.contoso.com zu, durch den Datenverkehr an Ihre Azure-Ressource weitergeleitet wird.

  2. AUFHEBUNG DER BEREITSTELLUNG:

    1. Die Azure-Ressource wird deprovisioniert oder gelöscht, nachdem sie nicht mehr benötigt wird.

      An diesem Punkt greatapp.contoso.com der CNAME-Eintrag aus Ihrer DNS-Zone entfernt werden. Wird der CNAME-Eintrag nicht entfernt, wird er als aktive Domäne angekündigt, es wird jedoch kein Datenverkehr an eine aktive Azure-Ressource weitergeleitet. Sie verfügen jetzt über einen "dangling"-DNS-Eintrag.

    2. Die verwaiste Unterdomäne greatapp.contoso.com ist jetzt anfällig und kann übernommen werden, indem sie einer Ressource eines anderen Azure-Abonnements zugewiesen wird.

  3. ÜBERNAHME:

    1. Ein Bedrohungsakteur findet die verwaiste Unterdomäne mithilfe allgemein verfügbarer Methoden und Tools.

    2. Der Bedrohungsakteur stellt eine Azure-Ressource bereit, die den gleichen vollqualifizierten Domänennamen besitzt wie die Ressource, die sich zuvor unter Ihrer Kontrolle befand. In diesem Beispiel ist dies app-contogreat-dev-001.azurewebsites.net.

    3. Der an die Subdomain greatapp.contoso.com gesendete Datenverkehr wird nun an die Ressource des böswilligen Akteurs weitergeleitet, wo dieser den Inhalt kontrolliert.

Subdomänenübernahme von einer deprovisionierten Website

Risiken von Unterdomänenübernahmen

Wenn ein DNS-Eintrag auf eine Ressource verweist, die nicht verfügbar ist, sollte der Eintrag selbst aus der DNS-Zone entfernt werden. Wenn er nicht gelöscht wird, handelt es sich um einen „verwaisten DNS“-Eintrag, was eine Unterdomänenübernahme ermöglicht.

Verwaiste DNS-Einträge ermöglichen es Bedrohungsakteuren, den zugeordneten DNS-Namen zu kontrollieren, um böswillige Websites oder Dienste zu hosten. Böswillige Seiten und Dienste in der Unterdomäne einer Organisation können Folgendes verursachen:

  • Verlust der Kontrolle über den Inhalt der Subdomain: Negative Presse über die Unfähigkeit Ihrer Organisation, ihre Inhalte zu sichern, Markenschäden und Vertrauensverlust.

  • Cookie-Harvesting von ahnungslosen Besuchern: Es ist üblich, dass Web-Apps Session-Cookies in Subdomains (*.contoso.com) offenlegen. Jede Unterdomäne kann darauf zugreifen. Bedrohungsakteure können Subdomain-Übernahme nutzen, um eine authentisch aussehende Seite zu erstellen, ahnungslose Nutzer dazu bringen, sie zu besuchen, und deren Cookies (sogar sichere Cookies) sammeln. Ein weit verbreitetes Missverständnis ist, dass SSL-Zertifikate Ihre Seite und die Cookies Ihrer Nutzer vor einer Übernahme schützen. Bedrohungsakteure können die gehackte Unterdomäne verwenden, um ein gültiges SSL-Zertifikat zu beantragen und abzurufen. Gültige SSL-Zertifikate gewähren ihnen Zugriff auf sichere Cookies und führen außerdem dazu, dass die böswillige Website als legitim wahrgenommen wird.

  • Phishing-Kampagnen: Böswillige Akteure nutzen in Phishing-Kampagnen oft authentisch aussehende Subdomains aus. Das Risiko erstreckt sich sowohl auf bösartige Webseiten als auch auf MX-Datensätze. MX-Datensätze könnten es Bedrohungsakteuren ermöglichen, E-Mails zu empfangen, die an legitime Subdomains gerichtet sind, die mit vertrauenswürdigen Marken verknüpft sind.

  • Weitere Risiken: Bösartige Seiten könnten zu anderen klassischen Angriffen wie XSS, CSRF, CORS-umgehung und weiteren eskalieren.

Erkennen verwaister DNS-Einträge

Verwenden Sie die von Microsoft auf GitHub gehosteten PowerShell-Tools "Get-DanglingDnsRecords", um DNS-Einträge in Ihrer Organisation zu identifizieren, die möglicherweise verwaist sind.

Dieses Tool hilft Ihnen, alle Domains mit einem CNAME aufzulisten, der mit einer bestehenden Azure-Ressource verknüpft ist, die Sie auf Ihren Abonnements oder Tenants erstellt haben.

Wenn sich Ihre CNAME-Einträge in anderen DNS-Diensten befinden und auf Azure-Ressourcen verweisen, übergeben Sie die CNAME-Einträge in einer Eingabedatei an das Tool.

Von dem Tool werden die in der folgenden Tabelle aufgeführten Azure-Ressourcen unterstützt. Das Tool extrahiert alle CNAME-Einträge des Mandanten oder verwendet sie als Eingaben.

Dienst type FQDN-Eigenschaft Beispiel
Azure Front Door – der Dienst für Web-Traffic-Management microsoft.network/frontdoors properties.cName abc.azurefd.net
Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten) microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Öffentliche IP-Adressen microsoft.network/öffentlicheIP-Adressen properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Azure Traffic Manager microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instances microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Azure-API-Verwaltung microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Azure App Service microsoft.web/sites properties.defaultHostName abc.azurewebsites.net
Azure App Service – Slots microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Voraussetzungen

Führen Sie die Abfrage als Benutzer aus, der über Folgendes verfügt:

  • Zumindest Zugriff mit der Reader Rolle auf die Azure-Abonnements.
  • Lesezugriff auf Azure Resource Graph.

Wenn Sie Global Administrator des Mieters Ihrer Organisation sind, folgen Sie den Anweisungen in Elevate Access, um alle Azure-Abonnements und Verwaltungsgruppen zu verwalten, um Zugriff auf alle Abonnements Ihrer Organisation zu erhalten.

Tipp

Erwägen Sie Drosselungs- und Auslagerungsgrenzwerte für Azure Resource Graph, wenn Sie eine umfangreiche Azure-Umgebung haben.

Erfahren Sie mehr über das Arbeiten mit großen Azure-Ressourcendatensätzen.

Das Tool verwendet eine Batchverarbeitung für Abonnements, um diese Einschränkungen zu vermeiden.

Führen Sie das Skript aus.

Weitere Informationen zum PowerShell-Skript finden Sie unterGet-DanglingDnsRecords.ps1.

Behandeln verwaister DNS-Einträge

Überprüfen Sie Ihre DNS-Zonen, und ermitteln Sie verwaiste oder übernommene CNAME-Einträge. Wenn Sie hängende oder übernommene Subdomains entdecken, entfernen Sie die verwundbaren Subdomains und mindern Sie die Risiken durch folgende Schritte:

  1. Entfernen Sie in Ihrer DNS-Zone alle CNAME-Einträge, die auf FQDNs nicht mehr bereitgestellter Ressourcen verweisen.

  2. Um den Verkehr zu den von dir kontrollierten Ressourcen zu leiten, stelle mehr Ressourcen mit den FQDNs bereit, die in den CNAME-Datensätzen der hängenden Subdomänen angegeben sind.

  3. Überprüfen Sie Ihren Anwendungscode auf Verweise auf bestimmte Unterdomänen, und aktualisieren Sie alle fehlerhaften oder veralteten Unterdomänenverweise.

  4. Untersuchen Sie, ob es zu einer Kompromittierung kam, und ergreifen Sie Maßnahmen gemäß den Vorfallreaktionsverfahren Ihrer Organisation. Tipps und bewährte Verfahren zur Untersuchung:

    Wenn Ihre Anwendungslogik dazu führt, dass Geheimnisse wie OAuth-Zugangsdaten an hängende Subdomänen gesendet werden oder wenn datenschutzsensible Informationen an diese Subdomains übertragen werden, könnten diese Daten Dritten zugänglich gemacht werden.

  5. Verstehen Sie, warum der CNAME-Datensatz nicht aus Ihrer DNS-Zone entfernt wurde, als Sie die Ressource deprovisioniert haben, und ergreifen Sie Maßnahmen, um sicherzustellen, dass DNS-Datensätze angemessen aktualisiert werden, wenn Azure-Ressourcen in Zukunft deprovisioniert werden.

Vermeiden verwaister DNS-Einträge

Machen Sie Prozesse, die offene DNS-Einträge und daraus resultierende Subdomain-Übernahmen verhindern, zu einem entscheidenden Bestandteil Ihres Sicherheitsprogramms.

Die folgenden Abschnitte beschreiben Azure-Servicefunktionen, die bei der Entwicklung präventiver Maßnahmen helfen können. Entwickeln Sie andere Methoden, um dieses Problem durch die Best Practices oder Standardarbeitsverfahren Ihrer Organisation zu verhindern.

Microsoft Defender für den App-Service aktivieren

Die integrierte Plattform für Workloadschutz in der Cloud (Cloud Workload Protection Platform, CWPP) von Microsoft Defender for Cloud bietet eine Reihe von Plänen zum Schützen Ihrer Azure- sowie Hybrid- und Multicloudressourcen und -workloads.

Der Plan Microsoft Defender für App Service umfasst das Erkennen verwaister DNS-Einträge. Wenn du diesen Plan aktivierst, bekommst du Sicherheitswarnungen, wenn du eine App Service-Website deaktivierst, aber nicht deren benutzerdefinierte Domain aus deinem DNS-Registrar entfernst.

Der sogenannte "Dangleling DNS"-Schutz von Microsoft Defender for Cloud ist unabhängig davon, ob Sie Ihre Domains mit Azure DNS oder einen externen Domainregistrar verwalten, und gilt für App Service sowohl unter Windows als auch unter Linux.

Weitere Informationen zu dieser Funktion und anderen Vorteilen dieser Microsoft Defender-Pläne finden Sie unter Einführung in Microsoft Defender für App Service.

Verwenden von Azure DNS-Aliaseinträgen

Azure DNS-Alias-Datensätze können hängende Referenzen verhindern, indem sie den Lebenszyklus eines DNS-Datensatzes mit einer Azure-Ressource koppeln. Stellen Sie sich beispielsweise einen DNS-Eintrag vor, der als Aliaseintrag qualifiziert wird, um auf eine öffentliche IP-Adresse oder auf ein Traffic Manager-Profil zu verweisen. Wenn Sie diese zugrunde liegenden Ressourcen löschen, wird der DNS-Aliaseintrag ein leerer Eintragssatz. Der DNS-Alias-Eintrag verweist nicht mehr auf die gelöschte Ressource. Alias-Datensätze sind darin begrenzt, was sie schützen können. Die Liste ist derzeit beschränkt auf:

  • Azure Front Door – der Dienst für Web-Traffic-Management
  • Traffic Manager-Profile
  • Azure Content Delivery Network-Endpunkte (CDN)
  • Öffentliche IPs

Trotz des heutigen begrenzten Serviceangebots sollten Sie Alias-Datensätze verwenden, um sich gegen Subdomain-Übernahmen zu schützen, wann immer möglich.

Weitere Informationen finden Sie unter Azure DNS Alias Records Capabilities.

Verwenden der Überprüfung benutzerdefinierter Domänen von Azure App Service

Wenn du DNS-Einträge für den Azure App Service erstellst, erstelle einen asuid.{subdomain} TXT-Eintrag mit der Domain-Verifizierungs-ID. Wenn ein solcher TXT-Datensatz existiert, kann kein anderes Azure-Abonnement die benutzerdefinierte Domain validieren oder übernehmen.

Diese Datensätze verhindern nicht, dass jemand eine Azure App Service-Instanz mit demselben Namen wie in deinem CNAME-Eintrag erstellt. Ohne die Möglichkeit, den Besitz des Domainnamens nachzuweisen, können Böswillige keinen Traffic empfangen oder den Inhalt kontrollieren.

Für weitere Informationen siehe Einen vorhandenen benutzerdefinierten DNS-Namen Azure App Service zuordnen.

Erstellen und Automatisieren von Prozessen zum Abschwächen der Bedrohung

Entwicklungs- und Betriebsteams sollten Bereinigungsprozesse durchführen, um Bedrohungen durch verwaiste DNS-Einträge zu vermeiden. Die folgenden Maßnahmen helfen Ihrer Organisation, diese Bedrohung zu vermeiden.

  • Erstellen von Verfahren zur Verhinderung:

    • Informieren Sie Ihre Anwendungsentwickler darüber, dass sie beim Löschen von Ressourcen Adressen immer umleiten.

    • Nehmen Sie „DNS-Eintrag entfernen“ auf die Liste der Punkte auf, die bei der Außerbetriebsetzung eines Diensts beachtet werden müssen.

      • Füge Löschschlösser zu allen Ressourcen hinzu, die einen eigenen DNS-Eintrag haben. Eine Löschsperre dient als Indikator dafür, dass die Zuordnung entfernt werden muss, bevor die Bereitstellung der Ressource aufgehoben wird. Solche Maßnahmen funktionieren nur, wenn sie mit internen Bildungsprogrammen kombiniert werden.
  • Erstellen von Verfahren für die Ermittlung:

    • Überprüfen Sie Ihre DNS-Einträge regelmäßig, um sicherzustellen, dass alle Ihre Unterdomänen Azure-Ressourcen zugeordnet sind, auf die Folgendes zutrifft:

      • Vorhanden: Durchsuchen Sie Ihre DNS-Zonen nach Ressourcen, die auf Azure-Subdomains wie *.azurewebsites.net oder *.cloudapp.azure.com verweisen (siehe die Referenzliste der Azure-Domänen).
      • Sie besitzen: Bestätigen Sie, dass Ihnen alle Ressourcen gehören, auf die Ihre DNS-Subdomains verweisen.
    • Pflegen Sie einen Dienstkatalog mit Ihren Azure-FQDN-Endpunkten (Fully Qualified Domain Name, vollqualifizierter Domänenname) und den Anwendungsbesitzern. Verwenden Sie Azure Resource Graph, das Azure-Portal oder einen anderen Asset-Inventory-Prozess, um regelmäßig die FQDN-Endpunktinformationen für Ressourcen zu exportieren, auf die Sie zugreifen können. Wenn Sie Zugriff auf alle Abonnements Ihres Mieters haben, fügen Sie alle Abonnements im Inventar auf. Wenn nicht, dokumentieren Sie, welche Abonnements das Inventar abdeckt.

  • Erstellen von Verfahren zur Behebung:

    • Wenn Ihr Team offene DNS-Einträge findet, untersuchen Sie, ob es zu einer Kompromittierung gekommen ist.
    • Untersuchen Sie, weshalb die Adresse nicht umgeleitet wurde, als die Ressource außer Betrieb gesetzt wurde.
    • Löschen Sie den DNS-Eintrag, wenn er nicht mehr verwendet wird, oder verweisen Sie ihn auf die korrekte Azure-Ressource (FQDN), die sich im Besitz Ihrer Organisation befindet.

Bereinigen Sie DNS-Zeiger oder fordern Sie das DNS zurück

Wenn Sie eine klassische Cloud-Service-Ressource löschen, reserviert Azure den entsprechenden DNS-Namen gemäß den Azure DNS-Richtlinien. Während des Reservierungszeitraums können nur Abonnements, die zum Microsoft Entra-Tenant des Abonnements gehören, dem der DNS-Name ursprünglich zugeordnet war, diesen erneut verwenden. Nach Ablauf der Reservierung kann jedes Azure-Abonnement den DNS-Namen beanspruchen. DNS-Reservierungen geben Ihnen Zeit, Assoziationen oder Hinweise auf den DNS-Namen zu bereinigen oder den DNS-Namen in Azure zurückzufordern. Löschen Sie unerwünschte DNS-Einträge so schnell wie möglich. Du kannst den reservierten DNS-Namen ableiten, indem du den Cloud-Service-Namen an die DNS-Zone dieser Cloud anhängst.

  • Öffentlich: cloudapp.net
  • Mondkuchen: chinacloudapp.cn
  • Fairfax: usgovcloudapp.net
  • BlackForest: azurecloudapp.de

Zum Beispiel hat ein gehosteter Dienst in Public named test den DNS-Namen test.cloudapp.net.

Beispiel: Abonnements A und B sind die einzigen Abonnements, die zum Microsoft Entra-Tenant ABgehören. Abonnement A enthält einen klassischen Cloud-Dienst mit dem Namen test und dem DNS-Namen test.cloudapp.net. Wenn du den Cloud-Dienst löschst, reserviert Azure den DNS-Namen test.cloudapp.net. Während der Reservierungsphase kann nur ein Abonnement A oder ein Abonnement B den DNS-Namen test.cloudapp.net beanspruchen, indem ein klassischer Cloud-Dienst namens testerstellt wird. Kein anderes Abonnement kann es für sich beanspruchen. Nach Ablauf der Reservierungsfrist kann jedes Azure-Abonnement test.cloudapp.net beanspruchen.

Nächste Schritte

Weitere Informationen zu verwandten Diensten und Azure-Features, die Sie verwenden können, um sich vor Unterdomänenübernahmen zu schützen, finden Sie auf den folgenden Seiten.