Rebinding attacks unbound Federico Biancuzzi, 2007-10-17 NS rebinding was discovered in 1996 and affected the Java Virtual Machine (VM). Recently a group of researchers at Stanford found out that this vulnerability is still present in browsers and that the common solution, known as DNS pinning, is not effective anymore. In August, SecurityFocus covered the resurgence of interest in the attacks at the Black Hat Security briefings in Los Vegas. " Pinning is no longer a sufficient defense against DNS rebinding because modern browsers contain many different technologies that permit network access, such as Flash and Java " Adam Barth, PhD student, Stanford University Federico Biancuzzi tracked down one of the authors of the study, Adam Barth, to learn about the impact of the problem, which workarounds can be deployed right now, and how to protect browsers from DNS rebinding attacks in the long run. SecurityFocus: Could you introduce yourself? Adam Barth: I'm a Ph.D. student at Stanford University and a member of the Stanford Web Security Lab. Collin Jackson, Andrew Bortz, Weidong Shao, Dan Boneh, and I are presenting a paper at the 2007 ACM Conference on Computer and Communications Security, detailing how to protect browsers from DNS rebinding attacks. What is DNS rebinding? DNS rebinding is a vulnerability in Web browsers and their plug-ins that can be exploited to circumvent firewalls or to temporarily hijack a client's IP address, effectively converting browsers into open network proxies. Users rely on their Web browsers to isolate sites they visit using the same origin policy: one site should be able to read and write data only from itself. DNS rebinding vulnerabilities permit an attacker to confuse a Web browser into aggregating a target server into his or her origin, allowing the attacker to communicate with that server through the browser. These attacks work because browsers and plug-ins use DNS host names to distinguish between different origins, but browsers don't actually communicate with the hosts by name: they must first use DNS to resolve the host name to an IP address and then communicate with the host by its IP address. Consider a host name, such as attacker.com, that is first bound to the attacker's Web server. The attacker can load JavaScript, Flash, or other active content into the attacker.com origin in the browser. If the attacker then rebinds attacker.com to point to the target's Web server, that active content can now read and write on sockets to the target server. What type of attacks can it be used for? These vulnerabilities can be used for two types of attacks. First, DNS rebinding can be exploited to circumvent firewalls. If a user inside a corporate network views malicious content (delivered, for example, as an advertisement on a reputable Web site) the attacker can open network connections to any machine behind the corporation's firewall, through the browser. Using these connections, the attacker can ex-filtrate confidential documents, exploit unpatched vulnerabilities in network services, or otherwise abuse network services relying on the firewall for protection. Second, DNS rebinding can be exploited to temporarily hijack a user's IP address to send spam email or defraud pay-per-click advertisers. Filtering spam relies heavily on black-listing IP addresses known to send spam. Using DNS rebinding, an attacker can send spam from the IP address of every client viewing his or her malicious content, avoiding these black lists. Similarly, the pay-per-click advertising schemes used by most advertising networks rely on filtering fake clicks by examining the patterns of clicks by each IP address. Using DNS rebinding, the attacker can launder his or her clicks through hundreds of thousands of unsuspecting Web browsers. These attacks are extremely cost effective, because the attacker needs only for the client to display his or her malicious content. Advertising networks sell impressions for tens of cents per thousand. We ran an experiment where we ran a Flash advertisement containing a DNS rebinding attack (against ourselves) on an advertising network and were able to hijack 30,000 unique IP address for $30, an order of magnitude cheaper than building a traditional bot network. What is DNS pinning? DNS rebinding vulnerabilities were first discovered in 1996 as an attack against Java. The classic vulnerability was fixed by the Java Virtual Machine preventing host names from changing from one IP address to another -- a defense that came to be known as DNS pinning. Since 1996, pinning has been steadily weakened in Web browsers because it reduces robustness by preventing one server from failing over to another server. In fact, pinning was removed from Firefox in version 1.5. An attacker can cause modern browsers to release their pins in about one second. Why isn't it enough to protect us? Pinning is no longer a sufficient defense against DNS rebinding because modern browsers contain many different technologies that permit network access, such as Flash and Java. These technologies have separate pin databases, but are permitting to communicate within the browser. This allows the attacker to pin one technology, say JavaScript, to his server and simultaneously pin another technology, say Java, to the target server. The attacker can then use LiveConnect (a feature that bridges Java and JavaScript) to communicate with the target server -- effectively rendering the DNS pins useless. Can the OS do something to defend the browser? Organizations can protect themselves against firewall circumvention by configuring their DNS resolvers not to bind external host names to internal IP addresses; for example, by deploying Google DNS Wall. This prevents the attacker from binding attacker.com to an internal machine, foiling any rebinding attack against internal machines. Defending against IP hijacking is more difficult because there is no simple method of separating malicious host names from honest IP addresses. In the short term, plug-in vendors can patch their technologies to default to denying socket access to active content unless the socket's destination explicitly allows access from the content's origin. Flash already has a policy mechanism it could leverage to this end; but, unfortunately, applying this approach to Java would break some existing applications. In the longer term, DNS rebinding vulnerabilities can be prevented using host name authorization -- a technique for embedding the set of authorized host names for an IP address in DNS. Web browsers and their plug-ins can consult this set and prevent the attacker from binding his or her host name to a target server. This defense requires browser vendors and server operators to cooperate in order to be successful. How do current browsers use DNS? This part gets very technical in the paper. Some browsers attempt to pin DNS entries, but virtually all Web browsers can be reliably forced to unpin in approximately one second (the one modern exception is Opera 9, which requires four seconds). The one browser that seems relatively resistant to DNS rebinding is the browser inside the Nintendo Wii. However, in our experiments we found that some PlayStation 3 Web browsers were vulnerable. Is there any browser that is not vulnerable? In our testing, the most secure configuration we found was Safari running on a Mac without Flash and without a proxy. This configuration avoids the multi-pin attacks because Safari does not support LiveConnect and the configuration does not include Flash. Additionally, Safari on Mac seems to correctly pin for several minutes (unlike other browsers which can be made to unpin in one second). We did not test Konqueror in our lab. In our experiment, we only observed five Konqueror impressions (out of 50,000 impressions) and did not attempt rebinding on any of them. Would using one single pin cache improve the situation? A common pin database shared by all the technologies in the browser could help defend against rebinding attacks, but there are several limitations to this approach. Replacing the operating system's DNS resolver with a pinning resolver would break the standard semantics of DNS for non-Web applications, and browser vendors appear unwilling to provide their plug-ins an interface to their DNS pins. Worse yet, not all browser technologies are located on the same device. For example, it is difficult to share a common pin database with a proxy server. What happens if we are using a HTTP proxy to browse the Internet? Browsers behind HTTP proxies are more vulnerable to these attacks because the proxy is yet another technology that resolves host names. If the attacker embeds a Java applet in his or her Web page, the JVM is unable to pin correctly because it requests the applet by name from the proxy server (which does the DNS resolving). If the applet later attempts to open a socket to attacker.com, the JVM permits this socket connection to go to any IP address. Do browsers behave differently if we are using a HTTPS connection? HTTPS offers no protection against rebinding attacks. Because the attacker owns the domain name involved in the attack, he or she can legitimately obtain an SSL certificate and serve the malicious content over HTTPS. Additionally, HTTPS provides no protection to target servers because the attacker has direct socket access and can correctly negotiate an SSL tunnel. Would DNSSEC help? DNSSEC provides no protection against DNS rebinding attacks. DNSSEC is concerned with ensuring that all DNS records are valid and authoritative. This is intended to prevent pharming -- an attack which involves compromising a legitimate host name, such as bank.com, but does not prevent rebinding because the attacker is able to sign whatever DNS records he or she wishes for attacker.com. Is there any workaround that we might deploy quickly? One workaround is to install the NoScript plug-in for Firefox. Unfortunately, this disables many Web features that users enjoy. End users, unfortunately, have to wait for browser and plug-in vendors to fix this vulnerability. Did you discuss the topic with vendors? And if so, what did they say? We're working with vendors to help them fix their rebinding vulnerabilities, but we're unable to disclose details about those discussions until the vendors issue patches. However, some of our work with vendors is public; for example, we attended a Firefox security round table about DNS rebinding. In the long term, what solutions could we use and which ones do you think will actually be chosen? I'm hopeful the vendors will reach a consensus to fix these issues using host name authorization, but this requires the vendors to cooperate with each other. One way to bootstrap this cooperation is to leverage existing deployments of this policy in the form of crossdomain.xml files. Flash uses these files to authorize HTTP connections to different origins, but they contain enough information to help prevent rebinding attacks. There is no easy patch for DNS rebinding because it is a vulnerability in the Web's design, but hopefully we will be able to fix the vulnerability without breaking existing applications or disrupting users.