I wrote last week about how DNS rebinding can bypass browser same origin policies. Since then I found a paper titled Protecting Browsers from DNS Rebinding Attacks that describes rebinding attacks in greater detail. It turns out that there are several varieties of rebinding attacks, and a couple of proof-of-concept DNS rebinding demonstrations already exist.

To perform a DNS rebinding attack, an attacker initially answers DNS queries for their domain with the IP address of their server, and a very short time-to-live (TTL). Using javascript, or some other mechanism, the attacker initiates a second request to their domain from the victim’s machine. Since the TTL has expired, another DNS query is sent to the attacker’s DNS server. This time, the server responds with the IP address of a target server that the attacker wishes to connect to (e.g., an internal web server).

Modern browsers implement a security mechanism called DNS pinning as a partial defense against DNS rebinding attacks. Once a browser resolves a host name to an IP address, the browser caches the result for a fixed duration regardless of the TTL (the cache duration varies quite a bit: 1 second for Safari 2, 120 seconds for Firefox 2, and 30 minutes for IE7).

But browser plug-ins maintain their own pin databases, creating a new class of multi-pin vulnerabilities. After the browser resolves an attackers host name, subsequent network connections from Flash or Java LiveConnect will trigger additional DNS queries. Thus, an attacker can pin one IP address to the browser, while pinning a second address to Java or Flash. Browsers allow inter-technology communication between plug-ins and the browser, so transmitting data between components is trivial.

Moreover, the Stanford research paper describes a number of techniques for bypassing the browser’s internal pinning mechanism, and performing rebinding attacks without relying on third-party plug-ins. It turns out that an attacker “can cause the browser to release its pin after as little as one second by forcing a connection to the current IP to fail, for example by including the element <img src=”http://attacker.com:81/”>.”

If you’re still questioning whether this sort of attack could be carried out in the real-world, the researchers at Stanford “tested DNS rebinding experimentally by running a Flash 9 advertisement on a minor advertising network… The experiment used two machines in our laboratory, an attacker and a target. The attacker ran a custom authoritative DNS server for dnsrebinding.net, a custom Flash policy server, and an Apache web server hosting the advertisement. The target ran an Apache web server to log successful attacks.” The results show that the experiment was “successful on 30,636 (60.1%) impressions and 27,480 unique IP addresses.” After running the experiment for three nights, the researchers “obtained 100.3 machine-days of network access.”

That’s proof enough for me, but for you seeing-is-believing folks, make sure you check out the proof of concept attacks for your browser, Java LiveConnect, and Flash 9.