Plugin to check MD5 sum on certain files

[Dan Stromberg]

Actually, if you wouldn't mind doing it again?

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.  :)
> > 
> > -- 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-lists.org/archive/users/attachments/20041111/bf074057/attachment.sig>