VERIFYSYS.PL - automate a check of the integrity of system files

Download this program

SYNOPSIS

 sudo apt-get clean
 sudo apt-get update
 verifysys.pl -logfile /tmp/j  create /tmp/fchks.txt
 sudo verifysys.pl -logfile /tmp/jj verify /tmp/fchks.txt
 sudo verifysys.pl -logfile /tmp/jj -rootdir /otherroot \
      verify /tmp/fchks.txt

DESCRIPTION

"Yikes, I think I've been hacked", you say. Something is seriously wrong on my system, but I'm not sure exactly what. I think maybe someone has gotten on my system and maybe changed some binaries. I either do not have another system exactly like mine to compare with - and comparing is a difficult process.

Verifysys.pl was written to help answer the question, "What system binaries were changed? Can I trust ANY command on the system?"

The approach is to re-fetch all the packages for the system and then compare the binaries in the distribution to that on the system. verifysys.pl only supports Debian packages, including those on Ubuntu distributions. Redhat RPMs could easily be supported, but have not. If you're interested, please add that support and tell the author of your work.

PROCESS

The verification process is to fetch all the packages that are on the system and create a file of detailed information about the contents of the contents in the package. This could be done on another system which closely resembles the system in question - same architecture, distribution and most of the packages are the same. This step can be really tediously slow as it might fetch a really large number of packages, all of which are downloaded (but not installed) on your system. The good news is that it need only be run once - at least until the distribution changes.

The second step is to verify the system in question by using the package verification information from the first step to look for executables which are different. This generates a list of files which have potentially been modified by your attacker.

The approach has some drawbacks:

  * Requires the machine to be connected to the network
  
  * Uses some binaries on the system
  
  * Fetching all those packages is not fast

  * If your system is not close to being up to date, it will report
   many false-positives. Many binaries will be reported as
   changed, but the real change was because the distribution
   changed the file, not some attacker.

  * Only checks for executables from your distribution and
    not other executables from you or your attacker.
    Does not check system configuration files.

You can help minimize the drawbacks by having a second system which is closely configured to the one in question. Create the package verification information on a clean system and use that information to check your suspect system. This is something akin to what Tripwire and other similar programs do.

SECURITY CONSIDERATIONS

Even on completely unaffected systems, the verify process may find files which have changed from their original executables as distributed in the packages. Sometimes this is because the executable was not stipped before being installed, changing the size of the executable (e.g. gnuplot on my Ubuntu system). Sometimes the executable is script which has had some part dyanamically modified during the install (e.g. perldoc).

The list of intentionally changed files seems to be small in my experience, but each of these identified changes should be checked. I have never encountered any of the common files (e.g. ls, ifconfig, route etc.) which are intentioanlly changed by the install of the package.

You may well find that some files in your package files are missing on your system. Again, this list is small in my experience and most often seems to have to do with files being renamed or removed by other packages.

A common source of change is just because some package has been upgraded by your distirbution and the system in question had not been kept quite up to date. These changes can be difficult to figure out.

Verifysys.pl is not a complete answer, but just one more tool you might consider after the fact to help decide if you were actually successfully attacked and how completely your system was penetrated. This program does nothing to help prevent the attack.

Seems to me the most prudent approach when you think you might have been attacked is paranoia.

OPTIONS

-arch string

Specifies the architecture of the distribution. This defaults to i386 and will automatically detect amd64.

-help

Generates this help.

-logfile path

Specifies the log file to be created. This defaults to verifysys.log.

-pkgdir string

Specifies the path to the directory where the distribution's packages (e.g. deb files) are kept. This defaults to /var/cache/apt/archives.

-rootdir path

Specifies the path to a place where the root directory for the system is to be found. This defaults to /. In some cases you might be able to NFS mount or otherwise have access to the questionable system's root filesystem.

PARAMETERS

create|verify

Specifies the function, either create the package verification information (the first step) or verify the binaries on the system by reading the package verification information file (second step).

This second step is run on a system which has access to the system binaries of the system in question (e.g. likely ON the possibly affected system). Running on an infected system means it is always possible that your attacker has crafted a devious way that you cannot detect the infection. This program was written to minimize that chance, but you never know.

verifyinfofile

Specifies the package verification information file. This is created with create and contains details on all the executables installed as part of your distribution. This is read with verify and used to generate a list of executables that are different from those found in -rootdir.

This file could be pretty large - containing information on many thousands of files.

 
=head1 EXIT

If no fatal errors are detected, the program exits with a return code of 0. Any error will set a non-zero return code.

AUTHOR

Written by Terry Gliedt I<E<lt>tpg@hps.comE<gt>> in 2009 and is
copyrighted (C) by Terry Gliedt and the University of Michigan.
This is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; See http://www.gnu.org/copyleft/gpl.html