You know, just when I think I’m being a super nice guy, and I go out of my way to go through responsible disclosure, I am slapped in the face with the exact reason why I don’t think responsible disclosure works for some companies. Certain companies I have worked with are ultra responsive, understand risks, and do their absolute best to combat anything that may be used to harm them or their consumers. Then there’s Google:

Hi RSnake,

On further review, it turns out that this is not a bug, but instead the expected behavior of this domain. Javascript is a supported part of Google modules, as seen, for example, here: http://www.google.com/apis/maps/documentation/mapplets/#Hello_World_of_Mapplets. Since these modules reside on the gmodules.com domain instead of the Google domain, cross-domain protection stops them from being used to steal Google-specific cookies, etc. If you do find a way of executing this code from the context of a google.com domain, though, please let us know.

If I misunderstood the report in any way, please don’t hesitate to correct me. For the moment, though, I’m closing this issue. Thanks for sending this over.

Regards,
The Google Team

BZZZT! Wrong answer. Thank you for playing though. On further review, Google needs to figure out what XSS is used for - it’s not just for credential theft. You couldn’t make this stuff up if you tried. Putting phishing sites on gmodules.com is apparently expected behavior. My favorite part of this email is where Google explains how cross domain policies work. I’m simply not impressed. Click here to see the XSS hole. I’ll let the JavaScript injected on Google branded domains do the talking for me.

So for anyone interested in exploiting this non-bug, they would tell people to add their own modules, which are hijacked, of course, allowing them to take over other people’s websites when they embedded the erroneous third party code. Kinda nasty. Unlikely, but nasty. More likely it would simply be in phishing sites that didn’t want their sites taken down, but wanted Google’s to be taken down instead. For the record, this is not the first time I have responsibly disclosed issues to Google, and this is the third time they have said what I reported was either not a bug or too hard to fix. So much for using responsible disclosure with Google. Ugh.

Okay, it’s time for the second round of the ha.ckers.org challenge. If you remember last time I didn’t do a particularly good job of giving people a head’s up that the challenge was happening. This time I’m giving you lots of warning. I also made it harder in a few small ways. id thinks it’s way harder, but we’ll see, I have a feeling it’ll be solved pretty quickly (it can theoretically be solved in under 5 minutes if you already knew how to solve it). Here is the exact time it will start. Please make sure you do the correct conversions into whatever timezone you are in:

Monday August 20th at 1PM Pacific Time (4PM Eastern Time).

This time I’ll be focusing less on HTTP and a lot more on “states”. That’s your one and only hint. When the clock strikes, I’ll remove the htaccess file and you’ll find the challenge sitting here. Feel free to use the forum to chat amongst yourselves before/during/after the challenge. id and I still haven’t come to agreement on the prizes, but if anyone wants to sponsor the challenge and give away some shwag, let me know. Otherwise it might be more tee-shirts since we still have a box full of them that we’ll need to give away at some point or another.

Again, the rules of the challenge and the directions are part of what you need to find. There are lots of things going on, and I tried to build on the same framework as last time, so having some familiarity with the last test might help you (or it might not). Either way, it’s tough, and requires work, so good luck to anyone who attempts it. For those of you who couldn’t figure out the last one, don’t bother with this one, this one uses many of the same principles. I hope you guys like it - we are already coming up with some pretty out of the box ideas for the next one.

If you missed our Blackhat talk the other day and wanted to hear it, Whitehat is sponsoring a webcast this Tuesday. It’s at Tuesday, August 21, 2007 at 11:00 AM PDT (2:00 PM EDT). This is going to be almost a direct repeat of our Blackhat talk, so for those of you who already made it, don’t worry if you miss it.

We’ll be talking about a lot of the same concepts that we’ve already talked about on our individual sites, so if you are up to date and current with this and Jeremiah’s site, you probably won’t learn anything, but for those of you who tend to be hit and miss on the site and the technology, it’s probably worth it for you to join in to see a lot of what we talk about come together.

