"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." />

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:


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

Explore Topics

Industry Updates – Sponsored Posts

2015 Trends: Multi-channel, Streaming Media and the Growth of Fraud

Priority Access Program for Verisign's First IDN New gTLD, .コム

Minds + Machines Group Expands Into Chinese Market

New .PET Domain Sunrise Period Begins January 19

.CO Hits 2 Million Domains as Premium Sales Surge

Neustar's Career Site Launched Under Its Own Branded TLD: 'careers.neustar'

Data Volumes and Network Stress to Be Top IoT Concerns

DKIM for ESPs: The Struggle of Living Up to the Ideal

Radix Closes Holiday Sales With Over 35K Paid Registrations

Radix's .ONLINE Fastest to Sell 100,000 Domains

.PRO Domains Now Available to All

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Verisign Mitigates More Attack Activity in Q3 2015 Than Any Other Quarter During Last Two Years

Protect Your Privacy - Opt Out of Public DNS Data Collection

Verisign & Forrester Webinar: Defending Against Cyber Threats in Complex Hybrid-Cloud Environments

Measuring DNS Performance for the User Experience

LogicBoxes Announces Pioneer Registrar Program

Introducing Verisign Public DNS: A Free Recursive DNS Service That Respects Your Privacy

Faster DDoS Mitigation - Introducing Verisign OpenHybrid Customer Activated Mitigation

City of Miami 3rd in U.S. to Launch Dedicated TLD

Sponsored Topics