I hear rumors that it should be released in Firefox-next (also known as 3.6 - scheduled for early to mid 2010). So give it another year or so and we should have a workable defense against XSS on pages that must allow user submitted HTML and JavaScript - think eBay, MySpace, and so on. The only trick is making sure the companies who have these problems have projects in their pipelines to use this header once it becomes live. So if you happen to know someone who works for a company who has this problem or happen to work there yourself, please make sure others are aware of this well ahead of time. I for one am very excited to see this approaching reality after all these years, and I encourage you to watch their website for updates if you are at all interested in building user submitted widgets and the like.

On a less thrilling note it also has some clickjacking defenses in it, but just like Microsoft’s X-FRAME-OPTIONS header, I think it’s really not particularly interesting, it’s an opt-in model and clickjacking is so prevalent as an avenue for attack. Opt in security models work on sites that know they’ve got a problem (like user submitted HTML and JS) not on sites that don’t know they’ve got a problem (like wireless access points and web enabled firewalls). Alas - I digress, and I don’t mean to diminish the overall positives of this solve. Indeed, I’m very excited by the future of Content Security Policy as it may make surfing “fun” sites safe again - even with JavaScript and Flash enabled! Wouldn’t that be a crazy thought?

In unrelated news, I did a podcast with Dennis Fisher over at Threatpost on some of the RFC1918 issues I discussed a few weeks back and Slowloris. If you’re interested, please feel free to have a listen!

<DIV STYLE="background-image: url(http://router/path.to.hack)">blah</DIV>

I know there are others tags that work, but probably not as well as this method from what I’ve seen so far. I haven’t found a reliable way in other browsers to allow this to happen, but I’ve only barely scratched the surface of the vast number of CSRFable tags out there. But anyway, yes, this doesn’t cause the Basic or Digest auth dialog to fire so it will be more stealthy upon performing a CSRF that fails. Of course for POST based CSRF you’re still out of luck…

As I mentioned a few days ago, there is one way you can use the site by keeping a session open that you initiated prior to the attack, so that essentially you are the only person on the system - or one of only a handful at best. Well one place this helps you is with timing attacks. If you know a system tends to react to load because of the heavy database calls or you just aren’t certain what the effect of a lot of users are, you have an option - denial of service.

By denying service to everyone except you, you can remove the bandwidth and database chatter, and give you far more precise information about what is going on at the code and database levels. By examining the timing differences between a valid username that you know exists and an invalid one you know cannot exist you can create lists of valid usernames, or at minimum identify what the timing should be for both use cases with and without load. Again, this is another virtue of a DoS attack that leaves you alone on the system but stops everyone else from connecting. Having no one else is there to pester you or give you erroneous results is a timing attack dream come true.

First of all there’s really not all that much you can do within SSL itself to create more than binary options (there are some exceptions to that rule, and I’ll post about that later) but those binary options are actually just enough. Let’s say I have several sites. One of which is a banking site. The others just have something as simple as a tracking pixel on them. Firstly, the time difference between when the user pulls the SSL certificate and actually instantiates the site might indicate whether they are going directly to the site or if they had to take some time to accept a self signed-per site certificate (a la Burp Suite).

Now if the MITM proxy uses a standard root signing certificate one of those sites with the tracking pixels on them can use the same standard root signing certificate (since it’s sitting right there in the tool and can probably easily be ripped out and re-tasked to be used on the banking’s tracking pixel site) to sign it’s own SSL session. If the user pulls it down anyway, even with the mis-match error, you know they are either using or have used that particular MITM proxy.

Another pixel might be protected by a snake oil SSL certificate. If that image is pulled anyway, despite the mis-match error, there is a good chance they are using something like an sslstrip or something like a root signing authority. Because the image is pulled and it shouldn’t be, you know there must be something off here.

Lastly, you can have another completely valid SSL signed site. If they are using something like Burp Suite it will give them a certificate mismatch error and it won’t pull the image (at least not immediately), even though it should. Although the image may get pulled eventually, as the hacker goes through the annoying manual process of adding the cert in or okaying it, the time frames will be so great compared to pulling images on the same site that it should be obvious that they aren’t an average user.

Of course these techniques have strange effects on certain browsers, like the iPhone Safari browser as I talked about before. But if the user is claiming to be one of the common standard browsers, this technique should work - although I’d test it thoroughly before deploying it.

