Interview with Rootkit Hunter author Michael Boelen
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?
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?
JK: What, specifically, are rootkits?
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?
JK: Over the course of rkhunter's evolution, have you found anything interesting about root kits? Any similarities or differences? Are there any trends?
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?
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?
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?
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!
Index entries for this article | |
---|---|
GuestArticles | Klemmer, Joe |
Posted Sep 30, 2004 10:20 UTC (Thu)
by dps (guest, #5725)
[Link]
Brute force the remainder of the system calls that take a process id generates a real process list. The fact that kill() gives different results is a definite evidence of fun and games. Note that this method also reveals the real infomration inside various forms of sandbox.
Once you have a good process lsit you can then determine a real connection list via /proc/<pid>/fd/*, even if <pid> is something that is hidden. Comaprison with ps output would tell you than your system has been owned.
checkps, my background version of this, can also stop or kill the hidden processes with using ptrace if you ask it to and most of a netstat test is also included. I am open to offers if to maintain this beast.
Generic logic is also included in chkrootkit (albeit less exhaustive logic). A good default deny firewall is also effective against many remote access tools, especially if it implements fascism in both directions.
Posted Oct 8, 2004 1:05 UTC (Fri)
by accensi (guest, #11754)
[Link] (1 responses)
> When I run chkrootkit, I see some problems, here they are :
Actually they are not necessarily .png files. They can be anything supported by gtk2's image loader (svg, xpm, jpeg, ...) Therefore adding a .png extension would be misleading in many cases.
The question is why does chkrootkit think they are suspicious?
!?!
Posted Oct 20, 2004 9:28 UTC (Wed)
by mmacok (guest, #20088)
[Link]
The AV approach to rootkits is probably the least effective one. Instead you can construct broad-spectrum tools that look for the *effects* of root kits. In the case of adore, it only patches kill() and access via /proc. If netstat and ps output are not falsified one wonders how protective the rootkit is.The Anti-Virus approach to rootkits
Speaking in rootkits, seen today in ROX devel list:Interview with Rootkit Hunter author Michael Boelen
> Searching for suspicious files and dirs, it may take a while...
> /usr/lib/apps/AbiWord/.DirIcon /usr/lib/apps/Emacs/.DirIcon
> /usr/lib/apps/GMix/.DirIcon /usr/lib/apps/GQView/.DirIcon
...
> /usr/lib/apps/Mandrake/Système/Terminaux/.DirIcon
> /usr/lib/apps/Mandrake/Système/Terminaux/Eterm/.DirIcon
> /usr/lib/apps/Mandrake/Système/Terminaux/X Term/.DirIcon
>
> As you can see, .DirIcon files are considered by chkrootkit as suspicious.
> After a little search I found that these files are frome the Rox RPM
> package, so I am reporting what I believe as a bug. As .DirIcon files are
> PNG pictures, why are they not in "file.png" format ?
Maybe all "hidden" files (name starting with a dot) in /usr are suspicious? (my guess)chkrootkit