3.2 Exploits

An exploit allows an attacker to take advantage of known weaknesses in operating systems or applications to gain access to a server. Exploits can be performed in many ways; however, it is becoming increasingly common for an exploit to be written into a software application that can be easily pointed at any server.

NOTE

Exploits as programs make it very easy for script kiddies to wreak havoc, but they also separate true attackers from the script kiddies. One developer, having set up a honeypot on a FreeBSD system, went into a well-known script kiddie chat room and told them about a "vulnerable" Microsoft Windows IIS server he had discovered . Seconds after his announcements the honeypot server began getting attacks designed to exploit vulnerabilities in the Microsoft Windows server. Not one person bothered to verify whether it was really a Microsoft Windows server.

Before an exploit can be run, it is important to know what operating system is running on the network device. Some exploits work on some systems, but not others. There are many tools to do this, but since nmap has built-in operating system fingerprinting capabilities, it is often easiest to use:

 [root@test root]# nmap -O www.datacenterwire.com  Starting nmap V. 2.99RC2 ( www.insecure.org/nmap/ )  Interesting ports on (66.150.201.102):  (The 1587 ports scanned but not shown below are in state: closed)  Port State Service  21/tcp open ftp  22/tcp open ssh  25/tcp open smtp  53/tcp open domain  80/tcp open http  81/tcp open hosts2-ns  110/tcp open pop-3  443/tcp open https  587/tcp open submission  886/tcp filtered unknown  3306/tcp open mysql  5432/tcp open postgres  10000/tcp open snet-sensor-mgmt  32787/tcp filtered sometimes-rpc27  Remote operating system guess: FreeBSD 4.5-RELEASE (or -STABLE) (X86)  Uptime 72.083 days (since Fri May 17 17:15:58 2002)  Nmap run completed -- 1 IP address (1 host up) scanned in 685 seconds 

The attacker now knows that the site is running FreeBSD, Version 4.5, on an Intel processor. With that knowledge the attacker can:

• Attempt to exploit known vulnerabilities in the operating system.

• Try to access the server through security holes in the applications running on the server.

FreeBSD is a fairly secure operating system. Rather than try to crack the operating system directly it is usually easier to exploit security holes in applications running on the server.

In June 2002 a serious security flaw was found in the Apache web server, used by more than 18 million websites around the world. This security hole caught many people off guard, and given the large install base, it will be a while before the majority of Apache web servers will be upgraded. A good attacker knows this, and will check to see if the server is vulnerable.

Fortunately there are numerous tools that can be used to test for application weaknesses. Network administrators use scanning tools to find security holes within their own network. Unfortunately, there is nothing preventing an attacker from putting these tools to the same use.

A common application used for tasks like this is Nessus (www.nessus.org). Nessus is designed specifically for remote security scanning; that is, it is built to emulate the actions of an attacker attempting to break into a network. The developers of Nessus maintain a database of known vulnerabilities. Administrators ”or attackers ”can use this database to find known security holes in various servers on the network. Administrators can patch the holes; attackers can exploit them.

In this case, the attacker already knows that he or she wants to try an Apache exploit, so there is no need to use Nessus, because there are programs that will simply check for Apache vulnerabilities. A fairly common tool is the Retina Apache Chunked Scanner, developed by eEye Digital Security (www.eeye.com). Simply enter the IP address, or range of IP addresses to be scanned, and it will check for the vulnerabilities. Figure 3.2 shows that the server is not vulnerable to this particular attack.

Figure 3.2. The Retina Apache Chunked Scanner checks for a specific Apache vulnerability. Other tools will check for a wider range of vulnerabilities.

This server is not vulnerable to the Apache exploit, so what is the next step? That depends on the attacker. If the attacker is specifically targeting this server, he or she will attempt to find another way in. If the attacker is simply looking for a server to attack, and does not have many tools with which to launch the attack, then he or she will probably move on to another server that is vulnerable, as in Figure 3.3.

Figure 3.3. This server is most likely vulnerable to the Apache Chunk exploit. The next step would be to attempt to exploit the server.

It is not uncommon for an attacker, especially a script kiddie, to have a limited arsenal of weapons with which to launch an attack. This is especially true if the attacker does not understand how the attack works, and is relying on tools developed by someone who does. This type of attacker is not going to try a systematic approach to a server attack; instead, the attacker will move on to a less secure server.

