What Is a Trojan?
Trojan horses present more difficulties in definition than at first appears. Whereas viruses are defined primarily by their ability to replicate, Trojans are primarily defined by their payload, or, to use a less emotive term, their function. Replication is an absolute value. Either a program replicates, or it doesn't. Damage and intent, however, are not absolutes, at least in terms of program function. The first clue to their nature lies in ancient history and classical mythology.
Origin of the Species
Around the 12th century B.C., Greece declared war on the city of Troy. The dispute arose when Paris, variously described as a shepherd boy and as prince of Troy, abducted Helen, the wife of Menelaus, king of Sparta, and reputed to be the most beautiful woman in the world. The Greeks gave chase and engaged Troy in a 10-year war, but failed to take the city. This, of course, is the central plot of Homer's Iliad.
Finally, the Greek army withdrew, leaving behind a huge wooden horse. Greece's finest soldiers hid silently inside. The people of Troy saw the horse and, thinking with stunning naivete that it was a gift, brought it inside their city. That night, Greek soldiers under the leadership of Odysseus emerged from the horse, and opened the gates to the rest of the Greek army, who destroyed the city. It has been suggested that the Trojan horse story is the origin of the saying "Beware of Greeks bearing gifts."
In computing terms, the term Trojan horse is most often applied to an apparently attractive program concealing in some way an unpleasant surprise.
One well-known definition is included in the (now obsolete) RFC 1244, the first draft of the Site Security Handbook (the more recent draft doesn't include a definition):
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.
This definition contains three useful ideas not that they give us the best possible summary, but they serve as a good starting point for discussion of some implicit ambiguities. First, the definition doesn't say that the Trojan always does something useful or interesting, but that it might. This generality opens a wide range of possibilities, from programs whose only function is to do something malicious; through programs that do something desirable and something malicious but covert; to accidental Trojans, which are intended to do desirable things, but somehow do something undesirable as well (or instead).
Second, this definition includes the idea that a Trojan does something "unexpected" (unexpected to the recipient, or "victim", but not usually to the programmer). This assumption is common to nearly all definitions of Trojans.
Third, it contains the implication that the "payload" is something malicious. In fact, it's quite specific (intentionally or otherwise) about the fact that the cited example payloads (stealing passwords or copying files) involve unauthorized access rather than a breach of data integrity. For our purposes, this is less useful. It is overly specific about the type of security breach it appears to address (breach of privacy), and carries an assumption of malicious intent that is not universally accepted.
Most security professionals would accept a general definition along the lines of "A Trojan is a program that claims to perform some desirable or necessary function, and might even do so, but also performs some function or functions that the individual who runs the program would not expect and would not want."
I Didn't Mean It
Like many definitions, this one misses out on the idea of malicious intent. It therefore begs a number of questions about Easter Eggs (harmless code concealed more or less legitimately in production software by the original production team). Joke programs, installation routines that pass back information to the manufacturer and overwrite previous versions of system files, and accidental Trojans also present difficulties. However, as far as this chapter is concerned, these ambiguities are no bad thing. This chapter will refer (not necessarily in depth) to a whole range of relevant issues, rather than ignore everything that doesn't conform to a strict single definition.
A common modern usage distinguishes Trojans (and related malware, or MALicious softWARE) from viruses and worms, based on the Trojans'inability to self-replicate. In fact, Ian Whalley, in an article for Virus Bulletin (Talking Trojan. Virus Bulletin, July 1998) has suggested using the term non-replicative malware rather than Trojan horse, thus avoiding the popular confusion between replicating programs (viruses, worms) and static code (Trojans, for instance). This certainly has advantages, but reintroduces the assumption of malicious intent (by using the word malware). Clearly, while we may prefer not to admit to malicious intent as a defining characteristic, we can't avoid considering it as a possible or even likely characteristic.
Apart from the intent to deceive implicit in many Trojan definitions, malicious intent can cover a wide range of intentions and mechanisms.
Using the classic tripod model of data security, Trojans can be divided into three broad classes of intent:
Intent to gain unauthorized access
Intent to obstruct availability (deny service)
Intent to modify or destroy data and systems without authorization
By extension of this idea, we can also postulate three further classes of accidental Trojan that allow unauthorized access, obstruct availability, or compromise integrity, but are not intended to do so.
A problem here is that, whereas automated examination and analysis of the binary content of a program can tell us a great deal about function, it can tell us little about the intent of the author.
Dr. Alan Solomon gave a definition in All About Viruses that neatly illustrates the problem from the other end:
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.
Solomon's scenario is useful because it shifts the focus away from the programmer's or distributor's intent and onto the recipient/user's expectations. Implicitly, it also indicates that social engineering is a major component of a Trojan horse because it manipulates the victim's expectations. The passage also restates a problem that we will need to consider in more detail. It is (sometimes) possible to analyze a virus automatically because the defining characteristic of viral code is replication. It is at least theoretically possible to deduce the ability to replicate by automatic or semi-automatic code analysis. (This is one of the ways in which heuristic virus scanners are meant to operate.) It is much more difficult, however, to deduce either the intentions of the programmer or the expectations of the program user by tracing what the code does.
Viruses and worms are sometimes referred to as a special case of Trojan horse. The argument is that, because the legitimate program now contains embedded malicious code, it has been Trojanized (or, less commonly, Trojaned). This is a defensible position, although it doesn't distinguish between a program written to be malicious and an "innocent" program hijacked by a malicious code. However, the main reason for disregarding this argument is that it compounds the popular confusion between Trojans and viruses.
All malicious programs are popularly described as viruses, irrespective of their replicative properties or the lack thereof. In fact, some programs and coding problems that aren't even malicious are also described as viruses (the so-called Millennium virus, for instance). The situation isn't helped by the fact that hoaxes almost invariably describe mythical "viruses" that would be more properly described as Trojans, if they were capable of existing at all. Even worse, anti-virus vendors, although fully aware of the distinction between replicative and non-replicative malware, continue to display nonsensical alert messages such as "Virus Trojan/W32/xxx detected in file xyz.exe ". For a scanner to alert not only on Trojans but also on other non-viruses such as joke programs, garbage files, and intended viruses (attempted viruses that can't replicate), is misleading and might inspire panic quite inappropriately.
Trojan horses are usually regarded as representing either an attack on privacy (password stealing, for instance, leading to unauthorized access and possibly modification), or on integrity (destructive Trojans). This is a little over-simplified. After all, unauthorized modification is an attack on integrity. A privacy-invasive program often destroys files so as to cover its tracks, and an attacker might want to gain access for specifically destructive purposes. Furthermore, this approach presupposes malicious intent, which, as we've seen, isn't universally accepted as a defining characteristic. Consequently, some types are included here that are often not considered in this context.
The sort of payload you expect a Trojan horse (technically, I suppose it was a Greek horse) to carry might reflect your computing orientation. For many years, mainframe and minicomputer users tended to think in terms of programs that stole passwords or otherwise breached privacy, whereas microcomputer users tended to think in terms of destructive Trojans which formatted disks or trashed file systems. In real life, both destructive and privacy-invasive Trojans have been known at both ends of the Big Iron/PC spectrum for many years. However, recent years have seen more cross-fertilization.
Trojans whose main purpose is destructive have long plagued microcomputer owners. The Dirty Dozen list, first published via FidoNet in the mid-1980s, originally focused on such programs, and at one time the list defined a Trojan in terms of purposeful damage. Of course, the list quickly outgrew the original dozen Trojans and went through a number of changes through the 1980s and 1990s. It might still be possible to find it on some Simtel mirror servers in the DOS/virus directory hierarchy, but it is really only of historical interest. Old Trojans of the type generally listed in DIRTYD*.ZIP are almost invariably short-lived.
Malicious, non-replicating programs have also been widely reported on Macintosh comput ers, including destructive Trojans. Virus Info purported to contain virus information but actually trashed disks. (It should not be confused with the informational [but obsolescent] HyperCard stack Virus Reference.) A PostScript hack that could effectively render certain Apple printers unusable by attacking firmware also excited much interest at one time. NVP modified the Sys tem file so that no vowels could be typed, and was originally found masquerading as New Look, which redesigned the display. More recently, destructive and privacy-invasive, compiled AppleScript Trojans have been noted. For more information, see http://www.sherpasoft.org.uk/MacSupporters/macvir.html.
However, the social impact of such Trojans is often disproportional to their impact in terms of actual incidents. Since they don't self-replicate, unlike viruses and worms, they are less likely to be spread by innocent third parties. They tend to be crudely programmed. Simple batch files using DEL, DELTREE, or FORMAT are still common, sometimes compiled into an .EXE or .COM file using a batch-file compiler such as BAT2COM. This makes them harder to identify. Trojans are usually direct action, that is, as soon as a Trojan is executed, it does all its damage at once This militates against their being spread by previous victims. There are, however, resident Trojans that install themselves so that they are run during every computing session. Often, these are associated with activities such as password stealing. However, any Trojan whose payload is not immediately and overtly malicious maximizes its own chances of being passed on.
The PKZip "Trojan virus" is described in the alt.comp.virus FAQ (which I have my own permission to quote and to correct slightly, since the FAQ is slightly out-of-date in the relevant section). I've included most of the section, since it makes an interesting case history.
The threat described in recent warnings is definitely not a virus, since it doesn't replicate by infection.
There have been at least two attempts to pass off Trojans as an upgrade to PKZip, the widely used file compression utility. A recent example was the files PKZ300.EXE and PKZ300B.ZIP made available for downloading on certain Internet sites.
An earlier Trojan passed itself off as version 2.0. For this reason, PKWare have never released a version 2.0 of PKZip: presumably, if they ever do release another DOS version (unlikely, at this date, in my opinion), it will not be numbered version 3.0(0). [In fact, the latest version is 2.50 at time of writing.]
In fact, there are hardly any known cases of someone downloading and being hit by this Trojan, which few people have seen (though most reputable virus scanners will detect it). As far as I know, this Trojan was only ever seen on warez servers (specializing in pirated software).
There are recorded instances of a fake PKZIP vs. 3 found infected with a real live in-the-wild file virus, but this too is very rare. To the best of my knowledge, the latest version of PKZip is 2.04g [now 2.50], or 2.50 for Windows [now 2.60/2.70].
There was a version 2.06 put together specifically for IBM internal use only (confirmed by PKWare). If you find it in circulation, avoid it. It's either illicit or a potentially damaging fake.
The recent rash of resuscitated warnings about this is at least in part a hoax. It's not a virus, it's a trojan. It doesn't (and couldn't) damage modems, V32 or otherwise, though I suppose a virus or trojan might alter the settings of a modem if it happened to be on and connected .
It appears to delete files, not destroy disks irrevocably.
It's certainly a good idea to avoid files claiming to be PKZip vs. 3, but the real risk hardly justifies the bandwidth this alert has occupied.
Why is it an interesting case history? For one thing, the subject of the attack is a typical target for a destructive Trojan that passes itself off as something it isn't. PKZip is a popular and very useful shareware utility. Recently, it has been rather overshadowed by other utilities using the same compression format, which might explain why PKZip is a less attractive target for Trojanization nowadays. In the following, we allude to a similar utility for the Mac whose identity was also purloined to lure incautious victims into running an imposter program.
Second, it was a counterfeit program that made no effort to assume the appearance or functionality of the program whose identity it claimed. This is characteristic of direct action, destructive Trojans, but not a defining characteristic.
Third and most interestingly, a program that very few people ever saw became a major nuisance because of the number of people who received and passed on a "semi-hoaxified" warning about the Trojan. In fact, the impact of the chain letter was more serious than the Trojan itself was ever likely to be. (This is a not uncommon side effect of direct action Trojans, but it rarely displays such spectacular impact.)
By semi-hoax, we refer to a misleading alert based on a real virus or Trojan, but into which enough misinformation has been introduced to render it too inaccurate to be useful. We should probably distinguish here between a number of possibilities:
An alert based on real malicious software, but too imprecise to be useful. (Many virus alerts passed on by non-experts fall into this category.)
An alert based on real malicious software, but rendered less useful by misinformation based on imperfect understanding of the relevant technology. Even knowledgeable individuals can inadvertently introduce such an inaccuracy into an alert.
An alert based on real, malicious software, but invalidated by the introduction of deliberately misleading material, exaggeration, or complete fabrication of attributes and potential for damage.
Isn't a warning either a hoax or not a hoax? I think not. The intent to hoax (or the lack of it) might be absolute, but the mixture of fact and fiction is commonplace in hoaxes, where fact lends circumstantial support to an essentially fictional assertion.
In late 1997, a bogus version of StuffIt Deluxe was distributed. (StuffIt is a another popular archiving tool used primarily on Macs.) During installation, the program would delete key system files. Aladdin systems, makers of StuffIt, issued widespread advisories about the Trojan at the time.
Malicious Trojans have also been known to masquerade as anti-virus software.
A very well known Trojan that combined sabotage and extortion was the PC CYBORG Trojan horse, or AIDS Trojan. In 1989, some 10,000 copies of an AIDS information diskette were distributed in Europe, Africa, Scandinavia, and Australia, many to medical establishments. After the program was installed and run, a hidden program encrypted the hard disk after a set number of reboots. The idea was that the victim would have to send a "license fee" to PC Cyborg's Panamanian address to get the decryption key. Fortunately, a virus researcher in the UK cracked the encryption.
You can find the CIAC bulletin Information About the PC CYBORG (AIDS) Trojan Horse at http://www.ciac.org/ciac/bulletins/a-10.shtml.
Privacy-invasive Trojans generally perform some function that reveals to the programmer vital and privileged information about a system or otherwise compromises that system. Passwords are, for obvious reasons, a very common target.
They can also (or instead) conceal some function that either reveals to the programmer vital and privileged information about a system or compromises that system.
Some anti-virus companies have differentiated between PC-specific privacy-invasive Trojans and destructive Trojans by restricting the use of the term Trojan to destructive programs. They use the term password stealers for the most common privacy-invasive programs. In the latter half of the 1990s, password-stealing programs aimed specifically at AOL users seemed to become very common (some estimates at the number of such programs rose to many hundreds). Some anti-virus software uses an APS identifier for such programs, probably standing for AOL Password Stealer. However, AOL is not and never was the only vulnerable service. In their paper Where There's Smoke, There's Mirrors, Sarah Gordon and David Chess describe running user simulations on AOL over a seven-month period. While attempts were made to gain their dummy users'screen passwords, these attempts generally used direct social engineering techniques by correspondents masquerading as AOL staff, rather than indirectly with password stealing programs.
Back Door Trojans
Trojans have, from time to time, been planted in legitimate applications. Ken Thompson describes in Reflections on Trusting Trust a number of interesting (not entirely hypothetical) scenarios, the most famous being the Trojanized compiler scenario. In this case, production software offers the means of privileged access to anyone knowing of the back door or trapdoor described.
Back doors and trapdoors offering unauthorized access (and maybe modification) are not the only instances of unauthorized code introduced into legitimate programs, however. Many Mac owners who bought a certain brand of third-party keyboard with a Trojan hardcoded into ROM chip found that the text "Welcome Datacomp" was inserted into their documents at apparently random intervals. PC motherboards with a Trojanized BIOS were characterized by "Happy Birthday" played through the system loudspeaker at boot-up, apparently on the programmer's birthday.
Remote Access Tools (RATs)
Though few anti-virus vendors would claim to detect all known Trojans, most do detect at least some on the platforms for which they have products, especially those Trojans that do direct damage. Remote Access Tools (RATs) such as Netbus and Back Orifice, however, straddle a line between legitimate systems administration (similar to that carried out by programs such as PC Anywhere) and covert unauthorized access. When the system owner is persuaded to run the installation program, a server program is installed that can be accessed from a client program on a remote machine without the knowledge of the user. The server is used to manipulate the victim machine.
Functionally, there might be no difference between a RAT and a "legitimate" tool. The difference lies not in the functionality, but in the facilitation of the covert availability of that functionality to unauthorized individuals. As with sniffers and network scanners, it's not what the program does so much as the reason it's being used. Yet if RAT software is willingly installed, opening the system to an attack the user does not expect, does that make it a Trojan? Using Microsoft Word also makes the user vulnerable to attacks he might not have anticipated. It was, for instance, literally years before some computer users realized that using versions of Word and other Microsoft Office applications supporting macro languages made them vulnerable to macro viruses and Trojans. Does that make Bill Gates a Trojan author? No, because the functionality in this case is too generalized to be described as a back door. However, a RAT broadcasting its presence to a hacker, who probes a characteristic range of port numbers, can certainly be described as a back door Trojan. It promotes the intentions of the author and subverts the expectations of the victim.
This is a serious issue not least in that the "Bad Guys" frequently allude to the shortcomings of legitimate software (especially Microsoft's) as if unforeseen bugs in Office justified their own premeditated activities.
Nonetheless, some RAT authors have exploited this ambivalence by producing "Professional" versions of such software and charging for them. This allows the authors to complain of the anti-capitalist, anti-competitive behavior of security vendors who detect their program as a Trojan (or, all too often and inaccurately, a virus). It works, too. Several anti-virus vendors have dropped detection of the Professional version of Netbus, despite the murkiness of its antecedents and its continuing potential for misuse. Others have gone out of their way to distinguish between standard Netbus Pro installations and Trojanized installations.
A dropper is a program that is not itself a virus, but is intended to install a virus. Curiously, given the popular association of Trojans and viruses, droppers are a comparatively rare entry point for viruses in the wild (see the preceding chapter on viruses). In the PC world, dropper programs are most commonly associated with transporting boot sector viruses across networks, and can be used for that purpose by both pro- and anti-virus researchers. They can be used as a covert means of introducing a virus onto a system, if the victim can be persuaded by social engineering techniques to run the dropper program.
Droppers have been used surprisingly frequently in the Mac world, though. The MacMag virus was introduced via a HyperCard stack called New Apple Products. The Tetracycle game was implicated in the original spread of MBDF. ExtensionConflict is supposed to identify conflicts between extensions (now there's a surprise), but installs the SevenDust virus. Both SevenDust and MBDF are still being reported in the field. Back in the PC world, the Red Team alert muddied the waters by attaching a virus dropper alleged to be a fix for a virus that didn't and couldn't possibly exist.
Joke programs are almost as old as computing. One venerable example is the PDP Cookie program, which popped up and asked the victim for a cookie. PC and Mac users have both long been delighted or irritated by such programs. Confusion has arisen due to the habit of anti-virus software of alerting (using the word virus) not only on viruses and Trojans, but on joke programs such as CokeGift. This widely distributed program offers the victim their CD tray as a holder for their fizzy drink (or possibly white powder for nasal ingestion or carboniferous fossil fuel). Cute for some, irritating for others, but not exactly life-threatening. However, the practice of alerting on joke programs might have arisen in response to supposed joke programs that threaten to format disks, or claim to have done so, but make no such actual attempt. Indeed, there have been instances when, what one vendor has reported as a Trojan, another vendor reported as a joke.
Logic bombs are malicious programs that execute their payload when a preprogrammed condition is met. When the trigger condition is a time or date, the term time bomb may be used. A time-out is a logic bomb sometimes used to enforce contract terms. Characteristically, the program stops running unless some action is taken to indicate (for instance) that the license fee has been paid, or the contractor who wrote the code has been paid. It's not unknown for a contractor to introduce some more drastic time bomb to be triggered if a dispute over payment arises.
The use of the word bomb does suggest a destructive payload, but this need not, in fact, be the case. Mail bombs and subscription bombs, which don't really belong in a chapter on Trojans, are DoS (Denial-of-Service) attacks intended to inconvenience the victim by battering his or her mailbox with a barrage of mail. Often this is done by subscribing the victim to large numbers of mailing lists. Email Trojans certainly exist, although email is more commonly an infection vector for viruses and worms.
The term ANSI bomb usually refers to a mail message or other text file that takes advantage of an enhancement to the MS-DOS ANSI.SYS driver. This allows keys to be redefined with an escape sequence, in this case, to echo some potentially destructive command to the console. Such programs were at one time quite frequently reported on Fidonet. However, nowadays few systems run programs that require ANSI terminal emulation, and ANSI.SYS is not normally installed in Windows 9x or later.
There are alternatives to ANSI.SYS that don't support keyboard redefinition, or allow it to be turned off.
A rootkit is an example of a set of trojanized system programs that an intruder who manages to root-compromise a system might be able to substitute for the commands'standard equivalents. Examples include modified versions of system utilities such as top and ps, allowing illegitimate processes to run unnoticed; daemons modified to compromise log entries or hide connections; utilities gimmicked to enable escalation to root privileges or to hide rootkit component files or other backdoor functionality (secret passwords to allow privileged access, for instance). Associated programs include packet sniffers and utmp/wtmp editors (used to doctor log files).
Rootkits exist for a number of flavors of UNIX, and are appearing in NT versions. However, one-off Trojanized versions of login (that is, versions not included in a suite of programs such as a rootkit) have been used, for instance, to harvest passwords since Pontius programmed in PILOT.
You can find information on rootkits in the FAQ at http://staff.washington.edu/dittrich/misc/faqs/lrk4.faq.
Sarah Gordon's paper Publication of Vulnerabilities and Tool (Proceedings of the Twelfth World Conference on Computer Security, Audit and Control, 1995) includes a technical analysis of some rootkit components.
DDoS (Distributed Denial-of-Service) tools like Stacheldraht, TFN2K, and Trinoo are Trojans designed with a very specific purpose. They are intended to bring down Internet servers by remotely coordinating packet-flooding attacks from multiple machines. Typically, the intruder controls a number of master machines. These, in turn, control daemons on remote machines. Covertly installed, their presence is often concealed by the installation of rootkits. Daemons can be installed on many hundreds of remote machines, all directing flooding attacks at the victim system.
Detailed analysis of DDoS attacks and counter-attacks is beyond the scope of this chapter. However, the installation and presence of a DDoS attack tool can be detected by the same means as other malware. That is, recognition of a specific search string (Known Something Detection), heuristic scanning, and change detection. Virus scanners usually detect known DDoS tools. Network traffic can be monitored for characteristics such as IP packets with spoofed source addresses. Intrusion detection systems can be configured to scan for patterns characteristic of communications between master software and daemon software. A number of papers are available discussing these issues at greater length:
In principle, this should probably be the longest subsection in this chapter. Many system administrators now apply the term Trojan to what the author of Chapter 17, "Viruses and Worms," described as worms. While I regard this usage as misleading, it is defensible, common, and can't be ignored.
It's defensible because, as discussed in Chapter 17, most present-day worms are reliant on social engineering to persuade the recipient to execute the malicious code. In other words, they conform to one of the definitions we've previously examined suggesting that Trojans are programs that purport to do one (desirable) thing while actually doing some other (less desirable) thing.
The usage is misleading because it defies the definition of Trojans as non-replicative malware. In the virus business, most people hold the view that viruses and worms replicate. Some believe that the class worm is a subset of the class virus, and many regard Trojans as non-replicative. These distinctions are not just academic. To fight malicious code effectively, we need to understand how it works, and distinctions are particularly important when we come to examine a multipartite threats such as MTX or LoveLetter. Modern mail-borne malware might include components which can be described as parasitic (a file virus), a worm (a network virus that doesn't infect other files by direct attachment), and/or a classic Trojan.
The theoretical basis of computer virology might be a little shaky as we consider the impact of such recent developments. However, there is plenty of information on such programs on Web sites maintained by anti-virus companies, such as those listed in Chapter 17.