rootkit detection theory
Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: rootkit detection theory

  1. #1
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,019

    rootkit detection theory

    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?

  2. #2
    Member
    Join Date
    Dec 2001
    Posts
    31
    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.

  3. #3
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,019
    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

  4. #4
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Location
    Redondo Beach, CA
    Posts
    7,324
    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).
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

  5. #5
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,019
    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!

  6. #6
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    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
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  7. #7
    Member
    Join Date
    Nov 2003
    Posts
    67
    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
    [gloworange]The Only Way to be Safe is To Never Be Secure. [/gloworange]
    Benjamin Franklin

  8. #8
    Member
    Join Date
    Jun 2003
    Posts
    57
    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.
    \"If you take a starving dog in off the street and make him prosperous he will not bite you, this is the principle difference between a dog and a man\" - Mark Twain

  9. #9
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  10. #10
    Senior Member
    Join Date
    Sep 2001
    Posts
    144
    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..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •