Subdomain Takeover: Wie es passiert und wie Sie es verhindern

Ein Subdomain Takeover geschieht, wenn ein DNS-Eintrag in Ihrer Zone noch auf eine externe Ressource zeigt, die Sie nicht mehr kontrollieren, und jemand anderes diese Ressource für sich beansprucht. Der typische Fall: shop.example.com ist ein CNAME auf eine gehostete Plattform, der Shop wurde gekündigt, der Eintrag blieb stehen. Lässt die Plattform jeden den freigewordenen Namen registrieren, ohne die Kontrolle über die Domain nachzuweisen, tut ein Angreifer genau das und liefert seine Inhalte auf Ihrer Subdomain aus, mit einem gültigen Zertifikat. Die Abhilfe ist unspektakulär und wirksam: Wissen Sie, welche Einträge nach außerhalb Ihrer Infrastruktur zeigen, und entfernen Sie den DNS-Eintrag, bevor Sie das löschen, worauf er zeigt. Dieser Leitfaden behandelt die Varianten, die Auswirkungen, das Aufspüren mit dig und curl und eine Checkliste zur Vorbeugung.

Wie ein Takeover abläuft

Nichts wird im üblichen Sinn gehackt. Ihr DNS sagt mit Ihrer Autorität „dieser Name wird dort drüben bedient“, und „dort drüben“ ist ein Namensraum, den sich alle Kunden eines Anbieters teilen. Die Abfolge:

Sie legen bei einem Cloud- oder SaaS-Anbieter eine Ressource an (einen Storage-Bucket, eine Plattform-App, eine Helpdesk- oder Landingpage-Site) und richten mit einem CNAME eine Subdomain darauf.
Später wird die Ressource gelöscht: Projekt beendet, Abonnement gekündigt, Konto geschlossen.
Der CNAME bleibt in der Zone. Niemand ist dafür zuständig, nichts erinnert daran. Das ist ein verwaister Eintrag (dangling record).
Der Anbieter gibt den alten Ressourcennamen wieder frei und prüft nicht, wer die Domain kontrolliert, die darauf zeigt.
Ein Angreifer registriert diesen Namen. Von diesem Moment an liefert Ihre Subdomain die Inhalte des Angreifers aus.

Ob Schritt 4 möglich ist, hängt vom Anbieter ab. Viele verlangen inzwischen einen TXT-Record zur Verifizierung oder reservieren freigegebene Namen, aber Sie kennen selten die Regeln jedes Dienstes, der je mit Ihrer Domain verbunden war.

Die Varianten

Verwaister Eintrag	Was der Angreifer braucht	Was er gewinnt
CNAME auf eine gelöschte Cloud-/SaaS-Ressource	Denselben Ressourcennamen beim Anbieter beanspruchen	Webinhalte auf der Subdomain
CNAME auf einen Host, dessen Domain abgelaufen ist	Diese Domain registrieren	Alles unter diesem CNAME-Ziel
NS-Delegation einer Subzone an einen DNS-Anbieter, bei dem die Zone gelöscht wurde, oder an Nameserver unter einer abgelaufenen Domain	Die Zone bei diesem Anbieter anlegen oder die Domain der Nameserver registrieren	Volle Kontrolle über die Subzone: jeder Record-Typ, jeder Name darunter. Der schlimmste Fall
A-Record auf eine freigegebene Cloud-IP-Adresse	Dieselbe IP-Adresse zugewiesen bekommen: eine Frage von Glück und Wiederholung	Webinhalte; eher opportunistisch als gezielt
MX-Record auf einen abgeschalteten E-Mail-Dienst	Die Domain bei diesem E-Mail-Dienst beanspruchen	Eingehende E-Mails der Subdomain

Warum es mehr bedeutet als eine verunstaltete Seite

Eine Subdomain Ihrer Domain erbt Vertrauen, das eine ähnlich aussehende Domain nie bekommt:

Phishing unter Ihrem echten Namen. login-help.example.com besteht jede Schulung nach dem Motto „prüfen Sie die Adressleiste“.
Cookies. Cookies, die mit Domain=example.com gesetzt wurden, schickt der Browser an jede Subdomain, auch an die, die der Angreifer jetzt betreibt. Je nach Flags können das Sitzungscookies sein.
Allowlists, die *.example.com vertrauen. CORS-Konfigurationen, Quellen in der Content Security Policy, OAuth-Redirect-URIs und Single-Sign-on-Einstellungen vertrauen häufig der ganzen Domain. Eine übernommene Subdomain steht innerhalb dieses Vertrauens.
Öffentlich vertrauenswürdige Zertifikate. Wer die Inhalte eines Hostnamens kontrolliert, kann die HTTP-basierte Domainvalidierung bestehen und ein gültiges Zertifikat dafür erhalten.
E-Mail. Bei einem verwaisten MX werden E-Mails an die Subdomain dem Angreifer zugestellt, einschließlich der Zurücksetzung von Passwörtern für Konten, die mit solchen Adressen registriert wurden.

