Re: tripwire database handling (WAS:Re: hacked boxes / countermeasures)

[Zombie Cow <waste@zor.hut.fi>]

Anyone have a workable systems security strategy and planned
countermeasures that would include consideration and operation
guidelines in case of compromise for all of these nasties?
Are there any tools for verifying codes inside programmable chips?
Can you trust what the chips tell you?

Maybe an FAQ to go with the distribution on issues such as this 
would be good?

---------- Forwarded message ----------
Date: Mon, 12 Jul 1999 17:58:30 +0300 (EEST)
Cc: INCIDENTS@SECURITYFOCUS.COM
Subject: Re: tripwire database handling (WAS:Re: hacked boxes / countermeasures)

And what of the programmable chips on most new systems?
Could some of them be altered to "edit" the read programs
before they're run? What if the BIOS has been altered?

How can you trust a processor with re-writeable microcode?

(
Especially when Intel has had close dealings with 
NSA and also does loads of US military hardware, AFAIK.
http://caq.com/cryptogate
http://www.iptvreports.mcmail.com/ic2kreport.htm
)

---------- Forwarded message ----------
Date: Fri, 9 Jul 1999 20:16:35 +0200
From: Joel Eriksson <jen@ETTNET.SE>
To: INCIDENTS@SECURITYFOCUS.COM
Subject: Re: tripwire database handling (WAS:Re: hacked boxes /             
    countermeasures)

On Thu, Jul 08, 1999 at 12:39:18PM +0200, Joakim Rastberg wrote:
> On Wed, 7 Jul 1999, blind to the present wrote:
> >Tripwire can also be worse than useless (if an admin assumes that no
> >database change means no system compromise, and if they implement
> >it poorly out of ignorance or laziness).
>
> (de-lurk)
>
> I work as a contractor at a big Swedish company, running boxen and trying
> to convince other sysadmins that security is A Good Thing (tm). The main
> complaint the admins have about tripwire was the manual work
> when rebuilding and doing off-machine storage of the tripwire database.
>
> The solution I came up with was this: do a "-initialize" every night and
> email the result (without storing it anywhere) to a hardened machine
> running only smapd and a secured webserver.. This other machine compares
> the output with yesterdays result and email/pages the admin(s) if any
> changes are detected (or no email showed up).

Creative, but unfortunately it's no secure setup.

Ways around this include at least:

- An attacker could just do a "tripwire -initialize" by himself, save the
  results, and arrange so the saved copy instead of the new database is
  e-mailed every night instead.

- An attacker could make a wrapper for tripwire that modifies the database
  after tripwire has been run. This could be done with simple shellscripts.

- An attacker could trojan tripwire itself and for example make sure that
  the cryptographic checksums for the backdoors, trojans, etc is hardcoded
  to the original ones and the rest are calculated as usual.
  This way it's also possible to escape detection when change in the
  databases is _expected_ (when installing new software, etc.), and even
  when the trojaned binaries are replaced when new versions are installed
  if the saved checksums only are used when the new checksums matches the
  checksums of the trojan / backdoor.

- An attacker could modify the open() systemcall so that the saved copy of
  the files that are replaced with trojans / backdoors is read instead of
  the trojan / backdoor itself. The exec() systemcall would still use the
  trojan. This could in many cases be done using kernelmodules, or if the
  attacker is sophisticated enough it could be done by modifying kernelmemory
  in runtime.

- An attacker could arrange so the trojans / backdoors are automatically
  "deinstalled" before the nightly tripwire database update, and reinstalled
  after the update is done. Tripwire doesn't check running processes right?..

To be secure, the tripwire-binary should be on a read-only medium, the
medium that stores the databases should only be mounted when the database
is updated and stored safely, and...

Last but not least, the machine should be taken down to single-user mode and
everything must be done manually. Since the kernel, shared libraries, etc may
have been modified one should boot from for example a read-only floppy if that
is possible, the important thing is that anything that has been accessable when
from the host when it was up & running shouldn't be trusted. _Then_ the partition(s)
to take databases of should be mounted and tripwire be run.

> If the changes are ok, the admin can simply ack this on a webpage on the
> secure machine.

And how do you protect the mechanism for acknowledging changes, when not
being able to determine whether the host that acknowledges changes is itself
compromised?

> This setup requires almost no effort from the hardworking admins to
> maintain a current tripwire database and requires the attacker to
> compromise the hardened SMAP/SSLwebserver to stay undetected.

Even if that was true, the risk is too high IMHO. The weak point may
very well be a flaw in SMAP or the secured webserver running on the
supposedly hardened machine.

If the setup described had not been severely flawed, it would have been absolutely
great. Unfortunately, security comes at a price. In the case of tripwire it may seem
high, but if security is important it may be unavoidable.

I know that many servers can not be shut down now and then for a tripwire update
since downtime means big moneylosses etc. In that case one may be forced to makeo
a tradeoff and accept that certain security measures can not be done, and try to
make up for it somehow by improving overall security on the machine.

There is, of course, nothing wrong with using the method you described, as long
as one is aware of the flaws and takes appropriate security measures besides
using tripwire..

Tripwire, when not used correctly, may give a false sense of security that may be
far more dangerous than if tripwire was not used and the administrators instead were
more alert. If the administrators doesn't care either way, it can't get much worse
though.. :-)

I hope you don't take this as a flame, it is absolutely not intended as one..

> /Joakim Rastberg, Xinit AB, Sverige. Unix-only since 1984.

--
Joel Eriksson
Security Consultant

-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/