DNS rebinding can bypass browser same origin policy
Security, Web Development August 2nd, 2007 - 2,934 viewsArtur Bergman posted an interesting story yesterday on O’Reilly Radar titled Your browser is a tcp/ip relay. In the post, Bergman explains a new technique that could allow malicious code to bypass the same origin browser security model. The article credits security researcher Dan Kaminsky with discovering the loophole, though it appears to have been around for a while.
The attack is fairly simple (to explain, at least). The attacker first configures their DNS server so that query results have a very short time to live (TTL) — say 10 seconds. The victim connects to attacker.com, and loads the site as usual. The DNS server is immediately reconfigured to resolve attacker.com to a different IP address (say, 10.0.0.1). After the TTL expires, JavaScript on the victim’s browser makes another request to attacker.com, in compliance with the same origin policy. But this time attacker.com resolves to an internal IP address (10.0.0.1), allowing the attacker to remotely access a private network.
I spoke briefly to OpenDNS founder David Ulevitch about the exploit. Though the concept is fairly simple, we agreed that it would be difficult to perform this sort of attack in practice. An attacker would need to have intimate knowledge of the victims internal network, or rely on Flash or other web technologies to perform a network scan. Moreover, an attack would end as soon as the victim closed their web browser.
Nevertheless, a vulnerability clearly exists, and it could be difficult to resolve. Many web sites rely on round robin DNS configurations for load distribution. Since round robin configurations may legitimately return different IP addresses for the same host name, distinguishing malicious DNS rebinding attacks from round robin configurations will be difficult, if not impossible to do.
August 2nd, 2007 at 9:50 pm
This is why we should all use OpenDNS right?
August 2nd, 2007 at 10:11 pm
Hah. That was the response I was looking for when I contacted David, but he’s too humble (and honest). I don’t think OpenDNS will solve this particular problem, unfortunately. But everyone should use it anyways =p.
August 2nd, 2007 at 11:26 pm
The thing with this theoretical attack, and while I know Dan well and love the guy, I’m considering this only theoretical right now…anwyas, the thing with this attack is that most browsers cache the result regardless of TTL.
The system version of getaddrbyhost() doesn’t ever return a TTL so a browser has to make up its own choice. It might be a day or an hour or a $count of requests. Either way, this seems like more theory than practice… I’d like to see it used.
August 3rd, 2007 at 12:03 am
I was under the impression that the browser would call gethostbyname() for each request and rely on the local DNS resolver in the operating system to cache the host name resolution until the TTL expired.
I know that browsers will cache the original host name that was requested, and send it along in the HTTP headers. This is part of the same-origin policy, so web servers should be able to stop some of these attacks by explicitly setting the virtual host (i.e., not having a wildcard vhost for the server). More sophisticated socket-based attacks that use the Flash 9 socket library would be more difficult to detect/block.
I’ll have to look into this a bit further.
August 3rd, 2007 at 9:31 am
David is right. According to gethostbyname(3) man page, a call will return struct hostent defined in netdb.h (this is on Linux). It doesn’t include TTL. So javascript in theory should have no reason to contact DNS again.
This behavior is explained in greater detail here - http://tenereillo.com/, in the context of DNS-based GSLB and why it won’t always work as expected.
The attack can work only if javascript code explicitly tries to re-look up something in DNS - for example, via AJAX to server side which contacts DNS. This can be a real scenario for a complex long-running web-based app, but I can’t think of any real-life examples.
August 3rd, 2007 at 11:06 am
I read that Radar article sometime yesterday as well and my exact thoughts were “yeah, that’s going to take some effort to pull off”. Assuming said attacker somehow did the actual exploit well, as previously mentioned they would have to know my internal network structure and where all the good stuff was kept. However, I can imagine that they would be able to write some malicious code to easily mess with common Linksys, Netgear, etc. users with predictable intranets and the such, if not just search it.
August 6th, 2007 at 9:33 pm
Stop posting crap in a manner that makes it appear as if you wrote it. Your trying to pass off other peoples work and opionions as your own…your lame you dorky loser.
August 6th, 2007 at 10:23 pm
dnix, wtf are you talking about? I made it clear in the first sentence that I didn’t come up with the vulnerability, or break the news. And I linked to several sources that provide additional information. I posted about this because it’s interesting news. If you don’t think so, you don’t have to tread my site. Thanks.
August 8th, 2007 at 5:58 pm
[…] 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 […]