The techniques hackers use to get into a targeted system, for example brute forcing passwords or using exploits, usually leave a lot of traces behind on a (good configured) victim system. And even if they succeeded in compromising the system, there�s still a big chance of being detected by the system administrator. Log file entries, suspicious processes and network connections are bound to be noticed by the local system administrator or security team. A rootkit is a tool used by many hackers in order to solve some of these �problems�. The main purpose of a rootkit is to allow intruders to come back to the compromised system later and access it without being detected. A rootkit generally contain network sniffers, log-cleaning scripts, manipulated replacements of system utilities such as ps, netstat, ifconfig and killall, trojanized versions of certain login daemons, this all to stay undetected and get more accounts. Although an intruder still needs to break into a victim system before he or she can install their rootkit, the ease of use and the amount of destruction they cause make rootkits a big threat for system administrators. In this article I will be explaining some of the basics of �root-kitting� and of course the usual stuff on how you can protect yourself against such tools.

Rooting for kids?
Using a rootkit is extremely easy, with which the potential risk factor increases dramatically (script kiddies). Another problem is that there is rootkit available for (almost) every operating system, and if there none yet, there will be in the future.

The most common used rootkit on Linux goes by the name or t0rnkit. This rootkit can be used without having to execute further commands and it hides processes and connections, which would arouse suspicion, automatically. Luckily it is one of the easier ones to detect and remove, but still very dangerous if the system administrator doesn�t know what he is looking for.

For the undermining of system integrity there are basically two methods: the older and more harmless rootkits replace/change system instructions and safety programs, while the more modern and dangerous rootkits directly manipulate the kernel by replacing system-calls like open() and read().
An example of an older and more harmless rootkit is the earlier mentioned t0rnkit, a rootkit that is widely used on Linux and Unix. T0rnkit attempts to hide its presence when installed. During installation it first shuts down the system logging daemon, syslogd. It then replaces several other system executables with trojanized versions and adds a trojanized ssh daemon to the system as well. Programs that are replaced are, among others; du, find, ifconfig, login, ls, netstat, ps, sz and top. If the system administrator uses these somewhat vital functions they report normal looking information, but the processes and network connections that the hacker uses aren't shown. Finally T0rnkit starts a sniffer in background, enables telnetd, rsh and finger daemons in "/etc/inetd.conf", restarts inetd to activate changes made and starts syslogd again. This all without the system administrator knowing about it.
Noteworthy is that all new programs in the t0rnkit all have the exact size of 31.336 bytes. T0rnkit usually can be found in the directory /usr/src/.puta, but of course not if it already has been activated because the command 'ls' will have been replaced. With the standard installation of t0rnkit TCP port 47017 is open for root access to the system. A modified version of this rootkit was also distributed by a variant of Unix/Lion worm. A system administrator that is a little bit into the security world can find a with t0rnkit infected system pretty fast because of the change in file sizes and a simple port scan will reveal the open port, but funny enough most people don't have this 'expertise'.
Another common used, more advanced, rootkit is 'Adore', which is a lot harder to discover. This is because adore integrates into the system as a Loadable Kernel Module (LKM). Doing so it replaces system-calls like open() and in doing so it changes the behaviour of programs without changing the programs. For example, 'ps' uses a open()-system call and reads information from files in the directory /proc, where also the information about running processes is kept.

Thus the effect is the same as rootkits that change system files; processes, files, connections and other information isn�t displayed. Adore tests files and connection on certain conditions and changes the output of the kernel so for example directories and connections of the attacker aren't displayed anymore. 'Knark', the follow-up of 'Heroin' work likewise.
Adore and other LKM-rootkits only function when if the kernel is compiled in such a way that dynamic modules can be loaded, so they can be integrated while using the system. When you delete the module(s) of these LKM-rootkits, your problem will be solved, but of course first you will have to detect the infection.

But even with a static kernel you won't be in the free zone: the Kernel Intrusion System (KIS) from Optyx is this moment probably the most important and modern program to undermine system integrity. In stead of offering own manipulated kernel functions it writes directly into the RAM-memory of a system and thus changing the output of programs. KIS uses kernel-memory-patching to accomplish this. For this method there is no support of kernel-modules required, only write access to parts of the RAM (with Linux /dev/kmem).

An admin on a Linux network/system can't do much with the given means because write access to /dev/kmem is part of the kernel. But there are solutions like the kernel-patch from grsecurity, which protects the Linux 2.4 kernel series protects against this type of attack. Before installing such kernel-patches on your system(s) do read the documentations because with some configurations of the patch your system will no longer work smoothly.

What makes KIS really special is the build-in backdoor, that even with intensive scans is hard to discover. This is because the backdoor is only activated when a special TCP-packet is send to the backdoor's IP. KIS is also ready for the future with its interface for plug-ins, which will allow expansion of new features.

Who's screwed?
In principle all operating systems are at risk to be infected with a rootkit. But the recent trend is to make rootkits for Linux, which gives little protection against this type of manipulation of the root-account. But don�t pull out the champagne yet, for Solaris (solk5.tar.gz) and BSD (thcbsdk) there are functioning rootkits out there.

Because of BSD-secure-levels, which prevent manipulation of kernel modules without a reboot, BSD is better protected against such manipulations. According to Optyx, creator of KIS, there are many possible scenario's in which these secure-levels can be fooled; he wants to port KIS to BSD and Solaris in the near future. But seeing is believing.

Not even Windows NT/XP/2k are unaffected by this event; Windows attackers can enter through a weak spot in the Internet Information Server (IIS), gain administrator rights and change the Windows-kernel using rootkit-DLL. Windows-rootkits aren't as commonly used by hackers as the other variants. Maybe this is because Windows is always full of holes through which a hacker can (re-)enter, or maybe they don't see the need to hide their tracks, or just because most servers hackers encounter aren't Windows based.

Reacting�
A simple strategy to find unauthorised changes in the file system is the calculation of cryptographic checksums for all essential system files, which normally never change. To do this you have to start with a completely clean/safe system and copy the baseline to a cd or a removable device. You also have to compare the new and old checksums on a regular basis to see if there have been any unauthorised changes. The most used program that does the job well is Tripwire, but there are lots of other alternatives out there. But with LKM-rootkits Tripwire is useless because it will then trust on manipulated system-calls of the Operating System.

Even methods based on a specially developed security-kernel-modules which detect and prevent the installation of rootkits by guarding the system 24/7, aren't immune to these kinds of attacks. Certainly in the generation of kernel-memory-patching-rootkits like KIS there are specific attacks implemented which systematically can either bypass or terminate such security-kernel-modules.
Kernel-based rootkits are in general to detect by tests which are run on the infected system, because those tests are influenced by the manipulated kernel. This can be prevented by not trusting the system-calls without any suspicion, but comparing it with the information directly from the kernel-memory. 'Check-ps' is a usable tool that uses this method. The program compares certain information with the information that is read directly from the RAM.
An example of an infected system is that the output of 'netstat -anlt' (all open TCP-ports) and the output of a direct port scan is different (nmap 127.0.0.1 -p 1-65535). Differences in open server ports most likely mean that there is a hidden backdoor present on the system.

But this is not enough to determine wetter or not the system is infected, there will have to be an extensive analysis: all data on the hard disk has to be analysed from a clean system install and checked, if there is a baseline of checksums present. The best way to do this is to boot from cd, which doesn't use the installed system. Although most installations cd's give the option to do this, it is best to make a boot-cd yourself which is compatible with RAM-disc.

Preventing�
Of course the best think is to avoid installations of rootkits. System administrators using Linux or Unix have several ways to make it harder for hackers to install a rootkit, and in case of an infection detect it pretty fast.
The most important thing you have to do to avoid being infected with a rootkit, is try to not be a likely victim of random hacking. You can do this by keeping your system secure and up to date. Make sure all your software is up to date, disable unnecessary daemons, install a firewall and implement a good security-policy. For extra protection you can install a security-patch for your kernel, which will protect you against some known attacks (buffer overflows, etc.). These patches are available for both Linux and BSD distributions. Don�t forget to check the documentation that comes with these patches, in some configurations of a production process they will affect it because of the restrictive security policy.

