Luny has been on a bit of a rampage lately writing XSS worms against MMORPGs. This time he hit U-Dominion.com which is an online role playing game with over 100k users and over 50-100 users logged in at any one time. Luny released the code to me here if anyone is interested.

The age of the XSS worm is definitely upon us… Very soon the anti-virus/spyware crowd will have to start looking into this for ways to block it because consumers will demand it. There are lots of variants and since JavaScript is a full fledge language it is very easy to encrypt the data which would require hooks into the DOM. Has anyone heard of anyone actually attempting to stop XSS through browser plugins? I’ve heard of a few projects that attempt to do it, but nothing at the browser level, and nothing that I think had any legs. I’d love to talk to anyone doing this sort of research if they’re out there.

As anyone who has been following the site for any time will know I’ve been on both sides of vulnerability disclosure. Most of the time I think it’s a boring topic that was solved by Rain Forrest Puppy all those years ago with his RFPolicy. Since then, however, the nature of vulnerabilities have changed with the advent of heavily known XSS exploits. CSO magazine contacted me while they were in the process of a thorough writeup on XSS disclosure. Unlike software vulnerabilities of yesterday XSS provides a unique challenge for software researchers.

Generally I’m of the mentality that if it is easier to disclose it to the company in question (if I have personal contacts with them) I will do so, but generally speaking the simple act of disclosing is horribly complex and could get you into more trouble than not depending on how the interaction proceeds. That’s why when Scott from CSO magazine contacted me, I was happy to lay out the current battlefield. Companies have been notoriously difficult to get in contact with, they have not paid attention when their sites have been found to be vulnerable and then they can backlash even after responsible disclosure. Of course that doesn’t apply to all, but definitely to some, and why would a vulnerability researcher take the chance?

Granted, I have bills to pay and I’m not going to go to war for any individual researcher if someone with a badge asks me to tell them where I found information, and if I have a reason to protect a company, I’ll do so with the best of my abilities. But overall I am a consumer advocate attempting to find the balance between protecting the consumer and not completely screwing over the companies who have the issues. That’s why all my demonstrations are meant to be innocuous and non-malicious even to the user who views them. What malicious people do with that information later is out of my control, as it is out of my control if someone uses my paper on filter evasion of chat to send death threats.

What we are providing is a tool-set for the people who are interested in fixing these issues. We provide a communication path to allow companies and security researchers to communicate with one another. That communication will increase in the future, with some projects that are on the horizon, but for now, at least the sla.ckers.org forum is available for anyone to use. Feel free to ask questions of myself and other researchers. This is an emerging threat, so while no one knows how to completely solve all possible issues at this exact moment, we are getting closer and closer to that point every day. Eventually, with the help of the vulnerable enterprises, the vulnerable browser companies and the software developers that write vulnerable code, I am sure we will find all the solutions to these problems. That can only come with help from one another.

Hat tip to WhiteAcid for the new naming convention for the post (it’s easier to name it in terms of powers, rather than to type it out by hand). But yes, yet again, MySpace is vulnerable, and yes, again, to the exact same thing as before. This cat and mouse game makes them look pretty foolish. Instead of just doing it right they are writing single blacklist/whitelist strings that are trivial to circumvent. digi7al64 found yet another way around the same XSS filters that are attempting to stop the non-alpha non-digit XSS vector that effects FireFox. Here is the string:

<body <script onload<script=alert('xss');> turns into <body .. onload..=alert('xss');> which works in Firefox.

What did MySpace do against the last filter? They simply stopped stripping in the single case where they found the offending string. No, they didn’t get rid of it, block it, enumerate through a while loop or anything else, they just did nothing, causing the string to fail (not a particularly great defense there). This is silly, and embarrassing to watch. I feel bad for them, I really do. The only thing I can think that would cause them to not write a while loop is over concerns of CPU, but adding more and more filters doesn’t help CPU either, and there are other ways to solve CPU bound search issues (I know because I’ve designed them before).

