Open Sourcing Jaqen, A Tool For Developing DNS Rebinding PoCs

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?

DNS rebinding, in the simplest form, permits a “bypass” of same-origin policy (SOP), allowing a webpage with active content (e.g., JavaScript) to make network requests which would normally be blocked by SOP.

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.

As an example, let’s say you have sensitive array of user data hosted at http://unsafe.internal.data/users, where unsafe.internal.data has an IP address of 10.20.30.40. If the attacker was able to change the IP address associated with the rebind DNS record (rebind.attackerdoma.in) to 10.20.30.40 after the page has loaded, JavaScript running on that page could potentially exfiltrate that data (if no authentication is required) provided someone in your company accessed the attacker controlled domain.

For a more in-depth/hands-on explanation of DNS rebinding, I will describe my research on DNS rebinding at DEF CON 25 (10am on 7/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 (Mozilla Firefox and Google Chrome) 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:

Suggested mitigations

While I’m excited to introduce a tool that makes it easier to create PoCs for DNS rebinding, the main point of my research is attack mitigation. In that spirit, here are a few suggestions on how software engineers can protect against these attacks. Depending on your environment, protecting against DNS rebinding can either be a simple fix or somewhat complicated.

The “correct” way to mitigate DNS rebinding is to simply add authentication to your service. Fundamentally, this issue is only exploitable against services with weak/non-existent authentication. However, this isn’t always possible (legacy systems, localhost-bound tooling, etc.), or in some cases doesn’t make sense—for example, local development tools.

You might initially think to protect against these attacks at the network border, preventing any external DNS zones from resolving to internal subnets. However, this doesn’t offer complete protection for users on VPN or endpoints moving between untrusted networks where DNS responses are not controlled.

One of the simplest approaches to mitigating DNS rebinding on a vulnerable service is to enforce TLS. In addition to being good security hygiene, it will prevent a rebind due to the inevitable hostname mismatch between the certificate and the attacker-controlled domain. If possible, you should combine this with the other suggested mitigations; however, most developers understand how to quickly implement this fix in many frameworks, making it a great starting point.

Sometimes adding TLS isn’t possible or doesn’t make sense (for example localhost-bound services). In these cases, verifying the “Host” header against a whitelist of expected values, such as “127.0.0.1,” “localhost,” “::1,” etc., can prove an effective control in modern browsers. For an example of this approach, see the great implementation by the kubernetes team.

Open sourcing Jaqen

When I started looking into DNS rebinding, I looked at existing tools like rbndr and rebind. However, after a bit of digging, it seemed like some of these projects didn’t allow for a full range of DNS rebinding scenarios, were lacking in functionality (such as IPv6 support), or were not actively maintained. That’s why I’m happy to announce that Jaqen, the in-house tool LinkedIn uses for developing DNS rebinding PoCs, is now available to the community as an open source project on GitHub under a BSD 2-clause license. Our hope is that it will help other security professionals to easily develop PoCs for DNS rebinding, which will allow developers to easily recreate and fix the issue.

Acknowledgements

I’d like to acknowledge the entire House Security team at LinkedIn for their assistance and support for creating Jaqen.