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.
...how long it will be beofre someone tries to ban books like this?
I used to have a better sig but it broke.
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.
Nah, the Patriot Act by itself won't work. I know, let's bri^h^h^hlobby congress to revive the CBDTPA, and let's have them call it something else so the sheeple won't know any difference. When we get that, we wil use it along with the patriot act to exe^h^h^hhunt down those tourists.
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
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.
What do you think Microsoft is going to do about it? If someone has system access there isn't anything to be done about them moving in with a rootkit.
Oh wait, did you mean you want Palladium? Microsoft is way ahead of you, then.
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.
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
A secure microkernel is quite possible, but, as Ballmer once said, "If we stopped adding features to Windows, it would become a commodity, like a BIOS. And Microsoft is not in the BIOS businees".
There is no such thing as security if you have physical access to the box. Period.
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
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
I think the fact that a book about rootkits is considered good documentation by a driver developer is demonstrative of the sorry state of affairs of drivers these days. Most exploits and crashes are due to bugs in drivers ... perhaps it wouldn't be so bad if driver developers didn't have to code their driver as if it were hijacking the OS.
(No offense to the parent post, of course. I'd like better driver documentation too.)
Lack of eloquence does not denote lack of intelligence, though they often coincide.
The preformance / security tradeoff was a bit different 13 years ago. The best decision in 1992 isn't necessarily the best decision today. Folks are *far* more concerned about security today, and CPU performance doesn't seem as large a concern.
This sort of slow change is normal in any engineering field. You have to adapt to changing materials and changing requirements.
Socialism: a lie told by totalitarians and believed by fools.
Encryption on disk helps, but like any security measure, it merely delays the attacker. Unless you do file-by-file encryption without any help from the system in storing the keys, of course, but that's not the normal case (and these days any key you can memorize is weak).
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
I'll take this one on. Let's start with minimal microkernel, then build ontop of that an OpenBSD like subsystem. (just because it has the resources that I'm aware of, and will be using.)
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?
I am unamerican, and proud of it!
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.
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.
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.