In one of the most honest moves in Google’s history, Google admitted to their own customers that their own site is bad and can be used to harm your computer. Don’t believe me?

Click here to enlarge

Okay, okay, so it was just one of the worst tested code rollouts in history, they weren’t actually admitting it (at least not on purpose). The site couldn’t handle the load, and there was a bug. But it sure is funny and ironic since really they are the top rated worst offender yet I highly doubt they will be blocking their own IP space again. At least not on purpose.

hypocrisy [hi-pok-ruh-see] (n) - when living up to your own standards simply won’t do.

While traveling through Sweden, I had the opportunity to hang out with a friend of mine, David Jacoby from TrueSec. As we were walking around he told me about a new technique he is working on to use a remote file include exploit in a scenario where the system doesn’t allow outbound access from the webserver. If you actually care about security you’re hopefully doing egress filtering on your firewall which has the great side benefit of making remote file includes fail. Additionally, hopefully you’re using a modern version of PHP which by default disallows remote files to be included. Well, it turns out David found that there’s a way around that.

Barring any other file upload, it’s usually impossible to use a remote file include attack in that situation, but an attacker can inject information into Apache access logs either by URL strings or User Agents, or they can include PHP information in the mail logs by sending email from contact forms, etc… The reason this works, is that the web user typically has the rights to read from those files and those files are in somewhat predictable locations. So instead of including a file from the Internet, you include it from the local file system itself. PHP will parse the file, and run the attacker’s code. Boom.

I typically tell people to make sure the entire file system is not writeable by the web user, but unfortunately those types of files are pretty important to be able to write to for the site’s basic functionality on most systems. However, there is still an option there. You can use commands like chattr (change attribute) under *NIX platforms to make the files writable but not readable by the web user, which would solve that problem, or making it not readable by the web user using chmod - either way. Pretty cool research from David!

I’m sure you’ve heard about the new IE8.0 Clickjacking protection here, here and probably most importantly here on the IE blog. It’s probably time I explain exactly what the pros and cons are of this technology as I see it. It’s a complicated problem for those who aren’t entirely initiated so bear with me.

Pros:

1) It will protect against clickjacking if the header is present.

2) It has some usability improvements over the original idea I heard which is that it can allow same-domain iframes.

3) It doesn’t require a plugin which makes it useful by default for any users of IE8.0. That’s a good thing - now if we could just get Noscript built into the browser too! Firefox currently has no default equivalent and I don’t know of any viable projects underway to create a better fix in any other browser by default. That gives IE an edge in the market for default users, once the browser reaches the user’s desktop.

Cons:

1) It’s proprietary to Microsoft - which means that other browsers aren’t protected on the same site that tries to protect itself. That dramatically reduces the percentage of coverage - but that’s a reasonable issue in my mind because we have to start somewhere and other browsers can adopt it if it’s a good idea. There is precedence for this - HTTPOnly. HTTPOnly was a Microsoft proprietary tag on the end of cookies. They invented that concept many years ago and here we are years later and relatively few sites have adopted it and almost no browsers have adopted the standard, even though I think most security people would agree it has a lot of advantages over normal cookies. So if it took years for developers to add a few bytes of text to a cookie that they were already setting, how much longer is it going to take for them to understand how to set an entirely new HTTP header? If your bet is years, you and I are in agreement.

2) No one uses IE8.0, yet. You wouldn’t believe how many times I’ve gone to a customer’s site and realized that everyone in the company is still on IE6.0! Yes, you heard me, not even 7! It’ll be a long time until we see companies getting with the times (and by the times I mean this century’s tech).

3) Since it’s an HTTP X-header it will severely limit who can protect themselves and in what circumstances they can protect themselves. That’s not altogether a bad thing, because most of the big sites can probably muddle their way through this problem. But it’s not nearly as easy as it would be if the browsers just worked securely by default.

4) There is no way for an average user to know that a site is protected (this was Giorgio’s point). Even more advanced IE users would find it a pain to check every single function on every site to make sure it was sending the proper header. This isn’t that big of a deal in my mind simply because there are tons of things average consumers can’t do. It doesn’t bring any peace of mind though, like an SSL lock does - for whatever real security good that does. But this header isn’t even a public relations win unlike whizbang green EV certs.

