This post has been sitting in my to-post-about file for ages. I don’t know why it took me this long since thankfully, it’s one of the few things that I don’t actually have to research to post about (which is rare for me, actually). Anyway, almost exactly a year ago the Microsoft Live Labs group came to me and asked me to check out their web sandbox. Unlike Content Restrictions which is browser specific and still not available publicly, Live Labs tries to solve the problem of allowing rich user content by way of an API that blocks all known bad inputs.

It was written, in large part, by Scott Isaacs, who was one of the original guys who worked on the JavaScript engine within IE - so he knows what’s he’s talking about. The upside is that I wasn’t able (in the admittedly small amount of time I looked at it) to get around the filter. It may be possible to do, especially as technology changes, but it certainly wasn’t straight forward. I’m sure the Live Labs team would love feedback if someone was able to. The down side is that this is an API that you must send your data through. So it’s not on-page entirely, as it must go through a filter that they’ve developed server-side. If you can get around that one barrier, it’s a pretty slick little tool. I’m sure they’d appreciate feedback.

Every once in a while it becomes clear that there is a nice convergence of technologies and of the ecosystem itself where it may be possible to divine the future through the tea leaves. I stumbled across a page that shows how you can measure how many of your visitors look at porn using the CSS History hack. Now let’s take a step back. This is the second time I’ve seen the CSS history hack used in a production environment in just a few weeks, and never before. Two completely different applications (one for blocking Torrent users and this one, presumably just for fun). Two in a few weeks… statistically irrelevant possibly, but maybe it’s also pointing towards a new convergence of interest in this relatively old technique.

Now let’s take some of the stuff that Jabra and I (and others throughout the last several years) have been working on to actually get usernames and even people’s full real names from computers (here and here). Now what if you knew that Mr. Conservative Republican Congressman from a bible belt constituency was visiting a gay porn site? Suddenly something as simple as a few de-cloaking hacks turns into a perfect way to blackmail someone. I’m not saying it absolutely will happen, I’m just saying that we now have enough tools at our disposal and there is enough interest converging towards anti-privacy that it wouldn’t take much to turn it into a viable weapon against prominent individuals. The only trick is surfacing the JavaScript payload to the right demographic. XSS anyone?

For those of you who have been following the much anticipated Content Security Policy - you’ll be excited to know it’s currently available for early preview. The guys at Mozilla have a blog post explaining the details of where Content Security Policy is and asking for input. As you’d expect it’s not as full featured as it will probably end up being when it finally gets released, but if you want a chance to tell Mozilla what you think, this is the place to go.

They also include a demo page so that you don’t have to do your own development, you can just try it out right on their site. The demo page can be found here. For anyone interested in solving XSS issues on sites that need to allow it by policy (because of user demand), this is something you should definitely look into. Come to think of it, user generated HTML kind of reminds me of this picture. If it seems like a bad idea, it probably is - but maybe we can make a bad idea worth it after all:

Click to enlarge

I got an email from MaXe describing a way to inject JavaScript protocol directives in such a way, that they got around a rather stupid filter that looks for :// (naturally limiting you to things like http:// https:// ftp:// and the like:

Basically when researching this vulnerability I found out a “new” way: (at least in my little world) http://forum.intern0t.net/exploits-vulnerabilities-pocs/1502-vbulletin-3-8-4-cross-site-script-redirection.html http://forum.intern0t.net/blogs/maxe/62-having-fun-cross-site-scripting.html

Basically some forum applications and such checks url inputs for ://, just like vBulletin did before the patch so after some time I came up with javascript:// ..

Which wouldn’t really do anything, but if you apply “new line” or “carriage return” (%0a or %0d) to the url then you have all the power in the world.

So basically javascript://%0A is “cancelling” the comment (actually the browser interprets it as a new line just as described in my blog) and there by making f.ex. alert(0) possible.

javascript://alert(0) wouldn’t work of course since alert(0) is commented out.

javascript://%0Aalert(0) works because alert(0) is placed on a new line!

Pseudo example:
<script>
// %0A ( \n aka new line )
alert(0)
</script>

I know it looks so simple and anyone could have come up with that, but I haven’t seen it yet anywhere on the net and it made my day.

Pretty clever filter evasion there. Easy enough to patch, of course, but just another great example of how people’s mis-understanding of the protocol and languages they are attempting to thwart works against them. Chalk this up to another blacklist that shouldn’t exist.

Jeremiah brought my attention to the new Firefox 3.5+ CORS (Cross-Origin Resource Sharing) which is a way to do a cross domain XMLHTTPReqest. Does that sound scary? Well, it is, but there’s been a ton of work into hardening it. It has all sorts of cross domain opt-in verification built into it to limit the abuse. Honestly, if you look at the people who were acknowledged in it’s construction, it’s a who’s who of people who understand cross domain browser security issues. So it wasn’t surprising that it was fairly free of obvious flaws.

Anyway, I was poking around with it and I noticed that it had one fairly strange issue. Although an attacker is not allowed to know if the page was there or not (only if it was allowed to see the content or not), the attacker is still allowed to make an initial request. In doing so that initial request can be used as a pseudo “ping” sweep. You can tell if the site is there or not because it will either return immediately (latency and threading applies) or it will wait around much longer (between 20-75 seconds on the several networks I’ve run this on) before the browser gives up. That timing difference is pretty substantial - and as a result you can enumerate a substantial amount of internal address space behind the victim’s firewall and relatively quickly. I created a demo here (works only in Firefox 3.5+ and you must enable JavaScript globally for this to work). It won’t work if you just whitelist ha.ckers.org you have to globally allow JavaScript if you use Noscript for the demo to work - and you must disable ABE in Noscript as well.

You can read the page for the details, like the fact that basic and digest authentication popups are suppressed which makes this technique ideal for Intranets where those are common and would normally alert a user to the fact that something was wrong in the browser. It also doesn’t matter whether you do or don’t have port 80 open for this to work, I should note that there is a IE8.0 version of Firefox’s XMLHTTPRequest called XDomainRequest, but I didn’t have much time this weekend to try to get it working in both browsers so I have no idea if it has the same issue or not.

Incidentally, Jeremiah and I both gave the thumbs up to the idea of a cross domain XHR several years ago when the Mozilla team first asked us about the concept. Because there are so many other things wrong with the browser Jeremiah and I told them that it wouldn’t change much - the browser is already so broken from a security perspective that it really didn’t matter - a sad commentary thinking back. Of course, it really is all about the implementation.

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!

I’m happy to announce that Microsoft has released MS08-069 today. It’s got a lot of changes in it, but one in particular that I’ve been tracking for about a year now. MSXML has made a change so that HTTPOnly cookies cannot be read by XMLHTTPRequest within IE. Why is that good? It makes it so that JavaScript can no longer steal cookies that try to protect themselves. That’s a good thing.

It might seem like a big thing that that was even possible, but really it’s not as bad as it sounds, making this issue a lower priority in my mind. Cookies are rarely sent from the server to the client on every request and typically do require some information to be sent (like a username and password) before the Set-Cookie header is sent. So XMLHTTPRequest was really only useful for stealing cookies if the Set-Cookie header was sent on every request. Maybe there are some sites out there that do that, but it’s not that common. Either way, I’m glad MS got around to fixing it.

Meanwhile, the other browser that has implemented it of note is Firefox, and I hear rumors that they too are fixing this problem although I’m not sure on the timeframe there. So good news all around for HTTPOnly - the little non-standard cookie directive that could, and one of the few practical defenses against credential theft in the face of XSS.