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

In diesem Artikel werden die allgemeinen Sicherheitsrisiken einer Unterdomänenübernahme und die Schritte beschrieben, die Sie ergreifen können, um dieses Problem abzuschwächen.

Was ist eine Unterdomänenübernahme?

Unterdomänenübernahmen sind häufige Bedrohungen mit hohem Schweregrad für Unternehmen, 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 Azure-Ressource verweist, deren Bereitstellung aufgehoben wurde. 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. Wenn die Azure-Ressource nicht mehr benötigt wird, wird sie gelöscht oder ihre Bereitstellung aufgehoben.

      An diesem Punkt greatapp.contoso.comsollte der CNAME-Eintrag aus der 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. An die Unterdomäne greatapp.contoso.com gesendeter Datenverkehr wird nun an die Ressource des bösartigen Akteurs weitergeleitet, wo er die Kontrolle über die Inhalte hat.

Unterdomänenübernahme einer Website, deren Bereitstellung aufgehoben wurde

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 Unterdomäne - Negative Presse dazu, dass Ihre Organisation ihre Inhalte nicht schützen kann, Schädigung der Marke und Vertrauensverlust.

  • Cookie-Harvesting von ahnungslosen Besuchern - Es ist üblich, dass Web-Apps Sitzungscookies für Unterdomänen (*.contoso.com) verfügbar machen. Jede Unterdomäne kann darauf zugreifen. Bedrohungsakteure können mithilfe einer Unterdomänenübernahme eine authentisch wirkende Seite erstellen, die von ahnungslosen Besuchern aufgerufen wird, und anschließend deren Cookies sammeln (einschließlich sicherer Cookies). Ein gängiges Missverständnis besteht darin, dass SSL-Zertifikate Ihre Website und die Cookies Ihrer Benutzer 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 häufig authentische Unterdomänen in Phishingkampagnen. Das Risiko erstreckt sich sowohl auf bösartige Websites als auch auf MX-Einträge, die es Bedrohungsakteuren ermöglichen könnten, E-Mails zu empfangen, die an legitime Subdomänen vertrauenswürdiger Marken gerichtet sind.

  • Weitere Risiken: Böswillige Websites können auch für andere klassische Angriffe wie XSS, CSRF, CORS-Umgehungen und Ähnliches verwendet werden.

Erkennen verwaister DNS-Einträge

Möglicherweise verwaiste DNS-Einträge in Ihrer Organisation können mithilfe des auf GitHub gehosteten Microsoft-PowerShell-Tools Get-DanglingDnsRecords erkannt werden.

Mit diesem Tool können Azure-Kunden alle Domänen mit einem CNAME-Eintrag auflisten, der einer vorhandenen Azure-Ressource zugeordnet ist, die in ihren Abonnements oder Mandanten erstellt wurde.

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 Typ FQDNproperty Beispiel
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Azure Blob Storage 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/publicipaddresses 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 Management 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:

  • mindestens Zugriff auf Leserebene für die Azure-Abonnements
  • Lesezugriff auf Azure Resource Graph

Wenn Sie ein globaler Administrator des Mandanten Ihrer Organisation sind, folgen Sie den Anleitungen unter Erhöhen der Zugriffsrechte zum Verwalten aller Azure-Abonnements und Verwaltungsgruppen, um Zugriff auf alle Abonnements Ihrer Organisation zu erhalten

Tipp

Bei Azure Resource Graph gelten Drosselungs- und Auslagerungsgrenzwerte, die in umfangreichen Azure-Umgebungen berücksichtigt werden müssen.

Weitere Informationen finden Sie unter Arbeiten mit großen Datasets von Azure-Ressourcen.

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

Ausführen des Skripts

Unter https://aka.ms/Get-DanglingDnsRecords können Sie das PowerShell-Skript Get-DanglingDnsRecords.ps1 von GitHub herunterladen, und Sie erhalten weitere Informationen dazu.

Behandeln verwaister DNS-Einträge

