Weekly Edition
Return to the Security page
| |||||||||||||
Hunting for RootkitsAdministrators like to know what processes are running on their machines, with good reason as they are responsible for ensuring that no unwanted or malicious software is present. Rootkits are a means of evading administrators, hiding the presence and the execution of certain programs. Probably the most famous rootkit is the one that Sony so helpfully installed on Windows boxes when their owners tried to play a copy-protected audio CD, but they exist for Linux as well. It is critical for administrators to understand what rootkits can do and how they do it in order to protect their systems against this kind of attack. Rootkits come in multiple flavors, depending on what level of the system they subvert. The simplest just replace binaries of various programs to hide; for example, running a backdoor shell server masquerading as a standard long-running service (like httpd or ntpd) and patching netstat and other tools so that the listening socket is not reported. System libraries are another likely place for rootkits.. If a rootkit can replace glibc, it can intercept system calls made by any of the standard tools allowing it to hide anything that it chooses from those tools. Kernel and boot rootkits are the most difficult to detect. Loadable kernel modules can change the kernel's behavior in very intrusive ways and allow all manner of malware to run undetected. The lowest level rootkit changes the Master Boot Record (MBR) of the system to load itself before the kernel at boot time. After that the rootkit can run the kernel in a virtual machine and intercept every instruction that it executes. This is the ultimate in rootkits and can be made undetectable from within the running kernel. Trying to detect a rootkit installation while running the potentially infected system is a dodgy prospect at best. Because the rootkit is specifically designed to avoid detection it could be subverting any technique used to look for it. The important thing to notice is that in order to operate, the rootkit must change things about the system and in order to persist across reboots, it must write those changes to the disk. This provides the means to detect them. To avoid running afoul of the rootkit while trying to detect it, one should boot from a live CD and run a rootkit detector from there. There are a number of distributions specifically targeted for this kind of analysis; Helix and Aghesa for example. Both of those distributions contain the two leading Linux rootkit detecting programs: chkrootkit and Rootkit Hunter. These programs look for things in the filesystem that correspond to rootkit signatures: hidden files and directories, logfile changes, non-standard kernel modules, etc. In addition they look for the signature of various 'in the wild' rootkits. Another helpful tool in recognizing the presence of rootkits are programs that track changes to critical files and directories. The most well known is probably Tripwire, but others such as AIDE and Samhain are available as well. These programs keep a record of each file in the system (using a digest like MD5 or SHA-1) and can alert the administrator when one of them changes. They also keep track of files and directories that get added or deleted. Prudent administrators will, of course, keep the records on a separate machine or on read-only media so that they cannot be tampered with by rootkits that infect the machine. The biggest problem with these kinds of programs is false positives each time a new package is installed, but for relatively static systems, an alert email from those checkers is an enormous red flag. A very interesting sounding rootkit detection toolkit called Rootkit Profiler LX was recently announced on the Bugtraq mailing list. It is a linux kernel module that gets loaded into the running kernel of a machine suspected of harboring a rootkit and has an impressive sounding list of capabilities. It is not available in source form which makes it of dubious utility; it could after all, be a rootkit itself. One could argue that using binaries from the live CDs is no different, and in some ways that is true, but one could in principle inspect the code and build their own version rather than trusting the distributor (of course they have to trust their compiler and other components; security paranoia can run deep). Once a rootkit has been detected, it is probably a waste of time to try and remove it. Reinstalling the operating system is the safest course. The time spent trying to remove every last piece of the rootkit and the malware it hides would be better spent determining how the rootkit was installed to begin with. If there is a vulnerability in one of the programs that run on that machine, it is pretty likely the rootkit (or some other) will return. Of course, the rootkit, in and of itself, is not a huge problem; it is the malware that it hides that makes all the trouble. (Log in to post comments)
Host integrity monitoring Posted Mar 1, 2007 4:09 UTC (Thu) by anchorsystems (subscriber, #40101) [Link] Another useful host integrity monitoring tool is Osiris.
Hunting for Rootkits Posted Mar 1, 2007 5:55 UTC (Thu) by drag (subscriber, #31333) [Link] Not that I am a expert so take it for what it's worth...
It's also probably worth mentioning that these things are only usefull for _detecting_ rootkits.
Removing and disabling rootkits is another problem entirely.
In my opinion once you detect a rootkit, even if it's a stupid dinky one, that you should considure that paticular OS dead. It's not worth the time, effort, or uncertainty its going to take to clean that thing off.
Pull the plug on the computer (don't shutdown) take a image of the harddrive for safe keeping, format the drive and go on with your life.
Shutting down Posted Mar 8, 2007 23:53 UTC (Thu) by blujay (guest, #39961) [Link] Sometimes it might be a good idea to use the SysReq keys to remount partitions read-only, sync, and then shutdown or reboot. Since those commands go directly to the kernel, they would work unless the rootkit was on the kernel level, and might help prevent lost data.
They can also be helpful if X locks up your screen or keyboard.
Hunting for Rootkits Posted Mar 1, 2007 8:38 UTC (Thu) by NAR (subscriber, #1313) [Link] These programs keep a record of each file in the system (using a digest like MD5 or SHA-1) and can alert the administrator when one of them changes.A couple of years ago there was an article about a method that could generate a PDF file with different content but with the same MD5 digest value. Is that method applicable to config files, shell scripts and binary executables too? After all, config files and shell scripts can have comments where the necessary binary string can be inserted to fool the MD5 digest.
Hunting for Rootkits Posted Mar 1, 2007 9:06 UTC (Thu) by tadmini (guest, #41980) [Link] That is why some tools keep both MD5 and SHA-1 checksums. I am sure it is very difficult to modify the file and keep *both* checkums unchanged.
Hunting for Rootkits Posted Mar 1, 2007 9:14 UTC (Thu) by Los__D (guest, #15263) [Link] AFAIK it requires changing the length (because the same MD5 is found by padding the file). If the length of the files is also stored, it'll suddenly get a whole lot harder to create the right MD5 sum.(But of course, if the new content of the file is much shorter than the old content, there's quite a bit of space for doing padding).
Hunting for Rootkits Posted Mar 1, 2007 12:30 UTC (Thu) by MathFox (guest, #6104) [Link] One could create two similar files that hashed to the same digest value. It is possible to hide them in binaries (executables and libraries); they stand out in text files.Getting one of those patters into a Linux system requires a compromise of the distribution site; but when you do that it's far easier to upload a simple trojan horse.
Hunting for Rootkits Posted Mar 1, 2007 13:43 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
I remember reading about a kernel-based rootkit which enabled the miscreant to redirect
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?
Hunting for Rootkits Posted Mar 1, 2007 19:43 UTC (Thu) by tialaramex (subscriber, #21167) [Link] Specifically the method generates _two_ files (not plain text but it could easily be PDF, HTML or various other formats) with the same MD5 digest value.
The files have the same length, but a block of nonsense (wrapped with a comment, or in a hidden inline image, or concealed in some other way) is different between the two files. A suitable feature of the file format is needed to make the apparent contents conditional on the nonsense data.
There is no way to use this attack, or any variation on the attack, to create an imposter for an existing file.
The threat model for which the attack is relevant is digital signing of third party documents. Imagine a company uses digital signatures to authorise purchase orders instead of hand written signatures. Suppose you're allowed to sign for POs up to $5000 without confirmation. A salesman from a new company offers you a great deal, for $200 you can get the parts you'd otherwise need to spend nearly $500 on elsewhere. He sends you a PDF to sign, which shows the $200 price, you sign it, and once the parts arrive you forget about it, central finance can do the paperwork. A few months later you're called into your bosses office because you've gone way over budget. The salesman, and the money, are long gone, but there's a PDF, signed by you, which clearly says the price is $4000 and so central finance paid the invoice.
If you use binary executables, or even certain types of configuration file, which have unexplained content, and you don't trust the party which created them, then you have a problem. You'd be vulnerable to this attack, but more importantly, you're already running untrusted code. If you trust the people who built your program executables, wrote your configuration files etc. then the known flaws in MD5 and SHA-1 are nothing to worry about in this particular application.
Two files with the same MD5 digest Posted Mar 2, 2007 17:03 UTC (Fri) by giraffedata (subscriber, #1954) [Link] So let me get this straight: The salesman created two contracts: one said $200 and the other said $4000 and they both have the same MD5 digest. I signed the MD5 digest. The Accounts Payable people are pretty stupid then, aren't they? With $4000 at stake, they should demand a signed copy of the full contract. But I'm sure if we think hard enough, we can find a case where signing a whole file is impractical and this twin-file technique would work.
Two files with the same MD5 digest Posted Mar 3, 2007 14:23 UTC (Sat) by kevinbsmith (guest, #4778) [Link] No, you signed the full $200 contract. Signing a digest is the same as signing the document. If the vendor delivers the contract to Accounts Payable, with your signature, they could deliver either the $200 contract (signed by you) or the $4000 contract (also signed by you). To foil (or at least detect) the attack, YOU would have to deliver the contract (the $200 one that you think you signed) to Accounts Payable yourself.
But this is just an example story, so don't get caught up in the unimportant details. The attack is possible any time you MD5 sign a document that was created by someone else.
The trivial defense is to make slight changes to the document before signing it. Even adding a few spaces. I suppose the other defense, at least to help you later in court, is to be sure to keep an archive copy of everything you sign.
At least that's my understanding. I'm not a crypto expert.
Two files with the same MD5 digest Posted Mar 3, 2007 19:10 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Signing a digest is the same as signing the document. In what way? As we've shown here, fraud is possible when you sign the digest and not when you sign the full document. That's a big difference. If I sign the full document, that means I encrypt the actual PDF with my private key and send the result to the salesman. He forwards it to Accounts Payable, which looks up my public key and decrypts it. The result is a PDF in which AP must see the same price I saw when I signed it. People like to sign digests instead because it uses less resources. Sometimes the tradeoff is worthwhile.
To foil (or at least detect) the attack, YOU would have to deliver the contract ... to Accounts Payable yourself. the other defense, at least to help you later in court, is to be sure to keep an archive copy of everything you sign. Those defeat much of the purpose of the signature, either allowing me to defraud the vendor or leaving an open question of what the agreed price was. It would be no worse than paper, though, where the salesman can take the signature sheet off the $200 contract and staple it to the $4000 one. Electronic signatures have the wonderful advantage over paper of non-repudiation. I can't deny that I authorized $4000 if I did.
Hunting for Rootkits Posted Mar 2, 2007 2:36 UTC (Fri) by smoogen (subscriber, #97) [Link] When keeping track of checksums, one needs to do the following:
One figure out if the system is using some sort of prelinking. If it is.. then your system will go through and change the checksums itself. make sure whatever tool you have can deal with prelinking by knowing how to check around the prelink area.
Two, use two different algorithms AND make sure you keep a copy of the sizes of the item. Differing algorithms would be like using whirlpool AND sha-2 as I am pretty sure they are not related closely enough for a similar attack to be useful.
Hunting for Rootkits Posted Mar 2, 2007 10:39 UTC (Fri) by drag (subscriber, #31333) [Link] Also Checksumming is only usefully ran from a different system then the one your testing. (example: Knoppix using Tripwire to test a webserver)
LiveCDs for security Posted Mar 1, 2007 13:30 UTC (Thu) by vonbrand (subscriber, #4458) [Link] The distributions mentioned in the article seem abandoned (last news some six months old), better mention newer ones. A personal favorite is INSERT, a Knoppix-based mini distribution that fits a credit-card size CD.
Signed Executables. Posted Mar 2, 2007 2:57 UTC (Fri) by aashenfe (guest, #12212) [Link] I know it maybe it smells a little of DRM, but is anybody considering signed executables/modules.
I know RPM based distros are alread doing this type of thing as far as installing packages.
I think having the system refuse to run anything that might be suspect would be a very good way to increase security, and prevent rootkits in the first place, plus changed binaries would no longer match their signature, so rootkit versions of programs would spit out security violations instead of running.
As long as there is a secure way for adminstrator/user to resign an executable, or import/create new keys. Plus safeguard against executables detecting how they are signed (I'm not sure how this would be done) to avoid DRM like fuctionality.
There would also be levels of signature so an executable signed by a user could only be run by that user, but root would be able to sign for the systems of course the private key would have to be on the system for this to work. It would be the same for importing keys. Root could import for all, and users would import for themselves. Or a particular account other than root could be configured to skip signature tests for developers.
Also if a system needed extra security, all signing/importing could be disabled in such a way it can not be reconfigured without booting single user.
So is this even a good option? Is there to much overhead with all this signature checking? Is it imposible to stop this from being used for DRM. How would this work for non-binary languese (shell, perl, etc)
Signed Executables. Posted Mar 2, 2007 6:57 UTC (Fri) by tetromino (subscriber, #33846) [Link] You have basically described a selinux system with a gpg-aware package manager.
Signed Executables. Posted Mar 2, 2007 15:34 UTC (Fri) by aashenfe (guest, #12212) [Link] Very true. SELinux can and probably does provide this and way much more.
I think "way much more" might be the problem.
When I'm looking around for different howto's for certain setups, a number of time it says they disabled SELinux to get the system to work correctly. I try to leave SELinux enabled if I can, but sometimes I still give up and disable it. I'm sure there is a way to configure SELinux correctly, and maybe I'm irresponsible for not figuring it out.
I like the Idea of signed executables because it targets one security question. "Do I let this executable run?" SElinux or AppArmor can then answer the harder to setup question "What do I let this executable do? "
Signed Executables. Posted Mar 2, 2007 10:45 UTC (Fri) by drag (subscriber, #31333) [Link] Remember that you can't trust a root comprimised system to be honest about the checksums and signitures.
A kernel-level rootkit (all non-trivial modern ones are) can make any file it modifies come back with any value or checksum it wants by interecepting system calls and such things from kernel-land.
This is a major problem for Windows since the systems are trivially compromised there is no reliable way a Virus scanner or Anti-adware applicaiton to successfully clean a system.
Signed Executables. Posted Mar 2, 2007 15:09 UTC (Fri) by aashenfe (guest, #12212) [Link] >Remember that you can't trust a root comprimised system to be honest about the checksums and signitures.True, but I was hoping signed executables, and modules would help prevent a kernel level compromise in the first place. At least for the older rootkits that are unaware of the new security.
Helix has an absurd license. Posted Mar 8, 2007 23:48 UTC (Thu) by blujay (guest, #39961) [Link] The EULA on the Helix site is pretty absurd. It claims that you can't distribute or sell the CD, and that you can't even use the CD in work you are compensated for without contacting them first. All that, and the disc is probably at least 99% Free Software.
|
|||||||||||||