DNS Rebinding Video
I decided to throw together a video for those of you who are still having trouble wrapping your heads around DNS Rebinding. It’s my first attempt at making a video so there are zero frills, but if and when I make future videos, I may improve that. Most importantly, hopefully this will help explain the details for those of you who aren’t super clear on the problem:
And yes, Raf and JJ - I wore the shirt just for you.
December 1st, 2009 at 9:07 am
The shirt…I…can’t…look…away…..
December 1st, 2009 at 10:41 am
Ok, so the idea is you can make requests via js or flash to your same domain while you are actually contacting another website…
…but would you have to switch back and forth between your ip and the “secondary” one to actually retrieve that information?
i.e. : the attacker sends Mr.dude to google instead of evil.com,
Mr.dude unwillingly searches stuff on google in a 0×0 iframe, now how does the attacker get that info back if not by switching the ip back to his own? or can he retrieve the info via subdomains of evil.com?
December 1st, 2009 at 10:47 am
Absolutely awesome. I haven’t read anything about DNS rebinding before so this video was a new subject for me.
Thanks for the explanation.
December 1st, 2009 at 10:54 am
@Andrew - I’m glad I could enchant your senses.
@Mystic - you don’t have to contact the same domain (rebind again) although you could if you could somehow DoS the site. A more reasonable solution though is to do a cross domain post to another subdomain that isn’t blocked that you use for logging.
@wojtek - glad you got some value out of it!
December 1st, 2009 at 11:24 am
Nice video, there is a paper “Protecting Browsers from DNS Rebinding Attacks” from Collin Jackson which explains how this attack can be performed.
December 1st, 2009 at 6:48 pm
Very nice video.
The only question I have after watching concerns the solution. Do ‘popular’ web servers and/or frameworks currently support the ability to verify the Host header before processing the request (and discarding the request if it does not match)?
I’m asking this from an assessment side - is this something that should be reported during web app pen tests? If no solution exists, telling web app owners about the issue doesn’t help and instead we should probably focus our pressure on web server (or framework?) vendors to support this fix.
Additional question: does enforcing the Host header break anything? Or can anyone provide any examples of something that it might break? (Proxies should still work fine with this change, right?)
Again, excellent video, I’m going to be sharing it with colleagues.
December 2nd, 2009 at 12:39 am
Very nice explanation, it showed a new way of exploiting DNS TTLs for me - very informative. Looking forward to your next videos.
December 2nd, 2009 at 2:47 am
RSnake, thanks a lot!!! I’ll watch it once I get back to home.
I love your blog for it keeps giving me suprise here. I’ll wait for your next pose.
December 2nd, 2009 at 11:51 am
Excellent Post !
Two questions:
Does the ‘Host’ header have some secondary advantages for software stacks to not check it (inspite of knowing that it fixes a big issue)?
Secondly, Kaminskys DNS bug was swiftly fixed by vendors as it affected servers and the threat impact was high. DNS rebinding seems equally potent and also easy to achieve for hackers. So why is there no movement to get this fixed soon (atleast by popular software stacks)? I ask this because i am intrigued by your comment that you see this problem lingering for 5-10 years atleast.
December 2nd, 2009 at 12:30 pm
@nickhacks - I’m on the fence, because again, it’s sorta the way the Internet works. But yes, I’m starting to report it more and more, especially because of how it can be used in tandem with other exploits. Enforcing the host header has no negative issue for the vast majority of the sites. In Google’s case, I’m sure there are lots of robots out there that are scraping them that would suddenly no longer be able to. It may also be easier from a configuration perspective, but those are edge cases.
@Arun - Yes, one example would be when people have http://example.com and http://www.example.com both resolving to the same IP address. They don’t want to worry about having to create virtual hosts for each of them. But beyond that, no, there’s really no difference.
The second question is tougher. There’s no easy way to fix this bug. You might get some software manufacturers like Apache Foundation and Microsoft via IIS to do more education or make the configuration of those options more clear/easier. But that would only work for sites that use those options and only from now forward. All existing web servers would still be vulnerable. But beyond that I haven’t heard any solutions that I think have any likely chance of working.
December 2nd, 2009 at 7:16 pm
You could fix this easily on the webapp side…
i.e. if($_SERVER[’HTTP_HOST’] != $sitename) die(”DNS Rebinding?”);
or through a simple regex to avoid having to write this for every subdomain…
December 2nd, 2009 at 11:27 pm
Wow, excellent video!
Thanks for taking the time to do this, this was the clearest explanation I’ve seen so far.
Great Work!
December 4th, 2009 at 10:16 am
Excellent stuff! flawless explanation!
December 4th, 2009 at 3:51 pm
Regarding the Session Fixation and setting cookies - cookies have an attribute called HOST that is set based on the DNS host name, e.g. internalwiki.biz.com. If I set a cookie for evil.com then the browser won’t send that cookie to internalwiki.biz.com even if the IPs are equal, but this seems what you are suggesting. Am I missing something?
December 8th, 2009 at 3:59 pm
Matt:
Lets say that the original address is 1.1.1.1 for “evil.com”
and rebound address is 1.2.3.4.
The browser will not be sending the cookie to internalwiki.biz.com - it is not the Domain Name that is altered here, but the domain name’s IP address. It will still be accessing evil.com, but will think evil.com has Moved its location to another IP address. And if the internalwiki server does not do HOST checking, then any cookies set on evil.com will be valid for evil.com on that new IP address. It does not allow you to modify cookies from another domain name however.
December 9th, 2009 at 8:49 am
@StarliteShadow - Correct with one minor exception. If the IP 1.2.3.4 sets a cookie javascript on evil.com will be able to read it. Lots of sites use cookies as nonces to prevent CSRF. Rebinding would allow that system to be defeated.
December 9th, 2009 at 10:29 am
Got it, thanks.
December 9th, 2009 at 2:05 pm
what about recursive dns servers doing query response filtering? that would stop dns binding attacks against internal hosts (behind your firewalls). if your recursive dns servers don’t allow public domain names to be translated into rfc1918 addresses then your internal network should not be at risk.
December 9th, 2009 at 7:14 pm
@RSnake
“If the IP 1.2.3.4 sets a cookie javascript on evil.com will be able to read it.”
I’m pretty sure it’s impossible. I did tests using js and http headers in firefox.
The only tricky thing you can do with cookies is passing values to sub-domains.
December 10th, 2009 at 7:43 am
@h3xstream - maybe I wasn’t clear:
[~] telnet www.whatever.com 80
Trying 1.2.3.4…
Connected to www.whatever.com.
Escape character is ‘^]’.
GET / HTTP/1.1
Host: www.evil.com
HTTP/1.1 200 OK
Date: Thu, 10 Dec 2009 14:41:24 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: Apache
Transfer-Encoding: chunked
Set-Cookie: whatever.comsupersecretcookie
…
If it doesn’t matter if the host mis-matches and 1.2.3.4 sets a cookie, www.evil.com can read it when it is set (via XHR).
December 10th, 2009 at 7:45 am
@bsdwiz - that might break stuff, but it’s been discussed before. I mentioned that in the Threatpost podcast, actually. http://threatpost.com/en_us/blogs/robert-hansen-dns-rebinding-attacks-and-browser-security-120409
December 10th, 2009 at 10:13 am
thanks for the response RSnake.
“that might break stuff” - white lists should be provided for any ligitamate rfc1918 mappings. after doing a little bit of research i see that this is already a service provided by OpenDNS. also, have you checked out dnswall?
seems that should at the very least narrow the attack vectors.
thanks,
December 10th, 2009 at 10:40 am
@bsdwiz - sure, sounds like a pain. I can’t think of any good valid reason someone would want to surface RFC1918 externally, but I’ve definitely seem some very large companies that do it, probably because they don’t understand DNS separation. DNSwall looks interesting. It would need to be deployed on every DNS resolver everywhere to solve the problem - so again, probably not happening any time soon, but it’s a nice point solution if it works as advertised.
December 10th, 2009 at 10:42 pm
i misunderstood what you meant in the previous comment.
just another thought, host verification seems pretty limited since flash and java applet can open socket “on the same domain” and spoof the host.
December 11th, 2009 at 1:58 pm
@h3xstream - My understanding is that both Flash and Java fixed that problem a year or so ago. Can you re-produce that, or were you speculating? If it’s reproducible, you’re absolutely right and you should file a bug.
December 11th, 2009 at 6:52 pm
yup you’re right. I’ll do more tests next time..
there is dns pinning for the domain of the page. (i only test it with java applet)
December 12th, 2009 at 12:09 pm
Hi RSnake. It’s a great video.
Your case for some of these vectors is stronger than for the others. For example, setting cookies that can be cross-sited is a cool vulnerability.
On the other hand, getting remote hosts to contact Google on your behalf seems like a weak vector. If you can rebind evil.com to a Google IP address (let’s say it’s one of their cache servers) and get the client to do your dirty work, then how is that any different from creating a normal A record google.evil.com => 74.125.95.132. Does that not give you the same parent origin for your scripts?
December 14th, 2009 at 8:29 am
Nice work Robert, I have a question though about the session fixation.
Since the browser security is nil on the victim’s end with scripts on, why the attacker will bother to go through dns rebinding? Using jscripts/ajax he could connect to some popular sites (forcing a connection from the client’s end with js in other words) then if the victim’s browser accesses these sites (eg: on a different browser tab) later on, he has everything, same session/cookie the attacker initiated etc.
Cuz the session will be pulled in from the active scripts in the first place and can be transmitted to the evil server or whatever info from this kind of connection can propagate. All it takes is the js to be enabled on the browser. Unless I am missing something with the latest browser patches as I mostly block js.
December 14th, 2009 at 7:07 pm
@Robert - no, that definitely doesn’t work. The same origin policy applies to subdomains and even to ports.
@Mark - JavaScript can’t read content on another domain that it’s not running on because of the same origin policy. Session fixation can be forced via forced POST submissions in many cases, but not all - like when there’s a nonce on the login page in a hidden form field for instance. But DNS Rebinding would work even in that case.
December 17th, 2009 at 2:36 am
“There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks.”
Are you saying that’s not true now?
December 17th, 2009 at 12:39 pm
@Robert - I’ve never found that to be true in my tests, but maybe my tests weren’t performed well. If you can create a demo, that’s great. I’ve just never seen that technique work, in anything other than trying to fool deframing scripts, and that’s not cross domain, really - so it’s a different implication. But you’re right, if that did work, that would make it unnecessary to do DNS Rebinding in the same way having XSS on the site would.
December 18th, 2009 at 4:31 pm
LOVE that shirt … no seriously!
…oh, and good video since I finally got enough time to watch it at 12:30 ..
December 21st, 2009 at 4:47 am
Hey Robert,
nice Video, nice shirt. It’s a very good visualisation and should help a lot of people to understand the problems occuring with DNS rebinding attacks.
December 21st, 2009 at 1:50 pm
Really nice video, keep up this good stuff.
December 22nd, 2009 at 6:27 pm
great video….. pretty shirt
December 26th, 2009 at 3:36 pm
I’m currently studying computer science in Germany and I’m really interested in web security. I already know pretty much about sql-injections and XSS(this is how I found your website a few days ago) and this Video gave me a lot more understanding of how the web works.
Thanks!
January 8th, 2010 at 8:13 pm
I see now, the superdomain trick works for gaining access to the parent, but not the other way around. Having google.evil.com point to a cache server actually enables Google to hack evil.com… interesting.
January 8th, 2010 at 8:15 pm
So, here’s what you do. You point google.evil.com to the cache server, then you set up your own script on eviler.google.evil.com and voila DNS rebinding is not needed?
January 21st, 2010 at 5:18 pm
lmfao! you wore the shirt. bahahaahaha! priceless.