| |||||||||||||
Hunting for RootkitsHunting for RootkitsPosted Mar 1, 2007 8:38 UTC (Thu) by NAR (subscriber, #1313)Parent article: Hunting for Rootkits 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.
(Log in to post comments)
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)
|
|||||||||||||