#TwitterWorm Code Analysis – Cleaned-up Version

15:56 Update – Cleaned-up Version

About 1345 my friend Jon Katz tweeted:


From experience this was clearly something malicious; it looked like Twitter was enabling data to be passed as an argument to the shortened link, so that it would somehow be embedded into a webpage and acted-on as JavaScript code. In this case if you moused-over the above link it would fetch http://is.gd/fl9A7 – which the excellent is.gd people rapidly switched off:

This shortened URL has been disabled due to a violation of our terms & conditions. Most likely this link was being used maliciously or was used in spam. Please be careful when visiting links you receive from somebody you don’t know.


For reference and to help those fighting spam the original destination of this URL is given below (we strongly recommend you don’t visit it since it may damage your PC): – http://lexasoft.jino-net.ru/up1415.js

…but for a while which redirected the fetch to a server in Russia that provided yet more JavaScript code – which in this case would invoke the Twitter status-update-page and re-send the original tweet:


In short: it would propagate and tie-up resources, rather than killing your hard disk or similar.

This is/was a cross-site scripting bug. There is some analysis on http://blog.inspired.no/xss-vulnerability-on-twitter-com-760 that explained it propagated by people mousing-over ‘black squares’ of text – oversize font – on the main twitter web client page.

I ran Safari with JavaScript, Java and Plugins switched off; using this somewhat safer platform to go backwards through the twitter search history for “onmouseover” showed a variety of worms in the wild, including one by user @migueltarga who is getting everyone to retweet one particular tweet of his, and a second form of propagation:

Osmondmanurung: RT @migueltarga: www.t.co/@"onmouseover="document.getElementById('status').value='RT MiguelTarga';$('.status-update-form').submit();"class="modal-overlay"/

…and there were a bunch of people using the code to do “cute” JavaScript hacks, like opening alert boxes.

My suspicion was that if it wasn’t patched soon enough, the Worm would be combined with the #TwitterWorm hashtag and propagate through the hashtag most likely to be loaded by people seeking information. Graham Cluley posted a Youtube video demonstrating some of what the bug does on-screen.

Final analysis:

It’s a much simpler XSS bug than I originally feared, and it appears to have now been fixed; @moeffju pointed out the mistake I made in my original postings but also helpfully linked to a git repo which gave me the hint to how it actually worked.

What was happening was that the @$JAVASCRIPT.FOO in the URL being interpreted as a mistyped @USERNAME in the URL, so that the $JAVASCRIPT.FOO would get spliced (verbatim) into the HTML which appeared on the Twitter webpage; the resulting hyperlink was active for “onmouseover” and when activated would cause the fetch/execute (of the replication code). My fear was more of a two-way thing involving t.co; but fortunately not so.

Hopefully it’s all fixed now, except maybe for the stuff cached in RSS feeds and the like.

Makes rather a nice worked example for posterity.

5 Replies to “#TwitterWorm Code Analysis – Cleaned-up Version”

  1. Pingback: Anonymous

Leave a Reply

Your email address will not be published. Required fields are marked *