Beta testers needed for security tool

Beta testers needed for security tool

Post by Ross Ridg » Tue, 08 Sep 1992 19:26:53




><unlock SysAdm Cabinet>
><remove "special" floppy>
><insert "special" floppy>
>mount -r /dev/fd0c /floppy
>/floppy/tripwire

>This is one possible way to do it on floppy-equipped systems (say, an
>SS2 or IPX or whatever).  Maybe this should go in the docs?

While this would be what I'd do, even this isn't 100% guaranteed if
someone has broken security on the machine.  It's possible, for instance,
that the mount command, shell or even kernel has been hacked to prevent
tripwire from doing it's job properly.

                                                        Ross Ridge

--
Ross Ridge - The Great HTMU                                          l/  //
                                                                    [OO][oo]

uunet.ca!zooid!ross                                                  db  //

 
 
 

Beta testers needed for security tool

Post by Rich Holla » Wed, 09 Sep 1992 02:43:35



>While this would be what I'd do, even this isn't 100% guaranteed if
>someone has broken security on the machine.  It's possible, for instance,
>that the mount command, shell or even kernel has been hacked to prevent
>tripwire from doing it's job properly.

*shaking head*  Man, some people can get just a LITTLE too paranoid!

Why don't you just restore the OS from tape every morning?  No, wait --
someone could break in, mount the tapes in the night, and backup their
hacked kernel.  Bad Idea.  Maybe Sun would be willing to mail you new
tapes every day?  No, someone could intercept them from your Post Office
and tamper with them...

...some people need a better sense of reality!

--


Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

 
 
 

Beta testers needed for security tool

Post by Rich Holla » Tue, 08 Sep 1992 08:52:48



> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>find the root's version of tripwire and change it to *always* spit out the
>"don' worry, be happy message"....

...but it may not be '/etc/tripwire' or something so obvious.  What if
the admin put it in '/var/spool/mail/some-user' and changed the perms
so that it's not executable (harder to find).  You gonna poke through
EVERY file on the system lookin' for it?  What're the chances you'll be
detected before you do?  :-)

--


Manhattan, KS  66502-3357 | UUCP    : ...!rutgers!matt.ksu.ksu.edu!holland
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

 
 
 

Beta testers needed for security tool

Post by Gene K » Mon, 07 Sep 1992 02:13:29


Announcing the pending availability of

               Tripwire: A Unix File Integrity Checker

    This message is being posted to various newsgroups and mailing
lists to gather a group of beta-testers for a new security tool called
Tripwire.  Tripwire was written by Gene Kim, currently at Purdue
University, under the direction of Professor Gene Spafford.

    Tripwire should be of significant interest to system
administrators concerned about timely detection of system file
tampering on their Unix hosts.

Goal of Tripwire:
=================

    With the advent of increasingly sophisticated and subtle
account break-ins on Unix systems, the need for tools to aid the
detection of unauthorized modification of files becomes clear.
Tripwire is a tool that aids system administrators and users in
monitoring a designated set of files for any changes.  Used with
system files on a regular basis, Tripwire can notify system
administrators of corrupted or tampered files, so damage control
measures can be taken in a timely manner.

    Tripwire is a system file integrity checker, a utility that
compares a designated set of files and directories against
information stored in a previously generated database.  Any
differences are flagged and logged, and optionally, a user is
notified through mail.  When run against system files on a
regular basis, changes in critical system files would be spotted
at the next time-interval when Tripwire is run, so damage
control measures may be implemented immediately.  With
Tripwire, system administrators can conclude with a high degree
of certainty that a given set of files remain untouched from
unauthorized modifications, provided the program and database are
appropriately protected (e.g., stored on read-only disk).

    Tripwire uses message digest algorithms (cryptographic
checksums) to detect changes in a hard-to-spoof manner.  This
should be able to detect significant changes to critical files,
including those caused by insertion of backdoors or viruses.  It
also monitors changes to file permissions, modification times,
and other significant changes to inodes as selected by the system
administrator on a per-file/directory basis.

What we need:
=============

    As of this writing, Tripwire runs successfully on both BSD
and System V variants of Unix.  Among the operating systems
Tripwire has run on are:

                SunOS 5.x (SVR4)
                SunOS 4.x (BSD 4.3)
                Dynix 3.x (BSD 4.2)

    Compiling Tripwire should be as simple as editing the config.h
file to set the appropriate #defines, and typing 'make'.

    A pool of beta-testers is needed to ensure that Tripwire
works predictably on a wide variety of systems.  Of particular
interest are system administrators using the following operating
systems:                

                AIX
                AUX
                BSD4.4
                HP/UX
                Mach
                NextOS
                OSF/1
                SVR3.x
                Ultrix
                Unicos
                Xenix
                System III
                Versions 6, 7, 8, & 9  :-)
                other versions we didn't list

    A config.h file allows you to tailor Tripwire around your
