Cross-Site Scripting Worm Floods MySpace 321
DJ_Vegas writes "One clever MySpace user looking to expand his buddy list recently figured out how to force others to become his friend, and ended up creating the first self-propagating cross-site scripting (XSS) worm. In less than 24 hours, 'Samy' had amassed over 1 million friends on the popular online community. According to BetaNews, the worm's code utilized XMLHTTPRequest - a JavaScript object used in AJAX Web applications and was spreading at a rate of 1,000 users every few seconds before MySpace shut down its site. Thankfully, the script was written for fun and didn't try to take advantage of unpatched security holes in IE to create a massive MySpace botnet."
XSS? (Score:5, Informative)
XMLHTTP has a same-site policy... the problem here is they let users render html & javascript in their own pages on the site. If slashdot allowed executable javascript in the comments, we'd have the same problem.
Re:XSS? (Score:5, Informative)
Re:XSS? (Score:3, Informative)
"he split the word 'JavaScript' into two lines", and "MySpace has stripped out JavaScript and <script> tags for at least a year and a half"
More info... (Score:5, Informative)
Evidently LiveJournal and other sites take care to scrub out JavaScript in user-provided web pages, but the rumors are that sometimes people do figure out how to obfuscate their HTML enough to deliver the payload, despite the scrubbers.
Here's the Guys Explanation of his code (Score:5, Informative)
And here [namb.la] is his version of the story.
He comes off as a sweet practical joker. But maybe that's just b.s. that he cooked up after he realized he might have some 'splainin' to do.
Also, his site really is "namb.la" -- he's making some sort of joke at NAMBDLA's expense, which is pretty suspect, I think.
samy is my hero (Score:5, Informative)
Interview with "Samy" (Score:3, Informative)
samy is my hero (Score:5, Informative)
Samy's info on the topic (coral) [nyud.net]
His explanation of how it works [namb.la]
Re:More info... (Score:2, Informative)
XSS basics (Score:5, Informative)
The exploit involves placing javascript code into your posting on a website, such that when other people visit the website their browsers download your comment with the embedded javascript, which is then processed. The javascript, because it is being processed on your machine as part of the rendering of the page, can be used to exploit all sorts of vulnerabilities within browsers. When you have browsers tightly coupled with operating systems, this can open up some rather scary scenarios.
In this case, the guy just used the vulnerability to make some relatively benign changes, but he could have just as easily exploited some of the many problems with IE to be more malicious.
The Code (Score:2, Informative)
Re:In the beginning (Score:3, Informative)
myspace is certainly addictive though
Re:AJAX vuns (Score:3, Informative)
Re:XMLHttpRequest (Score:4, Informative)
Re:XSS? (Score:5, Informative)
From what I gather, you can upload CSS tags and other non-harmful tags. However, 'Samy' managed to find out that instead of writing valid CSS code inside the CSS tag, you can simply write a Script tag (so long as you split it over two lines) and upload it that way.
This in itself shouldn't be a problem; since the code is inside a CSS tag it should be parsed as invalid CSS code, and so there's no reason for MySpace to have blocked it.
This is where IE comes into it, if you are using IE, IE will parse it as a valid Javascript tag anyway, and execute the code.
This isn't really a bug in MySpace (well, technically it is now), it's more like a bug in IE which can be exploited on MySpace, or any other site which allows similar tags in which code can be 'hidden'.
Re:That's Irrevellant (Score:4, Informative)
Re:XSS? (Score:3, Informative)
the turd of myspace (Score:2, Informative)
All I can surmise is that the person who designed this worm is far more clever than any of the people who designed MySpace.
I still don't have a profile on it...
Re:I find this amusing... (Score:3, Informative)
The term cross site scripting is not a very accurate description of this class of vulnerability. In the words of XSS pioneer Marc Slemko: Check out the full article for a good description of the types of XSS exploits.
Re:This is *not* XSS (Score:2, Informative)
And now for the nit-picking minute...
If you read the technical explanation [namb.la] of the worm, you will see (item 8) that he had to add an extra redirection go from profile.myspace.com to www.myspace.com.
The cross-site part is not the main part of the worm. But still...
Developers just don't care (Score:2, Informative)
So I took my discovery and emailed it to their designated bug report address. 5 months later it was finally fixed. I've found other vunerabilities that would allow anyone to do the same thing, but I don't even want to bother writing a proof of concept and telling them about it. Most companies just don't see XSS as a danger until someone wreaks some havoc.
Re:More info... (Score:2, Informative)
Occasionally someone finds a new security hole, but they're patched pretty quickly.
LiveJournal Took up the Responsibility (Score:5, Informative)
I completely agree that IE is the problem, but to say that this is something site administrators couldn't have been prepared for is untrue. To expect a self replicating javascript? No way. But to secure the filter to prevent multiline tags? Yes, cleanhtml.pl already does. It's known and out there already.
Re:With myspace popularity, comes the problems (Score:2, Informative)
Re:More info... (Score:3, Informative)
If you are referring to the Unicode escape strings like \u000A then you are not following another rule, which I'll add to your list as rule #3:
1. Defining "badness" instead of "goodness"
2. Trying to "clean up" invalid code
3. Not using the appropriate parser
If someone enters in \u000A and then your code should either treat that as the 6 character sequence that it is, at which point there is no problem; or it should treat it as a newline character which will be rejected. Either way you are fine. It is only a problem if you treat it one way in one part of the code, and another way in another part of the code. That's why you use the proper parser. If the user entered ASCII and you wanted UNICODE then the UNICODE parser will see that as a newline and you will reject it. If they entered ASCII and you wanted ASCII then that sequence does nothing and you are fine. If your filtering routine treats it as ASCII then you later make it UNICODE and pass it to a SQL server then the user may have snuck something in. Really, if you use the appropriate parser than characters never need to be filtered. Suppose a malicious tries a SQL injection by entering in a \ or an unmatched quote or a newline character, then I don't need to be afraid so long as I used the SQL engine's prepare() command to parse the string. It knows how to escape the strings properly. So there is no need to filter anything.
How he did it (Score:4, Informative)
http://namb.la/popular/tech.html [namb.la]
Re:AJAX vuns (Score:3, Informative)
XmlHttpRequest breaks the ingrained UI idiom of 'nothing happens until I click something'. Ajax (specifically XmlHttpRequest) has some scary implications for phishing. From a post on JoelOnSoftware discussion list by 'JD'
For example, when someone clicks a link in an email that is out phishing for an SSN and personal info, you could be half-way through the form, and think - wait, I don't want to do this. BUT, with XmlHttpRequest, your information that you've only typed into the form has already been nabbed and sent to someone overseas - and you didn't see ANYTHING happen.