Slashdot Mirror
Rootkits: Subverting the Windows Kernel
nazarijo (Jose Nazario) writes "A group of people out there, let's call them 'elite hacker d00ds,' are
able to skillfully craft Windows rootkits that evade almost any known detection
system. Some people want to know how this is done, be they aspiring
elite hackers, security professionals who have to try and find these
rootkits, or just interested parties. If you're one of them, Grog Hoglund
and James Butler's new book, Rootkits: Subverting the Windows
Kernel is for you. It's focused like a laser on how to defeat
detection at various levels in the Windows OS once you're in." Read on for the rest of Nazario's review.
Rootkits: Subverting the Windows Kernel
author
Grog Hoglund and James Butler
pages
352
publisher
Addison-Wesley Longman
rating
9
reviewer
Jose Nazario
ISBN
0321294319
summary
A highly technical tour of how to develop and detect Windows rootkits
Some may wonder if Hoglund and Butler are being irresponsible by writing a book that shows you how to bypass detection. If you look closely, however, you'll see that all of the methods they outline are detectable by current rootkit revealing mechanisms. And they also show you how to detect many new rootkits in the process. I consider this book to be a responsible contribution to the community, professionals and amateurs alike, in the finest tradition full disclosure.
The book is organized into three major sections, even if it's note explicitly marked as such. The first section serves as an introduction to the topic and some of the high level concepts you'll need to know about Windows, control mechanisms, and where you can introduce your code. The second part is a highly technical tour of the techniques used to hook your rootkit in and hide it, And the third section is really one chapter covering detection of rootkits.
The first few chapters, which serve to introduce the topic, get technical right away. Chapter 2, for example, shows you some basic mechanisms for hooking in your rootkit. If you're getting lost at this point, you'll want to probably augment your reading with a Win32 internals book. The resources listed by the authors, though, are great. By this point you can also see that the writing is clear and the examples contribute perfectly to the topic. Hardware hooking basics are covered in chapter 3, which should give you some indication of the book's pace (quick!).
By the time you get to chapter 4 and discussing how to hook into both userland and the kernel, you're getting at some very valuable material. Although the book focuses on kernel hooking, a brief description of userland hooking is provided. Chapter 5 covers runtime patching, a black art that's not well known. This is almost worth the full price of admission, but the material gets even better.
In chapters 6-9 you get into some serious deep voodoo and dark arts. In these chapters you'll learn the basics of direct kernel object manipulation, layered device drivers (which can save you a lot of work), hardware manipulation, and network handling. All of these are techniques used by rootkit authors to varying degrees and effect, so you should become familiar with them. The code examples are clear and functional, and you'll learn enough to write a basic rootkit in only about 150 pages. Simple keyboard sniffers and covert channels are described in the code examples. Useful stuff.
I can't say I found many errors or nits in the book. There's some problems at times getting the code formatting just right, and what appear to be a few stray characters here and there, but nothing too obvious to me. Then again, I'm not a Windows kernel programmer, so I don't feel qualified to comment on the correctness of the code.
In the finest tradition of using a blog and dynamic website to assist your readers, the authors have set up rootkit.com, which nicely supplements their book. Most of the resources they mention in the book are available here, as well as a great array of contributors and evolving techniques. Without the book the site is still useful, but together they're a great combination. Too many books lose their value once you read them, and some books stay with you because you're having difficulty understanding the authors. Rootkits will stay near you while you develop your skills because it's a lot of material in a small space, and although it's very clearly written, there is a deep amount of material to digest. You'll be working with this one for a while.
My only major wish for this book is for it to have covered detection more significantly. One chapter covers how to detect rootkits, and although you may be able to look for some specific telltale signs of rootkits depending on how they were introduced, a more complete coverage of this approach would have made the book even more worthwhile.
Rootkits is an invaluable contribution in the wider understanding of advanced attack and hacker techniques. Previously, much of this material was known to only a handful of people, and assembling your own knowledge base was difficult. Hoglund and Butler write clearly, use great code examples, and deliver an excellent book on a high technical and specialized topic. If you're interested in learning how to write your own rootkit or detect someone else's rootkit on your system, you should definitely start with this book.
You can purchase Rootkits: Subverting the Windows Kernel from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Some may wonder if Hoglund and Butler are being irresponsible by writing a book that shows you how to bypass detection. If you look closely, however, you'll see that all of the methods they outline are detectable by current rootkit revealing mechanisms. And they also show you how to detect many new rootkits in the process. I consider this book to be a responsible contribution to the community, professionals and amateurs alike, in the finest tradition full disclosure.
The book is organized into three major sections, even if it's note explicitly marked as such. The first section serves as an introduction to the topic and some of the high level concepts you'll need to know about Windows, control mechanisms, and where you can introduce your code. The second part is a highly technical tour of the techniques used to hook your rootkit in and hide it, And the third section is really one chapter covering detection of rootkits.
The first few chapters, which serve to introduce the topic, get technical right away. Chapter 2, for example, shows you some basic mechanisms for hooking in your rootkit. If you're getting lost at this point, you'll want to probably augment your reading with a Win32 internals book. The resources listed by the authors, though, are great. By this point you can also see that the writing is clear and the examples contribute perfectly to the topic. Hardware hooking basics are covered in chapter 3, which should give you some indication of the book's pace (quick!).
By the time you get to chapter 4 and discussing how to hook into both userland and the kernel, you're getting at some very valuable material. Although the book focuses on kernel hooking, a brief description of userland hooking is provided. Chapter 5 covers runtime patching, a black art that's not well known. This is almost worth the full price of admission, but the material gets even better.
In chapters 6-9 you get into some serious deep voodoo and dark arts. In these chapters you'll learn the basics of direct kernel object manipulation, layered device drivers (which can save you a lot of work), hardware manipulation, and network handling. All of these are techniques used by rootkit authors to varying degrees and effect, so you should become familiar with them. The code examples are clear and functional, and you'll learn enough to write a basic rootkit in only about 150 pages. Simple keyboard sniffers and covert channels are described in the code examples. Useful stuff.
I can't say I found many errors or nits in the book. There's some problems at times getting the code formatting just right, and what appear to be a few stray characters here and there, but nothing too obvious to me. Then again, I'm not a Windows kernel programmer, so I don't feel qualified to comment on the correctness of the code.
In the finest tradition of using a blog and dynamic website to assist your readers, the authors have set up rootkit.com, which nicely supplements their book. Most of the resources they mention in the book are available here, as well as a great array of contributors and evolving techniques. Without the book the site is still useful, but together they're a great combination. Too many books lose their value once you read them, and some books stay with you because you're having difficulty understanding the authors. Rootkits will stay near you while you develop your skills because it's a lot of material in a small space, and although it's very clearly written, there is a deep amount of material to digest. You'll be working with this one for a while.
My only major wish for this book is for it to have covered detection more significantly. One chapter covers how to detect rootkits, and although you may be able to look for some specific telltale signs of rootkits depending on how they were introduced, a more complete coverage of this approach would have made the book even more worthwhile.
Rootkits is an invaluable contribution in the wider understanding of advanced attack and hacker techniques. Previously, much of this material was known to only a handful of people, and assembling your own knowledge base was difficult. Hoglund and Butler write clearly, use great code examples, and deliver an excellent book on a high technical and specialized topic. If you're interested in learning how to write your own rootkit or detect someone else's rootkit on your system, you should definitely start with this book.
You can purchase Rootkits: Subverting the Windows Kernel from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hopefully the hax0rs are not the only ones reading this. There are some valuable lessons for MS and security providers.
Jerry
http://www.cyvin.org/
I own this book and I thought it was great. I am not a rootkit creator, but I am woking with drivers, and the information this book gives is great for a driver developer. This book is very straight forward and understandable, even for someone with little driver experiance, unlike many resources for driver developers. Also it gives actual source code to illustrate concepts, unlike many books which spend too much time covering concepts and too little getting those concepts to do actual work for you.
Philosophy.
...how long it will be beofre someone tries to ban books like this?
I used to have a better sig but it broke.
Here's a story of some peeps from Microsoft Product Support Services who got a call about a weird crash in Exchange; tracked it down with the debugger, and found a pretty well-hidden rootkit. In fact, it would've remained hidden if it didn't have a bug in it!
Don't believe everything the debugger is telling you!!! (aka Rootkit)
DMCA...no, that won't work. How about PATRIOT ACT! Yeah, those damn terrorists and their first amendment.
Give a man a fish and he'll eat for a day. Teach him to fish and he'll wipe out the species.
I was chatting up this chick in a bar last night and I said, "Yeah, I could root your box in about five seconds," and she slapped me! I thought that would impress the chixxors!
I keep thinking I need this book just to secure my own PCs and also help out friends...
You have to love the windows environment.
No, I don't trust in god. He'll have to pay up front, like everybody else.
Yah I saw them too. Everyone knows it's not 'elite hacker' but rather 'l33t hax0r'
Damn editors.
Technology, the cause of and solution to all of life's problems.
It is nice to see that you took the time to post a knee-jerk response, but could not be bothered to read the first paragraph of the article.
Some may wonder if Hoglund and Butler are being irresponsible by writing a book that shows you how to bypass detection. If you look closely, however, you'll see that all of the methods they outline are detectable by current rootkit revealing mechanisms. And they also show you how to detect many new rootkits in the process. I consider this book to be a responsible contribution to the community, professionals and amateurs alike, in the finest tradition full disclosure.
I remember people had Linux boot disks for changing the Windows NT admin password. But does this kind of thing still work for Windows XP and the server editions? I wonder if Microsoft will take this info and use it in Windows Vista to counteract rooting.
Where I learned this. Well, about the rooting, not about the smoothing over chicks.
Click here or here.
I don't think I've ever seen Jose be so complimentary about a book before. Nice job, guys. I have the book as well, and I like what I've seen so far, but I haven't read enough yet to comment meaningfully.
I will point out though that the rootkit.com site has been around for a few years now, and obviously predates the book. In fact, I hope the book will explain in greater detail a lot of the technical topics from the site that are often only presented via code.
It's also a useful tool for advocates who try to convince people to switch from Windows to another OS (no, not just Linux), the argument being "look, you wonder if Windows is insecure? how about a whole friggin book, with an ISBN and all, about how to do nasty things in Windows despite A/V software and anti-spywares!"
Which OS were you talking about? I could swear the ones you might name have hacking books written about them too.
r0x0rz j00r b0x0rz, d00d
Sorry, that's spelled 'ARGV'.
Kernels are so big and bloated that there is almost %100 chance of there being some exploitable whole in them. If the "good hackers" discover it, it will be patched, if the "bad hackers" discover it, they will make rookits.
A lot of the code that is not tested and buggy is in the drivers, and I don't understand why do current operating systems still have drivers that are run in the kernel instead of in the user space. The machines are fast enough to switch contexts between the display, mouse, sound, disk and communication with the ports. The kernel should be very small and only implement the security policies and handle communications between devices. If the hacker manages to exploit a hole in the display driver, the driver will not crash the system. These are called secure microkernels or separation kernels. I think the present 4Ghz machines can hangle a %10 slowdown at the expense of say, %80, improved security. In 18 months, the speed will double anyway ;)
Check out this paper from NIST that talks about this. Also, more general info about it here
Since its vaguely on topic, and I'd like feedback if I can get it, here is some shameless whoring for a Free rootkit detection program I wrote:
Heres the URL
This is a multithreaded script that establishes socket connections between the threads and tries to pass a keyphrase between them. The assumption is that even if windows is compromised, a successfull TCP connection will indicate that the port is really not in use, regardless of what netstat says. Unless a rootkit is slick enough to make multiple programs share a port regardless of SO_REUSEADDR, this should catch it. The drawback, unfortunately, is that it can take a significant amount of time to scan 65,000 odd ports in this manner. Anyway, its GPL, so have at it.
The core problem with detecting a rootkit is that the detection software would seem to need to run inside the infected codespace. Unless the detector is 100% self-contained (e.g., involves NO calls to OS API during the detection process) the detector is itself detectable and defeatable by a skilled rootkit. Since invoking any software on a running system means calling APIs of that system (to read the executable, spawn a new process, etc.) and those APIs are not trustworthy on a rooted system, detection seems like a tricky problem.
The solution is either to boot the detector from its own media (inconvenient if you want to scan your system for rootkits on any regular basis) or to create a ROM core to the OS that is totally incorruptible. To be safe, this core needs to be not patchable or modifiable by any software running outside the ROM.
The point is that no computer can trust code fragments stored of writable media. The only way to really secure a system is with hardware (i.e., functionality embedded in a chip) or ROM-based software.
Moving to ROM isn't without its challenges. The writers of the code will actually need to be very good at their jobs because they won't be able to fix the problem later with a simple patch. But maybe the core of an OS should be this way -- based on very well-written code that does not need patching.
Two wrongs don't make a right, but three lefts do.
I doubt it would do them much good, I suppose you would have to have more technical knowledge than the average script kiddie to make effective use of this title.
Not to mention know how to read.
I am Bennett Haselton! I am Bennett Haselton!
oh nevermind
Where is the "I for one welcome our rootkit overlords"? Or the "ALL YOUR ROOT ARE BELONG TO US"?
"Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves
Instead of windows they could switch to Linux or a *BSD or MacOS.
Oh wait, almost all OS's out there right now have rootkits for them.
It scans all files and registry entries at a high and low level then compares the two to see which files and registry entries were hidden to the high level scan.
Input error. Replace user and press any key to continue.
How many readers won't know what a root kit is, and declare 'ha, see! windowze is insecure, glad I run [alternate]'? :}
If you are running MS windows, is it then really your computer? Look good at the licensing, it might reveal some things in the really small print......
Ok, you got moderated as a troll, this should really score good!
My wife's sketchblog Blob[p]: Gastrono-me
If you encrypt the Windows Filesystem then there is no trivial way to get the data without the decryption key. This is breakable given time, etc. depending on how strong the encryption is.
It also makes it a royal pain to recover if certain things go wrong.
If you DIDN'T encrypt the filesystem then it is absolutely trivial to change the admin password, to put the disk in another machine, to boot linux and read the HD... etc. Because the data is completely insecure.
This is COMPLETELY THE SAME on Linux. You can boot any normal linux install from a boot disk and reset the root password. Actually in Linux you don't even usually need a disk, you just need to enter init=bash in LILO (depending on LILO/Linux settings; this can certainly be turned off)
Security means not giving people physical access, or at a minimum restricting the boot sequence to only be harddrive, locking the CPU, locking the BIOS and locking the boot loader. This is true in any OS.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Well, it's not really an Apples-to-Apples comparison, of course. But to answer your question, No, it could not be installed "just as easily." However, once installed, it might be "just as difficult" to remove or detect. :)
Two main points:
Disclaimer: I am a Windows network admin (and MCSE:2003 certified), but I lead a double life where I use and administer a small network of Macs.
I hate it when non-technical posts get rated as informative. First off, as others here have misstated, rootkits are essentially malicious drivers or kernel-level backdoors. They are *not* exploits, not bugs, and not driver cracks. Rootkits are essentially malware that runs at a higher level than most malware, with the intention of using API-hooking to misreport filesystem, process, and network status. The expertise required to make them is generally several orders higher than DDOS zombies or botnets. Though ironically, that same kind of malware is almost always installed and then subsequently hidden by the rootkit after one is installed.
I only felt it necessary to mention this because of those individuals who seem to think rootkits themselves are exploits to get escalated privileges. While some rootkits get installed via "shatter attacks" and other priviledge escalation exploits, they themselves aren't doing any exploiting.
I found an interesting pop-up generating piece of malware several weeks ago that appeared to use rootkit-type techniques to hide itself. It was invisible from the process lists (including the nicer command line ones) and the filesystem. I was able to track it down and delete it (unfortunately, the machine was several hundred miles away and I was working on it remotely, otherwise I would have booted off a CD and made a copy of the little bugger), but it was a royal pain in the ass to do.
... grrr). So I used ProcMon to kill any threads associated with the pid - the process was invisible, but you could still find the threads by which libraries they were using and kill them there (use the search command). Once the threads were killed, I could overwrite the loader file (you couldn't read it, copy it, list it, etc., but it would give you an error if you tried to overwrite it while the threads were running).
For the interested (some of the details might be slightly off because I've consumed a lot of booze between then and now, but the overall gist is correct), I found the malware by using SysInternals RegMon to find the process ID that kept replacing the registry entries that loaded it. That Process ID couldn't be killed by any of the tools I could find (because they check to see if the pid is valid before trying to terminate it, and it had stealthed itself to the point where the ID appeared to be invalid
Help save the critically endangered Blue Iguana
Not true? Yes it is. Windows XP sets up one admin account for the user, and it doesn't encourage using an unprivileged account. In fact, most Windows users think that it is best to use the admin account all the time (because of the reasons I just mentioned and also the fact that so many USER APPLICATIONS need administrative privileges (like games) when they really shouldn't need these privileges.
Microsoft-free since March 28, 2004
Oh, I sure do. I once briefly worked in a clinic for neurosurgery once (this was a summer job during school; I wasn't actually involved with the medical side of things in any way) - it was rather scary at times.
We also a considerable amount of accident victims, too, though, and in the case of those, I think that even a 33% chance to improve isn't so bad, because otherwise, they'd have a 100% chance of dying.
quidquid latine dictum sit altum videtur.
I think when the Palladium platform is released, it will eventually be hacked or otherwise subverted by rootkit hackers. The rootkits will use the DRM restrictions of Palladium to prevent any tool from removing the rootkit. People who's computers get infected by these Palladium rootkits will be forced to throw entire computers out.
You've asked about three things:
-How does one install a rootkit on a running box, while minimizing traces left behind
-How do you leave your rootkit code on the machine such that booting it off of secure media and checking hashes of a class of files won't detect any changes
-How do you maintain control over the machine from early in the boot process. Note that this isn't the only was to hide, depending on exactly what is checked in question two.
How to get on the box in the first place is the easiest step. It's done all day, every day. Buffer overflows are not a solved problem. Buffer overflows are not the only way to break into a box. Your questions about binary signatures, hashes etc... at this point do not matter. You have nothing checking binaries on the fly. Or I can do my work using binaries with a perfectly valid signature, or binaries that already exist on the system. Or I can do everything in RAM. I believe all the popular exploit frameworks have options that work straight out of RAM. I know Metasploit does. I can install the rootkit into the live kernel by modifying kernel RAM. That was done several years ago.
Question two: So, describe your file checking process to me. I believe you may have been originally talking about the RPM hash checking. That only covers a portion of your files. What about config files, your mail spool, your temp files, your documents, your log files, your profile files, and on and on. There are all these places code could be hidden. And then there is slack space, unused sectors, unpartitioned space, etc... Hiding isn't a problem.
The third question is really the only hard one. There are simple cases, like DOS. Bootsector viruses are 20+ years old on DOS. Here's how I'd do one for Linux, conceptually. I wouldn't want to actually tackle this, mind you...
Every operating system that wants to boot from a hard drive on a PC has to go through a particular process. After the BIOS is done, you sector 0, and start running it. Sector 0 knows enough to get to a several sectors, which know a little about a filesystem, which know how to find an OS-specific file, which switches the machine into real mode, and can load a disk driver, or a kernel, and so on.
So, I would substitute a part of the boot sector or the next chain of sectors in the process. Instead of loading the next piece that gets us to the real grub, I load my modified grub, which I have hidden on the disk. My modified grub loads my modified kernel, which I have hidden on the disk. From there, I can use the rest of the real filesystem.
The trick is, if you boot from a CD and inspect the filesystem, you find the original grub and kernel files. If you try to check things once Linux is up, my modified kernel is feeding you a version of reality that matches what you expect. I.e. if you check grub and the kernel file from the running Linux, it hands over copies of the original files for you to inspect.