Stefano Di Paola sent me an interesting email the other day. Honestly, it took me a good hour of playing with it before I finally wrapped my brain around what was going on. Using data binding he can make JavaScript attach user content to the page while validating that it does not contain active content. That is, styles are okay, but JavaScript is not. Very interesting. Here’s the demo (warning, not for the technically feint of heart).

Stefano asked me to give my report on the good and the bad. The good is, this is pretty damned good at stopping XSS. It probably won’t stop abuse of styles that position themselves over other people’s content, but it would stop a good deal if not all XSS if implemented properly. That’s the good news (and that’s very good news for most people). Here’s the bad news.

The bad news is that it requires JavaScript to work. If you don’t have JS installed, forget it. That’s bad news for security people, bad news for accessibility, and even worse news for robots who are trying to get contextual understanding of the page. It also forces the bottom of the page to be where the user generated content is. That’s also bad for SEO because it means the most relevant content is at the very last part of the page. Depending on how the page is built and the spider, this may fall off the size limits of the robot. Not good. Lastly, it would reap havoc on lots of those poor web application scanners. They would light up like Christmas trees because there is NO output encoding done. None. Zip. It’s funny to make web application scanners have false positives, but it’s also a pain in the butt if you’re the operator of said scanner. Herein lies one of the advantages of scanners that use built in rendering engines (forgiving any other issues they may have).

So where would this be useful? Think about all those web2.0 applications out there that have to put dynamic content on the page, don’t have to worry about spiders, robots, and need to make sure that what they output is okay no matter what encoding, or any other craziness that users may put in. I’m not advocating being sloppy, and there may be other issues here that I haven’t found, but thus far, it’s looking like a promising technology. Very nice work by Stefano!

A few people have mentioned Stanford’s DNS rebinding paper over the last few weeks. I’ve known about it for several weeks when it magically appeared in my inbox. Absolutely nothing in it comes from me or any of the research I’ve done, so I should probably give my thoughts - late as they may be.

First the good - the paper does an excellent job of explaining why it’s a problem. It doesn’t mention some things that I probably would have, like clients that need to access localhost webservers (EG: Google Desktop) but alas, other than that minor omission I really liked how they showed that much of the web is ownable and how they did it with only $100. Not too shabby! If you want to test your browser go here (there’s no warning so if you want to protect yourself turn everything off before going there).

Now for the bad - a number of the mitigation techniques mentioned are pretty flawed. For instance, browser pinning by width (Page 7-8) only works if a webserver is moving within a class C. Every time I’ve done a webserver move, it has been well outside of the class C. The way they tested where DNS can rebind to is pretty flawed, because it doesn’t measure moves, it only measures where the hosts are in relation to one another. Trust me, for most companies in the process of datacenter moves (which I help with regularly), this is a silly mitigation technique.

Pinning based on Internet verses Intranet has some problems. I’ve been talking with the Microsoft folks about this, and I really think it makes less sense to think about it in terms of RFC1918 and more about zones. Sure RFC1918 and localhost represent a certain zone, but there’s lots of cases where IP based restrictions fall on the Internet, rather than behind NATted addresses. I’d rather leverage zones, and allow people (most likely sys-admins) to modify zones to include whatever is necessary. This same issue befalls the long term mitigation techniques mentioned at the firewall levels as well. Also, when people use proxies, all DNS resolving is done by the proxies. One more place that needs to be fixed.

The Hostname Authorization just seems like a huge can of worms. There’s really one of two ways to do this. The first would be to require a re-deployment of every webserver on earth, plus having an up to date registry of all bound hostnames - which if able to be queried could leak more information about the host than some administrators feel comfortable with. If you didn’t go that route and instead put this onus on DNS (as their paper suggests) it will require changes to all browsers to consume that data - which is pretty insanely complex and will take many years to get in everyone’s hands but do-able. But it also means that every webmaster on earth needs to modify their DNS records. Something tells me this long term solution is a bit of a pipe dream. This sorta reminds me of SPF. Who’s using that? Only the largest of large companies and banks, even though spam affects everyone.

