Paid Advertising
web application security lab

DNS Rebinding for Scraping and Spamming

Okay, last post about DNS Rebinding and then I’ll (probably) shut up about it for a while. If you haven’t already, please read posts one and two for context. As I was thinking about the best possible uses for DNS Rebinding I actually landed on something that is extremely practical for botnets, email scrapers, blog spammers and so on. One of their largest problems for most attackers/spammers is that they need to be able to scrape the search engines for targets and the only way to do that is to send a massive amount of traffic at them and if they use a small subset of machines they are also making themselves easy to block or subvert. Google typically tries to stop robots from scraping by showing a CAPTCHA. Wouldn’t it be easier and better if the attacker/spammer could use other people’s IP addresses? That’s the promise of DNS Rebinding, now isn’t it - unauthenticated cross domain read access from other people’s computers.

David Ross had a good post about how another practical defense against DNS Rebinding is using SSL/TLS, but since Google has opted not to secure their search engine, it becomes possible to use DNS Rebinding for its next logical use. Google hasn’t even fixed their other SSL/TLS woes so there’s pretty much no chance they’re going to secure the search engine any time soon. So DNS Rebinding gives the attacker IP diversity. An attacker can use DNS Rebinding to get other people to rip tons of information from Google without Google being able to block the real attacker. Since sites like Google do not respect the host header and they don’t use SSL/TLS an attacker can scrape information from these sites all they want - all the while using other people’s browsers. Now think comment spamming, polling fraud, brute force, and on and on… All of these become extremely easy and practical by burning other people’s IP addresses, instead of the attacker’s/spammer’s. Yes, DNS Rebinding is nasty, and unless the browser companies do something or every attacked web server on earth starts respecting the host header and/or using SSL/TLS it’s a problem that’s here to stay.

I know a lot of people think this is a complicated technique, but it’s really not that hard. It just requires some JavaScript (similar to BeEF or XSS Shell), a place to log data to log whatever the user saw when the attacker forced them to perform the action, a hacked up DNS server (like the simple DNS Rebinding server sample), a domain, a Firewall that is somehow linked to the attacker/spammer application and some Internet traffic to abuse. None of these things are out of reach for a decently skilled attacker. Anyway, I doubt it’s getting fixed anytime soon, which means DNS Rebinding essentially allows nearly free reign for attackers and spammers for the foreseeable future - and no one appears to be doing anything about it.

8 Responses to “DNS Rebinding for Scraping and Spamming”

  1. Todd Says:

    How do you verify the Host header and can’t that be spoofed?

  2. RSnake Says:

    @Todd - it depends on your server entirely. We do it by using a virtual host and saying the virtual host must match. But there are several different ways to do it. And no, it cannot be spoofed. Browsers have restricted modification of Host headers specifically to stop this sort of thing from happening. If you try it your browser will throw a permission denied JavaScript error or simply ignore your header by throwing it away.

  3. Wladimir Palant Says:

    Problem with this approach to ensure IP diversity - at some point Google will notice that something is wrong, they will take a look at the Host header of the incoming requests and immediately see who is scraping them. They might even have an IDS doing that already - just because the server sends the same response regardless of Host header it doesn’t mean that this header is entirely ignored.

  4. TBSheridan Says:

    Question from the great unwashed: What is the barrier stopping sites from respecting the host header right now?

    I assume this must have some sort of usability/cost impact? Or it would be respected by standard if everything you write is correct (and I’m sure it is).

    Is this lazyness or a technical barrier to be overcome?

  5. RSnake Says:

    @Wladimir Palant - Agreed - but so what? They’ll notice and do what about it? Unless they start blocking the users/requests which are sending the invalid host headers detection is useless. It’s a huge signal, you’re right, but why allow it at all instead of having to invent some crazy IDS detection/real time blocking mechanism - I mean besides the fact that they’re Google and they never seem to really get security. That just seems way way way harder and more error prone than doing it the right way.

    @TBSheridan - There’s almost no impact whatsoever. It’s sheer laziness/ignorance in most cases. I’m sure there are special circumstances where it would be difficult for some extremely technical reason, but those would be edge cases. For the vast majority of sites it’s just a configuration change.

  6. JJ Says:

    After seeing these posts I think DNS Rebinding is horrible. I think we’ll need one more post to discuss what practice besides SSL/TLS can help us prevending or migating the damage of it as a summary.

  7. Wladimir Palant Says:

    I think they actually want Google to be accessible under custom names. They for sure want it to be accessible by IP address but that wouldn’t justify ignoring the Host header altogether. Maybe there are companies that integrate Google into their DNS namespace.

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

    @Wladmirir Palant May i just add to Rsnake’s point that google might not do anything about it which makes the attack possible for a while yet. I once discovered that the Google orkut state cookie was expiring 24hours after a session and they never did anything about it for almost a month after i informed them and also wrote an advisory.