- So, What Do Traditional RootKits Do?
- Defending Against Traditional RootKits
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Defending Against Traditional RootKits
As we have seen, traditional RootKits can cause some serious problems. How can you defend against them? A variety of techniques should be applied in tandem to prevent such attacks.
Don't Let Them Get Root in the First Place!
As we have seen, traditional RootKits are quite powerful, and preventing their installation is certainly a worthwhile pursuit. An attacker must have root-level access to install a RootKit. By preventing attackers from getting root in the first place, you prevent them from installing RootKits. Therefore, everything we've discussed about securing a system, including using difficult-to-guess passwords, applying security patches, and closing unused ports, is very helpful in preventing attackers from gaining root and installing RootKits. If you are a system, security, or network administrator, your organization must have a defined security program in place for hardening systems and maintaining their security.
Looking For Changes in the File System
Unfortunately, even if you keep your system hardened, an attacker still may find some unknown hole in your system and gain root. There is no such thing at 100 % security; flaws in information protection schemes happen. So, how can you detect a RootKit once it is installed? As we have seen, the computer underground has very carefully designed RootKits to foil detection. However, all is not lost because there are some interesting techniques for detecting a RootKit.
One possible method for detecting RootKits is to use the command echo * to list the contents of a directory. While most RootKits Trojanize the ls program, very few modify the echo command. Therefore, echo * will return a legitimate listing of the contents of a directory. If the results of echo * differ from what the ls command shows for a given directory, something may be hidden in that directory and you should investigate further. While the echo * technique can be helpful, it tends to be rather impractical. Searching an entire file system to see if there are any discrepancies between the files listed in the output of echo * and ls can take considerable effort. Better methods are available for detecting RootKits.
Host-Based Security Scanners
Some tools are available today that can analyze /bin/login programs to determine if a known RootKit is installed. These tools consist of an agent that is installed on the protected machine. Periodically, the tool scans the local system looking for evidence of an attack, including performing an automated RootKit check of /bin/login on the local system. Essentially, these tools know what a corrupt /bin/login looks like and can compare the existing /bin/login routine with the known corrupt versions. For critical servers (for example, Internet servers, critical internal servers, and so on), you may want to consider such a host-based scanner or host-based intrusion-detection system (IDS).
The Best Defense for Traditional RootKits: Program Integrity Checkers Like Tripwire and AIDE
Really, the best way to defend against RootKits is to use cryptographically strong digital fingerprint technologies to periodically verify the integrity of critical system files. The fix program included in RootKits can pad a Trojan horse program so that it appears unaltered to the sum routine. This flaw is based on the simple checksum algorithm use by the sum program, which can easily be fooled by applying appropriate padding to the file.
By calculating a strong cryptographic fingerprint of sensitive system files, an attacker will not be able to alter the file and come up with the same fingerprint. MD5, a one-way hash function, is a very suitable algorithm for calculating these strong fingerprints. MD5 supports creating a unique sequence of bits (a digital fingerprint, essentially) based on the contents of a given file. Because MD5 is a one-way hash function, an attacker will not be able to determine how to modify the file in such a way that its MD5 fingerprint will remain the same. Therefore, the RootKit fix trick of padding will not work if a function like MD5 is applied to create a database of hashes for critical system files like /bin/login, ifconfig, netstat, and so on. Therefore, a system or security administrator should create a read-only database of cryptographic hashes for critical system files, store these hashes offline, and periodically compare hashes of the active programs to the stored hashes looking for changes.
Tripwire is a wonderful file integrity-checking tool originally written by Gene Spafford and Gene Kim of Purdue University. Tripwire generates MD5 hashes of critical files (including /bin/login, ls, ps, du, /etc/passwd, and many others) and periodically compares the hashes with a safe database. A free version of Tripwire is available at http://www.tripwire.org/. Furthermore, if you need vendor support, Tripwire has been commercialized and can be purchased at http://www.tripwire.com/. Additionally, various other MD5 hash tools are available, or PGP signatures could be used to ensure the integrity of system files. One of the most promising open source, free file integrity-checking tools is AIDE.
The safe hashes or signatures should be stored on read-only media (such as a write-protected floppy disc or a write-once CD-ROM). You must check the hashes of your critical executables against this safe database on a regular basis (daily or weekly), and all changes must be reconciled. Of course, an integrity-checking tool works best if you apply it before an attack occurs so that you have a secure baseline of hashes to compare against. If you are comparing the hash of a back-door /bin/login with the hash of the same back door from a week earlier, you won't detect any problems. You must compare against a trusted baseline, like the original system installation or a recent patch. Therefore, you must have a policy and processes regarding running file integrity checkers on all critical systems. To help establish a safe baseline, some vendor Web sites (such as Sun Microsystems) offer hashes of trusted versions of their programs available for access on the Web. Sun's Solaris Fingerprint Database (sfpDB) is a public resource containing hashes of critical Solaris executables at http://sunsolve.sun.com/pub-cgi/show.pl?target=content/content7. This is a fantastic idea, and kudos go to Sun for this very useful resource.
You must analyze the output of the file integrity-checking program and reconcile all changes to critical system files. Why did your /bin/login program change? Did anything else change? Was it the result of a legitimate system patch or other upgrade that a system administrator applied since you last ran the integrity check? If not, your system may have been RootKitted.