DNS rebinding attacks, also known as anti-DNS pinning attacks, have been around for at least a decade, but they...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The advent of Web 2.0 technology and its use of browser plug-ins to provide ever increasing functionality on the Web, has introduced vulnerabilities that once again make DNS rebinding a viable attack. Normally attack methods evolve in cat-and-mouse fashion; as the sophistication of attacks increase, application code is hardened in response. With DNS rebinding, however, the balance has shifted in favor of the attack method.
The emergence of multi-pin vulnerabilities
Modern browsers implement what's called the same-origin policy, a security feature that attempts to isolate distinct "origins," protecting sites from each other. But the same-origin policy can be subverted by confusing the browser into grouping network resources controlled by distinct entities. The plug-ins and the browser maintain their own DNS pin databases, and this is what the attacker exploits, thus creating a new class of vulnerabilities known as multi-pin vulnerabilities. Essentially, the local network is made to appear to be the same as the attacker's network to the browser; in effect, the attacker has created an open proxy and has access to the local LAN.
Here's how someone can take advantage of these vulnerabilities, according to a Stanford University report on DNS rebinding attacks:
An attacker exploits the interaction between the browser and a Java or Flash plug-in. The hacker then pins the browser to one IP address while pinning Java or Flash to another IP address, usually on the internal network. The result allows an attacker to read and write data directly on sockets to a host and port of the attacker's choice, all under the security context of the compromised machine's user account.
An attacker can mount a number of different attacks using the DNS rebinding vulnerabilities. Some of these will require direct socket access, such as that afforded by Flash Player and Java; others require only the ability to read HTTP responses from the target. Depending upon the attacker's goal, the Princeton report breaks the attacks into two broad categories:
1. Firewall circumvention -- Machines behind the firewall, such as a corporate intranet server, are not normally accessible to the Internet. DNS rebinding allows an attacker to bypass the firewall and gain access to these machines. Using direct socket access, the attacker can also interact with other services that are only available on the internal network, over and above HTTP. For example, if FTP is available internally, the attacker can gain access to this service and upload sensitive information to his own servers. Using this attack, criminals could target a financial institution, such as a credit card company, get account information, upload it, and sell it to the highest bidder for use by identity thieves.
2. IP hijacking -- In this case, the attacker will be able to access publicly available servers from the client's IP address, thus taking advantage of the target's trust in the client's IP address. For example, an IT consultant's client's firewall can be configured to accept remote management connections only from the IP range of the consultant's network (a security feature that my own firm uses). If an attacker hijacks an IP address in that range, he would have remote access to any of the consultant's clients' firewalls and routers. Having previously succeeded with a firewall circumvention attack against the consultant, the attacker may have discovered the login details to the bank's remote management interfaces -- a major disaster in the making. The attacker could then add his IP address to the access control lists and direct traffic to his servers and websites.
DNS rebinding defenses
At least three defenses are currently effective against these attacks. (As research on this attack continues, additional defenses are likely to develop.) The first is to block the resolution of external names into internal addresses. OpenDNS, a San Francisco-based company that provides a free DNS service designed to help companies avoid malicious websites, which provides a simple strategy. According to CEO David Ulevitch, an enterprise can get protection by using OpenDNS servers in its network configuration and setting its DNS servers to 188.8.131.52 and 184.108.40.206. This OpenDNS filter aims to protect and block users from malicious DNS responses, ones that resolve to a host inside of your network.
A corporate network would normally use internal DNS server addresses, but it's a simple matter to point the DNS forwarders to OpenDNS, or configure the gateway to block addresses that resolve to local network computers. To that end, OpenDNS and other providers offer Dnswall, a daemon that filters out private IP addresses in DNS responses. It's designed to be used in conjunction with an existing recursive DNS resolver in order to protect networks against DNS rebinding attacks. Dnswall prevents external names from resolving to internal addresses.
The second method is to block execution of all browser scripts unless they are approved. In Internet Explorer, this is done by disabling active scripting. Firefox users have a much more elegant solution in the form of a browser extension: NoScript. The extension only allows execution of scripted content and plug-ins by user permitted websites.
Finally, of course, change the default password on routers, switches and any other configurable device on the network. Where possible, run in a user account with the minimum privileges that allows you to get your work done. DNS rebinding could be a serious threat to your network security, but one that is easily prevented by implementing some simple security measures.
About the author:
Ken Harthun is a systems engineer at Connective Computing Inc., specializing in network and desktop security for small and medium businesses. He has been working with computers since 1973 and advocating sensible security practices since 1989 when one of his employees infected a company computer with the Stoned virus. He quickly isolated the infected diskette and implemented strict security policies to prevent future infections. Ken is currently working on his first consumer-oriented book on computer security.