5) It doesn’t work for all companies in all situations. Companies like banner advertizers, who need people to be able to click on their sites from other domains, can’t protect themselves because it would break their functionality. Similarly mashups and widgets present a real technical challenge.

If you’re a company and you really want to go through the trouble of implementing this as a short term stop gap for the very few IE8.0 users that visit your website, there may be some shortcuts. For instance, if you have an HTTP gateway (like a F5 load balancer or any sort of HTTP proxy for instance) you may be able to send this header on every request without touching your application logic. Not ideal, of course, but it’s possible and probably a lot cheaper than re-writing a lot of application code to protect those very few users who would be protected. All in all I think this is interesting tech from Microsoft and I’m glad they’re thinking about it. But it’s not a panacea, and you shouldn’t rest easy if you’re an IE8.0 user.

I’ve been promoting the concept of opt-in security for years now. I was the one who first came up with content restrictions for instance and pushed it heavily for the last 4-5 years now (and we still don’t have it). So this is one of the first very good examples of that philosophy - which is that sites should be able to protect themselves without having to interfere with anyone else’s tech anywhere else on the internet. It’s a good model in the case of content restrictions because the amount of sites that take rich HTML and need to allow script and objects and whatever else (think MySpace), still shouldn’t be forced to allow their end users to steal cookies as a price of doing business.

The amount of sites and types of sites that intentionally allow rich HTML to be posted by any user are extremely small in comparison to the global scope of all websites everywhere. So the opt in content restrictions model makes sense in that case. X-FRAME-OPTIONS on the other hand applies to a surface area that effects nearly all dynamic websites on the entire Internet. Clickjacking is closer to CSRF than it is to sites that are vulnerable to persistent XSS worms. So while the opt in security model made sense in one sense, I think it’s improper to think about these two problems as being similar enough to warrant the same model. I’m not trying to beat up on MS here, I just want to explain my opinion!

It will be years at the earliest before enough companies adopt Microsoft’s solution to make any real difference in the clickjacking surface area that is the Internet. The really pragmatic question is why bother creating a partial fix for a problem that no one has actually maliciously exploited yet? I’m still waiting for an actual exploit to hit the wild before I start sounding the alarm bell. Sure, there’s tons of workable exploits out there. But like a lot of things this all might be premature - there’s still a lot of easier ways to exploit websites and consumers out there.

The 100 embassy passwords that were compromised in the middle of 2007 through compromised Tor exit nodes has always stuck with me. Simply sniffing passwords is a great way to gain a ton of intel about the traffic that’s going over the networks. But what about other bad things?

Two “attacks,” if you can call them attacks, sprung to mind when I heard about that. The first was changing banner ads. You can change one banner ad to be another banner ad, and get the additional revenue associated with that. Doing may or may not prove to be lucrative because people using proxies generally aren’t clicking on a lot of ads - or if they are, they aren’t the brightest bulbs.

However, cookie stuffing is actually a slightly more feasible attack. By putting reseller cookies in the browser for every request made to a partner’s website, it’s entirely possible that some of the people who use the proxy will forget to clean their cookies upon closing down the proxy. Hackers hacking hackers. Of course, again if someone is using a proxy to anonymize themselves and they don’t clear cookies too, they probably need to get hit with a clue stick.

Amit Klein and I’ve been going back and forth for the last few days regarding my last two posts, how browsers cache requests, how that can be abused, etc…, and in the process of it, Amit came up with another interesting way to do the same thing but without requiring any DNS rebinding whatsoever. Here’s his idea:

BTW, I can improve your attack (I think), by eliminating the need for browser restart. If www.attacker.com sets domain-wise cookie for all “.attacker.com”, and then forces navigation to say target.attacker.com (that maps, even statically, to 10.10.10.10), you have your XSS delivered.

He’s right - that would work. So really, being able to set cookies for an entire domain is actually a security issue, since it can actually impact functionality on other websites that aren’t owned by the domain owner. Interesting take. Again, while this wouldn’t give you access to the user, it might allow you to change site functionality, inject XSS, insert erroneous tracking information or something else - whatever could be done from an un-authenticated user state.

In an attempt to clarify my post on the dangers associated with persistent cookies and DNS rebinding, I’d like to give a simple scenario and then describe solutions. Let’s say there is an intranet website called intranet.exploitable.com that resolves to 10.10.10.10, and there is an attacker website called www.attacker.com that resolves to 222.222.222.222. Now let’s say intranet.exploitable.com typically sets a cookie that has also has a known XSS vulnerability in it (could be known because the attacker knows what sort of open source software is used internally, or they were once a contractor or whatever…). Now let’s also assume that the website is not SSL, as most aren’t and it would mess up the attack with a mis-match SSL error.

Okay, so the victim user visits www.attacker.com who sets the same cookie as something like this:

Set-Cookie: last-visited=<script>alert("XSS")</script>; path=/

Then the user shuts down their browser, or the attacker forces a browser shutdown through any one of the dozens of browser DoS scripts out there. Eventually the user goes back to www.attacker.com, but this time, the site changes it’s DNS to point to 10.10.10.10. Because the browser was shut down, the DNS for www.attacker.com is now allowed to be rebound to the new IP address, which happens to be the IP address of intranet.exploitable.com. The user now visits that site with the XSS exploit in their cookies, with the incorrect host header:

Host: www.attacker.com

However, because most sites don’t care about host headers, the request is still parsed by intranet.exploitable.com’s website. The XSS is now running there. While this wouldn’t allow the attacker to log into their account, it would allow them to “see” what is running on the victim’s intranet website, by using an XSS shell. Although this attack may take a while, it’s not that difficult, compared to a lot of other rebinding attacks.

Now in terms of mitigation, there’s a whole host of things you can do if you happen to run intranet.exploitable.com. Firstly, using SSL would stop this attack because of the SSL to hostname mis-match. Secondly, not allowing any unknown host header to be sent would stop the incorrect host header from being processed. Using client side protections like LocalRodeo would stop the intranet from being contacted as well. Lastly, making sure that _all_ cookies are removed upon each shut down of the browser would stop the attacker from being able to re-use their cookies after having forced the victim’s browser to shut down. I hope all that was a lot more clear.

Let’s talk about cookies for a moment. Cookies, for the most part, are persistent. Sure, more browsers are trying to make it easier to reset cookies, but still, a fairly small group of users regularly remove cookies on each browser shutdown, or with enough regularity to make a difference. Now let’s talk about web servers. Web servers, for the most part, don’t care if you send a host header. If you send nothing, it’s the same as if you sent the host name. This has never seemed like a great idea to me, but nevertheless it’s really common, except in virtual hosting environments.

Lastly, let’s talk about DNS rebinding. The browser typically pins the DNS to the same IP-to-DNS mapping for the term of the browser session (DNS rebinding exploits notwithstanding). I’m not trying to discount DNS rebinding exploits for the moment, but rather, there may be another vector here, even if DNS rebinding ever does get “solved” by being able to map the IP to the DNS for the term of the browser session.

Now, remember, the cookies can outlive the browser session, and that is entirely based on how they are set, unless the user intentionally removes them. So let’s take a scenario of a message board that allowed crossdomain images. An attacker could submit two cross domain images. The first being to http://www.attacker.com/image.php and the second being http://victim.attacker.com/somefunction.php. The first image would set a cookie to test and see if the user had visited that domain before. If not it sets a cookie. The second domain (victim.attacker.com) sets a cookie that is designed to be used on www.victim.com.

At some point down the road, the user reboots their browser window. Later they go back to the same board and visit the www.attacker.com image which alerts the DNS for victim.attacker.com to switch to www.victim.com’s IP address. Although the hostname is wrong, the cookie is still sent. Since the cookie doesn’t contain any information to tell the server that it’s being sent a cookie from another subdomain, the server helplessly executes somefunction.php with the credentials set by the attacker.

While this won’t help an attacker gain access to the user’s cookies, it will allow them to set their own, which can have all sorts of nasty side effects, depending on what those cookies control. There are some XSS attacks that can only be performed by setting a cookie that contains the payload, which is normally a non-issue since being able to set a cookie cross domain is supposed to be impossible. However, this scenario would enable those attacks, unless it’s a requirement that that same cookie also contained session information that the attacker couldn’t know since they won’t be able to read the user’s original (legitimate) cookies for www.victim.com. Of course it’s just far easier to do this kind of exploit by just waiting for a certain amount of traffic to hit your site and then just switching the DNS over as well, but that’s just too easy of an attack. Anyway, it’s just a thought!

