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

Related topics: Cyberattack, Cybercrime, DNS, DNS Security, Domain Names, IP Addressing, Security, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Re: Defending Networks Against DNS Rebinding Attacks The Famous Brett Watson  –  Aug 09, 2007 6:34 PM PST

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.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Join Paul Vixie & Robert Edmonds at the Upcoming Distinguished Speaker Series

Q3 2014 DDoS Trends: Attacks Exceeding 10 Gbps on the Rise

LogicBoxes Announces Automation Solutions for ccTLD

TLD Registry Wins Best Marketing Award at China New gTLD Roadshow

Update on Minds + Machines' Top-Level Domain Launches

ICANN Los Angeles Recap Webinar

TLD Registry Appoints First China General Manager, Mr Jin Wang

TLD Registry Opens China Headquarters in "China's Silicon Valley"

.nyc Goes Public to Brand the Big Apple

pink.host: Breast Cancer Awareness by Bluehost

3 Questions to Ask Your DNS Host About DDoS

Introducing Our Special Edition Managed DNS Service for Top-Level Domain Operators

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Infographic: Where in the World Do Chinese People Live?

Neustar to Build Multiple Tbps DDoS Mitigation Platform

Auctions Update: MMX Wins .law and .vip

The Latest Internet Plague: Random Subdomain Attacks

Digging Deep Into DNS Data Discloses Damaging Domains

New .ORGANIC Top-Level Domain Welcomes Leading Brands As .ORGANIC Pioneers

Dot Chinese Online and Dot Chinese Website Featured in EURid's World Report on IDNs 2014

Sponsored Topics

dotMobi

Mobile

Sponsored by
dotMobi
Afilias

DNS Security

Sponsored by
Afilias
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Verisign

Security

Sponsored by
Verisign