Paid Advertising
web application security lab

MySpace 0day Again^6

This is just painful to write this. Again today, digi7al64 found another non-alpha-non-digit XSS hole in MySpace. This is number 6, folks. SIX times MySpace has failed to fix this issue. I will admit, they did make it harder, from what I can tell, as of yesterday a lot more filters were put in place that appeared to fix the issue, but alas, they still haven’t taken the single point of advice that will set them free… use a while loop! Maybe I should clarify, I don’t mean use it sometimes, I mean use it whenever you strip. And even then I don’t recommend stripping at all, but if you have to you absolutely must use a while loop.

I’m not even going to bother trying to write out digi7al64’s XSS vector, you can click the link above to see it yourself, but the jist is that they strip out xsrc=… in certain contexts, and then don’t iterate over the text again to insure that the data they stripped didn’t cause another vector to surface. If it isn’t clear to anyone yet, here’s the basic idea of this issue. Let’s say the word “TED” is bad. We hate TED today. Now, let’s say I put the word TETEDD. The text looks like this TE[stripped]D after stripping, which then re-creates the word we were trying to stop in the first place.

MySpace continues to have this problem over and over because they don’t loop over the text to try to find the same strings they were initially trying to block again. If they did they would find the malicious string and strip it again (then iterate again and so on). Painful.

11 Responses to “MySpace 0day Again^6”

  1. MySpace 0day Again^6 of Myspace Html Codes Blog Says:

    […] Original post by RSnake for Myspace News MySpace 0day Again^6 […]

  2. maluc Says:

    one point of contention as devil’s advocate.. if they started a while loop, someone could attempt to bring them to their knees with a worm. Basically by having a payload that repeatedly opens iframes to the Profile Preview page that they POST too with tons and tons of loops necessary to filter the info..

    Now, that all depends on how much at capacity their servers tend to run.. and i don’t think akamai’s servers will help them much in that as i think they only store the static content for customers (or do they do dynamic too?)

    I don’t run tests on what kind of CPU usage that’s looking at, by changing anything in a program/script/algorithm from a worst case of O(1) constant time to anything else should be considered carefully.

  3. Gavin Says:

    Small note.
    your example leads to TE[striped]ED not TE[striped]D

  4. MikeA Says:

    When will people learn! If you have “bad” input, dont even try to fix it - just error out. *any* kind of error correction causes all sorts of issues, it’s just not worth the risk.

    Will someone send MySpace the wikipedia entry on Whitelists vs Blacklists :)

  5. RSnake Says:

    Thanks, Gavin, fixed!

  6. RSnake Says:

    Maluc, that may be true that you can incur some amount of extra processing overhead, but realistically it’s pretty minor unless you do it a lot of times. Looping over a 500k text block 100 times takes only a few seconds at worst. And if I were MySpace I wouldn’t filter anyway. Once you find something potentially malicious you should bounce the text back and tell them to fix it. If you see malicious text over and over again upon stripping it’s probably safe to assume it’s okay to reject it outright.

  7. chlog.net » Nochmal Myspace.com Says:

    […] Hier gibts den ganzen Artikel: LINK […]

  8. maluc Says:

    Indeed.. the point being that a few seconds at worst, times a million people in a worm, divided by the number of servers myspace has for profile.myspace.com - can probably be enough to DoS their servers.

    Rejecting outright would likely be the way to go then.. but it’s probably less user friendly. The cost-benefit is something they’ll have to decide.

  9. RSnake Says:

    Yes, but you could write something like this:

    $flag = 0;
    while (malicious_string_is_found()) {
      if ($flag == 0) {
        $flag = 1;
      } else {
        outright_reject_content();
        exit;
      }
    }

    So that after finding two strings that are malicious it outright rejects the content. If the user has that much wrong with their page (which would never happen other than with malicious users) it’s probably okay to incur the loss in usability.

  10. ChrisP Says:

    It’s computationally feasible - using http://en.wikipedia.org/wiki/Aho-Corasick_algorithm for instance. I guess the issue is for the MySpace admins to know before hand all possible malicious patterns to weed out, and so far it looks it’s the hackers who are up ahead in that game.

  11. RSnake Says:

    I’m more familiar with Boyor Moore but yes. Anything that uses a word graph can be iterated over. Stripping can be ultra efficient, if you understand what you are doing.

Respond here or Discuss On the Forums