So all in all, it was a pretty good paper, but I hope the browser companies seriously think through the mitigation techniques and the use cases before implementing them. There are some good thoughts there, so it’s not a waste of research, but I don’t think this paper will be the final word on where DNS rebinding is heading.

Ronald just posted an interesting PoC code that quickly enumerates a huge chunk of the variables inside Firefox. Basically, by including the JavaScript from the plugins, and the chrome in the page, by iterating over the list, you get all the variables out of the plugins. Here’s his writeup. Depending on what security information lives in those plugins, you could theoretically find some really nasty stuff.

As it stands this is only for recon, but plugins tend to do lots of dangerous things, like store personal information, or give access to the drive, or what have you. By being able to access those functions and variables directly, that could give an attacker all the tools necessiary to pretty much hose a machine depending on what you’ve got installed. Ouch. The PoC lives here. It doesn’t steal the variable information in the PoC but it easily could. Very nice work by Ronald!

A few weeks ago fukami showed me a sample application he had written in Flash to do port scanning. It was actually really good, and accurate. It’s probably a preferred method, if the target uses flash since it’s pretty fast. He asked me to wait to post until after he had released it, and he has now done so. Please check out his demo and writeup here. You’ll need both JS and Flash enabled.

The basic premise is the error handler for the socket control can be used to detect raw sockets that are open. It also doesn’t seem to have restrictions against testing localhost, and not the server it’s hosted on, which is a pretty bad cross domain issue. He recommends downgrading flash to 8 and/or using Flash only on trusted sites (which is only helpful if the site isn’t vulnerable to XSS). Great demo, and nice work by fukami!

In talking with the browser companies there seems to be more and more interest in content restrictions. For those of you who don’t know anything about it, let me just quickly give you the overview. Three or four years ago I was trying to find a way for my company to put malicious user generated input into a sandbox but still allow it to show up on the site. The obvious answer was use an iframe to isolate it. That, unfortunately, has all sorts of user experience issues. The first one being that you cannot tell how big it needs to be so you often end up with double scroll-bars which messes up printing, and causes links inside flash movies to only change the iframe instead of the whole page. Yah, it’s ugly. So I started looking for alternatives.

The first was talking about the concept of a re-sizable iframe. There are security implications with that cause the parent to know the state of the child, so that was thrown out by the Mozilla team. There may be tricky ways to bring that up but some of the other usability problems are still there so it’s not really ideal anyway. So the best alternative is to create something that tells the browser, “If you trust me, trust me to tell you to not trust me.” This is based off of the short lived Netscape model that said if a site is trustworthy you lower the protections of the browser as much as possible. Content restrictions was born. I submitted the concept to Rafael Ebron, who handed it off to Gerv. It went to the WHATWG, and that’s where it’s stayed for the last 3 years or so.

The Netscape model doesn’t work if the site you trust has lots of dynamic content. So by extending it with content restrictions makes a lot of sense for a few reasons. The first reason is that it puts the onus on the websites to protect themselves. The other is that it doesn’t hurt any other usability, because it’s an opt-in situation. Pretty ideal, actually. While I was talking with Mozilla last week they asked me to put together a list of the top things I’d like to see in content restrictions. They are eager to get started on it, but can’t promise the world. They’d like to hear the top two ideas and then work from there.

How you instantiate content restrictions is still up for debate - whether it be a new header pointing to an XML file, or inline in meta tags or a new HTML tag. I’m a little indifferent, except that I think it should be accessible both to people writing dynamic pages, as well as people who simply include HTML placed there by whatever means (FTP, mail, etc…). So it should probably be a hybrid of a few of those, but that’s a different discussion.

So there are two use-cases. The first is that the site wants to simply remove anything potentially malicious, which could include something like JavaScript but exclude things like objects, for instance. The other is that a site might want anything dynamic, but doesn’t want anything embedded off-host to get injected into a page, or any automatic redirection of any sort.

