Dangling CNAMEs und Subdomain-Takeover: die DNS-Gespenster alter Magento-Shops

Ein Händler zieht von Hypernode zu einem neuen Hosting-Vendor um. Der Umzug dauert ein Wochenende. Die Agentur des Händlers ändert den A-Record auf der Apex-Domain, bestätigt, dass der Shop läuft, schließt das Ticket. Sechs Monate später fährt ein Angreifer amass oder einen Subdomain-Enumeration-Scanner gegen die Zone des Händlers, findet eine staging.merchantstore.com, die weiterhin auf merchantstore.hypernode.io zeigt, meldet sich für einen kostenlosen Hypernode-Account an, beansprucht den Hostnamen und serviert eigene Inhalte darauf. Nichts Exotisches passiert. Der Angreifer hat keine Sicherheitsgrenze durchbrochen. DNS und Cloud-Vendor haben genau das getan, was ihnen gesagt wurde.

Das ist Subdomain-Takeover. Magento-Shops holen ihn sich überproportional oft ein, weil Magento-Hosting-Vendoren dieselben CNAME-Muster nutzen: yourstore.hypernode.io, yourstore.hipex-cloud.com, eine Cloudways-Variante. Beim Umzug werden A- und MX-Records auf der Apex aktualisiert. Die Subdomain-CNAMEs meistens nicht.

Deine Domain hat eine DNS-Zone mit Einträgen. Ein paar davon sind CNAME-Einträge: staging.merchantstore.com zeigt auf merchantstore.hypernode.io, zum Beispiel. Das CNAME-Ziel ist ein Hostname, der von einem Cloud-Vendor verwaltet wird. Der Cloud-Vendor besitzt TLS, Routing und Inhalt für diesen Hostnamen, in deinem Namen, solange dein Account dort aktiv ist.

Wenn du den Vendor verlässt, deaktiviert er deinen Hostnamen. Das CNAME in deinem DNS zeigt weiterhin darauf. Jeder kann sich jetzt beim selben Vendor anmelden, denselben Hostnamen beanspruchen (sofern der Vendor das zulässt, und die meisten tun es), und sein Inhalt wird auf deiner Subdomain ausgeliefert. Die Browser-Trust-Kette behandelt das als deine Seite: gleiche Apex-Domain, gleiches DNS-verifiziertes CNAME-Ziel, gültiges TLS-Zertifikat aus dem Wildcard oder der Aussteller-Kette des Vendors. Cookies, die auf .merchantstore.com gescoped sind, lassen sich lesen. HSTS mit includeSubDomains schenkt dem Angreifer kostenloses TLS.

Das ist kein Hack im Hollywood-Sinn. Das ist ein Vendor-Management-Problem, das sich als Sicherheitsproblem ausdrückt. Der Fix ist ebenfalls Vendor-Management: DNS beim Verlassen aufräumen.

Drei Dinge wirken zusammen.

Magento-spezialisiertes Hosting nutzt vorhersagbare CNAMEs. Hypernodes yourstore.hypernode.io, Hipex' yourstore.hipex-cloud.com, Cloudways in mehreren Varianten. Einfach aufzuzählen. Ein Subdomain-Scanner auf der Suche nach Takeover-Zielen muss nicht clever sein; er läuft einfach jedes große Magento-Vendor-Hostname-Pattern gegen deine Zone.

Umzüge sind Wochenendarbeit. Sie laufen unter Zeitdruck, mit kleinem Team, und Erfolg misst sich daran, dass „der Shop läuft und Bestellungen nimmt". Niemandes DNS-Audit-Aufgabe kommt im Migrations-Sprint aus dem Backlog; sie kommt sechs Monate später aus dem Backlog, nachdem ein Security-Audit sie findet.

Magento-Shops haben meistens viele Subdomains. checkout., images., cdn., ftp., mail., stage., dev., preview., m., www2., plus die Marketing-Subdomains, die der CMO vor zwei Agenturen aufgesetzt hat. Jede davon ist ein DNS-Eintrag. Jede davon ein potenzielles Takeover-Ziel. Der Umzug aktualisiert die Apex; der lange Schwanz der Subdomains ist, wo die Übersehen lauern.

