State of DNS Rebinding
Attack & Prevention Techniques and
the Singularity of Origin
Gérald Doussot & Roger Meyer | DEF CON 27
Contributions
New Tool: Singularity
Neat Technical Details/Techniques
Agenda
Introduction
Who Are We
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
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.
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 Walkthrough
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
Intranet
Internet
DNS Rebinding Attack Walkthrough
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
Intranet
Internet
Unauthenticated access
DNS Rebinding Attack Walkthrough
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
Intranet
Internet
Unauthenticated access
Blocked
DNS Rebinding Attack Walkthrough
DNS query rebind.it
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
DNS Rebinding Attack Walkthrough
DNS query rebind.it
DNS A record response: 35.185.206.165
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
DNS Rebinding Attack Walkthrough
DNS query rebind.it
DNS A record response: 35.185.206.165
DNS cache expires;�DNS query rebind.it
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
DNS Rebinding Attack Walkthrough
DNS query rebind.it
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
Target Service 127.0.0.1
Victim (Browser)
DNS Rebinding Attack Walkthrough
DNS query rebind.it
DNS A record response: 35.185.206.165
DNS cache expires;�DNS query rebind.it
DNS A record response: 127.0.0.1
GET/POST request to 127.0.0.1
Attacker DNS �& Web Server
35.185.206.165
Target Service 127.0.0.1
Victim (Browser)
Learning More About the Basics of DNS Rebinding
iOS Demo: DNS rebinding in 5 s (cache flooding)
DNS Rebinding Attack: Building on Reliable Foundations
�
You Visit a Completely 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
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
The Need for Speed: DNS Rebinding in 3 Seconds
Implementation Details Matter!
DNS Rebinding speed varies based on a number of factors:
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. More on 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
Target Browser
Attacker DNS �& Web Server
35.185.206.165
Target Service
127.0.0.1
DNS query rebind.it
DNS A record response:
t: 0s - HTTP request 1
t: 2s - HTTP request 3
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 time with 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
Browser | OS | Strategy | Time to Exploit | Fetch Interval | Target Spec |
| Windows 10 | MA | 3 seconds | 1 second | 127.0.0.1 |
| Ubuntu | MA | 3 seconds | 1 second | 0.0.0.0 |
| macOS | MA | 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
Common DNS Protections
Approaches:
Tools:
Dnsmasq
Unbound
DNS Rebinding Protection Bypass #1: 0.0.0.0
$ 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
$ 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
$ 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 hooked browser 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
Attacker Browser
Websocket: connect and wait for instructions
Singularity
Hooked Target Browser
Target Service
HTTP: connect �and select hooked target browser
Proxy Architecture
Attacker Browser
Singularity
Hooked Target Browser
Target Service
GET /home HTTP/1.1
Websocket: op=”fetch”,� args “/home”
HTTP: fetch(“home”,{...})
...and back
translate
translate
Proxying without an HTTP Proxy
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 first test 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:
For HttpOnly cookies:
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:
Leveraging Modern APIs and Focusing on What Matters (fetch, abort, http only)
Other bits and pieces:
Automation: Service
Detection & Exploitation and Orchestrating all the Above
Auto Detection and Exploitation of All Things Accessible by the Target Web Browsers
Choosing the Right Targets 0.0.0.0, "localhost", CNAMES, Weak Host Model
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 and deliver 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 Enough
Use 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
Thank You