| |||||||||||||
Hunting for RootkitsHunting for RootkitsPosted Mar 1, 2007 13:43 UTC (Thu) by vonbrand (subscriber, #4458)In reply to: Hunting for Rootkits by NAR Parent article: Hunting for Rootkits
I remember reading about a kernel-based rootkit which enabled the miscreant to redirect
(Log in to post comments)
Hunting for Rootkits Posted Mar 2, 2007 10:37 UTC (Fri) by drag (subscriber, #31333) [Link] 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.
For example:
System Boots.
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".
Is it used for strengthing 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.
Hunting for Rootkits Posted Mar 2, 2007 16:49 UTC (Fri) by giraffedata (subscriber, #1954) [Link] it's absolutely worthless to run checksums from a running system s/absolutely/somewhat/ There are lots of intrusions that running checksums from a running system do catch. Lots of systems are vulnerable to having important files compromised but not to having the checksumming stuff compromised. And lots of attacks are sophisticated enough to replace a file, but not to disable the checksumming facility. Given how much cheaper doing the checksums on the suspected system is than running checksums somewhere else, it's a good compromise for many systems.
Hunting for Rootkits Posted Mar 3, 2007 9:49 UTC (Sat) by danshearer (guest, #18686) [Link] Some reasonable points, but you can reduce exposure a lot by never mounting executables rw except when you are going to update them, which is a lot easier than all this. And with VMs the update is quite possible external. So the internal system never gets a chance to compromise its binaries. I fact it may not even have permission to do so. You can enforce the same thing on a real machine with various mechanisms such as immutable bits.
RO policies can be circumvented, but it does substantially narrow the possibilities for an attacker.
Mounting r/o + root permissions Posted Mar 8, 2007 23:57 UTC (Thu) by blujay (guest, #39961) [Link] If modifying an executable requires root permissions, and an attacker was able to do so, wouldn't he also be able to remount a partition r/w?
|
|||||||||||||