dns-rebinding-attacks

Über dns-rebinding-attacks

Ein Leitfaden zu DNS-Rebinding-Angriffen, der sich auf die clientseitige Technik konzentriert, mit der die Same-Origin-Richtlinie des Browsers umgangen wird, indem die IP-Adresse hinter einem Hostnamen geändert wird, den das Opfer bereits geladen hat. Der zentrale Aspekt dabei ist, dass die Same-Origin-Richtlinie die Hostnamen-Zeichenkette überprüft, nicht die aufgelöste IP-Adresse: Ein Angreifer, der den autoritativen DNS-Server für seine Domain kontrolliert, kann bei der ersten Auflösung (Angreifer-IP) bösartiges JavaScript ausliefern und anschließend denselben Hostnamen erneut auf eine interne IP-Adresse auflösen, sodass der Browser Anfragen an den internen Dienst als „Same-Origin“ behandelt und das Skript die Antworten auslesen kann.

Der Beitrag verdeutlicht den Unterschied zu SSRF, da DNS-Rebinding das clientseitige Gegenstück darstellt, und beschreibt die praktischen Hindernisse sowie mögliche Umgehungsstrategien. Da Browser einen eigenen DNS-Cache unterhalten, der kurze TTL-Werte ignoriert (etwa 60 Sekunden in Chrome, Edge und Firefox), werden Umgehungsstrategien dokumentiert, darunter das Abwarten, bis der Cache geleert ist, Antworten mit mehreren A-Einträgen und Blockierung der Angreifer-IP, um einen Fallback zu erzwingen, Subdomain-Flooding für neue Auflösungen sowie Verzögerungen durch Service Worker. Zu den Angriffsvarianten gehören klassisches HTTP-Rebinding, WebSocket-Rebinding, ein serverseitiger TOCTOU-Hybrid sowie der schnelle Ansatz mit mehreren A-Einträgen.

Verwenden Sie es beim Testen von Anwendungen, die bei Herkunftsprüfungen auf DNS vertrauen oder die clientseitige Fetch-/XHR-Aufrufe an vom Angreifer kontrollierte Domänen ausführen, insbesondere dort, wo serverseitiges SSRF nicht möglich ist. Eine Tabelle mit besonders wertvollen Zielen listet Cloud-Metadaten (169.254.169.254), die Docker- und Kubernetes-APIs, interne Admin-Panels, Elasticsearch, Redis sowie Consul/etcd auf; dabei wird darauf hingewiesen, dass die Token-Anforderung von IMDSv2 einem Rebinding widersteht, da benutzerdefinierte Header im No-CORS-Modus nicht ohne Weiteres gesetzt werden können. Zu den abgedeckten Tools gehören Singularity, der ohne Einrichtung nutzbare Dienst rbndr.us (mit einem Subdomain-Format im Hex-IP-Format), whonow sowie minimale Python-DNS-Server; außerdem werden Querverweise zu den Fähigkeiten im Bereich SSRF- und CORS-Konfigurationsfehler hergestellt.

FAQ

Inwiefern unterscheidet sich DNS-Rebinding von SSRF?

SSRF ist serverseitig, während DNS-Rebinding das clientseitige Pendant ist, das im Browser des Opfers ausgeführt wird. Es nutzt aus, dass die Same-Origin-Policy die Hostnamen-Zeichenkette überprüft und nicht die aufgelöste IP-Adresse.

Warum funktioniert eine TTL von 0 nicht sofort?

Browser verwalten ihren eigenen DNS-Cache, der niedrige TTL-Werte ignoriert (etwa 60 Sekunden in Chrome, Edge und Firefox), daher behandelt das Modul Umgehungsstrategien wie Warten, mehrere A-Einträge mit Fallback, Subdomain-Flooding und Service-Worker-Verzögerungen.

Was sind die besonders wertvollen internen Ziele?

Cloud-Metadaten unter 169.254.169.254, die Docker-API, die Kubernetes-API, interne Admin-Panels, Elasticsearch auf Port 9200, Redis auf Port 6379 sowie Consul/etcd.

Kann man durch „Rebinding“ AWS-Anmeldedaten aus IMDSv2 stehlen?

Nicht ohne Weiteres. IMDSv2 erfordert einen „X-aws-ec2-metadata-token“-Header in einer PUT-Anfrage, und beim Rebinding lassen sich im No-CORS-Modus bei der ersten Token-Anfrage nicht ohne Weiteres benutzerdefinierte Header setzen. IMDSv1 ist anfälliger.

Welche Tools werden empfohlen?

Singularity (ein vollständiges Framework), rbndr.us (ohne Konfiguration, unter Verwendung von Subdomains mit Hex-IP-Paaren), whonow (ein dynamischer Rebinding-Server) sowie minimale benutzerdefinierte Python-DNS-Server.