We're assuming by now that it's pretty clear that there isn't any everything else . There will always be other attacks and other means for third parties to modify or disrupt your system. Before ending the chapter, however, you should be familiar with a few other concepts that are mentioned throughout the book.
A rootkit isn't a compromise, per se; it is a set of tools that are installed after a system has been compromised and root access gained . The purpose of a rootkit is to provide tools for covering an attacker's tracks so that its presence will not be detected on the machine. In some cases, rootkits may contain additional software for carrying out further attacks.
For example, common rootkit components include the following:
du / ls / find . Modified to hide files.
top / ps . Modified to hide processes (sniffers and so on).
netstat. Modified to hide remote connections.
ssh / xinet / inetd / tcpd . Modified to allow remote access, ignore deny lists.
syslogd. Modified to hide log entries.
wtmp / utmp / lastlog . Software included to modify or erase the system accounting logs.
killall. Modified to not kill attacker processes.
lsof. Modified to hide connections and files.
passwd / sudo / su . Modified to provide root access.
More information on the logs and rootkit modifications can be found in Chapter 19, "Logs and User Activity Accounting." If a rootkit has been installed, the operating system cannot be trusted. You must make the decision to either attempt to repair the damage or reinstall the operating system. The only cases where a repair should be attempted are those where a piece of software such as Tripwire (http:// sourceforge .net/projects/tripwire/) is installed and can verify which files have changed from the default distribution.
A quick and dirty solution is to use md5 to calculate a checksum for the critical system files, which can be stored offline and used for comparison in the event of an attack:
# md5 /usr/bin/* MD5 (/usr/bin/CFInfoPlistConverter) = be7664241c675f06424961d8773d19c1 MD5 (/usr/bin/a2p) = 6f0ff3f32ffc295cc00ea2ecf83b1143 MD5 (/usr/bin/aclocal) = 6b204bce8a0151c330649cb3ff764a43 MD5 (/usr/bin/aclocal-1.6) = 6b204bce8a0151c330649cb3ff764a43 MD5 (/usr/bin/addftinfo) = e55d67a1e4848a4a4abd75c9d78106dc MD5 (/usr/bin/addr) = 2c4824c5fa6a9ee332a5e4ab14787e42 MD5 (/usr/bin/aexml) = 788248a22bdfac053473af90728efca1 MD5 (/usr/bin/afmtodit) = 7da2c8b3d85e10500bd01b59ae52780b MD5 (/usr/bin/appleping) = 0cda19ad69004d8fd1b6b66e7159ece4 ...
The calculated 128-bit signatures will be identical only if the files are identical. Files altered by a rootkit display a different signature from the initial calculations.
At this time, there are no known "popular" rootkits for Mac OS X, although it is certainly possible that anyone with access to a Mac and a compiler has recompiled any of the popular Linux rootkits for the operating system. A rootkit checker has already been compiled for Mac OS X (http://www.gouedart-lafeuille.net/software/applescript/ChkRootKit_for_MacOSX/, a port of the ChkRootKit software found at http://www.chkrootkit.org). ChkRootKit is capable of detecting common rootkit changes and reporting the files that have been compromised.
Too often (and with reason), users trust data if it is processed by software they know and trust. Someone with an understanding of their internals, however, can often trick these programs into falsifying or providing "unexpected" data.
A simple example of this is the system date and time. Files are stamped with a creation date and time that cannot be changed by end users. The modification times are easily updated with touch , but the creation date is inaccessible. Tar and other backup utilities can restore files to the system with their original timestamps. As a result, it's easy to modify a file's creation time stamp by tarring it, adjusting the time stamps within the tar file, then untarring it again.
Although this particular form of data falsification is trivial now that everyone on the planet can run a Unix box (and have access to their own system clocks), it is an example of an exploit that allows a user to falsify what is normally considered trusted information.
A Mac OS X 10.2.2 vulnerability was caused by a similar means of slipping information in "under the radar." By creating a disk image as an administrator on a remote system, then opening it under a nonadmin account on another Mac OS X machine, the user opening it can receive elevated administrator privileges (CVE: CAN-2002-1266). Like using tar to modify time stamps, an attacker using this technique need only let the operating system utilities perform the attack for him. Don't worry; this vulnerability was corrected in Mac OS X 10.2.3.
There are numbers of other attacks that can be directed at you personally rather than your machine. Through simple but effective tricks, attackers can gain information about you by just letting you use your computer. These are just a few more things to lose sleep over.
The most obvious piece of information that can be gleaned without a direct attack is whether or not you have and actively read a given email address. It is commonly believed (and in many cases it's certainly true) that spammers use the links in a piece of spam (including the unsubscribe links) to verify that the email address that was used is valid. Unfortunately, all that is needed in most cases is for you to read your mail in order for the spammer to know that your address is active. Most spam is HTML-based and includes images, which are loaded by default in Apple's Mail application. Images can easily be embedded in the HTML so that they pass information back to a script:
[View full width]<img src="http://www.spammeringplace.com/displayimage.php?image=ad.gif &email@example.com">
This might, for example, pass the name of an image to be displayed ( ad.gif ) along with my email address, to the remote host. The potential for this type of information gathering to take place can be eliminated by shutting off viewing of inline HTML objects within Apple Mail's Viewing Preferences. Of course, if you do that, you'll miss out on the graphic- intensive ads for products to make you richer, smaller, or larger.
Even more devious schemes have been designed by some attackers to convince you to willingly provide sensitive information under the pretense of a secure connection. Browser windows , for example, typically indicate a secure connection via the status bar at the bottom of the window. Attackers, through a variety of means (spoofing, compromised site forwarding, and so on), can redirect users to insecure sites for the purpose of collecting information. What the attacker cannot do, however, is (easily) get a site certificate that will be authenticated with your browser. As a result, they cannot create a secure connection with the victim. To "trick" the remote user to into believing that a secure connection is in place, the server can simply spawn a new browser window without a status bar, then draw its own! Using DHTML it would even be possible for an enterprising cracker to develop a complete browser interface within a window. Obviously, the browser wouldn't match everyone's interface ( chances are, Mac users would be safe), but the illusion could be very convincing.