Verwaiste Einträge finden

Beginnen Sie bei Ihrer Zone, nicht von außen (die Record-Typen erklärt der Beitrag DNS-Record-Typen). Exportieren Sie jede Zone, die Sie haben, und listen Sie die Einträge auf, deren Ziel nicht Ihre eigene Infrastruktur ist: CNAMEs auf andere Domains, NS-Delegationen, MX-Records sowie A/AAAA-Records in Adressbereichen von Cloud-Anbietern.

Dann testen Sie jeden einzelnen.

CNAMEs. Lösen Sie das Ziel auf. Ein Ziel, das nicht existiert, ist das deutlichste Zeichen:

$ dig +short CNAME shop.example.com
promo-example.cloudhost.example.

$ dig promo-example.cloudhost.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711

NXDOMAIN für das Ziel bedeutet, dass der Eintrag ins Leere zeigt. Löst das Ziel auf (viele Plattformen antworten per Wildcard auf jeden Namen), sehen Sie sich die HTTP-Antwort an:

$ curl -sI https://shop.example.com | head -n 1
HTTP/2 404

Die generische Seite eines Anbieters mit „no such site“, „no such bucket“ oder „hier gibt es noch nichts“ auf Ihrer Subdomain bedeutet, dass die Ressource dahinter verschwunden ist. Prüfen Sie außerdem, ob die Domain jedes CNAME-Ziels noch registriert ist und dem erwarteten Anbieter gehört.

NS-Delegationen. Fragen Sie jeden delegierten Nameserver direkt und ohne Rekursion, ob er für die Subzone autoritativ ist:

$ dig +short NS sub.example.com
ns1.dns-host.example.
ns2.dns-host.example.

$ dig @ns1.dns-host.example sub.example.com SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1289

REFUSED, SERVFAIL oder eine Antwort ohne das Flag aa bedeutet, dass dieser Server Ihre Zone nicht hält. Gar keine Antwort kann ein Netzwerkproblem sein: Wiederholen Sie den Test, bevor Sie Schlüsse ziehen.

Namen, die Sie vergessen haben. Der Zonenexport findet Einträge; er findet keine Zonen, von denen Sie vergessen haben, dass Sie sie besitzen, und keine Namen, die ein anderes Team bei einem anderen DNS-Anbieter angelegt hat. Hier helfen die Certificate-Transparency-Logs: Jedes öffentlich vertrauenswürdige Zertifikat wird protokolliert, also verraten sie Hostnamen, die irgendwann ein Zertifikat bekommen haben. Sie verraten auch Zertifikate, die Sie nicht beantragt haben, und das ist die Spur, die ein Takeover hinterlässt.

Vorbeugung

Reihenfolge der Schritte. Diese eine Regel verhindert die meisten Fälle:

Außerbetriebnahme: Zuerst den DNS-Eintrag entfernen, die TTL abwarten, dann die Ressource löschen.
Inbetriebnahme: Zuerst die Ressource anlegen und prüfen, den DNS-Eintrag zuletzt ergänzen.

Geben Sie Einträgen Verantwortliche. Führen Sie DNS-Änderungen über ein Review durch, idealerweise als Infrastructure as Code im selben Repository wie die Ressource, auf die sie zeigen, damit das Löschen der Ressource und das Löschen des Eintrags eine einzige Änderung sind.

Wählen Sie Anbieter, die Domains verifizieren. Ein Anbieter, der vor dem Ausliefern einer eigenen Domain einen TXT-Record zur Domainverifizierung verlangt, lässt sich von einem Fremden nicht für diesen Angriff nutzen.

Vermeiden Sie Wildcard-CNAMEs auf Dritte. *.example.com CNAME something.provider.example macht jeden denkbaren Namen zum Kandidaten.

Begrenzen Sie, was eine Subdomain darf. Verwenden Sie für Sitzungen Host-only-Cookies (ohne Domain-Attribut). Nennen Sie in CORS-, CSP- und OAuth-Redirect-Allowlists exakte Origins statt *.example.com.