Der Audit ist drei Schritte, lauffähig in jeder Shell mit dig und curl.

Schritt 1: jede Subdomain in deiner Zone aufzählen.

Dein DNS-Vendor (Cloudflare, Route 53, Gandi, wer auch immer) hat einen Export-Button. Nutze ihn. Rohe Zone-Datei ziehen und A- und CNAME-Records extrahieren. Wenn der Export nicht da ist (oder die Zone irgendwo handgeführt wird), kombiniere das mit einem externen Subdomain-Scan (amass, subfinder, crt.sh-Lookup gegen deine Certificate-Transparency-Logs), um Subdomains zu erwischen, an die du nicht mehr gedacht hattest. Der Certificate-Transparency-Lookup ist kostenlos und findet üblicherweise Einträge, die der interne Zone-Dump übersieht.

Schritt 2: jedes CNAME-Ziel per dig prüfen und klassifizieren.

1# Beispiel: dig jede Subdomain aus einer Datei von Hostnamen im Bulk.
2while read sub; do
3  target=$(dig +short CNAME "$sub" | sed 's/\.$//')
4  echo "$sub -> ${target:-A-RECORD}"
5done < subdomains.txt

Achte auf CNAMEs, die auf Magento-spezialisierte Hosting-Vendors zeigen (*.hypernode.io, *.hipex-cloud.com, *.cloudways.com, *.sonassi.net) oder auf generische Cloud-Vendors, bei denen du keinen aktiven Account mehr hast (*.herokuapp.com, *.s3.amazonaws.com, *.azurewebsites.net, *.github.io). Flagge außerdem jedes CNAME, dessen Zieldomain du nicht unmittelbar zuordnen kannst.

Schritt 3: jedes Ziel per curl abfragen und auf Takeover-Signaturen prüfen.

1# Der „wird der Hostname dieses Cloud-Vendors gerade von jemand anderem bedient?"-Check.
2curl -sI "https://yourstore.hypernode.io" | head -5
3curl -sI "https://old.yourstore.com" | head -5

Jeder Cloud-Vendor hat eine unverwechselbare Fehlerseite, wenn ein Hostname nicht beansprucht ist. Hypernode zum Beispiel liefert eine konkret gebrandete „not found"-Seite. GitHub Pages liefert „There isn't a GitHub Pages site here." Heroku liefert die „No such app"-Seite. Das GitHub-gepflegte Repo can-i-take-over-xyz ist der kanonische Katalog der Takeover-Signaturen pro Vendor; konsultiere es, bevor du auf ein Finding handelst.

Jedes CNAME, dessen Ziel eine Unclaimed-Hostname-Response des Vendors zurückgibt, ist ein Takeover-Risiko. Jedes CNAME, dessen Ziel NXDOMAIN liefert, ist ebenfalls ein Risiko (der Angreifer muss nur den Namen beanspruchen).

Wenn du schon in der Zone bist, prüfe auch auf TXT-Records mit Namen wie __backup__, _old_ip, origin_ip oder jede Variante, die aussieht, als hätte sich ein Entwickler eine Notiz über die historische Origin hinterlassen. Die werden meist während eines Umzugs zum Rollback-Komfort ergänzt und nie entfernt.

Das Problem: ein Angreifer, der Aufklärung gegen deine Zone fährt, erntet diese TXT-Records und kennt jetzt deine echte Origin-IP. Wenn du hinter Cloudflare sitzt, ist Cloudflares ganzer Sinn, die Origin-IP zu verstecken, damit Angriffe durch das CDN müssen. Ein TXT-Record, der die Origin direkt veröffentlicht, hebt das auf. Der Angreifer kann dann die Origin auf Port 443 und 80 direkt probieren, ohne Cloudflare zu passieren, und deine WAF, deine Rate-Limits, deine Firewall-Regeln, alles davon umgehen.

Diese Records sind leicht zu finden und sollten auf Sicht gelöscht werden. Wenn ein Team historische Infrastruktur zum Rollback behalten muss, gehört diese Info in ein Runbook, nicht in eine öffentliche DNS-Zone.

Drei Schritte, in dieser Reihenfolge.

