 Compiling chkrootkit from source
Today I will be demonstrating how to compile the chkrootkit program from source code. The chkrootkit program is used to check local systems for signs of a rootkit. Rootkits are used mainly by hackers to circumvent the detection of thier presence on your system. They can use rootkits to hide system processes in order to trick system users into believing everything on thier system is fine. This compile will be taking place on a slackware machine that we only have ssh access to. The following will demonstrate how to install chkrootkit.
The chkrootkit source code can be found at http://www.chkrootkit.org/download/ . The files we will need to obtain are the latest source tarball and the latest source tarballs MD5 signature. These files will be downloaded into our build directory for compiling purposes. root@slackware:/usr/local/src# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz root@slackware:/usr/local/src# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5
Now that we have downloaded the files that are needed for the installation, we will now verify the integrity of the downloaded files. The way that we verify the integrity of the chkrootkit.tar.gz file is by comparing the values of the MD5 hashes. The first thing we want to do is check the md5 hash value of the chkrootkit.tar.gz file. The command to generate the md5 hash for comparison purposes is md5sum. The following command will display the md5 hash value of the file we downloaded. root@slackware:/usr/local/src# md5sum chkrootkit.tar.gz
de8b8b5013e7faa2b66c0e33c59677e8 chkrootkit.tar.gz
The md5sum of our source file chkrootkit.tar.gz has a value of de8b8b5013e7faa2b66c0e33c59677e8. Now that we know the md5 hash of the file we downloaded, we will need to compare that value to the md5 hash that we downloaded previously. All we need to do is look at the value stored in the chkrootkit.md5 file. root@slackware:/usr/local/src# more chkrootkit.md5
de8b8b5013e7faa2b66c0e33c59677e8 chkrootkit.tar.gz Since the supplied md5 hash value matches the hash value we generated on our system using md5sum we can proceed to the next step. If the two hashes do not match, then re-download the file and perform the md5sum again. The md5sum is used to verify integrity and allow us to be confident that the file we downloaded is the exact file that they intended for us to download. The verification is complete so we need to unpack the gunzipped tarball. To unpack this archive use the following command. root@slackware:/usr/local/src# tar -xvzf chkrootkit.tar.gz
chkrootkit-0.48
chkrootkit-0.48/ACKNOWLEDGMENTS
chkrootkit-0.48/check_wtmpx.c
chkrootkit-0.48/chkdirs.c
chkrootkit-0.48/chklastlog.c
chkrootkit-0.48/chkproc.c
chkrootkit-0.48/chkrootkit
chkrootkit-0.48/chkrootkit.lsm
chkrootkit-0.48/chkutmp.c
chkrootkit-0.48/chkwtmp.c
chkrootkit-0.48/COPYRIGHT
chkrootkit-0.48/ifpromisc.c
chkrootkit-0.48/Makefile
chkrootkit-0.48/README
chkrootkit-0.48/README.chklastlog
chkrootkit-0.48/README.chkwtmp
chkrootkit-0.48/strings.c
root@slackware:/usr/local/src# The tar -xvzf command will unzip and untar the chkrootkit.tar.gz file archive into the current directory /usr/local/src. From the output we can see that this file archive has created a subdirectory named chkrootkit-0.48 in the current directory. Now we will need to change directories to the chkrootkit-0.48 subdirectory in order to complete the compilation. root@slackware:/usr/local/src# cd chkrootkit-0.48
root@slackware:/usr/local/src/chkrootkit-0.48# Now that we are in the right place we need to know what to do. Compiling things from source is somewhat of an artform. This example is very trivial as opposed to something more advanced like a LAMP system. One thing that is almost always true is the existence of documentation. As you can see from the output of our tar command, the contents of the archive include a README file. Although this time we have a README file, other programs might include an INSTALL file or any other type of instructions. I suggest taking a look at these files prior to blindly attempting to compile. This might seem to be a skippable step to a seasoned administrator but these files can also inform you of any pre-install steps you need to take. It's always a pain in the rear but it's better to read before than to read it afterwards when you are trying to figure out why something went totally wrong. root@slackware:/usr/local/src/chkrootkit-0.48# more README The readme file contains a breakdown of what it is, what it does, how to compile, how it works, and past modifications in the changelog. The part we are interested in can be found in section 5 of the README. 5. Installation
---------------
To compile the C programs type:
# make sense
After that it is ready to use and you can simply type:
# ./chkrootkit That is as easy as it gets. A single command will compile the files we need. The make command takes one command line argument "sense". Make will then check out all prerequirements and compile the program as long as our systems meets the requrements. The make command is almost always used to compile programs from source. Typically the source installation will be ./configure, make, make install. This example however only has a single call to make which we will now execute from within the /usr/local/src/chkrootkit-0.48 directory. root@slackware:/usr/local/src/chkrootkit-0.48# make sense
gcc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c
gcc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c
gcc -DHAVE_LASTLOG_H -D_FILE_OFFSET_BITS=64 -o ifpromisc ifpromisc.c
gcc -o chkproc chkproc.c
gcc -o chkdirs chkdirs.c
gcc -o check_wtmpx check_wtmpx.c
gcc -static -o strings-static strings.c
gcc -o chkutmp chkutmp.c From the output of the make sense command we can see that gcc has been used to compile the programs needed. after completion of the make sense command we have a few more executable files (binaries) located in our current directory. Prior the running the make command we only have one executable file in the chkrootkit-0.48 directory named chkrootkit. Now that make has ran and gcc compiled everything we need our directory contains a few new executable binary files. We now have check_wtmpx, chkdirs, chklastlog, chkproc, chkutmp, chkwtmp, ifpromisc, and strings-static. These new executable files are the result of gcc compling the .c code in our directory. These new files will perform various tasks that are needed by the chkrootkit program. As we were told earlier, in order to run chkrootkit, we have to perform the command ./chkrootkit. root@slackware:/usr/local/src/chkrootkit-0.48# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not infected
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not infected
Checking `gpm'... not infected
Checking `grep'... not infected
Checking `hdparm'... not found
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not tested
Checking `inetdconf'... not infected
Checking `identd'... not infected
Checking `init'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not found
Checking `mingetty'... not found
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not infected
Checking `rshd'... not infected
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `syslogd'... not infected
Checking `tar'... not infected
Checking `tcpd'... not infected
Checking `tcpdump'... not infected
Checking `top'... not infected
Checking `telnetd'... not infected
Checking `timed'... not infected
Checking `traceroute'... not infected
Checking `vdir'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for LOC rootkit... nothing found
Searching for Romanian rootkit... nothing found
Searching for Suckit rootkit... nothing found
Searching for Volc rootkit... nothing found
Searching for Gold2 rootkit... nothing found
Searching for TC2 Worm default files and dirs... nothing found
Searching for Anonoying rootkit default files and dirs... nothing found
Searching for ZK rootkit default files and dirs... nothing found
Searching for ShKit rootkit default files and dirs... nothing found
Searching for AjaKit rootkit default files and dirs... nothing found
Searching for zaRwT rootkit default files and dirs... nothing found
Searching for Madalin rootkit default files... nothing found
Searching for Fu rootkit default files... nothing found
Searching for ESRK rootkit default files... nothing found
Searching for rootedoor... nothing found
Searching for ENYELKM rootkit default files... nothing found
Searching for common ssh-scanners default files... nothing found
Searching for suspect PHP files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... chkproc: nothing detected
chkdirs: nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... eth0: not promisc and no PF_PACKET sockets
eth1: not promisc and no PF_PACKET sockets
Checking `w55808'... not infected
Checking `wted'... chkwtmp: nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... chklastlog: nothing deleted
Checking `chkutmp'... chkutmp: nothing deleted
The above output is displayed to use when the ./chkrootkit command is executed. One thing to note is the fact that when we are executing ./chkrootkit we are in the /usr/local/src/chkrootkit-0.48 directory. If you attempt to run the chkrootkit command from outside the chkrootkit-0l48 directory you will see a few errors in the output. The errors will be similar to the following text. Checking `sniffer'... not tested: can't exec ./ifpromisc
Checking `w55808'... not infected
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp
The reason we see the not tested: can't exec errors is because the chkrootkit program expects to find these executables in the same directory it is running from "./". This is one complaint that I have with this particular program. The current directory reference effectively forces me to change working directories to chkrootkit-0.48. Even if I have copied the chkrootkit file to /usr/sbin it will still look for these other executable files in my current working directory. If I copy the chkutmp file into /usr/sbin/ alongside chkrootkit, chkrootkit will still not be smart enough to find these other programs that it relies upon. Since chkrootkit will always call the sub-programs by referencing current directory/program-name we can't just move our binary files and call it quits. We can move the files all we want but it will not run the sub-programs unless they reside in the same directory as our current session. To overcome this limitation of the chkrootkit program we will have to work a bit of magic. This "magic" can be ignored if you want to remember to change directories to /usr/local/src/chkrootkit-0.48 every time you run chkrootkit. This is an acceptable way to use chkrootkit but the beautiful thing about compiling from source is the fact that I can put my programs anywhere I would like to on this system. It's nice to take the easy way out but I like to "clean up" my build directories after I have compiled the source code. The workaround that I have created for this situation goes like this... I want to standardize the location that I will use for my chkrootkit program. I already know I am going to have to always change directories into this location before executing the chkrootkit command. What I am going to do is create a new directory that will house my chkrootkit binary files. Then I am going to move all the executables from the build directory /usr/local/src/chkrootkit-0.48 into my new program directory. After that is complete, I will then write a wrapper script to put in the /usr/sbin directory that will essentially change working directories into the newly created program directory and then proceed to execute the chkrootkit. You could just write a script that first cd's into /usr/local/src/chkrootkit-0.48 before executing the chkrootkit command but what's the fun in that. Here I will create the /usr/local/chkrootkit to house my latest binaries for version 0.48 of chkrootkit. In the future, I will compile the next version and replace the binaries in /usr/local/chkrootkit with the latest versions. Our wrapper script will be /usr/sbin/chkrootkit that will always change directories into /usr/local/chkrootkit before running the application. So lets get started... root@slackware:~# cd /usr/local
root@slackware:/usr/local# mkdir chkrootkit
root@slackware:/usr/local# cd src/chkrootkit-0.48/ We have changed into /usr/local and created a chkrootkit directory. Next we move into src/chkrootkit-0.48 which is our build directory. In order to move all the executable files in one swoop I will be using a for loop from the command line. For more information on the for loop and various uses you can look at the Shell Based Scenarios article located HERE The following command will move our binary files into /usr/local/chkrootkit. root@slackware:/usr/local/src/chkrootkit-0.48# for i in `ls -al | egrep '^-rwx' | awk ' { print $8 } ' | cut -d "*" -f1`
> do
> mv $i /usr/local/chkrootkit/
> done A quick listing of the /usr/local/chkrootkit directory shows us all of our binary files have been successfully moved. root@slackware:/usr/local/src/chkrootkit-0.48# ls /usr/local/chkrootkit
check_wtmpx* chkdirs* chklastlog* chkproc* chkrootkit* chkutmp* chkwtmp* ifpromisc* strings-static*
We have put the files where we wanted to put them. Now that we have our files placed where we desire, it's time to do a little system cleanup. We will be removing the build directory /usr/local/src/chkrootkit-0.48 and also deleting the tarball that was used, and the md5 hash we had previously downloaded.
root@slackware:/usr/local/src/chkrootkit-0.48# cd ..
root@slackware:/usr/local/src# rm -rf chkrootkit-0.48/
root@slackware:/usr/local/src# rm chkrootkit.tar.gz
root@slackware:/usr/local/src# rm chkrootkit.md5
The files and directories used to build our binary files have now been removed from our system. This step not only helps us keep our system clean, it can also create more work for any hacker who might compromise our system. If a hacker somehow accesses your system and loads a rootkit, he can then proceed to modify the source code for the chkrootkit program and recompile the binaries. Then, when you go into the directory and run chkrootkit, the system reports it is not infected when infact that is just not true. By removing source code and placing our binaries in non standard locations it can help protect our system integrity. It's alot more work to find, download, patch, and install compromised executables than it would be to simply modify existing source and recompile. The final steps we will be performing is the creation of a wrapper script and some permission changes. The first task is creating a wrapper script. I will be creating a script called chkrootkit in the /usr/sbin directory. The script needs to contain the following... root@slackware:/usr/local/src# more /usr/sbin/chkrootkit
#!/bin/sh
####################################
# CHKROOTKIT WRAPPER
####################################
CHKROOTKIT_DIR=/usr/local/chkrootkit
export CHKROOTKIT_DIR
####################################
cd $CHKROOTKIT_DIR
./chkrootkit
You can then call chkrootkit from any directory on your system. The wrapper will then change working directories to /usr/local/chkrootkit prior to executing the chkrootkit script. Once chkrootkit begins examining your system, it will be able to find the other programs it depends upon, when fully checking out your system. The next time chkrootkit releases a new version, we can download it, verify the download, unpack, build, move our binaries into /usr/local/chkrootkit, remove the build directory, and remove the tarball. The wrapper script will continue to work with our current setup. The last thing we will be doing is performing a few modifications to the file permissions.
root@slackware:/usr/local# chmod 500 /usr/sbin/chkrootkit
root@slackware:/usr/local# ls -al /usr/sbin/chkrootkit
-r-x------ 1 root root 234 2008-03-20 23:23 /usr/sbin/chkrootkit*
root@slackware:/usr/local/# cd /usr/local/chkrookit root@slackware:/usr/local/chkrootkit# chown root:root *
root@slackware:/usr/local/chkrootkit# chmod 500 * root@slackware:/usr/local/chkrootkit# cd ..
root@slackware:/usr/local# chmod 700 chkrootkit
The first command listed will change the permissions of our wrapper script so that root is the only user who can read or execute /usr/sbin/chkrootkit. The next thing we do is change directories into /usr/local/chkrootkit. We then change ownership for the user and group to root:root. After the ownership change is complete we will modify the permissions of all the files in the directory so that only the root user can read or execute any script or binary located in that directory. For good measure we change directories to /usr/local and apply permissions that will block out any non root users. In summary, this installation was lengthier than it needed to be. However, building from source gives us the freedom to do whatever we want however we want. These customized steps will make your setup unique and help you create gotchas for any hacker who gains access to your system. If you were really paranoid you could rename chkrootkit to something else entirely. It could be an ls command in /usr/local/bin if you so desired. The more customization you perform, the harder it will be for someone to covertly access your system without alerting you. Although I did things this way, you could do them any way you want, that's the coolest thing about building from source! This concludes our installation of chkrootkit. I hope this information will help you get started not only building from source but also custom tailoring your installation to fit your needs, whatever they might be. If you found this article informative and useful, support us by clicking on our advertising. Until next time - Mr Oss |