system specifics, such as the locations of system utilities (like
sort and diff), and desired lookup pathnames to your Tripwire
database files.

    Possible porting trouble-spots are generally restricted to
dirent(S5)/direct(BSD) funkiness and #defines that changed for
POSIX compliance (such as those in <sys/types.h> for stat.st_mode).

    Hopefully the process of beta-testing will highlight any
problems before any widely-released distribution.  It is also
hoped that reasonable system defaults for a wide variety of
systems can be gathered from a diverse set of beta-testers.
This would allow useful plug-and-play builds for the majority of
Tripwire users.

What you'd get as a beta-tester:
================================

    The entire source to Tripwire, manual pages, a README, and
the Tripwire design document.

What you'd need to do:
======================

    You will need to install the code on your system and run
it.  You will need to report back any bugfixes, enhancements,
optimizations or other code-diddling that you believe useful.  If
you build a configuration file for a new system, you will need
to send this back.  You will have to collect some performance
data.  You will need to provide some honest, critical feedback on
utility, clarity, documentation, etc.

    You will need to do all this by about October 21.

Are you interested?
===================

    If so, please fill out the form at the end of this message, and

three respondents for each system type for the beta test.

    Please allow some time for processing and selection of
beta-testers.  I promise to reply to all requests as
expeditiously as possible.

    A formal release of Tripwire is planned for sometime in
November.  Watch this space for details!

Gene Kim
September 4, 1992

===============================================================================

Name:
Email address:                          
System configuration:
    machine type
    operating system
    version

Site information: (completely optional)
    type of site (ie: university, corporate, military, etc...)
    comments on machine security
        (ie: numerous break-in attempts on our dialback servers,
             repeated intrusions through network, etc...)

===============================================================================

 
 
 

Beta testers needed for security tool

Post by Jim Si » Mon, 07 Sep 1992 10:32:14


(buncha stuff about a utility to diff files as a security measure deleted)

 It seems to me rather useless and extremely CPU and I/O expensive to diff
files as a security measure. How ooften you gonna run this thing? Every 10
minutes? What's the expected delta between logins that someone could be
snagging passwords on your system? Seems like better control over changing
the files is the answer rather than finding out afterwards....

 If I was gonna hack some system, I'd be sure the first thing I'd do to is
find the root's version of tripwire and change it to *always* spit out the
"don' worry, be happy message"....

 
 
 

Beta testers needed for security tool

Post by Gene Spaffo » Tue, 08 Sep 1992 10:21:22


(Mostly in response to comments by Jim Sims):

Actually, the documentation for Tripwire will recommend that it be
installed on a read-only disk or across a network on read-only media.
The program has been designed to work with read-only input and with
the program on read-only storage.  If the read-only attribute is set
in hardware, it is very, very difficult to "hotwire" the code or
database.

As far as frequency of operation, that is up to the sysadmin.  Many
alterations cannot be detected without something like this.  In some
cases (e.g., mounting file systems across a network), files can be
altered without any unauthorized login from occuring.  Tripwire will
find those kinds of access.  This will also find Unix viruses, if any
ever appear.

Tripwire doesn't run "diff" against the file contents.  It uses message
digests/cryptographic signatures on those files that the sys admin
chooses to sign.  If the sysadmin wishes to only check i-node contents
for selected files, then the signature is not performed.

A fair amount of careful thought went into the design of this.  I'm
certainly interested in hearing comments and criticisms, but it sure
would be helpful if people would wait until they know what it is they
are commenting on.  (But then, this *is* Usenet. :-)
--
Gene Spafford
Software Engineering Research Center & Dept. of Computer Sciences
Purdue University, W. Lafayette IN 47907-1398

 
 
 

Beta testers needed for security tool

Post by Gene K » Tue, 08 Sep 1992 11:04:01




>> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>>find the root's version of tripwire and change it to *always* spit out the
>>"don' worry, be happy message"....
>...but it may not be '/etc/tripwire' or something so obvious.  What if
>the admin put it in '/var/spool/mail/some-user' and changed the perms
>so that it's not executable (harder to find).  You gonna poke through
>EVERY file on the system lookin' for it?  What're the chances you'll be
>detected before you do?  :-)

    You are right in pointing out that Tripwire is only as reliable
and secure as the database and Tripwire executable files.  Therefore,
putting these files on the local system where they can be tampered with
would be a bad idea.

    In the documentation for Tripwire, we suggest putting both the
database and the Tripwire executable on a ``secure-server''.  For
instance, putting them on read-only media on a remote file-system
with the files accessed via read-only NFS would be prudent.

Gene


 
 
 

Beta testers needed for security tool

Post by Christopher Dav » Tue, 08 Sep 1992 11:22:04



 Gene>     You are right in pointing out that Tripwire is only as
 Gene> reliable and secure as the database and Tripwire executable
 Gene> files.  Therefore, putting these files on the local system where
 Gene> they can be tampered with would be a bad idea.

<unlock SysAdm Cabinet>
<remove "special" floppy>
<insert "special" floppy>
mount -r /dev/fd0c /floppy
/floppy/tripwire

This is one possible way to do it on floppy-equipped systems (say, an
SS2 or IPX or whatever).  Maybe this should go in the docs?
--
Christopher Davis   | ]CALL -151      

System Administrator| *3D0G            
EFF +1 617 864 0665 | ]CALL 768        

 
 
 

Beta testers needed for security tool

Post by Bill Sommerfe » Wed, 09 Sep 1992 03:49:26



   >While this would be what I'd do, even this isn't 100% guaranteed if
   >someone has broken security on the machine.  It's possible, for instance,
   >that the mount command, shell or even kernel has been hacked to prevent
   >tripwire from doing it's job properly.

   *shaking head*  Man, some people can get just a LITTLE too paranoid!

   ...

   ...some people need a better sense of reality!

You're one of them :-)

For the record, there have been a number of instances of break-ins on
the Internet involving hacked operating systems software..  typically
/bin/login and/or telnet and/or telnetd.

Hacking the shell isn't too much harder than hacking any other
user-mode program.

It's a *lot* harder to replace write-protected boot media in a locked
cabinet through the network.

Multics, one of the most usable of secure systems (and most secure of
usuable systems), was always booted from a write-protected *tape*,
which contained the boot loader, kernel-equivalent, shared libraries,
and critical commands.
--

 
 
 

Beta testers needed for security tool

Post by Christopher Dav » Wed, 09 Sep 1992 04:49:08



 Bill> It's a *lot* harder to replace write-protected boot media in a
 Bill> locked cabinet through the network.

Especially if the boot media is a CD-ROM.  Then you don't even have the
"they hacked the kernel then re-wrote the boot tape I left in the drive"
problem :-)

This is one nice side-effect of Sun's move to CD-ROM for software
distribution, IMHO.  Not the main one (portability and durability are
somewhat higher up), but it's on the list.

(Hm, maybe we can get Sun to put tripwire on the CD-ROM...)
--
Christopher Davis   | ]CALL -151      

System Administrator| *3D0G            
EFF +1 617 864 0665 | ]CALL 768        

 
 
 

Beta testers needed for security tool

Post by Paul A. Karg » Thu, 10 Sep 1992 01:41:08



|>

|>
|>    >While this would be what I'd do, even this isn't 100% guaranteed if
|>    >someone has broken security on the machine.  It's possible, for instance,
|>    >that the mount command, shell or even kernel has been hacked to prevent
|>    >tripwire from doing it's job properly.
|>
|>    *shaking head*  Man, some people can get just a LITTLE too paranoid!
|>
|>    ...
|>
|>    ...some people need a better sense of reality!
|>
|> You're one of them :-)
|>
|> For the record, there have been a number of instances of break-ins on
|> the Internet involving hacked operating systems software..  typically
|> /bin/login and/or telnet and/or telnetd.
|>
|> Hacking the shell isn't too much harder than hacking any other
|> user-mode program.
|>
|> It's a *lot* harder to replace write-protected boot media in a locked
|> cabinet through the network.
|>
|> Multics, one of the most usable of secure systems (and most secure of
|> usuable systems), was always booted from a write-protected *tape*,
|> which contained the boot loader, kernel-equivalent, shared libraries,
|> and critical commands.
|> --

And even Multics fell victim to a hacked shell at one point in its life.
I recall a case back in '69 or thereabouts when one of the system
administrators was given a hacked shell that displayed a convincing
error message and then hung up the modem.   That administrator spent
several days looking for a system bug, before discovering the hacked
shell.

Just because you're paranoid, DOESN'T mean that they aren't out to
get you, anyway!

 
 
 

Beta testers needed for security tool

Post by Wes Morg » Thu, 10 Sep 1992 03:45:41



>(buncha stuff about a utility to diff files as a security measure deleted)

> It seems to me rather useless and extremely CPU and I/O expensive to diff
>files as a security measure.

Well, every little bit helps.  If I can run this thing once or twice per
week without melting my CPU or I/O controller, it's worth it.

Quote:>How ooften you gonna run this thing? Every 10
>minutes? What's the expected delta between logins that someone could be
>snagging passwords on your system? Seems like better control over changing
>the files is the answer rather than finding out afterwards....

In theory, you're absolutely right.  In reality, there will always be a
hole of which you are unaware.  I'd like to have something like Tripwire
"looking over my shoulder".

