Cenzic 232 Patent
Paid Advertising
web application security lab

JSPing Might Help Build Time Measuring Attacks

I know this is coming late, but when I first looked at this, I wasn’t sure if I thought this was particularly interesting but David Kierznowski built a JavaScript tool to ping hosts. At first I thought “well, okay, but why?” but then I started considering other potential implications of knowing if a webpage is up or down. Port scanning is the obvious security implication but that’s already been done. What else? How about using it as tool in a time based attack?

Let’s think about this… If I can stop an iframe from loading and test if it has completed loading or not, I can send it to a URL that acts differently based on the time required to load a page in varying states. If it takes longer for a page to load if the user is signed in than it does when they aren’t it’s another potential way to do targeted attacks. Even assuming the CSS history attack that Jeremiah came up with is disabled by something like Stanford’s Safe History I can still tell if they are in authenticated states on websites that have this issue.

Since I’m on a roll talking about Stanford security today, let’s completely break Safe History by testing if they have been to a website before by detecting how long it takes them to load a website before and after going to it (if it’s cached it should be basically instant). Of course all of this is theory and I haven’t tested any of it, but I’ll be curious to hear people’s thoughts once they do. Cross domain restrictions seem to be getting more and more fuzzy lately.

3 Responses to “JSPing Might Help Build Time Measuring Attacks”

  1. WhiteAcid Says:

    This isn’t all that reliable and not something I’d ever really bother implementing, but a nice theory. Say the user was running torrents, or someone on his network was, then a lag spike may cause a delay in the ping which may flag a false positive.

    Usually I code is neatly as I can, but when I’m doing XSS I don’t care if I leave tags opened, if I cause redundant requests etc.

    Let’s say it takes 50ms to load a page if they’re not logged in. 100ms if they are. Then why not just assume they are and do whatever you would. If your attack fails because they’re not logged in so what? Most likely your attack wasn’t noticed and you can just create a request to your next site.

    As for the title… I read it as “JSP-ing … ” as in Java server pages. heh, my fault.

  2. RSnake Says:

    Agreed… probably a nicer theory than an actually useful exploit, but it’s just another tool in the arsenal. However, in some applications there are more than two states, which might be useful to try. Sure you can send them through twenty different flows and hope one works, or you can detect it and move them directly into the correct one. This might be helpful in highly branched logic where it might take 2^20 tries if you just send them through every flow, or 20 tries if you can isolate which branch to head down. Anyway… just an idea.

  3. David Kierznowski Says:

    Rsnake, pdp has also had similar thoughts.

    btw you could also use JSEScanner’s fingerprinting techniques to detect authenticated resources vs unauthenticated resources - although this technique has limitations.

    Like you said, its all about having the techniques in concept and practise ready to be applied to varying circumstances.