A BSD Rootkit Primerby Federico Biancuzzi
The first book on BSD Rootkits was recently published. Federico Biancuzzi interviewed the author, Joseph Kong, to learn more about the dark art of kernel voodoo...
Could you introduce yourself?
Joseph Kong: I am a relatively young (24 years old) self-taught computer enthusiast who enjoys working (or playing, depending on how you look at it) in the field of computer security; specifically, at the low-level. In the past I have contributed to Phrack Magazine, and I just recently finished writing my first book (Designing BSD Rootkits) published by No Starch Press.
Interested readers can find more information about me at thestackframe.org.
When did you hear about rootkits for the first time?
Joseph Kong: The first time I heard the term "rootkits" was in 2004--straight out of the mouth of Greg Hoglund, who was at the time promoting his new book Exploiting Software: How to Break Code. That's actually how I got into rootkit programming. Thanks Greg. :)
Why did you choose to write a book about BSD rootkits?
Joseph Kong: Frankly, because I wanted to fill an information gap. There is a lot of documentation regarding Windows and Linux systems programming (which is the basis for kernel-mode rootkits), but not as much documentation regarding *BSD systems programming. Also, at the time of this writing, I believe there are four different books on Windows rootkits and one on Linux rootkits.
However, if you want a really simple answer, it's because I like rootkits (for any OS) and I like FreeBSD.
Is the book focused on FreeBSD only?
Joseph Kong: The book is focused on FreeBSD, however, the methods covered will work on other OSes.
Do you have any experience or story to share about rootkits hunting?
Joseph Kong: It's hard. This is because if you are hunting a "real" rootkit (i.e., one that's not publicly available), you won't know what technique(s) it employs or which functions/objects it manipulates. Thus, you have to, more or less, validate the integrity of your entire system--and that's no small task.
This might be a bit off topic, but, this is why most rootkit detectors are signature based. It's just that much easier (in fact, it's rather trivial) to detect a rootkit when you know exactly what it's going to do.
Do you know any anti-rootkit tool/product for *BSD?
Joseph Kong: I know of two tools to detect rootkits on *nix-based (or derived) systems. They are chkrootkit, which is available in the FreeBSD ports collection, and Rootkit Hunter. Both of these tools are, more or less, signature based detectors, which makes them fairly lightweight. Also, they are both pretty easy to use.
Personally, and this isn't an attack against these tools or authors (as I respect the authors tremendously for their unpaid work), but I find these tools to be somewhat behind the curve (e.g., they don't detect some of the most common system call hooks). Of course, this isn't their fault, as there aren't a lot of security researchers dedicated to exposing *nix-centric rootkits.
As an aside, keep in mind that signature based detection, in general, will never be able to detect something (e.g., a rootkit, virus, or worm) that it doesn't have a "signature" for.
Along similar lines, I know a lot of people who refer to rootkits and rootkit-detectors as being in a big game of cat and mouse. However, it's really more like follow the leader--with rootkit authors always being the leader. Kind of grim, but that's really how it is. Until someone reveals how a specific (or certain class of) rootkit works, nobody thinks about protecting that part of the system. And when they do, the rootkit authors just find a way around it. This is what I meant earlier when I said rootkit hunting is hard--as you really have to validate the integrity of the entire system.
Are you working with FreeBSD guys to implement anti-rootkits measures?
Joseph Kong: In short, no. The interesting thing about rootkits is that, in general, every technique that a kernel-mode rootkit employs is a legitimate system building technique. For example, run-time kernel memory patching (or as Microsoft calls it, hot patching) can be used to legitimately or illegitimately patch a running system. The problem is, when a user gains root access, the system can't tell whether a request to augment the kernel is legitimate or not. Also, pretty much every anti-rootkit measure has been circumvented (although I am a fan of secure levels).
In my opinion, currently, the best anti-rootkit measure is prevention. That is, if you can prevent an unauthorized user from gaining root access, all the rootkits in the world won't help him/her. In this sense, I believe the OpenBSD methodology of fixing every bug (big or small), code auditing, secure by default, and so on, is the best course. And I believe that every system builder already knows this (they're just not all vocal about it).
Keep in mind that although I am extolling the virtues of prevention, as other computer security professionals (such as, Richard Bejtlich) have said, prevention eventually fails (e.g., Loïc Duflot showed that you can bypass secure levels in SMM), and detection is just as important. The problem is rootkit detection, as I said earlier, is difficult.
(Joanna Rutkowska presented an interesting idea for rootkit detection/OS verification back in December 2006.)
Do TrustedBSD extensions help us defending our systems?
Joseph Kong: Of course; that is their design goal after all.
I think the event auditing extension (which was included into the FreeBSD base system as of 6.2) is really useful. It allows you to log a variety of events, which can then be used for postmortem analysis or intrusion detection.
Also, the Mandatory Access Control (MAC) extension has a policy, I think, that lets you sign executables and prevents non-signed executables from running.
(I haven't played around with the MAC extension too much, but this is what John Baldwin tells me. Thanks John.)
Is there anything that a FreeBSD sysadmin should do to reduce the risk of getting rootkits in his boxes?
Joseph Kong: If you don't require KLD support, then of course you can disable it; which just requires you to raise the secure level to 1 or higher. (This is akin to disabling unnecessary services.) You can also "secure" your applications with jails.
If you haven't looked through it yet, the FreeBSD Handbook Chapters 14-17 provide some good (general purpose) information on how to harden your system.
FreeBSD keeps stable kernel ABIs in release branches. I am wondering if this means that a kernel rookit would just have to be developed for a particular major release (ie 6.0) and it will work on every following releases (6.1, 6.2,...).
Joseph Kong: Well that really depends on what your rootkit is trying to do, and whether or not there are any major changes to the OS's internals between releases. For example, if your rootkit was trying to patch some object, and that object's data structure changed between releases, your rootkit might break. From my personal experience, everything I have written for 6.0 runs perfectly under 6.1 and 6.2. Of course, this is probably because FreeBSD doesn't really change too much between STABLE releases. (However, the differences between STABLE and CURRENT sometimes are pretty drastic.)
Pages: 1, 2