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

Packet: 2, Time: 0.101079 DNS Response

Packet: 3, Time: 0.103195 SYN

Packet: 4, Time: 0.147479 SYN+ACK

Packet: 5, Time: 0.147536 ACK

Packet: 6, Time: 0.147801 HTTP request

Packet: 7, Time: 0.327528 ACK

Packet: 8, Time: 0.825132 TCP segment HTTP response

Packet: 9, Time: 0.826323 HTTP Response

Packet 10, Time: 0.826416 ACK

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…

If you’ve been watching the Olympics you might have see the pretty amazingly close call between Phelps and Cavic. I looked at lots of different pictures and video of it and everyone was saying it was a close call, but they also said it was 1/100th of a second difference. Was it? Okay, here is where we get into our webappsec theory of the day.

So let’s take a normal run of the mill timing attack over a somewhat latent connection, or worse yet, somewhat spotty and latent connection. You normally have two paths of latency - to the target host and back. For those of you who don’t know what a timing attack is go read this or the rest of this post won’t make any sense. The target host has to respond within a certain set range of milliseconds or you know that you have found a successful timing attack. This all relies on your connection being fairly latency free as people will argue with you time and time again. We are lacking precision, and that makes the attack less useful.

Here is where Michael Phelps comes to save the day. I’m no photo finish expert, it looked closer than 1/100th of a second to me. Either way, what if it had been even closer than that? Clocks lack a certain precision. Normally that’s okay, because the smallest people normally want to go down to in their daily life is seconds. Try landing a space shuttle or judging the Olympics with a degree of accuracy of 1 full second. No one’s going to be happy with those results. Although Michael Phelps might not have been 1/100ths of a second ahead of his competitor he might have been closer to 1/1,000,000th’s of a second on the other side of the 1/100th time marker. Clear as mud? No?

So let’s say Phelps touched the wall at a time marker of .001001 and Cavic touched it at .000999. The time difference is only 2/1,000,000ths different but that’s enough of a precision to make it different instead of a tie. God forbid Cavic touched the wall at the same 1/10,000ths of a second or all hell would break loose at the Water Cube and then it would have been a speedo showdown for sure. Okay, so it might not have really been that close at all, but you see my point. Now, back to webappsec.

Let’s say you know that there is some sporadic latency between you and the target. And it’s somewhere between 30 milliseconds and 80 milliseconds at the worst, but for your tests to be valid you need to have the least amount of latency as possible since the timing attack itself is only a fraction of a second different. You can actually time your attack to take advantage of the Date: HTTP header. Let’s say take that as an example where I send my packet at 22:51:50 and 69 milliseconds. When I get a return response of Date: Tue, 26 Aug 2008 22:51:50 GMT I know that the packet was received prior to the clock striking 51 seconds and therefore there is no or minimal latency. If I get the response back and it says Tue, 26 Aug 2008 22:51:51 GMT I know the result is invalid because there was too much latency.

This all hinges on you being able to identify the exact millisecond of precision on the remote computer, which you can do with a large enough sample size. The smallest value is the closest to being accurate. While this doesn’t completely get rid of all the latency issues, it certainly could give you a much higher level of precision in your timing attacks.

Stefan Esser has a really good article about how MySQL and SQL truncate columns which can lead to security holes. He uses a good example of a column that has a width of 16 chars but he submits something with 17 chars. Obviously enforcing length is one way to enforce that, even if it almost never happens. But one other thing came to mind.

Harkening back to my days of reading Rain Forrest Puppy’s papers, I realized that often times the code does a straight regex or string matching. Eg: if ($username eq “admin”) { fail(); } but if the $username was “admin    ” it clearly will fail the string match since it’s not an exact match, but it will have the same net effect in the database of passing the check and allowing you to access the admin data. Likewise padding in front of the username will have the same effect in some cases - depending on how the SQL query is constructed (if it’s encapsulated). Anyway, good article, go read it!

On good authority I was told to take a good hard look at the newly proposed HTML 5.0 spec that’s floating around the WHATWG. Firstly my eyes went to the new video and audio tags which are meant to help users deal with the apparently confusing nature of the fact that we have img tags instead of just using embed for everything. Personally I think that’s just a horrible idea that’s going to break a lot of blacklists out there and potentially open more security holes depending if the scriptable video objects are allowed, but there you have it.

Anyway, so then my eyes glanced across the new iframe spec and lo and behold I saw a miracle. Someone over at the WHATWG was really paying attention. Firstly, there’s a new parameter called sandbox which is similar in many respects to IE’s proprietary security=”restricted” parameter but with more granular controls. That’s not necessarily a good thing if you don’t like being framed, but it does give websites more control over what happens to their site once they frame a site that turns out to be bad.

But more importantly there is another new parameter called seamless which will allow a page of the same origin domain to iframe a page without having all the usability issues (double scroll bars, _self targets and so on) of the original iframe model. That’s great news for websites that want to frame and control a page on their own domain (a la content restrictions) without all the crazy usability issues with iframes. There’s some other security concerns with allowing content to be accessible on your site - there needs to be some tag to disallow rendering unless it’s embedded within an iframe to prevent someone from calling the malicious child frame directly. However, this is a big step forward in the right direction.

I’ve been meaning to write something about this for a while now, and a number of people have known and used this for a while too, but one of the most helpful tools out there for identifying subdomains of any given target is MSN IP search. I think Fierce is way better for finding subdomains if they aren’t on the same IP, but MSN IP search is way better at finding subdomains on the same IP.

Why is that important? Well, it turns out that a lot of companies use shared hosting, and as we all know, unless they have taken extreme steps to protect their clients, the hosting environments are basically saying that any compromise of any client means complete compromise of any of the other clients on the same machine. Great. So I created a small bookmarket that interfaces with MSN IP search. If you use Firefox, just drag it to your bookmarks and just go to a webpage of choice (other than ha.ckers.org ) and click the bookmarklet. It sends the domain to ha.ckers.org which performs an IP lookup and forwards the browser back to MSN with the IP for that domain. It’s that simple. You’d be amazed how many companies use shared hosting.