Domain/Subdomain-Übernahme

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Domain-Übernahme

Wenn Sie eine Domain (domain.tld) entdecken, die von einem Service innerhalb des Umfangs verwendet wird, das Unternehmen aber die Eigentümerschaft verloren hat, können Sie versuchen, sie zu registrieren (wenn es günstig genug ist) und das Unternehmen darüber informieren. Wenn diese Domain sensible Informationen wie ein Session-Cookie über einen GET-Parameter oder im Referer-Header erhält, ist das auf jeden Fall eine Sicherheitslücke.

Subdomain-Übernahme

Eine Subdomain des Unternehmens zeigt auf einen third-party service mit einem nicht registrierten Namen. Wenn Sie in diesem third party service ein Account erstellen und den Namen, der verwendet wird, registrieren können, ist eine Subdomain-Übernahme möglich.

Es gibt mehrere Tools mit Wortlisten, um mögliche Takeovers zu prüfen:

Generierung von Subdomain-Übernahmen durch DNS-Wildcard

Wenn in einer Domain eine DNS-Wildcard verwendet wird, werden beliebige angefragte Subdomains dieser Domain, die nicht explizit anders konfiguriert sind, auf dieselben Informationen aufgelöst. Das kann eine A-IP-Adresse, ein CNAME usw. sein.

Beispielsweise, wenn *.testing.com als Wildcard auf 1.1.1.1 gesetzt ist. Dann zeigt not-existent.testing.com auf 1.1.1.1.

Wenn der Admin jedoch statt auf eine IP-Adresse auf einen third party service via CNAME zeigt, wie z. B. eine GitHub subdomain (sohomdatta1.github.io), könnte ein Angreifer seine eigene Seite in diesem third party service (hier GitHub) erstellen und angeben, dass something.testing.com dorthin zeigt. Weil die CNAME-Wildcard das zulässt, kann der Angreifer beliebige Subdomains der Ziel-Domain erzeugen, die auf seine Seiten zeigen.

Ein Beispiel für diese Schwachstelle findet sich im CTF-Write-up: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Ausnutzung einer Subdomain-Übernahme

Subdomain-Übernahme ist im Grunde DNS-Spoofing für eine spezifische Domain im Internet; Angreifer können A-Records für eine Domain setzen, sodass Browser Inhalte vom Server des Angreifers anzeigen. Diese Browser-Transparenz macht Domains für Phishing anfällig. Angreifer können dafür typosquatting oder Doppelganger domains nutzen. Besonders gefährdet sind Domains, bei denen eine URL in einer Phishing-E-Mail legitim wirkt, Benutzer täuscht und Spam-Filter aufgrund des Vertrauens in die Domain umgeht.

Check this post for further details

SSL-Zertifikate

SSL-Zertifikate, wenn Angreifer sie über Dienste wie Let’s Encrypt erzeugen, erhöhen die Glaubwürdigkeit dieser gefälschten Domains und machen Phishing-Angriffe überzeugender.

Die Browser-Transparenz erstreckt sich auch auf Cookie-Sicherheit, geregelt durch Policies wie die Same-origin policy. Cookies, die häufig zur Sitzungsverwaltung und zum Speichern von Login-Tokens verwendet werden, können durch Subdomain-Übernahmen ausgenutzt werden. Angreifer können Session-Cookies sammeln, indem sie Benutzer einfach auf eine kompromittierte Subdomain lenken, was Benutzer-Daten und Privatsphäre gefährdet.

CORS-Bypass

Es kann sein, dass jeder Subdomain Zugriff auf CORS-Ressourcen der Hauptdomain oder anderer Subdomains erlaubt ist. Das könnte ein Angreifer ausnutzen, um sensible Informationen über CORS-Requests zu erlangen.

CSRF – Same-Site-Cookies-Bypass

