Home / Blogs

Defending Networks Against DNS Rebinding Attacks

DNS rebinding attacks are real and can be carried out in the real world. They can penetrate through browsers, Java, Flash, Adobe and can have serious implications for Web 2.0-type applications that pack more code and action onto the client. Such an attack can convert browsers into open network proxies and get around firewalls to access internal documents and services. It requires less than $100 to temporarily hijack 100,000 IP addresses for sending spam and defrauding pay-per-click advertisers. Everyone is at risk and relying on network firewalls is simply not enough.

In a paper released by Stanford Security Lab, “Protecting Browsers from DNS Rebinding Attacks,” authors Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, and Dan Boneh provide ample detail about the nature of this attack as well as strong defenses that can be put in place in order to help protect modern browsers.

In the following section from the paper, the authors explain how DNS Rebinding Attacks are implemented and why a well-known existing defense against these attacks, called “DNS pinning,” is simply ineffective in modern browsers.

Introduction to DNS Rebinding Attacks

Users who visit web pages trust their browser to prevent malicious web sites from leveraging their machines to attack others. Organizations that permit JavaScript and other active content through their firewall rely on the browser to protect internal network resources from attack. To achieve these security goals, modern browsers implement the same-origin policy that attempts to isolate distinct “origins,” protecting sites from each other.

DNS rebinding attacks subvert the same-origin policy by confusing the browser into aggregating network resources controlled by distinct entities into one origin, effectively converting browsers into open proxies. Using DNS rebinding, an attacker can circumvent firewalls to spider corporate Intranets, exfiltrate sensitive documents, and compromise unpatched internal machines. An attacker can also hijack the IP address of innocent clients to send spam email, commit click fraud, and frame clients for misdeeds. DNS rebinding vulnerabilities permit the attacker to read and write directly on network sockets, subsuming the attacks possible with existing JavaScript-based botnets, which can send HTTP requests, but cannot read back the responses.

To mount a DNS rebinding attack, the attacker need only register a domain name, such as attacker.com, and attract web traffic, for example by running an advertisement. In the basic DNS rebinding attack, the attacker answers DNS queries for attacker.com with the IP address of his or her own server with a short time-to-live (TTL) and serves visiting clients malicious JavaScript. To circumvent a firewall, when the script issues a second request to attacker.com, the attacker rebinds the host name to the IP address of a target server that is inaccessible from the public Internet. The browser believes the two servers belong to the same origin because they share a host name, and it allows the script to read back the response. The script can easily exfiltrate the response, enabling the attacker to read arbitrary documents from the internal server.

To mount this attack, the attacker did not compromise any DNS servers. The attacker simply provided valid, authoritative responses for attacker.com, a domain owned by the attacker. This is very different from “pharming” attacks where the attacker must compromise a host name owned by the target by subverting a user’s DNS cache or server.

DNS rebinding requires no such subversion. Consequently, DNSSEC provides no protection against DNS rebinding attacks: the attacker can legitimately sign all DNS records provided by his or her DNS server in the attack. DNS rebinding attacks have been known for a decade. A common defense implemented in several browsers is DNS pinning: once the browser resolves a host name to an IP address, the browser caches the result for a fixed duration, regardless of TTL. As a result, when JavaScript connects to attacker.com, the browser will connect back to the attacker’s server instead of the internal server.

Pinning is no longer an effective defense against DNS rebinding attacks because current browsers use plug-ins to add functionality to web pages. The browser and each plug-in maintain separate pin databases, creating a new class of vulnerabilities we call multi-pin vulnerabilities that permit an attacker to mount DNS rebinding attacks. We demonstrate, for example, how to exploit the interaction between the browser and Java LiveConnect to pin the browser to one IP address while pinning Java to another IP address, permitting the attacker to read and write data directly on sockets to a host and port of the attacker’s choice despite strong pinning by each component. Some of these attacks have been discussed recently in the black-hat community.

Our experiments show how an attacker can exploit multi-pin vulnerabilities to cheaply and efficiently assemble a temporary, large-scale bot network. Our findings suggest that nearly 90% of web browsers are vulnerable to rebinding attacks that only require a few hundreds of milliseconds to conduct. These attacks do not require users to click on any malicious links: users need only view an attacker’s web advertisement. By spending less than $100 on advertising, an attacker can hijack 100,000 unique IP address to send spam, commit click fraud, or otherwise misuse as open network proxies.

The above introduction to DNS Rebinding Attacks is reproduced here with permission from the Stanford Security Lab and the authors of the paper, “Protecting Browsers from DNS Rebinding Attacks”. Links provided within the article are included by CircleID for your reference.

By CircleID Reporter

CircleID’s internal staff reporting on news tips and developing stories. Do you have information the professional Internet community should be aware of? Contact us.

Visit Page

Filed Under


The Famous Brett Watson  –  Aug 10, 2007 2:34 AM

The problem here is one of authorisation. As the zone administrator of a domain name, I have the ability to make DNS records in my zone refer to any valid resource, whether or not that resource has anything to do with me. Herein lies the problem. The actual party responsible for the resource in question—usually a host—has no say in the matter. DNS records point in one direction—from the name to the resource—and do so without restriction.

What’s missing is the ability of a host to repudiate an identity ascribed to it—to authorise the use of the name (or not). A client looks up “foo.attacker.com” and finds its IP address: it must then be possible for the host at that IP address to somehow repudiate or affirm that identity before the client interacts further.

We already have an infrastructure in place to do this: reverse DNS lookups under the “in-addr.arpa” space. A very quick fix that could be applied to this security problem would be to verify the host name by seeking the corresponding “PTR” record in “in-addr.arpa” space. The attacker would then need to compromise the appropriate section of “in-addr.arpa” space before the attack could work.

This is not a new concept. Every host is supposed to be fully resolvable in reverse using this technique already, but the practice is widely neglected (in some regions more so than others). Maintenance of this address space is, I think, seen as broadly inconvenient and unnecessary. This kind of attack demonstrates why it is necessary, and security almost invariably entails some inconvenience.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign


Sponsored byDNIB.com


Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix