Fun With Tripwire
by Estragon
In war movies, a trip wire is invisible until you stumble across it. Then, all of a sudden, everybody knows you're there.
System administrators use Tripwire software for the same purpose: you sneak into a system and think you completely covered your tracks, but somehow the sysadmin knew you were there. Tripwire is for spotting changes in files (including directories) on the system it protects. So when a hacker wants to leave a Trojan'd version of a program like in.telnetd to make it easier to get back in again, or adds a new /etc/passwd entry, Tripwire finds out.
Tripwire isn't the only important intrusion detection software out there - other things, like log watchers and network monitors, are important too. But Tripwire is probably the best single way for a sysadmin to tell if a system has been hacked.
The original Tripwire was developed at Purdue University's COAST Lab, and is still available at: coast.cs.purdue.edu/pub/COAST/Tripwire
Now, there's a new enhanced version available free from: www.tripwiresecurity.com
Tripwire runs under UNIX/Linux but can protect any systems whose disks it can read (like over NFS). An NT version is supposedly forthcoming.
So what does it do?
Tripwire initially makes a database of checksums and other information (like access times, creation dates, etc.) for the files and directories you specify. Then, when it's run later, Tripwire can tell if files are different than the database entry.
Remember how excited you were to discover how to put a Trojan'd version of a program (like /bin/login) on a UNIX system with the same file size, creation date, and everything? Well... Tripwire will compute a checksum (using MD5 or another algorithm) and know that the actual contents of the file are different.
How can you overcome Tripwire? If the sysadmin is good, this is going to be tough. But lots of sysadmins are clueless, even if they run Tripwire.
Here's the deal on running Tripwire:
- The sysadmin should run Tripwire to make the initial database before the system is on the net, and when the OS was loaded from known good media (like a CD-ROM, or maybe another local system).
- The sysadmin should keep the Tripwire database on a locked read-only medium, like a write-protected floppy disk or CD.
- The sysadmin should run Tripwire nightly, so that the output (including whether there are any discrepancies) is sent by e-mail to him/her.
- The sysadmin should read this e-mail every day to make sure nothing has changed.
- There are a few places where a hacker could interfere to keep the sysadmin from knowing that system software was changed.
1.) If you can get on the system and install Trojan'd programs (or whatever) before the Tripwire database is created, you're golden! Lots of clueless sysadmins will reinstall the OS (like after they discover they were broken into), but will never take the system off the net. There's a window of opportunity, before the Tripwire database is created, to make changes so that Tripwire will think your warez are legit!
2.) Don't just disable Tripwire, or keep it from running. An alert sysadmin will notice right away that something's wrong when he/she doesn't get daily mail. (Tripwire is usually run from cron.)
3.) Although such hacks haven't been widespread, it is possible to Trojan horse Tripwire by changing the libraries on disk that it uses (like libc). This would be tough, and would also assume that Tripwire wasn't statically linked (it usually is, but not always since space on floppy disks is tight). See the article "Bypassing Integrity Checking Systems" in Phrack, Issue #51 about how to do this with loadable modules in FreeBSD.
4.) If you can get access to the sysadmin's email, you could find out what the daily message should look like, then continue to send the e-mail daily at the appropriate time, with the expected output.
5.) If you can get physical access to the locked read-only media, you could re-run the Tripwire database initialization, so that your changes don't show up.
#5 is the best possible solution. But unless the sysadmin is truly clueless and has stored the database on a read/write medium (like a hard drive, maybe that you could remount from real-only to read-write), you need to have actual physical access to pull this off.
#4 is pretty decent, but means you need to intercept the e-mail and set up a good facsimile to fool the sysadmin later.
#4 could work pretty well on a system where Tripwire, the database, and the sysadmin's mail are all on the same system. But this can get tougher if e-mail is forwarded elsewhere, and the Tripwire database lives on another (more secure) system - maybe mounted read-only by NFS.
The bottom line is that Tripwire, when properly used, is tough to fool. In the case where System A's filesystems are mounted to System B, and Tripwire is run from System B, you might not even know it's there if you only have access to System A.
In a corporate (or even academic) setting, the above is a pretty likely scenario - this way, the sysadmin(s) can monitor a bunch of systems all at once.
If you administer a system, no matter how small, you should be running Tripwire. Even if it's your home Linux system with a modem, how would you know if, while you're Telnet'ing out, someone else isn't Telnet'ing in (or exploiting some other hole)?