📖 CyberBook

Appearance

↕️ DNS Rebinding ​

📚 Resources ​

🛠 Tools ​

🏠 Local DNS Server ​

🌐 Online Rebinder Bypass FQDN ​

What is it ? ​

DNS rebinding is a technique used to bypass same-origin policies and access internal resources (e.g. 127.0.0.1) through a victim's browser or server, by manipulating DNS resolution over time.

DNS Rebinding Exploit (Self-Hosted) ​

To perform a DNS rebinding attack, you typically need:

  • A domain you control (e.g. example.com)
  • A custom DNS server (e.g. dnsrebinder, dnschef)
  • Port 53 (DNS) open on your public-facing server

🧠 How NS works in this context ​

As the domain owner, you define the authoritative name servers (NS) for your domain (e.g. ns1.example.com). Once your domain’s registrar points to your custom NS (which you host), you control how every subdomain resolves.

That means:

You can define foo.example.com, bar.example.com, or whatever.example.com, and your custom DNS server decides which IP to return — dynamically or conditionally.

Example Setup with DNSrebinder ​

  1. Point your domain’s NS to your own server:
bash
ns1.example.com -> 193.168.0.1 (your VPS)
  1. Run DNSrebinder on your server:
bash
sudo python3 dnsrebinder.py --domain foo.bar.example.com. --rebind 127.0.0.1 --ip 8.8.8.8 --counter 1 --ttl 0 --udp
  • --domain: the subdomain to use (can be anything under your domain)
  • --ip: the IP returned on the first DNS request (e.g., public IP)
  • --rebind: the IP returned after the counter is reached (e.g., 127.0.0.1)
  • --counter: number of requests before rebinding happens
  • --ttl: time-to-live (DNS cache duration) — 0 means no caching
  • --udp: use UDP (default for DNS)
  1. Test with:
bash
dig @ns1.exemple.com foo.bar.example.com
# Or
dig @server_public_ip foo.bar.example.com

Check DNSrebinder logs to see if requests are received. If it works, you're ready to exploit.

⚔️ Attack Explanation ​

  • First request → DNS returns 8.8.8.8 (or your controlled server)
  • Server/browser trusts the FQDN (e.g., foo.bar.example.com)
  • Subsequent request(s) → DNS returns 127.0.0.1
  • Victim server makes internal request to http://foo.bar.example.com/admin → resolves to localhost → you gain access to internal-only services

✅ Attacks Without Hosting DNS Yourself ​

If you don’t own a DNS server or want to go faster, you can use wildcard DNS services like:

  • *.nip.io
  • *.sslip.io
  • *.fbi.com (legacy, sometimes works)
  • domaincontrol.com → resolves to 127.0.0.1 (useful for testing)

These resolve domains like 127.0.0.1.nip.io to their embedded IP.

❌ Problem: FQDN Validation ​

If the target server validates the FQDN (Fully Qualified Domain Name) and blocks loopback addresses or domains resolving to them, basic wildcard services fail.

In that case, you can use smarter tools like:

They allow timed switching between two IPs:

  • IP A = real public IP (e.g. 8.8.8.8)
  • IP B = loopback (e.g. 127.0.0.1)

The server sees IP A first (passes FQDN check), then resolves to IP B when it makes the actual HTTP request.

⚠️ Only limitation: TTL is usually set to 1, so spamming or race conditions might be needed to trigger the rebind in time.

🎯 Exploitation Example ​

Target: vuln.com:8080
Vulnerable endpoint: /?url=http://attacker.com

Your goal: Access http://127.0.0.1:8080/admin through the victim server.

Use rbndr: ​

bash
# IP A: 8.8.8.8 (dummy IP)
# IP B: 127.0.0.1 (target loopback)
# Output:
7f000001.08080808.rbndr.us

Send the payload:

http://vuln.com:8080/?url=http://7f000001.08080808.rbndr.us/admin

On first request: resolves to 8.8.8.8
Second time: resolves to 127.0.0.1 -> SSRF hits loopback → internal admin panel exposed

🛡️ Tips for defense ​

  • Always validate resolved IPs against a whitelist.
  • Never blindly trust Host, Origin, or FQDNs from user-controlled inputs.
  • Set strict CORS + SameSite rules.
  • DNS pinning or proxying DNS resolution through internal resolvers can help.