Überprüfen Sie Ihre DNS-Zonen, und ermitteln Sie verwaiste oder übernommene CNAME-Einträge. Sollten verwaiste oder übernommene Unterdomänen gefunden werden, entfernen Sie die gefährdeten Unterdomänen, und verringern Sie die damit verbundenen Risiken wie folgt:

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

  2. Stellen Sie weitere Ressourcen mit den FQDNs bereit, die in den CNAME-Einträgen der verwaisten Unterdomänen angegeben sind, damit Datenverkehr an Ressourcen weitergeleitet werden kann, die Ihrer Kontrolle unterliegen.

  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 eine Kompromittierung vorliegt, und gehen Sie gemäß den für Ihre Organisation vorgesehenen Verfahren für die Reaktion auf Vorfälle vor, um geeignete Maßnahmen zu ergreifen. Tipps und bewährte Methoden für die Untersuchung:

    Wenn Ihre Anwendungslogik dazu führt, dass Geheimnisse wie OAuth-Zugangsdaten an gefährdete Subdomänen gesendet werden oder wenn datenschutzsensible Informationen an diese Subdomänen übertragen werden, besteht die Möglichkeit, dass diese Daten für Dritte zugänglich sind.

  5. Verstehen Sie, warum der CNAME-Eintrag beim Aufheben der Ressourcenbereitstellung nicht aus Ihrer DNS-Zone entfernt wurde, und stellen Sie sicher, dass DNS-Einträge künftig entsprechend aktualisiert werden, wenn die Bereitstellung von Azure-Ressourcen aufgehoben wird.

Vermeiden verwaister DNS-Einträge

Ein wichtiger Teil des Sicherheitsprogramms besteht darin, sicherzustellen, dass Ihre Organisation Prozesse implementiert hat, die verwaiste DNS-Einträge und daraus resultierende Unterdomänenübernahmen verhindern.

Einige Azure-Dienste bieten Features, die Sie bei der Erstellung vorbeugender Maßnahmen unterstützen. Diese werden weiter unten ausführlicher beschrieben. Andere Methoden zur Vermeidung dieses Problems müssen über Best Practices oder Standards Ihrer Organisation implementiert werden.

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 von Microsoft Defender für den App-Service umfasst das Erkennen defekter DNS. Wenn dieser Plan aktiviert ist, erhalten Sie Sicherheitswarnungen, wenn Sie eine App Service-Website außer Betrieb nehmen, aber nicht ihre benutzerdefinierte Domäne aus Ihrer DNS-Registrierungsstelle entfernen.

Der Schutz von Microsoft Defender für Cloud vor defekter DNS ist abhängig davon verfügbar, ob Ihre Domänen mit Azure DNS oder mit einer externen Domänenregistrierungsstelle verwaltet werden. Der Schutz gilt sowohl für den App-Service unter Windows als auch Linux.

Weitere Informationen zu diesem und anderen Vorteilen des Microsoft-Defender-Plans finden Sie unter Einführung in Microsoft Defender für den App-Service.

Verwenden von Azure DNS-Aliaseinträgen

Azure DNS-Aliaseinträge verhindern verwaiste Verweise durch eine Kopplung des Lebenszyklus eines DNS-Eintrags mit einer Azure-Ressource. 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. Er verweist nicht mehr auf die gelöschte Ressource. Beachten Sie jedoch, dass es Grenzen in Bezug darauf gibt, was Sie mit Aliaseinträgen schützen können. Dies ist derzeit auf Folgendes beschränkt:

  • Azure Front Door
  • Traffic Manager-Profile
  • Azure Content Delivery Network-Endpunkte (CDN)
  • Öffentliche IP-Adressen

Trotz der aktuell begrenzten Dienstangebote empfiehlt es sich, nach Möglichkeit Aliaseinträge zu verwenden, um sich vor Unterdomänenübernahmen zu schützen.

Unter Funktionen erhalten Sie weitere Informationen zu den Funktionen von Aliaseinträgen von Azure DNS.

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

Wenn Sie DNS-Einträge für Azure App Service erstellen, erstellen Sie auch einen asuid.{subdomain}-TXT-Eintrag mit der Verifizierungs-ID für die Domäne. Wenn ein solcher TXT-Datensatz vorhanden ist, kann kein anderes Azure-Abonnement die benutzerdefinierte Domäne verifizieren und übernehmen.

Diese Datensätze verhindern nicht, dass jemand den Azure App Service mit dem gleichen Namen wie in Ihrem CNAME-Eintrag erstellt. Wenn Bedrohungsakteure nicht nachweisen können, dass sie Besitzer des Domänennamens sind, können sie keinen Datenverkehr empfangen oder den Inhalt kontrollieren.

Unter Tutorial: Zuordnen eines vorhandenen benutzerdefinierten DNS-Namens zu Azure App Service erhalten Sie weitere Informationen.