Figure 3.3 shows a server vulnerable to the Apache Chunk exploit. Once the attacker finds a server that is vulnerable, the next step is to exploit it. Again, this can be done by understanding the weakness and developing a program to take advantage of it. Alternatively, if a script exists to do this for the attacker, that script can be used.

NOTE

The Apache Chunk exploit is a bug in the way Apache deals with files being uploaded when the server is unable to determine the file size .

In this case, the code to take advantage of the Apache Chunk exploit is available in a compiled format from the Packet Storm security website (packet- storm .decepticons.org/filedesc/apache-nosejob.zip.html). Download the code, target the server (as in Figure 3.4), and an attacker can gain root access to the remote web server.

Figure 3.4. Using the program to launch an attack against a website and exploit a security hole in the Apache web server

Often it takes very little skill to break into a server, especially a web server. It is simply a matter of knowing the tools needed for the job and implementing them.

3.2.1 Rootkits

When an attacker gains access to a server, the first goal is to cover his or her tracks. Installing a rootkit often does this. A rootkit has two purposes: to cover the tracks of the attacker and to gather information about the server and its users.

Rootkits usually kill logging services and monitor the keystrokes of system users looking for passwords and other useful information. A rootkit will contain several programs that hide the activity of the attacker.

A good example of a rootkit is Tuxkit, developed by Tuxtendo (www.tuxtendo.nl). Tuxkit has all of the classic features that make a rootkit useful for an attacker: easy to install, leaves a backdoor on the system, covers the tracks of the user , and replaces system files with compromised binaries that are used to gather server intelligence. Tuxkit consists of several files and an installation script:

 -rw------- 1 1209 1209 502884 Dec 4 2001 bin.tgz  -rw------- 1 1209 1209 406 Dec 4 2001 cfg.tgz  -rw------- 1 1209 1209 16213 Dec 4 2001 lib.tgz  -rw------- 1 1209 1209 3684 Dec 4 2001 README  -rw------- 1 1209 1209 461892 Jan 5 2002 sshd.tgz  -rw------- 1 1209 1209 1644819 Dec 4 2001 tools.tgz  -rwx------ 1 1209 1209 9489 May 15 14:59 tuxkit 

For ease of use the installation script, Tuxkit, requires that only a single variable be changed:

 #!/bin/sh  # Tuxtendo Linux Rootkit v1.0 By Argv[]  # Your e-mail address  EMAIL="[e-mail]"  # You don't need to edit anything below this 

All an attacker has to do is execute the install script. The attacker's tracks are covered and Tuxkit begins to gather information. It also sends a nice e-mail to the attacker with the IP address and backdoor information to the server:

 ssh 192.168.0.40 -l root -p 4000 # test.allan.org password: R0s3ann3  psyBNC: 4001 

This allows Tuxkit to be used in an automated fashion: Load a large netblock into a security scanner, looking for exploitable servers; when a server is successfully compromised, install Tuxkit. The e-mail is sent to the attacker, who may be able to take control of several dozen servers in a few hours.

On a well-secured network, a rootkit should not go unnoticed very long. If unusual traffic is generated from a server, or an administrator notices that syslog is disabled, this should set off alarms. In addition many administrators run chkrootkit (www.chkrootkit.org/) to check for rootkit installations. Not only does chkrootkit look for specific rootkits, it also looks for modified files and alerts administrators that they have been modified. On a system infected with Tuxkit:

 [root@test chkrootkit-pre-0.36]# ./chkrootkit  ROOTDIR is `/'  Checking `amd'... not found  Checking `basename'... not infected  Checking `biff'... not found  Checking `chfn'... not infected  Checking `chsh'... not infected  Checking `cron'... not infected  Checking `date'... not infected  Checking `du'... INFECTED  Checking `dirname'... not infected  Checking `echo'... not infected  Checking `egrep'... not infected  Checking `env'... not infected  Checking `find'... INFECTED  Checking `fingerd'... not infected  Checking `gpm'... not infected  Checking `grep'... not infected  Checking `hdparm'... not infected 

While relatively easy to spot, rootkits are popular because, like some of their companion exploits, they can be quickly installed and manage many tasks that some attackers do not have the skills to perform.