Pages

▼

Wednesday, March 02, 2005

The rootkit saga continues...

Rootkits really seem to be in focus these days, all thanks to Microsoft bringing them to everyone's attention at the RSA Conference. I was reading a piece by Larry Seltzer this morning entitled "Rootkits: Invasion of the Windows Snatchers" (okay, I know...it's been out for over two weeks already...), and had to drop Larry an email and thank him for the breath of fresh air. Larry's article injected a dose of common sense into the issue.

Now, the geek in me comes out...in the early '60s, Arthur C. Clarke wrote in his essay, "Profiles of the Future" that "Any sufficiently advanced technology is indistinguishable from magic." Applying this to rootkits in use on Windows systems, and the concept holds true over 40 years later.

"Not detected by anti-spyware and anti-virus software" != rootkit (not always, anyway)

My point is simply this...too often, an incident isn't fully investigated and what is first suspected to be a rootkit turns out to be something else entirely. I believe that this is due largely to the Windows GUI (which I still believe is meant only to protect the user or admin from himself...). What I mean by that comment is that the majority of the security training for Windows involves interaction through the GUI...click here, check this box, click "OK". However, the GUI tools provided with a native Windows installation are simply insufficient to perform incident response. Therefore, what we end up seeing is that administrators and first responders become limited by their interaction with the GUI, and have no concept of what's going on "under the hood". For example, most folks have very little idea how much the Windows system interacts with the Registry, and where evidence of activity can be found...but I'll leave that for another blog entry.

So that's where education comes in. But the question becomes...how do you educate the folks who need it? Write books? Offer courses? I'm not sure if this works...and I say this because one doesn't see a lot of discussion on such topics.

Why is this education important? Well, while MS's Strider Ghostbuster approach is a good one, there are a great number of machines that may (please note the heavy emphasis on the previous word) be compromised in some way, but can't be taken down for examination. Production machines in ecommerce infrastructures, file servers, or the CxO's workstation...such systems can't necessarily be taken offline. Usually, one needs justification to do so, and one needs facts in order to develop a justification. The education part comes in by teaching administrators and first responders where to look, what to look for, what to watch out for, and how to interpret the data they collect.

Is the concept of rootkits and rootkit detection important? Yes, most definitely so. I did quick search this morning and found the following bits of malware with rootkit capabilities:
Also, don't forget that Rootkit.com is the place to go for information on Windows rootkits.

With regards to rootkit detection, Joanna Rutkowska released flister earlier this year. Joanna's done some pretty interesting work in the past, and I'm definitely going to be adding flister to my rootkit testing infrastructure.

One final thought...I have to get a publicist or something. Sheesh! SysInternals releases RootkitRevealer and is almost immediately /.'d. Others have done work that doesn't seem to be making it into the public (or even the community) view. For example, in my book, I described and provided an initial implementation of tool for performing rootkit detection on live Windows systems, using a behaviour-based approach. I've actually found the code listed online, too (i.e., rkd.pl). Why do I bring this up? Well, how else do you pierce FUD like this?
at

2 comments:

  1. Anonymous5:38 AM

    [...] I believe that this is due largely to the Windows GUI (which I still believe is meant only to
    protect the user or admin from himself...). What I mean by that comment is that the majority of the security training for Windows involves interaction through the GUI...click here, check this box,
    click "OK". However, the GUI tools provided with a native Windows installation are simply insufficient to perform incident response. Therefore, what we end up seeing is that administrators and first responders become limited by their interaction with the GUI, and have no concept of what's going on "under the hood". [...]


    That feature called a GUI is probably the main one of a product which is called "windows" :-)
    And yeah, it is so mainstreamly used to HIDE COMPLEXITY from the user/admin, who then CAN'T do harm to himself anymore (sort of).


    Any reasonably skilled admin has got most "add-on" useful tools anyway: third party tools, scripts, whatever...

    I find it interesting to notice that you have two kind of issuses here, IMHO:

    First, most admins on windows won't know what to do with the advanced CLI tools anyway. To the point that most modern linux distribution try to obtain the admin's favour by copying/reproducing
    those wizard and those functionalities that made Windows famous in the first place. All in spite of the "power of the cli" and "real men don't use cli"-kind of motto's among the *real* unix folks.
    Not everyone does incident response anyway. Some of the folk who CAN do it, are studying it already, and have their toolkit. Those who can't, won't do it anyway, be it with or without a GUI.

    Second (more important), there's no much point in having all of the right tools ON THE system: as you teach us, everything on a machine which is potentially compromised is NOT TO BE TRUSTED.
    So you don't need to have the needed tools and executables to do forensics *on* the system (where they could be replaced, trojaned, rootkitted). You are better off having your trusted binaries on a
    support such as a FORENSICS CD anyway, IMHO.


    Moreover, one thing I understand is that it is more difficult to MONITOR a windows box - think of
    Honeynet project' SEBEK (http://www.honeynet.org/tools/sebek) : it is great on *nx, where it logs all shell activity. On windows, just logging what happens inside of a CMD.EXE is basically nothing of all that CAN happen through the interface....


    So IMHO, Windows is substantially easier to "DRIVE", but substantially more difficult to analyse in general. But this can even be to a lack of documentation, sure. Books like that of yours add a lot
    to make it easier, and so do Eric's posts about Windows Auditing (http://blogs.msdn.com/ericfitz)
    and those of Robert (http://weblogs.asp.net/robert_hensing/).

    ReplyDelete
  2. H. Carvey7:39 AM

    Excellent (think of Mr. Burns tenting his fingers...) comments...thanks!

    You said, "Not everyone does incident response anyway." ;-( Sadly, you're very likely right about that.

    You also said, "...one thing I understand is that it is more difficult to MONITOR a windows box..."

    I'm not sure I agree with that, necessarily. A considerable amount of monitoring can be done of Windows systems, as I've attempted to show through some of the scripts and tools I've mentioned here. In fact, the process monitoring tool I mentioned in an earlier blog entry does a great job of monitoring processes as they're created. No, it doesn't capture what's typed in at the command prompt, but that's something that can be accomplished via other means.

    Finally, you said, "So IMHO, Windows is substantially easier to "DRIVE", but substantially more difficult to analyse in general." I agree. I've often thought that for the information that's out there on collecting data from "compromised" systems, there's not a great deal covering "why" that particular information is collected, or how to actually analyze it. Data collection is easy, and IMHO, data analysis needs to be addressed.

    Thanks for your comments...they're very much appreciated.

    ReplyDelete