You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pentesting-web/cors-bypass.md
+31Lines changed: 31 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -413,6 +413,36 @@ You can find more information about the previous bypass techniques and how to us
413
413
414
414
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) is a tool to perform [DNS rebinding](https://en.wikipedia.org/wiki/DNS_rebinding) attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
415
415
416
+
### DNS Rebinding over DNS-over-HTTPS (DoH)
417
+
418
+
DoH simply tunnels the classic RFC1035 DNS wire format inside HTTPS (usually a POST with `Content-Type: application/dns-message`). The resolver still answers with the same resource records, so SOP-breaking techniques continue to work even when browsers resolve the attacker-controlled hostname via TLS.
419
+
420
+
#### Key observations
421
+
422
+
- Chrome (Windows/macOS) and Firefox (Linux) successfully rebind when configured for Cloudflare, Google, or OpenDNS DoH resolvers. Transport encryption neither delays nor blocks the attack-flow for **first-then-second**, **multiple-answers**, or **DNS cache flooding** strategies.
423
+
- Public resolvers still see every query, but they rarely enforce the host-to-IP mapping a browser must honor. Once the authoritative server returns the rebinding sequence, the browser keeps the original origin tuple while connecting to the new IP.
424
+
425
+
#### Singularity strategies and timing over DoH
426
+
427
+
-**First-then-second** remains the most reliable option: the first lookup returns the attacker IP that serves the payload, every later lookup returns the internal/localhost IP. With typical browser DNS caches this flips traffic in ~40–60 seconds, even when the recursive resolver is only reachable over HTTPS.
428
+
-**Multiple answers (fast rebinding)** still reaches localhost in <3 seconds by answering with two A records (attacker IP + `0.0.0.0` on Linux/macOS or `127.0.0.1` on Windows) and programmatically blackholing the first IP (for example, `iptables -I OUTPUT -d <attacker_ip> -j DROP`) shortly after the page loads. Firefox’s DoH implementation may emit repeated DNS queries, so the Singularity fix is to schedule the firewall rule relative to the **first** query timestamp instead of refreshing the timer on every query.
429
+
430
+
#### Beating “rebind protection” in DoH providers
431
+
432
+
- Some providers (e.g., NextDNS) replace private/loopback answers with `0.0.0.0`, but Linux and macOS happily route that destination to local services. Intentionally returning `0.0.0.0` as the second record therefore still pivots the origin to localhost.
433
+
- Filtering only the direct A/AAAA response is ineffective: returning a **CNAME** to an internal-only hostname makes the public DoH resolver forward the alias while browsers such as Firefox fall back to the system DNS for the internal zone, completing the resolution to a private IP that is still treated as the attacker origin.
434
+
435
+
#### Browser-specific DoH behavior
436
+
437
+
-**Firefox DoH** operates in fallback mode: any DoH failure (including an unresolved CNAME target) triggers a plaintext lookup via the OS resolver, which is typically an enterprise DNS server that knows the internal namespace. This behavior is what makes the CNAME bypass reliable inside corporate networks.
438
+
-**Chrome DoH** only activates when the OS DNS points to a whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, etc.) and does not provide the same fallback chain. Internal hostnames that only exist on corporate DNS therefore fail to resolve, but rebinding toward localhost or any routable address still succeeds because the attacker controls the entire response set.
439
+
440
+
#### Testing and monitoring DoH flows
441
+
442
+
- Firefox: `Settings ➜ Network Settings ➜ Enable DNS over HTTPS` and provide the DoH endpoint (Cloudflare and NextDNS are built in). Chrome/Chromium: enable `chrome://flags/#dns-over-https` and configure the OS DNS servers to one of Chrome’s supported resolvers (e.g., `1.1.1.1`/`1.0.0.1`).
443
+
- You can query public DoH APIs directly, e.g. `curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq` to confirm the exact records browsers will cache.
444
+
- Intercepting DoH in Burp/ZAP still works because it is just HTTPS (binary DNS payload in the body). For packet-level inspection, export TLS keys (`export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt`) before launching the browser and let Wireshark decrypt the DoH sessions with the `dns` display filter to see when the browser stays on DoH or falls back to classic DNS.
445
+
416
446
### Real Protection against DNS Rebinding
417
447
418
448
- Use TLS in internal services
@@ -442,6 +472,7 @@ You can find more information about the previous bypass techniques and how to us
-[NCC Group - Impact of DNS over HTTPS (DoH) on DNS Rebinding Attacks](https://www.nccgroup.com/research-blog/impact-of-dns-over-https-doh-on-dns-rebinding-attacks/)
0 commit comments