Plugin to check MD5 sum on certain files

[Dan Spray]

Okay, with all of that sorted out does anyone actually have an idea for a
plugin?  I understand that it will not be 100% accurate 100% of the time.
However, like Leif said in one of the threads, of the couple of systems that
I have had infected over the years I have never had anyone overwrite the
md5sum.  I'm not opposed to using another method, it is just what Big
Brother had used.  Basically I am not looking for a catch all or a false
sense of security, I just want to know quickly if even my junior sysadmin
messed up and installed the wrong package or upgraded the wrong thing.  I'm
sorry that I started a war but we are all here for the same thing.

Dan

-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of Dan Stromberg
Sent: Monday, November 08, 2004 6:49 PM
To: Andreas Ericsson
Cc: strombrg at dcs.nac.uci.edu; nagios-users at lists.sourceforge.net
Subject: Re: [Nagios-users] Plugin to check MD5 sum on certain files


Oh Andreas...  What am I going to do with you?

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.  :)

-- 




-------------------------------------------------------
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