Skip to content

The Twitter XSS Worm and Lessons That Can Be Learned From It

In the last entry that I wrote here, I mentioned the XSS worm that affected Twitter. In this entry, I describe this worm in greater detail. In addition, I explain what can be done by end users so that they can avoid being victims of attacks such as these.

This worm infected the profiles of Twitter users so that they contained malicious code. Logged-in Twitter users who would view one of these infected profiles would then, through execution of the JavaScript injected into one of these profiles via an XSS hole, have their own profiles infected with the same code. Therefore, propagation of this worm occurred via logged-in Twitter users simply viewing infected profiles. The source code used by this worm can be viewed here. As one can see by viewing this source code that is called from infected Twitter pages, it injects the malicious script and other data that would appear in profiles when they are infected with this worm. Damon Cortesi gives a good analysis of the worm here.

A number of different variations of this worm have affected Twitter. The source code used by one such variation can be viewed here. As one may be able to determine by comparing this source code to the source code used by the original worm, a fairly straightforward code obfuscation technique was used to make it different from the source code used by the original worm. Another variation of the source code, which can be viewed here, is a modified yet non-obfuscated version of the source code used by the original worm. As Giorgio Maone said, it appeared as if those trying to correct this issue were trying to defend against specific code that has been used, rather than the type of attack. A few days after this was mentioned, Lynne Pope mentioned that with variations of the worm continuing to affect Twitter, the XSS hole there did not appear to be closed. It appears as if Twitter is not doing what needs to be done to prevent attacks like these. They seem to be targeting individual attacks rather than closing the hole that allows these attacks to get through. And when there is not enough done by websites to prevent attacks like these, users need to know what they must do to protect themselves.

There are some Twitter users who may not have been affected by this worm even after viewing infected pages on Twitter. Those who use the Firefox extension named NoScript may not have been affected by it. When looking through the source code used by the worm and variations of it, one can see that code that is on a remote site is executed in order to cause the worm to propagate. After seeing this, I thought that this could be considered a reason for using NoScript. And NoScript author Giorgio Maone took this opportunity to mention that because it is very highly unlikely that NoScript users would have allowed any scripts from the sites where any malicious JavaScript file was located, NoScript users may not have been affected by this worm. In addition, Lynne Pope gives an excellent and interesting list of suggestions on what users can do to prevent anything like this from happening to them. Not surprisingly, she suggests that NoScript be used. She also mentioned that when logged into one site, one should not be logged into another one. While this certainly would prevent CSRF attacks, this might be considered excessively inconvenient by some. She does give another criticism of Twitter, saying that they should have given users the information mentioned in her blog post.

I understand that much has already been said about this worm. However, the more that is said about this, the more likely it is that users will know what can be done to keep themselves from being victims of this type of attack. Also, according to this article, those who used Google to find information on this worm may have visited malicious websites in doing so. This information that I gave here may have been given later than I should have given it. However, I have always considered it important for entries on this blog to be as well-written as possible, at the expense of being up-to-date. If I wanted to write entries that were as up-to-date as possible, I would have a Twitter account. And I would be sure to use NoScript when using that Twitter account.