1. Introduction

After a succesful intrusion into a system, usually the intruder will install a so-called "rootkit" to secure further access. Such rootkits are readily available on the net and are designed to be used even by less experienced users.

Rootkits usually comprise tools to erase traces of the intrusion from audit logs, "backdoors" that allow easy access, once installed, and means to hide the rootkit itself from administrators (such as, e.g., a modified executables of 'ps' and 'ls' that will hide processes and files of the rootkit. Advanced rootkits will install such modified executables with the same sizes and timestamps as the original ones (which is quite easy - any executable can be padded to a larger size by simply adding random junk at the end), and also with the same CRC checksum (which also can be adjusted).

To detect such rootkits, it is necessary to have a database of cryptographic checksums of critical files, and compare these against the actual files. Useful cryptographic checksums include MD5, SHA-1, TIGER (but not CRC, which can be faked).

Any application program is controlled by the kernel, and any system access (such as writing to/reading from the disk) is performed by the kernel. The application will call a kernel syscall, and the kernel will do the work and deliver the result back to the application. From a users viewpoint, these syscalls are the lowest level of system functions, and provide access to filesystems, network connections, and other goodies. By modifying kernel syscalls, kernel rootkits can hide files, directories, processes, or network connections without modifying any system binaries. Obviously, checksums to confirm the integrity of a system are useless in this situation.