What Level of Risk Do Trojans Represent?
Trojans represent a very high level of risk, mainly for reasons already stated:
- Trojans are difficult to detect.
- In most cases, trojans are found in binaries, which remain largely in non-human-readable form.
- Trojans can affect many machines.
Let me elaborate. Trojans are a perfect example of the type of attack that is fatal to the system administrator who has only a very fleeting knowledge of security. In such a climate, a trojan can lead to total compromise of the system. The trojan may be in place for weeks or even months before it is discovered. In that time, a cracker with root privileges could alter the entire system to suit his or her needs. Thus, even when the trojan is discovered, new holes may exist of which the system administrator is completely unaware.
How Does One Detect a Trojan?
Detecting trojans is less difficult than it initially seems. But strong knowledge of your operating system is needed; also, some knowledge of encryption can help.
If your environment is such that sensitive data resides on your server (which is never a good idea), you will want to take advanced measures. Conversely, if no such information exists on your server, you might feel comfortable employing less stringent methods. The choice breaks down to need, time, and interest. The first two of these elements represent cost. Time always costs money, and that cost will rise depending on how long it has been since your operating system was installed. This is so because in that length of time, many applications that complicate the reconciliation process have probably been installed. For example, consider updates and upgrades. Sometimes, libraries (or DLL files) are altered or overwritten with newer versions. If you were using a file-integrity checker, these files would be identified as changed. If you were not the person who performed the upgrade or update, and the program is sufficiently obscure, you might end up chasing a phantom trojan. These situations are rare, true, but they do occur.
Most forms of protection against (and prevention of) trojans are based on a technique sometimes referred to as object reconciliation. Although the term might sound intimidating, it isn't. It is a fancy way of asking "Are things still just the way I left them?" Here is how it works: Objects are either files or directories. Reconciliation is the process of comparing those objects against themselves at some earlier (or later) date. For example, take a backup tape and compare the file PS as it existed in November 1995 to the PS that now resides on your drive. If the two differ, and no change has been made to the operating system, something is amiss. This technique is invariably applied to system files that are installed as part of the basic operating system.
Object reconciliation can be easy understood if you recognize that for each time a file is altered in some way, that file's values change. For example, one way to clock the change in a file is by examining the date it was last modified. Each time the file is opened, altered, and saved, a new last-modified date emerges. However, this date can be easily manipulated. Consider manipulating this time on the PC platform. How difficult is it? Change the global time setting, apply the desired edits, and archive the file. The time is now changed. For this reason, time is the least reliable way to reconcile an object (at least, relying on the simple date-last-modified time is unreliable). Also, the last date of modification reveals nothing if the file was unaltered (for example, if it was only copied or mailed).
NOTE: PC users who have used older machines can easily understand this. Sometimes, when the CMOS battery fails, the system may temporarily fail. When it is brought back up, you will see that a few files have the date January 1, 1980.
Another way to check the integrity of a file is by examining its size. However, this method is extremely unreliable because of how easily this value can be manipulated. When editing plain text files, it is simple to start out with a size of, say, 1,024KB and end up with that same size. It takes cutting a bit here and adding a bit there. But the situation changes radically when you want to alter a binary file. Binary files usually involve the inclusion of special function libraries and other modules without which the program will not work. Thus, to alter a binary file (and still have the program function) is a more complicated process. The programmer must preserve all the indispensable parts of the program and still find room for his or her own code. Therefore, size is probably a slightly more reliable index than time. Briefly, before I continue, let me explain the process by which a file becomes trojaned.
The most common scenario is when a semi-trusted (known) file is the object of the attack. That is, the file is native to your operating system distribution; it comes from the vendor (such as the file csh in UNIX or command.com in DOS). These files are written to your drive on the first install, and they have a date and time on them. They also are of a specified size. If the times, dates, or sizes of these files differ from their original values, this raises immediate suspicion.
Evil programmers know this. Their job, therefore, is to carefully examine the source code for the file (usually obtained elsewhere) for items that can be excluded (for example, they may single out commented text or some other, not-so-essential element of the file). The unauthorized code is written into the source, and the file is recompiled. The cracker then examines the size of the file. Perhaps it is too large or too small. The process then begins again, until the attacker has compiled a file that is as close to the original size as possible. This is a time-consuming process. If the binary is a fairly large one, it could take several days.
NOTE: When an original operating-system distributed file is the target, the attacker may or may not have to go through this process. If the file has not yet been distributed to anyone, the attacker need not concern himself or herself with this problem. This is because no one has yet seen the file or its size. Perhaps only the original author of the file would know that something was amiss. If that original author is not security conscious, he or she might not even know. If you are a programmer, think now about the very last binary you compiled. How big was it? What was its file size? I bet you don't remember.
When the file has been altered, it is placed where others can obtain it. In the case of operating-system distributions, this is generally a central site for download (such as sunsite.unc.edu, which houses one of the largest collection of UNIX software on the planet). From there, the file finds its way into workstations across the void.
NOTE: sunsite.unc.edu is the Sun Microsystems-sponsored site at UNC Chapel Hill. This site houses the greater body of free software on the Internet. Thousands of individuals--including me--rely on the high-quality UNIX software available at this location. Not enough good can be said about this site. It is a tremendous public service.
For reasons that must now seem obvious, the size of the file is also a poor index by which to measure its alteration. So, to recount: Date, date of last access, time, and size are all indexes without real meaning. None of these alone is suitable for determining the integrity of a file. In each, there is some flaw--usually inherent to the platform--that makes these values easy to alter. Thus, generating a massive database of all files and their respective values (time, size, date, or alteration) has only very limited value:
...a checklist is one form of this database for a UNIX system. The file content themselves are not usually saved as this would require too much disk space. Instead, a checklist would contain a set of values generated from the original file--usually including the length, time of last modification, and owner. The checklist is periodically regenerated and compared against the save copies, with discrepancies noted. However...changes may be made to the contents of UNIX files without any of these values changing from the stored values; in particular, a user gaining access to the root account may modify the raw disk to alter the saved data without it showing in the checklist.
There are other indexes, such as checksums, that one can check; these are far better indexes, but also not entirely reliable. In the checksum system, the data elements of a file are added together and run through an algorithm. The resulting number is a checksum, a type of signature for that file (bar-code readers sometimes use checksums in their scan process). On the SunOS platform, one can review the checksum of a particular file using the utility sum. sum calculates (and prints to STDOUT or other specified mediums) the checksums of files provided on the argument line.
Although checksums are more reliable than time, date, or last date of modification, these too can be tampered with. Most system administrators suggest that if you rely on a checksum system, your checksum list should be kept on a separate server or even a separate medium, accessible only by root and other trusted users. In any event, checksums work nicely for checking the integrity of a file transferred, for example, from point A to point B, but that is the extent of it.
NOTE: Users who have performed direct file transfers using communication packages such as Qmodem, Telix, Closeup, MTEZ, or others will remember that these programs sometimes perform checksum or CRC checks as the transfers occur. For each file transferred, the file is checked for integrity. This reduces--but does not eliminate--the likelihood of a damaged file at the destination. If the file proves to be damaged or flawed, the transfer process may begin again. When dealing with sophisticated attacks against file integrity, however, this technique is insufficient.
Cross Reference: Tutorials about defeating checksum systems are scattered across the Internet. Most are related to the development of viruses (many virus-checking utilities use checksum analysis to identify virus activity). A collection of such papers (all of which are underground) can be found at http://www.pipo.com/guillermito/darkweb/news.html.
0 comments
Post a Comment