It’s kind of comical at this point - anyone want to take bets on how many more tries it will take for them to get it right? This is the trap you get into when you have to allow HTML for your business to survive.

I personally though this was pretty ballsy, and it’s not just because Jeremiah is a friend of mine. WhiteHatSec is offering a trade-up program for other security scanners. The deal essentially allows for a $10k-$30k credit to try Sentinel over any of the other commercial web application security scanners that your company may be using. Like I said, pretty ballsy.

This comes after a paper describing why web application security scanners have a hard time detecting the OWASP top 10. If they can’t find the top 10 then where’s there value? This is a pretty interesting way to put your money where your mouth is if you ask me. It’ll be interesting to hear people’s side by side evaluations of the current solutions they have and Sentinel once they’ve tried both.

digi7al64 found yet another hole in myspace using non-alpha-non-digit exploit. Again, this time, like last time, MySpace is doing a bad job of stripping out tags. This is the fifth time they’ve been hit by this exact same issue. MySpace should really consider hiring someone who knows how to write while loops. Until then they are vulnerable yet again. The trick is again simple:

<body onload<script=alert('xss');> becomes: <body onload..=alert('xss');> because they strip out the <script tag without recursively iterating over the same string to ensure they haven’t created another vector.

Like Forrest Gump might have once said, “Blacklist stripping is like a box of chocolates - you know what you’re going to get.” You never know what the data is going to end up looking like until you’re done stripping it, which is why you need to recursively go over the text over and over until you have found nothing. This is a hard lesson to learn I guess. Nice job, digi7al64!

A few years back I had an interesting business model requiring me to talk to countries like Sealand. Sealand is the world’s smallest country and it’s now for sale. The reason why Sealand is important to the security world is that it is not just an oddity with airgap protection but it is also the world’s most secure data-center. With no physical access, ultra secure computers, and networks, it is by far the most secure commercial hosting environment on earth.

Anyone have a billion to spend? I have got some great business models. Unfortunately the island is probably more hassle than it’s worth. Being extremely poorly known except for the security community doesn’t help much. Also it is obviously under current and constant threat of being taken over by Britain, making it a risky proposition for any high net worth activities that you want off shore and out of the hands of extradition treaties. It’ll be interesting to hear the future of the island state.

The last two days were pretty exciting from a web application security perspective. It’s only been the first few days of the year and we have easily found one of the worst holes in it - and then proceeded to make it worse. The Adobe PDF reader XSS was more than just a simple flaw in a commonly used software. The hole was a chance to analyze our own reaction to the problem. There were a lot of false steps here, and I think we should look carefully at a lot of the mis-perceptions and kneejerk reactions.

The first and most common mis-perception was that the anchor tag was sent to the server. That caused a rash of comments like “I’ll just stop it with my web application firewall” or “I’ll block it with an apache rule” etc. That’s dangerous thinking. No one bothered to test to make sure that would work before telling others that that’s what they should do. The only people who were the word of caution were people who already knew that wouldn’t work. That alone scares me.

Next was the “you can detect badguys using mod_rewrite” people. Here are two sample rules:

SetEnvIf Request_URI “\.pdf$” requested_pdf=pdf
Header add Content-Disposition “Attachment” env=requested_pdf

and

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([-a-z0-9]+\.)?example\.com[NC]
RewriteRule .*\.(pdf)$ http://www.example.com/images/noexternal.gif [R,NC,L]

Be careful using either of those. REQUEST_URI can contain anything: http://example.com/file.pdf?whatever#vectorgoeshere For that example the request URI will be ..pathto..file.pdf?whatever which does not match “\.pdf$”. Likewise the second one has issues, including the fact that referrers are not always present (Zonelabs Zone Alarm Pro, and both Norton Internet Security and Norton Personal Firewall). Also, referrers are spoofable using Flash.

Next was the token crowd. This probably has the most legs in terms of being able to still allow the customer to retain the user experience of viewing the PDF doc on the website. However it has one fatal flaw. Here’s the algorithm:

