Part 1 | Part 2 | Part 3 | Part 4

Part 2

Where Might One Find a Trojan?

Technically, a trojan could appear almost anywhere, on any operating system or platform. However, with the exception of the inside job mentioned previously, the spread of trojans works very much like the spread of viruses. Software downloaded from the Internet, especially shareware or freeware, is always suspect. Similarly, materials downloaded from underground servers or Usenet newsgroups are also candidates.

Sometimes, one need not travel down such dark and forbidden alleys to find a trojan. Trojans can be found in major, network-wide distributions. For example, examine this excerpt from a CIAC security advisory ("E-14: Wuarchive Ftpd Trojan Horse"), posted to the Net in 1994: CIAC has received information that some copies of the wuarchive FTP daemon (ftpd) versions 2.2 and 2.1f have been modified at the source code level to contain a trojan horse. This trojan allows any user, local or remote, to become root on the affected UNIX system. CIAC strongly recommends that all sites running these or older versions of the wuarchive ftpd retrieve and install version 2.3. It is possible that versions previous to 2.2 and 2.1f contain the trojan as well.

wftpd is one of the most widely used FTP servers in the world. This advisory affected thousands of sites, public and private. Many of those sites are still at risk, primarily because the system administrators at those locations are not as security conscious as they should be.

C'mon! How Often Are Trojans Really Discovered?

Trojans are discovered often enough that they are a major security concern. What makes trojans so insidious is that even after they are discovered, their influence is still felt. Trojans are similar to sniffers in that respect. No one can be sure exactly how deep into the system the compromise may have reached. There are several reasons for this, but I will limit this section to only one.

As you will soon read, the majority of trojans are nested within compiled binaries. That is to say: The code that houses the trojan is no longer in human-readable form but has been compiled. Thus, it is in machine language. This language can be examined in certain raw editors, but even then, only printable character strings are usually comprehensible. These most often are error messages, advisories, option flags, or other data printed to STDOUT at specified points within the program:

my_function()
{
cout << "The value you have entered is out of range!\n";
cout << "Please enter another:"
}

Because the binaries are compiled, they come to the user as (more or less) point-and-shoot applications. In other words, the user takes the file or files as is, without intimate knowledge of their structure.

When authorities discover that such a binary houses a trojan, security advisories are immediately issued. These tend to be preliminary and are later followed by more comprehensive advisories that may briefly discuss the agenda and method of operation of the trojan code. Unless the user is a programmer, these advisories spell out little more than "Get the patch now and replace the bogus binary." Experienced system administrators may clearly understand the meaning of such advisories (or even clearly understand the purpose of the code, which is usually included with the comprehensive advisory). However, even then, assessment of damages can be difficult.

In some cases, the damage seems simple enough to assess (for example, instances where the trojan's purpose was to mail out the contents of the passwd file). The fix is pretty straightforward: Replace the binary with a clean version and have all users change their passwords. This being the whole of the trojan's function, no further damage or compromise is expected. Simple.

But suppose the trojan is more complex. Suppose, for example, that its purpose is to open a hole for the intruder, a hole through which he gains root access during the wee hours. If the intruder was careful to alter the logs, there might be no way of knowing the depth of the compromise (especially if you discover the trojan months after it was installed). This type of case might call for reinstallation of the entire operating system.

Conversely, trojans may be found in executable files that are not compiled. These might be shell scripts, or perhaps programs written in Perl, JavaScript, VBScript, Tcl (a popular scripting language), and so forth. There have been few verified cases of this type of trojan. The cracker who places a trojan within a noncompiled executable is risking a great deal. The source is in plain, human-readable text. In a small program, a block of trojan code would stand out dramatically. However, this method may not be so ludicrous when dealing with larger programs or in those programs that incorporate a series of compiled binaries and executable shell scripts nested within several subdirectories. The more complex the structure of the distribution, the less likely it is that a human being, using normal methods of investigation, would uncover a trojan.

Moreover, one must consider the level of the user's knowledge. Users who know little about their operating system are less likely to venture deep into the directory structure of a given distribution, looking for mysterious or suspicious code (even if that code is human readable). The reverse is true if the user happens to be a programmer. However, the fact that a user is a programmer does not mean he or she will instantly recognize a trojan. I know many BASIC programmers who have a difficult time reading code written in Perl. Thus, if the trojan exists in a scripting language, the programmer must first be familiar with that language before he or she can identify objectionable code within it. It is equally true that if the language even slightly resembles a language that the programmer normally uses, he or she may be able to identify the problem. For example, Perl is sufficiently similar to C that a C programmer who has never written a line of Perl could effectively identify malicious code within a Perl script. And of course, anyone who writes programs in a shell language or awk would likewise recognize questionable code in a Perl program.

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.

 

NEXT - How Does One Detect a Trojan?