Cenzic 232 Patent
Paid Advertising
web application security lab

Session Fixation Via DNS Rebinding

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…

13 Responses to “Session Fixation Via DNS Rebinding”

  1. Michael Hampton Says:

    This isn’t likely to be an issue for any site that’s had a good working over by an SEO expert; they’ll already be redirecting such requests back to goodguy.com anyway.

    For WordPress, for example, installing a plugin like Permalink Redirect will take care of this for you.

  2. RSnake Says:

    @Michael Hampton - You’d be surprised. I’ll be talking about this more in the coming days. But I agree, that’s definitely not the desired behavior for any meaningful/large site.

  3. Chris Says:

    Just a quick addition: This is a big issue for ssl sites since these, by protocol, currently cannot respect the Host header at all.

    RSnake, did you look at SNI in depth yet?

  4. AbiusX Says:

    To be realistic, 99%+ of web apps don’t deploy that correctly, neither they bind their sessions to user via IP or anything. So this sounds very useful to me! specially if the victim site has no considerations for showing the victim his name or account name obviously!
    e.g You can use this to force someone send mail to his/her boss from you, LEGITIMATELY instead of himself/herself! That would be of course useful :D And I don’t think any of the famous web-based mail clients check for that.

    I’ve been wondering for a week or two why DNS rebinding is not dealt with yet! Read the Collin Jackson paper, but it didn’t sound promising to me since it wants the whole private network reconfigured and secured again, Which is not likely to happen at all!

    I think the only working solution for that would be something like PKI for SSH? Any ideas?

  5. RSnake Says:

    @Chris - I see what you’re saying, but that won’t work because of the SSL mismatch error. Their SSL on your domain will throw the error. To answer your question, it’s funny you should ask that I haven’t yet, but we’re supposed to do some testing on that in our lab this week. I’ve got a theory that I proposed to Mozilla at Blackhat this year, and I don’t think they’ve dealt with it, so I’m 95% sure it will work. More on this later.

    @AbiusX - I totally agree. PKI for SSH/SSL isn’t a bad idea. I don’t think there is an easy answer here, to be honest.

  6. Michael Hampton Says:

    Well, this also isn’t an issue for me, either, since I am using virtual hosting (and nginx, but that’s another story); any requests that come in with an unrecognized hostname get the “localhost” virtual host, which at the moment has been set up to serve the “Apache 2 Test Page” (yes, even though I’m using nginx).

    A web server admin who uses the virtual host features of the web server to set things up, and does it right, should mostly eliminate this problem. SSL is another story, but the certificate mismatch at least lets the user know there’s a problem. But too many users just click right through it without paying attention…

  7. Andreas Says:

    Well… The content the user sees belongs to goodguy.com. However, the domain his browser shows is still badguy.com (because it’s badguy.com that points to goodguy.coms IP).
    So, why should he enter any credentials or personal data on this page?
    If users are that stupid, you don’t have to come up with DNS rebinding. A Proxy on badguy.com that forwards all requests to goodguy.com and logs the data would do a better job - it works even if goodguy.com respects the host header.
    Or did I get something completely wrong?

  8. RSnake Says:

    @Andreas - I don’t think you understand. This isn’t for phishing. If I have credentials for a site I can get my own cookies. Then I can set my cookies into your browser (but for badguy.com domain). But domain is irrelevant here if goodguy.com doesn’t care about host headers. They’ll see the real credential and it’ll let them into my account. That’s only useful in some very specific circumstances, but it’s just another side effect of the fact that I own my own domain and can set whatever cookies I want. The most likely reason someone might want to do this is for session fixation via credential brute force like I talk about here.

  9. Andreas Says:

    @RSnake
    hmm… Let’s forget about phishing.
    Yes, you can obtain cookies from goodguy.com (do whatever you want with them) and you can set them in my browser (for badguy.com).
    But only, if you get me to open badguy.com in my browser (which is easy). But, as long as I don’t do anything on badguy.com (which I won’t, because I don’t want badguy.com in my address bar), what’s your benefit from that? Without my interaction, the session you fixed me to doesn’t gain any useful information. Or am I wrong here?

    I also don’t get the difference between my browser connecting to badguy.com, which points to goodguy.coms IP and my browser connecting to a transparent proxy on badguy.com which delivers the data it got from googduy.com.
    For the browser, it’s exactly the same. For you, it’s not. With DNS rebinding, you can only set cookies before you do the rebinding. With a proxy, you can modify everything all the time.
    And, for goodguy.com, the difference is that he sees the Host-Header badguy.com (which he has to ignore) and the actual clients IP in the DNS rebinding case - and with the proxy, he sees the proxies IP and goodguy.com as Host-Header.

  10. RSnake Says:

    @Andres - rather than trying to do this over text I made a video that may help clear up your confusion: http://ha.ckers.org/blog/20091201/dns-rebinding-video/ Let me know if it’s still unclear.

  11. Andreas Says:

    Well… sort of ;)
    If you want to access some server on the intranet, you’ll need DNS rebinding of course.

    I think I just got the term “Session Fixation” wrong… Usually this means to me, that I create a session on a website, fix you to this session and then use the data you provided me by using this session (e.g. authenticate to this website).

    What you’re talking about in the video is actually just brute-forcing any authentification data (which is easy, if it’s just an ID), which you can provide by cookie or http-auth, depending on the intranet website.
    However, to actually access the intranet website, you have to have a (Java)Script running on the client in badguy.coms context. This Script also could set the cookies, it doesn’t have to be badguy.com via HTTP, right? :)

    I guess I expected more than this really is :)

    However, the Video is really good *thumbsup*

  12. RSnake Says:

    @Andreas - yup, you got it, exactly. The JavaScript would be the one setting the cookie (in most cases), but if they didn’t have JavaScript it may be possible to this all entirely without using it using only redirection etc… but that’s unlikely and much slower.

  13. acemutha Says:

    I think that this can be useful in the case of some sites that don’t modify their cookies before and after authentication. In this case following your attack, the attacker get the cookies from goodguy w/out authenticating and then serve them to the victim that whenever authenticates himself on goodguy, It’ll provide a valid authenticated session to the attacker.