DNS Rebinding (or what's left of it)
14 June 2008
DNS rebinding has been a widely known issue since 1996. 12 years later, the attack is still alive.
I've spent quite some time researching what's still left of the attack, and did find out that most known vectors were patched or mitigated by now. However, the attack is still very real, and could be fully exploited on most (if not all) modern browsers.
I've compiled a list of vectors that I had dealt with during this brief research. Most were discovered to have been fixed in one way or another, some only partly, but a few are still exploitable.
Disclaimer: This is not a how-to. This post deals only with what could or could not be done on today's systems. A step-by-step explanation of every vector described would be irrelevant.
Methods to break DNS-pinning in browsers:
1) Trying to load a page from a closed port (http://rebinding-domain.com:81). - Hardly works. Doesn't break the 120 second pin on Firefox. Does, however, break the half-hour pin on IE. Still, this requires a couple of reload attempts (3-6, don't know why) so it's quite slow.
2) Using the Flash or Java plugins, since they have their own pinning-database for Sockets. - This no longer works. The issue had been patched on both platforms in the beginning of 2008. Adobe has recently enhanced Flash's security model significantly. Now in order for a Flash movie to open a socket, a policy file has to come from the same IP as the destination IP of the socket connection (and not only the same domain - thus mitigating DNS rebinding).
References: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html (scroll down to "DNS hardening")
3) Shutting down (or firewalling) the HTTP server on the attackers machine in order to force the browser into a new DNS lookup. - Doesn't work on Firefox. It seems as though no matter what you try, Firefox would never give up those 120 seconds of pinning. On IE, yet again, this works after a couple of reload attempts.
4) Using the browser's cache in order to store the attack page. - Works great, but has its drawbacks. The DNS record should be altered right after the victim downloads and caches the page. If the page is revisited after the DNS pinning had expired, any XHR request would force the browser into a new lookup, and complete the attack. The obvious pitfall is that the page needs to be visited twice.
On the bright side, an attack page could be held inside an invisible iframe, well hidden from the unsuspecting user. The iframe could be located on many different sites and linked to in many different contexts. As such, even mass-attacks should be possible. A targeted attack, with the help of very basic social engineering skills, could easily work every time.
Methods to rebind DNS on the nameserver/cache level
1) 0 TTL records. - This works, but not always. Many DNS servers force a minimum TTL of 300 seconds. Some even reject 0 TTL records as invalid (rare, but I believe it happens).
2) One domain with 2 "A" records. - Works, but only on non-local IPs. If you point a domain to both 209.40.204.211 (own-the.net) and 192.168.0.1 (a local IP), the browser won't choose one of them randomly. The local IP will always be chosen. Yet, if the second IP would have been 72.14.207.99 (google.com) this method could still work. The browser would choose a random record after every lookup attempt. (you'll have to retry one or two times with different host-names). If the server on the chosen IP appears to be down (firewalled), the browser will instantly connect to the second IP, thus creating a rebinding scenario.
3) Setting up a CNAME sub-domain in order to force the DNS cache into revising the original record upon lookup (regardless of TTL).
evil.com. 0 IN A 1.1.1.1 1.evil.com. 0 IN CNAME evil.com.
- Works fine, on almost all name servers. I've seen this technique on a DefCon 15 video. A very great video on the subject, by the way. The guy shows how you could use DNS rebinding in order to VPN into a corporate network, through a web browser. Ouch. (This was possible back in 2007). Video: http://video.google.com/videoplay?docid=3470502418262982787
A realistic scenario:
1) The domain evil.com points to the attacker's server at 1.1.1.1 .
2) The victim is lured to a specially crafted page on http://evil.com, that tells the browser to cache it for a very long time ("Cache-Control: max-age=999999999, must-revalidate")
3) On the server side, the page invokes a script that alters the DNS records of evil.com and points it to the victim's server, at 2.2.2.2 . (At this point, it would be smart to use the CNAME "CNiping" trick to force the DNS cache to update. This is nicely described in the video above).
4) The attacker needs to wait between a minimum of 2 and 30 minutes (depends on the victim's browser) before proceeding. As the page is cached for a long time, there is no need to rush the attack.
5) The attacker lures the user back to the same page on http://evil.com . The page will be recovered from the browser's cache.
6) A script on the page would invoke an XMLHttpRequest to evil.com (that now points to 2.2.2.2) and finalize the attack.
Necessary "tools"
1) A domain name. Get free ones at http://afraid.org
2) A server with root access. Dedicated / VPS / compromised machine.
3) LAMP (Linux, Apache, Mysql, Php) installed on the server.
4) A DNS server (BIND 9) installed and configured.
5) Patience and time.
All of this costs me about $7 a month. Thank you, Open Source.
Conclusion
I have actually made a proof of concept based upon the scenario above, and it works fine in every browser I tested it in. Even the new, shiny Opera 9.5 is as vulnerable as the rest.
Surely you can say that the chances of conveying such an attack successfully are low, but I beg to differ. If a serious attacker would put some thought and creativity into it, he/she could easily sneak into a corporate network using the steps mentioned above.
And even if the chances of success are low, the consequences of such a penetration are severe. XHR allows you to alter HTTP headers, send GET/POST requests, and read the responses. This also allows you to send XML SOAP requests. Thus, you can pretty much own any HTTP based web service on the network.
UPnP (a control protocol supported by devices such as routers) is also based upon SOAP requests, and here is something worth reading about what arbitrary access to your UPnP device could do: http://www.gnucitizen.org/blog/hacking-the-interwebs/ (another great read, although the Flash vector no longer works).
Changing the primary DNS servers of a machine? How about that? On success, this literally means "pure ownage".
Finally, a PoC will be posted as soon as I find the time to get it done (some work is still necessary).
In the meantime, I hope you found this post helpful.
Posted by: kGen | In category: DNS | Comments (0)
