Well, it turns out I am speaking at Blackhat after all - plus I have an OWASP preso to do tomorrow. That makes five presos in 6 days. Shoot me now. Anyway, I was playing around with Firefox today and accidentally found a super tiny DoS for Firefox that reminded me of my childhood. Remember that math puzzle where you put one penny on one square and then two on the next and four on the next and so on? Clearly that would amount to more money than you could realistically have when you really think through it, but kids have a hard time wrapping their heads around it. This is sort of similar, except it’s not geometric, it’s linear, which was surprising that it caused Firefox so much pain. I had just assumed the JS engine in Firefox would have said that it’s running too tight of a loop and throw the “running too slow” prompt at worst - or just finish at best since it doesn’t look all that complicated:

var a;
for(i=0;i<65536;i++){
document.write(a+=String.fromCharCode(i));
}

I let this run for 10 minutes on a decent sized test machine and it never finished - I had to kill the process. Yeah, I know there are a million ways to DoS browsers, this one was just surprising because I honestly didn’t think it could. Anyway, if I don’t post before then, see you in Vegas!

For my upcoming speech at DefCon on Friday of next week I was testing a server that happens to not be open on a port that you’d expect it to be. That same server also uses load balancing via DNS so it has a ton of different IP space that it points to. So I wanted to check to see if that port was open on any of the servers that were connected to it. I used wget to do this. It looked something like this:

$ wget –server-response –timeout=3 https://somesite.com/
–2009-07-21 13:58:32– https://somesite.com/
Resolving somesite.com… 1.1.1.1, 2.2.2.2, 3.3.3.3, …
Connecting to somesite.com|1.1.1.1|:443… failed: Connection timed out.
Connecting to somesite.com|2.2.2.2|:443… failed: Connection timed out.
Connecting to somesite.com|3.3.3.3|:443… failed: Connection timed out.
Connecting to somesite.com|4.4.4.4|:443… failed: Connection timed out.
Connecting to somesite.com|5.5.5.5|:443… failed: Connection timed out.
Connecting to somesite.com|6.6.6.6|:443… failed: Connection timed out.
Connecting to somesite.com|7.7.7.7|:443… failed: Connection timed out.
Connecting to somesite.com|8.8.8.8|:443… failed: Connection timed out.
Connecting to somesite.com|9.9.9.9|:443… failed: Connection timed out.
Connecting to somesite.com|10.10.10.10.|:443… failed: Connection timed out.
Connecting to somesite.com|11.11.11.11|:443… failed: Connection timed out.
Retrying.

…

So you can see that if it can’t find the first IP address in your list of IPs that you provide in the DNS it’ll try the second, if that’s also unreachable then it’ll try the third and so on. This means that if you can detect that someone is using wget on you you can essentially rebind their IP address to something else, assuming you have the other IP address that you want to rebind them to listed. So you can rebind them to Google or something and have them spin forever trying to download the Internet or something else just as dumb. Or you can point them to their own internal IPs…

That means that there is a second and much more weak attack there as well. Let’s say I had a list of DNS entries like 1.1.1.1, 192.168.0.1, 1.1.1.1, 192.168.1.1, 1.1.1.1, 10.0.0.1, 1.1.1.1, …. where it alternated back and forth between my domain (1.1.1.1) and internal RFC1918 address space. If it fails the first one it’ll try the second. If there’s a closed port there, it’ll miss that one and try the third (my IP again) and so on. I don’t have an open port but that doesn’t mean I can’t see the SYN packet coming in. In this way you can create a very weak intranet port scan, that will stop scanning as soon as it hits the very first successful IP address internally. So it’s almost useless as an attack. But still - really? Why does wget of all things need to be vulnerable? What’s next? Heap spraying in lynx?!

Update: One more speech added for Blackhat - turns out I am speaking there after all!

DefCon is fast approaching and I have a bunch of speeches to prep for (and this doesn’t include the other non-DefCon speeches on my roster). Thankfully I’m mostly done with my prep work, but there’s never enough time is there? If you happen to be at DefCon and want to hear me speak, here are the speeches and times:

1) Wednesday at 4:45 - Unmasking You! - I’ll be co-presenting with Josh Abraham about a bunch of anti-privacy 0day as well as a major privacy leak built into a huge percentage of browsers.

2) Friday at 2PM - DefCon Security Jam (AKA Fail speech) - I’ll be speaking about a really dumb/funny browser Fail.

3) Saturday at 3PM - Hijacking Web 2.0 Sites with SSLstrip - I’ll be co-presenting with Sam Bowne regarding Slowloris.

4) Sunday at 12PM - Unmasking You - repeat of the Blackhat talk.

So yeah, I’ll be very busy while I’m there. Feel free to drop by and say hi at some point if you happen to be at the conference. I’ll be checking Twitter periodically while I’m there too if you want to message me directly. If you know about any good industry parties please message me too. You can never have too many invites!

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.

