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.
It is an interesting book (Score:4, Interesting)
Jerry
http://www.cyvin.org/ [cyvin.org]
My opinion (Score:5, Interesting)
Wow (Score:4, Interesting)
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.
Re:I wonder... (Score:3, Interesting)
Fat bloated kernels (Score:5, Interesting)
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 [nist.gov]paper from NIST that talks about this. Also, more general info about it here [acumeninfo.com]
Shameless plug (Score:3, Interesting)
Heres the URL [elifulkerson.com]
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 need for ROM kernels (Score:5, Interesting)
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.
Re:Although good for security experts, (Score:3, Interesting)
Not to mention know how to read.
Linux is NOT UNIX! (Score:1, Interesting)
-Linux, for those who hate MS.
-*BSD, for those who love UNIX.
Re:Rootkit Sleuthing IRL (Score:2, Interesting)
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?
Re:Fat bloated kernels (Score:3, Interesting)
The problem is that people do want performance, but after their box gets rooted and their hard drive erased, they tend to change their priorities. I sure could have lived with a 10% slowdown and play Quacke at 90 fps instead of 100 fps if that meant that I had a more secure OS and my box did get rooted.
In 1992 for Linus, performance was very important. I don't think he anticipated the popularity of Linux and that one day people would be using it on their desktops and they will be connected to the net, and script kiddies will turn them into zombies.
But it is not 1992 anymore and I think it is time to reconsider. Security is becoming more and more important and slowdown can be compensated by just buying a faster CPU next year.
Re:Fat bloated kernels (Score:3, Interesting)
I've been wondering about this. In a huge number of cases I would gladly swap 20% or even 50% of the speed for absolute guaranteed security. And in my opinion in lots of cases it would be the obviously correct choice (if there was such a choice, that is). What makes people value their security so little?
Re:Fat bloated kernels (Score:4, Interesting)
This is all fine and dandy in theory, but, out here in the real world, device drivers still have to talk to hardware directly. When a device driver sends commands to hardware that will effectively pre-empt data bus operations at the hardware level (outside of cpu control), you have to sit back and go 'gotta trust the driver code'. Unless the kernel has full knowledge of the consequences of all hardware i/o operations, it's really pointless to run it thru a mapping layer so that the kernel actually does the io on behalf of a higher level program.
I remember once many years ago, somebody showing me a shiny new install of WindowNT, and they were telling me it was a secure, crash proof box. I chuckled, and took a look at some of the installed hardware. I then proceeded to sit down, start 'debug', write a value to one video port, and another value to another video port. Screen went blank, machine sat there for a while, then it reset. It's not hard to set a video card into a state where it's going to assert wait on the memory bus until an event occurs, yet pre-program the device so that the event will never occur. At that point, the main bus is effectively dead, the cpu can no longer access memory, game over. This 'exploit' took advantage of a not so well known flaw in Video Seven graphics controllers.
The hardware attached to the various busses on modern computers has the ability to halt/corrupt the bus. As long as that's the case, there's no point trying to put a kernel layer in between to 'protect' the system, unless the kernel layer has full knowledge of all aspects of the hardware in question, and will prevent such conditions from being set up. This is typically the responsibility of [drum roll] the device driver for the device [/drum roll].
If you are suffering from driver instability problems, then, you are part of the problem. You chose to buy the cheapest crap, and then sit back blaming 'somebody else' because the driver support is crap. You had the opportunity to vote with your wallet, buy stuff that's well supported, and doesn't have stability problems. If the market as a whole actually used this 'vote with the wallet' clout, the state of affairs would be different, because only vendors providing good support would survive in the marketplace. Sadly, that's not the case. The market is driven by 'the cheapest price' and you get what you pay for.
The computer I'm using to write this, doesn't have any driver stability problems. I paid a little extra to get a set of video cards (plural, I have 3 displays on this computer) that would operate cleanly, and not cause problems in a multi-display environment. I paid a little extra for a motherboard that's known to be solid and reliable. I paid a little extra for a disk that doesn't have a history of failures.
I voted with my wallet, because I understand, it's not physically possible for an operating system running on the cpu to recover from problems generated in the hadware. If a given device corrupts a data bus, or asserts reset at the wrong time, there are going to be problems. The key is, buy the devices that dont do that, and choose the ones that have a track record of good software support in the form of drivers.
I have zero sympathy for folks that complain about buggy drivers all the time. It was your choice to buy the crap hardware. You saved a few bucks, and bought a stack of aggrivation. That's your choice, but, there were other choices. You could have chosen to make informed purchases, and buy based in quality rather than price.
As long as the operating system is something that runs ON TOP OF THE HARDWARE, it's going to be subject to the problems of the hardware. The software support for the hardware is part and parcel of the package. Isolating drivers up to user space is NOT going to solve the problem, because that driver is still going to be manipulating dat
Yes, rootkits are now in Malware (Score:5, Interesting)
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
Re:Why are you reviewing this book? (Score:3, Interesting)
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.
Re:Yes, rootkits are now in Malware (Score:5, Interesting)
I have a Palladium prediction (Score:4, Interesting)
Re:I have a Palladium prediction (Score:3, Interesting)
To address part of your point though, I DO believe that it will be possible for someone to find a hole inthe Palladium software, and install a rootkit on the "Secure" side. If they do it right, then you might have to reformat to get rid of it.
Re:Fat bloated kernels (Score:2, Interesting)
Now, all the absolutely vital system components that could be used for the exploitation of the system for a rootkit. Mark those system immutable.
Wouldn't this also stop auto updates and similar? Of course provided that your code is perfect the first time there would be no need - but as a previous post pointed out - we is human and we makes mistakes