Es kann vorkommen, dass die Subdomain berechtigt ist, Cookies an die Domain oder andere Subdomains zu senden, was eigentlich durch das Same-Site-Attribut der Cookies verhindert werden sollte. Beachten Sie jedoch, dass anti-CSRF-Tokens diesen Angriff weiterhin verhindern, wenn sie korrekt implementiert sind.

OAuth-Token-Weiterleitung

Es kann möglich sein, dass die kompromittierte Subdomain in der redirect_uri-URL eines OAuth-Flows verwendet werden darf. Das könnte ein Angreifer ausnutzen, um den OAuth-Token zu stehlen.

CSP-Bypass

Es kann sein, dass die kompromittierte Subdomain (oder jede Subdomain) z. B. für das script-src der CSP verwendet werden darf. Das könnte ein Angreifer ausnutzen, um bösartige Skripte einzuschleusen und potenzielle XSS-Schwachstellen auszunutzen.

E-Mails und Subdomain-Übernahme

Ein weiterer Aspekt der Subdomain-Übernahme betrifft E-Mail-Dienste. Angreifer können MX-Records manipulieren, um E-Mails einer legitimen Subdomain zu empfangen oder zu versenden, was Phishing-Angriffe noch wirkungsvoller macht.

Weitergehende Risiken

Weitere Risiken beinhalten die NS-Record-Übernahme. Wenn ein Angreifer Kontrolle über einen NS-Record einer Domain erlangt, kann er potenziell einen Teil des Traffics auf einen von ihm kontrollierten Server umleiten. Dieses Risiko wird verstärkt, wenn der Angreifer eine hohe TTL (Time to Live) für DNS-Einträge setzt und so die Dauer des Angriffs verlängert.

CNAME-Record-Schwachstelle

Angreifer könnten unbeanspruchte CNAME-Records ausnutzen, die auf externe Services zeigen, die nicht mehr genutzt oder abgebaut wurden. Dadurch können sie eine Seite unter der vertrauenswürdigen Domain erstellen und Phishing oder Malware-Verbreitung erleichtern.

Gegenmaßnahmen

Gegenmaßnahmen beinhalten:

  1. Entfernen verwundbarer DNS-Einträge - Das ist wirksam, wenn die Subdomain nicht mehr benötigt wird.
  2. Den Domainnamen beanspruchen - Die Ressource beim jeweiligen Cloud-Provider registrieren oder eine abgelaufene Domain zurückkaufen.
  3. Regelmäßiges Monitoring auf Schwachstellen - Tools wie aquatone können helfen, anfällige Domains zu identifizieren. Organisationen sollten außerdem ihre Infrastruktur-Management-Prozesse überarbeiten und sicherstellen, dass die DNS-Erstellung der letzte Schritt bei der Ressourcenerstellung und der erste Schritt bei der Ressourcendestruktion ist.

Für Cloud-Provider ist die Verifizierung der Domain-Eigentümerschaft entscheidend, um Subdomain-Übernahmen zu verhindern. Einige Provider, wie GitLab, haben dieses Problem erkannt und Domain-Validierungsmechanismen implementiert.

Erkennungstechniken

  • Finde dangling DNS-Einträge: Suche nach CNAME/A/AAAA/ALIAS/ANAME-Records, die auf nicht existierende Ressourcen zeigen (gelöschte Buckets, Apps, Pages, Load Balancer).
  • Prüfe Provider-Fehlersignaturen: Vergleiche HTTP-Antworten, TLS-Zertifikate oder DNS-Fehler mit bekannten Takeover-Mustern (siehe can-i-take-over-xyz).
  • Suche verwaiste Cloud-Assets: Überprüfe S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian und ähnliche Services.
  • Passive DNS und historische Records: Alte CNAMEs offenbaren oft zuvor genutzte third-party-Services, die noch anfällig sein könnten.
  • Wildcard-Fallen: Bestätige Wildcard-DNS vs. explizite Records, um False Positives zu vermeiden und die Verstärkung eines Takeovers zu verstehen.

APIs und Datenquellen

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks