Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross-Site Scripting Worm Floods MySpace

Posted by Zonk on from the why-would-you-want-to-do-anything-on-myspace dept.

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."

27 of 321 comments (clear)

  1. XSS? by mindstrm · · Score: 5, Informative

    Is it really XSS if it's all happening at the same site? Just sayin.....

    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.

    1. Re:XSS? by Skye16 · · Score: 5, Informative

      No, they don't let you render JavaScript on the site. If you RTFA, he split the word "java script" into two lines, hid it in a CSS tag, and IE read it anyway. MySpace has stripped out tags for at least a year and a half.

    2. Re:XSS? by Skye16 · · Score: 2, Informative

      Goddammit, this is what I get for not previewing.

      "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"

    3. Re:XSS? by Haydn+Fenton · · Score: 4, Informative

      No, you can't upload Javascript to MySpace. That's the whole point.
      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'.

    4. Re:XSS? by arkanes · · Score: 2, Informative

      I suspect that IEs "dynamic CSS" JavaScript exrepssions, which can contain arbitrary JavaScript, are also a XSS vulnerability just waiting to happen. The ability to do this may have something to do with why script tags are parsed in stylesheets at all.

  2. More info... by TheSync · · Score: 5, Informative

    Here is a recent paper on XSS viruses. Also there is an analysis of the specific MySpace worm.

    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.

    1. Re:More info... by slavemowgli · · Score: 1, Informative

      Livejournal disallows Javascript (and even CSS) on their users' user info pages, but not in the actual journal entries.

      --
      quidquid latine dictum sit altum videtur.
    2. Re:More info... by ffrinch · · Score: 2, Informative

      That's not true. You can add JavaScript to entries, but it will never be displayed on the page. The HTML cleaner strips it out.

      Occasionally someone finds a new security hole, but they're patched pretty quickly.

    3. Re:More info... by MobyDisk · · Score: 2, Informative
      Your concepts are right, but I see two flaws in your execution:
      1) Write a rule that says "Passwords may contain only letters, numbers, and underscores."
      Rules like this are arbitrary and cause other problems. My passwords use more than just letters, numbers, and underscores. There are lots of other characters that are perfectly valid. If you are going to define what is good, define it universally, not arbitrarily. How about all non-control ASCII characters: 32-126? It is safe but also non-restrictive.

      2)For a simple, but very very real-world example, don't write a rule that says "If the password contains /, =, or \, reject it."
      There is nothing wrong with / = and \. If your code somewhere on the back-end treats those as escape characters then you have a security bug that needs to be fixed at that level. Limiting the user is not the solution because what if those characters make it in to your library through some other route?

      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.

  3. Here's the Guys Explanation of his code by putko · · Score: 5, Informative

    Here is his explanation -- it goes over the transformations he had to make to the program to smuggle it past Myspace's filters.

    And here 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.

    --
    http://www.thebricktestament.com/the_law/when_to_s tone_your_children/dt21_18a.html
  4. samy is my hero by gr8n10zt · · Score: 5, Informative

    The scoop from himself: http://fast.info/myspace/

  5. Interview with "Samy" by Bananatree3 · · Score: 2, Informative
    There is some guy's blog that has a personal interview with Samy, the writer of this "my hero" worm here ):

  6. samy is my hero by zippity8 · · Score: 4, Informative

    Turns out that he just used the fact that (not trying to start a flame war here) IE and some versions of Safari allow javascript tags within CSS.

    Samy's info on the topic (coral)
    His explanation of how it works

  7. XSS basics by flanker · · Score: 4, Informative

    Cross-site scripting is a family of vulnerabilities that share these attributes: a) a web-site that takes and displays text (e.g. Slashdot allows you to post comments) and b) a web browser that processes javascript in webpages.

    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.

    --
    Left shift 1 for e-mail...
  8. The Code by pturpin · · Score: 2, Informative

    Here is a link to the blog entry the article mentions that contains the code of the worm. (From Evan Martin of Google)

  9. Re:In the beginning by White+Shade · · Score: 2, Informative

    there ARE lots of chicks, yes, but they're all 15 years old! (claiming to be 99, and that they're "bi", and "married" to their favourite female friend from middle school, haha)

    myspace is certainly addictive though ;)

    --
    ìì!
  10. Re:AJAX vuns by erlenic · · Score: 2, Informative

    As others have pointed out elsewhere, it was an IE issue. MySpace apparently does filter out the word "javascript", but this guy was able to use a problem in IE to split the word across two lines, and put it inside some CSS code. For some reason, IE sees fit to execute code like that.

  11. Re:XMLHttpRequest by patio11 · · Score: 3, Informative

    What would encryping anything have accomplished, exactly? The problem isn't that someone intercepted a legitimate transfer in the middle and modified it to be evil. The problem is that one end of the legitimate transfer was compromised, and the other end of the legitimate transfer was too trusting of the input from the compromised end, and then happily passed along that input (perfectly legitimately) to other parties who were then compromised themselves.

    --
    Help poke pirates in the eyepatch, arr.
  12. Re:That's Irrevellant by TWX · · Score: 3, Informative

    And because of that, I still use Netscape 3.0 Gold on GUI machines, and I telnet to port 80 on console machines...

    ;)

    --
    Do not look into laser with remaining eye.
  13. the turd of myspace by 5n3ak3rp1mp · · Score: 1, Informative

    awhile back all my younger friends started bugging me to get a myspace profile. I took one look at the site, first thought was "crap design" (I'm a web/db dev), second thought was "superficial", closed window. I was just appalled at how bad it looked (despite still visiting Slashdot every day... hehe)

    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...

  14. Re:I find this amusing... by MrRogers2 · · Score: 3, Informative
    According to this article, XSS is a bit of a misnomer:
    The term cross site scripting is not a very accurate description of this class of vulnerability. In the words of XSS pioneer Marc Slemko:
    This issue isn't just about scripting, and there isn't necessarily anything cross site about it. So why the name? It was coined earlier on when the problem was less understood, and it stuck. Believe me, we have had more important things to do than think of a better name.
    Check out the full article for a good description of the types of XSS exploits.
    --
    MrRogers(2)
  15. Re:This is *not* XSS by Anonymous Coward · · Score: 2, Informative

    And now for the nit-picking minute...

    If you read the technical explanation 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...

  16. Developers just don't care by LlamaGui · · Score: 2, Informative

    About a year ago, I discovered a bug in xanga.com's software that would allow anyone to use any javascript they wanted. Xanga simply made 1 pass through to remove any tags... so all you had to do was write <script> and </script>. I created a proof of concept that would allow me to capture a user's cookies and send them to an offsite PHP script, totally transparent to the victim. You could then simply replace the victim's cookie with yours, and have total control of their account.

    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.

  17. LiveJournal Took up the Responsibility by BobPaul · · Score: 4, Informative

    LiveJournal's cleanhtml.pl already covers multiline splits in IE. It's not like IE's interpretation of single tags split on mutiple lines hasn't been known about for quite some time.

    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.

  18. Re:With myspace popularity, comes the problems by blake213 · · Score: 2, Informative

    Use these greasemonkey scripts to get rid of all that crap.

    --
    mund freud.
  19. How he did it by Sheepdot · · Score: 3, Informative

    From the horses's mouth:
    http://namb.la/popular/tech.html

  20. Re:AJAX vuns by dmh20002 · · Score: 2, 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.