Okay, here’s the deal. I have decided it’s time for all of us to get into the spirit. So this is the first annual hacker pumpkin carving contest for all the ha.ckers out there. And without being a hypocrite, I’ve kicked it off by doing the first pumpkin myself. I’ve given all of you 2 weeks notice, so I don’t want to hear any bitching that you didn’t have enough time. No whining. Log off from world of warcraft and go to the store.

Now it’s your turn. Submit your best pumpkins on or before Halloween (Midnight GMT October 31st, 2006) and I’ll throw it up on the website. I’ll make a decision on which is best (no I don’t vote for myself unless I’m the only one who posts his pumpkin). This isn’t a democracy - my vote is the only one that matters, so aim to impress! Here are the rules:

There are none. Okay, well that’s not really true. It should involve a pumpkin. I’ll be extra impressed by craftsmanship and l33t haX0rship. Bonus points for 0-day pumpkins, or pumpkins involved in hacking “incidents.” Be creative. I can be bribed.

I’ll post the winner sometime after Halloween depending on my general mood and level of hung-over-ness. If you want to chat about it, do so on the forums. Email me your pumpkin pictures (640×480 or less preferrably so I don’t have to use The Gimp on them). I can be reached at h@ckers.org. Good luck!

I don’t think this will come as much of a surprise to anyone, but it appears MySpace accounts are easily phished. This probably wouldn’t be so bad except that people put everything about their lifes into social networking sites and there are tons of minors on it and it is owned by an evil advertizing company and it was founded by people who build data mining software (okay, I’m not sure how those last two play a part in this but I still don’t like it).

Also people tend to use their password on more than one site and most of the people listed use their email addresses as usernames and email addresses are one of the primary functions for forgot password in websites. Shall I go on? Okay, so maybe this is a big deal.

Here’s the link to the list of compromised users. Of course a good chunk of them aren’t valid because they are phished accounts, but you get the point. I’m not sure what means were used to compromise them, but clearly it was some amount of social engineering to give these types of results, but even still, MySpace is feeling like a scary place to be right now.

This is almost too ridiculous to post, but there’s a point to it, I promise. There is a pretty funky issue that VMWare has on their site where they basically show the username and password to their drupal install. It’s just so sloppy I barely even want to mention it, except (again) there’s a point here that goes beyond VMWare’s configuration oversight.

Well if you look at the above picture you’ll notice something interesting in their featured partners. Something… not right:

Click to enlarge.

Digging through the source we find the originating code:

Click to enlarge.

Ouch… the server is either mis-configured to render .php extentions as PHP or the PHP include is not ended well. Oops. Now the drupal site password is disclosed. “Okay, boring problem, why are you even talking about it, RSnake?” Here’s why… one of my major problems with database driven web applications is that the password is almost always embedded within the code. At any point, if there is a breech in either the way the code is rendered or if there is something where the server gives up information about the source of the page, the site can be compromised. There’s one saving grace here - the fact it’s an internal database (localhost). But my point remains. Keep your passwords out of the web accessable directory whenever possible.

Jeremiah released a really interesting survey he did today on some broad web application security questions he asked of some security professionals. Now I feel bad that I didn’t answer it myself when he sent it to me, but I would have skewed the results in almost the same way everyone else did so maybe it’s not that bad. From a security perspective it’s really interesting seeing what other professionals think about certain things. Maybe the sample size is slightly too small to be exact, but really there aren’t that many true web application security professionals out there, so maybe this IS the statistic.

The most interesting statistic that I found was the percentage of people who use web application security scanners for their penetration testing. 71% of the users polled said “never”. Ouch! That smacks of some serious issues with either functionality or perception of the scanners out there. What are the reasons why though? Why is it so difficult to test for web application security issues from an automation perspective?

