DNS Rebinding - Same-Origin-Policy-Bypass via DNS
DNS rebinding is an attack that circumvents the browser’s Same-Origin Policy (SOP) by temporarily redirecting the DNS record of an attacker’s domain to internal IP addresses. Browsers believe they are communicating with the external attacker’s domain, but are actually accessing internal services (routers, cameras, IoT devices, localhost). Attacks enable the reading of internal resources, CSRF against internal services, and access to cloud metadata. Protection: DNS rebinding filters in routers, private IP blocking in browsers, and authentication on internal services.
DNS Rebinding exploits a subtle flaw in the browser's security model: The Same-Origin Policy checks the origin based on the hostname—not the IP address. An attacker who sets their DNS TTL to seconds can change the IP address after the browser performs the lookup. The browser still sees "attacker.com" as the origin, but is actually communicating with an internal device.
Attack Principle
Same-Origin Policy (SOP) – Basis of the Attack:
The SOP does NOT allow JavaScript on http://attacker.com to read responses from http://victim.com. Crucial: The SOP checks the hostname, not the IP address.
http://attacker.com → 1.2.3.4 ← allowed (own IP)
http://attacker.com → 192.168.1.1 ← ALSO allowed?!
→ Browser sees "attacker.com" in both cases!DNS Rebinding Process:
- Victim visits http://attacker.com → Browser resolves: attacker.com = 1.2.3.4 (real IP) → JavaScript loads, TTL is short (5–10 seconds)
- TTL expires → Attacker’s DNS server changes entry: attacker.com = 192.168.1.1 (victim’s internal router!)
- JavaScript sends a request to attacker.com → Browser: "attacker.com is same-origin, no problem!" → New DNS lookup: attacker.com = 192.168.1.1 → Request goes to the victim’s internal router → Attacker reads the response!
Prerequisites:
- Victim visits attacker’s website (1–2 minutes is enough!)
- Victim has internal services without authentication
- DNS TTL short enough (browsers cache DNS for varying lengths of time!)
Attack Targets
1. Home Router Admin Interface
- 192.168.1.1:80 / 192.168.0.1:80
- Default interface without authentication or default credentials
- DNS rebinding → Attacker takes over router
- Can: Change DNS server (permanent DNS hijacking!), port forwarding, firewall
2. Smart Home / IoT Devices
- IP cameras: Video stream accessible!
- Smart TVs: DIAL protocol (YouTube/Netflix app launch)
- 3D printers: Send printer commands (Prusa, OctoPrint on 5000/TCP)
- Philips Hue Bridge: Control lights
- Amazon Echo (local commands)
3. Developer Workstations (localhost)
- Local development servers: localhost:3000, localhost:8080
- Docker containers without bind-to-localhost
- Jenkins, GitLab: often on localhost without authentication during development
- Kubernetes Dashboard: localhost:8001 (kubectl proxy)
- Cloud metadata: 169.254.169.254 (when developing on a cloud VM!)
4. Cloud metadata via DNS rebinding
If the victim is working on a cloud VM:
- Rebind to 169.254.169.254
- AWS IMDS: IAM credentials accessible!
- GCP Metadata: all service account tokens!
5. Intranet Web Services
- HR systems, Wiki, ticketing without VPN requirement
- Internal APIs with IP whitelisting instead of authentication ("anyone internally can access" – wrong!)
Practical Exploit Tools
Singularity of Origin (Joe Linn)
- Automatic DNS rebinding framework
- GitHub: nccgroup/singularity
- Includes: Manager server + DNS server + Attack server
- Configurable rebinding strategy: Timing, Target IP
rebind.it (Proof of Concept)
- Online tool for easy DNS rebinding testing
- Own domain:
<ip>.rebind.it→ rebinds to<ip>
DNS Server Configuration for Rebinding (Demo)
; Zone: attacker.com
; TTL: 5 ← Very short!
; Phase 1: real IP
attacker.com. 5 IN A 1.2.3.4
; After trigger, switch to:
attacker.com. 5 IN A 192.168.1.1Evidence in the penetration test:
- Demonstrate that the internal service is accessible via the attacker’s domain
- Read response content (HTML, JSON) from the internal service in browser JavaScript
- No credentials required if the service has no authentication!
Mitigation Measures
1. DNS Rebinding Filter in Resolver/Router
Block private IP ranges in DNS responses for public domains (RFC 5735: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
# Pi-hole / AdGuard Home configuration:
rebind-domain-ok= # Empty = all private IPs blocked
# dnsmasq (router firmware):
stop-dns-rebind
rebind-localhost-ok # Only 127.0.0.1 allowed as an exception> Fritz!Box: DNS rebind protection is enabled by default!
2. Browser-internal protection mechanisms
Chrome Private Network Access (PNA):
- Blocks requests from public to private IPs (after consent)
- Preflight request with
Access-Control-Request-Private-Networkheader - Internal servers must explicitly respond with
Access-Control-Allow-Private-Network: true - Status (2024): Being rolled out gradually in Chrome
Firefox: private-network-access-respects-permission (experimental)
3. Host header validation on internal services
Internal service checks: Does the request come from an expected host? If Host: attacker.com on internal service → BLOCK!
server {
listen 8080;
if ($host !~ ^(localhost|192\.168\.1\.100)$) {
return 421; # Misdirected Request
}
}4. Authentication on ALL internal services
- No services "just because they're internal = trustworthy" without auth!
- Even for internal tools: Basic Auth, Token Auth, OAuth
- DNS rebinding with auth: Attacker JS cannot send credentials along
- Or:
SameSite=Strictcookies + CSRF tokens
5. Network segmentation
- IoT devices in a separate VLAN (192.168.10.0/24)
- Office PCs CANNOT access the IoT VLAN (firewall rule)
- DNS rebinding cannot directly attack IoT devices if the firewall blocks it
6. DNSSEC - not helpful here
DNSSEC signs responses from the authoritative server. However, the problem lies with the attacker-controlled DNS server for their own domain - DNSSEC does NOT help against DNS rebinding here!
