IN THIS CHAPTER
“For they still prefer sheep to thinking men Ah, but men who think like sheep are even better” | ||
| --Brian McNeill, “No Gods and Precious Few Heroes” | ||
“Beware of geeks bearing gifts” | ||
| --Anonymous | ||
This chapter examines a type of threat to system and Internet security that has been with us almost as long as the computer: Trojan horses, often simply referred to as Trojans.
Trojan horses present more difficulties in definition than at first appears. Whereas viruses are defined primarily by their capability 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.
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 for 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” (RFC 2196, a 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, such as steal passwords or copy files without your knowledge.
This definition contains three useful ideas—not that they necessarily give us the best possible summary, but they serve as a good starting point for the 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 inadvertent and essentially 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.
This is the baseline definition used in this chapter. We will consider variations in payload type in terms of subclassifications, rather than by defining the general malware class “Trojan” by a particular function, or by the type of security breach it attempts.
Like many definitions, the one in the previous paragraph misses out on the idea of malicious intent. It therefore raises a number of questions. Should we include Easter eggs (harmless code concealed more or less legitimately in production software by the original production team), for instance? 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 not bad things. 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.
One 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 a July 1998 article for Virus Bulletin (“Talking Trojan,”) suggests using the term nonreplicative malware rather than Trojan horse, thus avoiding the popular confusion between replicating programs (viruses, worms) and static, nonreplicative code (Trojans, for instance). This certainly has advantages, but re-introduces the assumption of malicious intent (by using the word malware). Clearly, although 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 enable 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 sometimes tell us a great deal about function, it can tell us little about the intent of the author.
Dr. Alan Solomon gives 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. It’s not unreasonable to expect that a computer user who consciously runs a program called FORMAT to know what to expect from a program of that name. However, if a legitimate disk formatting program is renamed to something that disguises its real function, or includes documentation that indicates that it is intended to display graphics, or optimize video performance, there is a clear intent to deceive and harm.
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 capability 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, for an automatic analytical tool to deduce either the intentions of the programmer or the expectations of the program user by tracing what the code does, if the program is named inappropriately and deceptively, or whether its true functionality jibes with the description in the accompanying documentation.
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. Nevertheless, email worms do conform to the working definition with which we closed the preceding section, differing from classic Trojans of other types only in that they include replicative functionality. Indeed, it has recently become more common in security circles (less so in the antivirus community) to refer to worms that use social engineering techniques to trick the victim into running them as Trojans, irrespective of their capability to replicate.
By extension, if we accept this view, we can also accept self-launching worms as Trojans, because they still use an element of deceit to persuade a potential victim that they are legitimate messages from trusted sources. This usage reflects a basic distinction between older parasitic virus types and the recent generation of email viruses and worms.
Despite the distinctions maintained by the antivirus community, it is still the case that 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 are more properly described as Trojans, or sometimes as worms, if they’re capable of existing at all. We should however note a degree of convergence between the descriptions of mythical viruses found in hoax alerts and the functionality of real email viruses and worms. I refer here particularly to the use of virus names in hoax alerts that correspond to real viruses, but ornamented by ascribing to real viruses a set of imaginary supernatural characteristics.
Even worse, some antivirus vendors, although fully aware of the distinction between replicative and nonreplicative 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) as if they were viruses, is misleading and might inspire panic quite inappropriately.
However, there is a point in alerting on intended viruses. Because such objects are often encountered in poorly maintained collections used for badly designed product tests, a product that only detects “real” malware, however technically and ethically correct, is in danger of being put at a competitive disadvantage, because a less “correct” product will fare better in such tests, by scoring a higher percentage of detected objects. The problem here is that to alert on such objects using messages that suggest that they are real viruses is poor practice, inaccurate, and confusing.
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 may be an attack on privacy (unauthorized access) as well as 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 that 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 as well as an expansion of the terminology to include some nonreplicative objects. Arguably, this has come about as the borders between server-class and desktop-class functionality has blurred, with the result that rootkits and denial-of-service attacks have become a threat to desktop users, while server administrators have had to take into account programs that endanger server and clients alike.
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. Curiously, one vendor has revived the “Dirty Dozen” idea, but applied it to a list of the most reported current threats of all types for the current month. These will generally be viruses or worms, in the current climate, though it must be noted that Trojans (not necessarily destructive) have become much more of a concern to the antivirus community in recent years.
Malicious, nonreplicating programs have also been widely reported on Macintosh computers, 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 can effectively render certain Apple printers unusable by attacking firmware also excited much interest at one time. NVP modified the System file so that no vowels can 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, as well as at least one worm. For more information on Macintosh malware, see http://www.sherpasoft.org.uk/MacSupporters/macvir.html.
With the increasing popularity of Linux as a PC computing platform, an increasing number of Trojans has been reported, although worms are more common at present. Some PDA platforms have also been associated with destructive and/or data-stealing Trojans, prompting some speculation about cellphone-targeted malware.
Regardless of platform, the social effect of such Trojans is often disproportional to their effect in terms of actual incidents. Because 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 traditionally usually direct action; that is, as soon as a Trojan is executed, it does all its damage at once. This works against their being spread by previous victims. However, tradition has never been a good basis for complacency. This particular tradition has as much to do with the laziness and coding incompetence of the average script kiddie. There is no absolute reason a destructive Trojan should not be well-coded, persuasively presented, and include a multiple or deferred payload designed to give the victim more time to pass it on to other victims. Furthermore, resident Trojans exist that install themselves, so they’re run during every computing session. Often, these are associated with activities such as password stealing or other unwanted effects, such as opening multiple windows or pornographic Web pages. 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 somewhat out-dated alt.comp.virus FAQ. Much of the FAQ text referring to this incident is included, because it makes an interesting case history:
The threat described in warnings widely seen in the mid-90s was definitely not a virus, because it did not replicate by infection.
A number of attempts were made at various times to pass off Trojans as an upgrade to PKZip, the widely used file compression utility. A recent example was the files
PKZ300.EXEandPKZ300B.ZIPmade available for downloading on certain Internet sites.An earlier Trojan passed itself off as version 2.0. For this reason, PKWare never released a version 2.0 of PKZip. In fact, there were hardly any known cases of someone downloading and being hit by this Trojan, which few people ever saw (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. 3found infected with a real live in-the-wild file virus, but this too is very rare. The subsequent rash of resuscitated warnings about this was, at least in part, a hoax, and was certainly misinformative if not misinformed. It was not a virus, but a Trojan. It did not (and cannot) damage modems, V32 or otherwise, though a virus or Trojan might alter the settings of a modem—if it happened to be on and connected, or exploit other network- or broadband-specific vulnerabilities…It deleted files, it did not destroy disks irrevocably. This is not altogether impossible in all circumstances, but such exploits are virtually unknown.
It’s certainly a good idea to avoid files claiming to be unverified updates, system patches and such like
PKZip vs. 3, but the real risk hardly justified the bandwidth this alert 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 was 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 pages, we allude to a similar utility for the Mac whose identity was also purloined to lure careless 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, though not a defining characteristic. Disguising a Trojan as the program it claims to be is more characteristic of privacy-invasive programs, such as some password-stealers that are passed off as login programs. However, programs that look as if they are acting in accordance with their assumed function while carrying out some covert and destructive act have been reported.
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 effect of the chain letter was more serious than the Trojan itself was ever likely to be. (This is a common side effect of direct action Trojans, but it rarely displays such spectacular effect.)
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 an imperfect understanding of the relevant technology. Even knowledgeable individuals can inadvertently introduce such an inaccuracy into an alert. Using the line of thought previously explored in relation to “accidental Trojans,” we might refer to this as an accidental hoax, although the terminology is not in wide use.
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. A particularly gross recent manifestation concerns hoaxes that describe legitimate Windows files such as SULFNBK.EXE and JDBGMGR.EXE as being malicious programs.
When a victim finds that she does indeed have a file of that name on her system, she is set to follow the advice and instructions on removal that accompanies some versions of these hoaxes. In such a case, we see what might be described as a memetic Trojan (see the section on memetic viruses in the preceding chapter): Whereas a real Trojan uses social engineering to persuade the victim to run malicious code, a hoax like this uses social engineering to persuade the victim to perform the destructive or otherwise undesirable act themselves.
As another example, 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 antivirus software, in a manner analogous to the distribution of viruses by attaching them to legitimate antivirus or other software. A further refinement is to use the alleged antivirus program as a dropper—that is, a program that installs a virus, but is not a virus itself. Virus droppers are not always Trojans (they are not always intended to operate covertly), but a dropper that masquerades as a beneficial program yet actually installs a virus can certainly be described as a Trojan. Droppers are described in more detail later in this chapter.
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 floppy disk 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 very quickly.
TIP
You can find the CIAC bulletin “Information About the PC CYBORG (AIDS) Trojan Horse” at http://www.ciac.org/ciac/bulletins/a-10.shtml. This incident is also described in some detail in Viruses Revealed, by Harley, Slade, and Gattiker (Osborne McGraw-Hill).
Because it has become so common to distribute BIOS updates as software for flash BIOS systems, there have been attempts to take advantage of the potential for damage inherent in some such systems. Viruses and Trojans that attempt to trash a system by writing garbage to the flash BIOS have caused substantial damage from time to time (CIH/Spacefiller/Chernobyl is a well-known viral example, but Trojans such as Flashkiller have also used this vulnerability—indeed, Flashkiller seems to be just the destructive subroutines from CIH recompiled without the replicative code).
Interestingly, such payloads have come close to fulfilling the hoax writer’s dream of a malicious program that causes irrevocable damage to hardware. Some flash BIOS systems cannot be recovered when the BIOS has been trashed except by chip replacement. Fortunately, some systems include stub programming to proceed far enough into the boot process to enable a reflash.
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 antivirus 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 antivirus 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. Although 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.
In recent years, viruses and Trojans have frequently appeared that attempt to steal other privileged information relating to a wide variety of applications and data formats. They have also been associated with the more-or-less random dissemination of possibly sensitive data to persons other than the author of the malicious software, including other intended victims.
Another recent development is the rise of convergent or blended threats, such as multipolar worms and viruses using a number of attack vectors, Trojan/social engineering techniques as a means of deceiving the victim into running malicious code, and installing back-door or privacy-invasive Trojans as part of the infective process.
This diffuse class of malware includes a variety of subtypes and specific programs, but is often associated with programs like BackOrifice and NetBus that use particular network ports and a variety of subversive network-related activities, such as remote access and file modification, Registry and SAM modification, keylogging (password capture), display of local cached data, creation of network shares to allow unauthorized access, exploitation of victim systems to launch attacks on systems at one stage removed (WinTrinoo), ICQ and IRC exploits, (SubSeven) and so on. Some of these types of Trojan are examined in more detail below.
Trojans have, from time to time, been planted in legitimate applications. Ken Thompson describes in his paper “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 who knows 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 a 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. The term back door Trojan is also used increasingly to refer to a class of Trojan we have preferred to refer to as Remote Access Tools, and to software associated with the installation of commercial software that reports back to the vendor, or uses the host machine as a platform for further advertising. This type of activity is more often referred to as spyware or adware.
Though few antivirus vendors will 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 BackOrifice, 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 she 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. Arguably, any software with a significant degree of functionality also carries the risk of subversion by malicious software. 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. Trojans that use specific ports are, along with a number of other examples of malware, listed at http://www.simovits.com/trojans. A number of sites also list the legitimate assignment of port numbers to given protocols and products: For instance, http://www.iana.org/assignments/port-numbers/ includes both the Well Known Ports (assigned by the IANA, usually to system processes) between 0 and 1023, and the Registered Ports between 1024 and 49151 inclusive. 49152 through 65535 are known as Dynamic or Private Ports, and are not registered for particular uses.
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 enables 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. Some antivirus vendors for a time 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. Clearly, the dividing line between a RAT and a back door Trojan can be somewhat hazy, because they may use very similar technology and functionality.
A dropper is a program that is not itself a virus, but is intended to install a virus. Technically, a program that installs other nonviral programs, might also be referred to as a dropper. 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 antivirus 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. Somewhat ironically, we have seen a number of instances in recent years where an email virus has installed a password-stealing or backdoor Trojan as part of its payload: W95/Matrix, for instance.
Droppers have been used with surprising frequency 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 because of the habit of antivirus software of alerting (using the word virus) not only on viruses and Trojans, but on joke programs such as CokeGift. This widely distributed program offered 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. One real-life example concerned a program that changed the victim’s desktop wallpaper to a pornographic photograph. (So who wallpapers their desktop in real life?) Such a payload might well be considered humorous by the Trojan author, and no more harm intended than is associated with other practical jokes. However, run on a system in an environment with a draconian policy towards trafficking in pornographic data, this payload might result in the victim’s dismissal, a result that might well be regarded as being as catastrophic to that individual as the loss of data through deliberate destruction (though the corporate view of this comparison might be a little different).
There might be an argument for regarding this scenario, though, as an example of an accidental Trojan, an undesirable result unintended by the program’s author. However, too much focus on accidental Trojans might also open up the possibility of the accidental non-Trojan, a program that fails to achieve a malicious intention. In the same way, perhaps, an “intended” (a virus whose replicative function never works) is of some interest to researchers, but not necessarily to the intended victim.
In recent years, a number of Trojans have carried payloads best described as annoying, rather than data-threatening: opening multiple windows, opening dialog boxes that move away from the mouse cursor when the victim attempts to close them, or redirecting Web browsers to undesirable Web pages. Some versions of HTML/script Trojans such as JS/NoClose have made much use of such irritating side effects. Again, more significant damage may be incurred when attempts to remove such programs go wrong, as may easily happen with software that hooks itself deep into the operating system using modifications to the Windows Registry, for example. Does this also qualify as an “accidental Trojan”? Probably not. After all, programs on this particular borderline between Trojan horses and jokes are still employing the deception characteristic of some definitions of Trojan. Furthermore, I’d argue that a program that is intended to irritate a victim or make him feel foolish is as malicious in intent as a destructive Trojan. Only the type and extent of damage varies. Furthermore, such a joke cannot be described as harmless if the victim is driven to take unnecessarily stringent and time-intensive measures because of uncertainty about what other changes might have been introduced to the system.
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 denial-of-service (DoS) attacks intended to inconvenience the victim by battering 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. Security vendors such as MessageLabs, which monitor email for known and unknown malware, are increasingly reporting the use of email to disseminate Trojans.
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 enables 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 enable 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, enabling illegitimate processes to run unnoticed, daemons to be modified to compromise log entries or hide connections, and utilities to be gimmicked to allow escalation to root privileges or to hide rootkit component files or other backdoor functionality (secret passwords to enable 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 NT-based systems. 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.
TIP
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.
Distributed denial-of-service (DDoS) tools such as 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:
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
http://staff.washington.edu/dittrich/misc/trinoo.analysis
In principle, this should probably be the longest subsection in this chapter; however, this area has already been covered in the preceding chapter. Many system administrators now apply the term Trojan to what are often described as worms. Although 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 nonreplicative malware. In the virus business, most people hold the view that viruses and worms replicate. Some believe that the worm class is a subset of the virus class, and many regard Trojans as nonreplicative. 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 multipartite/multipolar threats such as MTX or LoveLetter. Modern mailborne malware might include components that 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 effect of such recent developments. However, there is plenty of information on such programs on Web sites maintained by antivirus companies, such as those listed in Chapter 17.
Usenet is a common source of Trojans and viruses, especially newsgroups that carry binaries of any sort, and more particularly, groups that traffic in warez (illicit software) or pornographic material. Trojans are also distributed through email and instant messaging services, as well as from Internet file repositories, and their distribution is increasingly associated with email viruses and worms.
The AOLGOLD Trojan horse was distributed via Usenet and through email. The program was claimed to be an enhancement package for accessing America Online. The distribution consisted of an archived file that, when unzipped, revealed two files, INSTALL.EXE and README.TXT. Executing INSTALL.EXE resulted in expanding 18 files to the hard disk. One of the new files, called INSTALL.BAT, attempted to delete several directories on drive C, as well as running a program called DOOMDAY.EXE that failed to execute because of a bug in the batch file. Destructive Trojans of this type have not captured the same attention recently, or caused as much damage. However, it would be naïve to assume that they no longer pose a threat. Furthermore, while Trojans such as FlashKiller, KillCMOS, and Winnuke V probably inspire more panic than their actual incidence might suggest, backdoor Trojans such as the wu-ftpd Trojan can be the means of entry for individuals set on causing equal or more damage.
TIP
You can find the security advisory titled “Information on the AOLGOLD Trojan Program” at http://www.emergency.com/aolgold.htm or http://ciac.llnl.gov/ciac/bulletins/g-03.shtml.
Trojans frequently masquerade as games, joke programs, screensavers, and other programs frequently exchanged by email, especially when strict system policies or security policies are not enforced. If software contains a privacy-invasive Trojan or a destructive Trojan with a delayed payload (a time bomb or other form of logic bomb, for example), the Trojan might be distributed by a victim who is not yet aware that the program is malicious.
AOL users are frequently targeted by privacy-invasive Trojans, as we’ve already seen, but also by destructive Trojans.
In April 1997, someone developed a Trojan called AOL4FREE.COM (not be to be confused with the AOL4FREE virus hoax that surfaced that same year—of course such confusion was part of the point of the hoax). The Trojan claimed to be a tool to gain unauthorized access to AOL and destroyed hard disk drives on affected machines. To learn more about it, check out the CIAC advisory at http://ciac.llnl.gov/ciac/bulletins/h-47a.shtml, though this advisory is inaccurate in at least one respect—many antivirus programs routinely detect Trojan horses.
In fact, attacks on AOL users are symptomatic of a mindset regularly encountered among computer vandals of all types. Like Usenet newbies and unwary IRC users, they are seen as a group of “lamers” lacking low-level knowledge of the systems they use. This is seen in itself as some twisted justification, not only for jokes and hoaxes, but for intentionally destructive programs.
Direct intrusion enables installation of rootkit components and other Trojanized files, especially if the intruder is able to gain root/administrator privileges.
Trojans, especially password-stealers, are frequently discovered in communities such as AOL. AOL presents an Internet service for computer users who don’t want or need to be computer geeks. Many newcomers to the Internet have no interest in the finer points of networking protocols and the mysteries of Gopher, Telnet, and Archie, and AOL emphasizes user-friendliness rather than 1970s geek cliques. Trojans in AOL usually target the least computer-literate members (new users, children) of those communities, already seen by technosnobs to be among the least computer-literate groups. This is significant because there are Black Hats (bad guys), who regard the technical ignorance of everyday users as justification of vandalism. They reason that if lame AOLers can’t learn to protect their systems, they deserve everything they get.
In the corporate arena, Trojans are a major security concern on multiuser systems, which can, of course, include many desktop machines. They can be insidious, too, because even after they’re discovered, their footprints may remain in dark corners of the directory system or Windows Registry, and it is often recommended that compromised systems be rebuilt completely in case undocumented or unconsidered residual compromises remain undiscovered. Trojans are often hidden within compiled binaries. The Trojan code is therefore not in human-readable form or machine language. Without using a debugging utility, you can learn little about binary files. Using a text editor or a utility such as strings to view a binary file or extract readable text from it, for example, is often unhelpful. Often, the only recognizable text strings will be copyright messages, error messages, or other data that prints to STDOUT at various points in the program’s execution—stub loader messages, for example. In a graphical environment, recognizable strings will be even less frequent or useful. However, reverse-assembling serious quantities of potentially damaging code is not a task for the fainthearted or under-resourced. As we’ve already noted, such code is not always susceptible to automated analysis.
NOTE
Compiled binaries are not the only places you’ll find Trojans. Batch files and other shell scripts, Perl programs, and perhaps even code written in JavaScript, VBScript, or Tcl can carry a Trojan. Scripting languages have been described as unsuitable for the creation of Trojans if the code remains humanly readable. This increases the victim’s chances of discovering the offending code. In real life, though, victims often seem quite happy to run unchecked code, even when it’s humanly readable. The LoveLetter virus was executed by countless recipients, even though the cleartext code clearly included a subroutine whose very name indicated that it was intended to infect files.
Nesting a Trojan within such code is, however, more feasible if the file is part of a much larger package—for example, if the entire package extracts to many subdirectories. In such cases, the complexity of the package can reduce the likelihood that a human being, using normal methods of investigation, will uncover the Trojan, especially if it’s an easily overlooked short sequence, such as DELTREE C: or rm -rf.
Trojans don’t usually announce their intent. Worse still, many Trojans masquerade as legitimate, known utilities that you’d expect to find running on the system. Thus, you cannot rely on detecting a Trojan by listing current processes.
In detecting a Trojan by eye, much depends on the user’s experience. Users who know little about their operating systems are less likely to venture deep into directory structures looking for suspicious files. More proficient users are unlikely to have time to examine the complex system structures of modern operating systems, especially on server-class machines. Even experienced programmers can have difficulty identifying a Trojan, even if the code is available for their examination. Identification of malicious code by reverse-engineering can be more difficult and time-consuming by several orders of magnitude.
Trojans can represent a moderate-to-serious level of risk, mainly for reasons already discussed:
New Trojans are difficult to detect using heuristic detection. (Unless you use the somewhat sweeping heuristic that a change in a file detected automatically is likely to indicate a Trojan substituted for a legitimate file.) There is no absolute test for code to determine whether it is (or is not) a Trojan because author intent and user expectations are not generally susceptible to automated analysis.
In most cases, Trojans are found in binaries, which remain largely in non-human–readable form. However, the fact that the code is largely static does make Trojans at least as susceptible to “known-something” detection as viruses. In other words, when a known malicious program is identified, it can be detected by software updated with an appropriate search string. Remember that, by most definitions, replication is not a characteristic of the Trojan breed. Trojans spread through the action of being copied by an attacker or a victim socially engineered into carrying out the attacker’s wants, not by self-copying. Thus it is not usually feasible for an attacker to use techniques such as polymorphism to reduce the chance of detection. Because the copying of the program is not a function of the program itself, the program has no means of evolving into a non-identical copy (a morph) of itself.
Nevertheless, undetected privacy-invasive Trojans can lead to total system compromise. A Trojan can be in place for weeks or even months before it’s discovered. In that time, a cracker with root privileges can alter the entire system to suit his needs. Even when the Trojan is discovered, many hidden loopholes might be left behind when it is removed. It is for this reason that the complete rebuilding of compromised desktop and server software is sometimes recommended after the discovery and removal of Trojans, rootkits, DDoS agents, and so forth. Antivirus vendors tend to be over-relaxed in this respect, probably because historically they are used to dealing with a fairly small subset of the Trojan class.
Detecting Trojans is easy, if you have a static search pattern to scan for. Antivirus software routinely detects some Trojans using much the same pattern-searching techniques used for detecting viruses. In fact, known Trojans are often easier to detect than viruses, because they aren’t usually embedded into other programs, or even polymorphic, though variations may be introduced, deliberately or otherwise, over time. However, identification of a known Trojan isn’t always the best defense. Detection of previously unknown Trojans is also conceptually simple, provided you have always maintained the best security practices (literally always, at least as far as the protected system is concerned).
Most detection methods on traditional multiuser systems derive from a principle sometimes called object reconciliation. Object reconciliation is a fancy way of asking, “Are things still just the way I left them?” Here’s how it works: Objects are system areas, such as files or directories. Reconciliation is the process of comparing those objects against a snapshot record of the same objects taken at some previous date when the protected object was known to be in a trustworthy, “clean” state.
NOTE
Strictly speaking, there is no such “clean state” time. Even a “day zero” installation of system software onto a virgin system assumes a program suite with no substitutions and back doors. Can you place unlimited trust in a system you didn’t build totally from scratch yourself? “No amount of source-level verification or scrutiny will protect you from using untrusted code,” says Ken Thompson. Does this mean we should give up on this approach? Of course not, but we should bear in mind that, even if we build an application from scrutinized source code, we might not be able to trust the compiler, or every snippet of hardware microcode on the system motherboard.
More commonly, the process described as object reconciliation is known as change detection, integrity checking, or integrity management. However, these terms are not strictly synonymous.
Change detection simply describes any technique that alerts the user to the fact that an object has been changed in some respect. Integrity checking has the same core meaning, but is often taken to imply a more sophisticated approach, not only to detecting change in spite of attempts to conceal it, but to ensuring that the reporting software itself is not subverted.
Integrity management is a more general term. It can include not only the detection of unauthorized changes, but other methods of maintaining system integrity. Such methods can include some or all the following, in no particular order:
Maintaining trusted backups
Blocking unknown intrusions at or after entry (for instance, by running system files from read-only media or refreshing system files from trusted read-only media)
Maintenance of strict access control
Careful application of manufacturer patches to block newly discovered loopholes
A finely engineered change-management system, using only signed (trusted) code
A simple method of testing file integrity is based on reports of changes in file state information. Different file integrity tests vary in sophistication. For example, you can crudely test a file’s integrity using any of the following indexes:
Date last modified
File creation date
File size
Unfortunately, none of these three methods constitute a really adequate defense against more than the crudest attack. Each time a file is altered, its values change. For example, 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 file timestamp. How difficult is it? Change the system time, apply the desired edits, archive the file, and reset the system time. Better still, get and save the date/time information using standard C library functions (for instance), modify or replace the object, and restore the file modification date. On a single-user system (such as MS-DOS) with minimal or no access controls, the coding involved is trivial. For this reason, checking time of modification is an unreliable way to detect change. Also, the last date of modification reveals nothing if the file was unaltered (for example, if it was only copied, viewed, or mailed). On the other hand, if there is a disparity between the modification date returned by the system and the date of modification recorded by a system monitoring utility, there is a distinct possibility of malicious action.
Another way to check the integrity of a file is by examining its size. However, this value can be very easily manipulated, either by trimming or padding the file itself, or by altering the value reported by the operating system.
There are other indexes: For example, basic checksums can be used. However, although checksums are more reliable than time and date stamping, they can be altered, too. If you rely on a basic checksum system (or use change detection software, which relies on simple checksumming), it is particularly important that you keep your checksum list in a trusted environment. This might mean on a separate server or even a separate medium, accessible only by root or other trusted users. Checksums work efficiently and appropriately for checking the integrity of a file transferred, for example, from point A to point B, but are not suitable for high security applications. They simply aren’t designed to guard against a malicious attempt to subvert them to return false information.
NOTE
If you’ve ever performed file transfers using communication packages such as Qmodem, you might remember that these programs perform cyclical redundancy checksum (CRC) verification as the transfers occur. This reduces the likelihood that the file will be damaged in transit. When dealing with sophisticated attacks against file integrity, however, this technique is insufficient. Tutorials about defeating checksum systems are scattered across the Internet. Most are related to the development of viruses. (Some older virus-checking utilities used checksum analysis to detect possible infection by new viruses; that is, viruses not yet known to the compilers of virus-specific scanner databases.) You can get an overview of CRC32 (and other algorithms) from RFC 1510 at ftp://ftp.isi.edu/in-notes/rfc1510.txt.
A less easily subverted technique involves calculating a more sophisticated digital fingerprint for each file using various algorithms. A family of algorithms called the MD series can be used for this purpose. One of the most popular implementations is a system called MD5.
MD5 belongs to a family of one-way hash functions called message digest algorithms. The MD5 system is defined in RFC 1321 as follows:
The algorithm takes as input a message of arbitrary length and produces as output a 128-bit “fingerprint” or “message digest” of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be “compressed” in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.
TIP
RFC 1321 is located at ftp://ftp.isi.edu/in-notes/rfc1321.txt.
When you run a file through MD5, the fingerprint emerges as a 32-character value. It looks like this:
2d50b2bffb537cc4e637dd1f07a187f4
Many sites that distribute Unix software use MD5 to generate digital fingerprints for their distributions. As you browse their directories, you can examine the original digital fingerprint of each file. A typical directory listing might look like this:
MD5 (wn-1.17.8.tar.gz) = 2f52aadd1defeda5bad91da8efc0f9800 MD5 (wn-1.17.7.tar.gz) = b92916d83f377b143360f068df6d8116 MD5 (wn-1.17.6.tar.gz) = 18d02b9f24a49dee239a78ecfaf9c6fa MD5 (wn-1.17.5.tar.gz) = 0cf8f8d0145bb7678abcc518f0cb39e9 MD5 (wn-1.17.4.tar.gz) = 4afe7c522ebe0377269da0c7f26ef6b8 MD5 (wn-1.17.3.tar.gz) = aaf3c2b1c4eaa3ebb37e8227e3327856 MD5 (wn-1.17.2.tar.gz) = 9b29eaa366d4f4dc6de6489e1e844fb9 MD5 (wn-1.17.1.tar.gz) = 91759da54792f1cab743a034542107d0 MD5 (wn-1.17.0.tar.gz) = 32f6eb7f69b4bdc64a163bf744923b41
If you download a file from such a server and find that the digital fingerprint of the downloaded file is different, there is a good chance that something is amiss.
With or without MD5, integrity management is a complex process. Various utilities have been designed to assist with integrity management on complex and distributed systems. The following utilities were originally Unix-based, but similar programs are available for Microsoft operating systems.
Tripwire (originally written in 1992) is a comprehensive file integrity tool. Tripwire is well-designed, easily understood, and easily implemented.
The original values (digital fingerprints) for files to be monitored are kept within a database file in simple ASCII format that is accessed whenever a signature needs to be calculated or verified.
Ideally, a tool such as Tripwire would be used immediately after a fresh (day zero) installation. This gives you 100% assurance of file system integrity as a starting point (or nearly 100%—remember the Ken Thompson article). After you generate the complete database for your file system, you can introduce other users (who will immediately fill your system with junk that, optionally, might also be fingerprinted and verified on subsequent checks). Here are some of its more useful features:
Tripwire can perform its task over network connections. Therefore, it’s possible to generate a database of digital fingerprints for some entire networks at installation time.
Tripwire was written in C with a mind toward portability. It will compile for many platforms without alteration.
Tripwire comes with a macro-processing language, so your tasks can be automated.
Tripwire is a popular (especially in its commercial incarnation) and effective tool, but there are some security issues common to most or all integrity management tools. One such issue relates to the database of values that is generated and maintained. From the beginning, Tripwire’s authors were well aware of this:
The database used by the integrity checker should be protected from unauthorized modifications; an intruder who can change the database can subvert the entire integrity checking scheme.
TIP
Tripwire is discussed at length by its original authors in “The Design and Implementation of Tripwire: A File System Integrity Checker” by Gene H. Kim and Eugene H. Spafford. It is located at ftp://coast.cs.purdue.edu/pub/papers/gene-spafford/Tripwire.pdf.
One method of protecting the database is to store it on read-only media. This eliminates any likelihood of tampering. Kim and Spafford suggested that the database be protected in this manner, although they pointed out that this can present some practical, procedural problems. Much depends upon how often the database will be updated, and its size. Certainly, if you are implementing Tripwire or a similar utility on a wide scale (and using its most stringent settings), the maintenance of a read-only database can be formidable. As usual, this breaks down to a trade-off between the level of risk and the inconvenience of setting and maintaining paranoid defaults.
You can find Tripwire and some documentation at ftp://coast.cs.purdue.edu/pub/tools/unix/ids/tripwire/. However, Tripwire is no longer a supported research project at Purdue University. In its commercial incarnation, more information (and a downloadable evaluation version of the product for Windows XP Pro, 2000, and NT 4.0) is available from http://www.tripwiresecurity.com/.
The TAMU Tiger suite (from Texas A&M University) is a collection of tools that greatly enhance the security of a Unix box. These tools were created in-house, in response to an extensive attack from a coordinated group of Internet crackers. The package has since been upgraded and renamed TARA (Tiger Analytical Research Assistant). It incorporates a number of scripts used to scan Unix systems for problems. More information is available from http://www.securityfocus.com/tools/481. TARA-PRO is available at http://www-arc.com/tara/index.shtml.
File integrity checkers exist for Windows—in fact Tripwire has been developed for Windows NT-based operating systems as well as for Unix. Integrity checkers are not necessarily expressly designed to check multiple machines and file systems over networks. Some older DOS and Windows tools use simple CRC checksumming as an index and therefore might be easier to subvert than tools that employ MD5 and related or equivalent algorithms. The majority are intended for use as a supplement to virus scanners (because detectable changes to an infectable object might indicate virus infection). This doesn’t invalidate the potential usefulness of integrity checkers as a means of detecting possible substitutions of compromised code for system files.
However, change detection is less convenient on Windows platforms in that system files accessed by multiple applications can be replaced by legitimate installations and upgrades. There is often a sharper delineation on other platforms between files belonging to the system and files that belong to an application.
Furthermore, change detection only works well with certain types of binary executables, even in the context of virus detection. Many viruses and Trojans infect files whose main purpose is to contain data (spreadsheets, word-processing files, and so on). However, such files are usually intended to be modified as necessary, as are the log files used on many multiuser systems to track possible malicious action. Clearly, change detection based on the presumption that files remain static isn’t going to work in these instances. In some instances, it’s possible to specify changes that might signify a breach (the addition of macro code to a Word file, for instance). This approach requires that the inspecting software “know” more about the internals of the file, rather than just its digital fingerprint. That would entail serious administrative difficulties, so the approach is not well-favored at present.
Certain kinds of modifications to the Windows registry are particularly associated with viruses, worms, or Trojans, particularly those that set up the system configuration so that a (in this case malicious) program is executed each time the system is run. Unfortunately, Registry keys that are associated with such problems can also be used for legitimate purposes, so unless it is intended to lock down the registry and other configuration files, so that no modification at all is possible, it’s difficult to evaluate and deal with modifications to such areas of the Registry. Attempts to prevent any modification to the system using this approach might have an adverse impact on the system.
The safest defense, though, is to block unauthorized modification of system files proactively by code signing, read-only media, and other preemptive measures. Sadly, safe and convenient are not always the same thing.
Trojans are a significant security risk to any network, server, or workstation. Although Windows and Unix-hosted antivirus software usually detects known Trojans, though not necessarily for all platforms, there are strong arguments for using integrity management tools, especially on server-class machines, to reduce the possibility of system compromise from Trojans masquerading as system utilities. This approach is viable on workstations, too, although it may be harder to implement effectively. A combination of targeted integrity management, efficiently backing up data but restoring systems from a standard day zero image rather than from backup tapes, and sound user management controlling the installation and execution of unauthorized software, is more effective than any single strategy in any server or workstation environment.