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…
August 29th, 2008 at 3:03 am
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.
August 29th, 2008 at 6:44 am
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.
August 29th, 2008 at 10:22 am
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.
August 29th, 2008 at 11:53 am
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.
August 29th, 2008 at 12:53 pm
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.
August 30th, 2008 at 9:38 am
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?
August 31st, 2008 at 10:58 am
@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.
October 13th, 2008 at 7:34 am
There are several people hiring programmers on GetAFreelancer to code the tool!
Let’s see how long it takes
October 13th, 2008 at 7:41 am
@Abe - Do you have a URL? I’d be curious to follow that.
October 13th, 2008 at 8:18 am
http://www.abeontech.com
Or
http://www.abeontech.com/security/147/sockstress-tcp-ip-vulnerability.html
October 13th, 2008 at 11:39 am
@ChosenOne - You would appear in the victims logs if you dodn’t cloak the attack via a botnet or something.
October 13th, 2008 at 3:02 pm
@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.
October 15th, 2008 at 5:03 am
…… -_-
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