14.3. Rootkits

Having obtained access to the system, hackers strive to fortify their positions and to obtain maximum privileges. Once in the system, a hacker will never be satisfied with regular user privileges and will seek the capability to execute commands with the root privileges.

The hacker can go about obtaining this capability by obtaining file-loading capabilities and then uploading and installing a special program for raising privileges to root, called a rootkit. After this, any command issued by the hacker is executed as follows :

The command has regular user permissions and is sent to the rootkit program.
The rootkit program has root permissions and executes the hacker's program as the root.

But how does the rootkit program obtain root permissions? With the help of the same notorious SUID or SGID bit.

Moreover, the ownership of the rootkit program must belong to the root user. There are two ways of changing a program's ownership to root and setting its SUID or SGID bit. These are the following:

Use the chown and chmod commands (if such an opportunity exists).
Substitute the rootkit program for an existing program with root permissions and the SUID or SGID bit set.

This is why SUID and SGID programs should be tightly controlled. Each such program is a hole in system security, but unfortunately sometimes these programs are necessary. You should closely monitor such programs and immediately delete any new ones that are not installed by yourself. You should also monitor changes to the legitimate SUID and SGID programs. A size change of an SUID or SGID program is a cause to sound the alarm, because this may be an indication of the legitimate program having been substituted with a hacker version.

Pay close attention when checking SUID and SGID programs. Hackers know that administrators monitor such programs, and they resort to various tricks to prevent their infiltrated or subverted SUID and SGID programs from being detected . For example, you may see nothing alarming in that the /mnt/mount program has the SUID set because the mount program does require this. However, the legitimate mount program is located in the /bin directory, and the one in the /mnt directory is without a doubt a cuckoo egg. If you are going over the list of the SUID and SGID files in a hurry, you may not notice the directory difference or may not even be looking at the directories in the first place.

Moreover, hackers can substitute letters in the names of legitimate programs with letters similar in appearance. For example, they can add the /bin/logon program masquerading as the /bin/logon. The difference is that the letter "1" in the legitimate version is substituted with the digit "1" in the counterfeit one. You likely will not notice the difference, because the legitimate version does not have the SUID and SGID bit set and only the fake one will show in the SUID and SGID list. And even though the login program should not have this bit set, you, most likely, will not suspect this program is anything malicious.

In addition to making it possible to execute commands with root permissions, rootkit packages provide other functionality. These can be utilities such as network sniffers, log file manipulators for cleaning up hacker's tracks in the system, and other hacker tools.

Once hackers have a rootkit package installed in the system, they can always come back even if you find and patch the hole used to enter originally. Thus, you should be able to locate and neutralize rootkit packages.

You can use the chkrootkit program for this purpose (available from www.chkrootkit.org ). Currently, it can detect more than 50 different popular rootkit packages.

But, as usual, the protection from an automated tool is limited and a sweep by chkrootkit will not guarantee your system a clean bill of health. The problem is that only beginning hackers use readymade rootkit packages. Professional hackers are good programmers and create their own tools. It is not that difficult; they only have to know some programming and the way Linux operates. Therefore, you should be able to detect and neutralize rootkit packages manually yourself.

One of the ways of detecting rootkit packages manually is to scan the ports, because to open a back door to the system a rootkit opens a port, which it monitors for the hacker to connect.

One of the best Linux scanning tools with extensive functionality is the already-mentioned nmap utility. To scan all 65,535 ports, the program is launched as follows:

 nmap -p 1-65535 localhost

The -p parameter sets the port range to be scanned. In this case, the entire range of existing ports from 1 to 65,535 is specified.

The following parameters can also be used:

-sT Standard TCP connect scan. This is the slowest scanning, opening a connection to every port on the scanned machine. Any antiscanning utility will detect this scan (see Section 12.4 ). This is the default scanning mode if the program is run with the regular user permissions.
-sS TCP synchronization (SYN) scanning. This is the default scanning mode for root users. It is faster than the sT mode and is detected by fewer antiscanning utilities.
-sF TCP finish (FIN) scanning. Pursuant to RFC 793 specifications, closed ports must reply to a FIN packet (sent by a client to the server to initiate connection termination) with an reset (RST) packet. Consequently, receiving no RST packet in response to a FIN packet indicates that the given port is open. This, however, applies to Linux systems only. Windows creators , as usual, decided to ignore the standard and do it their own way, so the scan will not work against these systems.
-sX TCP Xmas tree scanning. This scan is similar to the TCP scan, only the URG and PUSH flags are set in addition to the FIN flag.
-sN TCP null scanning. This scan is similar to the previous two scans , only no flags are set.
-I Ident scanning.
-sU UDP scanning. UDP ports are different from TCP ports and must be scanned separately.

The idea of scanning consists of obtaining some sort of reply from the server. Depending on the scanning method employed, a positive or negative reply indicates that the given port is closed or open.

A faster way to determine open ports is to use the lsof -i or netstat command; however, these can only be executed on the machine whose ports are being scanned.

In addition to checking the system for rootkit packages, you should check for the presence of extraneous loadable kernel modules. You can use the chkproc utility for this purpose, which is included in the chkrootkit package. The packet also includes the ifpromisk utility, which is used to detect network sniffers.

Finally, check for the presence of extraneous processes by executing the ps -aux command to list all currently running processes. Pay close attention when inspecting the process list. Remember the trick of swapping the digit "l" for letter "l," which is probably the most widely-used trick. Giving just a cursory once-over, you may not notice the difference.

Combined use of all of these utilities will allow you to detect rootkits that chkrootkit misses.

After you identify the files belonging to the rootkit program, you have to stop their operation and delete them from the system. This will suffice unless the rootkit has modified some system files. If, however, it has, you will have to determine, which programs have been modified, and reinstall them. In Red Hat distributions, which support RPM packets, this can be done by simply executing the following command:

 rpm -U -force packet_name.rpm

Here, packet_name.rpm is the name of the program to reinstall.