Impacta Blog

No doubt you may have already heard about the worm that hit the Twitter service over the weekend that affected 10,000+ tweets as reported on Twitter’s blog. According to the Puget Sound Business Journal, 17-year-old Michael “Mikeyy” Mooney from StalkDaily admitted to originating the attack.  

How could something like have been prevented? More important, how could you prevent something like this from happening to you? From what I can tell, the attack is based on what’s known as a cross-site scripting (XSS) vulnerability. Cross-site scripting vulnerabilities happen to be the most common Web-based vulnerability and relies on the fact that Web-sites and services (like Twitter) read data from un-trusted sources and then embed that data in Web responses. If that untrusted contains malicious script then any user’s Web browser reading the Web reponse containing the malicious script will be affected, or in Twitter’s case infected.

One way to visualize cross-site scripting attacks is say someone gave you (let’s say your name is Bob) a package and asked you to store that package and give it to the next person who comes to your door.  Inside the package is a bomb (unbeknown to you), and so when someone new comes to your door and you give them that package. That new person will think “Hey I trust Bob, I’ll go ahead and open the package” and … boom! From the perspective of the victim, you were the one who attacked them, and not that unsavory character who asked you to store the package in the first place!  This is how a variant of cross-site scripting called persistent cross-site scripting works, and I suspect what happened to Twitter.

To remediate cross-site scripting vulnerabilities you’ll need to encode any potentially any untrusted data prior to embedding it in Web responses. To easily encode data you can use the Microsoft Anti-Cross Site Scripting Library which while at Microsoft I helped release v1.0 (deprecated) and v1.5. The current version of that library is up to v3.0 beta right now. I haven’t played around with v3.0, but the idea behind encoding remains the same: encoding takes ‘potentially executable data’ and transforms it into ‘non-executable data’. Or if we go back to our exploding package example, encoding has the effect of defusing the bomb before giving it to someone. 

So to prevent something like what happened to Twitter from happening to you, follow this rule: if you read data from an un-trusted source (such as users, other services, etc.) and embed that data in Web responses, encode it first.  Here’s a tutorial I wrote on using the Microsoft Anti-Cross Site Scripting library that will help.

Good luck, and if you have any questions on preventing cross-site scripting vulnerabilities feel free to drop an email to info@impactalabs.com.

–Kevin

BTW: I don’t profess or wish to tell anyone what to do (or in this case what not to do), but why on earth would you want to claim credit for this worm? The days of hacking a major site/company/application, claiming credit for it and instantly landing a nice cushy job are long gone. Michael Mooney probably had good intentions at heart, but he will be lucky if he gets away without having serious charges pressed against him.