Jacco Tunnissen dropped me a line this morning to let me know about the Strider Ghostbuster technical paper from Microsoft. Jacco had read about this on Bruce Schneier's blog (note the date on Bruce's blog entry) and since he knows I'm interested in this sort of thing...
The technical paper lays out an interesting approach taken to detect rootkits. The authors (Wang, Vo, Roussev, Verbowski, and Johnson) take the fundamental approach that in order to be persistent, the rootkit files must exist on disk. So, what they do is insert their Ghostbuster CD into a system, and the CD runs a 'dir /s /a' command against the entire file system, saving the output of the command to a file on the hard drive. Then, the CD boots to a WinPE-based installation of Windows and walks the file system again. Once done, a clean version of Windiff.exe is used to compare the two files.
This is a very interesting development...not so much that it's a "new approach", because I don't think it is...more so because this is coming out of Microsoft. Take a look at the Strider page at Microsoft...I found the GateKeeper paper to be quite interesting.
While I think that there are a lot of positive things in the Ghostbuster paper, I also think that there are some caveats that need to be pointed out. Again, let me say that I think that the Ghostbuster approach is a good one, easy for just about anyone to use. After all, what could be easier than inserting a CD and walking away to get a cup of coffee, and than coming back a few minutes later? Yes, I know it's not entirely scalable, but still. However, the first thing I thought after reading the paper (and admittedly, when I went back to Bruce's blog entry, I found the same thoughts there, too) was that, as good as this approach is, it only works for those rootkits that try to hide files. Oddly enough, some of the most successfully hidden files do not require rootkits or any API hooking techniques at all...simply change the name of the file.
Here's an example...a while ago, I did an analysis of an IRCbot that I dubbed "russiantopz", because the bot seemed to have come from Russia, and the name was found in one of the scripts. When the bot installed itself, it ran two processes...the first was simply mIRC32.exe with some scripts, and the second was a program called hidewndw.exe, which is a simple little program that modified the settings for any window to make it invisible. Hidewndw.exe was launched immediately after mIRC32.exe and effectively hid it from view. Now, admittedly, both filenames had been changed...mIRC32.exe was 'statistics.exe', and hidewndw.exe became 'TeamScan32.exe'. So, while the window for the IRC client wasn't visible on the desktop, there was a process visible in the Task Manager called 'statistics.exe'. When I received initial notification of this bot, I was told that the administrator had checked Task Manager, and there was NO (an emphatic "no") evidence of anything suspicious.
Simply changing the filename is an extremely effective way of hiding something in plain site on a system. Forget hiding executable code in .png files (I didn't make this one up, someone actually said this on the comments to Bruce's blog entry)...that's not necessary. Too often it seems, Windows admins seem to be more interested in discussing all of the possible ways of hiding things, without really getting down to finding them. I mean, think about it...if you know something about computer technology (and something about Windows), you'll know that while there are hundreds (or thousands) of files on a Windows system, it's still a finite number. And of all the entries in the Registry, there are only a limited number of auto-start locations.
On a side note, ProDiscover from TechPathways is a forensics toolkit that includes a similar functionality in it's Incident Response version. Basically, it walks the file system using 'dir /s /a', and then walks the actual MFT.
One more thing...I took a pretty good look at the Ghostbuster paper and while I was impressed with the overall concept coming out of MS, I was taken aback by a couple of simple things. In a nutshell, I took a look at the rootkits they'd tested their methodology against. Two in particular jumped out...HackerDefender 1.0 and AFX Rootkit 2003. First off, as I've blogged about before, RKDetect already detects the presence of HackerDefender, without having to reboot the machine. In fact, some modifications (I'd use Perl myself) to the script would allow it to run against a set of machines, or an entire domain. I also presented a rootkit detection methodology in my book (along with a sample script) that can detect some rootkits, such as this. Further, I did an actual analysis of AFX Rootkit 2003 (haven't worked closely with the 2004 version yet) and found that it was pretty trivial to detect.
Thoughts?
2 comments:
I haven't checked out the papers yet, but it would seem to me a pretty useful tool would be something that does a hash value on each file and excludes it by comparing it to a set of known has values. If the hash doesn't match a file that also shows up in a dir /s /a, wouldn't that be an easy way of picking out these files that are renamed? Maybe I'm totally off base, but we use that in the forensic community as a way of eliminating known good files.
Excellent idea, and I do think that the Ghostbuster paper mentions hashes at one point...I'll have to go back and check.
Data reduction is always good...if you can winnow down the data, you're more likely to focus on the important things.
However, given Windows 2000, XP (Home and Pro), and Windows 2003, with all of the various Service Packs and Hotfixes for each, I wonder if something like that may fit on a CD. If not, perhaps the CD would need to be able to "phone home" in some manner.
One thing that is evident, though...while hashes are a good idea for data reduction, they're also used to solve a problem that isn't something that's specifically addressed by the Ghostbuster paper. The issue raised in the Ghostbuster paper is that of files hidden by API hooking (or other mechanisms employed by rootkits). Data reduction is inherent to the method used by Ghostbuster. Much like tools written for *nix, Ghostbuster does one thing, and does it well. I think Windows users are probably too used to "feature creep", where a great deal of additional functionality is added to a simple tool.
Besides, if you hash a file, rather than simply pull it's name and last access time from a directory listing, you inherently alter the last access time of that file. The initial description of the tool in the Ghostbuster tool inherently preserves that information.
It's definitely something to consider...
Again, thanks for the excellent comments.
Post a Comment