Web Site for Terry Gliedt
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
"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.
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.
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.
If no fatal errors are detected, the program exits with a return code of 0. Any error will set a non-zero return code.
Written by Terry Gliedt I<E<lt>firstname.lastname@example.orgE<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