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.