Cenzic 232 Patent
Paid Advertising
web application security lab

CSS History Hack In Firefox Without JavaScript for Intranet Portscanning

Okay, I know we’ve talked about Intranet port scanning to death, but I’ve been toying with an idea for around three years now regarding how I might be able to turn off JavaScript and perform intranet port scanning. Jer had some good ideas around delayed CSS timing (I even got that working at one point). But I still wanted to get the CSS history hack working with forced browsing and see if I could possibly turn that into a crude port scanner. Yeah, I have a few items on my plate, so it took me this long to finally sit down and hack it out. It turns out it was trivial once I got started, because CSS history testing is instant, you don’t have to force a re-load of your test to see if it was successful.

That’s the good news. Here’s the bad news. 1) It only works in Firefox so far in my testing. It didn’t work in IE8 (false negatives), Opera (false positives) or Safari (false negatives). 2) It’s slow. Since it has to wait for all the HTTP requests to fire it’s pretty unwieldy once you get over a few dozen requests. 3) It’s noisy. If you’re dealing with NTLM/basic or digest auth, not to mention any other popups or sounds or what-have-you, you’re talking a pretty noisy port scanner. But all that said, it seems to work fairly well. You can check out the demo here.

15 Responses to “CSS History Hack In Firefox Without JavaScript for Intranet Portscanning”

  1. Chris Schmidt Says:

    You totally beat me to the punch here, great work! I was thinking about this the other day when I checked out the Samy expansion of the Jeremiah CSS History Hack… This is all some great stuff!

  2. rvdh Says:

    Doesn’t seem to work here in Firefox 3.5.7, could be due to my router settings though.

  3. RSnake Says:

    Do you have browsing history enabled? That caught me up several times.

  4. rvdh Says:

    Yep. got that enabled, and don’t use very exotic plugins or extensions. I configured my router firewall pretty strict, so I’m guessing that that blocks it.

  5. RSnake Says:

    Noscript will also block it if you have that enabled (cross domain iframes). So will request policy. It could be something like that as well.

  6. rvdh Says:

    Got no NoScript nor any policies running so far, odd isn’t it?

  7. RSnake Says:

    Or you don’t have anything at those locations - that could also be. Way too many variables there! :)

  8. rvdh Says:

    Ah wait, I thought I had my server running at 127.0.0.1 but it was turned down while testing. Now it works. :)

  9. RSnake Says:

    hah! Fail. :)

  10. rvdh Says:

    Indeed. In MSIE I get false positives as well as you did.

  11. risk Says:

    you’re my hero.. :)

    i’d love to see more posts on your deanonymizing (via protocol:// URLs and otherwise) research, btw.

  12. Nos Says:

    Awesome work, ever since i found out about the css history hack my mind has been blazing with thoughts about the possible applications of it, didn’t thought of this one though, great job!

  13. Picci Says:

    I’m currently using the css history hack to find out who visits my profile on facebook. Basically I can check who goes to “theirprofile?ref=name”, etc… Which are links (currently i’m tracking 4 for each friend) only visible to the profile owners themselves. I am currently developing an app to track what users have seen before going to my profile on fb: think about this showing up on your wall ->
    – This morning Billy went on the following sites (…) before visiting my profile, what a perv!
    Anything is possible till fb doesn’t remove profile boxes. ATM i’m trying to find better url’s to track down my friends. I will gladly email you the link to the app (picci@in.com).
    Picci
    PS right now i’m tracking name?ref=profile, name?ref=name, #/name?ref=profile, #/name?ref=name, and same thing with the ones who have profile.php?id=123&ref=name, etc…
    Yes, you can cheat this system by visiting a friend and adding ?ref=profile at the end of his name and then visiting a tracking profile box but still, that would be just a few people messing with it out of quite a number of fb users.
    The basic idea behind the app is simple: it generates a profile box that contains tons of lines of css containing the usual background() dynamic tag. Facebook will call that url from its own proxy and u’ll see when someone has visited your profile. You can refresh the profile box whenever you want, i just have a cronjob refreshing mine every 10 minutes, to change an id in the background requests, so that most visits will be “unique” and I can track also other url’s and associate them with a single friend instead of having them split by time frames. (It’s sounding way more complicated than it actually is…)

    Btw, messing with the facebook proxy is also cool (right jecky?:P), btw, did u know you can get it to re-cache images just by adding a %00 somewhere in the filename? You’ll have a second image cached under the different name, with the same checksum on the request… blah, probably just BS, but still fun to play with.

  14. Picci Says:

    Oh, btw, just another comment on the “brute force” line:

    bla

    Will work as well… and you can brute force any hardcoded auth’s in visited links… :) (Often a sys admin will tend to visit htaccess protected pages like that for quicker access…) not sure if this was already pointed out in previous articles.

  15. Aerik Says:

    Another way of blocking the attack is using the extension ‘blocksite’ and blacklisting the localhost IP ranges with wildcards.