Where Do Trojans Come From?
Trojans are created strictly by programmers. One does not get a trojan through any means other than by accepting a trojaned file that was prepared by a programmer. True, it might be possible for a thousand monkeys typing 24 hours a day to ultimately create a trojan, but the statistical probability of this is negligible. Thus, a trojan begins with human intent or mens rea. Somewhere on this planet, a programmer is creating a trojan right now. That programmer knows exactly what he or she is doing, and his or her intentions are malefic (or at least, not altruistic).
The trojan author has an agenda. That agenda could be almost anything, but in the context of Internet security, a trojan will do one of two things:
- Perform some function that either reveals to the programmer vital and privileged information about a system or compromises that system.
- Conceal some function that either reveals to the programmer vital and privileged information about a system or compromises that system.
Some trojans do both. Additionally, there is another class of trojan that causes damage to the target (for example, one that encrypts or reformats your hard disk drive). So trojans may perform various intelligence tasks (penetrative or collective) or tasks that amount to sabotage.
One example that satisfies the sabotage-tool criteria is the PC CYBORG trojan horse. As explained in a December 19, 1989 CIAC bulletin ("Information about the PC CYBORG (AIDS) Trojan Horse"):
There recently has been considerable attention in the news media about a new trojan horse which advertises that it provides information on the AIDS virus to users of IBM PC computers and PC clones. Once it enters a system, the trojan horse replaces AUTOEXEC.BAT, and may count the number of times the infected system has booted until a criterion number (90) is reached. At this point PC CYBORG hides directories, and scrambles (encrypts) the names of all files on drive C:. There exists more than one version of this trojan horse, and at least one version does not wait to damage drive C:, but will hide directories and scramble file names on the first boot after the trojan horse is installed.
Cross Reference: You can find the CIAC bulletin "Information about the PC CYBORG (AIDS) Trojan Horse" at http://www.sevenlocks.com/CIACA-10.htm.
Another example (one that caused fairly widespread havoc) is the AOLGOLD trojan horse. This was distributed primarily over the Usenet network and through e-mail. The program was purported to be an enhanced package for accessing America Online (AOL). The distribution consisted of a single, archived file. Unzipping the archive revealed two files, one of which was a standard INSTALL.BAT file. Executing the INSTALL.BAT file resulted in 18 files being expanded to the hard disk. As reported in a security advisory ("Information on the AOLGOLD Trojan Program") dated Sunday, February 16, 1997:
The trojan program is started by running the INSTALL.BAT file. The INSTALL.BAT file is a simple batch file that renames the VIDEO.DRV file to VIRUS.BAT and then runs it. VIDEO.DRV is an amateurish DOS batch file that starts deleting the contents of several critical directories on your C: drive, including
c:\
c:\dos
c:\windows
c:\windows\system
c:\qemm
c:\stacker
c:\norton
When the batch file completes, it prints a crude message on the screen and attempts to run a program named DOOMDAY.EXE. Bugs in the batch file prevent the DOOMDAY.EXE program from running. Other bugs in the file cause it to delete itself if it is run from any drive but the C: drive. The programming style and bugs in the batch file indicates that the trojan writer appears to have little programming experience.
Cross Reference: You can find the security advisory titled "Information on the AOLGOLD Trojan Program" at http://www.emergency.com/aolgold.htm.
These trojans were clearly the work of amateur programmers: kids who had no more complex an agenda than causing trouble. These were both destructive trojans and performed no sophisticated collective or penetrative functions. Such trojans are often seen, and usually surface, on the Usenet news network.
However, trojans (at least in the UNIX world) have been planted by individuals that are also involved in the legitimate development of a system. These are inside jobs, where someone at a development firm inserts the unauthorized code into an application or utility (or, in rare instances, the core of the operating system itself). These can be far more dangerous for a number of reasons:
- These trojans are not destructive (they collect intelligence on systems); their discovery is usually delayed until they are revealed by accident.
- Because most servers that matter run UNIX, some highly trusted (and sensitive) sites can be compromised. By servers that matter, I mean those that provide hundreds or even thousands of users access to the Internet and other key networks within the Internet. These are generally governmental or educational sites, which differ from sites maintained, for example, by a single company. With a single company, the damage can generally travel only so far, placing the company and all its users at risk. This is a serious issue, to be sure, but is relevant only to that company. In contrast, the compromise of government or educational sites can place thousands of computers at risk.
There are also instances where key UNIX utilities are compromised (and trojaned) by programmers who have nothing to do with the development of the legitimate program. This has happened many times and, on more than one occasion, has involved security-related programs. For example, following the release of SATAN, a trojan found its way into the SATAN 1.0 distribution for Linux.
NOTE: This distribution was not the work of Farmer or Venema. Instead, it was a precompiled set of binaries intended solely for Linux users, compiled at Temple University. Moreover, the trojan was confined to a single release, that being 1.0.
Reportedly, the file affected was a program called fping. The story goes as follows: A programmer obtained physical access to a machine housing the program. He modified the main() function and altered the fping file so that when users ran SATAN, a special entry would be placed in their /etc/passwd file. This special entry was the addition of a user named suser. Through this user ID, the perpetrator hoped to compromise many hosts. As it happened, only two recorded instances of such compromise emerged. Flatly stated, the programming was of poor quality. For example, the trojan provided no contingency for those systems that made use of shadowed passwords.
NOTE: The slackware distribution of Linux defaults to a nonshadowed password scheme. This may be true of other Linux distributions as well. However, the programmer responsible for the trojan in question should not have counted on that. It would have been only slightly more complicated to add a provision for this.
As you can see, a trojan might crop up anywhere. Even a file originating from a reasonably trusted source could be trojaned.
0 comments
Post a Comment