# DNS rebinding attacks explained: The lookup is coming from inside the house!
DNS rebinding attack without CORS against local network web applications. Explore the topic further and see how it can be used to exploit vulnerabilities in the real-world.
My colleague Kevin Stubbs mentioned the topic of DNS rebinding attacks in a previous blog post. No worries if you haven’t read it yet though—in this article, we’ll walk you through the concept of DNS rebinding from scratch, demystify how it works, and explore why it’s a serious browser-based security issue.
We’ll start by revisiting the same-origin policy, a fundamental part of web security, and show how DNS rebinding bypasses it. You’ll see real-world scenarios where attackers can use this technique to access internal applications running on your local machine or network, even if those apps aren’t meant to be publicly available. We’ll dive into a real vulnerability in the Deluge BitTorrent client, explaining exactly how DNS rebinding could have been used to read arbitrary files from a local system. Finally, we’ll go over practical steps you can take to protect yourself or your application from this often-overlooked but potent attack vector.
## Same-origin policy
Same-origin policy (SOP) is a cornerstone of browser security introduced in 1995 by Netscape. The idea behind it is simple: Scripts from webpages of one origin should not be able to access data from a webpage of another origin. For example, nobody wants arbitrary webpages to be able to read their currently logged-in webmail. So that websites can be distinguishable from the next, they’re each defined with a combination of protocol (schema), host (DNS name), and a port number. Any mismatch in these three parts makes the origin different.
For example, for the webpage: `https://www.somedomain.com/sub/page.html` possible origin comparisons are the following:
## The attack: DNS rebinding
People tend to think running something on localhost completely shields it from the external world. While they understand that they can access what is running on the local machine from their local browser, they miss that the browser may also become the gateway through which unsolicited visitors get access to the web applications on the same machine or local network.
Unfortunately, there is a disconnect between the browser security mechanism and networking protocols. If the resolved IP address of the webpage host changes, the browser doesn’t take it into account and treats the webpage as if its origin didn’t change. This can be abused by attackers.
For example, if an attacker owns the domain name `somesite.com` and delegates it to a DNS server that is under attacker control, they may initially respond to a DNS lookup with a public IP address, such as 172.217. 22.14, and then switch subsequent lookups to a local network IP address, such as 192.168.0.1 or 127.0.0.1 (i.e. localhost). Javascript loaded from the original `somesite.com` will run client-side in the browser, and all further requests from it to `somesite.com` will be directed to the new, now local, IP address. From then on, documents loaded from different IP addresses—but resolved from the same hosts—will be considered to be of the same origin. This gives the attackers the ability to interact with the victim’s local network via Javascript running in the victim’s browser. This makes any web application that runs locally on the same machine or local network as the victim’s browser accessible to the scripts loaded from `somesite.com` too.
One catch is that if the web application requires authentication, its cookies are not made available to the attacker. Since the targeted user originally opened `somesite.com`—and even though subsequent Javascript requests are directed to the new, attacker rebound, IP address—the browser still operates in the context of the `somesite.com` origin. That means the victim’s browser will not use stored authentication or session context for the locally targeted service name.
Other scenarios could include attackers abusing local VPN routes that are available to the targeted user, allowing access to corporate intranet web applications, for example.
## The response: caching
Browsers try to resist DNS rebinding like this by caching DNS responses, but the defense is far from perfect. Some browsers have implemented Local Network Access (also known as CORS-RFC1918), a new draft W3C specification. It closed some avenues, but still left some bypasses, such as 0.0.0.0 IP address on Linux and MacOS, so the DNS rebinding behavior is very browser and operating system (OS) dependent. There are so many layers involved (browser DNS cache, OS DNS cache, DNS nameservers) that the attack is often considered unreliable and not taken as a real threat. However, there are also tools that can automate attacks such as Tavis Ormandy’s Simple DNS Rebinding Service or NCCGroup’s Singularity of Origin.
## A real-world vulnerability
Now let’s dive into technicalities of a real-world vulnerability found in BitTorrent client Deluge (fixed in v2.2.0) and how DNS rebinding could have been used to exploit it.
The Deluge BitTorrent client supports starting two services on system boot: daemon and WebUI. The WebUI web application service may also be started by enabling the WebUI plugin (installed, but disabled by default) in the preferences dialog of the Deluge client. It is also convenient to run the WebUI application permanently on a server in the local network. We found a path traversal in an unauthenticated endpoint of the web application that allowed for arbitrary file read.
“`
def render(self, request): log.debug(‘Requested path: %s’, request.lookup_path) lookup_path = request.lookup_path.decode() for script_type in (‘dev’, ‘debug’, ‘normal’): scripts = self.__scripts[script_type][‘scripts’] for pattern in scripts: if not lookup_path.startswith(pattern): #