Part 1 | Part 2 | Part 3 | Part 4

Part 1

What Is a Trojan?

Before I start, I want to offer a definition of what a trojan is because these devices are often confused with other malicious code. A trojan horse is

• An unauthorized program contained within a legitimate program. This unauthorized program performs functions unknown (and probably unwanted) by the user.
  
  
• A legitimate program that has been altered by the placement of unauthorized code within it; this code performs functions unknown (and probably unwanted) by the user.
  
  
• Any program that appears to perform a desirable and necessary function but that (because of unauthorized code within it that is unknown to the user) performs functions unknown (and probably unwanted) by the user.

The unauthorized functions that the trojan performs may sometimes qualify it as another type of malicious device as well. For example, certain viruses fit into this category. Such a virus can be concealed within an otherwise useful program. When this occurs, the program can be correctly referred to as both a trojan and a virus . The file that harbors such a trojan/virus has effectively been trojaned . Thus, the term trojan is sometimes used as a verb, as in "He is about to trojan that file."

Classic Internet security documents define the term in various ways. Perhaps the most well known (and oddly, the most liberal) is the definition given in RFC 1244, the Site Security Handbook: A trojan horse program can be a program that does something useful, or merely something interesting. It always does something unexpected, like steal passwords or copy files without your knowledge.

Another definition that seems quite suitable is that given by Dr. Alan Solomon, an internationally renowned virus specialist, in his work titled All About Viruses : A trojan is a program that does something more than the user was expecting, and that extra function is damaging. This leads to a problem in detecting trojans. Suppose I wrote a program that could infallibly detect whether another program formatted the hard disk. Then, can it say that this program is a trojan? Obviously not if the other program was supposed to format the hard disk (like Format does, for example), then it is not a trojan. But if the user was not expecting the format, then it is a trojan. The problem is to compare what the program does with the user's expectations. You cannot determine the user's expectations for a program.

At day's end, you can classify a trojan as this: any program that performs a hidden and unwanted function. This may come in any form. It might be a utility that purports to index file directories or one that unlocks registration codes on software. It might be a word processor or a network utility. In short, a trojan could be anything (and could be found in anything) that you or your users introduce to the system.

Where Do Trojans Come From?

Trojans are created strictly by programmers. One does not get a trojan through any means other than by accepting a trojaned file that was prepared by a programmer. True, it might be possible for a thousand monkeys typing 24 hours a day to ultimately create a trojan, but the statistical probability of this is negligible. Thus, a trojan begins with human intent or mens rea . Somewhere on this planet, a programmer is creating a trojan right now. That programmer knows exactly what he or she is doing, and his or her intentions are malefic (or at least, not altruistic).

The trojan author has an agenda. That agenda could be almost anything, but in the context of Internet security, a trojan will do one of two things:

• Perform some function that either reveals to the programmer vital and privileged information about a system or compromises that system.
  
  
• Conceal some function that either reveals to the programmer vital and privileged information about a system or compromises that system.

Some trojans do both. Additionally, there is another class of trojan that causes damage to the target (for example, one that encrypts or reformats your hard disk drive). So trojans may perform various intelligence tasks (penetrative or collective) or tasks that amount to sabotage.

One example that satisfies the sabotage-tool criteria is the PC CYBORG trojan horse. As explained in a December 19, 1989 CIAC bulletin ("Information about the PC CYBORG (AIDS) Trojan Horse"): There recently has been considerable attention in the news media about a new trojan horse which advertises that it provides information on the AIDS virus to users of IBM PC computers and PC clones. Once it enters a system, the trojan horse replaces AUTOEXEC.BAT , and may count the number of times the infected system has booted until a criterion number (90) is reached. At this point PC CYBORG hides directories, and scrambles (encrypts) the names of all files on drive C:. There exists more than one version of this trojan horse, and at least one version does not wait to damage drive C:, but will hide directories and scramble file names on the first boot after the trojan horse is installed.

Another example (one that caused fairly widespread havoc) is the AOLGOLD trojan horse. This was distributed primarily over the Usenet network and through e-mail. The program was purported to be an enhanced package for accessing America Online (AOL). The distribution consisted of a single, archived file. Unzipping the archive revealed two files, one of which was a standard INSTALL.BAT file. Executing the INSTALL.BAT file resulted in 18 files being expanded to the hard disk. As reported in a security advisory ("Information on the AOLGOLD Trojan Program") dated Sunday, February 16, 1997:

The trojan program is started by running the INSTALL.BAT file. The INSTALL.BAT file is a simple batch file that renames the VIDEO.DRV file to VIRUS.BAT and then runs it. VIDEO.DRV is an amateurish DOS batch file that starts deleting the contents of several critical directories on your C: drive, including

c:\
c:\dos
c:\windows
c:\windows\system
c:\qemm
c:\stacker
c:\norton

When the batch file completes, it prints a crude message on the screen and attempts to run a program named DOOMDAY.EXE . Bugs in the batch file prevent the DOOMDAY.EXE program from running. Other bugs in the file cause it to delete itself if it is run from any drive but the C: drive. The programming style and bugs in the batch file indicates that the trojan writer appears to have little programming experience.

These trojans were clearly the work of amateur programmers: kids who had no more complex an agenda than causing trouble. These were both destructive trojans and performed no sophisticated collective or penetrative functions. Such trojans are often seen, and usually surface, on the Usenet news network.

However, trojans (at least in the UNIX world) have been planted by individuals that are also involved in the legitimate development of a system. These are inside jobs, where someone at a development firm inserts the unauthorized code into an application or utility (or, in rare instances, the core of the operating system itself). These can be far more dangerous for a number of reasons:

• These trojans are not destructive (they collect intelligence on systems); their discovery is usually delayed until they are revealed by accident.
  
  
• Because most servers that matter run UNIX, some highly trusted (and sensitive) sites can be compromised. By servers that matter, I mean those that provide hundreds or even thousands of users access to the Internet and other key networks within the Internet. These are generally governmental or educational sites, which differ from sites maintained, for example, by a single company. With a single company, the damage can generally travel only so far, placing the company and all its users at risk. This is a serious issue, to be sure, but is relevant only to that company. In contrast, the compromise of government or educational sites can place thousands of computers at risk.

There are also instances where key UNIX utilities are compromised (and trojaned) by programmers who have nothing to do with the development of the legitimate program. This has happened many times and, on more than one occasion, has involved security-related programs. For example, following the release of SATAN, a trojan found its way into the SATAN 1.0 distribution for Linux.

Reportedly, the file affected was a program called fping. The story goes as follows: A programmer obtained physical access to a machine housing the program. He modified the main() function and altered the fping file so that when users ran SATAN, a special entry would be placed in their /etc/passwd file. This special entry was the addition of a user named suser . Through this user ID, the perpetrator hoped to compromise many hosts. As it happened, only two recorded instances of such compromise emerged. Flatly stated, the programming was of poor quality. For example, the trojan provided no contingency for those systems that made use of shadowed passwords.

As you can see, a trojan might crop up anywhere. Even a file originating from a reasonably trusted source could be trojaned.

 

NEXT - Where Might One Find a Trojan?