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.
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.
If they are not banned outright, don't be suprised if your FBI file is augmented when you check this book out from the library.
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!
-Linux, for those who hate MS.
-*BSD, for those who love UNIX.
Wow, I read up on rootkits. Amazing. And hacker defender reads like a manifesto on hacking PCs.
As I Mac user I keep hearing about how much more secure Macs are than PC's, and sort of believe that. But in reality, what is the true security of a Mac vs. a PC? I mean, I *want* to believe I have the more secure system, but complacency is the surest way to hack a system. So, anybody know the real deal.
If a Mac hacker was as motivated as any PC hacker, could a rootkit like hacker defender be installed just as easily on a Mac?
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
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.