User: Password:
Subscribe / Log in / New account


Interview with Rootkit Hunter author Michael Boelen

September 29, 2004

This article was contributed by Joe Klemmer

One of the greatest joys we Linux users have is to say to our Windows-running friends, family and co-workers that we do not suffer from viruses like they do. However, the reality is that we aren't immune from being attacked. There are plenty of nasty things out there that would be happy to trash our systems. One of these nasty things is something called a rootkit. Rootkits allow a cracker to ensure future access to a compromised system while hiding the evidence from administrators and users; see LWN's look at the Adore rootkit for an example.

So how do you detect them? One way is to use the tool Rootkit Hunter. The following is an interview with the author of this utility, Michael Boelen.

Joe Klemmer: Tell us a bit about yourself. Who is Michael Boelen?

Michael Boelen: I'm a 22 years old guy, working for a small company (small webhosting, maintaining servers/services and application development). My task it to maintain the internal servers and perform administration for our customers. I live in The Netherlands at my parents. Computers are my hobby and my work, so I'm the author of Rootkit Hunter :-)

My main interests are networking, hardware, security and small application development. As many people, I like to read, but especially interested in computer related stuff.

JK: What led you into system security?

MB: It's a special part of computer services, which attracts me because it's never the same. It's a dynamic world inside the big computer world. Although a lot of companies aren't aware of the consequences of (a missing plan for) security, I think it's a very important part. That's why almost everyone in the computer world will use/need some security enhancements sooner or later. In my case, open relays, Trojans and viruses were the first signals to have a better look at security.

JK: What, specifically, are rootkits?

MB: Rootkits are often little packages with some binaries, some sources and an easy-to-use installer. These packages are being created to 'stay root' after a successful comprise of a host. The installer in these packages do check the host and replaces the default binaries with the one in the package. Most times these are binaries like 'ps', 'ls', 'top', 'netstat', where traces of the hacker/cracker/scriptkiddie are being filtered, with one purpose: hide evil processes, network connections etc.

Because rootkits are unwanted and difficult to find without good searching, automated tools are being created. Although an UNIX specialist is often able to find bad things better/quicker than automated tools, it can be a very valuable tool. Of course it is a nice addition to UNIX specialists, but also for average UNIX users which aren't able to find out with things of a UNIX system are good or evil (like hidden files, bad strings, not usual network ports etc).

JK: You've said elsewhere that you built rkhunter because you didn't find the existing tools to your liking. What was it about them that you felt needed changing?

MB: The lack of active development is the most important one. I won't say my tool is better than the others, but I try to maintain it as active as possible. When users come with (nice) new ideas, most times I try to implement it as soon as possible.

JK: Over the course of rkhunter's evolution, have you found anything interesting about root kits? Any similarities or differences? Are there any trends?

MB: Yes, a lot of interesting information. I also have a better idea now (since the development) why hackers/crackers/scriptkiddies use rootkits and what to do to detect them. The most difficult part is to maintain an utility which keeps smart enough to detect suspicious traces on a system.

Most tools use the same approach, so I tried to combine as many as possible ways to detect these suspicious traces. And although it gets better every release, a lot of things have to be done.

Rootkits don't have a 'normal' trend like viruses/worms have, because viruses aren't often used for a single person to achieve his goal (beside breaking up systems, sending spam or planting a trojan). In fact, some individuals create rootkits for their needs at the moment they need them. These custom made rootkits contain often simple things like IRC bots, backdoors and sniffers. Within the next few months, those things will be getting special attention from me and added to Rootkit Hunter. Rootkits won't quickly disappear, so the war isn't yet over.

JK: Do you know if rkhunter has had an impact on the root kit community? Are they now trying to design kits to work around rkhunter?

MB: I have really no idea, because most rootkits and backdoors are still being used by individuals and use private parts (although there are a lot of often used public tools). So I haven't seen any tools yet, which are build to hide for Rootkit Hunter. But I'll guess there will be variants already available.

JK: I would guess that the battle between the root kit "developers" and the security community is similar to the anti-virus wars. Is the bulk of your work spent in catching up to new root kits? Or are you in a position of developing preemptive technologies to head off the kit builders?

MB: On both ways, because maintaining a 'rootkit hunter' is almost similar to maintaining an anti-virus tool, with one exception, viruses aren't made to be hidden for the system (yet?). So anti-virus developers try to discover as quick as possible new (unknown) viruses. The approach on rootkits is a little bit different. It means also adding unknown rootkits, but more important, adding new ways to discover all kinds of hack traces.

JK: What do you see for the future of rkhunter? With the advent of SElinux will there still be a need for rkhunter and it's kind?

MB: I guess tools like this one, won't be quickly useless, because even if you have a secured system (like with SElinux and all other kernel and application improvements), it's always possible someone breaks your system. At that stage, tools like Rootkit Hunter (and the few others) can provide an administrator very useful information.

This interview gives me the opportunity to ask people an easy question: If you find something interesting for me, can you send it to me?

The question above gives an answer to your question, because although I can improve Rootkit Hunter a lot, I really need input from the users and the guys on the field. Rootkits, sniffers, ideas and even books are needed to keep on improving. Till now I have already got a lot of input, but I still need more information. So have a simple thought about the future: it only will be better, but only if I get support from the community!

Comments (3 posted)

New vulnerabilities

apache: protected pages vulnerability

Package(s):apache CVE #(s):CAN-2004-0811
Created:September 23, 2004 Updated:September 29, 2004
Description: Apache 2.0.51 may allow the viewing of protected pages because of a problem merging the Satisfy directive.
Gentoo 200409-33 apache 2004-09-24
Trustix TSLSA-2004-0049 apache 2004-09-23

Comments (none posted)

getmail: filesystem overwrite vulnerability

Package(s):getmail CVE #(s):CAN-2004-0880 CAN-2004-0881
Created:September 23, 2004 Updated:October 4, 2004
Description: Getmail has a vulnerability that may allow a local user to create or overwrite files in any directory on the system.
Slackware SSA:2004-278-01 getmail 2004-10-04
Debian DSA-553-1 getmail 2004-09-27
Gentoo 200409-32 getmail 2004-09-23

Comments (none posted)

jabberd: remote denial of service vulnerability

Package(s):jabberd CVE #(s):
Created:September 23, 2004 Updated:September 29, 2004
Description: Jabberd's XML parsing routines have a vulnerability that may be exploited to create a remote denial of service.
Gentoo 200409-31 jabberd 2004-09-23

Comments (none posted)

sendmail: pre-set password

Package(s):sendmail CVE #(s):CAN-2004-0833
Created:September 27, 2004 Updated:September 29, 2004
Description: Hugo Espuny discovered a problem in sendmail, a commonly used program to deliver electronic mail. When installing "sasl-bin" to use sasl in connection with sendmail, the sendmail configuration script use fixed user/pass information to initialize the sasl database. Any spammer with Debian systems knowledge could utilize such a sendmail installation to relay spam.
Debian DSA-554-1 sendmail 2004-09-27

Comments (none posted)

subversion: metadata information disclosure

Package(s):subversion CVE #(s):CAN-2004-0749
Created:September 23, 2004 Updated:November 4, 2004
Description: The subversion version control system has vulnerabilities in the handling of metadata such as log file entries related to using mod_authz_svn.
Conectiva CLA-2004:883 subversion 2004-11-04
Gentoo 200409-35 subversion 2004-09-29
Fedora FEDORA-2004-318 subversion 2004-09-23

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Kernel development>>

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds