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.
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.
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)
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!
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.
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
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.
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.
Cash is suspicious. Use a gift card that you bought with cash at a different store. And use a disguise. Nothing's less suspicious than a guy in a trenchcoat buying a book with blackhat potential with a gift card . . . . . . .
Outside Australia, in the rest of the world, to explain the joke as though nobody else gets it is to demonstrate that you don't have much of a sense of humour yourself.
Tubal-Cain smokes the white owl.
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