Going down memory lane I decided to go back and look at Microsoft’s Active Agent. For those of you who aren’t familiar with this, “Clippy” might sound more familiar. Clippy actually came much later. It all started with a little bird named “Peedy” the parrot. Peedy could read text, fly around, dance, look bored, and all kinds of stuff. It was scriptable, could be instantiated through a web-page and worked well in browsers that had the agent pre-installed (which was pretty much no one).

A few companies decided to try to create business models based on it - trying to read people’s emails for them, and other similar things. All doomed to failure and internet obscurity, although all very cool in their own way. Alas, as I was going and looking back at some old links I found this:

Microsoft has decided to discontinue development of Microsoft Agent technologies. Beginning with Windows® 7, Microsoft Agent will not be included or supported in future versions of the Microsoft Windows operating system. We encourage Microsoft Agent application developers and redistributors to evaluate their activities in light of this decision.

*sigh* Even though it never took off, Peedy will always have a place in my heart. Like that time we called up Bronc’s girlfriend and read off some ransom note we had crafted using Robby the robot’s text to speech. We laughed and laughed - until she called Bronc’s cell phone. You should have seen his face, “Hi honey. Yeah, we were just screwing around.” Man, that still cracks me up and yes he was in trouble. Yeah, we were dumb kids, but boy, Peedy and the gang will be missed! Farewell…

Every once in a while I have those discussions with id about “what I would do if I were the NSA and had no mission to accomplish.” It could also be called the overgrown “boys with toys” conversation. It typically goes off on tangents where we abuse system resources for entirely impractical applications, and this is no different. Today we started talking about the PS3 collisions stuff. Cool indeed. But what if we wanted to use something entirely unrelated to find something that’s barely worth knowing? Ahh, that’s where gigantic rainbow tables comes into play.

Every hashing algorithm has possible collisions once you allow a certain number of chars to be hashed. Let’s say you found out that “bob” and “sam” collided in whatever hashing algorithm. If you created an account on a web server with the password of “bob” and then later typed in the password of “sam” assuming no salts you would be able to get into the system. That’s not all that interesting because you could get into your own account anyway. The vaguely more interesting fact is that you now know what hashing algorithm is being used. Rinse and repeat for every salt (random set of chars preceding, after, or XOR’d typically), every password rule variant (must have upper case, or must have special chars, etc…) and every hashing algorithm (MD5, SHA1, SHA256, double hashed because people think they’re being super clever, etc…) and you have an extremely overkill way to get a very small amount of information disclosure. Yes, what a waste of taxpayer money!

The slightly less impractical implication of this is if you already had some collisions that you could use for this purpose you could attempt certain types of brute force against passwords that matched on the backend but were in fact different passwords when applied to a blacklist of typed passwords. Also, you could use these kinds of tricks for other sorts of database collisions where a primary key is a hash of some known data. What a complete waste of resources that are best used for far more interesting tasks, if you ask me. But hey - it’s possible.

Yeah, I know, I’m very late to the rush of installing the way over-hyped and extremely poorly named, Chrome browser. For those who aren’t in the know, it’s sort of like naming a car “Engine”. Ignorant person says, “I’ve got an Engine.” Smart person says, “I know, I have an Engine too. Everyone who has a car does.” Ignorant person says, “Really? I thought they just came out.” Smart person says, “Wait, are you talking about the car, Engine.” Ignorant person says, “Yes, of course I am.” So people who actually know what chrome is have to deal with ignorant people that think we’re talking about Google’s attempt at installing more crap on people’s desktop and confusingly misinterpret when guys like us are talking about chrome versus Chrome. Gah!

Anyway, despite that idiocy which I am sure will haunt me for many many years to come, I was going through looking at some old functionality that I haven’t toyed with in a while and I noticed something odd almost immediately. Google Chrome appears to allow JavaScript to fire despite the fact that you are viewing source through the view-source: directive. Click here for an example (only works in Chrome with JavaScript enabled). This doesn’t work in IE, Firefox, Safari, or Opera - yup, it’s a Chrome only problem. Why is this a problem? Because some security people use view-source: to neuter the danger of pages that they think are potentially malicious - so that they can safely view the page without any JavaScript firing - alas, so much for that idea - at least in Chrome.

I’ve been toying around a little with DNS rebinding code lately, with some mixed results. Firstly, Java fixed their DNS rebinding issues (although it is my opinion they are still vulnerable, just in a different way - I talked with Dan Kaminsky about this and he agrees. Also CUPS fixed their DNS rebinding issues as well. All good things. However, there’s still tons of exploits left to find in this arena.

Anyway, I went hunting for some good sample DNS rebinding server code, and I couldn’t find anything that was remotely good or easy to work with in a test environment. So I whipped up some sample code quickly for anyone interested in doing their own research. You can download the code here. Of course you’ll need some JavaScript/Java/Flash/etc… code to make the browser call the server twice, and you’ll need something to shut the port down after the initial call is made to force the browser to make the second DNS request, but I thought it was better to leave that part as an experiment for the user, since that code will probably vary a lot depending on the server environment.

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!