Security [LWN.net]

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.

Alerts:

Gentoo	200409-33	2004-09-24
Trustix	TSLSA-2004-0049	2004-09-23

Security

Interview with Rootkit Hunter author Michael Boelen

apache: protected pages vulnerability

getmail: filesystem overwrite vulnerability

jabberd: remote denial of service vulnerability

sendmail: pre-set password

subversion: metadata information disclosure

Apache mod_proxy: denial of service

apache2: stack-based buffer overflow in ssl_util.c

aspell: bounds checking problem

cdrecord: failure to drop privilege

cups: denial of service

Filename disclosure vulnerability in fam

flim: insecure file creation

Foomatic: Arbitrary command execution in foomatic-rip

FreeRADIUS: denial of service

Gaim: remote code execution vulnerability

gtk2, gdk-pixbuf: buffer overflows

glFTPd: Local buffer overflow vulnerability

glibc: Information leak with LD_DEBUG

gnome-vfs: backend script vulnerabilities

gtkhtml: malformed messages cause crash

heimdal: root escalation

httpd: mod_ssl input filter denial of service vulnerability

apache2: IPv6 denial of service

imagemagick: buffer overflow vulnerability

imlib2: buffer overflows

iproute: local denial of service

kdebase: multiple vulnerabilities

kernel allows unauthorized changes to the group ID

kernel information leak

kernel-utils: setuid vulnerability

lha: stack-based buffer overflow

libpng: multiple vulnerabilities

libxml2 - arbitrary code execution

libxpm4: stack and integer overflows

logcheck: symlink vulnerability

Midnight Commander: extfs vfs vulnerability

mikmod: buffer overflow

mod_python: denial of service vulnerability

mozilla products: arbitrary code execution and other vulnerabilities

mpg123: buffer overflow bug

mpg321: format string vulnerability

neon: buffer overflow

netpbm: insecure temporary files

OpenOffice: information disclosure

openssh: timing attack leads to information disclosure

OpenSSL: denial of service vulnerabilities

pavuk: buffer overflow

php: remotely exploitable memory errors

phpGroupWare: cross site scripting vulnerability

PuTTY: pre-authentication arbitrary code execution problem

python: buffer overflow

qt3: BMP image parser heap overflow

rsync: path-sanitizing bug

ruby: insecure file permissions

Samba: Denial of Service vulnerabilities

SnipSnap: HTTP errors

sox: buffer overflow

SpamAssassin: Denial of Service vulnerability

squid: buffer overflow

SquirrelMail cross site scripting vulnerabilities

Subversion: Remote heap overflow

sysstat: temporary file vulnerability

File overwrite vulnerability in tar and unzip

tcpdump: ISAKMP payload handling denial-of-service vulnerabilities

Multiple vendor telnetd vulnerability

Webmin, Usermin: Multiple vulnerabilities in Usermin

wv: buffer overflow

XChat 2.0.x SOCKS5 Vulnerability

xine-lib: buffer overflows

xine-ui - insecure temporary file creation

zlib: denial of service