C'mon! How Often Are Trojans Really Discovered?
Trojans are discovered often enough that they are a major security concern. What makes trojans so insidious is that even after they are discovered, their influence is still felt. Trojans are similar to sniffers in that respect. No one can be sure exactly how deep into the system the compromise may have reached. There are several reasons for this, but I will limit this section to only one.
As you will soon read, the majority of trojans are nested within compiled binaries. That is to say: The code that houses the trojan is no longer in human-readable form but has been compiled. Thus, it is in machine language. This language can be examined in certain raw editors, but even then, only printable character strings are usually comprehensible. These most often are error messages, advisories, option flags, or other data printed to STDOUT at specified points within the program:
my_function()
{
cout << "The value you have entered is out of range!\n";
cout << "Please enter another:"
}
Because the binaries are compiled, they come to the user as (more or less) point-and-shoot applications. In other words, the user takes the file or files as is, without intimate knowledge of their structure.
When authorities discover that such a binary houses a trojan, security advisories are immediately issued. These tend to be preliminary and are later followed by more comprehensive advisories that may briefly discuss the agenda and method of operation of the trojan code. Unless the user is a programmer, these advisories spell out little more than "Get the patch now and replace the bogus binary." Experienced system administrators may clearly understand the meaning of such advisories (or even clearly understand the purpose of the code, which is usually included with the comprehensive advisory). However, even then, assessment of damages can be difficult.
In some cases, the damage seems simple enough to assess (for example, instances where the trojan's purpose was to mail out the contents of the passwd file). The fix is pretty straightforward: Replace the binary with a clean version and have all users change their passwords. This being the whole of the trojan's function, no further damage or compromise is expected. Simple.
But suppose the trojan is more complex. Suppose, for example, that its purpose is to open a hole for the intruder, a hole through which he gains root access during the wee hours. If the intruder was careful to alter the logs, there might be no way of knowing the depth of the compromise (especially if you discover the trojan months after it was installed). This type of case might call for reinstallation of the entire operating system.
NOTE: Reinstallation may be a requisite. Many more of your files might have been trojaned since the initial compromise. Rather than attempt to examine each file (or each file's behavior) closely, it might make better sense to start over. Equally, even if more files haven't been trojaned, it's likely that passwords, personal data, or other sensitive materials have been compromised.
Conversely, trojans may be found in executable files that are not compiled. These might be shell scripts, or perhaps programs written in Perl, JavaScript, VBScript, Tcl (a popular scripting language), and so forth. There have been few verified cases of this type of trojan. The cracker who places a trojan within a noncompiled executable is risking a great deal. The source is in plain, human-readable text. In a small program, a block of trojan code would stand out dramatically. However, this method may not be so ludicrous when dealing with larger programs or in those programs that incorporate a series of compiled binaries and executable shell scripts nested within several subdirectories. The more complex the structure of the distribution, the less likely it is that a human being, using normal methods of investigation, would uncover a trojan.
Moreover, one must consider the level of the user's knowledge. Users who know little about their operating system are less likely to venture deep into the directory structure of a given distribution, looking for mysterious or suspicious code (even if that code is human readable). The reverse is true if the user happens to be a programmer. However, the fact that a user is a programmer does not mean he or she will instantly recognize a trojan. I know many BASIC programmers who have a difficult time reading code written in Perl. Thus, if the trojan exists in a scripting language, the programmer must first be familiar with that language before he or she can identify objectionable code within it. It is equally true that if the language even slightly resembles a language that the programmer normally uses, he or she may be able to identify the problem. For example, Perl is sufficiently similar to C that a C programmer who has never written a line of Perl could effectively identify malicious code within a Perl script. And of course, anyone who writes programs in a shell language or awk would likewise recognize questionable code in a Perl program.
NOTE: Many Perl programs (or other scripted shell programs) are dynamic; that is, they may change according to certain circumstances. For example, consider a program that, in effect, rewrites itself based on certain conditions specified in the programming code. Such files need to be checked by hand for tampering because integrity checkers will always report that the file has been attacked, even when it has not. Granted, today, there are relatively few dynamic programs, but that is about to change. There is talk on the Internet of using languages like Perl to perform functions in Electronic Data Interchange (EDI). In some instances, these files will perform functions that necessarily require the program file to change.
0 comments
Post a Comment