State of DNS Rebinding
Attack & Prevention Techniques andthe Singularity of Origin
Gérald Doussot & Roger Meyer | DEF CON 27

Contributions
New Tool: Singularity
●
●
●
●
●

Neat Technical Details/Techniques

Everything you need for DNS●
rebinding
Reliable: Default settings just work ●Performant: up to 20x faster (3s vs
60s)
Built-in payloads: Jenkins, Rails,●
AWS Instance Metadata, etc...
Autopwn: Networks & services
scan, service detection andauto-exploitation

Speed: Multiple DNS answers andcache flooding
Protection Bypasses: 3 different
bypasses for common DNS
rebinding protections○

Using DNS trickery

Hook/Control - Interactively browse
the victim’s internal network○

Websocket proxying, no HTTP proxyneeded!

Agenda
●
●
●
●
●
●
●

A Refresher on DNS Rebinding
DNS Rebinding Attack: Building on reliable foundations
The Need for Speed: DNS rebinding in 3 seconds
Protection Bypasses: 3 different bypasses for common DNS rebinding
protections
Hook and Control: Interactively browse the victim’s internal network
Scanning for Vulnerable Host Services
Automation: Service detection & exploitation and orchestrating all the above

Introduction

Who Are We●●●●

Gérald Doussot and Roger Meyer
Security consultants at
San Francisco, CA
Authors of Singularity of Origin,a DNS Rebinding Attack Framework
https://github.com/nccgroup/singularity

Why Should You Care About DNS Rebinding

bind 0.0.0.0

Why Should You Care About DNS Rebinding

bind 127.0.0.1

Why Should You Care About DNS RebindingWhy Should You Care About DNS RebindingWhy Should You Care About DNS RebindingWhy Should You Care About DNS RebindingWhy Should You Care About DNS RebindingWhy Should You Care About DNS RebindingWhy Should You Care About DNS Rebinding●●●

Prevalence of apps exposing HTTP servers on localhost (e.g. Electron)
IoT devices exposing sensitive interfaces on internal networks
Misconceptions○○

DNS rebinding is slow
DNS rebinding can be solved by out-of-the-box DNS filtering products or services

A Refresher on DNS
RebindingOn the Origin of Web Documents
The “Origin” of a resource is a tuple consisting of scheme, host and port.

Two documents A and B share the “same-origin” if they have identical scheme,
host and port components.
●●

https://mysite.com/hello.html and https://mysite.com/world.html ✔
https://mysite.com/hello.html and https://attacker.com/hello.html ✖

On the Origin of Web Documents
The “same-origin policy” dictates how two different origins may interact.
These interactions between origins are typically permitted: form submissions,links, redirects, content embedding (JavaScript, CSS).
Cross-origin reads are typically not allowed e.g. reading the content of an HTML
document located on gmail.com from site attacker.com.
DNS Rebinding permits to bypass restrictions imposed by the same-origin
policy.

DNS Rebinding Attack WalkthroughIntranet

Victim (Browser)

Target Service
127.0.0.1

Internet

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughIntranet

Victim (Browser)

UnauthenticatedaccessTarget Service
127.0.0.1

Internet

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughIntranet

Internet

Victim (Browser)

UnauthenticatedaccessTarget Service
127.0.0.1

BlockedAttacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughDNS query rebind.it
Victim (Browser)

Target Service
127.0.0.1

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughDNS query rebind.it
Victim (Browser)

Target Service
127.0.0.1

DNS A record response:
35.185.206.165

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughDNS query rebind.it
Victim (Browser)

DNS A record response:
35.185.206.165
DNS cache expires;
DNS query rebind.it

Target Service
127.0.0.1

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughDNS query rebind.it
Victim (Browser)

DNS A record response:
35.185.206.165
DNS cache expires;
DNS query rebind.it

Target Service
127.0.0.1

DNS A record response:
127.0.0.1

Attacker DNS& Web Server
35.185.206.165

DNS Rebinding Attack WalkthroughDNS query rebind.it
Victim (Browser)

GET/POST
request to
127.0.0.1
Target Service
127.0.0.1

DNS A record response:
35.185.206.165
DNS cache expires;
DNS query rebind.it
DNS A record response:
127.0.0.1

Attacker DNS& Web Server
35.185.206.165

Learning More About the Basics of DNS Rebinding
●
●
●
●
●
●