Over the last few days I’ve had the pleasure of corresponding with Justin Samuel, who has recently authored a new module called RequestPolicy that has some pretty wide reaching security implications for anyone who is concerned with cross domain related exploits. Here’s a snippet of our conversation:

RequestPolicy gives users full control over the cross-site requests made by their browser. It has a default deny policy and allows easy whitelisting of origins, destinations, and origins-to-destinations.

The website is here:

http://www.requestpolicy.com/

You can probably imagine the various security issues this helps with (not just CSRF, but that’s a big one). We have a security page here with some details:

http://www.requestpolicy.com/security

I see RequestPolicy as fulfilling an essential role for privacy and security in our browsers. I believe that a truly secure Firefox install is running at a minimum both RequestPolicy and NoScript. (RequestPolicy is not a competitor to NoScript, obviously, but unfortunately a large number of people immediately think this because they are unaware of threats that aren’t from scripts and objects.)

Justin has a bunch of things on his to-do wishlist, including improvements to the UI, more granular control over what gets blocked, a blacklist of subnets (similar to localrodeo), and so on. Of course there are a few small issues that I ran into almost immediately, like the fact that subdomains are always allowed, which means an attacker could subvert that protection by assigning a subdomain to RFC1918 (assuming LocalRodeo wasn’t installed) or to a target domain that required no cookies to be submitted for the exploit to function since the wrong hostname would be sent. So perhaps for the time being a combination of LocalRodeo, NoScript and RequestPolicy is the safest bet.

It’s also fairly easy to detect that this module is installed, and for most users, it will be a very tough user experience to get used to, unless they whitelist everything. Still, very cool module to prevent most of the crossdomain/cross website client side hacking, and I bet it will become even better with time!

This post is meant to be overly controversial, but it’s also meant to make people think. Please take that for what it’s worth. My most recent publisher said that I shouldn’t make excuses before I say something, but in this case, I think it’s warranted because it’s a little out there, but I also think it’s a topic worth discussing. Please bear with me.

Looking back in American history, there have been a few significant military losses of recent years. We could easily call Korea a loss, and Vietnam was the worst “police action” in American history. Afghanistan is a tossup, and only time will tell. However, I think there is a perception that there is no way the United States could ever have won those wars. That’s just not true.

The United States has a wide variety of unconventional weapon options and military tactics that it never used. For instance, we never ventured north of a certain line in Vietnam, but only for political reasons. We also never used nuclear, or non-nuclear WMD’s. The United States stockpile of biological, radiological and chemical weapons is unrivaled by any country it has ever gone to war with since WWII. But it never chose to unleash those weapons or pursue those tactics, and ultimately the US lost. But more interestingly, the US chose to lose.

I think this analogy speaks nicely to a computer security problem regarding crime in general. There are a set of options that we as computer security practitioners have at our disposal but we also have chosen not to use them. I would say that in well over three quarters of the attacks that I am aware of, it is trivial to find the person who is responsible for them. Sure, that could change and yes, it’s easy to frame people for crimes they did not commit, but for the moment, let’s just pretend that that statistic was valid.

There are two ends of the spectrum of punishment. On one end we have capital punishment - the ultimate result. It’s pretty much a guarantee that their life of crime is concluded upon their death (barring time delay attacks which are incredibly rare). Most people don’t believe in capital punishment for any purpose other than extreme cases and still I would say there is no clear consensus about when it should be used. However, there is no debate about the finality and clear effects of capital punishment.

On the other end of the extreme we can do absolutely nothing, or worse yet, reward the attacker for their actions in some way. I would argue that more often than not the second is the option we as a security community take. When we are aware of a problem we either do nothing at all because we believe it won’t actually work against our systems, or we block the attackers, under the false premise that that will stop them. In reality it only makes them stronger because they now know how our defenses work, which they can either try to circumvent later or use as knowledge against other targets elsewhere.

Only in the most extreme cases do we actually bother to track down, locate, arrest and prosecute attackers. And even then the penalties are usually only a few years in jail. Most experts believe that jail is not an effective rehabilitation habitat. While it’s admittedly unclear what the effect is on computer criminals, it’s certain that it is not an effective deterrent given how much computer crime occurs.