Then I started thinking about HTTP pipelining works in browsers, and also how HTTP sessions can send more than one request over a single socket. So imagine this. A server is under a Slowloris attack and either prior to the attack or by re-purposing one of the existing sockets to send something like the following:

GET / HTTP/1.1
Host: www.whatever.com
User-Agent: Mozilla/4.0 …
Connection: Keep-Alive
Accept-Encoding: identity, *;q=0
Accept-Language: en
Range: bytes=0-10

On some web servers this will only send back a small amount of information because of the Range request header (the first ten bytes) which is awfully similar to a HEAD request, in terms of not wasting your bandwidth looking at something you don’t care about while you wait for the attack to ramp up. But more importantly the Keep-Alive will allow you to then send a second request a while later and then another one and so on…

What that means is that you can be the one person sitting at a very large table - you’ll have the website all to yourself. That’s because all the other sockets are tied up, so that no one else can use the site. With some re-programming Slowloris could be capable of that task, or a secondary program could be used to initiate and hold open a certain amount of sockets that you can use and re-use as you probe the site or use it in peace - because no one else will be on the site to bother you. It’s just another interesting side effect of a DoS that only denies the service to everyone - except you.

As you may recall at one point a few weeks back I talked about how denial of service can be used for hacking and not just yet another script kiddy tool. Well I wasn’t speaking totally hypothetically. A month ago, or so, I was pondering Jack Louis (RIP) and Robert E Lee’s Sockstress, and I got the feeling that other unrelated low bandwidth attacks were possible. Then I randomly started thinking about the way Apache works and figured out that it may be possible to create something similar to a SYN flood, but in HTTP.

Slowloris was born. It basically uses a concept of keeping an HTTP session alive indefinitely (or as long as possible) and repeating that process a few hundred times. So in my testing, against an unprotected and lone Apache server, you can expect to be able to take it offline in a few thousand packets or less on average, and then you can let the server come back again as soon as you kill the process. It also has some stealth features, including a method of bypassing HTTPReady protection. Why is this noteworthy?

Typical flooding attacks require tons and tons of packets and end up denying service to other applications as a result. By creating a flood of TCP requests, sure you can take down an upstream router, or a web server, but it’s overkill if you really just want to take down a single website. Slowloris does this without sending an overabundance of TCP or HTTP traffic, and it does so without increasing the load significantly, or in any other way hurting the box (assuming other things aren’t tied to the HTTP processes - like a database for instance). This appears to only affect certain types of webservers (generally those that thread processes, like Apache, but not like IIS).

So I contacted Apache a week ago, because I was a little concerned that I hadn’t heard much about this, other than one conversation with HD Moore about a similar attack he encountered using a different payload. I expected a well thought through response, given their dominance in the server market and the fact that I gave them an early copy of the code. Alas:

DoS attacks by tying up TCP connections are expected. Please see:

http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos

Regards, Joe

Yes, that was the entire response. So, while RTFM is a perfectly valid response on the Internet, it’s also extremely short sighted, because almost no servers are configured properly - or if they are, it’s as a side effect of needing load balancing or something upstream that happens to protect them. Also, if you actually read that Apache.org page, it really doesn’t cover this attack at all. And Joe sorta totally missed the boat or at least mis-typed in his brevity, because this isn’t a TCP DoS, it’s an HTTP DoS. If your server used UDP and I re-wrote Slowloris to speak UDP it would work too. The best example of how this differs from a TCP DoS is the fact that other unrelated services are unaffected, and you can still connect to them like you normally would.

The reason this works is because the web server will patiently wait well beyond what is reasonable, allowing an attacker to consume all of the available threads of which there are a finite amount. That makes it a web server problem, not a OS or networking problem, although there may be OS or network solutions to Apache’s default configuration issues. This is further evidenced by the fact that IIS isn’t vulnerable to Slowloris in it’s current incarnation. Even if Apache and IIS are on the same physical box, Apache will be affected but IIS will not. That would lead me to believe it’s a architectural flaw in Apache’s default web server’s design. Though this isn’t just Apache’s problem, to be fair. Other web servers are vulnerable as well, although none come close to the size of Apache in terms of market share. You can find more information on the Slowloris page.

Anyway, I hope this gets people thinking about better web server architecture. That’s especially true if this is “expected” behavior of their web server, and at least offer a default configuration that can protect from this sort of attack, instead of having to jump through a bunch of convoluted hoops. I thought it would be better to open this up for discussion, so I encourage you to try out the tool in QA or staging and see how your web server handles it. The software is very beta though, so do not use this against anything in production - I make no warranties about its ability to do anything outside of a lab environment!

