One of the other barriers to a successful long lasting worm is how long will a vulnerability stay exploitable. Most worms take advantage of some known exploit, usually a buffer overflow. This technique limits a worm’s capability to fully wreak havoc due to the ease at which the hole can be patched. So in essence the successfulness of the worm becomes its own demise as the more machines it infects the more popular it becomes and the faster people patch the hole or vulnerability to avoid exploitation.
A good worm creator will realize that security companies will eventually identify some method of stopping the propagation of the worm by using some sort of signature or network-based anomaly detection. Therefore, worm creators are constantly researching and finding new ways to become more and more successful and destructive with their creations. This is where the battle between the worm creator and the security companies becomes interesting.
By taking a look at how Web application worms work, it is apparent that there are similar problems with widespread success as seen with traditional network worms, but to a lesser extent. For instance, the ability to identify targets becomes a much easier game. No longer do worms have to guess at which targets to hit. Web search engines create this list for them and even narrow it down to the most likely vulnerable victims. The most dangerous part of Web application worms is that most application-level issues are development errors within the application code and are not simply corrected by installing a patch. Take for example the common Web application vulnerability, SQL injection. SQL Injection is a technique for exploiting Web applications that use client-supplied data in SQL queries without stripping potentially harmful characters first. SQL injection requires a developer to cull through their entire application code base in order to manually fix each piece of code that is vulnerable. Depending on the size of your application, this could take months, years or may not even be feasible to appropriately correct in order to be secure. So the issue is no longer the patch roadblock, but a coding issue at the beginning of an application’s development. This can make a Web application worm very deadly.
Let’s take for an example what a possible SQL injection worm might look like. First step is to infect your starting host. This is accomplished by identifying where the host is vulnerable to SQL injection. Second step is to upload your worm payload, which may be done either via unprotected command execution API’s, or via your own stored procedure. Once your payload is running it will use the infected host to make requests to multiple search engines and identify more victims that are vulnerable to SQL injection. It will then upload itself to that victim and the process starts over. What will this accomplish? It all depends on the creator of the worm – it could be malicious and drop the entire database and cause a huge amount of chaos, or it could do something more drastic like dumping the entire database to your index page on the Web site or push it onto the gnutella network.