2001 was without any doubt the year of vulnerabilities.
CERT, the leading security information source (www.cert.org), documented an increase of 240 percent for reported vulnerabilities and incidents in 2001. The reality is that existing web servers such as IIS and Apache (to a lesser extent) can be easily penetrated, especially if they are not patched and configured properly. Web application programs, which run on top of the web servers, were found to be vulnerable as well. In the last year several vulnerabilities were found in known CGI programs, PHP, JRUN and other web application development tools. Firewalls, that are supposed to protect against external threats, don't deal with these vulnerabilities since they cannot distinguish between malicious and non-malicious HTTP requests.
At the same time, malicious code developers have further improved their worm technology, making their engines more powerful and destructive, and demonstrating their effectiveness on multiple occasions, including Code Red and Nimda. The combination of new vulnerabilities and advanced worm technology makes the threat of Internet worms significant and requires an immediate solution. In the following article, we introduce Internet worms, talk about the threat, provide some predictions of future developments, and identify the key features an effective protection system should offer to deal with this threat.
The term "worm" is used in different contexts for different types of malicious code. This article concentrates on Internet worms. These have the following characteristics:
- They exploit a vulnerability to break into the system.
- They do not require manual intervention.
- They spread automatically through the network.
What makes the worms so powerful is automation. Unlike a trojan or a virus where the user needs to perform a manual action for the virus to spread (such as executing the trojan), in the case of a worm, the whole process is automatic. The worm, by itself, exploits the vulnerability in an attempt to run its malicious code on the attacked computer. The first malicious code that runs is typically used as a bootstrap program. It communicates through the Internet and downloads and runs a more sophisticated worm distribution program. The distribution program typically has two goals:
- Infect the attacked machine. This may include destroying resources (deleting files) or installing backdoors.
- Propagate itself. It uses the Internet connection to spread by looking for vulnerable Internet servers that are waiting for service requests. Once a vulnerable server is identified the program launches an attack that exploits the specific vulnerability to break into the vulnerable server.
Automation makes the worms spread rapidly and compromise a vast number of machines. Back in 1988, the 'Morris worm' was probably the first case that got a lot of attention. This simple worm exploited a buffer overflow vulnerability and spread across more than 6,000 machines within 90 minutes. Considering the small size of the Internet and the slow connections back then, this attack was very significant. Code Red in 2001 spread over 300,000 machines in 14 hours. This powerful and destructive power translates into a significant cost. According to Computer Economics, the associated damage from Code Red and Nimda came to $3.72 billion.
The existence of two components, the bootstrap code and the distribution engine make the worms modular and hence, more powerful. The bootstrap code exploits a newly discovered vulnerability in order to penetrate the system and to download the distribution engine. To come up with a new worm one only needs to rewrite the bootstrap code to take advantage of the new vulnerability. The distribution engine does not need to change significantly; it can be shared between different worms and the progress of the distribution programs is then accumulative since each version is built on top of previous ones.
Code Red and Nimda were perfect examples of Internet worms. Code Red exploited the .IDA vulnerability in IIS. It had three different versions, each one improving the distribution mechanism, which resulted in dramatic acceleration and spreading. The final version also installed a backdoor that allowed free access to the infected machines.
In the case of Nimda, the worm exploited a number of Microsoft web server vulnerabilities to gain control of a victim host. Network attacks included exploitation of the "IIS/PWS extended Unicode directory traversal vulnerability" and the "IIS/PWS escaped character decoding command execution vulnerability." In this specific case, the worm gave commands and executed them using the TFTP command to transfer its distribution code from the attacking machine to the victim.
The bottom line is simple: worms prove that despite the significant effort and money spent on security, the single biggest challenge faced by users is still software vulnerabilities. Simply, users are left exposed for prolonged periods of time between vulnerability exposure, patch development and deployment. Due to the relative ease with which new worms can be created, the situation only worsens. The typical reasons for users' exposure are:
- Vulnerabilities do not typically become public knowledge within a short timeframe. More and more anecdotal evidence shows that a vulnerability may be known in the hacking underground for a long period before it becomes public knowledge.
- Vendors release patches slowly. It is common that several months will pass between the vendor being notified of a vulnerability and the patch being released. In other cases, the patches, unfortunately, are not adequate and the systems remain vulnerable.
- Users deploy patches slowly, if at all. This is perhaps the biggest issue. It is not uncommon that test machines are left unpatched, increasing their potential for victimization. For example, with Code Red, most of the public web servers were patched but the big surprise was the huge number of test web servers connected to the Internet that were not patched.
It is obvious that there is a steady evolution in worm technology. The bootstrap programs are going to leverage the new exploitation techniques being developed. The more significant progress in exploitation techniques is identified in the following categories:
Non-execution buffer overflows. These techniques, such as return-to-LIBC, do not require the malicious code to execute. They cause the vulnerable program to execute an existing procedure and often provide the attacker with elevated privileges. These mechanisms bypass the non-stack execution feature provided by various vendors, including SUN Microsystems and Immunix (makers of StackGuard).
Heap-based overflows. With the recent techniques discovered, it is possible to manipulate the "malloc" data structure effectively such that an attacker is able to write any value to any address in memory. This powerful capability allows a malicious program to manipulate important data structures, overcoming the program's integrity. For example, by manipulating authentication flags, a hacker can bypass the authentication and authorization mechanisms and gain privileged access.
Design bugs. In some cases, bugs allow non-privileged users to access APIs and services that can be used to escalate user privileges. Recent examples are Debug registers and Debploit that allow an attacker to exploit improperly designed interfaces to escalate privileges.
On the distribution program side, it is anticipated that worms will use root kits. A rootkit inserts backdoors into existing programs, and patches or breaks existing security systems. A rootkit may:
- Disable auditing when a certain user is logged on.
- Allow anyone to log in if a certain backdoor password is used.
- Patch the kernel itself, allowing anyone to run privileged code if they use a special filename.
The possibilities are endless, but the point is that the rootkit involves itself in pre-existing architecture, so that it goes unnoticed. Unlike a remote administration application such as PC Anywhere, a rootkit patches the already existing paths within the target operating system. Once the worm gains control of the machine, it is anticipated that a rootkit will be installed, allowing hackers access to the compromised machine without being noticed.
Once the system is compromised the next logical step is to stop existing protection systems. Anti-virus products are most likely going to be the first candidates but host-based intrusion detection systems (HIDS) and other host guarding mechanisms will also be targeted.
Solutions that can prevent worms should address the following issues.
System patching is an effective solution, but the gap between the exploit appearance and deployment of the patch is inherently large. During that time, users are exposed. This is an unacceptable situation and there is a clear need for a solution that will either replace patching or provide an additional security layer until the patch is applied.
Solutions that are based on understanding the specific vulnerability are not adequate. Signature-based approaches need to be complemented with more generic approaches such as behavior monitoring that can handle unknown attacks.
Since at least 50 percent of the security advisories deal with buffer overflow vulnerabilities, special attention should be given to solutions that address buffer overflows. Simple stack buffer overflow exploitations, as well as more advanced heap based and non-executable exploitation techniques, should be addressed.
Solutions that detect changes in the integrity of the system are vital. Even more important are solutions that lock down the machine, preventing any modification to the binaries, data and configuration of the system. Application level security is also becoming increasingly important. Specific systems that address web servers and other common servers should be considered.
Worms are a major threat to the Internet. Their automatic nature makes them powerful and destructive. Using existing and evolving methods of propagation, it is likely that they will become increasingly more powerful. Solutions based on diligent application of patches or signature-based products are not realistic, as recent experience shows. There is a clear need for active protection systems that prevent exploitation attempts and can deal with unknown attacks, as well as provide protection for all critical software layers, including the OS, APIs and applications.
Dr. Yona Hollander is vice president of security research, Entercept Security Technologies (www.entercept.com).