dns-rebinding-attacks

About dns-rebinding-attacks

A DNS rebinding attack playbook focused on the client-side technique for bypassing the browser same-origin policy by changing the IP behind a hostname the victim has already loaded. The central insight is that the same-origin policy checks the hostname string, not the resolved IP: an attacker who controls authoritative DNS for their domain can serve malicious JavaScript on the first resolution (attacker IP) and then re-resolve the same hostname to an internal IP, so the browser treats requests to the internal service as same-origin and the script can read the responses.

It clarifies the distinction from SSRF, since DNS rebinding is the client-side counterpart, and details the practical obstacles and workarounds. Because browsers keep their own DNS cache that ignores low TTLs (roughly 60 seconds in Chrome, Edge, and Firefox), it documents bypass strategies including waiting out the cache, multiple-A-record responses with attacker-IP blocking to force fallback, subdomain flooding for fresh resolutions, and service-worker delays. Attack variants include classic HTTP rebinding, WebSocket rebinding, a server-side TOCTOU hybrid, and the fast multiple-A-records approach.

Use it when testing applications that trust DNS for origin checks or that make client-side fetch/XHR to attacker-controlled domains, particularly where server-side SSRF is not possible. A high-value target table lists cloud metadata (169.254.169.254), the Docker and Kubernetes APIs, internal admin panels, Elasticsearch, Redis, and Consul/etcd, with a note that IMDSv2's token requirement resists rebinding because custom headers cannot easily be set in no-cors mode. Tooling coverage includes Singularity, the zero-setup rbndr.us service (with a hex-IP subdomain format), whonow, and minimal Python DNS servers, and it cross-references the SSRF and CORS misconfiguration skills.

FAQ

How is DNS rebinding different from SSRF?

SSRF is server-side, while DNS rebinding is the client-side counterpart that runs in the victim's browser. It abuses that the same-origin policy checks the hostname string, not the resolved IP.

Why doesn't a TTL of 0 immediately work?

Browsers maintain their own DNS cache that ignores low TTLs (around 60 seconds in Chrome, Edge, and Firefox), so the skill covers bypasses like waiting, multiple A records with fallback, subdomain flooding, and service-worker delays.

What are the high-value internal targets?

Cloud metadata at 169.254.169.254, the Docker API, the Kubernetes API, internal admin panels, Elasticsearch on 9200, Redis on 6379, and Consul/etcd.

Can rebinding steal AWS credentials from IMDSv2?

Not easily. IMDSv2 requires an X-aws-ec2-metadata-token header from a PUT request, and rebinding cannot easily set custom headers on the initial token request in no-cors mode. IMDSv1 is more exposed.

What tools does it recommend?

Singularity (a full framework), rbndr.us (zero-setup, using hex-IP-pair subdomains), whonow (a dynamic rebinding server), and minimal custom Python DNS servers.