Wissen Sie, was CAA leistet und was nicht. Ein CAA-Record schränkt ein, welche Zertifizierungsstellen für Ihre Namen ausstellen dürfen. Ein Takeover verhindert er nicht: Der Angreifer verwendet einfach eine CA, die Sie erlauben. Die sinnvolle Ergänzung ist die Überwachung von Certificate Transparency auf Zertifikate, die niemand auf Ihrer Seite beantragt hat. Einzelheiten in CAA-Records erklärt.

Checkliste

Alle Zonen bei allen DNS-Anbietern sind bekannt und exportiert.
Jeder CNAME-, NS-, MX- und Cloud-IP-A/AAAA-Record hat einen benannten Verantwortlichen und einen Zweck.
Jedes externe CNAME-Ziel löst auf, und seine Domain ist auf den erwarteten Anbieter registriert.
Jede delegierte Subzone wird von allen ihren Nameservern autoritativ beantwortet.
Das Verfahren zur Außerbetriebnahme lautet: erst der DNS-Eintrag, dann die Ressource.
Kein Wildcard-CNAME zeigt auf einen Dritten.
Sitzungscookies sind Host-only; Allowlists nennen exakte Hosts.
CT-Logs werden auf unbekannte Hostnamen und unerwartete Zertifikate durchgesehen.

Wenn Sie einen finden

Entfernen Sie den verwaisten Eintrag sofort (oder legen Sie, wenn der Dienst noch gebraucht wird, die Ressource zuerst im eigenen Konto neu an). Das Entfernen des Eintrags beendet die Exposition, sobald die Caches abgelaufen sind.
Finden Sie heraus, ob er bereits beansprucht wurde. Was liefert die Subdomain gerade aus?
Falls ja: Betrachten Sie Cookies, die auf die übergeordnete Domain gesetzt sind, als offengelegt, und machen Sie Sitzungen ungültig. Prüfen Sie Allowlists, die die Subdomain enthielten.
Sehen Sie die CT-Logs durch nach Zertifikaten, die während der Exposition für diesen Namen ausgestellt wurden, und bitten Sie die ausstellende CA, diejenigen zu widerrufen, die Sie nicht beantragt haben.
Beheben Sie den Prozess, der den Eintrag zurückgelassen hat, und prüfen Sie dann den Rest der Zone: Verwaiste Einträge kommen selten allein.

Ethik und Recht

Testen Sie nur Domains, für die Sie verantwortlich sind oder deren Prüfung Ihnen schriftlich erlaubt wurde. Öffentliches DNS abzufragen ist harmlos. Die Ressource hinter dem verwaisten Eintrag eines anderen zu beanspruchen ist eine andere Handlung: Sie würden Inhalte unter dessen Namen ausliefern und womöglich die Cookies oder E-Mails seiner Nutzer empfangen. Das ist unbefugter Zugriff, auch mit einer harmlosen „Beweis“-Seite und guten Absichten. Wenn Ihnen ein verwaister Eintrag auf einer fremden Domain auffällt, melden Sie ihn dem Inhaber über den Kontakt in dessen security.txt-Datei (der security.txt-Check zeigt, ob eine veröffentlicht ist), und belassen Sie es dabei.

Häufige Fehler

Zuerst die Cloud-Ressource löschen und „das DNS später aufräumen“.
Nur die Hauptzone prüfen und delegierte Subzonen vergessen.
*.example.com in CORS-, CSP- oder OAuth-Einstellungen vertrauen.
Glauben, ein CAA-Record verhindere Takeovers.

Mit OrbitProbe prüfen

Subdomains finden von OrbitProbe listet die Hostnamen unter einer Domain auf, die in öffentlichen Certificate-Transparency-Logs erscheinen, jeweils mit dem Datum des jüngsten Zertifikats. Das ist eine Aufzeichnung von Zertifikaten, nicht von DNS: Ein gelisteter Name existiert womöglich nicht mehr, und ein Name, der immer nur ein Wildcard-Zertifikat verwendet hat, fehlt. Das Werkzeug ergänzt den Zonenexport also, statt ihn zu ersetzen. Nutzen Sie es für Domains, für die Sie verantwortlich sind, um vergessene Hosts und Zertifikate zu entdecken, an deren Bestellung sich niemand erinnert, und prüfen Sie dann jeden unbekannten Namen mit einer DNS-Abfrage, um zu sehen, wohin er heute zeigt.