Plugin to check MD5 sum on certain files

[Andreas Ericsson]

Dan Stromberg wrote:
> Actually, if you wouldn't mind doing it again?
> 

That's entrapment, Danny dearest, and the answer is no. You should have 
dumped the ram to disk before reinstalling. It would have cured your 
curiousity (eventually).

> We reinstalled the system, to get less stuff to sift through.
> 
> "Without loss of generality..."
> 
> On Tue, 2004-11-09 at 13:47 +0100, Andreas Ericsson wrote:
> 
>>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