Plugin to check MD5 sum on certain files

[Andreas Ericsson]

Dan Stromberg wrote:
> Oh Andreas...  What am I going to do with you?
> 

Thank me for teaching you a thing or two? Press charges? I left the 
reply to this email on jesus.nac.uci.edu (or wherever one of its open 
ports are forwarded to). Let me know if you find it.

Since you probably won't (don't reboot or it's lost forever), you could 
also explain to me why you're going through all this trouble building 
hoops to hop for people trying to install trojans when they can just 
compromise the system all over again (in about 30 minutes, including 
vuln research) and use whatever binaries are already there.

In all fairness; If you've done your homework and set up networking 
daemons in chroot jails running as dedicated pseudo-users, the 
compromise wasn't complete.

If anyone else is interested in the answers, let me know off-list. I 
don't want to take away the incentive and spoil the surprise for Mr. 
Stromberg.

Proof of concept code for the exploit used will neither be handed out 
nor pointed to (not on this list anyway).

> On Mon, 2004-11-08 at 15:19, Andreas Ericsson wrote:
> 
>>First off, I'm on the list. There's no need to send me two additional 
>>copies with each reply that goes to the list.
> 
> 
> You're fighting a losing battle.  Too many e-mail programs make it the
> path of least resistance to cc broadly.  Set up procmail once to
> eliminate duplicates - headache gone.  No more useless badgering people
> to do things your way.  :)
> 
> 
>>With that out of the way, answers below.
>>
>>Dan Stromberg wrote:
>>
>>>On Sat, 2004-11-06 at 05:03, Andreas Ericsson wrote:
>>>
>>>
>>>
>>>>>I believe this would be difficult - generating a trojaned ls with the
>>>>>same md5 sum.  md5 is designed to distribute small bits of a file, from
>>>>>all over within that file, across different parts of the digest.
>>>>>
>>>>
>>>>You're attacking the wrong end of the problem. If someone can trojan 
>>>>some of your binaries, they can trojan ALL your binaries (assuming 
>>>>you're not a complete idiot who have given write permissions away on 
>>>>some of your $PATH directories to non-root users).
>>>
>>>
>>>Trojaning binaries in a read-only, NFS mounted volume is possible, but
>>>difficult.
>>>
>>
>>No, it's simple. It's merely an exercise of replacing a few more 
>>binaries and then remount that same part of the system using a local 
>>filesystem. It's security by (not very) obscurity: Useless.
> 
> 
> Conceptually simple, but far beyond the average script kiddie to
> implement until it's part of a rootkit.
> 
> It's an arms race, and to not play that particular arms race, is to lose
> it.  You can always add more tests, and the kiddies can always add more
> ways to get around those tests.  But again, to not try, is clearly to
> lose.  (Kind of an "Anti-Wargames").
> 
> 
>>>Alternatively, or additionally, you can NFS mount the filesystem you
>>>intend to check and run a trusted md5 and sha-1 generator on a trusted
>>>system.
>>>
>>
>>It fails for the reasons stated above.
> 
> 
> -But-, it's an additional weapon in your arms race.  Also, as you add
> more "weapons", it becomes less and less likely that the kiddies will
> know all the different things that must be trojaned.
> 
> Additive effect.  That simple.
> 
> 
>>>>>It's not like you can just assume a one to one mapping, or tack some
>>>>>crud on the end.
>>>>
>>>>I know perfectly well how md5 hashing works. I also know that what 
>>>>you're trying to implement is utterly useless unless you run everything 
>>>>off some non-writable media. It just won't work. Worse, it will create a 
>>>>false sense of security, so a possible attacker can hang on to your 
>>>>system for a much longer period once properly compromized.
>>>
>>>
>>>So why are we ruling out nonwritable media?  :)
>>
>>I'm not. I'm ruling out MOUNTED read-only media, because it's not 
>>logically read-only if you already have access to replace system 
>>binaries. A root file-system on read-only media with network mounted 
>>untrusted writeable media would be secure though.
> 
> 
> If you mount in both directions, over multiple protocols, that forces
> the kiddies ever-deeper into the kernel.  Eventually, in your arms race,
> you md5+sha-1 the VFS layer, as well as the md5+sha-1 code in the
> kernel.  Then add a daemon that verifies those sums.  Then you add a
> kernel-groveler that verifies those sums.  Then you go to another
> protection ring in your hardware.
> 
> Granted, "Reflections on Trusting Trust" makes a good point, and yet,
> the above, plus kexec, gives ever-increasing numbers of hoops for the
> kiddies to jump through.  And in so doing, we're reversing roles:
> normally, on the patch scene, the kiddies have to find just one
> vulnerability, and we're sunk if we miss any one out of n.  But in this
> latter arms race, we're changing the rules to favor the admins: the
> admins just have to find one check that works, while the kiddies have to
> find ways around -all- of the checks.
> 
> That's worth something.
> 
> 
>>> Granted, that's fakeable too, but like I said above, it's hard.
>>
>>I can easily prove you wrong in two commands. Assume "fake-share" holds 
>>all binaries and files located on the real share, but trojaned when 
>>necessary.
>>
>>umount /shared/disk/mount/point
>>mount <options> fake-share /shared/disk/mount/point
> 
> 
> Not so fast.  You just verified your kernel via the latest tests, some
> in-kernel, some not.  You just verified your executables over n
> bidirectional protocols, using m hashes.
> 
> You don't have to be infallible.  You simply have to be ahead of the
> kiddies.
> 
> 
>>And we're done.
> 
> 
> You might be, but I'm not, and neither are the kiddies.
> 
> 
>>> And we already had
>>>nonwritable media in the discussion anyway, so there's no point in
>>>arbitrarily ruling it out for one purpose and not another.
>>>
>>>Please don't spin the "false sense of security" yarn again.  That's so
>>>overused.
>>
>>Perhaps so, but still. The false security is why systems stay 
>>compromised, and why real security isn't applied. Idiot ideas by idiot 
>>admins is why script kiddies get cocky and stay "in business".
> 
> 
> Credit where it's due:
> 
> 90+% of breakins happen because admins either knew and didn't care, or
> didn't know about the existence of relevant patches (or alternatively,
> didn't know to/bother to run up2date/yum/windowsUpdate/whatever).
> 
> Applying patches is your primary defense.
> 
> After that, comes steps in the arms race sketched abovew.  Layer after
> layer of rootkit's vs chkrootkit's.  At this layer, to not play is to
> lose - to have no second line of defense whatsoever (OK, maybe
> firewalling is second, but no nth line of defense...)
> 
> 
>>> Better to light a candle in the darkness, than to complain
>>>that it isn't a floodlight and do nothing.  An effort doesn't have to be
>>>100% effective to be valuable.
>>>
>>
>>Correct, but it should at least require more than two commands (and very 
>>trivial changes to a few extra standard programs) to be circumvented.
> 
> 
> It was pretty easy to demonstrate that it can be made to require more
> than two commands.  :)  C'mon, you should try harder.  :)  Let's see you
> somehow ditch the benefits of changing from 1 to n, into 1 to n + n to
> 1.  :)
> 
> -- 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null