The obvious answer is because there are just so many tests to be performed and there isn’t enough intelligence built into the scanners that even when they happen accross an issue they can’t reasonably tell what the issue is or what it means. They can only tell you which bucket it falls into and move on. That’s just not enough. Maybe it tells you where to start looking for some of the obvious low hanging fruit, but does it make a serious enough dent in over all vulnerability assessment to consider yourself secure? Well it stands to reason that the experts would say no based on the results Jeremiah came back with today. Interesting.

Dave Ferguson today released a series of rather nasty CSRF attacks against Netflix. CSRF is nasty. It can do anything any command that you can perform allows you to do but without your knowledge. If you can do something it can do it on your behalf. From a web application security perspective it’s just about the closest thing to completely owning an user account without actually having to penetrate the system or even know the user’s password. Here are some of the examples of vulnerabilities in Netflix:

- add movies to your rental queue
- add a movie to the top of your rental queue
- change the name and address on your account
- change the email address and password on your account (i.e., take over your account)
- cancel your account (Unconfirmed/Conjectured)

Pretty scary! Even if you couldn’t change the password by changing the email address you can use the forgot password function on most applications to forgo knowing the actual password. Who cares what the password is anyway (unless you are doing password research). Most of the time the attacker just wants access to the account in question.

David used a quote I’ve heard Jeremiah say a number of times, “CSRF is a sleeping giant.” I guess my comment to that statement is that it feels like the giant is coming out of hibernation as more dynamic applications are built and more malicious people understand the value of attacking online accounts. It’s already happening, even if only in the very smallest quantities. Time to start building secure applications so we can put the giant back to bed. More on this in the future…

It occured to me today as I looked over the referrer spam in my logs that it is particularly ineffective these days. For those of you who aren’t webmasters or don’t look at your logs very often, referrer spam is when spiders connect to your website and send a fake HTTP_REFERER (sic) header that incorrectly tells you that someone is linking to you. Most of the time it’s pretty ineffective, however, with Jeremiah’s CSS history hack, it might be far more useful.

It stands to reason if I’m an administrator of a website I’ve probably been to the homepage at some point in my last browser session. Of course I can turn that off the cross domain leakage with Safe History but no one uses that so the attack is pretty effective. If you know there is a single choke point (like a login page) that the administrator must use that’s even better, as they will have to use it to view their logs.

By verifying that the person looking at the logs is the person viewing the site in the logs the spammer can be sure that the webmaster views their logs and does something with them that may be effective in generating traffic. This is similar to how email spammers put tracking links on their email to watch open rates against particular emails (that’s why you should never auto-render images and you should never use the preview pane as that opens them automatically). Anyway, new attacks using this old hack are always interesting to me.

Well it was interesting to see that on a recent article by Help-Net Security they report that Cross Site Scripting was the number one security issue that plagues Web 2.0 technologies. This is a pretty interesting take one one fairly major issue - not that XSS is or isn’t bad but how AJAX increases the attack surface.

To quote the article:

In the last few months, several cross-site scripting attacks have been observed, where malicious JavaScript code from a particular Web site gets executed on the victim’s browser thereby compromising information. A recent example is the Yamanner worm that exploited cross-site scripting opportunities in Yahoo mail’s AJAX call. Another recent example is the Samy worm that exploited MySpace.com’s cross-site scripting flaw. AJAX gets executed on the client-side by allowing an incorrectly written script to be exploited by an attacker. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it.

I think the only difference between AJAX applications and normal web applications from an XSS perspective is that I’ve seen more examples where application developers attempt to do the escaping at the client level rather than at the server level. That creates several attack points instead of just one. Instead of just having to encode the output at the server level now it muddies the water.

Muddying the waters might not sound like a big deal but XSS is a terribly complex issue. It’s hard enough to keep the server output from executing HTML (and just because it appears hidden doesn’t actually mean it is hidden if I send the user there directly). Now you have to worry about it in two places or more. In the case of the JSON issue in Google that I found they had three or four places (once at the server and a few places in the JavaScript code) that required different types of filtering for the different applications. Ugly!