Now let’s imagine for a moment that we were decide that capital punishment were a reasonable solution to a problem, because it was an actual deterrent. I know people who care a lot more about their life than they do about jail time, so it’s not an unrealistic assumption. Let’s take a small slice of computer crime, that’s considered by almost everyone to be a minimal offense but also highly annoying - spam.

A few years ago a spammer was killed with a hammer. Now let’s say whether by vigilante justice or state sponsorship, once a week a spammer was killed in the same way, as a symbol to all other spammers everywhere - keep it up and you’re going to end up like this. It’s a terrible fiction I’m spinning here, I know, but I honestly believe it would reduce the amount of spam far more than the amount that was generated by the deceased spammers alone. It would actually have the effect most punishment is designed to have - it would be a deterrent. Although, admittedly it’s gruesome and unrealistic.

So on one end of the spectrum we have nothing which is what we are primarily doing now, and on the other a punishment that outweighs the crime. (Technically, we actually are doing something - we are making it less financially viable for the attack to be profitable by reducing the amount of spam that gets through, but we are a long way from succeeding, unfortunately). In the same way that the US wasn’t about to start using thermonuclear weapons in Vietnam and Korea and most likely won’t in Afghanistan either, we as a society aren’t going to start killing spammers at any rate necessary to act as a proper deterrent. Now I told you all of that so that I could get to the real meat of the matter. What is the proper proportionate response to computer crime to act as a deterrent?

There was an interesting section of a book (the title is escaping me as I write this) that described things that were off limits in a pen test. Things like rubber hose cryptanalysis are apparently not allowed during a pen test (although if anyone wants me to beat them up to see if I can get their password out of them, just let me know - I’ll give you a discount too). It’s funny but it’s also true. In the real world that is an option, just not one that many people use.

So things that are typically off the table that we don’t talk about as a real option are things like kidnapping loved ones, extortion, torture, and of course capital punishment. While all real actual options, we have tied our own hands and said we aren’t allowed to use them. We also take other options off the table, like hacking into people who hack into us, DoSing them and so on. We aren’t even allowed to fight back! So the real heart of the matter is what is the right response to a packet bound for your network that intends to do you harm? Should we keep ignoring it or should we instead track the originator to the ends of the planet and enact a gruesome deterrent for the greater good of all humanity?

No, put your gun down, I’m not saying we should go on a spammer killing spree, although I’d be plenty happy to use my rubber hose on them every once in a while. Perhaps instead of killing people we should make it a priority to actually pursue attackers instead of defending ourselves in a reactionary manner. My friend Mike Rothman is fond of saying “REACT FASTER”, but maybe reacting isn’t enough. Maybe we as a society are missing the most important dimension of this whole thing by focusing on reacting instead of going on the offensive.

We actually pursue shoplifters and put them in handcuffs, which in terms of monetary loss can pale in comparison to a computer criminal’s potential. Shoplifting is a relatively petty crime too, yet the consequences are so severe compared to the crime itself and with the wide proliferation of modern loss prevention technology most people don’t shoplift. Maybe if more people were actually forced to face the consequences of their computer crimes all over the world, it would have the effect the laws were intended to have - which is to limit the breadth and scale of the crime itself.

Until something like that happens, I find it difficult to believe we will ever see a real decline in computer crime. I know one thing for certain - what we’re doing now isn’t working.

I read a few interesting posts here and here regarding brute forcing HTTP verbs. The F5 post suggested that it is possible to thwart people who are looking for what options you support by giving a fake response. That’s certainly one way to do it, but it’s not as robust as it might appear.

By actually testing each verb by hand, it’s pretty easy to skip using options, if that’s not available to you. Or, if you are on the defensive side, if you are turning off one verb, turn off everything that you don’t use, so you don’t have to worry about it. Iterating verbs can be super useful for finding open/unprotected Webdav servers, finding open directories that allow PUT, or open proxies. In general automated worms just try to perform the exploit rather than iterate options anyway, so in general it’s probably a good idea to shut down all HTTP verbs and open them up as you need them, rather than close them down one at a time as you figure out why they could be used for nefarious purposes.