Without re-explaining the paper, it turns out that in certain browser, and with certain VPN and the current architecture of most RFC1918 networks, there is a high tendency for bad things to inadvertently happen, like IP collisions. That’s annoying in the networking world (and a well known problem) but it’s dangerous in the security world (and far less understood). Anyway, I talked it over with HD Moore and Toby and some of the other guys at SANS and it turns out they had actually seen similar things happen in the past, so it’s been validated in the wild (again, inadvertently though).

Timing: Let’s say you have a site that accepts bids up to a certain time of day - say an auction site or a site that allows you to bid on work or whatever. Most of the time people submit their bids as close to the deadline as they can so that their competitors don’t have time to revise their bids. Sure, you can write a robot to come in at the last fraction of a microsecond and underbid, but what if you want to keep your bid highest or lowest (depending on the type of site)? Well by submitting your bid earliest and then denying service to the application for the remainder of the time your competitors don’t have a chance to submit their bids.

Web services: Sometimes, it’s not a matter of denying service to the site itself, which may have all sorts of robust protections in place, but sometimes the web service is actually more interesting. This could include things like authentication or even email. Let’s say I know someone is traveling and they use their phone to get their email. If I know they are in charge of responding to events, I can deny service to the webmail server and poof - suddenly they are no longer getting updates that something else is going on that they need to take care of.

Diversionary: And that leads us to the last item on the list which is using denial of service as a diversionary tactic. Sure, we can just do the bad thing that we intend to, but wouldn’t it be so much better to throw a red herring in there to cause them to look in the wrong place while the attacker stealthily gets whatever he wants elsewhere?

Anyway, it’s an interesting concept to talk about. I think most people think of DoS as a simple script kiddy menace without considering it’s other useful purposes. And now, with a case of the Mondays, it’s time to buckle down for a lonnng week.

If you put Anti-virus on every desktop in the world, would you stop viruses from existing? I think any reasonable person who understands how viruses work would say no. It will, however, make the bad guys work harder and iterate faster to get by the filters (boutique malware). So there is actually a diminishing return once you get above a certain level of deployment. On the other hand, at the very lowest end, if only a few people had anti-virus they would be pretty well protected, because the virus authors wouldn’t bother trying to figure out a way around it. Of course everyone else who doesn’t have the AV is screwed in that scenario. So the right percentage of deployment for anti-virus isn’t global, it somewhere in the middle in that simple example.

If we’re talking about firewalls doing proper egress filtering, that would stop some worms from propagating, but it probably wouldn’t solve enough of the problems compared to the other options out there. If we’re talking about whitelisting applications that can run on computers, that would probably solve a much bigger percentage of the problems compared to firewalls, but the total cost of ownership is through the roof - and who is going to monitor and create all those whitelists. Eesh!

But back to AV for a second - AV has the hidden benefit outside of security that theoretically increases longevity of computers. So AV increases the lifetime of the computer, although the decrease in usability of the computer because of the resources that are being used might offset that number. Anyway, all of that factors into the total cost of ownership. Once we go through that exercise (which is probably best left for the product managers of each product line to do) you come up with a few interesting metrics. The first is the silver bullet metric, and the second is exactly what the maximum level of deployment that product or service should get to before it stops being an effective tool for the money - because TCO might change depending on how widely it is deployed as well (economies of scale, diminishing returns, etc…).

I’m not at all saying I have the right answer, or that I do believe there is a single best product out there, but to be the devil’s advocate, what if we did find that one product or service had the best silver bullet metric - what then? Why would we back any other technologies at that point? Anyway, it’s a fun thing to think about. Perhaps it’s just another lens by which to look at the security industry through. Of course this exercise has it’s evil twin too - which is the types of exploits that can be performed and their own associated cost benefit analysis.

Click to enlarge

The really amusing part was when a rather dim witted Google marketing person came over after a minute or so and asked if she could help us. Then she saw the ha.ckers.org logo, to which I said, “Don’t worry, we were just playing a practical joke on you.” To which she said, “Okay.” Okay indeed.

So you’ve seen ha.ckers.org on Google’s own machines at a security conference - where there’s so much irony it hurts. But what about you guys? Where can you get ha.ckers.org to show up in places it shouldn’t be? I’ll give out some sort of special prize for the winner - I just haven’t figured out what it is yet.