SecurityFeed.info » ha.ckers.org web application security lab

« Expand/Collapse

ha.ckers.org web application security lab (10 unread)

August 29, 2008
5:44
More Timing Precision Enhancements
» ‎ ha.ckers.org web application security lab

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 27, 2008
2:12
Timing Precision
» ‎ ha.ckers.org web application security lab

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.
August 18, 2008
18:04
MySQL Truncation Etc…
» ‎ ha.ckers.org web application security lab

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!
August 16, 2008
20:58
HTML 5.0
» ‎ ha.ckers.org web application security lab

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.
August 03, 2008
19:43
MSN IP Search
» ‎ ha.ckers.org web application security lab

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.
July 30, 2008
2:42
Firefox Security Model Growth
» ‎ ha.ckers.org web application security lab

Okay, I can bet I’m going to get a lot of flack for this post, so before I start, this is only my opinion and is not at all based on actual numbers. The only reason I’m putting a graph here is because I think it’s easier to visually explain. No numbers. Got it? Just opinion. Don’t get all excited here. Okay. Calm yet? Okay, now don’t start reading this post unless you intend to read the whole thing. Ready? Now you may continue reading the post.

The last post I made was describing just a small smattering of some of my personal Firefox woes around the add-ons that I use to personally secure myself from attacks that either I have helped create, or have seen in the wild. Now, truth be told, I use Firefox every day, due to the add-ons that it supports and the ease of testing webapps. And it’s with that that I’m disheartened by my sense of helplessness around updates.

So here’s what I feel is happening over time for security people (not for the regular every day casual web surfer, but indeed, hardcore security folks, like most of the people who read this site). Over time there are upgrades. Those upgrades fix a number holes, and introduce a few others. They also break the add-ons. Those add-ons help fix the broken browser security model. Therefore, for the likes of me and the vulns I actually am affected by, my security is reduced with each new major revision of the browser, making it look something like this:

Sure, the overall security is trending up with time, but there are major gaps in my perceived security while developers catch up to the new codebase. While the numbers and timelines may be way off, the concept (for me at least) is right. I don’t personally see any immediate major benefit from the browser changes - only negative. With time, sure, things get better, but I happen to be in a particularly bad security slump at the moment right there on the right hand side of the graph. The exploit code that I may have been at risk of, for the most part, is neutered by the add-ons, until they stop working. So which is it? Am I trusting the browser to evolve faster than the add-ons or vice versa?

Firefox’s model has always been, “Feel free to contribute, it’s open source!” While this is great in theory, a) My programming skills get me by and not much more - you don’t want my code in your browser holding the Internet together, trust me b) I don’t have access to all the security bugs - most of the worst of which are hidden from view on bugzilla for only a very small select few people to view and c) there are very few people who have the ability to commit code let alone to fix other people’s add-ons.

It’s tempting to get overwhelmed by the helplessness of it all, but then I just remember that none of these plugins fix things like CSRF which helps me ignore that particular issue. So then I just go home and cry myself to sleep. Okay, now rant away, but if you mis-quote me or fail to read everything before commenting, so help me, I’ll make fun of you senselessly.
July 28, 2008
22:00
History Hack Male vs. Female and Beyond
» ‎ ha.ckers.org web application security lab

Strangely enough there’s been a ton of things happening in the CSS history hacking world lately, and I thought I should recap some of the more important events of late. Firstly, Firefox 3.0 came out, and wow - it feels an awful lot like when Firefox 2.0 came out. A good chunk of my favorite plugins no longer work - Switch Proxy, Auto Copy, LocalRodeo (since ironically it doesn’t install over SSL - and btw, that was the only public tool protecting anyone from JS based intranet hacking that I am aware of) and, of course, Safe History. Why is that a problem? Well, if you were relying on it to protect your history, it’s no longer an option.

Now, if that’s not bad enough, Jeremiah Grossman pointed me to a page that attempts to calculate your gender based on a portion of your history. An interesting take on the usefulness of the old CSS history hack. How accurate it is is questionable, but realistically this is pretty good for a first generation tool that is virtually un-tuned.

