Rootkits: Subverting the Windows Kernel 381
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.
I wonder... (Score:2, Insightful)
...how long it will be beofre someone tries to ban books like this?
Re:Great! (not) (Score:2, Insightful)
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.
Re:We've got to stop them! (Score:1, Insightful)
Sincerely
George W. Bush
President of Hali^h^h^h^h The United States of America
Richard Cheney
Vice President of Hali^h^h^h^h The United States of America
Bill Ga^h^h^h^h^h^h^h
Re:The great thing about this book (Score:4, Insightful)
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.
Re:It is an interesting book (Score:4, Insightful)
Oh wait, did you mean you want Palladium? Microsoft is way ahead of you, then.
Re:The great thing about this book (Score:4, Insightful)
Instead of windows they could switch to Linux or a *BSD or [rootkit.nl]MacOS [secretweaponlabs.com].
Oh wait, almost all OS's out there right now have rootkits for them.
predictions? (Score:3, Insightful)
Re:Great! (not) (Score:3, Insightful)
Ok, you got moderated as a troll, this should really score good!
Re:The need for ROM kernels (Score:5, Insightful)
Re:Does this still work? (Score:3, Insightful)
Which is why you need disk encryptors. The entire disk is encrypted. Go ahead, access it outside the OS environment. All you get is random bits.
Yes, you can try to brute force the password, but that takes many, many CPU cycles, and much time.
Google it [google.com]
Re:My opinion (Score:5, Insightful)
(No offense to the parent post, of course. I'd like better driver documentation too.)
Re:Fat bloated kernels (Score:3, Insightful)
This sort of slow change is normal in any engineering field. You have to adapt to changing materials and changing requirements.
Re:Does this still work? (Score:3, Insightful)
Beyond that special case, NOTHING is safe vs an in-circuit emulator. If the machine can access those files, the key is in memory at some point. If I can't give myself rights to debug that point, I'll replace the CPU with a hardware emulator that lets me have my way with *everything* without any running process being the wiser. (ICEs are actually very cool to work with, great for recovering source from encrypted object code and other fun tricks.)
Physical access to a machine is access to the data, sooner or later.
Re:Fat bloated kernels (Score:3, Insightful)
In _general_ on the same processor the faster the clock speed the greater computational throughput. If Mhz!=speed, then underclock you machines to 100Mhz, see if you'll notice a difference...
I can run 10Ghz over a copper wire, WHOA that is fast.
Good for you. Whatch the output power and keep it away from the brain and the reproductive organs.
Re:Fat bloated kernels (Score:3, Insightful)
Now, all the absolutely vital system components that could be used for the exploitation of the system for a rootkit. Mark those system immutable.
Now, the hacker needs physical access, and single user mode to hijack your system. I'd call that as secure as you can get.
Now, granted... like you said, this is the end of the exploit. If they had sufficient eploits to get physical access and single user mode, well then, I suppose they *could* install a root kit.
But how many script kiddies do you let into your house?
Re:Fat bloated kernels (Score:3, Insightful)
Depends on whether you're talking a remote or local rootkit, doesn't it? All bets are off when you can tweak the machine directly, but an OS can be secured sufficiently to not run any code from the outside.
Re:Linux does this well. MS's approach is broken. (Score:3, Insightful)
-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.