Six Rootkit Detectors To Protect Your PC

An anonymous reader writes "InformationWeek has a review of 6 rootkit detectors.This issue became big last year when Sony released some music CDs which came with a rootkit that silently burrowed into PCs. This review looks at how you can block rootkits and protect your machine using F-Secure Backlight, IceSword, RKDetector, RootkitBuster, RootkitRevealer, and Rookit Unhooker."

Comments

Security solutions

[chris(pinecone)]

Shouldn't these tools be a part of already-existent anti-virus solutions? Why another application for rootkits if trojans, virii, and spyware detection are (usually) in the same package? It's not like rootkits are new threats.

Nervous about these...

[ubuwalker31]

Is it just me, or am I being overly cautious not wanting to download a rootkit detector from Chinese and Russian software developers? Are these programs opensource? Are they safe? Anyone?

Re:Nervous about these...

[gooman]

I swear, that's the first thought that ran through my head.
I'm sure they'll detect every rootkit except the one they install.

Why am I so paranoid?

Oh yeah, I run Windows.

Wow....

[Creepy Crawler]

Wow! Lets rate programs on diagnosing a potentially lying PC!

This is just a stupid idea if anything. The purpose of a rootkit is to make a very hidden hole into a system. Doing this requires reprogramming and setting up the system in that nobody can diagnose itself. The key is to diagnose any sort of rootkit, one must run from known good binaries.

Now, we dont have the source to Windows, but we have binaries. Well, lets MD5 the binaries and then compare to a known good (just installed, no network interfaces) installation. The differences are possible holes.

No program can be trusted when the system it sits upon cannot be trusted. When system trust is gone, one must redeploy the system to regain trust.

Re:Wow....

[Creepy Crawler]

---If a native app can analyze the disk volume directly it can identify malicious drivers and reveal them to a friendly Win32 application that can remove them after a reboot.

Oh bother... If I had a Kernel Level rootkit, I can SHIM all your commands through it and filter what I want you to see. You can guarantee that I will hide my program ID, memory used, swap used, location on fixed disks, and any network data transmitted/received. As far as you know, the system will be "ok". But it'll be OK, because you can analyze the volume directly!!

---This works for user mode and kernel mode rootkits, but if there's a BIOS rootkit you're pretty much screwed.

Sure. If you have to run a "checking program" on a corrupted system, what makes you think you'll get good results? I keep drilling this point, but all you do is give dumb comments. And bios rootkit? Good luck with that one. You all might wannna give LinuxBios some help if you can flash WORKING hacked firmwares to the multitudes of X86 boxes. Oh... you mean diddle with the ACPI tables. Welllll.. Bah.

---See my previous post, Norton AntiVirus 2007 operates in this way.

I ignore ads.

Re:Wow....

[EvanED]

Oh bother... If I had a Kernel Level rootkit, I can SHIM all your commands through it and filter what I want you to see. You can guarantee that I will hide my program ID, memory used, swap used, location on fixed disks, and any network data transmitted/received

If that's ALL you hide, then you'll be found by all of these tools.

You ALSO have to mess with low-level I/O requests; if an application can say "I want block #17" you need to be able to mutate the returned data if it's a directory block or something like that. On Windows if you have detectable information in the registry, you also need to intercept all requests to the registry hives (either by file name or block number) and mutate the information in them to hide your data.

If you can analyze the volume directly (and be sure of the integrity), you CAN'T hide data on it.

If you have to run a "checking program" on a corrupted system, what makes you think you'll get good results? I keep drilling this point, but all you do is give dumb comments.

I don't think there's a rootkit now that has the sophistication to hide from all the above avenues of detection.

There's no reason why they MUST work, but for now they do a decent job.

Re:Wow....

[EvanED]

Wrong. If I control the CPU as kernel level, I can do anything I want.

That's true.

The OS is too untrustworthy after you hook it on a network (in Windows case especially).

Windows is no more vulnerable once you've got a kernel hook than Unix/Linux/whatever is. If anything, Linux is more vulnerable because figuring out the appropriate places to hook in Windows is a lot harder without source.

