Editor’s note: Members of the information security team at LinkedIn have an opportunity to work on research topics under a well-defined framework that allows them to evaluate new products and technologies, as well as explore the related threat surface. The team strives to find new and innovative ways to help simplify and strengthen security and contribute back to the community where possible to do so. In early 2017, Luke Young had the opportunity to make use of this framework and research the subject of DNS (Domain Name System) rebinding to be presented at DEF CON 25 in Las Vegas, NV.
What is DNS rebinding?
A useful illustration, if overly-simplified, is to imagine DNS rebinding as allowing an attacker the same type of access they would get to your network if they walked into your building and plugged in (assuming your network lacked port-security/authentication). The attacker wouldn’t gain access to any systems that have strong authentication, but an unauthenticated development database or a wiki page containing sensitive information would be accessible via DNS rebinding. The rebind allows the attacker to hitch a ride into your network on the back of the adjusted DNS record.
DNS rebinding isn’t a new technique; in fact, it’s been around for many years and has been discussed multiple times before, such as at DEF CON 18. But despite the many discussions that have taken place on this topic, DNS rebinding remains an issue today.
How does it work?
To explain it simply, SOP (as implemented in modern browsers) prevents active content on one domain (such as attackerdoma.in) from accessing data on another domain (such as www.linkedin.com). DNS rebinding allows a malicious website to bypass this restriction under certain circumstances by abusing the TTLs (time to live) of DNS records.
The attack works by first loading a webpage (e.g., rebind.attackerdoma.in) which will initially resolve to an attacker-controlled server. After the webpage has loaded, the server will trigger a “rebind” and adjust the DNS record to resolve to another address such as an internal IP (e.g., 127.0.0.1). After the rebind occurs, the webpage can make requests to rebind.attackerdoma.in which will resolve to the internal IP address (127.0.0.1). Because the browser considers the request to originate from the same origin as the currently loaded page, it will be allowed to read the response. Since these requests occur from a “new” origin, they will not contain credentials (cookies, auth, etc.); however, they can be used to exfiltrate data from internal networks that are protected solely by a firewall and to attack services without authentication.
For a more in-depth/hands-on explanation of DNS rebinding, I will describe my research on DNS rebinding at DEF CON 25 (10 a.m. on July 27). If you can’t make it out to Las Vegas, Robert Hansen has a great video from 2009 explaining DNS rebinding at a high-level.
Why does this issue still exist?
If this issue has persisted for years, the obvious question would be: why isn’t this fixed yet? The answer gets a little complicated. Major browser vendors (like Mozilla Firefox, Google Chrome, etc.) have repeatedly declined to fix this issue, and discussion in the developer community tends towards statements like this one from Stanford’s Adam Barth:
“I’d also recommend that Firefox not fix this issue. It’s not feasible for the browser to protect the user from DNS rebinding attacks. Servers need to protect themselves by validating the Host header and firewalls need to protect themselves by preventing external names from resolving to internal IP addresses.”
And to be fair to the browser vendors, this isn’t a browser issue—browsers are implementing the specification exactly as it was written, which doesn’t require specific handling for edge-cases like this. Their argument (which has merit) is that these issues should be fixed within the vulnerable applications themselves.
However, I’ve found that in practice many vulnerable applications decline to fix this problem, believing it to be only exploitable in edge-cases, or so difficult to set up that it’s impractical to exploit in the real world. Part of the problem is that DNS rebinding is notoriously unreliable and hard to debug. Browsers have unintentionally (and intentionally, in some cases) made developing proof-of-concepts (PoCs) for DNS rebinding increasingly difficult, resulting in more time spent by security engineers and developers debugging the DNS rebinding itself, rather than just verifying the bug and working on a fix. I wanted to help resolve that by developing a tool, which I call “Jaqen,” to simplify the process of developing a DNS rebinding PoC.
How the tool works
When developing Jaqen, I had two goals in mind. The first was to expose an extremely simple interface that transparently performs a DNS rebind, abstracting away the complicated implementation details while still also offering a more complex interface for power-users.
The second goal was to reduce the notorious unreliability associated with DNS rebinding. To accomplish this, Jaqen offers a new approach by attempting multiple DNS rebinding methods at the same time, selecting the first method to succeed, then remembering that preferred method for future rebinds.
A pool of public IP addresses is maintained that can be used when executing rebind attacks. When a request is received, resources are selected from the pool based on current utilization and are reserved for the duration of the attack. Because Jaqen intelligently allocates and releases these binds when they are no longer in use, it can be run with minimal hardware requirements.
Jaqen abstracts away the complex steps required to perform a DNS rebind and exposes an HTML5 Fetch interface, which transparently triggers a DNS rebind: