Consider this scenario... Your machine running GNU/Linux has been penetrated by a hacker without your knowledge and he has swapped the passwd program which you use to change the user password with one of his own. His passwd program has the same name as the real passwd program and works flawlessly in all respects except for the fact that it will also gather data residing on your machine such as the user details each time it is run and transmit it to a remote location or it will open a back door for outsiders by providing easy root access and all the time, you will not be aware of its true intention. This is an example of your machine getting rooted - another way of saying your machine is compromised. And the passwd program which the hacker introduced into your machine is a trojaned rootkit.
A rootkit is a collection of tools a hacker installs on a victim computer after gaining initial access. It generally consists of network sniffers, log-cleaning scripts, and trojaned replacements of core system utilities such as ps, netstat, ifconfig, and killall.
Hackers are not the only ones who are found to introduce rootkits in your machine. Recently Sony - a multi billion dollar company, was found guilty of surreptitiously installing a rootkit when a user played one of their music CDs on Windows platform.This was designed *supposedly* to stop copyright infringement. And leading to a furore world wide, they withdrew the CD from the market.
Detecting rootkits on your machine running GNU/Linux
I know of two programs which aid in detecting whether a rootkit has been installed on your machine. They are Rootkit Hunter and Chkrootkit.
Rootkit Hunter
This script will check for and detect around 58 known rootkits and a couple of sniffers and backdoors and make sure that your machine is not infected with these. It does this by running a series of tests which check for default files used by rootkits, wrong file permissions for binaries, checking the kernel modules and so on. Rootkit Hunter is developed by Michael Boelen and has been released under a GPL licence.
Installing Rootkit Hunter is easy and involves downloading and unpacking the archive from its website and then running the installer.sh script logged in as root user.
Fig: Rootkit Hunter checking for rootkits on a Linux machine.Once installed, you can run rootkit hunter to check for any rootkits infecting your computer using the following command:
# rkhunter -cThe binary rkhunter is installed in the /usr/local/bin directory and one needs to be logged in as root to run this program. Once the program is executed, it conducts a series of tests as follows :
- MD5 tests to check for any changes
- Checks the binaries and system tools for any rootkits
- Checks for trojan specific characteristics
- Checks for any suspicious file properties of most commonly used programs
- Carries out a couple of OS dependent tests - this is because rootkit hunter supports multiple OSes.
- Scans for any promiscuous interfaces and checks frequently used backdoor ports.
- Checks all the configuration files such as those in the /etc/rc.d directory, the history files, any suspicious hidden files and so on. For example, in my system, it gave a warning to check the files /dev/.udev and /etc/.pwd.lock .
- Does a version scan of applications which listen on any ports such as the apache web server, procmail and so on.
After all this, it outputs the results of the scan and lists the possible infected files, incorrect MD5 checksums and vulnerable applications if any.
Fig: Another screenshot of rootkit hunter conducting a series of tests.On my machine, the scanning took 175 seconds. By default, rkhunter conducts a known good check of the system. But you can also insist on a known bad check by passing the '--scan-knownbad-files' option as follows :
# rkhunter -c --scan-knownbad-files As rkhunter relies on a database of rootkit names to detect the vulnerability of the system, it is important to check for updates of the database. This is also achieved from the command line as follows:
# rkhunter --updateIdeally, it would be better to run the above command as a cron job so that once you set it up, you can forget all about checking for the updates as the cron will do the task for you. For example, I entered the following line in my crontab file as root user.
59 23 1 * * echo "Rkhunter update check in progress";/usr/local/bin/rkhunter --updateThe above line will check for updates first of every month at exactly 11:59 PM. And I will get a mail of the result in my root account.
Chkrootkit
This is another very useful program created by Nelson Murilo and Klaus Steding Jessen which aids in finding out any rootkits on your machine. Unlike Rootkit hunter program, chrootkit does not come with an installer, rather you just unpack the archive and execute the program by name chrootkit. And it conducts a series of tests on a number of binary files. Just like the previous program, this also checks all the important binary files, searches for telltale signs of log files left behind by an intruder and many other tests. In fact, if you pass the option -l to this command, it will list out all the tests it will conduct on your system.
# chkrootkit -lAnd if you really want to see some interesting stuff scroll across your terminal, execute the chkrootkit tool with the following option:
# chkrootkit -x Rootkit Hunter and Chkrootkit together form a nice combination of tools in ones forte to detect rootkits in a machine running Linux.
Update: One reader has kindly pointed out that Michael Boelen has handed over the Rootkit Hunter project to a group of 8 like minded developers. And the new site is located at rkhunter.sourceforge.net
22 comments:
I think that there is room to mention the well known tools such as AIDA and TripWire and LogCheck.
Maxim.
OSSEC HIDS (http://www.ossec.net) and I think OSSIM (http://www.ossim.net) also have rootkit checkers.
I can't remember the name, but there was also another one that attempted to open every tcp and udp socket, and compared the results to what was publicly available on the system (netstat, lsof, et al). If you can't open the socket, and nothing is listed there, its probably not good!
I too was going to mention Tripwire. The whole point of this application is to make sure someone does not change any of your executables without your knowledge. Snare can also be used to an extent if you set it up to check certain files/executables.
And there are also commercial products; at least F-Secure (http://support.f-secure.com/linuxbeta/) has one. I was quite sure Panda and Trend also had one but couldn't find them now -
linux AV seems to be a well kept secret for all AV vendors.
And what if rootkit can modify the root kit hunter script? :) Wouldnt it be better to check the system offline?
Keep in mind that AIDE (the free replacement for Tripwire) although an excellent program, must be installed and configured on a known-clean system before it will be useful in detecting a rookit intrusion.
The tools mentioned in the post are designed for post-infection analysis.
Another thing to keep in mind is that you can't be 100% certain of the scan results when running these tools on a possibly trojaned machine. The best idea is to bring the machine down and scan it from a live CD (for example Auditor) or place the disks in another known clean system and run the tools from there.
Keep up the good work, even Linux users need to be aware that running Linux alone is not the end of the security process.
And what if rootkit can modify the root kit hunter script? :) Wouldnt it be better to check the system offline?
Usually the procedure is to burn the chrootkit or rootkit hunter or whatever to a CD and then run the program from the CD or a read only medium. So the question of the script being replaced by a rootkit is at the least very difficult.
Uhh... what about mtree(1)?
Note that development of Rootkit Hunter is no longer being done by Michael Boelen, so your link is out of date. It can now be found at: http://rkhunter.sourceforge.net/
Not so difficult to bypass the rootkit checker on a read only medium. When you do:
% /cdrom/chrootkit
the shell has to start that binary. If that part of the OS is also a trojan it can recognize an attempt to run one of the handful of known rootkit checkers and then emulate their output. (Ironically using
more or less the same sort of pattern matching techniques that the rootkit checkers themselves employ.) The hacked OS will arrange that "ps -ef" shows /cdrom/chrootkit
when in fact what's running is:
/you_are_so_hacked/chrootkit_emulator.
So read only media offers very little protection on a hacked system. You need to boot from a CDROM and then run rootkit checker from that environment (and not from a copy you had on a hard disk on the compromised system!)
This is quite interesting info. I didn't know we were so vulnerable as to getting backdoors open and info sent out to remote locations that easily. I figure this much: once someone has initial access, which is the first step in putting rootkits in a computer system, basically anything can be done from there. I guess i'll be testing this on my machine, before i go ahead and perform that at work.
Any problems or info i should know on which distros to run this tools before performing them? I use kubuntu, red hat and fedora core. Are there any issues on these 3 distros?
> Usually the procedure is to burn the chrootkit or rootkit hunter or whatever to a CD and then run the program from the CD or a read only medium. So the question of the script being replaced by a rootkit is at the least very difficult.
No, this is wrong. It wouldn't work.
It doesn't matter where you run the program from, read-only media or not. The rootkit would still be in control of all of the interactions between the root kit detector and the compromised box.
You might answer that *then* the answer is to *boot* from read-only media. That would be better, but not be perfect. You'd just need to find the loader that gets the rootkit into ram then.
> This is quite interesting info. I didn't know we were so vulnerable as to getting backdoors open and info sent out to remote locations that easily.
Err - Linux isn't, unless you run untrusted binaries (particularly as root).
okay, so it seems there is room for a live distro that checks for rootkits and viruses, from an updated database of course. is there any such distro?
alternatively, to not reboot the system, isn't it possibile to fire up a known clean virtual machine that checks for rootkits?
my 2cts
As both tools are very good tools for detecting rootkits on Linux I believe everyone has touched on the fact that in order to provide security and file protection in Linux other tools like tripwire are needed. I use rkhunter in some of my forensics along with livecd's such as helix which provides quite a few forensics toolkits. In order to understand rootkits and malware you have to watch it work first hand...try nepenthes honeypot for malware analysis.
Err - Linux isn't, unless you run untrusted binaries (particularly as root).
Or if a service is compromised via either an unpatched vulnerability or a zero day.
AFICK is much faster than AIDE, and easier to setup. It's worth checking out.
What about built-in package verification? RPM, Portage, whatever can do exactly that - check if package files are OK. The tools described create a dangerous illusion of better safety, while in fact a removable read only bootable storage is necessary to check if RPM or whatever tool used to verify package integrity is intact.
Huumm, very interesting article. But, I am wondering. If I use AIDE, every time I would check my files, should I reboot the machine with a 'clear' boot? If in a 'socracked' system the use of a ROM media is enough, is my guess correct?
It is very complicated to reboot 'servers'.
Thank you.
Just something to note:
From time to time people complain about the Linux/UNIX standard filesystem and how segregating executables and their config/data files in their own directories is "inconvienient" and leads to disorganization.
However, having all executables, particularly system executables in known locations (/sbin, /bin) means you can give those directories their own partitions. After you have your programs installed, you can then remount such partitions as READ ONLY, which would easily prevent replacing the executables without breaking anything else.
This would be more difficult or impossible if the executable and its data were in the same directory.
Just another thing to keep in mind.
They are "crackers" NOT hackers.
Good article for, nice tips.
Post a Comment