So you’ve had a compromise and need to figure out which files (if any) were modified by the intruder, but you didn’t install Tripwire? Well, all is not lost if your distribution uses RPM for its package management system. While not as powerful as Tripwire, RPM can be useful for finding to what degree a system has been compromised. RPM keeps MD5 signatures for all the files it has ever installed. We can use this functionality to check the packages on a system against its signature database. In addition to MD5 checksums, you can also check a file’s size, user, group, mode, and modification time against that which is stored in the system’s RPM database.
To verify a single package, run this:
If the intruder modified any binaries, it’s very likely that the ps command was one of them. Let’s check its signature:
# which ps
# rpm -V `rpm -qf /bin/ps`
Here we see from the S, 5, and T that the file’s size, checksum, and modification time has changed from when it was installed—not good at all. Note that only files that do not match the information contained in the package database will result in output.
If we want to verify all packages on the system, we can use the usual rpm option that specifies all packages, -a:
# rpm -Va
S.5….T c /etc/pam.d/system-auth
S.5….T c /etc/security/access.conf
S.5….T c /etc/pam.d/login
S.5….T c /etc/rc.d/rc.local
S.5….T c /etc/sysconfig/pcmcia
…….T c /etc/libuser.conf
S.5….T c /etc/ldap.conf
…….T c /etc/mail/sendmail.cf
S.5….T c /etc/sysconfig/rhn/up2date-uuid
…….T c /etc/yp.conf
…….T c /etc/krb5.conf
There are other options that can be used to limit what gets checked on each file. Some of the more useful ones are -nouser, -nogroup, -nomtime, and -nomode. These can be used to eliminate a lot of the output that results from configuration files that you’ve modified.
Note that you’ll probably want to redirect the output to a file, unless you narrow down what gets checked by using the command-line options. Running rpm -Va without any options can result in quite a lot of output resulting from modified configuration files and such.
This is all well and good, but ignores the possibility that someone has compromised key system binaries and that they may have compromised the RPM database as well. If this is the case, we can still use RPM, but we’ll need to obtain the file the package was installed from in order to verify the installed files against it.
The worst-case scenario is that the rpm binary itself has been compromised. It can be difficult to be certain of this unless you boot from an alternate media, as mentioned earlier. If this is the case, you should locate a safe rpm binary to use for verifying the packages.
First find the name of the package that owns the file. You can do this by running:
Then you can locate that package from your distribution media, or download it from the Internet. After doing so, you can verify the installed files against what’s in the package using this command:
RPM can be used for quite a number of useful things, including verifying the integrity of system binaries. However, it should not be relied on for this purpose. If at all possible, something like Tripwire or AIDE (http://sourceforge.net/projects/aide) should be used instead.
[ Taken from the Book “Network Security Hacks” ]