Validating Software Validation

by Malvineous

In issue 33:1, there was an interesting article ("Software Validation") by Ben Kenobi detailing a method for checksumming files on a system to discover any unauthorized modifications.

This got me thinking - if presented with a system like this, how might one find their way around this seemingly impenetrable layer of security?

The system produces a signed list of all important files, complete with a checksum for each one.  The idea being that should any file be tampered with, its checksum will change so it won't match the list, and the intrusion is detected.

Updating the master list requires some work - creating new keys, comparing changes to the old list, etc. - so let's imagine that due to this effort, security updates aren't applied as often as they should be.  Someone breaks into the system and uses a recent vulnerability to gain root access.  This part is not that unusual, which is the reason why one might go to the trouble of having the checksum list in the first place.

Now, most intruders might install a script somewhere and have it run at boot time.  This script could be installed anywhere, and if it's placed in an unmonitored directory (say deep within ~/.config) then the checksum process will not pick it up, as it is avoiding those directories to minimize false positives.  The script can be marked as suid root so that it will always run as root (even if launched by a normal user later on).

Loading it at startup can also be quite straightforward - just put it in the user's own startup scripts, such as ~/.Xsession, ~/.bashrc, or similar.

This means that despite all the elaborate checksum tests, it's still possible for a malicious program to run unnoticed on every boot, with full root privileges.

Taking it a step further, once our malicious program is running, perhaps we might want to capture some passwords or private keys.  One way of doing this is to replace the PGP binaries with our own modified versions, which have been changed such that any time a private key passphrase is entered, the passphrase along with the key is sent to a remote server - possibly via a series of specially coded DNS lookups so as to avoid creating any unusual-looking outgoing network connections.

Once we replace the PGP binary on the system with our malicious version, we can capture any private keys and use them ourselves to decrypt whatever we need - at least until the next checksum run, when the user will realize that /usr/bin/gpg, or similar, has been modified.

However, if we have looked around the system and discovered this checksum process, we will see that it is using the sha256sum program to produce the checksums.  Depending on the system, this means we can either replace sha256sum itself or one of the libraries it uses to calculate the checksums (such as OpenSSL), so that we can control the checksums produced.  A few simple lines of code at the right place (if checksum = A then checksum = B) means that any time the "wrong" checksum is calculated, it will be replaced with the "right" one and all our modified programs will still show up as having their original checksums, appearing as though they have never been changed.

As a side note, this illustrates one of the dangers of relying on in-band security - where you are using a system to verify itself.  If the system has indeed been compromised, then) you can no longer trust the verification process as it too could have been tampered with.  If you can't trust that the verification process is telling the truth, how do you know whether the system has been compromised or not?

Getting back to our malicious programs, you might think booting off read-only media will prevent programs from being replaced.  Many systems that can boot off read-only media have the ability to mount overlay filesystems to give the impression that the filesystem is read-write.  It would not be that difficult for the suid binary to run in the user's own startup scripts, then, as the root user, mount a new overlay filesystem with the modified sha256sum and PGP binaries overriding the originals.  It would do this on every boot, which means if you examined your boot media on another running system it would look fine, and if you booted a machine with it and ran the checksums there, it would still look fine - even though it was sending all your passwords out to a remote system.

Admittedly there are many ifs and buts in this scenario, and you could argue that if you are targeted individually then there is little you can do anyway.  However, when discussing security I always find it interesting to think about how one might get around it, as it can often lead to ideas that make the system more secure - for example, much of this scenario could be defeated (or at least made more difficult) by setting the read-only boot media to mount the home directory and other read-write areas with the nosuid option, so they cannot run suid binaries.

There is actually nothing wrong with this idea of checksumming your files - in fact there are a number of IDS (intrusion detection) programs out there that will do it for you automatically.  Many attacks are of the "smash and grab" variety that won't try very hard to defeat an IDS anyway, so checksums actually work quite well.  As with any type of security, the issues only arise when you put your complete trust in an idea, or it's your only line of defense.

So my thanks go to Ben Kenobi for the thought-provoking article, and for making me discover that even though I don't use checksumming on my own system, I probably should still be mounting my home directory with the nosuid option!