DNS rebinding (simulated)

Why This Matters

DNS rebinding has been a known attack technique since Dan Kaminsky described it in 2008, and it has seen a significant resurgence in the context of cloud SSRF and smart-home device exploitation. In 2018, researchers from Armis demonstrated that DNS rebinding could be used to attack smart speakers (Google Home, Sonos) accessible from a browser on the same LAN, extracting WiFi credentials. In 2019, a proof-of-concept showed DNS rebinding against internal Kubernetes dashboard APIs from a browser. For CTF and assessment contexts, simulated DNS rebinding (using controlled DNS infrastructure without real TTL manipulation) demonstrates the same-origin policy bypass concept and is directly applicable to SSRF scenarios where server-side re-resolution creates a race window. OWASP notes DNS rebinding under SSRF (A10:2021) as a technique that bypasses IP-based validation because the validation step and the connection step see different IP addresses.

Core Concept

DNS rebinding exploits the fact that most security boundaries are enforced at the time of a domain name lookup, but the actual network connection is made subsequently — potentially after the DNS record has changed. The attack has two phases separated by a TTL expiry.

Phase 1 — Initial resolution: the attacker controls a DNS server for attacker.com. The attacker configures a DNS A record with a very low TTL (1 second or less). When the victim's browser (or the server) first resolves attacker.com, the DNS server returns a legitimate public IP (the attacker's own server). All security checks that run at resolution time — IP blocklists, firewall rules, CORS checks — see the legitimate public IP and permit the connection.

Phase 2 — Rebinding: the TTL expires. On the next DNS query for attacker.com, the attacker's DNS server returns 127.0.0.1 (or any internal IP). The browser's same-origin policy still considers attacker.com the same origin because the hostname has not changed, only the IP behind it. JavaScript on the attacker's page can now issue fetch('http://attacker.com/api/data') which resolves to 127.0.0.1 — the browser makes a same-origin request to localhost, and the response is accessible to the script.

Server-side DNS rebinding in SSRF works analogously: an application validates a webhook URL by resolving the hostname and checking the IP against a blocklist. If the hostname is resolved and checked at validation time but re-resolved at connection time, and the attacker's DNS server returns a different IP on the second query, the SSRF filter is bypassed. This is called a time-of-check/time-of-use (TOCTOU) race in the DNS resolution.

Key distinction from standard SSRF filter bypass: standard SSRF bypass uses alternative encodings of a prohibited IP address in the URL. DNS rebinding uses a legitimate public IP initially, then changes the DNS answer between check and connection — it does not require any IP encoding tricks.

Browser protections: Chrome's Private Network Access (PNA) specification (implemented from Chrome 94) adds a preflight check for requests from public to private network addresses, mitigating browser-side DNS rebinding. DNS pinning (caching the resolved IP for the lifetime of the page) prevents re-resolution within a session. Both protections apply to browser-side attacks; server-side SSRF TOCTOU is not mitigated by browser protections.

Simulated lab setup: in a CTF or lab context, DNS rebinding is simulated by configuring an authoritative DNS server (e.g., using dnsmasq or the 1u.ms service) to return different IP addresses for sequential queries to the same hostname, enabling demonstration of the TOCTOU window without requiring actual low-TTL infrastructure.

Technical Deep-Dive

DNS Rebinding Attack Sequence:

Time T+0 (Attacker registers webhook):
  Application resolves attacker.com → 203.0.113.42 (attacker public IP)
  IP check: 203.0.113.42 is NOT in blocklist → webhook accepted

Time T+1 (TTL = 1 second expires):
  Attacker DNS server is configured to return 127.0.0.1 on next query

Time T+2 (Application fires webhook event):
  Application re-resolves attacker.com → 127.0.0.1 (now returns internal)
  Application sends HTTP POST to 127.0.0.1 (internal target)
  → SSRF achieved despite IP blocklist check at registration time

Server-side TOCTOU race window:
  validate_url(webhook_url)    ← DNS resolves to public IP; check passes
  ... (time passes) ...
  send_request(webhook_url)    ← DNS resolves to 127.0.0.1; SSRF fires

# Simulated DNS rebinding demonstration using 1u.ms wildcard service
# The 1u.ms service provides subdomains that resolve to user-specified IPs
# Useful for simulating the rebinding outcome without controlling real DNS

# Hostname that resolves directly to 127.0.0.1:
simulated_rebind_host = "http://127.0.0.1.1u.ms/"
# If the application resolves this and then connects, it reaches localhost

# In a real rebinding attack, the hostname would initially resolve to a public IP
# and later resolve to 127.0.0.1 after TTL expiry — 1u.ms skips directly to the
# rebinding outcome for testing purposes

