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.
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 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.
That's GREG HOGLUND. Not 'Grog Hegland'!
Sheesh, it's even written down on the front cover of the book that you supposedly have in front of you while reviewing it!
This one bothers me. How does one go about just trying without trying anything in specific. It's like humming with your mouth open!
It's "try to find".
Stop Global Warming!
Just say no to irreversible processes!
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.
which include Windows NT/XP/Vista (a single-user system subverted to multi-use)
just as sort of a postscript here, that is absolutely false
You can make a rootkit for any OS, even a minimal microkernel, unless your OS runs out of ROM or there's similiar hardware level measures in place. A rootkit is the end result of an exploit, not an exploit itself - the tricky part is getting sufficent access to install a rootkit.
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.
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
This could be largely incoherent, its been a long day:
Regarding the "hop around the port numbers" tactic, depending on how much hopping they do, this would actually make them more findable. One of the major issues I ran into writing this script in originally was what happens to a socket set once the connection is dropped. The TCP/IP stack doesn't actually remove the connection, it sits around in a waiting-for-death state (I have forgotten the actual technical name at the moment) until it has been idle for the timeframe of twice the maximum time to live. The technical reason for this is that it is conceivable that some errant packet may go all the way out by 1 ttl unit, and then wander back by 1 other ttl unit, and until it is no longer possible that any packets will make it home, the stack holds onto that port rather than reassigning it a new connection.
The fun part here is if my scanner scanned numerically, and the OS also is assigning outgoing ports numerically, what you end up with is a mess of everybody stomping on themselves in order (crashing on 1000, then 1001, then 1002... etc) for hundreds and hundreds of ports.
What a port-hopper would run into a situation where his *old* connection, even if he had given it up, would still show up on the scanner as 'in use' for something on the order of an entire minute after the connection was dropped. A substantial amount of port hopping would (after some mathematically calculatable limit) actually make you more easily detectable.
Regarding the client/server version, that wouldn't alleviate my biggest concern: a patched network stack that does an inspect/pass on of interesting packets. If the rootkit is capable of saying "hey, thats mine!" and holding packets that it knows are intended for it and simply passes on all other packets to the "real" port, it wouldn't need to worry about whether or not the machines talking to it were rootkitted or not. They could concievably simply use the Evil Bit for that determination.
I don't think our local script kiddies are going to be that clever though. The way I figure it, if we can force the kiddies to push deeper into the kernel to avoid detection, the harder it will be for their tricks to be version independent and the better off we'll be.