Robert seems to be busy keeping the rootkit saga going over on his blog, with some interesting tidbits about how RootkitRevealer interacts with HackerDefender. Evidently, the bad guys are including the RootkitRevealer process name in the HackerDefender config file, and the result is that RootkitRevealer isn't reporting the existance of the rootkit. In a nutshell, this is because the RootkitRevealer process runs as a root process, and the rootkit files themselves aren't hidden.
In order to combat this, Robert suggests changing the name of the RootkitRevealer file to something different, possibly a random name. This would work, and the ensuing discussion via the comments on his blog entry lead into various ways the bad guys could counteract this tactic.
This reminds me of the old arms race/escalation issue in the military. For example, man invents tanks. Then some other guy invents a way to disable a tank. These two guys go back and forth, one guy producing heavier armour, the other guy coming up with advanced tactics. Finally, some guy invents the TOW Missile. So the tank guys come up with reactive armour. So then the missile guys improve their missiles with a probe, giving the missile standoff...the probe sets off the reactive armour, leaving a space for the missile to continue on through.
See how that works? In Robert's blog the comments go to changing the name of the RootkitRevealer executable, to the bad guys hashing the executable images, to the good guys padding the executable, etc. The next logical step would be the bad guys using some sort of anti-virus-type technique to identify the RootkitRevealer process.
However, the key is that all of these steps are purely reactive in nature. The good guys could get around this by (a) improving their prevention mechanisms, and (b) changing their detection tactics. Sound prevention mechanisms have been around for a while...perhaps they just aren't being used, or used employed in an effective manner. The other option is to change detection tactics, and one possibility is to use techniques I talked about in my book. If you don't have the book, I found a copy of the rootkit detection script (ie, rkd.pl), online. I'm being redundant, I know, having posted this before, but I thought it deserved another look.
A tool that may be of use with kernel-mode rootkits on Windows systems is KProcCheck. According to the web site, this proof-of-concept tool directly accesses the kernel structures and enumerates through the process and thread lists, looking for disparities. KProcCheck may definitely be something worth checking out...the latest beta version supports XP.
As a side note, I wanted to comment briefly on one of the comments that appeared on Robert's blog entry...the comment was "SysInternals could generate a random name as well I suppose, at the cost of convenience to the user. If they did so and generated a rootkitrevealer.lnk shortcut from which to launch it would that be traceable by hxdef?"
Don't get me wrong...I'm not going to be high-and-mighty here, nor am I going to be preachy. However, I see this kind of thing all the time at conferences and in courses. People just throw questions out without really reasoning through things themselves first. With regards to the above comment...first, why should SysInternals generate the random name for the file? Second, when a process is running, there isn't anything associated with the process that indicates how it was started...did the user open the "Run..." box, or double-click a desktop shortcut, or was the process launched via the ubiquitous HKLM\..\Run key in the Registry? So, then, how would any other process determine this based on information that does not exist?
Thoughts? Comments?
No comments:
Post a Comment