# Test webhook with 1u.ms hostname:
import requests
r = requests.put(
    "https://target.example.com/api/webhooks/42",
    json={"url": simulated_rebind_host},
    headers={"Authorization": "Bearer <attacker_token>"}
)
# Then trigger the webhook and observe whether localhost is reached

# Setting up a minimal DNS rebinding server with dnsmasq (lab environment)
# Phase 1: serve public IP for first query
# Phase 2: serve 127.0.0.1 for all subsequent queries

# Install dnsmasq; create rebind config:
# /etc/dnsmasq.d/rebind.conf:
# address=/rebind.attacker.com/203.0.113.42   # first resolution (public IP)
# After TTL, update to:
# address=/rebind.attacker.com/127.0.0.1       # rebind target

# For a single-file simulation, use Singularity (DNS rebinding toolkit):
# https://github.com/nccgroup/singularity
# Singularity provides a manager + DNS server that automates the rebinding cycle

# Start Singularity:
# docker run --rm -p 8080:8080 -p 53:53/udp nccgroup/singularity
# Navigate to http://singularity.me:8080/attackerui
# Configure rebind: fromIP = attacker public IP, toIP = 127.0.0.1

Security Assessment Methodology

1. Confirm SSRF with standard techniques first — DNS rebinding is an advanced bypass. Always confirm whether simpler SSRF techniques (direct IP, open redirects, IP encoding) work before attempting rebinding.
2. Identify TOCTOU window — Determine whether the application resolves the hostname twice: once at URL validation/registration time and once at actual request time. Review application flow and documentation for async webhook delivery.
3. Use 1u.ms for simulated rebinding — Register a webhook URL using a 1u.ms hostname that resolves to 127.0.0.1 directly (http://127.0.0.1.1u.ms/). This simulates the rebinding outcome and tests whether the application re-resolves at delivery time.
4. Test with Singularity in a lab environment — Set up Singularity to perform true DNS rebinding. Configure a webhook URL to attacker.com (resolves to attacker server initially). After TTL, Singularity serves 127.0.0.1. Trigger the webhook event and monitor whether the internal address is reached.
5. Measure TTL compliance — Check whether the application's HTTP client respects DNS TTL or uses DNS pinning (caches the IP indefinitely). If the client re-resolves, the TOCTOU window is open.
6. Probe internal services — Once rebinding is confirmed, probe common internal services via the webhook URL: Redis (6379), internal APIs (8080, 9200), IMDS (169.254.169.254).
7. Document the validation-connection gap — Report the exact code path showing that DNS resolution at validation time differs from DNS resolution at connection time as the root cause.

Defensive Countermeasure — Resolve the hostname to an IP address exactly once at request time — immediately before opening the TCP connection — and perform the IP blocklist check against that resolved IP (not a previously cached result). This eliminates the TOCTOU window. Use a DNS-aware SSRF protection library (e.g., ssrf_filter in Python, SafeCurl in PHP) that resolves and checks the IP atomically within a single function call. Alternatively, use a dedicated outbound proxy (Squid, Envoy) with an IP-based access control list for all webhook delivery traffic, so the proxy enforces the blocklist regardless of application-layer validation.

Common Assessment Errors

• Testing DNS rebinding before confirming basic SSRF — DNS rebinding is complex to set up; simpler bypass techniques are far more common. Always exhaust simpler vectors first.
• Confusing DNS rebinding with URL confusion — URL confusion (http://[email protected]/) is a URL parser trick that works in a single request; DNS rebinding requires DNS TTL expiry between validation and connection — these are distinct mechanisms.
• Not accounting for DNS caching — If the application's DNS resolver caches the initial resolution and does not re-resolve within the webhook delivery window, rebinding will not work. Verify TTL compliance before concluding the attack is feasible.
• Missing browser vs server-side distinction — Browser-side DNS rebinding bypasses the browser's Same-Origin Policy; server-side DNS rebinding bypasses SSRF IP filters. Both are called DNS rebinding but have different prerequisites and impacts.
• Overlooking Chrome PNA — Reports claiming that browser-side DNS rebinding affects users on modern Chrome (94+) may be inaccurate; PNA preflight checks have significantly mitigated browser rebinding. Server-side SSRF rebinding is not affected by PNA.
• Using only 1u.ms without confirming re-resolution — The 1u.ms shortcut confirms that the application's HTTP client reaches localhost if given a hostname that resolves to it, but does not prove the TOCTOU gap exists. A full rebinding PoC requires demonstrating the timing window separately.

NICE Framework Alignment

Further Reading

• Attacking Private Networks from the Internet with DNS Rebinding — Tavis Ormandy, Google Project Zero (2018)
• Singularity of Origin: DNS Rebinding Toolkit — NCC Group (github.com/nccgroup/singularity)
• DNS Rebinding: A Practical Attack — Dan Kaminsky, Black Hat USA 2008
• Chrome Private Network Access Specification — W3C Web Incubator Community Group