CryptoMark: Locking the Stable door ahead of the Trojan Horse

Once attackers have penetrated a system, they will usually take advantage of their position by extending their reach to compromise other systems (e.g., by sniffing passwords from the network), and by installing “back doors” that will enable them to regain access even if the original insecurity is repaired. A common approach is to install a modified version of a standard system daemon such as telnetd. It is also common for attackers to attempt to cover their tracks by installing doctored versions of standard programs like ls, ps and sum. Programs like this, which conceal something harmful inside a harmless looking exterior, are called Trojan Horses. CryptoMark detects Trojan Horses as they are about to be activated. It is similar in its goals to Kim and Spafford’s Tripwire, but detects intrusions with lower latency. That is, rather than laying dormant until the system administrator next runs a Tripwire integrity check, CryptoMark would detect a Trojan Horse as soon as it is run. Another difference is that CryptoMark can be configured to prevent the Trojan Horse from running at all. Deploying a Trojan Horse involves installing code crafted by the attacker or imported from another site. In principle, this can be detected by requiring that all code that runs on a system be certified. Using Public Key Cryptography, it is possible to sign executable binaries to indicate that they are genuine, and to check the signature on a binary before it is executed. The Trojan Horse would then be exposed before the system is put at risk by loading it. But what is possible in principle does not always work well in practice. Our goals in developing CryptoMark was to deploy code certification as an intrusion detection tool in a real system (LINUX version 2.0.36) so that its practical impact can be This work was partially supported by DARPA Grant F30602-96-1-0331 and by NSF Grant Number CDA-9703218 Introduction and Motivation 2 CryptoMark: Locking the Stable door ahead of the Trojan Horse evaluated. The paper makes three contributions. First, we show that the implementation of binary code certification in a modular system like LINUX is simple. Second, we discuss configurations that trade different degrees of security for different degrees of inconvenience, but in all cases we are able to find reasonable points of compromise. Finally, we show that the impact of the additional checks on system performance is small enough to encourage the wide adoption of this technology. Introduction and Motivation The idea that Public Key Cryptography can be used to digitally sign a document, thus establishing its authenticity, is as old as public key cryptography itself [1]. Toolkits that implement the basic cryptographic algorithms are now widely available, for example, PGP [2] and GPG [3]. CryptoMark, described in this paper, represents the practical application of these ideas in a way that prevents unauthorized programs from running on the protected system. Alternatively, CryptoMark can be configured to allow unauthorized programs to run, but to generate a log record detailing the attempt. When intruders gain access to a system, they frequently try to down-load and run programs that will either seek to discover further weaknesses in the system, or install a back door, or will hide these very activities from legitimate users and system managers. Using CryptoMark, the running of these programs can be prevented or detected. CryptoMark is similar in many respects to Tripwire [4, 5]. Tripwire and CryptoMark both collect vital statistics about files, which are later used to detect tampering with those files. Tripwire operates “off-line”, in the sense that comparison between the current version of the file and the previously recorded version is done when explicitly requested by the system administrator, for example, at 8am every morning. CryptoMark is “on-line”, in the sense that the comparison is done every time that the binary is executed. However, Tripwire is more general than CryptoMark, since it can be applied to any file (for example, configuration files), while CryptoMark protects only executable files. THE BASIC IDEA The basic idea behind digital signatures is simple. Suppose that Alice wants a digital signature. Alice first obtains a pair of keys kpub and kpriv, known as her public and private keys. These keys have the property that if a file (or other sequence of bytes) is first encrypted with kpriv, and the result is then encrypted a second time, with kpub, the original file is obtained. Knowledge of kpriv is like possession of a rubber stamp bearing Alice’s signature. Knowledge of kpub is like the ability to compare the imprint of a stamped signature on a document with the real thing. kpub, as its name implied, is intended to be public, for example, Alice might publish it in an Internet directory, so that anyone who is presented with a document d that claims to be signed by Alice can test that fact by obtaining Alice’s public key kpub, and encrypting d with kpub. If the result makes sense, d was genuine. If the result is gibberish, then d was a forgery. (Note that this is just the opposite of what one would do to maintain secrecy; in that case the sender would encrypt with the public key of the recipient, and the appropriate private key would be needed to read the contents.) Introduction and Motivation CryptoMark: Locking the Stable door ahead of the Trojan Horse 3 In practice, a transmitted document normally contains both the unencrypted and the encrypted version of the original file, so that it is easy to test whether the second encryption actually generates the original text. Because this would make the transmitted document much larger, it is usual to perform the encryption not on the entire file, but instead on a “digest”, a hash of the file contents produced by a digest function. A digest is a function that takes a (usually large) file and produces a (usually much smaller) result called a hash value. A simple example is a CRC or checksum function, which adds the bytes in the original file together, modulo 232or 264. In general, digests are designed to resists inversion— finding another input that produces a known output— and collision— finding two inputs that generate the same hash value. A good digest will depend on every bit of the input, because if it does not, it would be possible to tamper with some of the bits without being detected. MD5 [6] is a digest function that generates a 128-bit hash from a file of arbitrary length. MD5 is widely regarded as being secure, and software implementations are now widely available. APPLYING THE IDEA Given this background, it is easy to see how to use digital signatures to check the authenticity of a binary program. 1. On a secure (possibly non-networked) computer S, Alice generates the binary in the usual way, using her favourite compiler and linker. On LINUX, the result is a loadable file in Executable Linkable Format (ELF). 2. Alice computes the MD5 digest of the executable portions of the ELF, and then encrypts the digest with kpriv. The result is called a certificate for that file 3. She then appends the encrypted digest to the original file, creating a signed version of the binary file. 4. The signed file can now be copied from S to the system P that requires guarding. If S is not on the network, the file can be transmitted by “sneaker net” using a removable medium disk. 5. On P, before the binary is executed, the operating system kernel first checks that the MD5 digest computed from the executable portions of the file and the MD5 digest obtained by decrypting the certificate with kpub are identical. 6. If they are identical, then we can assume with high confidence that the file was indeed signed by Alice, or at least by someone who has Alice’s private key. If they are not, then the file is a forgery, or has been corrupted in some way. In either case, an alert should be sounded. CryptoMark may thus be thought as having two components: a set of utility programs that run on S, and a kernel modification that is inserted into P. Of course, it is possible for S and P to be the same machine; this is convenient, but opens the possibility that an attacker may manage to capture the secret key, and thus gain the ability to forge Alice’s signature. We do not recommend running CryptoMark in this configuration.