Last but not least, I did a little looking into the ol’ about:config options in Firefox and landed on a few options that were noteworthy. Not the least of which is browser.visitedcolor which can be re-set to anything you’d like. That means if you are simply looking for the color of a typical viewed link, you may be deceived if this color has been modified. That is - unless, the attacker knows that the victim has visited something before (a previous page perhaps), and the attacker’s code verifies that against something they couldn’t have visited (a domain that isn’t up, for instance) to isolate what the real viewed color is. So that option, if you were considering it, wouldn’t work for a more advanced version of the code that checked for this kind of thing.

It’s a sad day for the old CSS history hacking security though. And please, please don’t tell me that you’ll just turn off JavaScript to protect yourself!
July 24, 2008
17:28
Private Investigator or Forensics Expert
» ‎ ha.ckers.org web application security lab

What do I have in common with Magnum PI? What does id have in common with Dog the Bounty Hunter? Well in the state of Texas we all need PI licenses. That’s right, if you want to help anyone recover from an incident, investigate computer theft, or engage in any sort of investigation relating to computers whatsoever, you need to become a private investigator in Texas. We can chalk this up to lawyers legislating something they completely fail to understand.

Firstly, I highly doubt any of my customers would get any more value out of hiring Dog the Bounty Hunter to hunt through logs, or recover deleted data. Secondly, legislators are making broad statements like, “the computer industry needs cleaning up”. I’d like to make my own broad sweeping statement, “legislators who write ill-concieved laws need cleaning up.” I understand the reasoning, as poor as it might be. Proper handling of evidence, is always an important thing for convictions, but this is far more broad than that - even delving into the inner workings of private companies working to help other private companies do business.

I guess I better start waxing my chest and wearing dog tags, so I can start understanding how these darned computer thingies work.
July 21, 2008
3:19
WebAppSec Survey Time Plus A Fast Approaching DefCon and Blackhat
» ‎ ha.ckers.org web application security lab

Yup, it’s about that time again. Jeremiah has put up yet another webappsec professional survey. If you haven’t taken a look at his previous surveys you should - some of them are actually pretty interesting. Either way, it’s worth looking at the results, even if you don’t take part in the survey itself.

Also, I should note that the time is quickly approaching in which we’ll all be descending upon Blackhat and DefCon. I’ll be speaking at Blackhat on Xploiting Google Gadgets and an abrieviated version of the speech at DefCon as well. I’m also doing another speech at DefCon with Rich Mogul, David Mortman, Chris Hoff, Robert Graham, and David Maynor called All Your Sploits (and Servers) Are Belong To Us. So if you are planning on being there, drop on by and introduce yourself! I hope to see you all there.
July 17, 2008
1:47
Redirection Report
» ‎ ha.ckers.org web application security lab

Brian Krebs had an interesting report over at the Washington Post that cited a report from Indiana.edu about how redirects are in quite an abundance. Well, anyone who has worked in this field for any length of time should know that perfectly well, but it’s still interesting to get some validation from the researchers at Indiana.edu who specialize in anti-phishing research. Here’s the rub from Brian’s article:

Indeed, some of the Internet’s biggest Web sites — particularly Google — used to host large numbers of open redirects.

“Used to”? I know I’ve laid it on thick over the last few years, but I’m amazed people still think Google has somehow magically fixed problems that it never got around to fixing. Redirects are not fixed, XSS is not fixed. These issues still exist all over Google and Google’s web properties. But in case someone doesn’t believe me, here’s an example I whipped up in about 10 seconds that redirects to a random eBay auction from Google’s image server as a for instance (make sure you enable JS for the full effect).

It’s good to see people are finally understanding this in the main stream media, but let’s not give credit to companies that are clearly undeserving of it (both historically and currently). I’ll be the first one to stand up and give applause when we see these issues closed once and for all on Google even if it truly is just one company out of the vast untold wealth of sites out there that are vulnerable. But if it really is aiding phishers - and it is - the only way we are going to get ahead of it is by taking responsibility for our own sites. That’s especially true if we intend to be the be all end all of trustworthy advertising giants that Google aims to be.

← GNUCITIZEN Media Portfolio heise security →

SecurityFeed.info » ha.ckers.org web application security lab

Feeds

ha.ckers.org web application security lab (10 unread)