Paid Advertising
web application security lab

Measuring Execution For Web Application Exploitation

Well, I’m somewhere hovering around a third of the way through the new version of Hacking Web Applications Exposed 2 and I ran across a section talking about how you can measure the time it takes for pages to return as a measurement of the logic overhead. Wow. I credit Arian Evans with this idea personally, but I’m not sure if the origins pre-date him. As a result of this function you can actually tell what is going on within the internal server logic.

Here’s how it works. Let’s say, to make this easy, there are two paths of logic within a sign-in application. The first path is a valid username with an invalid password and the second is an invalid username with an invalid password. Either way the application logic ends up in a sign-in failure and if the user interface designers built it correctly it gives an anonymous error state that says something like, “Either your username and/or your password is incorrect. Please try again.” That is to not tell the attacker anything about what happened if they happened to have found a valid username or not to begin their attack against.

From the outside this should provide you no information about the account from an attacker perspective but if you measure the time difference between the two application logic paths they can easily provide you with more information than they intend to. Let’s take the first path. 1) It has to make a query to the database first to insure that the user name exists. 2) Then perhaps to check if it is in a valid state. 3) Then maybe it checks to make sure that the user has not tried logging in too many times with failed attempts. 4) Then lastly it hashes the password using the same salt as the hash for the appropriate password and does a string compare. 5) After this it errors out as you would expect.

Now let’s contrast that with the second path. 1) It has to make a query to the database first to insure that the user name exists. 2) Upon finding no password, it errors out immediately.

Of course this is a simplistic example but you can plainly see that the first path is far more complex and requires more CPU cycles and database lookups than the second path, meaning that it will take far less time. With a known userid you can test the difference between that user and one that is highly statistically unlikely to exist like “189hdjhnt2h1″

Measuring the difference between the first and second paths of a single function will let you know information about the internal application logic that the presentation layer does not disclose. Pretty interesting stuff, and I hadn’t heard it anywhere else. So far, it’s a pretty good book. I can’t wait to find enough time to sit down and read the rest of it.

8 Responses to “Measuring Execution For Web Application Exploitation”

  1. maluc Says:

    This attack is referred to as a timing attack, and originally developed by Paul Kocher - his original paper shown here: ..

    But wikipedia has a much easier to digest explanation, with a nice example of the timing vulnerability in OpenSSL

    These attacks are particularly interesting for hardware hacking of cryptographic chips, and smartcard hacking (wheres if often overlooked) .. An equally powerful attack (no pun intended) for hardware hacking utilizes differential power analysis .. to reverse engineer the algorithm/privatekey based on battery drain

    Genius outside of the box thinking.

  2. WhiteAcid Says:

    This has already been used against say FTP servers (called a timer attack, or something like that). Some FTP servers allow you to specify a random time for the server to wait during registration, makes the attack form pretty void.

  3. anty Says:

    That’s obvious, but I don’t think that you can rely on the response time. I haven’t tried it, but I don’t think that you see any obvious time difference on server located far away or on servers with a small database of users.
    Anyway, it’s a nice idea.

  4. DK Says:

    Time measuring attacks have been around for decades. It isnt new to web application testing either.

    Nice refresher though.

  5. DK Says:

    This attack was first published in November 1979, Morris Password Security paper. Quote:

    ‘When the slow encryption algorithm was first implemented, the
    encryption was done only if the user name was valid, because other-
    wise there was no encrypted password to compare with the supplied
    password. The result was that the response was delayed by about one
    half second if the name was valid, but was immediate if invalid. The
    bad guy could find out whether a particular user name was valid. The
    routine was modified to do the encryption in either case.’

  6. RSnake Says:

    Hahah, alright, it’s clear I didn’t do my research to find the origins of the attack (and I openly admitted I didn’t know if the origins pre-dated Arian Evans so give me some credit for integrity here), but from what I remember timing attacks were generally reserved for server application type attacks (SSH is a good example actually) and not web applications. I had heard of this in use for other types of things but never the measurement of data returned from webpage in state a and webpage in state b. Perhaps I’m the only one who missed the boat on that one though.

  7. Arian J. Evans Says:

    1. Yes, timing based attacks are old, dating back quite a ways on hardware, but I’d never heard of the Morris Password Security Paper. That’s very funny…

    2. I was inspired to start this type of testing after seeing David Litchfields presentation on timing-based inference attacks against databases at BH 2005 last spring in the Dam.

    3. After leaving the beautiful city of Amsterdam and returning home to the mecca of cosmopolitian culture known as Kansas City, I decided to scripts some tests against the very next app I had to test.

    I was able to harvest multiple valid user accounts from the login page through timing inferrence, and several emails from the password reset page via the same (admittedly, I had created the accounts and knew the email addresses I was targeting, but once the PoC is demonstrated the rest is simply a math/keyspace problem for brute-force fuzzing).

    4. The issue essentially was that, due to performance overhead of the JSSE implementation they were using, they had asynchronously implemented the hashing functions with their string-compares. This makes sense on the one hand; good solid development says stay loosly coupled and be asynchronous, right? but here when we are making a security decision…

    5. I’ve heard over and over again from folks that these type of attacks (timing-based inference attacks) will not work over the Internet, too unreliable, too much latency, etc.

    They can and they do, and I used them reliably across the Internet from both cable modem and DS3 (to clients who, admittedly, have significant bandwidth).

  8. web application security lab - Archive » JSPing Might Help Build Time Measuring Attacks Says:

    […] 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? […]