Some of you who have been following my blog over the last 3+ years may recall me talking about Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous. In reality I’ve been talking about this for close to 5 years privately with the Mozilla team - back when their offices were about 2000 square feet and the entire office smelled like feet. Ahh, those were the days. Well, we are creeping very close to seeing Content Restrictions (now named Content Security Policy) in reality, finally! Thanks in huge part to Gerv and Brandon over at Mozilla.

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!

One of the single most annoying things about CSRF and router hacking etc… is that you get the annoying popups on Basic and Digest authentication pages, asking you to log in. More and more devices are moving away from these popup style alerts and moving more towards form based authentication, which is better from a hacking perspective. But still, I would say the vast majority of firewall/switch/router devices out there use Basic or Digest based authentication. The problem with that from an attacker’s perspective is that it creates a noisy popup if it fails (if the user isn’t authenticated) that the user is bound to notice and question. Well, now we have an answer - at least in Internet Explorer:

<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…

Because of all of the stuff that happened over the last week or so regarding Slowloris, I started thinking about other ways to use DoS to aid in existing attacks. A lot of times it’s really the opposite of what an attacker wants to do. Typically the attacker wants to keep the system alive so they can steal information from it or break into it. The more it stays up the better.

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.

There are several different ways for MITM/hacking proxies to handle SSL. They can create a self signed root cert that the attacker/user accepts once, they can do a per site snake oil cert, or they can simply downgrade the attacker/user to HTTP (a la Moxie’s sslstrip). Any of those work, and it’s kind of a matter of preference and circumstance as to which is better. But what if I’m running a site and I want to see if the user coming in is using a hacking proxy? There’s a few techniques to do that.

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.

One of the things I noticed early on in my testing of Slowloris was that not every server reacted like you’d expect it to. Some gave database errors - I’m assuming because the database connections had different limits than the HTTP server. Whatever the reason, it only seemed vaguely interesting at first, from a fingerprinting perspective. The other issue is that to “see” the issue I had to basically hit a race condition by connecting to the webserver with my browser right in the split second as the sockets were being freed but before the database could recover. Not exactly the best way to go about things.

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.

UPDATE: Amit Klein pointed me to a post written by Adrian Ilarion Ciobanu written in early 2007 that perfectly describes this denial of service attack. It was also described in 2005 in the “Programming Model Attacks” section of Apache Security. So although there was no tool released at that time these two still technically deserves all the credit for this. I apologize for having missed these.

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!

Well, it’s been quite a week or so for me. 7 days of travel, to Las Vegas for SANS and Stockholm for the penetration testing summit. Man, I’m tired! But I promised tons of people I’d actually write out what I was talking about during my speeches, since it’s tough to cover everything in such a short presentation, with all the other things I was talking about, and now that I’m finally recovered from my jet lag, I had a chance to sit down and write it all out. For those of you who have no idea what I’m talking about, don’t worry, you’re not behind the times. You can read the whole RFC1918 issue here. I tried to make it into a blog post, but it kept getting longer and longer, so I just turned it into a whitepaper instead because it’s easier.

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).

Happy Monday! I spent the better part of this weekend thinking about denial of service, but rather than releasing a tool, I thought it would be worthwhile to talk about how denial of service attacks could be used in tandem with other attacks to exploit other logical or business issues. Let’s take a few examples:

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.

I don’t have time for a full blown Google rant today, but I was forward this link today and I couldn’t believe my eyes. This is Google’s “What’s Up” CAPTCHA. You know, when I first heard about it it was described to me as “a picture and you have to tell it which way is up”. So my first reaction was “that’s a terrible CAPTCHA - only one in four chance.” Well, it’s not that bad. If you actually read the paper it’s actually a 1/22 chance (assuming no optimizations).

There are other problems with this though - like the fact that it relies on a set of pictures and someone has to make a judgment call on what is the correct position. I bet it’s easier to solve for humans, but it’s also fairly trivial for robots to solve too. CAPTCHA - what does that mean anyway? Let’s see if Google’s project meets the definition:

Completely Automated - Google employees need to make judgment calls ahead of time on each image orientation, so this requirement of a true CAPTCHA fails and incidentally adds a hidden cost to using the “What’s up” CAPTCHA, although it might not be huge, if you make the set small (which would cause other problems).

Public - well, as public as anything Google does is public. It’s not open source or anything, but it’s out there.

Turing Test to tell Computers - I would argue that it’s not a Turing test at all, because if you have a set of 45 robots that try only one guess a piece Google’s “What’s up” will fail to catch two of them. And again - that’s with zero optimizations. Second major failure making this not actually a CAPTCHA.

and Humans Apart - I think it fails this one as well, since blind people are humans. So are non JavaScript/Flash/CSS wielding users - I know I’m human. So that’s three major failures of one definition alone. Not great!

Someone with far greater math skills than I will some day create the mathematical proof that explains why CAPTCHAs aren’t technically achievable. It’s possible to create tests that are vaguely good at telling computers and humans apart (CAPVGTCHAs perhaps?) but unless my understanding of the universe is way off base, I think CAPTCHAs are modern day perpetual motion machines. Everyone thinks they get it and it can work, but it’s never been done, and no one has come even close, in my mind. Sorry, I know this wasn’t as good a Google rant as I normally come up with, but as one of their guys over there recently told me, “You don’t call, you don’t rant…” I know… too busy!

Born from much frustration out of not seeing this anywhere else I finally created a dictionary file for all the US cities. I really couldn’t believe such a thing wasn’t already floating around. Tons of companies use US city names as names for hardware devices, passwords for networking devices, and so on. Anyway, it finally came to a head the other day when I was presented with a secret question that said “What is your city of birth?” Well, generally speaking you know that it has to be one out of around 20,000 cities in the US, so if they don’t have any brute force detection on the secret question you can brute force that pretty easily (10,000 guesses on average per account - which only takes about 1/2 an hour if you automate it).

So I looked around places like Packetstorm’s wordlist page and a few other places and finally just decided it was easier to rip one of the GEOIP databases apart and generate my own. So if anyone else has had the same problems, never fear - you can just download the list of US Cities here. Hopefully that will make someone else’s life easier. Happy auditing!