Cenzic 232 Patent
Paid Advertising
web application security lab

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.

39 Responses to “DNS Rebinding Video”

  1. Andrew Hay Says:

    The shirt…I…can’t…look…away…..

  2. Mystic Says:

    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?

  3. wojtek Says:

    Absolutely awesome. I haven’t read anything about DNS rebinding before so this video was a new subject for me.
    Thanks for the explanation.

  4. RSnake Says:

    @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!

  5. Kaio Rafael (kaiux) Says:

    Nice video, there is a paper “Protecting Browsers from DNS Rebinding Attacks” from Collin Jackson which explains how this attack can be performed.

  6. nickhacks Says:

    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.

  7. Mattias Says:

    Very nice explanation, it showed a new way of exploiting DNS TTLs for me - very informative. Looking forward to your next videos. :-)

  8. JJ Says:

    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.

  9. Arun Viswanathan Says:

    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.

  10. RSnake Says:

    @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.

  11. Mystic Says:

    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…

  12. Daniel Magliola Says:

    Wow, excellent video!

    Thanks for taking the time to do this, this was the clearest explanation I’ve seen so far.

    Great Work!

  13. 4th of the 5th green horse Says:

    Excellent stuff! flawless explanation!

  14. Matt Presson Says:

    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?

  15. StarliteShadow Says:

    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.

  16. RSnake Says:

    @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.

  17. Matt Presson Says:

    Got it, thanks.

  18. bsdwiz Says:

    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.

  19. h3xstream Says:

    @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.

  20. RSnake Says:

    @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).

  21. RSnake Says:

    @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

  22. bsdwiz Says:

    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,

  23. RSnake Says:

    @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.

  24. h3xstream Says:

    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.

  25. RSnake Says:

    @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.

  26. h3xstream Says:

    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)

  27. Robert Chapin Says:

    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?

  28. Mark Says:

    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.

  29. RSnake Says:

    @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.

  30. Robert Chapin Says:

    “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?

  31. RSnake Says:

    @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.

  32. "Raf" Says:

    LOVE that shirt … no seriously!

    …oh, and good video since I finally got enough time to watch it at 12:30 ..

  33. Benjamin Flesch Says:

    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.

  34. D L Says:

    Really nice video, keep up this good stuff.

  35. Tom Brennan Says:

    great video….. pretty shirt ;)

  36. Alex Says:

    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!

  37. Robert Chapin Says:

    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.

  38. Robert Chapin Says:

    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?

  39. JJ Says:

    lmfao! you wore the shirt. bahahaahaha! priceless.