Paid Advertising
web application security lab

XMLHTTPReqest “Ping” Sweeping in Firefox 3.5+

Jeremiah brought my attention to the new Firefox 3.5+ CORS (Cross-Origin Resource Sharing) which is a way to do a cross domain XMLHTTPReqest. Does that sound scary? Well, it is, but there’s been a ton of work into hardening it. It has all sorts of cross domain opt-in verification built into it to limit the abuse. Honestly, if you look at the people who were acknowledged in it’s construction, it’s a who’s who of people who understand cross domain browser security issues. So it wasn’t surprising that it was fairly free of obvious flaws.

Anyway, I was poking around with it and I noticed that it had one fairly strange issue. Although an attacker is not allowed to know if the page was there or not (only if it was allowed to see the content or not), the attacker is still allowed to make an initial request. In doing so that initial request can be used as a pseudo “ping” sweep. You can tell if the site is there or not because it will either return immediately (latency and threading applies) or it will wait around much longer (between 20-75 seconds on the several networks I’ve run this on) before the browser gives up. That timing difference is pretty substantial - and as a result you can enumerate a substantial amount of internal address space behind the victim’s firewall and relatively quickly. I created a demo here (works only in Firefox 3.5+ and you must enable JavaScript globally for this to work). It won’t work if you just whitelist you have to globally allow JavaScript if you use Noscript for the demo to work - and you must disable ABE in Noscript as well.

You can read the page for the details, like the fact that basic and digest authentication popups are suppressed which makes this technique ideal for Intranets where those are common and would normally alert a user to the fact that something was wrong in the browser. It also doesn’t matter whether you do or don’t have port 80 open for this to work, I should note that there is a IE8.0 version of Firefox’s XMLHTTPRequest called XDomainRequest, but I didn’t have much time this weekend to try to get it working in both browsers so I have no idea if it has the same issue or not.

Incidentally, Jeremiah and I both gave the thumbs up to the idea of a cross domain XHR several years ago when the Mozilla team first asked us about the concept. Because there are so many other things wrong with the browser Jeremiah and I told them that it wouldn’t change much - the browser is already so broken from a security perspective that it really didn’t matter - a sad commentary thinking back. Of course, it really is all about the implementation.

11 Responses to “XMLHTTPReqest “Ping” Sweeping in Firefox 3.5+”

  1. Robert A. Says:

    When it comes to identifying resources based on response times I see this as a fairly difficult thing for a browser vendor to solve/prevent without disabling/restricting script (js/css/vbs) functionality.

    This issue will persist with any markup/code that allows fetching a request and is something that the security industry needs to discuss more in depth with the browser vendors.

  2. Peter Says:

    Wow! That is really cool!

  3. Sébastien Duquette Says:

    Nice trick. just wanted to mention that the authentication popup of my router did appear in my browser.

    Something problematic with XDR is that it is server controlled (via the Access-Control-Allow-Origin header), so if you manage to find an XSS on a website you can enable an AJAX tunnel to your server by setting this header. Mozilla’s CSP ( would greatly mitigate this problem but it is not implemented yet (since it would break a lot of websites).

  4. RSnake Says:

    @Sébastien - weird - I totally had the opposite finding (twice). I have no idea why that would be. But I re-tested and sure enough it worked. Anyway, thanks and I updated the blog and removed the comment about that in the tool itself. That makes it far less ideal for this type of probing, unfortunately.

  5. RSnake Says:

    @Sébastien - although, haha… I just realized, it doesn’t matter which port you pick. So you don’t have to pick a web server port. You can pick something like sendmail (25) or something else, and it will work the same way. So I take it back - it is good for this kind of attack.

  6. RSnake Says:

    @Sébastien - okay I’m an idiot - I forgot that I turned on authentication in my demo. I’ve since turned that off so that popup should no longer happen.

  7. Scott Johnson Says:

    Wow, some of these take a long time to come back:
    Doesn’t exist: at 587503ms.

  8. RSnake Says:

    @Scott - that’s your timeout. If you’re using a proxy or something that keeps the timeout living past the 20 seconds, that’s how long it’ll stay open. There is a way to reduce the max timeout window for an XHR request, I just didn’t build that function in.

  9. Robert A. Says:

    This is correct, if you’re behind a proxy it will often have a different timeout value than when you’re not behind one. You may be able to fingerprint those response time differences to identify the specific proxy a user is behind also. I wrote a proxy scanner for work a couple of years ago and first observed this proxy related behavior when trying to identify brute force hosts through a proxy.

    Certainly can be researched further.

  10. Inferno Says:

    very nice attack RSnake. just wrote a version for IE8.

  11. prabashis behera Says:

    carry out pink sweeping ip rang to