I was doing some writing about the Samy worm last night in the XSS book and after doing some looking into the growth pattern of the worm (which I don’t think anyone has bothered to do) I was able to come up with a rough estimation of the acceleration of growth. Thanks to Samy for diligently writing down times and numbers. Granted those times and numbers are probably rough estimates, and the last entry, which is probably the most important to calculating this was not entered (bummer). Only “a few minutes” was marked for that last entry, so it’s difficult to say what it would have looked like. I put four minutes as less than 5 and greater than three for the worst case since no one really knows.

Click to enlarge

The are a few interesting points to note here. Firstly is not just that it had a super slow growth but that the point at which it became explosive in growth was somewhere just north of 8000 users who were infected. Further, if you look at the last two bullets (granted the last one is a guess) it appears that there is still an increase in acceleration of growth. That means that while the Samy worm was bad, it was no where near as bad as it could have been if it had been allowed to spread naturally. That insane growth scale is pretty unheard of, so it’s an interesting thing to see written out in this way.

unsticky sent over a nice snippet of code that helps identify if the user is using IE (of which there are dozens of ways to perform this task) and then, more importantly it can help you identify what is their default browser, if it’s not Internet Explorer using mimeType. A working proof of concept code is here. It works well detecting Firefox and Opera.

There does appear to be at least one false positive when using Netscape. If you are using Netscape in IE mode it will think you are using IE and will still report if that is not your default browser. However, I believe this code would also think your default browser is Firefox if you set it to Netscape since Netscape tends to use the Gecko rendering engine as it’s default (I haven’t tried, but that’s my theory). Anyway, cool snippet of code. Thanks, to unsticky for finding it!

There’s a really interesting thread on sla.ckers.org talking about bypassing some fairly rigid anti-XSS vectors that allow nothing that looks like HTML. Specifically it doesn’t allow <[A-Za-z] which does limit the vectors pretty substantially. In the process of working through the attack vector Hong mentioned that an attack could surface inside of an end HTML tag. Here’s the example code:

</a style="xx:expression(alert('xss'))">

It gets around the filter because there is no letter immediately following the open angle bracket, it is a forward slash. I’m not exactly sure why any end attribute should be allowed to have style information associated with it, since that doesn’t really make sense contextually. This doesn’t appear to work in Firefox or Opera, but it does work in Internet Explorer, which makes up a vast majority of the browsing community. I wanted to wait until the exploit actually worked before posting it, as it was a very interesting way to bypass filters that probably wouldn’t have worked in any other way (with the possible exception of injecting nulls). Nice find, Hong!

Kishor sent me a link to a recent post he wrote as a follow up to my previous post about how forgetting global replace can cause XSS. What he talks about is how doing something as simple as turning HTML into it’s equivalent entities can cause command injection. This is yet another reason why modifying content is a dangerous proposition.

Kishor notes that changing < into &lt; and injected within a string xyx<ls -l will turn into xyx&lt;ls -l which still renders. Obviously I’m not a fan of taking any user input and piping it through a system call but if you have to do it make sure to dump the script through a while loop to ensure that it’s not doing anything you don’t want it to. Something that’s okay for web content isn’t necessarily okay for SQL or commands or any other use. Just make sure you know what you’re doing with the text and don’t just blindly use it.

One of the most common things I hear people say when they are writing perl programs is to remember to use the taint flag. I’ve always been one of those guys who knows enough not to leave strings un-cleansed and I never really saw the value in it. Firstly, it doesn’t tell you if something is vulnerable or not, it simply tells you that you are using it before making sure it’s clean. That in of itself may be of some use to some people, but I think it gives you a false sense of hope in a lot of ways. For instance, let’s take this snippet of code:

$var =~ s/"/&quot;/;
$var =~ s/</&lt;/;
$var =~ s/>/&gt;/;

That would seem, at first blush to stop three characters (the open and close angle brackets and the double quote) from appearing in $var. Alas, it is missing one obvious thing that would have protected it. It is missing the “g” at the end of each of the pattern matches that would have globally changed the string. It’s a silly thing to forget, given that it’s clearly designed to stop XSS. And what is it vulnerable to? Let’s look at how it is outputted:

print '<INPUT TYPE="TEXT" value="', $var, '">';

So what it is vulnerable to is double the strings:

"">><<script>alert("XSS")</script>

Turns into:

<INPUT TYPE="TEXT" value="&quot;"&gt;>&lt;<script>alert("XSS")</script>">

Pretty silly vector but it works like a charm. But who would be stupid enough to mess up something this simple? Yup, you guessed it, me! That’s what I get for using old scripts written in 1995, written long before XSS was really understood and before I knew much about programming. Thank you to zeroknock for finding the issue and letting me know. See? Everyone makes mistakes!

Ferruh emailed me today about a new SQL Injection Cheat Sheet that he has built (similar in concept to the XSS Cheat Sheet) meant to be a learning tool for those who are unfamiliar with SQL Injection. It’s really good as it has a lot of explanations that go well beyond anything else I’ve seen. Click here for the SQL injection cheat sheet. To be fair, I know of at least two other SQL injection cheat sheets out there. First was my feeble attempt that I never followed through with (I’m too embarrassed to give out the URL any more than I already have since it sucks so bad) and Jungsonn’s SQL injection cheat sheet.

