rootkit detection theory

[groovicus]

Due to the difficulty of detecting rootkits (because they are easily modified), I got to wondering about maybe a different approach to detection/prevention that I hadn't seen covered anywhere. Since I am a Linux newbie, maybe something like this is already implemented, and I haven't found it yet.

One of the difficulties with rooting windows lies in the implementation of Windows File Protection (XP) and System File Protection (WinME), which in my understanding, are a built in intrusion detection system. Without getting too long winded, upon startup and at regularly scheduled times, WFP scans sensitive files to see if they have been altered. When it detects a change, it looks in the dllcache, driver.cab, or the original installation files to see if it is there. If it finds a good version, it over-writes the bad version. If it can't find a good version, it pops an error message.

Does linux incorporate a similar system? I t seems to me that it wouldn't be too difficult to implement, but I am not a coder. For all I know, it opens another can of worms.

Any thoughts?

[cire]

there is a similar program called tripwire. it checks the integrity of files. more information about it can be found at http://www.tripwire.org/

hope this helped.

[groovicus]

Thank you for your effort, but Tripwire only alerts you if a file has changed? It does nothing to "repair" the file. Or once again, do I not know what I am talking about? I haven't had my foot in my mouth for a couple days

http://www.techspot.com/tweaks/wfp/index.shtml

[MrLinus]

groovicus, AFAIK, I've never seen something similar in *nix but I will say this: WFP is also to ensure that users don't delete -- stupidly -- important files. How effective it is at protecting against trojans, etc. I don't know and have doubts given the fact that many Win2K/XP boxes do still get compromised (WFP first appeared with Win2K).

Also, given the flexibility that Linux offers, I'd imagine it'd be hard to set something like this up since default locations wouldn't necessarily apply (something that is hard-coded into Windows).

[groovicus]

Thanks Mittens, that's kind of what I thought. I maybe incorrectly implied that WFP was a protection mechanism...it is merely an indirect benifit. In order to root a window box, you would have to alter the default scanning option set in the registry..so that makes it a little more problematic.

So in theory, then, as long as my "app" knew where to look for good copies, such as on a cd-rom, or encrypted virtual drive, then it is feasible...not necessarily easy.

Cool!

[Maestr0]

WFP can be disabled through the registry (aka "The Achilles Heel" of Windows)making it fairly worthless as a protection against malicious modification of system files. Something probably roughly equivalent would be to mount your filesystems which contain important binaries (aka /usr,/sbin etc) as a read-only file system, this of course can be reversed if you have root. Another little trick is to mount /tmp with nosuid and noexec to keep an exploit from dropping SUID files in /tmp as they so love to do.


-Maestr0

[phantomj104]

Hello All

I guess you could check Here..

http://www.google.com/search?sourcei...Kits+Detection

But I am assuming you allready Have.....

Cheers and Best Regards

[Gump]

Groovicus,

Root kits come in three basic flavors, user level which arer like executables, application level that hide in other executables, and then Kernel Root Kits. The first 2 should be fairly easy to detect in the manner that you are discussing (Relatively that is). But a kernel root kit would just lie to any of the other programs you had running to check for integrity or changes etc.. For a kernel root kit the only thing that comes to mind would be to boot from an external known good kernal like a clean knoppix STD or some other bootable disk that you know is clean and check from there. Once it owns your Kernal How do you trust anything from that point.

You could compile your Kernel and set it to not accept KMods, that would be a preventative. ALthough I'm sure there is a way around that too. Anyway just my thoughts on this discussion, hope I added something to it.

[slarty]

WFP is designed to protect system files from accidental overwriting by well-meaning programs run as an administrator user. These are usually installers for older programs which don't check file timestamps before overwriting them.

WFP can be disabled programmatically by an admin user and hence the files overwritten anyway.

Windows rootkits can do that, or possibly operate on a lower level still and stick kernel hooks and stuff in. This enables them to overwrite the files anyway, or modify stuff in an undetectable way.

This brings me on to my main point

Tripwire etc, detects changes in files. A kernel-based rootkit is capable to masking those changes, to make the files appear unchanged, thus defeating Tripwire.

The only way of checking the files totally reliably, is to do the file checking with the system booted from a known safe medium (notably, CD-ROM) to ensure that Tripwire itself, required libraries and system components (i.e. kernel) have not been modified. This is inconvenient for network servers as it requires physical access (or at least remote console) and involves taking the machine offline.

Otherwise, a rootkit can quite easily defeat Tripwire.

There are kernel IDS methods which attempt to spot kernel intrusions; they can also be defeated, Phrack has made several articles which explain methods rootkits can use to defeat these.

Slarty

[g00n]

I was under the impression that tripwire worked by creating md5sums of the files you wanted to watch, then compares the md5sums periodically and tells you what if anything has changed.

to beat that you would have to stop tripwire from running, or overwrite the md5sums with the new md5sums of the new files... without letting tripwire know you've changed anything...

i've only briefly used tripwire, but it is possible for the md5sums to be on a FS that is mounted just before the scan, and unmounted afterwards.. therefore hiding the signatures until they are needed...

making it that much harder to bypass..