Erstellen und Automatisieren von Prozessen zum Abschwächen der Bedrohung

Entwickler und Betriebsteams müssen häufig Bereinigungsprozesse durchführen, damit keine Bedrohungen durch verwaiste DNS entstehen. Mithilfe der folgenden Vorgehensweisen können Sie sicherstellen, dass Ihre Organisation diese Bedrohung vermeidet.

  • Erstellen von Verfahren zur Prävention:

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

    • Legen Sie Löschsperren für alle Ressourcen mit einem benutzerdefinierten DNS-Eintrag fest. Eine Löschsperre dient als Indikator dafür, dass die Zuordnung entfernt werden muss, bevor die Bereitstellung der Ressource aufgehoben wird. Maßnahmen wie diese funktionieren nur in Kombination mit internen Schulungsprogrammen.

  • Erstellen von Verfahren zur 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: Fragen Sie die DNS-Zonen in Bezug auf Ressourcen ab, die auf Azure-Unterdomänen wie *.azurewebsites.net oder *.cloudapp.azure.com verweisen. Weitere Informationen dazu finden Sie unter Referenzliste von Azure-Domänen (nicht vollständig).
      • In Ihrem Besitz – stellen Sie sicher, dass Sie alle Ressourcen besitzen, auf die Ihre DNS-Unterdomänen verweisen.
    • Pflegen Sie einen Dienstkatalog mit Ihren Azure-FQDN-Endpunkten (Fully Qualified Domain Name, vollqualifizierter Domänenname) und den Anwendungsbesitzern. Führen Sie zum Erstellen des Dienstkatalogs das folgende Azure Resource Graph-Abfrageskript aus. Das Skript projiziert die FQDN-Endpunktinformationen der Ressourcen, auf die Sie Zugriff haben, und gibt sie in einer CSV-Datei aus. Wenn Sie Zugriff auf alle Abonnements Ihres Mandanten haben, berücksichtigt das Skript all diese Abonnements, wie im folgenden Beispielskript gezeigt. Um die Ergebnisse auf eine bestimmte Gruppe von Abonnements zu beschränken, bearbeiten Sie das Skript wie gezeigt.

  • Erstellen von Verfahren zur Korrektur:

    • Wenn Sie verwaiste DNS-Einträge finden, muss das Team überprüfen, ob eine Gefährdung aufgetreten 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 von DNS-Zeigern oder Zurückfordern des DNS

Nach dem Löschen der klassischen Clouddienstressource wird das entsprechende DNS laut den Azure DNS-Richtlinien reserviert. Während des Reservierungszeitraums ist die erneute Verwendung des DNS verboten, MIT AUSNAHME von Abonnements, die zum Microsoft Entra-Mandanten des Abonnements gehören, das ursprünglich das DNS besitzt. Nach Ablauf der Reservierung kann das DNS von jedem Abonnement beansprucht werden. Durch die DNS-Reservierung erhält der Kunde eine gewisse Zeit, um entweder 1) alle Zuordnungen/Zeiger zu dem besagten DNS zu bereinigen oder 2) das DNS in Azure zurückzufordern. Es wird empfohlen, unerwünschte DNS-Einträge so schnell wie möglich zu löschen. Der reservierte DNS-Name kann durch anfügen des Clouddienstnamens an die DNS-Zone für diese Cloud abgeleitet werden.

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

Ein gehosteter Dienst in „Public“ mit dem Namen „test“ würde also beispielsweise das DNS „test.cloudapp.net“ aufweisen.

Beispiel: Das Abonnement „A“ und das Abonnement „B“ sind die einzigen Abonnements, die dem Microsoft Entra-Mandanten „AB“ gehören. Das Abonnement „A“ enthält einen klassischen Clouddienst „test“ mit dem DNS-Namen „test.cloudapp.net“. Beim Löschen des Clouddiensts wird eine Reservierung für den DNS-Namen „test.cloudapp.net“ vorgenommen. Während des Reservierungszeitraums kann nur das Abonnement „A“ oder das Abonnement „B“ den DNS-Namen „test.cloudapp.net“ beanspruchen, indem ein klassischer Clouddienst namens „test“ erstellt wird. Keinem anderen Abonnement ist es möglich, diesen Namen zu beanspruchen. Nach dem Reservierungszeitraum kann „test.cloudapp.net“ nun von jedem Abonnement in Azure beansprucht werden.

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.