I’ve always like the concept of Cheat Sheets - the at a glance tools that help people understand a lot more about a topic or use as a reference. I was never one for lectures in school, I liked the hands on learning, and in fact, when I read books I almost always skim over the words and my eyes land on the code samples. So this kind of thing is really nice if you want to just see the code and read the supporting text once you get interested.

As a side note there is a big section of the forums devoted to SQL injection that I hope people will use to discuss the topic, as there is certainly more work to be done in this area. I encourage anyone new to the field to check it out, and anyone who’s an expert to lend their skills to any questions that arise. We’ve had good conversations but the more people understand the issue the better.

Trev has a good writeup about some obvious holes in Firefox plugins. I’ve long said that the biggest holes you will find in Firefox will be in the plugins themselves, not in the browser. I consider browser rulesets to be sorta the equivalent of killing an ant with a club. You can be pretty sure you’ve taken care of the issue if you turn off scripting in the browser, but that is not the case with tools like noscript. As Trev points out once you start making exceptions that’s where things start going awry quickly. To quote myself:

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.

Trev himself told me that he’s been thinking about this a long time as well, outside of the context of my arguments. The sheer complexity of a stand alone web-browser is startling (in a big way this entire website is at least in part devoted to it) but it makes matters exponentially worse when you start adding new and untested technologies on top of the systems. Not that I think either Adblockplus or noscript are bad plugins, but both suffer from that exclusion list issue which really can make things far more complex from a security perspective. Diversity in browser functionality is a good thing for security, but from an actual vulnerability standpoint it’s a scary thought given how many holes we’ve found in these sorts of applications.

As a side note, I’ve been wanting to turn Adblockplus into an application firewall for a long time (over the less functional alternatives). I hope something as mature as adblockplus can be converted into something like this, because it’s got a great chance of at least partially mitigating a lot of problems that have been all but unsolvable to date.

I know this sort of attack has been around for a while, but perhaps not quite in this way and not quite as many servers were affected, but there is a report over at SANS talking about an XSS VBScript malware that injects malware. Ben Heinkel alerted me to it and actually put up two screenshots here and here showing how the code actually worked. Pretty nasty stuff, especially as it appears there is no virus definition for this particular variant yet.

However, there are two things about this that are more interesting from an attack perspective. The first is that this was not calling malware that was uploaded to the site that had been compromised. Why bother? Since the sites themselves had XSS holes on them (I’m assuming persistent) the only requirement was that the executable and VBScript was housed somewhere on the Internet. No longer do you have to upload your malware to the machine you want to infect people from. Who needs all that hassle when all you really want to do is link to it?

The second thing that’s interesting is that this uses VBScript. Firefox users might be cheering since they wouldn’t be vulnerable to this without a plugin, but really it’s a pretty interesting thing that it is easier to write Malware that installs executables in VBScript than JavaScript. Although JavaScript is still the favorite for port scanning and controlling the page it was VBScript used in the attack. I think people tend to forget about VBScript, but it’s potentially just as nasty considering the wide userbase that supports it.

beNi and I have been talking a lot about some issues within Gmail where too much information is disclosed by AJAX and JSON. Alas, it has finally been proven to allow for information disclosure. The example he built is based off a tiny XSS hole (that requires user interaction) but any XSS hole will do, this is only a proof of concept. Click here to see his post on the topic.

This is the second time Google has had this issue (the first was found by Jeremiah Grossman over a year ago). It’s not a good idea to have sensitive information stored like this, but really, once you find XSS on a system it’s almost irrelevant. But from this point forward your contact list will be vulnerable every time an XSS exploit is found (of which there are probably hundreds on the site at the moment). Not to mention the other terrible things you can do to Google consumers once you have XSS on Google. Nice find, beNi!

Ever heard of cyber bullying? I hadn’t either until yesterday. I guess it’s all over the news, but I don’t read that kind of stuff. I’m sure I saw a headline titled “cyber bully” and I immediately closed the window. But I guess it is a very real problem that has actually resulted in suicides. Hardly the kind of thing you normally think of when you are thinking of web applications but there you have it - the web can kill you. So apparently there is a new reputation service called GORB that takes this principle and tries to capitalize on other people’s misery. Unlike most reputation services it doesn’t bother verifying if the results are real or not (not sure how they deal with libel suits, but I’m sure it will happen sooner or later). I had to do everything in my power NOT to post this about the founder, Leonard Boord:

Meh, never liked the guy. He acts so proud of himself over this stupid business, he pretty much pisses off all his employees with the five finger discount with the corporate coffers and furthermore I don’t like the way he treats his significant other. If she were my sister I don’t know what I’d do - it wouldn’t be pretty, but Tijuana call girls are no substitute for love. Anyway, it’s not my place to say, I’ve just never gotten along with him. I just hope he gets clean soon, that stuff will kill you.

Alas, I didn’t post it, despite my incredible urge to mess with the system. But I’m sure there will be a number of people with less willpower who create havoc for otherwise innocent people. I wonder how long it will take for something like this to get shut down. Ultimately, it represents similar issue as don’t date him girl that allows people to post anonymously and obviously disparaging things about people on the Internet without their knowing. Think of the Internet as the new place to air your dirty laundry, even if it’s not really true. Fun stuff.