Home / Blogs

Defending Networks Against DNS Rebinding Attacks

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.

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



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

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

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Leading Internet Associations Strengthen Cooperation

5 Afilias Top Level Domains Now Licensed for Sale in China

Radix Announces Largest New gTLD Sale with Casino.Online

2016 Year in Review: The Trending Keywords in .COM and .NET Domain Registrations

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

A Look at How the New .SPACE TLD Has Performed Over the Past 2 Years

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

MarkMonitor Supports Brand Holders' Efforts Regarding .Feedback Registry

Don't Gamble With Your DNS

8 Tips to Find Your Perfect .COM Domain Name

Why .com is the Venture Capital Community's Power Player

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Radix Launches Startup League at TechCrunch