("Security through obscurity" is a bad idea -- but obscurity can be a layer and be helpful as long as you design and implement the rest of the system as if the obscurity wasn't there.)

(The increased vulnerability of Windows comes from the fact that it's easier to inject your code. The above only applies once you have a suitable kernel of your code running in ring 0.)

What does Kernel Level mean to you?

It means you're running in ring 0, privileged mode, CPL 0, whatever you want to call it. It means you can *theoretically* do anything.

I'm just saying that I don't think there are any non-VM rootkits that hide themselves so thoroughly that they can't be detected, because doing so is a difficult problem because there's way more that you have to trap if you want to be completely hidden than it initially seems. Like ALL I/O requests.

Or rather, does Microsoft allow you to do extensive reprogramming? I know of extensive Linux kernel, GLibc, and usermode program backdooring. You hit one, and theres still all the others. Essentially, if you have no reference system to verify good data/files, you're screwed.

Again, in theory, yes. In practice, now, there's still a lot you can do.

Assuming you'd actually store data in the registry if you're using a backdoor. That just strikes me as friggin stupid.

It really isn't; it's a perfectly legit method of ensuring that your rootkit is loaded if you can deal with the low-level/high-level scan thing or don't care if it's detectable with that method.

I'd store my data across the whole system in stupid stuff like user settings, whitespace on text and html files, files near commonly executed programs, and other various random places. And the backdoor would be hidden in plain sight, but in no recognizable form. It should take no more than 50 KB to start a backdoor, and the rest loaded from a distributed amount of places that the backdoor would have access to... local machines and the internet.

That's fine.

Remember, my point is that if you have detectable information on the disk (e.g. something you could find with a signature-based scan), you MUST be able to vet all I/O requests to the disk. That means requests through the file APIs, requests for specific blocks sent to devices, and I/O requests that might be issued from other drivers. (For instance, you have to be prepared for detection software to load its own device driver and issue I/O requests itself.) Of course, if you can intercept all I/O instructions then the first two come free. Your rootkit must then be able to mutate the data that's returned so that it hides its presence but is still sane. This very well may mean that you have to understand NTFS and FAT, though it's possible that you could get all needed information from existing kernel data structures.

I don't think such a rootkit is known to exist right now, and I don't think we'll see one. It's now easier to drop the OS into a virtual machine and have a VM-based rootkit. (Though I'm somewhat skeptical about a sudden loss of speed tipping people off, it should be possible in theory to make this undetectable to software running in the guest OS.)

Re:Rootkit

[chris(pinecone)]

Most rootkits target *nix. OS X is a Unix variant. But since Macs don't ever get viruses, I'm sure it would be impossible to get past Apple's expert, fully-secure software.

Re:I am the author of AFX Windows Rootkit 2003

[EvanED]

Also, making the same attack persist after reboot is only a matter of disabling SFC and altering userinit.exe, explorer.exe or whatever you like. Your rootkit detector will come up clean everytime.

But if you don't hide files, you leave yourself as open to signature-based detection as viruses are, so your typical virus scan should pick it up. Even if you can obfuscate yourself well enough to hide from signature-based scans, if you alter system files like userinit or explorer, you are vulnerable to tripwire-like systems.

So if you want to protect against that but remain persistent, you're back to hiding files or file data, which means you have to address the low-level/high-level type scan that these tools do.

change mod from

[John Jamieson]

The review was for tools for the Windows PC, not the MAC or Linux. Sorry this was not more evident. The parent is (without knowlege) implying that the Mac is not vunerable to being rooted. And some fanbois are modding this funny? This might be funny, IF IT WERE TRUE! Not only are MAC rootkits possible, they exist. Do a google search before you post and it will prevent mistakes like this. (Yes I know, I run a risk of hardcore fans modding me down)

Hunting down the bad guys like Dirty Harry.

[toadlife]

I find it curious and a bit disconcerting when I see how much emphasis people place on the subject of malware detection in the realm of information security. What to do after malicious code finds it's way onto our systems, or into our networks is certainly something to consider, and any security plan would be incomplete without it, but this area takes up far too much of our time, given that other aspects of security bring a much more favorable cost/benefit ratio.

I can only surmise that there is certain "sexiness" to malware detection; much the same way that fancy home alarm systems are the first thing that many think of when contemplating home security.

In the home security market, advertisements depict evil prowlers dressed in sweat-suits busting through the back door of the house, while a frightened soccer mom with her five year old daughter cower upstairs. The alarm sounds, the prowler runs away, and a call comes in from the alarm provider, asking if they are ok. Quite dramatic. Quite unrealistic too.

In the information security market there are no soccer moms, and the prowlers don't run around in matching sweat-suits, but the theme is similar. "Buy our product - it will catch intruders when they enter and save you." Again - quite dramatic, and quite unrealistic.

In the real world, people forget to turn on their alarm systems, or they forget to change the batteries, or intruders know how to disable them without triggering them.

In the real world, people also forget to update their AV/IDS signatures, or turn their security product off for various reasons - usually convenience-related, or like the prowler in the home, malware simply disables the security solution on it's way in.

Just as in securing a home, we would be better off if we first focused on installing heavy doors and deadbolts on all outside entrances, in the virtual world, we would be better off focusing on the barriers that malware must overcome to gain entry to our systems and access to our information and resources.

This is far from an original thought, but I'll say it anyway as it deserved to be repeated. The security industry is a joke. It's is filled by people who either don't understand the basic pricipals of information security, or do but choose to to sell 'sexy' solutions anyway. I once ran into the author of a somewhat popular Windows security product on a messageboard and was shocked at his aparent lack of understanding of how his platform of choice, Windows, worked.

I supposed this is more of a Windows problem than anything else. Not a problem with Windows, the operating system, but a problem with WIndows, the culture.