IF the URL doesn’t contain token_query, then:
calculate X=encrypt_with_key(server_time, client_IP_address)
redirect to file.pdf?token_query=X
ELSE IF the URL contains token_query, and
decrypt(token_query).IP_address==client_IP_address and
decrypt(token_query).time>server_time-10sec
serve the PDF resource as an in-line resource
ELSE
serve the PDF resource as a “save to disk” resource via a proper choice of the Content-Type header (and/or an attachment, via Content-Disposition).

Now let’s ignore the potential issues with Content-disposition browser compatibility for a moment and think about the basic premise that this pseudo code is working on. It is making an assumption that an attacker will never have the same IP address as the user. That’s just not the case. This isn’t as rare as just a few universities and ISPs. This also happens in lots of corporate networks (rogue user on the internal network), it happens with lots of internet cafe’s, it happens with AOL (~5MM users) and it happens with TOR users. So while, yes, I agree it is better than nothing it is hardly a rock solid solution for anyone on a shared IP.

In the end, Adobe issued an alert and told everyone to upgrade (which everyone should always do, but as we all know they rarely will). Browser companies didn’t chime in at all, even though they could easily fix the issue. The network security folks changed the content type. The application guys told us how to stop PDFs from working in browsers. And at the end of the day, where has that left us? There are still a lot of exploitable browsers out there. Like I said, it has been an interesting last few days.

Michael Sutton has a good writeup on the Google blacklist that he released today. He sort of went over the obvious stats, who’s getting phished the most, where the phishers are hosting, etc… So for the most part it wasn’t that interesting to me personally (but I’ve been in this business for years). However, one thing did make me think. Michael mentioned that the lack of sophistication points towards the lack of need for sophistication.

Like any stats person would do, I had to think about what that really means. Is it that they don’t require sophistication or is it that they can’t achieve it. Who is building the phishing kits that they buy? Are these people the world’s best programmers? Are they going to build something that’s in vogue for a few days (a 0day browser exploit) only to have to re-code it a few days later when the patch roles?

Just like in any business the name of the game is scalability. You have to build a scalable product for as cheaply as possible. Just because x% people have anti-phishing in their browser doesn’t mean you don’t put it up. That’s like saying if you’re McDonalds you don’t want to stay in business because a certain slice of the population cares about early heart disease. Who cares? If it makes you money that’s all that’s important. Sophistication is not a current requirement for their business model. The scary thing is that with technology that is years old they are only now encountering tools that even put a dent in their business model.

That lack of sophistication in our own tools to detect and take down phishing sites is the real issue here. We (browser companies, AV companies, ISPs) have not created enough damage to their business to force them to adopt next generation tactics. So although they may have the arms necessary to fight a nuclear war, they don’t have to, because we’re still fighting with bows and arrows. They haven’t even scratched the surface of technical sophistication in their phishing attacks. And who could blame them? There’s no cost incentive to do so. We haven’t created that incentive yet.

I go to sleep for a few hours and I miss all the fun. Apparently Kyran wrote and turned on an XSS worm against Gaiaonline.com. In just 3-4 hours over 1500 people were infected with the benign virus. I chatted with Kyran about this, and although it used a persistent means to propagate it was really a reflective payload. One could argue it’s completely persistent, but it’s interesting none-the-less.

Here’s the source to Gaiaworm.

Clearly these types of worms are becoming more commonplace as the propagation methods become more widely understood. Unfortunately most of these worms happen to look a lot like AJAX, so it’s difficult to write signatures for them. I’m surprised the anti-virus/anti-malware community hasn’t tried to solve this one yet. This is really their domain of expertise - genetic propagation.

Okay, I spent exactly 5 minutes looking at my machine before I found a default file that is included with Adobe Acrobat Reader 7.0. It’s located at file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf and it is a valid location. Great. So let’s see if it’s vulnerable to the XSS DOM injection:

file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:alert("XSS");

Hmmm… It would appear that Adobe Acrobat has now created a local JavaScript issue for Firefox and Opera users. I’m sure there are other default locations for other versions of Adobe Acrobat. Very scary stuff.