One thing is certain - there are many site that don’t want any content to be placed outside of the user’s content. The beauty of an iframe is that CSS only affects what’s in the iframe, JavaScript can’t overwrite things outside of it, doesn’t have access to the cookies etc. The first thing I can think of that would be highly valuable to lots of sites if they were able to create a resizeable psueo iframe to restrict the content to a portion of the page, which would include styles (absolute positioning) as well as JavaScript access to the page.

Other possibilities include not creating a new DOM (no iframes, frames, or the like on the page between two places on the page). Another is no automatic redirection that is not user initiated. That’s a common problem because malicious users perform redirection to other domains.

A possible valuable tool for content restrictions would be to be able to limit what sort of functionality is between two sets of tags. The first example would be turning off any HTML tags that aren’t allowed to be rendered. The second would be to limit the event handlers to a pre-defined set (or removing them entirely). I’ve seen a number of situations where this would have been handy as a last resort.

Another thing I have been toying with quite a bit lately is the concept of XMLHTTPRequest. One thing that has always surprised me is that it allows more than it’s name implies. That is, if you request something that isn’t XML it still gives access to the page. It could be up to the page’s digression if XHR has access to anything other than XML. That would limit XHR to session riding, rather than being able to read nonces or other unsavory functions used in worms.

So I’d like to get people’s feedback. Those are some of my ideas, but I’m hoping people will have even better ideas as well. Once I get the top two ideas, I’ll submit those, and we’ll rank order the next several ideas and submit them as supplemental ideas for a later day.

I just can’t seem to avoid controversy lately. This time Billy Hoffman decided to take a stab at something I am still befuddled by. He claimed Jeremiah Grossman and I re-presented a paper from 7 years ago. Wow, I think someone must have missed our talk and/or failed to read the paper completely. We only mentioned timing attacks in passing and in totally different contexts. Further, I’ve never once claimed to come up with the concept of timing attacks. In fact, quite the opposite. If he had read my blog carefully he would have seen that I fully admitted I had first read about the concept of it in Hacking Web Applications Exposed 2. Then in Billy’s best showdown lingo I am given the ultimatum to put up or shut up. Eesh.

I’m really not even sure what Billy thinks we stole, because the one thing we talked about in regards to timing attacks was about measuring JavaScript error time to port scan intranets, which is a concept that is not once mentioned in the paper he cites. The paper is a really good one on other practical uses for timing attacks, however, it neither mentions intranets, nor does it mention port scanning. Not really the same application but similar techniques - you will get no disagreements from me there. I guess I could see why Billy could be confused. As a side note, as maluc pointed out this paper is where the concept of timing attacks originated and is far older than the paper Billy cites. Neither of which have much to do with our talk, but there you have it.

The only other thing I can think of that would confuse Billy is that we talk about our attacks as working with and without JavaScript. The paper Billy cites does mention a JavaScript-less version of an attack, but he was talking about using it to detect if you have been somewhere or not. Jeremiah and I have totally different (and far more accurate) ways to do that, which is actually what we discussed - we didn’t even touch on using timing attacks for that purpose because it’s so much less effective than the ways we have come up with over the last year and a half. Anyway, we didn’t claim to invent JavaScript-less attacks either. I know, I know, it’s crazy to think we came up with and built everything we said we did.

So just to cover my basis in the off chance someone can figure out a way I have trampled all over the intellectual rights of any of the aforementioned papers, I hereby cite Paul Kocher and Edward Felton for the concept of timing attacks, and Al Gore and ARPAnet for the concept of the Internet and every other concept my attacks have been based on over the years. Rest assured, unlike some people in this industry I never steal research, and if I do so inadvertantly, I own up to it and publically retract. I’ve done so dozens of times on my blog whenever I find out I am in error, whether I find my error on my own or when it is communicated to me, and that’s not about to change. And if I know that I am getting awfully close to copying someone else’s work, I always find a way to make it clear that that is what I’m doing. For the record I have no problem with SPI Dynamics - as I’ve been meeting more and more of them I’m getting to know and like them, Caleb, Michael and Jeff are all great guys. Even though we’ve had our bumps in regards to who originally came up with JS port scanning, which I am well beyond done arguing about, I actually like some of the stuff coming out of that camp. Anyway, this post probably isn’t interesting to anyone - unless you just happen to be trying to publically disparage our work… or something.

