Does DNS pinning protect against all DNS rebinding attack?

Question

I found an example of a DNS rebinding attack scenario in the paper "Dynamic Pharming Attacks and Locked Same-origin Policies for Web Browsers".

Figure 1: An example of a dynamic pharming attack against www.vanguard.com. (1) Initially, the pharmer arranges for the victim’s DNS queries for www.vanguard.com to resolve to the pharmer’s IP address, 6.6.6.6. (2) Then, when the victim visits www.vanguard.com, the pharmer returns a trojan document containing malicious Javascript and a iframe referencing Vanguard’s home page. (3) The pharmer then updates the DNS entry for www.vanguard.com to the IP address of Vanguard’s legitimate server and denies subsequent connections from the victim. (4) This causes the victim’s browser to renew its DNS entry for www.vanguard.com, and (5) load Vanguard’s legitimate home page in the iframe. (6) After the user authenticates herself, the malicious Javascript in the trojan document hijacks her session with the legitimate server.

Now it seems browsers today implement a feature called DNS pinning. From Wikipedia:

Web browsers can implement DNS pinning: the IP address is locked to the value received in the first DNS response. This technique may block some legitimate uses of Dynamic DNS, and may not work against all attacks.

My question is: does this countermeasure effectively protect against the described attack scenario? If so: what are some examples of attack scenarios that are not successfully protected against (see claim in Wikipedia quote)? If not: what's the reason why the attack succeeds and how could you succesfully protect against it?

Answer 1

If you want to take into account the totality of content that can be executed from within a browser, then the browser alone performing DNS pinning would not be enough. Browser plugins such as Flash and Java can have socket access and that means they could very well be performing DNS queries themselves and if they do not implement a strategy of DNS pinning themselves, then the browser would still be vulnerable by proxy. See http://crypto.stanford.edu/dns/ or Google for "Protecting Browsers from DNS Rebinding Attacks" by Jackson et al. for further details.

Answer 2

I'll try to answer my own question with the help of an example attack I was linked to. Feedback and remarks are welcome, because I'm unsure about the correctness of this answer.

Yes, DNS pinning would prevent the described attack, although it needn't make the situation safe altogether. Imagine this:

1. Initially, the pharmer arranges for the victim’s DNS queries for www.good.com to resolve to the pharmer’s IP address, 6.6.6.6.
2. Then, when the victim visits www.good.com, the pharmer returns a trojan document containing malicious Javascript and a iframe referencing www.good.com/homepage. The pharmer also makes sure the Cache-Control header specifies a very high max-age value.
3. The pharmer then updates the DNS entry for www.good.com to the IP address of Good’s legitimate server and denies subsequent connections from the victim.
4. This causes the victim’s browser to renew its DNS entry for www.good.com, which the browser will not allow due to DNS pinning.
5. The DNS pinning will cause the iframe source to be fetched from the pharmer's IP address (6.6.6.6/homepage).
6. The request is denied by the pharmer's server and the user gets to see an error.

When the victim opens its browser again some time later, and tries to access www.good.com

1. The cached version of the page is loaded into the browser, regardless of the DNS records, including the malicious Javascript.
2. The iframe will be loaded again, because Cache-Control header does not apply to the content in iframes (this claim needs some backing up).
3. The iframe content will point to the correct server, because the DNS record is fixed
4. Good’s legitimate home page is loaded in the iframe.

What are some examples of attack scenarios that are not successfully protected against?

In addition to the scenario described above, an example attack scenario of a different kind is given in a comment on Mozilla's Bugzilla site, regarding a problem with DNS caching.

DNS TTL information is not something that a single application should decide it doesn't want to abide by.

There has been some discussion that the current behavior is a "security" issue. Refusing to abide by the TTL parameter from a DNS lookup is every bit as large of a security hole, perhaps larger. Using a cached, expired DNS lookup (such as for those users using dynamic DNS services,) will end up sending the wrong information to the wrong server, possibly an e-vil server.

Possible scenario:

1. My home server, using DHCP, receives a dynamic IP address of 12.13.14.15
2. I register the dynamic service myhome.dyndns.org to point to 12.13.14.15
3. User Alice visits my web site, using Mozilla, and begins a transaction.
4. My DHCP lease expires and I am given a new IP address of 12.200.200.200
5. My server detects the change and automatically registers myhome.dyndns.org to 12.200.200.200
6. My old DHCP address, 12.13.14.15 is given to Bob Evil's computer.
7. Alice finishes filling out a web form in Mozilla and submits it. Mozilla erroneously uses the cached IP address 12.13.14.15, and the data is incorrectly sent to Bob Evil's computer.

This has actually happened for me. I've ended up hitting other peoples' DSL routers (if they have no web site set up) instead of my own server with Mozilla, even though I've registered a new IP address.

Answer 3

DNS pinning does not protect against sophisticated DNS rebinding attacks.

Consider a scenario where an attacker sets up a firewall in front of their web server. You request their website, attacker.com, which results in a DNS query returning their IP address. The DNS result has a TTL (time to live) of 1 second. Normally, this means the browser should make another DNS request after 1 second has passed, however, DNS pinning instructs the browser to ignore the TTL and add some unit of time (say one hour) to it. So now, your browser won't make another DNS query for that hostname for 1 hour, 1 second. After the DNS query completes, your HTTP request is sent and the attacker sends back the website you requested with javascript code which will launch the attack.

Now, the attacker's Javascript has set up an AJAX request which waits two seconds before firing. Then it automatically requests some resource on the attacker's website again. However, the request fails. This is because the attacker has already set up a firewall rule blocking your browser's request. Now we are in the following state:

1. The TTL has expired on your first DNS request, but DNS pinning is still in effect
2. You made a request back to the attacker's website via their JS AJAX call
3. The request was dropped by the attacker's firewall

These three things will cause your web browser to send another DNS query despite the fact that you are using DNS pinning. In effect, the attacker has easily defeated your DNS pinning strategy by using a firewall and sending a second request outside of the TTL. DNS pinning isn't an effective strategy because there are plenty of legitimate reasons why someone's server might be down; your browser is forced to make a second DNS query in case there is another DNS record that will resolve to the correct machine (e.g. in case of a server migration, downtime, whatever). Basically, your browser has no way of knowing whether or not it's actually being attacked here; for all it knows, the server is legitimately down and so, it MUST make another DNS request.

So... why does it matter that there's a second DNS request?

The second DNS request is usually used by the attacker to return an incorrect IP address for the DNS record. Browsers have what is called a "same origin" policy which prevents webpages from making requests of resources that they do not own. Basically the way same origin works is that it says http://hostname.com can only request http://hostname.com. But it actually works using the IP address for hostname.com, not the human readable hostname itself. So in a DNS rebinding attack, when your browser makes the second DNS query that I described earlier, the attacker will return a "fake" IP address in the DNS query result. Then your browser will think, for example, that the IP address 1.1.1.1 belongs to attacker.com even though it really belongs to google.com. This allows the attacker to exploit the same origin policy of the browser; now the attacker's javascript can request stuff from google.com via AJAX. Also, they can read and set cookies and other malicious stuff. This exploits same origin policy by tricking the browser into trusting the second DNS record that was returned. Now the browser thinks hostname.com is associated with the IP address 1.1.1.1 even though it really isn't. What's a browser to do? DNS doesn't have that kind of authentication built in. :(

Preventing the DNS rebinding attack

There are a bunch of ways to prevent it, and I'm pretty sure modern browsers already have implemented protection against these attacks. One easy way to prevent it (as a web owner) is to check the HTTP host header of a request. For example if you are google.com then you would receive a request but the host header would still say attacker.com. Obviously that isn't part of your domain, so you can prevent the attack simply by dropping the request. Why would someone want to do this to begin with? Well, click fraud in advertising. Scraping search engines from many machines at once. Stealing valuable data from web sites on your internal company network. Etc.