To detect attacks in an early stage, it helps to use a good secured dedicated computer serve as a �loghost�. The information in the logs from all the systems must be protected and transferred in real-time to a secure place (the loghost). Although you have to take into account that after your network has been compromised, you won't receive further alarming log entries because the attacker installed a rootkit (or anything else for that matter). But you can still use the early log entries which show you that your network has been compromised, which is good to know. An even saver method of preserving and protecting logs is writing them to a not rewritable disc (cd-r), but this will proof very expensive in the long run.

If you want to be for a full 100% sure about the integrity of your system, or you want to be able to fix your system when compromised, you have to make a ghost backup of your entire system. This you have to store on a save place and medium, unattached from the network (stand-alone).

Intrusion Detection Systems (IDS's) also play an important role in the process of stopping attacks and detecting of backdoor entries. A Network Intrusion Detection System (NIDS) with Intrusion Response Capability can't only notify you, but can also block the ongoing attack. Snort is a common used IDS.

Lets not forget about LIDS, a host-based IDS for Linux, can also fight against local attacks with rootkits. If LIDS is installed and configured correctly not even a root user can without any doubt open new ports, add modules or alter system files, which are specially protected by LIDS. Although this sounds great, LIDS isn't the perfect solution because it doesn't prevent writing to the kernel-memory.

Another countermeasure against LKM-rootkits is not to compile drivers or features of the kernel as a module, and disabling module-support in the kernel by static compilation (deactivate all options in the kernel-configuration-menu with 'Loadable module support', and recompile). This measure makes the insertion of kernel modules (and rootkit modules) impossible. To make the memory entirely protected against writing to it, there has to be an little patch integrated into the kernel:

Future of rootkits.
What the further development of rootkits will be, we will just have to wait. History tells us that new rootkits always get developed by both white hat and black hat hackers. Usually they also publish the source code, with the effect that there are many variations of one and the same rootkit. Nowadays there is in almost every rootkit that is based on changing system programs also a kernel module. The more effective and easier kernel-memory-patching will be increased and improved.

There probably will be programmers of LKM-rootkits who will try to manipulate other parts of the system kernel. You can think of complex changes of the open()- and read()-system calls, which will render security measures of programs like check-ps useless. The real-time guarding of standard-I/O-output of every process is one of the possibilities of intercepting information that would expose an intruder.

The chances of the survival of a rootkit is best on a Linux based box, other Unix based machines offer better protection on kernel level. Because Windows-servers are more and more used, it is expected that there will appear new, more and improved rootkits for this Operating System. Via special kernel-DLL's a lot of functions of LKM-rootkits could be exported to Microsoft Operating Systems.

Links.

Loadable Kernel Module (LKM) Rootkits

http://rr.sans.org/threats/rootkits.php

http://rr.sans.org/linux/toolkit.php

http://la-samhna.de/library/lkm.html#common

http://www.pimmel.com/articles/lkm-hacking.html

Kmem-patching:

http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt

http://www.phrack.com/phrack/58/p58-0x07

Linux Kernel Patch (google):

--- linux/drivers/char/mem.c    Tue Jan  1 22:36:28 2002
+++ linux/drivers/char/mem.c.new        Mon Jan 14 00:55:32 2002
@@ -114,12 +114,16 @@
        unsigned long p = *ppos;
        unsigned long end_mem;

+       return -EPERM;
+
+       /* Never allow user space write access to memory
        end_mem = __pa(high_memory);
        if (p >= end_mem)
                return 0;
        if (count > end_mem - p)
                count = end_mem - p;
        return do_write_mem(file, __va(p), p, buf, count, ppos);
+       */
 }

 #ifndef pgprot_noncached

David O�Brien. "Recognizing and Recovering from Rootkit Attacks." November 1996.

http://www.cs.wright.edu/people/faculty/pmateti/Courses/499/Fortification/obrien.html

David Brumley. "Rootkits � How Intruders Hide"

http://www.theorygroup.com/Theory/rootkits.html

Network Intrusion Detection System:

http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm

Related Items:

• Altering ARP Tables V1.0
• The Art of Rootkits
• .:Hacking With Metasploit & Ne
• 3 Pervasive Phishing Scams
• 3 Reasons To Switch From Excel