I’ve been absolutely buried since I got back. Let me try to race through the highlights. Firstly, if you haven’t seen Llana Grossman’s take on the con I suggest you do. It’s pretty funny actually. If you just want to jump to the pics, and avoid all the jibber jabber click here. So where to start?

id and I flew in on Tuesday, managed to find our way to our ghetto hotel (I do not recommend anyone stay at the Imperial Palace - although they do have a good Chinese place on the third floor). I ditched id who had to do work, and found my way over to Jeremiah’s room which vastly outclassed the Imperial Palace.

We all went down and got our badges, and managed to meet up with some Mozilla guys, some more WhiteHat guys and Robert E Lee from Outpost24 for dinner. Mozilla bought sushi for the table, as we talked about breaking the Internet. The speaker party was pretty fun, although I think a lot of people just wanted to bail to get a good night’s sleep. I know I did - we were second in the morning.

The talk went great - it was standing room only, and a few dozen people rushed the stage after it was over to ask questions. It was a really good audience actually. We showed how we could use a lot of the same old tricks we came up with a year ago without using JavaScript. I wanted to get an 0day up and running to explain why I could enumerate files on a Windows box without JS but I couldn’t get the demo working in time. Anyway, what I was able to show is how split VPN tunnels are dangerous. There’s a write-up on a potential (but fairly flawed) mitigation technique here. It’s flawed because it assumes you can block the things that bad guys are going to want to hack (like http://intranet/). To do so would break tons of functionality. But I encourage people to keep thinking about it.

There was another good thought that came out of it here, talking about safe cookies although cookies are only part of the problem. Kerberos, NTLM, basic and digest auth are all huge problems as well. Plus in many cases I don’t need any form of authentication whatsoever - that’s how my demo worked as a matter of fact. So good thought, but it’s a long way from getting us to where we need to be.

After it was over, id and I were having some interesting conversations about some of the other information leakage problems. I’d like to propose that we consider getting plugin manufacturers (noscript seems like a likely candidate) that have a concept of an intranet zone that prohibits referrers from being sent to Internet zones. Just a thought. It could also work in the browser, but I have a feeling it would break stuff.

I saw some good speeches - DNS pinning galore. I was actually pretty impressed by Billy Hoffman’s take on detecting DHTML malware. In talking with some hardcore AV guys, I think it’s kinda a lost cause, but it was a good take on a tough problem that not a lot of people have put much thought into.

As I’m sure you saw if you read my last post, we spent quite a bit of time talking with the Mozilla guys. They were much more interested in talking about Content Restrictions (if you’re unfamiliar with it, it’s basically a way to programmatically tell the browser not to trust your site - a concept I came up with 4 years ago and asked Mozilla to implement). They did, however, ask for me to come up with a few good things to implement. I’ll start another post on this in the next day or two when I collect my thoughts on the most valuable portions of that.

I hung out quite a bit with Dinis Cruz and a number of the other high level OWASP guys. I’ll probably end up doing a few OWASP talks and maybe a whitepaper or two with Dinis, but that’s gotta wait for some of the other stuff to settle down. The Microsoft party was a lot of fun - they got the entire top floor of Pure. I met a lot of interesting people and probably will be working on some interesting projects there. Btw, they also mentioned us on their security researcher thank you page for some of the vulns we’ve disclosed to them.

I also met Lance James (author of the anti-phishing book) for the first time. We’ve exchanged lots of emails and both belonged to APWG, but it was good to put a face to a name. Likewise with Portswigger (who built Burp Proxy) and I had a good long talk. Hopefully there is a lot more being built into the tool in a not too distant future. Rain Forrest Puppy and I chatted a bit about disclosure stuff. I think there may be more coming there in the not too distant future. Lots to be done!

Anyway, I came back with a fist-full of business cards, about 200 urgent emails, three new tricks, four new things to research and a ruined liver. All in all, it was a great time. More follow-ups to come.