Tools & Prevention

This section will introduce Singularity, a robust and versatile DNS rebinding attack framework. Moreover, we will explore techniques to prevent DNS rebinding.

---

DNS Rebinding Tools

Singularity

A powerful DNS rebinding attack framework.

Installation

git clone https://github.com/nccgroup/singularity
cd singularity/cmd/singularity-server
go build

Setup

mkdir -p ~/singularity/html
cp singularity-server ~/singularity/
cp -r ../../html/* ~/singularity/html/

Run Server

Start on the same port as the target web application:

sudo ~/singularity/singularity-server --HTTPServerPort 80

Temporary secret: da4a821b782287813a5d366f476d5c0d406f3799
2023/05/14 10:40:26 Main: Starting DNS Server at 53
2023/05/14 10:40:26 HTTP: starting HTTP Websockets/Proxy Server on :3129
2023/05/14 10:40:26 HTTP: starting HTTP Server on :80

Configure Singularity as the nameserver for your domain (see Singularity's setup guide).

Using Singularity

1. Victim browses to http://rebinder.attacker.htb

2. Configure the attack:

   • Attack Host Domain: dynamic.attacker.htb

   • Target Host: 192.168.178.1

   • Target Port: 80

   • Attack Payload: Simple Fetch Get

3. Click Start Attack

4. Wait (may take minutes due to DNS pinning)

5. Alert popup confirms successful data access

For advanced options, see Singularity's wiki.

---

Prevention

SSRF Filter Bypasses

Best Practice	Description
Resolve before checking	Resolve domain name before checking to ensure IP format is expected
Use whitelist	If possible, check resolved IP against whitelist of allowed IPs
Block private ranges	Block 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 0.0.0.0/8
Handle redirects	Consider HTTP/HTML redirects and implement mitigations
Firewall rules	Prevent outgoing access from vulnerable app to internal network

Preventing DNS Rebinding in SSRF Filters

Do not resolve the domain name twice!

After resolving in the SSRF filter:

1. Fix the resolved IP address

2. Reuse it when making the actual request

3. Implementation is application-dependent

---

DNS Rebinding (Same-Origin Policy Bypass)

The danger: DNS rebinding enables attackers to access applications in victim's local network, circumventing firewalls/NAT.

Best Practices for Internal Network Design

Practice	Rationale
Use authentication on ALL internal services	DNS rebinding only accesses with cookies of corresponding domain name. Without credentials, only unauthenticated access possible.
Use TLS on ALL services	Certificate mismatch occurs when accessing internal service via incorrect domain name

Hardening Measures

Measure	Description
Refuse DNS lookups of internal IPs	DNS server responds with NXDOMAIN for domains resolving to internal IPs
Validate HTTP Host header	DNS rebinding uses incorrect domain name/Host header - reject unexpected values

---

Summary

┌─────────────────────────────────────────────────────────────────┐
│                DNS Rebinding Prevention Checklist               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  SSRF Filter Bypasses:                                         │
│  □ Resolve domain before checking                              │
│  □ Use IP whitelist or block all private ranges                │
│  □ Handle redirects properly                                   │
│  □ Implement firewall rules                                    │
│  □ Don't resolve domain twice (fix IP after first resolution)  │
│                                                                 │
│  SOP Bypass Prevention:                                        │
│  □ Require authentication on ALL internal services             │
│  □ Use TLS everywhere (internal + external)                    │
│  □ DNS server: refuse lookups returning internal IPs           │
│  □ Validate Host header on all internal applications           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