Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

Rootkits: Subverting the Windows Kernel 381

Posted by timothy from the only-for-bad-people dept.
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.
This discussion has been archived. No new comments can be posted.

Rootkits: Subverting the Windows Kernel More

Rootkits: Subverting the Windows Kernel

Comments Filter:

  • It is an interesting book (Score:4, Interesting)

    by confusion ( 14388 ) on Tuesday August 16, 2005 @02:24PM (#13332071) Homepage
    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/ [cyvin.org]
    • So how many years do you think it will be until Microsoft cares about it? ;) </toungeincheek)

    • Re:It is an interesting book (Score:4, Insightful)

      by ryanr ( 30917 ) * <ryan@thievco.com> on Tuesday August 16, 2005 @02:45PM (#13332236) Homepage Journal
      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.

      • I have a Palladium prediction (Score:4, Interesting)

        by TheNarrator ( 200498 ) on Tuesday August 16, 2005 @08:39PM (#13335407)
        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.
        • I've not heard of any proposal for nonvolitile storage for Palladium. So worst case, you'd have to reformat your hard drive and reinstall. Or are you being sarcastic?

          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.

    • Fat bloated kernels (Score:5, Interesting)

      by drgonzo59 ( 747139 ) on Tuesday August 16, 2005 @02:50PM (#13332269)
      The lesson in this article should be also that there is something wrong with the Windows kernel if there can be written whole books about how to make rootkits for it. The same can go for the Linux kernel. (Yeah that's right, I bashed _the_ penguin on the head, mod me down!)

      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]

      • Re:Fat bloated kernels (Score:5, Informative)

        by arkanes ( 521690 ) <<arkanes> <at> <gmail.com>> on Tuesday August 16, 2005 @03:14PM (#13332458) Homepage
        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.
        • You are right, I was just thinking that a small (couple of thousand lines) open source microkernel will have much less exploits than a kernel that is a million lines together with drivers and everything else that can run in kernel space.
        • That wasn't his point.

          The more code you throw in an OS kernel then you have more exploitable code.

          He's talking microkernel.
        • 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 ex
        • 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 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.
           
          That's it, I'm breaking out my Commodore 64!
      • Andy? Andrew Tannenbaum? I didn't know you read Slashdot. By the way, I thought Linus has already explained that matter to you!

        (no, 20% efficiency/speed lost is NOT an acceptable loss)

        • Re:Fat bloated kernels (Score:3, Interesting)

          by SLi ( 132609 )
          (no, 20% efficiency/speed lost is NOT an acceptable loss)

          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)

        by grozzie2 ( 698656 ) on Tuesday August 16, 2005 @04:43PM (#13333397)
        The kernel should be very small and only implement the security policies and handle communications between devices.

        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

  • My opinion (Score:5, Interesting)

    by Umbral Blot ( 737704 ) on Tuesday August 16, 2005 @02:25PM (#13332080) Homepage
    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.

    • Re:My opinion (Score:5, Insightful)

      by sean23007 ( 143364 ) on Tuesday August 16, 2005 @03:54PM (#13332884) Homepage Journal
      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.)

  • I wonder... (Score:2, Insightful)

    by squoozer ( 730327 )

    ...how long it will be beofre someone tries to ban books like this?

  • Rootkit Sleuthing IRL (Score:5, Informative)

    by chota ( 577760 ) <chrishota@gmail.com> on Tuesday August 16, 2005 @02:28PM (#13332107) Homepage

    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) [msdn.com]

    • Great link. Pretty impressive work to solve an Exchange crash, and it's a good example of how to use kernel/user debuggers to solve complex crashes. I'd like to hear more stories like that one. You could learn a lot.

      It just goes to show, you never can really tell what's really going on without some real effort.
    • 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

      • Re: Is it easy to get rooted for Macs? (Score:5, Informative)

        by chota ( 577760 ) <chrishota@gmail.com> on Tuesday August 16, 2005 @03:39PM (#13332703) Homepage

        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:

        1. It all comes down to default user permissions. On Windows (by default), everyone is an admin, so, with one wrong click, and you really can bring your system to its knees. With OSX, users are just users by default, and you have to authenticate to install something potentially nasty. I've observed that the actual *authentication* (typing in a super-user password, different from your own) is enought to get a user sit back and think "Gee, maybe I shouldn't do this." Contrast this with the Windows equivalent of a popup with 2 buttons, "Run" and "Don't Run." People condition themselves to click the "Run" button automatically. This is because of the inherent differences in the OS.
          • Windows has a legacy of having its users being administrators; therefore, the vast majority of Windows apps assume that they can write files and registry entries willy-nilly. (If you don't think it's that bad of a problem, talk to a knowledgable and responsible Windows network admin, trying to secure a general-access lab that MUST have Adobe and Macromedia apps on it -- it's a nightmare, I tell you)!
          • Mac OSX, in contrast, since it didn't have a "legacy" (i.e., it was architected from the ground up, and purposefully did NOT include backward-compatibility), all apps written for OSX simply must be written to the security spec, or they simply won't work. Additionally, with 10.4, Apple has proven that they care more about security and logic in the OS than backward compatibility (whether you think that's good or bad, it's there) -- witness the extreme breakage of pretty much every non-Apple OSX network utility.
        2. OSX has Single User Mode [apple.com] . There is no Windows equivilent. Safe mode is a laughable comparison. With OSX's Single User Mode, you can pretty darn easily clean up our theoretical infected machine.
        3. Third point that doesn't really count: Although I hate to stereotype; Apple users are generally smarter than Windows users. There, I said it.

        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.

      • What's kinda funny I went to the hacker defender website (they don't exactly hide themselves) and there's a big advert for this book!

  • We've got to stop them! (Score:3, Funny)

    by The Woodworker ( 723841 ) on Tuesday August 16, 2005 @02:28PM (#13332109) Homepage
    DMCA...no, that won't work. How about PATRIOT ACT! Yeah, those damn terrorists and their first amendment.

  • Don't tell girls you're going to root their box (Score:5, Funny)

    by Anonymous Coward on Tuesday August 16, 2005 @02:28PM (#13332114)
    I was chatting up this chick in a bar last night and I said, "Yeah, I could root your box in about five seconds," and she slapped me! I thought that would impress the chixxors!

  • Hmmmm (Score:3, Funny)

    by chriso11 ( 254041 ) on Tuesday August 16, 2005 @02:29PM (#13332116) Journal
    I keep thinking I need this book just to secure my own PCs and also help out friends...

    You have to love the windows environment.
  • 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!"
  • 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.

    • Re:Does this still work? (Score:4, Funny)

      by TripMaster Monkey ( 862126 ) * on Tuesday August 16, 2005 @02:43PM (#13332224)

      But does this kind of thing still work for Windows XP and the server editions?

      Short answer: yes.
      Long answer: hell yes.

      There is no such thing as security if you have physical access to the box. Period.
      • There is no such thing as security if you have physical access to the box. Period. Exactly. You could boot from alternate media, swap hard drives, or heck, you could even just put the system hard drive(s) in your pocket. That's why locking down desktops is basically pointless for anyone that knows what they're doing.
      • 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 [google.com]
        • My old high school did this. On machines with Windows 95 or 98, too little ram for anything, Quantum Bigfoot drives (slooow), and the encryption was hardware based. On ISA cards. You can imagine the swapping, when a 16mb Windows runs out of memory.

          The reason, of course, was that some people *ahem* had been taking the liberty to bring in their own hard drives to put in the computer, in order to use the (then) fat pipe at school to download all kinds of not-safe-for-anywhere stuff, in addition to other intere

        • Re:Does this still work? (Score:3, Insightful)

          by lgw ( 121541 )
          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 emula
      • 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
        • IIRC, the Windows encrypted filesystem keeps the key together with the data, still needing that the key passphrase is somewhat strong.
          There are Linux encrypted filesystems that permit you to keep your key in another media (like an USB drive or a floppy or a cd-rom).
    • Comment removed based on user account deletion
    • One thing I just recently learned when trying to recover files from a bad boot sector drive along the same lines is Windows security for protecting profile specific data (my documents etc.) can just as easily be hacked using nothing more than windows. All you have to do is load the drive on another windows machine, when you try to view the files and you get an "access denied" message, merely go through the advanced security settings on the folder and there is the option to apply your own security settings
      • You can do the exact same thing in pratically any other OS. Yes! Even Linux! Permissions are only as secure as the environment is willing to respect them. Next time, you might want to enable Windows data encryption. Lose the key and you'll NEVER recover those files.

  • Wow (Score:4, Interesting)

    by ryanr ( 30917 ) * <ryan@thievco.com> on Tuesday August 16, 2005 @02:36PM (#13332174) Homepage Journal
    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.

  • w00t (Score:4, Funny)

    by vga_init ( 589198 ) on Tuesday August 16, 2005 @02:39PM (#13332191) Journal
    r0x0rz j00r b0x0rz, d00d

  • Shameless plug (Score:3, Interesting)

    by republican gourd ( 879711 ) on Tuesday August 16, 2005 @02:52PM (#13332291)
    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 [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)

    by G4from128k ( 686170 ) on Tuesday August 16, 2005 @02:53PM (#13332293)
    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.

    • Re:The need for ROM kernels (Score:5, Insightful)

      by Animats ( 122034 ) on Tuesday August 16, 2005 @03:11PM (#13332433) Homepage
      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".
      • I fail to see the connection.

        I grew up with my mommy telling me that an operating system and a kernel are two different things.

        If Microsoft thinks that they need to alter the Windows kernel every time they add a feature to the OS, I think I see why they have so many quality control problems.
    • There is a middle path, where perhaps the ROM can be modified only with very particular acknowledgement from the user. Say, the mod has to be burned onto a CD and booted, and before overwriting itself the existing ROM asks, "Are you 100% sure you got this from a reliable source?" It could even check the Net to check the signature, if it had sufficient IP stack built in.

      This works best with microkernel architecture, which lets out Linux and Windows but OS X could conceivably go there. (And Windows actuall
      • There is a middle path, where perhaps the ROM can be modified only with very particular acknowledgement from the user. Say, the mod has to be burned onto a CD and booted, and before overwriting itself the existing ROM asks, "Are you 100% sure you got this from a reliable source?" It could even check the Net to check the signature, if it had sufficient IP stack built in.

        How can the ROM know that it got a valid user response (or that the user even saw the ROM's request) unless 100% of the UI is in ROM? Al
    • Read recently that in the XBox, there is some 512 bytes of code in the ROM (well hidden) that can authenticate the boot code, this way Im sure a future version of Windows can be sure that it is started without any rootkit exploits (ROM boot code refuses to execute exploited OS)
    • But maybe the core of an OS should be this way -- based on very well-written code that does not need patching.

      It doesn't even need to be "very well written". Look at BIOS code, for example. It doesn't exactly have a reputation as the most elegant and efficient code in the world. It just has to WORK, and be unmodifiable.

      I am not a programmer - I mean I used to dabble in programming years ago way back when. Did some assembler, some pascal, and some C/C++. I am way o
    • 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).

      That's not necessarily the case. Initially when I thought about it, I was thinking "Hm, a USB dongle would be a great device for that, just boot to the dongle periodically, and have it scan the drives." Of course, that would only really prevent rootkits in home computers [possibly], because you're absolutely right, no one in their right mind is going to hire some du

  • And with it I can hack the gibson in 3 seconds ... (Score:3, Funny)

    by PalmKiller ( 174161 ) on Tuesday August 16, 2005 @02:57PM (#13332322) Homepage
    oh nevermind

  • No Obligatory Snipery? (Score:3, Funny)

    by sadomikeyism ( 677964 ) <mlorrey@@@yahoo...com> on Tuesday August 16, 2005 @02:59PM (#13332345) Homepage Journal
    Where is the "I for one welcome our rootkit overlords"? Or the "ALL YOUR ROOT ARE BELONG TO US"?

  • Rootkit revealer (Score:5, Informative)

    by markh1967 ( 315861 ) on Tuesday August 16, 2005 @03:01PM (#13332361)
    If you run Windows and want to check if your system has a rootkit installed try running Rootkit revealer [sysinternals.com].

    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.

  • predictions? (Score:3, Insightful)

    by dioscaido ( 541037 ) on Tuesday August 16, 2005 @03:03PM (#13332377)
    How many readers won't know what a root kit is, and declare 'ha, see! windowze is insecure, glad I run [alternate]'? :}
  • I have been waiting for the day that Windows rootkits will start compromising the various detection utilities as well, such that the only way to remove the kits is to run read-only from a trusted environment. Then they will all discover how deep the rabbit hole goes. Or something like that.

    This is not a troll, because I think that is a sign of forthcoming higher maturity.
  • Try before you buy and check out the book's sample chapter, Leave No Trace [awprofessional.com] now!
  • What is with the constant irritating use of "In the finest tradition of"?

    In any case, good to see long articles. Slashdot should have more of them.

  • Woohoo!!! (Score:2, Funny)

    by eno2001 ( 527078 )
    I just got the winning bid on a Cray MP-X computer! I've wanted one of these since I was in high school back in 1988. It runs some old Unix variant called UniCOS, but considering the clock speed and RAM, I'm pretty sure it shouldn't be too hard to get Windows XP 64-bit running on it. That's one thing that always makes me laugh is how people are always buying the "latest and greatest" Pentium crap when it would be more cost effective to get a Univac, VAX or PDP-11 and just set up some x86 emulation on it

  • Ugh. (Score:5, Informative)

    by Sheepdot ( 211478 ) on Tuesday August 16, 2005 @04:04PM (#13332987) Journal
    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.

  • Yes, rootkits are now in Malware (Score:5, Interesting)

    by ErikTheRed ( 162431 ) on Tuesday August 16, 2005 @04:45PM (#13333421) Homepage
    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.

    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 ... 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).

    • Re:Yes, rootkits are now in Malware (Score:5, Interesting)

      by value_added ( 719364 ) on Tuesday August 16, 2005 @07:36PM (#13334938)
      Your post reminds me of something I read on the NTBugTraq mailing list. I don't have a link so I'll quote it below.
      CWS, CoolWebSearch, is a particularly nasty incarnation of ad-ware. CWS is widely discussed on the web, but it's poorly understood and procedures to remove it are often lengthy, cumbersome and ineffective. ... The shield-DLL installs itself to the following registry value in NT4-type systems:


      HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_Dlls

      Per MSKB 197571, a .DLL listed there is "loaded by each Windows-based application running within the current logon session." IOW, any ad-ware found here runs concurrently with _every_ program launched. It is truly astonishing that such a registry location exists.

      Here's what the CWS shield-DLL manages to do:

      1. It prevents almost all registry editors from displaying it as an AppInit_Dlls value. This list includes, but is not limited to: Regedit.exe (even if renamed), Regedt32.exe, Reg.exe, Autoruns, HijackThis, and, my favorite (because I wrote it), the "Silent Runners.vbs" script. The _only_ program known to display it, for unknown reasons, is the freeware Registrar Lite 2.0, available here: http://www.resplendence.com/reglite/ [resplendence.com]

      2. It prevents all GUI and command line tools from listing it or deleting it. This list includes, but is not limited to: Windows Explorer, DIR, ATTRIB, CACLS, and DEL.

      3. The .DLL file has eccentric security permissions (SYNCHRONIZE and FILE_EXECUTE) and is READ-ONLY. Once the shield-DLL is removed from memory, an Admin must reset security to delete the file.

      4. It has a unique name on every system it infects.

      5. It ensures that a BHO starts up with IE at every boot.

      6. If the BHO is deleted, it restores the BHO under a new name at the next boot.
      I'm sure you'd agree it's interesting reading. The conclusions one can draw are numerous, but I can't resist the comment that every time the folks at at Systernals decide to write a program, Microsoft should feel embarrassed.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close