Cenzic 232 Patent
Paid Advertising
web application security lab

More Timing Precision Enhancements

Okay, so my last post on timing precision was interesting, but then I went back and started doing more thinking and I found a few ways to get even better precision out of a typical timing attack. Let’s look at a real world HTTP request and response:

Packet: 1, Time: 0.000000 DNS Query (outbound)

Packet: 2, Time: 0.101079 DNS Response (inbound)

Packet: 3, Time: 0.103195 SYN (outbound)

Packet: 4, Time: 0.147479 SYN+ACK (inbound)

Packet: 5, Time: 0.147536 ACK (outbound)

Packet: 6, Time: 0.147801 HTTP request (outbound)

Packet: 7, Time: 0.327528 ACK (inbound)

Packet: 8, Time: 0.825132 TCP segment HTTP response (inbound)

Packet: 9, Time: 0.826323 HTTP Response (inbound)

Packet: 10, Time: 0.826416 ACK (outbound)

Now normally a timing attack would encompass this entire mess, but really we are only interested in a few time slices. We can completely disregard the DNS request and indeed up until the seventh packet, which is the acknowledgment that the packet was received (when we know that our packet has arrived and is in the process of being served up). That right there shaves 1/3 of a second off of my example (this was a real example, btw).

And again, when we are receiving the response, we don’t actually care about the last two packets, only the 8th packet (the returned data). The difference between packet 7 and 8 is what we are actually interested in. By combining this technique with the previous one about finding the exact time the packet arrived by calculating the precision you can identify exactly when the 6th packet arrived, and not just when you got your ACK in the 7th packet. The ACK is important but it gives you a slightly skewed result since it is a timestamp based on when you received it and not based upon when it was sent, unlike the Date: HTTP header that you receive in the 8th packet.

If you don’t look at the packet level information you are introducing up to 1/3rd of a second out of only .826 seconds on the first request, and still a few extra milliseconds extra even if you discount the DNS request. Point being there are certainly some enhancements to be made to the old timing attacks of yesteryear. Looks like a tool waiting to be made…

13 Responses to “More Timing Precision Enhancements”

  1. Wladimir Palant Says:

    Actually, I think the difference between packet 7 and packet 8 is *exactly* what you are interested in. Because the web server would typically acknowledge receipt of HTTP request immediately and start working on processing it. When it is done it will send you the response (web applications usually first do all the work and send the response as a whole then though there could be exceptions). So assuming that the one way latency from the server to you is always the same, the time between packet 7 and packet 8 is exactly how long it took the web server to process the request.

  2. RSnake Says:

    There is a lag between when the 7th packet was sent and when it arrived, and that doesn’t count any application time that might be variable in passing the request to the webserver. The Date: HTTP header is more precise since it’s based on when the application picked it up. So if you use the timing precision technique described in the previous post and marry it to this, you can get a slightly better precision than you could using the 7th packet - or at least you could ensure that there was little to no lag incurred when you do decide to measure the delta between the 7th and 8th packets.

  3. Wladimir Palant Says:

    Yes, there is some lag between sending the ACK and actually starting processing the request - but it should be constant lag, so it doesn’t matter.

  4. RSnake Says:

    Why would lag be a constant? It’s lag… it could be based on a whole bunch of different factors - not the least of which is server load.

  5. RSnake Says:

    One thing I should make clear, is that the ACK doesn’t have to come from the origin server - it can come from something upstream, like anti-DDoS boxes for instance that are simply relaying messages but only do so after a full HTTP connection has been made to stop SYN flooding and various other TCP level DoS attacks.

  6. ChosenOne Says:

    Do you really need to create a tool for timing attacks?
    I mean, I’d just use Wireshark, which *is* doing the time-measuring for me, right?

  7. RSnake Says:

    @ChosenOne - You don’t have to, if you want to do the math by hand, that’s possible too. Tools just make things quicker. That’s how I initially did my research into this as well. Wireshark is great, just extremely slow compared to a tool that could do the work for you.

  8. Abe Says:

    There are several people hiring programmers on GetAFreelancer to code the tool!

    Let’s see how long it takes

  9. RSnake Says:

    @Abe - Do you have a URL? I’d be curious to follow that.

  10. Abe Says:

    http://www.abeontech.com

    Or

    http://www.abeontech.com/security/147/sockstress-tcp-ip-vulnerability.html

  11. Abe Says:

    @ChosenOne - You would appear in the victims logs if you dodn’t cloak the attack via a botnet or something.

  12. RSnake Says:

    @Abe - I think you are thinking about something different (Robert E Lee’s tool). This post isn’t about denial of service. It’s about a timing attack to recover valid user names off of a server.

  13. Abe Says:

    …… -_-

    That’ll teach me to read the whole article before posting!

    Damn google SUPRs look so inviting some times, it’s easy to leech before reading.

    Great blog you have here anyway. Very informative :)