[2017] DEF CON 25 - Luke Young - There’s no place like 127.001: Achieving
reliable DNS rebinding (https://youtu.be/Q0JG_eKLcws)[2010] Black Hat USA & DEF CON 18 - Craig Heffner - How to hack millions ofrouters (https://youtu.be/VAaqABpjiUQ / https://youtu.be/Zazk0plSoQg)[2007] 24C3 - Dan Kaminsky - DNS Rebinding And More Packet Tricks(https://youtu.be/YwbpnZe74ds)[2018] NorthSec - Danny Cooper & Allan Wirth - Homeward Bound: Scanning
Private IP Space with DNS Rebinding (https://youtu.be/9iSvAS6IdiM)[2013] WOOT '13 - Yunxing Dai, Ryan Resig - FireDrill: Interactive DNS
Rebinding (https://www.usenix.org/conference/woot13/workshop-program/presentation/Dai)[2007] Stanford University - Protecting Browsers from DNS Rebinding Attacks(https://crypto.stanford.edu/dns/)

iOS Demo: DNS rebinding in 5 s (cache flooding)DNS Rebinding
Attack: Building on
Reliable Foundations

You Visit aCompletely
Innocuous
Looking Website

Malicious JavaScript Code Downloaded.

Sending First DNS Query...

What’s in a Query?
Example DNS query from a browser to Singularity DNS server:
s-35.185.206.165-127.0.0.1-3504134790-fs-e.d.rebind.it
●
●
●
●
●
●
●

(s)tart35.185.206.165: Attacker Host IP Address
127.0.0.1: Target Service IP Address or Name
3504134790: Session ID
fs: DNS Rebinding Strategy - “first then second” IP address.
(e)ndd.rebind.it: Attack Host Domain

Removing HTTP Performance Enhancing
Techniques That Impede DNS Rebinding
HTTP Caching - We want the browser to get fresh copies of resources.

Keep-Alive - We don’t want the browser to stick to the attacker’s server.

TTL Values# 1st query$ dig +noall +answer s-35.185.206.165-127.0.0.1-123-fs-e.d.rebind.it
S-35.185.206.165-127.0.0.1-123-fs-e.d.rebind.it. 0 IN A 35.185.206.165# 2nd query$ dig +noall +answer s-35.185.206.165-127.0.0.1-123-fs-e.d.rebind.it
s-35.185.206.165-127.0.0.1-123-fs-e.d.rebind.it. 0 IN A 127.0.0.1

Why not 1 second? We hoped 0 second would break stuff[1]. It did not so far, as far
as we know, it is a legitimate value[2].
[1] https://mark.lindsey.name/2009/03/09/never-use-dns-ttl-of-zero-0/[2] https://tools.ietf.org/html/rfc2181#page-10

How Do We Know We’ve Successfully Rebinded?
Two ways to differentiate the attacker server from the target service:$ curl -v http://s-35.185.206.165-127.0.0.1-3504134792-fs-e.d.rebind.it:8080/(...)
HTTP/1.1 200 OK
X-Singularity-Of-Origin: t # Custom HTTP Header(...)<!--thisismytesttoken--><!doctype html><title>(...) # Index TokenRandomness and Catering for Potential Interference
IPS/IDS/other interference via spurious DNS queries●●●

Challenge: the environment IPS/IDS may make their own queries to theattacker domains in addition to the target, resulting in incorrect DNS/out of
sequence DNS answers for the target.
Solution: Use the random DNS rebinding strategy.
Slower technique in general (but you could get lucky!).

The Need for Speed:
DNS Rebinding in 3
Seconds

Implementation Details Matter!
DNS Rebinding speed varies based on a number of factors:●●●●

OS implementation: Windows or Unix-like (Linux, macOS)
Browser vendor: IE/Edge, Firefox, Chrome/Chromium Edge, Safari
Target specification: local, remote
External factors: Spurious DNS queries e.g. presence of IPS/IDS

DNS rebinding may take 40+ min or ~3s on Edge depending on the strategy!
We can automatically fingerprint to optimize for speed in some conditions. Moreon this later!

Multiple Answers Rebinding Strategy with Targets
127.0.0.1 / 0.0.0.0
The time-varying (Singularity’s “first then second”) DNS rebinding technique is ~60
seconds on all browsers except IE/Edge.
Multiple answers (respond with attacker and target addresses, then block attacker
with ephemeral firewall rule) is near instantaneous. 127.0.0.1 works on Windows
only.
We got it to work on Unix-y machines (Linux, macOS) with “0.0.0.0”.
Solid and fast DNS rebinding against all “localhost” services.

Multiple Answers Rebinding Strategy Illustrated
DNS query rebind.it
Target Browser

DNS A record response:
1. 35.185.206.165
2. 127.0.0.1

Attacker DNS& Web Server
35.185.206.165

t: 0s - HTTP request 1
t: 2s - HTTP request 3
Target Service
127.0.0.1

t: 1s - HTTP request 2

Blocked!

DNS Cache Flooding
Multiple Answers works well for the loopback (0.0.0.0 or 127.x.x.x) interface inconsistent results for other target specifications.
On Google Chrome or Safari/iOS platforms, when flooding the DNS cache with
1K+ queries for which we receive valid answers, we observe DNS rebinding timewith the time varying attack technique (first then second) of 5 to 40 seconds, a
substantial progress over the average of ~60 seconds.
Flooding the cache is performed in a web worker.

Speed Measured / Target Definition
BrowserOS

StrategyTime toExploit

Fetch Interval

Target Spec

Windows 10MA

3 seconds

1 second

127.0.0.1

UbuntuMA

3 seconds

1 second

0.0.0.0macOSMA

3 seconds

1 second

0.0.0.0

macOS,Ubuntu,
Windows

FS+Cache Flooding

15-40 seconds

1 second

Any

iOS

FS+Cache Flooding

5 seconds

1 second

AnyProtection Bypasses

DNS Rebinding Protection Bypasses●

Singularity can bypass all known DNS rebinding protections:
○
○
○
○
○

●

UnboundDnsmasq
pfSense
OpenWRT
OpenDNS (Cisco Umbrella)Common recommendations and default configurations do not provide
complete protection

Common DNS Protections
Approaches:● Block RFC 1918 IP addresses
○

●
●
●

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Block localhost (127.0.0.0/8)
Block local (internal) networks
Block 0.0.0.0/8

Tools:● Dnsmasq & Unbound widely used○●

pfSense, OpenWRT, home routers (e.g. FRITZ!Box, ASUS)

Public DNS services○

OpenDNS: “Block internal IP addresses”: Blocks RFC 1918 IP addresses

Dnsmasq●●●●--stop-dns-rebind : Reject private IP ranges--rebind-localhost-ok : Exempt 127.0.0.0/8 from rebinding checks
This blocks RFC1918 addresses, 0.0.0.0/8, and 127.0.0.0/8
localhost is not blockedUnbound●●●private-address: Configure specific internal IP address range to be blockedThis blocks RFC1918 IP addresses
Does not block 0.0.0.0, 127.0.0.1, and localhost

DNS Rebinding Protection Bypass #1: 0.0.0.0●●●●

Wikipedia: “0.0.0.0 is a non-routable meta-address used to designate aninvalid, unknown or non-applicable target”
Fact: 0.0.0.0 works well on Linux and macOS to access the localhost
This bypasses protections that block DNS responses of 127.0.0.1
Singularity returns a DNS A record:$ dig s-1.2.3.4-0.0.0.0-474794-fs-e.d.rebind.it;; QUESTION SECTION:;s-1.2.3.4-0.0.0.0-474794-fs-e.d.rebind.it. IN A;; ANSWER SECTION:
s-1.2.3.4-0.0.0.0-474794-fs-e.d.rebind.it. 0 IN A 0.0.0.0

DNS Rebinding Protection Bypass #2: CNAME●●●

What if all internal IP addresses are blocked?
Canonical Name records (CNAME) map one domain name to anotherWe return a CNAME DNS record instead of an internal IP address○●●e.g. wiki.nccgroup.com or jenkins.internal.corp.com

This bypasses protections that block DNS responses of private IP addresses
The local, internal DNS server will then resolve the CNAME$ dig s-1.2.3.4- wiki.nccgroup.com-123-fs-e.d.rebind.it;; QUESTION SECTION:;s-1.2.3.4-wiki.nccgroup.com-123-fs-e.d.rebind.it. IN A;; ANSWER SECTION:
s-1.2.3.4-wiki.nccgroup.com-123-fs-e.d.rebind.it. 9 IN CNAME wiki.nccgroup.com.

DNS Rebinding Protection Bypass #2a: localhost●●●

localhost is a hostname that means this computer
We return a CNAME (Canonical Name) DNS record of “localhost.”
This bypasses protections that block DNS responses of 127.0.0.1$ dig s-1.2.3.4-localhost-123-fs-e.d.rebind.it;; QUESTION SECTION:;s-1.2.3.4-localhost-123-fs-e.d.rebind.it. IN
A;; ANSWER SECTION:
s-1.2.3.4-localhost-123-fs-e.d.rebind.it. 0 IN CNAME localhost.

Hook and Control :interactively browse
the victim's internal
network after DNS
rebindingExperimenting with Proxying without an HTTP Proxy
HTTP tools such as BeEF (Browser Exploitation Framework - https://beefproject.com/) and
FireDrill (https://www.usenix.org/conference/woot13/workshop-program/presentation/dai) can use a hookedbrowser via XSS or DNS rebinding as a gateway to otherwise unreachable
networks such as home or corporate environments.
We know that BeEF requires to configure the attacker browser or operating
system to use the BeEF HTTP proxy e.g. “http://beef.attaker.com:3120/”. We do not know
how FireDrill does it since its code is unfortunately not available.
We implemented browsing of services via a hooked browser in Singularity, without
requiring the attacker setting up its browser to use an HTTP proxy for fun.

Proxy Architecture
AttackerBrowser

Singularity

Hooked Target
Browser

Target Service

Websocket: connect and wait for instructions

HTTP: connect
and select hooked target browser

Proxy Architecture
AttackerBrowser

Hooked Target
Browser

Singularity

GET /home HTTP/1.1

Target Service

translate

Websocket: op=”fetch”,
args “/home”

translate
HTTP: fetch(“home”,{...})...and back

Proxying without an HTTP Proxy●●

Customized Golang’s RoundTripper https://golang.org/pkg/net/http/#RoundTripper
Using WS plain text protocol to package fetch() requests and responses Inflate size of data in transit: len ~= 4/3 of len(message) using base64
encoding.

Attacker Browser - Any user agent: Web browser, curl, HTTP inspecting proxy,
SQLMap, etc.

Dealing with Split Brains: Syncing the state between
the attacker and target’s browsers
The initial assumption was that we did not have to care about cookies. Our firsttest case was Duplicati, a backup application which was vulnerable to DNS
rebinding attack and has a web interface listening on localhost.

Oops.

Dealing with Split Brains: Syncing the state between
the attacker and target’s browsers
Cookies may be used as CSRF tokens or other purposes.
For non HttpOnly cookies:● Read them from target browser => transmit to the Singularity server● Singularity sets them on the attacker browser for the target domain (theDNS domain constructed by Singularity).
For HttpOnly cookies:● We don’t care - they can’t be read by JS so they cannot be used by JS.
● The target browser handles (receives and transmits) them for us.

Dealing with Split Brains: Syncing the state between
the attacker and target’s browsers
To be able to read cookies from a response to a fetch() request, you must pass
the option {credentials: ‘include’} to the fetch() request.
If the application requires HTTP authorization (WWW-Authenticate), then we must
forego completely about passing cookies, unless we know the credentials in
advance and pass them without being challenged for authentication.
Why? Let’s test in the next slides

Dealing with Split Brains: Syncing the state between
the attacker and target’s browsers
fetch ('http://127.0.0.1', {credentials: 'include'})→ Authentication dialog box popup in victim’s browser→ Victim 🤔

Dealing with Split Brains: Syncing the state between
the attacker and target’s browsers
fetch ('http://127.0.0.1', {credentials: omit})→ No authentication dialog box→ Victim 😌

Demo 2: Hook & Control

Scanning for
Vulnerable Hosts
ServicesOld World and Cool Hacks (Embedding Images,
Measuring Requests Response Time)
Many astute attempts to replicate nmap behavior without the power of raw
sockets.
Often unreliable / do too much for our purposes e.g. we don’t care about whether
a SSH port is open or not.
Does it speak HTTP? We are interested in DNS rebinding and DNS rebinding
deals with the HTTP protocol only (so far).

Leveraging Modern APIs and Focusing on What
Matters (fetch, abort, HTTP only)Leveraging Modern APIs and Focusing on What
Matters (fetch, abort, http only)
Solution:●●

Wrap in a web worker - distribute scan targets across 4 web workers
fetch() resource headers with timeout (300 ms) - Don’t bother with resp. body
○
○

●
●
●

Timeout drives how fast scans can go - how long we hang, waiting for a response
When an unhandled protocol (e.g. SSH) or when a port is firewalled (No TCP RST packet)

Fast for: open HTTP ports, closed ports
Slower for: firewalled ports, slow HTTP services & possibly specific protocols
Pro-tip:○○

Use a lower timeout when scanning LAN and/or fast HTTP services.
Use higher timeouts when scanning different networks e.g. across VPN.

Leveraging Modern APIs and Focusing on What
Matters (fetch, abort, http only)
Other bits and pieces:●●●

Use the classical WebRTC IP address leak when available to obtain the IP
address of the machine and derive a subnet (Chrome, Firefox).
fetch ('http://127.0.0.1', {credentials: omit}) → No authentication dialog box →Victim 😌. . Didn’t we cover this before? 🤔
Considering performing a second scan pass for potentially slower services(Singularity implementation TODO list).

Automation: Service
Detection &Exploitation andOrchestrating all the
AboveAuto Detection and Exploitation of All Things
Accessible by the Target Web Browsers●●●“Autoattack.html” automation and orchestration sample file
Customizable
Permits to leverage all features of Singularity
○
○
○
○
○

●

Specific exploitation payload or auto-selection of payload to deliver based on detected service
Targets selection + optional detection
Ports selection + optional port scanning
Default DNS strategy selection + optional detection of best strategy to use in specific cases
Various options such as flooding DNS cache, visibly hiding activity etc.

Future work: more auto-optimization so you don’t have to read the extensive
wiki (https://github.com/nccgroup/singularity/wiki) .

Choosing the Right Targets 0.0.0.0, "localhost",
CNAMES, Weak Host Model●●●

Mix and match different specifications of same target for reliability, security
controls bypass and speed (“0.0.0.0”, “localhost”, “127.0.0.1”).
Find and use the external IP address to exploit routers / Wifi APs’ internal
network facing administration interface (weak end system model https://www.defcon.org/images/defcon-18/dc-18-presentations/Heffner/DEFCON-18-Heffner-Routers-WP.pdf )Do some homework using OSINT - try to determine the local corporate
domains, use a dictionary of service names and specify them as CNAMES
e.g. jenkins.internal.corp.com. This is likely to pay off.

Service Detection
Singularity comes with a number of attack payloads targeting services such as
Chrome DevTools Remote Debugger, Amazon AWS instance metadata, Ruby on
Rails etc.
We recently augmented a number of its payloads with a service detection routine.

Selecting the “automatic” payload will instruct Singularity to detect the service anddeliver the appropriate attack!

Concluding Remarks:
There is Only One
HTTP Origin

How To Protect From DNS Rebinding:Use DNS blacklists
Use DNSSec?
Use this DNS service provider
Use this router/appliance/IPS!

How To Protect From DNS Rebinding:Common Wisdom is Not EnoughUse DNS blacklists
Use DNSSec
Use this DNS service provider
Use this router/appliance/IPS!

...Do you understand all the subtleties of DNS rebinding? And no, DNSSec
does not help at all!

How To Really Protect From DNS Rebinding
Use TLS on all services, external and internal including localhost(https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/, https://github.com/FiloSottile/mkcert/releases).
Always use authentication.
Validate the Host header of HTTP requests for correct values e.g. 127.0.0.1(whitelisting).
The future? https://wicg.github.io/cors-rfc1918/

Demo 3: Automation
1. Portscan
2. Rebind in 3s
3. Auto-detect
services
4. Exploit

Thank You●●

Get the Slides+Notes at: https://bit.ly/Singularity_Defcon27
Get Singularity of Origin at https://github.com/nccgroup/singularity
○
○
○
○
○
○
○

●

DNS server to rebind DNS names to IP addresses
HTTP server to serve HTML pages and JavaScript code to targets and to manage the attacks
Sample attack payloads: Chrome DevTools, Jenkins, & many more
Supports DNS CNAME to evade DNS filtering solutions
A simple, fast and efficient HTTP port scanner to identify vulnerable services
Attack automation: completely automate the scanning and exploitation
Hook & control to exploit victim browser as HTTP proxy to access internal
network resources

Contact us:○○

gerald.doussot@nccgroup.com
roger.meyer@nccgroup.com