A good friend of mine, nickg, contacted me about this MySpace XSS worm he ran into. It seems like he caught it right as it propagated, and we were able to dissect its functionality. I posted a bit about it on the OSVDB blog comments (http://www.osvdb.org/blog/?p=51). Thus far, we know several things:

1) This specific attack starts with an embedded .swf Flash file.2) The flash file uses ActionScript to send a simple GET request to an UNSANITIZED (whew, embarrassing on MySpace's part) variable by the name of TheName.3) the GET request in #2, then loads a remote .js script.4) the remote .js script then uses XML http send commands to execute the malicious part of the worm -- changing first, last, and display names with "g0dOfTheN00se" and injects the malicious .swf file into several parts of the profile, including television.

To execute the XSS attack directly:http://myspace.com/PROFILE/COMMENTS.CFM?FriendID=6221&getComments.recordcount=1&TotalComments=1&MyUserID=6221&TheName=XSS

The author also added a little note to users infected by the XSS worm:"MySpace Aids Is Back Bitch. Merry Christmas From ..!.g0dOfTheNoose.!.. ."

Here is a bit of what the malicious remote .js (JavaScript) file looks like. Its name is "SamyReloaded.js":

The vulnerability itself is in the unsanitized variable "TheName", which should end up embarrassing developers at MySpace, especially after that whole Samy fiasco. They shut down the MySpace site to fix unsanitized variable issues, and I guess passed right along on that one?

As for the usage of a malicious Flash file in the XSS worms propagation was actually a very interesting spreading idea. Since Flash, and other objects are embeddable and accepted on MySpace profiles -- I guess the developers at MySpace did not think about ActionScript being used as an attack vector.

That file allows for Cross-Domain data-loading, which is discussed here

If MySpace had allowed only domains in their own domain space, this XSS worm would have had a tougher time propagating via the malicious .swf flash files. That does not negate the fact that the XSS vulnerability exists!

UPDATE: Sebastian pointed out to me a Flash decompiler which actually allowed me to see the sort of code used in the malicious .swf file. And no surprise that the .swf file contained literally two lines of code! (I assumed so, since the file was so small; 247+ bytes). Here is a look at the decompiled code:

We see that the author goes as simple as possible, by using the GetURL() function; a simple request to initiate the attack.

Here you see the attack itself, directly to the "TheName" variable. It's amazing how simple that attack was, and how successful it _could_ have been. It's propagation really became unsuccessful simply because it relied heavily on that remote .js file, and all the free hosts the author used to upload the .js file were quickly removing the accounts.

This public blog will be a place for me to output any Security findings, both technological and physical, that I have come about. I will post Security advisories I was apart of, and also other interesting bits of knowledge.
email: xavier [at] tigerteam.se