While I was out at OWASP, I ran into Dan Kaminsky and we started chatting about DNS rebinding - as we are known to do. Almost immediately he surprised me by saying that DNS pinning is a bad idea. After much explaining, I get why he thinks so, and I found myself nodding. It’s not because it’s not a good idea, it’s because it doesn’t work, and all the crazy ideas we’ve both collectively heard are either hugely cumbersome or are easy to break. Either way, they aren’t good solutions. So the only valid solution that has any real hope of working is respecting the host header. This means that every web enabled firewall, print server, router, switch, and internal Wiki is in danger until they too learn how to respect the host header. So yes, DNS rebinding is probably here to stay.
Now, I’ve had a thought for a while about another attack that can be leveraged because of DNS rebinding - and that is session fixation. So here’s the scenario. Attacker goes to goodguy.com and logs into his account there. Then he takes the cookies that goodguy.com set in the attacker’s browser and he writes up a little script on badguy.com to set the same cookies. The attacker also has a DNS server that sends a DNS response with a time to live of only 1 second. Then the user comes to badguy.com and gets the cookies meant for goodguy.com but which are only visible on badguy.com. Then a piece of JavaScript redirects the user back to badguy.com in 2 seconds, (one second longer than the TTL on the badguy.com DNS response) and the attacker shuts down the firewall on badguy.com so the user cannot reconnect. The browser rebinds DNS, making a second DNS request in the process. This time the attacker responds to the user’s badguy.com DNS request with goodguy.com’s IP address. Since goodguy.com doesn’t respect the host header, the cookies that the attacker set now work flawlessly even though the user is sending the host header of badguy.com in each request. The attacker can’t control cookies on goodguy.com but they can on badguy.com, which is where the browser still thinks it is. The important part here is that the user is now not only on goodguy.com but actually inside the attacker’s account for which the attacker had the cookies (assuming the cookies haven’t timed out or became invalid - and assuming they weren’t in some other way tied to the attacker’s browser/IP, etc…). How this is useful? Well that’s for perhaps another post, but think of this as a great way to perform a certain sub-class of session fixation. The moral of the story - respect the host header, especially if your site has client-based authentication credentials! More about this to come…