Dave's Bit Bucket

Thursday July 26, 2007

"Integrity Checking in Depth"

Over the last few weeks, a number of folk have asked me about various elements of integrity checking and intrusion detection - so I figured it would be useful to aggregate my thoughts here.

First, I distinguish between integrity checking and intrusion detection, on the grounds that intrusion detection needs to be realtime whereas integrity checking does not; you can run BART or Tripwire a couple of times a day to gather reports of changes (this being the maximum recommended frequency, incidentally, as doing a full sweep of a system consumes a reasonable amount of system resource), whereas you'd want Prelude (or whatever IDS you're running) to scream at you in the form of an SNMP trap the moment it sees some activity it's not happy with.

With Solaris 10, you actually get the luxury of multiple methods of integrity checking; the title of this article is an allusion to the popular and valuable concept of "Defence in Depth", which is reflected in the ways in which you can make integrity checking work. The ways in which these integrity checking mechanisms relate to and complement eachother is subtle, and thus worth documenting. Out of the box, you get elfsign and BART, and with a little Internet connectivity, you can also call upon the services of the Solaris Fingerprint Database (SFpDB).

Today, elfsign verify <pathname> can tell you whether a given binary was genuinely released by Solaris Release Engineering as part of a production build of Solaris 10, or a subsequent Sun-issued patch to it. What it won't tell you, is if the binary is the current version, patch-wise; it also won't tell you anything about the config or change status of files which aren't ELF binaries, nor will it tell you about binaries bundled with Solaris which are part of specific third-party contributions (these don't get elfsigned by us, as from a legal perspective, signing a binary provided by a third party involves modifying that binary by changing its ELF header, thus creating a derivative work).

It is also worth noting that elfsign is a point of circular dependency. While anyone trying to trojan a Solaris 10 environment cannot get an elfsign-verifiable signature for their trojan binaries, if they were able - as a result of their attack mechanism - to trojan elfsign too, then it's Game Over. This is yet another good reason to deploy network-listening applications in sparse-root zones wherever possible, so that the elfsign binary remains usable but immutable from the application environment's perspective.

BART is a tool I typically describe - with tongue half in cheek - as "a poor man's Tripwire". While Glenn has produced a useful Blueprint on how to scale BART management, I still honestly think that, if you want to integrity-check a datacentre's-worth of installed systems, Tripwire is the superior product - this is owing to its cross-platform nature and the elegance of its key management. What both BART and Tripwire will tell you is, whether the file you had yesterday is the same as the file you have today. Both BART and Tripwire are agnostic regarding the file type, therefore they are applicable to scripts and config files as well as ELF binaries. However, they won't tell you where a file came from, nor what version it is. However, if someone manages to install a Trojan - or downgrade a Sun-issued and signed binary to a version which has an exploitable vulnerability which has subsequently been patched - either BART or Tripwire can potentially catch things which elfsign won't. The database of file digests which Tripwire holds on a system is also more resistant to attack than the equivalent BART database - the Tripwire db being signed with a key which is held on the Tripwire management infrastructure, rather than the host itself. Again, deploying network-accessible applications in sparse-root zones mitigates risk - most system binaries are loopback-mounted readonly in such environments, making them immutable even in the event of application compromise.

Last but not least, we have the Solaris Fingerprint Database. This contains comprehensive mappings between pathnames, MD5 digests and release / patch version numbers for scripts and binaries back to very early versions of Solaris; if you present a pathname and digest to it, it can tell you not only whether the associated file matches something produced by Solaris Release Engineering, but what release or patch version it is associated with. This maps to the functionality of elfsign plus the ability (when correlated with current patch levels) to spot binary version downgrade attacks, however Internet connectivity (direct or indirect) is required, and while it would be difficult to Trojan the MD5 digest generator to produce output which would match what the fingerprint database considered acceptable, it is not impossible (although sparse-root zones can help here, again).

So, there you have it - while any of the integrity verification tools above could potentially be compromised when used in isolation, owing to points of circular dependency (although to do so would be hard in all cases), a reinforcing combination of them plus the use of sparse-root zones results in an integrity enforcing and verification capability which would cause even a very capable attacker to have nightmares.

Glenn also has a Blueprint on integrating SFpDB and BART, which makes for good reading.

(2007-07-26 07:13:01.0) Permalink Comments [0]