While organizations rush to develop their security policies and implement even a basic security foundation, the professional hacker continues to find new ways to attack. Their attention has reverted to the application-layer, either shrink-wrapped or custom applications, which is commonly the least protected layer of an organization’s network. Industry experts estimate that three-fourths of the successful attacks targeting corporate networks are perpetrated via the application layer. Considering the nature of Web applications that allow access to internal and external audiences, this can pose serious risk to an organizations’ backend data without the organization even knowing.
Web applications by nature are not static. Content is continually being altered on a very frequent basis in order to keep up with the demand of new features and functionality. Even the simplest of changes could produce a vulnerability that may pose a major threat to corporate assets and confidential information, such as customers’ identity, if and when a Web application attack is launched. The list of Web application attacks used today is growing. From SQL Injection to Google hacking, organizations are learning the hard way of the ramifications from a Web application attack. This new generation of attacks has only begun and organizations are already behind in protecting their most precious assets.
Traditionally, many people viewed application-level exploits as a much harder and more targeted attack on their Web site. This was true a couple of years ago, but with the advent of using the power of search engines for malicious attack, hackers can now identify and exploit vulnerable applications with extreme ease. Now the threat of attack no longer requires your company to be focused target. Exploitation is as easy as turning up in a search result.
The Dawn of the Worm
Another form of attack becoming popular at the Web application-layer is the worm. Worms have traditionally been widely successful at the network layer of an organization’s infrastructure, targeting networks both personal and corporate. Worms focused on the network layer take advantage of existing network vulnerabilities such as a buffer overflows and un-patched systems. The network worm infects a vulnerable system then uses that system to identify other vulnerable targets to infect and propagate itself from one server to another. Traditional forms of Internet security have progressed, such as intrusion detection and protection systems (IDS and IPS), to help in discovering this popular form of malicious attack before any damage is incurred. Web application worms, however, are targeting the layer of organizations that is the least secure and are not protected by these traditional forms of Internet security. These nasty forms of attack utilize known exploits, apply worm methodology and then leverage the power of search engines to find vulnerable Web applications to accelerate effectiveness.
Worm Methodologies and Challenges
One of the keys to a successful worm is the ability to identify the next victim. Many worms apply different tactics in order to do this type of search and seizure. Traditionally these tactics have been patterns such as randomly picking IP addresses, or picking up an IP range of a victim and incrementally scanning that range. Some worms even take advantage of the data on the server. They grab e-mail or HTML documents on the infected host and scan thru these in order to find more potential targets to infect. The ability to find the next target is an art and the methods of doing so are amazingly clever.
Worms have been facing some key challenges since the first one emerged on the Internet scene mainly with efficient and effective methods of exploiting exponential numbers of hosts. In order for the worm to be successful it must spread as quickly and to as many different hosts as possible. Having a worm spin its wheels re-infecting a host that has been infected does nothing to get the worm towards its ultimate goal, so worm creators must come up with different methods in order to ensure a worm is not re-infecting the same host over and over again.
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.
As the Internet community is learning, Web application worms are not solely theoretical. In fact, the Santy worm and its variants emerged around the beginning of 2005. This worm used the popular search engine Google to find Web sites running phpBB and then used a known exploit in the Web application to propagate itself. However, luckily the worm, which was a first of its kind, did not cause too much damage because it had some fundamental problems. 1. The worm had a re-infection issue. Since it used Google to find vulnerable hosts, it used the same search query for each victim, which always returned the same search results so it could never really propagate to a lot of hosts. 2. It was dependent on Google for its victim list and used a very static query to retrieve the search result. Google was notified and thus corrected the issue so the search query that was used was then denied. Still with these very obvious defects in the nature of the worm, Santy still infected over 10,000 Web sites, defacing each of them.
Tackling the Potential Infestation of Web Application Worms
The solution to Web application worms and worms in general is to fix the problem that the worm uses to propagate. Application firewalls and assessment tools can be a good start, but the real solution is to get the individuals who create software to consider security as a fundamental building block in developing software. Developers who design and build business-enabling applications generally are not security experts and therefore do not know how to avoid creating defects that are so easily exploited by hackers. These applications tend to be pushed into production with little or no security testing. Just as with the network layer, companies must now view the application-layer as a potentially open portal to corporate assets and therefore need to implement the necessary security procedures across the application lifecycle to ensure that critical assets are secure from such new attacks as application worms. With more than one million new Web applications being launched each month and successful hacker attacks in the news each week; application security should no longer be an afterthought for any organization looking to remain viable.