Quote:> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>find the root's version of tripwire and change it to *always* spit out the
>"don' worry, be happy message"....

Of course, that'll be hard to do if I keep the binary(ies) encrypted (or
on a Sun floppy)......8)

--Wes

--




 
 
 

Beta testers needed for security tool

Post by william E Davids » Thu, 10 Sep 1992 04:37:51


| So flip the write-protect switch on the floppy.  No program is a
| panacea.  This sounds like a wonderful tool, regardless.
|
| Without knowing the full mechanism by which tripwire works, discussions
| like this are of limited usefulness.  If your system regularly has been
| compromised to the point that you can't trust your kernel, you
| shouldn't be trusting Tripwire alone anyway.  If we're going to be
| paranoid, make a miniroot disk, and put all the stuff on there.  I
| kinda doubt it would all fit, however.  A floppy with tripwire, related
| programs, a known good copy of the runtime C library, and the database
| should be enough.

  I have used the free brik program for some time, as a protection
against corruption rather than breakin, although it certainly is useful
there, too. I list all the files which are critical and create a master
list using the "generate list" mode. Then I check all of those files
from time to time, and after every boot.

  This may do more than that, I'm not sure.

--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.

 
 
 

Beta testers needed for security tool

Post by Tom Van Vle » Thu, 10 Sep 1992 06:28:06


In fact, Multics had a tool very like Tripwire:
 save_dir_info   wrote directory information, date modified etc for
                 a list of files into a user file;
 comp_dir_info   compared some fields of two such files and printed
                 differences.

These programs could be used by system administrators to find what
files in the system library had been modified.  They didn't do
checksums or digests though; would have been a good enhancement.
(I wrote them about 1976.)

--

 
 
 

Beta testers needed for security tool

Post by Malte U » Thu, 10 Sep 1992 18:44:37


Quote:>(buncha stuff about a utility to diff files as a security measure deleted)

> It seems to me rather useless and extremely CPU and I/O expensive to diff
> files as a security measure.

I have written a shell script performing checks on inodes of files and
computing checksums over them. After coding that inode comparison stuff
in C, the script runs only for about 80 seconds depending on the systems
load to check about 1.300 files. And I really can't think of more than 1.300
files to watch on a BSD system.
So I don't expect Tripwire to take much longer.

Malte.

P.S.: The Machine is a Sun 4/470, serving 15 diskless clients and 5 Xterminals.

 
 
 

1. Beta testers needed for log file analysis tool (Chartreuse Cartouche 2.0)

Hi,

Version 2.0 of Chartreuse Cartouche is getting ready ship, and we need
beta testers.  Chartreuse Cartouche is a powerful tool for analyzing web
logs (and other logs).  Chartreuse Cartouche runs as a CGI program, and
generates graphical, hierarchical statistics pages in HTML, allowing easy
analysis of log files.

Some of Chartreuse Cartouche's many features:

  * Powerful, easy-to-use graphical CGI interface supports remote
    browsing of log statistics, and remote configuration,
    from any machine with a web browser.

  * Hierarchical HTML display breaks log information down on one
    or more fields, massively cross-referenced and cross-linked.

  * Fast processing engine reads small or moderate-sized log files
    fast enough to browse them real-time.

  * For larger log files, disk database feature allows real-time
    browsing of stats, and can be incrementally updated.

  * Extensive configuration option set allows full control over
    appearance of stats pages.

  * Log format description features allow processing of
    a wide variety of log files, including all HTTP access and
    referrer logs, ftp logs, and others.

  * Runs on all all major platforms (Macintosh, Windows NT,
    Digital UNIX, Solaris, Linux, HP/UX, AIX, others).

For an idea of how Chartreuse Cartouche 2.0 output looks, see Chartreuse
Cartouche 1.0:

  http://www.flowerfire.com/cartouche/

Chartreuse Cartouche 2.0's output has improved since 1.0, but the core
concepts are similar.

As a beta tester, you will have the opportunity to help refine this
cutting-edge tool.  We really listen to our beta testers; if you have a
feature suggestion, we will almost certainly implement it.   For
information on being a beta tester, please send mail to

Note: to run Chartreuse Cartouche, you will need to have access to a web
browser, and web server which supports CGI.


2. Iomega ZiP error

3. Beta testers needed for new web log analysis tool

4. Test, please don't read

5. Beta site: Beta testers needed!

6. Umask question

7. SOFTWARE:'Fast-Start' QuickTime movie tool beta testers wanted

8. Intermitent Mosaic HELP!

9. Wanted: Software Design Tool Beta Testers

10. Security Scanner beta testers wanted

11. Alpha/Beta Testers for System Security Scanner

12. Beta Central - Beta Testers Resource

13. Beta Testers Needed