Erstens: DNS-Eintrag entfernen. Das ist die Aktion mit dem niedrigsten Risiko und dem höchsten Impact. Die Subdomain zeigt auf nichts mehr; das Takeover-Fenster schließt sich sofort. Alles andere ist Aufräumen. Wenn du nervös bist, einen Record zu entfernen („falls doch jemand die Subdomain genutzt hat"), greppe die Codebase, Cloudflare-Logs und Analytics nach Traffic auf die Subdomain der letzten 90 Tage. Wenn nichts da ist, kann sie weg.

Zweitens: entscheiden, ob du den Hostnamen zurückholst. Wenn du die Subdomain bald wieder nutzt, hole den Cloud-Vendor-Hostnamen für dich zurück. Wenn nicht, lass es; eine tote Subdomain zurückzuholen startet nur eine Abrechnungsbeziehung, die du vergessen wirst, und erzeugt in zwei Jahren dasselbe Problem.

Drittens: Zonen-Monitoring aufsetzen. Es gibt Hosted-Services (DNSDumpster-Alerting, Detectify, selbstgebaute Skripte), die deine Subdomains auf einem Zeitplan erneut aufzählen und bei neuen CNAME-Zielen oder NXDOMAIN-Antworten alarmieren. Einen davon budgetieren, einmal konfigurieren, laufen lassen. Wenn der nächste Entwickler eine Subdomain für ein zweiwöchiges Projekt hochzieht, weißt du davon.

1. 01

   Die volle DNS-Zone exportieren

   Jeden A-, AAAA-, CNAME- und TXT-Record aus dem Zone-Editor deines DNS-Vendors dumpen. Eine Kopie im Source-Control neben Infra-as-Code halten. Die Zone sollte nie größer sein, als du in einem Sitzen lesen kannst.

2. 02

   Über die Zone hinaus aufzählen

   amass, subfinder oder einen crt.sh-Lookup fahren, um Subdomains zu finden, die in Certificate-Transparency-Logs auftauchen, aber nicht in deinem Zone-Dump. Legacy-Subdomains, von denen migriert wurde, haben oft noch alte Zertifikate und tauchen hier auf.

3. 03

   Jedes CNAME-Ziel digen und klassifizieren

   Jedes CNAME, dessen Zieldomain gerade nicht deinen Inhalt hostet, ist ein Audit-Kandidat. Magento-spezialisierte Hosts (Hypernode, Hipex, Cloudways, Sonassi) zuerst markieren, dann generische Clouds (Heroku, S3, Azure, GitHub Pages).

4. 04

   Jedes Ziel curlen und auf Vendor-Takeover-Signaturen prüfen

   Die Antwort mit dem can-i-take-over-xyz-Katalog abgleichen. Ein Unclaimed-Hostname-Banner vom Vendor ist ein unmittelbares Takeover-Risiko. NXDOMAIN-Ziele sind ebenfalls gefährdet, Priorität leicht niedriger.

5. 05

   Zuerst löschen, später entscheiden

   Ein Dangling-CNAME zu entfernen schließt das Takeover-Fenster. Reclaim-vs-tot-lassen entscheidest du, nachdem der Record aus DNS draußen ist, nicht vorher.

6. 06

   __backup__- und origin_ip-TXT-Records löschen

   Die Zone nach TXT-Records greppen, deren Name oder Wert wie Dokumentation historischer Infrastruktur aussieht. Jedes davon ist ein Cloudflare-Bypass-Geschenk an jeden, der deine Zone aufzählt.

7. 07

   Laufendes Zonen-Monitoring aufsetzen

   DNSDumpster-Alerting, Detectify oder ein selbstgebauter Cron, der deine Zone erneut dumpt und gegen Source-Control diffed. Alerts auf neue CNAME-Ziele oder geänderte TXT-Records landen im selben Kanal wie andere Security-Alerts.

8. 08

   Nach jedem Hosting-Umzug den Audit fahren

   Das gesamte Finding-Set dieses Artikels entsteht durch Hosting-Änderungen. Einen verpflichtenden DNS-Audit in jedes Migrations-Runbook aufnehmen, terminiert eine Woche nach Abschluss der Migration.