Hunting for Rootkits
Posted Mar 2, 2007 10:37 UTC (Fri) by drag
In reply to: Hunting for Rootkits
Parent article: Hunting for Rootkits
That is why it's absolutely worthless to run checksums from a running system.
You MUST run tripwire or similar tools from a seperate OS, such as Knoppix or whatnot if you want to beleive their results.
I was thinking that this is a nice reason to run VMs.
For instance if you run your webserver on a Xen-based VM you can then store checksums of the file system in the base install you launch the VM from.
It will have full access to the file system so it's a easy thing to bring the webserver down, run a Tripwire, then boot it back up. You have to take special care though to ensure that the Xen-Linux machine hosting the VM does not become compromised since if that does then ALL VMs running on it are subject to compromise through the most trivial means.
The major concern with Xen is that the Xen-linux system hosting the VMs uses it's own kernel code to redirect I/O to and from the VMs and the real world. If there is a kernel-level vunerability in something like the DM or Netfilter code then you can get hacked.
Otherewise without VMs the only way you can sanely do it is to realy have a machine that is kept off any network completely running Tripwire were you can take a server down, pull the drive from it, and put it in the Tripwire test the FS from there. OR have a network/cdrom bootable system that then reads the checksums from read-only media.
You can never ever trust anything the system tells you if you suspect you've been hacked.
This is also why tools like rootkit hunter and such are mostly worthless against modern rootkits. They are trivially subverted. It's like anti-virus for Windows. Your fighting a loosing game going that direction.
Tripwire (and similar) is the most reliable and only trustworthy way to detect rootkits.
The ultimate solution is to use TPM (yes unstrustworthy computing) to have a 'chain of trust' were each componate of your system checks the next componate.
Bios is checksum'd to esure that it's fine, then runs the bios.
Bios runs checksum on bootloader, then boots it.
Bootloader runs checksum on on it's configuration files, then reads them.
Bootloader runs checksums on kernel, initrd, and I suppose a 'kernel checksum file'.
The kernel boots, initrd loads up.
Once the FS access starts the kernel only loads digitally signed drivers.
Then digital signitures are checked on major system files.
etc etc etc.
Until your system is completely booted up.
Of course this does nothing to prevent a exploit on a kernel during runtime. (say a rootkit is setup to be executed and re-exploit the kernel and inject the viral code each time it boots) But at least you know that after a reboot your system is secure for the time being.
'Trusted Computing' can be a good thing, or a bad thing.
It all depends on who controls the "keys".
If you do, then it's a good thing.
If you don't, then it's a bad thing.
Is it used for strengthing your hold over your own person and property?
Or is it used for weakening your hold over your own person and property?
here is the webpage for 'Trusted Grub', a componate of Linux trusted computing.
Of course this sort of thing is also why people who care about their freedom need to be as paranoid about the software security industry as the RIAA or the movie industry.
to post comments)