creating an xss worm
xss worms are pretty neat, interactive worms that propagate by using a client's browser to progressively infect other profiles in some way. i wrote my own worm a while back, and i wanted to talk about how it worked, how it was affective, and what challenges i faced.


the worm i created was in justin.tv. the best thing about xss worms is that they're as unique as the xss. tons of different things may occur, and it's up to many different variables that the worm is successful.


the xss in justin.tv was found by x2fusion. x2fusion and i worked on the worm right when we came up with the idea of making one.


the xss was in the location field. so, people viewing another user's profile would run whatever we put there, as it was not sanitized. but there was one more challenge: the location was placed in the title sanitized. we had to find a way to not only hide the worm in the title, but we also had to impliment some javascript that automatically changed the title as soon as it loaded.


once we started on the worm, we made the .js file on an external website, and before script inclusion we put several html comment tags to hide it in the title. in the location javascript, we edited the location javascript (local) to dynamically remove the title, keeping it stealthy (as possible) to avoid other issues. the local javascript also made a hidden, blank iframe that we could reference in the remove javascript.


to start off, the remote javascript would force the iframe to our website and provide, dynamically, the client's cookies and profile location. we would use this to track what profiles were infected by who, and when, and all of the client details at the time.


we would create the payload inside the remote javascript that we can use to inject with the viewing user's profile. the "payload" data is pretty much our local javascript. we also added a ^ (rare location element, if you ask me) character after the user's location, which our local javascript will use to manage the dynamic script.


what we didn't think about, well... we were in a hurry so it's not our fault, ^ would remain on the titles. people would definately notice, but it wasn't patched until about 24 hours after.


we printed a new iframe (hidden), and used it to read out the details in convinient little sub-frame form elements. we took the elements and processed them, only changing the location field if it wasn't already infected, and then sending the request (if it wasn't already infected).


this was more complicated as it seemed... we had to fight between ie and firefox (safari follows firefox for the most part) compatibility. after doing that, we realized... if the infected person was... well an actual broadcaster, the default page wasn't what we were looking for. thus, we needed to dynamically read whether certain elements were given on the page, and also go to the correctly named page.


we had another request upon new infections that saved user details.


once the request was sent, by then it is assumed the profile was infected and we have it recorded on our side. in-fact, quickly after we released it, i made a quick little php script that waited for more accounts to be infected (and their userdetails), and printed out a highlighted table element had it fade out after 5 seconds. after about 1500 profiles, i sat there watching 4 to 10 be infected a second, and it was funny to watch them be infected life.