How To Write AJAX Worms - Theoretical Point Of View
Over the last year the world has experienced some quite disturbing facts about the so called WEB 2.0. It is all fragile! MySpace was pretty much the most targeted platform among phishers, scammers, spammers and virus writer, but there were also Google, Yahoo and Youtube who had similar issues.
In this article I am going to introduce you to some of the key concepts behind a new generation of AJAX worms that could quite successfully span across the entire WEB. This article may seem unrealistic to some of you but keep in mind that none has thought that AJAX can be used for destructive purposes either. I hope that by knowing about the coming thread we can successfully invent proper countermeasures.
AJAX worms, a.k.a. WEB worms, has one particular characteristic that makes them different from all other types of worms: they move only when you interact with them. This peculiarity is due to the fact that AJAX worms are not standalone processes. They are sub-processes and they last as long as the resource they run on is opened by the user. As such, users and AJAX worms seam to be part of a massive turn based RPG (Role-Playing Game): the user makes a move, usually by attending a resource or clicking on a link, and the worm turns by starting another propagation-infection cycle. If you understand this fundamental characteristic you should be able to grasp the bigger picture.
AJAX worms are also a lot faster then normal worms. Simply put, the more users the exploited platform has, the faster the worm will propagate. The propagation process is also dependent on how well the currently infected resource is linked to other resources. This guarantees faster propagation. No wander why MySpace is the most targeted platform by AJAX worm writers. Because its complexity, enormous size and well linked resources, it makes perfect environment for worms and viruses to spread, mutate and of course destruct.
AJAX worms are quite similar in nature to Macro worms. Everybody has herd of "Melissa" or "I LOVE YOU" (a.k.a "LOVE LETTER") worms. They affected Microsoft Office users. Their propagation process starts when the users opens attached word document to an intriguing email. Upon opening, the document executes VBA script which mass mails itself to everyone in the current user's contact list. The process repeats when one of the contact list members opens the malicious attachment.
How Macro worms are similar to AJAX worms? First of all, Macro worms act when the user acts. Second, they propagate by using a network. In this case the network is build upon email contacts. The difference is that while Macro viruses affect email accounts, classic AJAX worms affect user profiles. Are there other systems that provide similar environment? Surely there are! In fact the entire WEB is such a system.
WEB 2.0 and Sir Tim Bernars Lee's Semantic WEB are all about connectivity. Both of them promote enhanced user interaction, content aggregation and machine learning. Both of them are suitable for worm attacks due to these characteristics. Because the Semantic WEB is nowhere close to reality, let's concentrate on what is more important today, WEB 2.0.
I started this article by saying that it is a big miss-conception to believe that AJAX worms affect one domain only. The technology and the nature of the WEB we know it today allows far more dangerous and agile code to be build. Let's theoretically design a proof of concept worm that spreads across the WEB in order to shed more light into this matter.
I am big Fan of blogging software. I like the power they provide but also I am aware of their weaknesses. The hypothetical AJAX worm that we are going to build together is going to spread on the top of the blogsphere. The Blogsphere is distributed social network of blogs and provides a perfect environment for worm propagation and malicious code infection.
The first most important rule worms cultivate in their logic is that malicious code needs to run without the current user permissions (run automatically). That's why some kind of security hole is required. The WEB is affected primarily by injection vulnerabilities such as, XSS, CSRF and SQL Injection. Although there are other types, these are the most commonly found today. The worm writer must implement any one of them.
The second most important rule worms cultivate in their logic is that propagation algorithm is required to assure future generations. The propagation mechanism is important for the worm existence.
The third and final rule worms may cultivate in their logic is that mutation and upgradability prove to be good partners to fight against anti-virus software (if there are any). That is optional.
The propagation process of a our hypothetical Blogsphere worm could start with a comment or trackback send to the first targeted blog. The reason for using comments and trackbacks for attacking blogs is because they are types of input that are freely available to anyone. If the commenting or trackbacking mechanism is vulnerable to XSS, then the situation is a lot simpler. The XSS vector will be persistent in that case. The worm can infect all posts that are served from this blog. This type of vulnerability is rare though, and it is because of its criticality. XSS of non-persistent nature could be found but in order to use its full potential the worms needs to trick the administrator of the targeted blog into attending a resource that has been infected already. That is easy. When administrators moderate comments and trackbacks they are logged in. If they are intrigued by the comment, they may also click on the author link, or the link that is supplied inside the comment for more information or even the trackback link.
If the administrator happens to be logged into the blog the worm is attacking, the malicious JavaScript will be granted access from the current browser to the targeted domain. That in tern will launch the infection process which will attach malicious JavaScript code all over the place, by either individually modifying each post or by modifying the blog template. The latter is better.
CSRF is also good technique that AJAX worms can use. Again the administrator needs to be authenticated in order for the code to gain access to the blog internals. CSRF attacks cannot execute JavaScript on the targeted domain, but they are able to modify data and as such inject malicious code. This code will be activated the next time the administrator visits the infected page.
SQL Injection is powerful. Together with CSRF, worms might be able to achieve a lot. If the SQL Injection issues appears inside the administrative panel, again an authenticated administrator is required to be tricked into attending an already infected resource. With CSRF the worm might be able to inject SQL queries and as such modify the database. If the database could be tampered then the posts' text and comments could also be enhanced with malicious JavaScript code. If the SQL Injection is external the process is a lot easier. CSRF is required but not the presence of an authenticated administrator.
Keep in mind that this is patient zero. Once a post or the blog template is infected with the worm body, it is time for the second stage - propagation. It is easy to propagate on the top of the blogsphere. The chances of authenticated administrator or member of the current blog to access an infected resource are very high. When this happens, the worm checks for the most recent trackbacks that are currently available inside the administrative area and sends a comment or a trackback to each of them on behalf of the current user. The comment may contain persistent XSS. Both comments and trackbacks can contain a link to the current blog that will launch non-persistent XSS, CSRF or SQL Injection (+CSRF) on the targeted domain. When the targeted administrator attends the malicious resource (the currently infected blog), the worm propagation cycle completes and the infection stage is triggered. The process repeats.
I know that this may sound a bit complicated and confusing but in practice it is very easy to do. I also mentioned that in order to make a worm successful the worm writer needs to implement features for upgrading and extending the worm code base. Unfortunately, this is quite easy to do with WEB technologies, as well. If the worm writer wants to upgrade the current worm, he/she may start another worm of the same nature but with the upgrade payload. Once the old worm reaches a resource that contains an upgrade payload, it will automatically upgrade itself and enhance its functionalities. The worm writer can manually upgrade the worm as well by leaving clues around the WEB. Once these clues are reached, they become part of the worm code and they lead the future generations.
I said that the worm is directly dependent on the type of vulnerability that is going to be exploited. Any of the above mentioned (XSS, CSRF, SQL Injection) will work so I strongly suggest to patch on a regular basis. Fighting this type of a menace is not easy. In fact, I really don't know what needs to be done in order to protect yourself. If a blogsphere worm has access to your administrative panel, it certainly has access to you database and maybe your local file system and as such it may modify them to ensure its existence. In order to remove the worm from the database for example, you need special type of tools that may not be that easy to find or build. In this case upgrading you blogging software may not even work.
P.S. At the time of writing this article I came across several Cross-site scripting vulnerabilities in Blogspot/Blogger, Youtube, MySpace, Wordpress and several other popular WEB 2.0 platforms.
Archived Comments
Chris Korhonen
