Wednesday, October 14, 2009

Linux Securirty Notes 12: Rootkits

RootKits - Security
    RootKits are bundles of programs that are meant to exploit the existing programs on the system for the purpose of providing backdoor access to crackers . Inshort the rootkits will provide a back door access to cracker. RootKits can be installed by gaining the root access or by exploiting the vulnerability of any software to gain the access of privilege users
RootKits are installed in several ways.
  • Using physical access. (Manipulating the grub and installing the rootkits in runlevel 1 & using any physical media like USB, CD-ROM etc)
  • By getting the root/user password by sniffing/bruteforce attack and install the root kit.

Major Function of Rootkits once it installed in *nix box
  • An attacker may use a rootkit to replace vital system executable, which might be altered to hide processes and files the attacker has installed, along with the presence of the rootkit.
  • RootKits act to obscure their presence on the system through subversion or evasion of standard operating system security scan and surveillance mechanisms such as anti-virus or anti-spyware scan, this makes they are Trojans as well, thus fooling users into believing they are safe to run on their systems
  • Rootkits may also install a "backdoor" in a system by replacing the login mechanism (such as /bin/login) with an executable that accepts a secret login combination, which, in turn, allows an attacker to access the system, regardless of the changes to the actual accounts on the system.
Detecting and cleaning up the RootKits:

    T0rnkit is one of the "older RootKit" that can be used to manipulate some of the binaries and make the server to compromise and enables a backdoor access. So now we will have a hands on by installing a the T0RNROOTKIT.


    Download it from
# wget
# tar zxvf tk.gz
# cd tk

    These folder contains modified binaries and the rootkit. The binaries are du, find, ifconfig, in.fingerd, login, ls, netstat, ps, pstree, top, ssh.tgz etc. These binaries have been modifies and the installation of the tornkit will replace all the original binaries with this altered binaries and makes the system accessible to third party via
# ./t0rn
    This will replace all the binaries in this directory with the original binaries. The execution of this binary will echo the status of the binary replacement.
Now if we try executing any of the compromised binaries eg:- ls, top, pstree etc the exicuted binary can now open your system to the cracker with the respective privileges.

Detecting the RootKit
Step 1:
    1. We have to take the md5sum for the prestige binaries in the system just after the installation to compare later on when the system is subjected to compramise.
Step 2:
    2. The usage of AIDE tool can be used to detect the change in the binaries done by RootKit. (refer Linux Security Notes - AIDE). This will detect the changed binaries, newly added files and folders And the removed files. So from this we can make out what binaries has been changed. Manual check with the changed binaries and the configuration files will give the mere idea that where & which binaries has been invoked upon next reboot the bring back the rootkit process. This is the simple way for checking the binary files integrity in case of any rootkit installation.
Step 3:
    3. Installing the rootkit checker     
CHKROOTKIT is the common rootkit checking tool

Installtion & configuration of CHKROOTKIT
    Dowmload chkrootkit, md5sum and signature from Compare the keys. chkrootkit runs has a shell script with helper  binaries.

# tar -zxcf chkrootkit-0.55
# cd chkrootkit-0.55

    Here we have chkrootkit shell script. This script scans the appearence of any rrootkits. This chkrootkit shell script relies upon "ls" "ps" and "find" commands. So keep in mind that we will have a uncompramised binaries of the "ls" "ps" & "find". These binaries can either be reinstalled or can be copied from any of the other systems before exicuting the chkrootkit . The chrootkit scripts need some of the binaries to get a versatile result on scanning. These programs are included in the source package of chkrootkit.
We have to compile these binaries (helper programs) and make available to chkrootkit while scanning.

# make sense
    This will compile all the 'C' programs and compiles the binary. This will yield some binaries which will be helping the chkrootkit script for scanning. These binaries can be exicuted intependandly for verifying the system.

Running the chkrootkit
#./chkrootkit OPTIONS TESTNAME

    This will check all the options and all the rules. This will start scanning all the files from the "/" of the directory and echos the out put in to the screen. The infected files will be denoted as INFECTED . And it will search for all the key rootkits that known to chkrootkit and echos too.  Using this result of chkrootkit and comparing with the AIDE output taken prior to compramise we can change/reinstall the binaries effected by rootkits and the remove the files and folders created by rootkits.

For an uninfected file the out put will be:
Checking `amd'... not found
Checking `basename'... not infected
Checking `hdparm'... not infected

For an Infected file the output will be:
Checking `ifconfig'... INFECTED
Checking `login'... INFECTED

    Now after cleaning up check the AIDE again to verify the file integrity. Run chkrootkit. Then use nmap and Nessus for checking any more ports are listening or still more vulnurability is there or not.

   Types of rootkits
  1. Will change the key binaries. This can be detect with AIDE/Chkrootkit.
  2. Runs as a kernel modules - LKM (Loadable Kernel Module) This can be also be detected by the AIDE/Chkrootkit. We can check this type of rootkits by comparing the modules prior and after the suspect of compramise using the # cat /proc/modules or lsmod
  3. Writes directly to /dev/kmem. It access directly the memmory area that applications that are using. And is very hard to trace out.
Other Binaries in chkrootkit.
    Will check whether the interface is running in promiscuous mode.
    checks the logfile for any manipulation.
    checks the trace for rootkits in the proc file system.
Consult the README file in the source code for more options on exicuting the chkrootkits.

    Always have a AIDE DB for reference.

    This is a simple rootkit which provides the server and clinet components to set up a backdoor for cracker in server by connecting to it remotely using UDP protocol. It sets up the UDP listener port:1500 which makes difficult to trace out. This waits for specially-crafted packets generated by the N-DU client and when revieves it switches to TCP: Port specified by Cracker.

For testing we will download the N-DU rootkit now.
            Download the N-DU rootkit from
(You will find a lot of penetration tools here in this website including various security tips. Here you can the majority of the rootkits which gives the cracker the backdoor entry)

Find the N-DU rootkit and download. We need the 'C' compiler installed to compile it.
# tar -zxvf nd-du.tgz
    This will extract the source.
n-client.c (n-du client)
n-du.c  (n-du server)

    are the files included in the source.
# make
    This will yield 2 new binaries called n-du (server rootkit) and n-client (client rootkit).
The cracker will place the n-du binary in the server which he needs to be accessed through backdoor and exicutes it. Now he uses the n-client from outside the network to connect to the n-du server.


    This will start the n-du rootkit in the daemon mode, starts the process and binds to the UDP port 1500. the user privilage relies upon the user which has exicuted the n-du daemon. for eg:- if the root user has been exicuted the n-du binary then the cracker if ne connects from outside using the n-client binary will gain the root shell access.
#netstat -tulpn
    This will show now the port 1500 has been started listening.

Exicuting the n-client
    Now in the client the cracker exicutes the n-client to access the remote server shell
# ./n-client host TCP-Port UDP-Port
    Host=the remote host that n-du needs to be connected to
    TCP Port = is the port that needs to be shifted once the connection is been established.
    UDP Port = the udp port that the remote n-du is listening.

#./n-client remotehost  6666 1500
    This will ask for the password. Now press enter with out any entry .This will gain you the remote system access with the user privilege that the n-du daemon runs.

        Use nmap and netstat to trace out the unknown open port. Check the vulnerability using the Nessus. And always use the AIDE file integrity tool along with chkrootkit to find out the new files installed by any rootkits

No comments:

Post a Comment

tag ur valuable ideas below