Paid Advertising
web application security lab

LocalRodeo Detection

With all this anti-DNS pinning stuff going on, Martin Johns published an interesting tool called LocalRodeo that does a really nice job at preventing JavaScript malware that tries to connect to intranets by circumventing DNS pinning as well as anything that connects to RFC1918 address space (and localhost/loopback as well). Really, it’s a very cool tool and I feel bad finding an issue with it, because this sort of research is critical to stoping some of the issues we’ve been talking about.

However it is pretty trivial to detect LocalRodeo by actually trying to connect to localhost. Because LocalRodeo won’t let the connection take place, neither an onload nor an onerror event handler will fire. However the DOM is not modified so you can’t just iterate over the images and see if the source still points to the correct location. But the first part is enough to detect if LocalRodeo is installed or not (example requires JavaScript). Still, it’s a great tool and I encourage people to try it out and give feedback to help improve it.

14 Responses to “LocalRodeo Detection”

  1. kuza55 Says:

    I honestly don’t see the issue here. Sure; you know someone has it installed, but unless you find an exploitable issue, then this is pretty much useless in my eyes…..Or am I clearly missing something?

  2. RSnake Says:

    There are two reasons you may want to know this. a) it can tell you the type of user you have on your site and b) it can tell you not to attempt an exploit. This is yet another way to do recon. Please view the Matt Cutts post prior to this one.

  3. kuza55 Says:

    Ok, I just noticed you other post from today, and having read it I do see the point of detection; but as I said above, its still only an issue if you can exploit what you detect. I can see how this is possibly useful if you find another issue with the extension, but atm its fairly pointless. Not that it shouldn’t be fixed, but that its just a minor bug.

  4. RSnake Says:

    Well, that’s not completely true. Knowing what NOT to exploit can be very valuable in certain circumstances - especially where the target is already paranoid to begin with. Trust me, it can be useful to know what security software people are using. I could have laid in months or years trying to catch my target only to have it fail every time, without knowing why. And yes, I agree it’s a minor bug, but even the smallest bug can be used to your advantage.

  5. Martin J. Says:

    To be honest with you, we didn’t even think about making LocalRodeo to be hard to detect when we wrote the extension. However what you say makes sense. The problem is that a protection measure like LocalRodeo is rather intrusive. Making it somewhat stealth is possible. But I cannot say if we will be able to hide its existence from people that are determined to find it (especially given Firefox’s internals that we have to work with).

  6. Stefan Esser Says:

    Come on RSnake, detection is the only hole you could find in LocalRodeo?

    There are atleast 2 rather trivial ways to bypass it, that took me less than 5 minutes to find.

  7. RSnake Says:

    Hahah, well I didn’t stress test it, did you find it in the RFC1918 portion or the anti-DNS pinning portion of the plugin?

    Actually, in looking at it this seems to work:

    <IMG SRC="×01./">

  8. RSnake Says:

    Okay, here’s a second one:
    <IMG SRC="http://asdf:fdsa@">

    When pressured, I do better. ;)

  9. Stefan Esser Says:

    No the two bypass vulnerabilities are

    1) LocalRodeo supports Location with 302 Status Code but obviously not 301/303

    2) LocalRodeo does not work (no idea why) when the external page does not contain the attack directly, but contains an IFRAME that is a data: URL and contains the attack on the local net.

    (2) is actually my favourite Firefox way to get stuff send from a kind of anonymous (no referer,…) context.

  10. RSnake Says:

    So maybe there are four/five or more vulns. Those would work nicely.

  11. Stefan Esser Says:

    Whatever Local Rodeo is a nice idea and I always wonder why this kind of behaviour is not built into Firefox.

    It makes absolutely no sense that an external page can reference resources in the LAN.

  12. Martin J. Says:

    Hey Stefan, hey RSnake, thanks for the feedback. I would have been surprised if there weren’t any bugs in the extension. Stefan’s 30x issue is a classical “Duh” and so are the IP-based issues that RSnake found. Hrmgl, this is pretty embarrassing. But hey, we are academics and it is scientifically proven that academics can’t code ;)

    The Data-URL issue on the other hand startles me. We use a nsIContentPolicy-component to intercept all outgoing http-requests. I have no idea why requests that are created by a data-URLs are not seen by it. Introducing a nsIContentPolicy-component is the “official” way to create for example parental control-add-ons (so data-URLs might be a nice way to p0rn).

  13. RSnake Says:

    I’m in complete agreement with Stefan - this tool was a long time in coming and one of the few plausible defenses. Even with the holes, I think you are on the right track.

  14. Stefan Esser Says:

    Uhmm, I believe the problem is not that it does not see it but that LocalRodeo does not consider the data: URL an external resource.

    But that is just a guess, I haven’t looked into the code to verify.