Subdomain-Übernahme: Wie ein vergessener DNS-Eintrag zur Website eines Fremden wird

Eine Subdomain-Übernahme (Subdomain Takeover) passiert, wenn ein DNS-Eintrag Ihrer Domain noch auf einen externen Dienst zeigt, den Sie nicht mehr nutzen. Erlaubt dieser Dienst jedem, den zurückgelassenen Namen zu beanspruchen, kann ein Fremder ihn registrieren und eigene Inhalte auf promo.yourcompany.com ausliefern. Besucher sehen Ihre Domain in der Adressleiste und haben keinen Grund, an der Seite zu zweifeln.

Die Ursache ist fast immer dieselbe: ein sogenannter „Dangling DNS“-Eintrag, also ein verwaister Eintrag. Jemand hat eine Kampagnenseite, ein Hilfecenter oder eine Test-App auf einer Cloud-Plattform gestartet, eine Subdomain darauf zeigen lassen und später die App gelöscht, den DNS-Eintrag aber nicht. Microsoft beschreibt genau diesen Ablauf für Azure, und dasselbe Muster gilt für viele Hosting-, Speicher- und SaaS-Plattformen.

Die gute Nachricht: Das ist ein Problem der Buchführung, und Sie können es mit wenigen DNS-Abfragen selbst prüfen.

Wie aus einem verwaisten Eintrag eine Übernahme wird

Das Problem durchläuft üblicherweise 3 Schritte:

1. Anlegen. Ein Team erstellt yourcompany-promo.azurewebsites.net (oder einen Bucket, eine Pages-Seite, einen CDN-Endpunkt) und fügt einen CNAME hinzu, damit promo.yourcompany.com darauf zeigt.
2. Abbauen. Die Kampagne endet, die App wird gelöscht, aber niemand entfernt den CNAME. Die Subdomain zeigt jetzt auf einen Namen, der Ihnen nicht mehr gehört.
3. Übernahme. Jemand bemerkt den verwaisten Namen, legt auf derselben Plattform eine Ressource mit demselben Namen an und kontrolliert ab diesem Moment, was promo.yourcompany.com anzeigt.

Nicht jede Plattform lässt den letzten Schritt zu. Das Community-Projekt can-i-take-over-xyz führt eine Liste von Diensten, markiert die anfälligen und hält den Fehlertext fest, den jeder bei einem nicht beanspruchten Namen anzeigt, zum Beispiel „The specified bucket does not exist“ bei Amazon S3.

Warum das mehr ist als eine verunstaltete Seite

Eine übernommene Subdomain ist nicht nur eine peinliche Seite. Laut Microsofts Leitfaden gehören zu den Risiken:

• Diebstahl von Cookies. Viele Webanwendungen setzen Session-Cookies für *.yourcompany.com, sodass jede Subdomain sie lesen kann.
• Ein gültiges Zertifikat für den Angreifer. Wer die Subdomain kontrolliert, kann dafür ein TLS-Zertifikat erhalten, also erscheint auch das Schloss-Symbol.
• Überzeugendes Phishing. Eine Login-Seite auf Ihrer echten Domain ist viel schwerer zu erkennen als eine auf einer Lookalike-Domain.
• Abfangen von E-Mails. Ein verwaister MX-Eintrag kann es jemandem ermöglichen, E-Mails an diese Subdomain zu empfangen.

Der OWASP Web Security Testing Guide ergänzt die gravierendste Variante: einen NS-Eintrag, der eine Subdomain an Nameserver auf einer Domain delegiert, die nicht mehr registriert ist. Wer diese Domain registriert, kontrolliert die gesamte delegierte Zone.

So prüfen Sie Ihr eigenes DNS

Beginnen Sie mit einer Liste aller Ihrer Subdomains. Der Zonenexport Ihres DNS-Anbieters ist die beste Quelle. Die Zertifikatshistorie ist eine nützliche zweite Quelle, weil fast jedes für Ihre Namen ausgestellte Zertifikat in den Certificate-Transparency-Logs verzeichnet ist.

Sehen Sie sich für jede Subdomain an, wohin sie zeigt:

dig +short CNAME promo.yourcompany.com
dig +short NS dev.yourcompany.com
dig +short MX shop.yourcompany.com

Prüfen Sie dann, ob jedes Ziel noch existiert und noch Ihnen gehört:

dig promo.yourcompany.com
curl -sI https://promo.yourcompany.com

Warnzeichen:

• das CNAME-Ziel liefert NXDOMAIN (der Name existiert nicht mehr),
• die Seite zeigt einen Plattformfehler wie „No such app“, „Repository not found“ oder „There isn't a GitHub Pages site here“,
• ein NS-Eintrag zeigt auf Nameserver einer Domain, die Sie nicht kennen oder die abgelaufen ist,
• niemand im Unternehmen kann sagen, wofür die Subdomain gedacht war.

Testen Sie nur Namen auf Ihrer eigenen Domain. Versuchen Sie nicht, eine Ressource zu beanspruchen, um das Problem zu „beweisen“. Den Eintrag zu entfernen reicht.

So beheben Sie es

1. Löschen Sie den verwaisten Eintrag aus Ihrer DNS-Zone. Das ist die Lösung sowohl im Leitfaden von Microsoft als auch bei OWASP.
2. Wenn die Subdomain noch gebraucht wird, legen Sie die Ressource unter Ihrem eigenen Konto neu an, bevor Sie wieder Verkehr darauf leiten.
3. Prüfen Sie, ob etwas passiert ist, solange der Eintrag verwaist war: ungewöhnliche Zertifikate für diesen Namen, Links in Ihrer App oder in E-Mails, die ihn noch verwenden, OAuth-Redirect-URLs, die ihn enthalten.
4. Nutzen Sie die Eigentümerverifizierung, wo die Plattform sie anbietet. Azure App Service etwa unterstützt einen TXT-Eintrag asuid.<subdomain>, damit kein anderes Abonnement die benutzerdefinierte Domain validieren kann.
5. Korrigieren Sie den Prozess, nicht nur den Eintrag. Nehmen Sie „DNS-Eintrag entfernen“ in die Checkliste für das Abschalten jedes Dienstes auf, und führen Sie ein einfaches Inventar, welche Subdomain auf welche Plattform zeigt und wer dafür zuständig ist.

Kurze Checkliste

• Exportieren Sie Ihre DNS-Zone und listen Sie alle CNAME-, NS- und MX-Einträge auf.
• Bestätigen Sie für jeden Eintrag, dass das Ziel existiert und Ihrem Unternehmen gehört.
• Entfernen Sie Einträge für abgeschaltete Dienste.
• Vergleichen Sie Ihre Zone mit den Namen in den Certificate-Transparency-Logs, um Subdomains zu finden, die niemand dokumentiert hat.
• Prüfen Sie erneut, wann immer eine Kampagne, ein Produkt oder ein Dienstleister endet.

Verwaiste Einträge liegen oft neben anderen vergessenen Teilen, etwa alten Staging- und Testservern. Beides gleichzeitig aufzuräumen ist meist der schnellste Gewinn.

Wo Datahorses ins Spiel kommt

Datahorses überwacht Ihr Unternehmen jeden Tag von außen: Es erstellt die Liste Ihrer Subdomains, prüft, wohin jeder CNAME zeigt, und markiert Einträge, die zu nicht mehr existierenden Diensten führen. Wir greifen nicht auf Ihre Systeme zu und benötigen keinen Zugang, und jeder Fund kommt mit den genauen Schritten für Ihren Entwickler. Sehen Sie sich die vollständige Liste dessen an, was wir überwachen, oder das Beispiel-Dashboard.