Dns rebinding

Protecting Browsers from DNS Rebinding Attacks
Collin Jackson
Stanford University

Adam Barth
Stanford University

Andrew Bortz
Stanford University

collinj@cs.stanford.edu abarth@cs.stanford.edu abortz@cs.stanford.edu Weidong Shao Dan Boneh
Stanford University Stanford University

wshao@cs.stanford.edu ABSTRACT
DNS rebinding attacks subvert the same-origin policy of browsers andconvert them into open network proxies. We survey new DNS rebinding attacks that exploit the interaction between browsers and their plug-ins, such as Flash Player and Java. These attacks can be used to circumvent firewalls and are highly cost-effective for sending spam email and defrauding pay-per-click advertisers, requiring less than $100 to temporarily hijack 100,000 IP addresses. We show that theclassic defense against these attacks, called “DNS pinning,” is ineffective in modern browsers. The primary focus of this work, however, is the design of strong defenses against DNS rebinding attacks that protect modern browsers: we suggest easy-to-deploy patches for plug-ins that prevent large-scale exploitation, provide a defense tool, dnswall, that prevents firewall circumvention, and detail twodefense options, policy-based pinning and host name authorization.

dabo@cs.stanford.edu
these security goals, modern browsers implement the sameorigin 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 oneorigin, 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 e-mail, commit click fraud, and frame clients for misdeeds. DNS rebinding vulnerabilities permit theattacker to read and write directly on network sockets, subsuming the attacks possible with existing JavaScript-based botnets [24], 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, theattacker 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 twoservers 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, as shown in Figure 1. To mount this attack, the attacker did not compromise any DNS servers. The attacker simply provided valid, authoritative responses forattacker.com, a domain owned by the attacker. This attack is very different from “pharming” [34], 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 DNSserver in the attack. DNS rebinding attacks have been known for a decade [8, 36]. 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...