Think about other places where muddying the water has become an issue - Firefox plugins and PHP plugins. Need I say more? Since they are different developers with different skillsets they will no doubt miss the security aspects. Since it’s two developers instead of one (as JavaScript and the server side code are most likely different languages) you’re twice as likely to have security holes.

So while I don’t think AJAX adds any additional attack vectors it definitely does increase the attack surface area and the potential for exploitation. Further attacks against web 2.0 technologies will be released in the future as browser technology evolves but for now things are about the same as they have been for traditional web applications. Muddying the water is bad, trust me.

6 hours of grueling testing later, I’ve completed updating the XSS Cheat Sheet with Internet Explorer 7.0. The findings were actually different than I thought they would be going into it. On the surface it looks like IE7.0 is dramatically better than IE6.0 and indeed, if you look at how many tests it passed compared to IE6.0 it is. However, a large chunk of the cross site scripting vectors on the cheat sheet use the JavaScript directive, which has been turned off in a lot more places than just inside images.

One thing I have not gone through is the list of event handlers - one step at a time. Of course any differences between my list and what is supported will evade lots of blacklists looking for particular strings (rather than a whitelist approach). I’ll list the changes here when I get to that point. For the differences it’s probably just worth looking at the cheat sheet for yourself and scanning the list if you are concerned about any particular vectors.

Eventually I’ll have to update the cheat sheet again as some of the principles are still valid, even if the vectors as written are no longer functional (like the grave accent and half open vectors for instance). IE7.0 appears to be quite an improvement in overall security though. I’m glad the JavaScript directive has been relegated to IFRAMEs and HREFs rather than being possible anywhere a location was - thereby definitely reducing the attack surface for the newest browser from Microsoft.

In a twist of a pharming attack Google has been targeted for typo domain squatters who built a look-alike website that also happened to install a trojan horse. Great! Typically pharming is where you take over a DNS or install malware to point somoene to an alternate domain. This, however, is another take on the same old attack we have grown to know and love.

The part that I think is interesting in this is not the attack they used - it’s old and boring. What would be interesting is to combine the attack used against Google and building a fake search engine based on where the user was previously. This attack simply requires that you have your code on whatever site is going to get the traffic. That means that you can XSS a page and if you see the referring URL come from a Google domain you can hijack the traffic when the page unloads.

The problem that Google currently faces with typo domain squatters can mostly be handled by better fraud detection by the domain registrars. What I’m discussing with building a fake search engine is not solvable. Google has bigger issues with people building fake websites and then getting Google to host their ads through Adsense on Google itself. Forget taking over a domain, it’s just not required if people think that whatever domains Google is hosting on it’s ad section is safe - a poor assumption at best.

Yup, it’s true, the first of my tests are coming back relatively positive for the newest release candidate for Microsoft’s Internet Explorer. IE7.0 RC1 has fixed a number of variable width encoding issues. Previously in IE6.0 both US-ASCII and UTF-8 encoding methods had variable width encoding issues in them, however, as of my tests today, both are now safe. It definitely closes down one of the most obscure attack vectors out there for two encoding methods, but never fear there are still more out there.

The encoding methods that have not been fixed so far (that I can tell using my fuzzer) are BIG5, EUC-JP, EUC-KR, GB2312 and SHIFT_JIS. Of course this is not necessarily a complete list, but it’s the best we’ve got so far with the research I’ve put in (non-security related day job getting in the way of good security research and development again).

Also, I should point out that IE7.0 did not fix the US-ASCII encoding issues that Kurt Hewig found. So it was definitely a good start for IE7.0 but it didn’t finish strong for the variable width encoding cross site scripting vectors. I could imagine that while discussing this the development folks probably figured that if someone were programming for those language sets they should know about this and take it into account on the server side. But I haven’t lost hope yet, there are still lots of vectors left to test.