|
|
Examined
here is one of the more dangerous devices used to circumvent Internet security:
The Trojan horse, or Trojan. No other device is more likely to
lead to total compromise of a system, and no other device is more difficult to
detect.
A
Trojan is a program that does something more than the user was expecting, and
that extra function is damaging. This leads to a problem in detecting Trojans.
Suppose I wrote a program that could infallibly detect whether another program
formatted the hard disk. Then, can it say that this program is a Trojan?
Obviously not if the other program was supposed to format the hard disk (like
Format does, for example), then it is not a Trojan. But if the user was not
expecting the format, then it is a Trojan. The problem is to compare what the
program does with the user's expectations. You cannot determine the user's
expectations for a program.*
*All
About Viruses by Dr. Alan Solomon can be
found at http://www.drsolomon.com/vircen/allabout.html
Therefore,
a Trojan can be any program that performs a hidden and unwanted function. This
may come in any form. It might be a utility that purports to index file
directories or one that unlocks registration codes on software. It might be a
word processor or a network utility. In short, a Trojan could be anything (and
could be found in anything) that anyone introduces to the system.
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 the hard disk
drive). So Trojans may perform various intelligence tasks (penetrative or
collective) or tasks that amount to damage.
Technically,
a Trojan could appear almost anywhere, on any operating system or platform.
However, with the exception of the inside job, the spread of trojans works very
much like the spread of viruses. Software downloaded from the Internet,
especially shareware or freeware, is always suspected. Similarly, materials
downloaded from underground servers or Usenet newsgroups are also candidates.
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.
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
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
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 tiny 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.
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. 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 would likewise recognize questionable
code in a Perl program.
Trojans
represent a very high level of risk, mainly for reasons already stated:
Ø
Trojans
are difficult to detect.
Ø
In
most cases, trojans are found in binaries, which remain largely in
non-human-readable form.
Ø
Trojans
can affect many machines.
To
elaborate, Trojans are a perfect example of the type of attack that is
fatal to the system administrator who has only a very fleeting knowledge of
security. In such a climate, a Trojan can lead to total compromise of the
system. The Trojan may be in place for weeks or even months before it is
discovered. In that time, a cracker with root privileges could alter the entire
system to suit his or her needs. Thus, even when the Trojan is discovered, new
holes may exist of which the system administrator is completely unaware.
How
to detect Trojans?
Detecting
Trojans is less difficult than it initially seems. But strong knowledge of your
operating system is needed; also, some knowledge of encryption can help.
If
the environment is such that sensitive data resides on your server (which is
never a good idea), it is necessary to take advanced measures. Conversely, if no
such information exists on your server, you might feel comfortable employing
less stringent methods.
The
choice breaks down to need, time, and interest. The first two of these elements
represent cost. Time always costs money, and that cost will rise depending on
how long it has been since your operating system was installed. This is so
because in that length of time, many applications that complicate the
reconciliation process have probably been installed. For example, consider
updates and upgrades. Sometimes, libraries (or DLL files) are altered or
overwritten with newer versions. If you were using a file-integrity checker,
these files would be identified as changed. If system administrator was not the
person who performed the upgrade or update, and the program is sufficiently
obscure, it might end up chasing a Trojan. These situations are rare, true, but
they do occur.
Most
forms of protection against (and prevention of) trojans are based on a technique
sometimes referred to as object reconciliation. Although the term might
sound intimidating, it isn't. It is a fancy way of asking, "Are things
still just the way I left them?" Here is how it works: Objects are
either files or directories. Reconciliation is the process of comparing
those objects against themselves at some earlier (or later) date. For example,
take a backup and compare the file as it existed a month back to the current
situation that now resides on your drive. If the two differ, and no change has
been made to the operating system, something is muddled. This technique is
invariably applied to system files that are installed as part of the basic
operating system.
Object
reconciliation can be easy understood if you recognize that for each time a file
is altered in some way, that file's values change. For example, one way to clock
the change in a file is by examining the date it was last modified. 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 time on
the PC platform. How difficult is it? Change the global time setting, apply the
desired edits, and archive the file. The time is now changed. For this reason,
time is the least reliable way to reconcile an object (at least, relying on the
simple date-last-modified time is unreliable). Also, the last date of
modification reveals nothing if the file was unaltered (for example, if it was
only copied or mailed).
Another
way to check the integrity of a file is by examining its size. However, this
method is extremely unreliable because of how easily this value can be
manipulated. When editing plain text files, it is simple to start out with a
size of, say, 1,024KB and end up with that same size. It takes cutting a bit
here and adding a bit there. But the situation changes radically when you want
to alter a binary file. Binary files usually involve the inclusion of special
function libraries and other modules without which the program will not work.
Thus, to alter a binary file (and still have the program function) is a more
complicated process. The programmer must preserve all the indispensable parts of
the program and still find room for his or her own code. Therefore, size is
probably a slightly more reliable index than time. Briefly, before continuing,
let us explain the process by which a file becomes trojaned.
The
most common scenario is when a semi-trusted (known) file is the object of
the attack. That is, the file is native to your operating system distribution;
it comes from the vendor (such as the file csh in UNIX or command.com
in DOS). These files are
written to your drive on the first install, and they have a date and time on
them. They also are of a specified size. If the times, dates, or sizes of these
files differ from their original values, this raises immediate suspicion.
Evil
programmers know this. Their job, therefore, is to carefully examine the source
code for the file (usually obtained elsewhere) for items that can be excluded
(for example, they may single out commented text or some other, not-so-essential
element of the file). The unauthorized code is written into the source, and the
file is recompiled. The cracker then examines the size of the file. Perhaps it
is too large or too small. The process then begins again, until the attacker has
compiled a file that is as close to the original size as possible. This is a
time-consuming process. If the binary is a fairly large one, it could take
several days.
When
the file has been altered, it is placed where others can obtain it. In the case
of operating-system distributions, this is generally a central site for download
(such as sunsite.unc.edu, which houses one of the
largest collection of UNIX software on the planet). From there, the file finds
its way into workstations.
For
reasons that must now seem obvious, the size of the file is also a poor index by
which to measure its alteration. So, to recount: Date, date of last access,
time, and size are all indexes without real meaning. None of these alone is
suitable for determining the integrity of a file. In each, there is some
flaw--usually inherent to the platform--that makes these values easy to alter.
There
are other indexes, such as checksums, that one can check; these are far better
indexes, but also not entirely reliable. In the checksum system, the data
elements of a file are added together and run through an algorithm. The
resulting number is a checksum, a type of signature for that file
(bar-code readers sometimes use checksums in their scan process). On the SunOS
platform, one can review the checksum of a particular file using the utility
sum. Sum calculates (and prints to STDOUT
or other specified mediums) the checksums of files provided on the argument
line.
Although
checksums are more reliable than time, date, or last date of modification, these
too can be tampered with. Most system administrators suggest that if you rely on
a checksum system, your checksum list should be kept on a separate server or
even a separate medium, accessible only by root and other trusted users. In any
event, checksums work nicely for checking the integrity of a file transferred,
for example, from point A to point B, but that is the extent of it.
MD5
There is a technique, which is
really reliable. It
involves calculating the digital fingerprint, or signature, for each
file. This is done utilizing various algorithms. A family of algorithms, called
the MD series, is used for this purpose. One of the most popular
implementations is a system called MD5.
MD5
is a utility that can generate a digital signature of a file. MD5 belongs to a
family of one-way hash functions called message digest algorithms. The
MD5 system is defined as
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
When
one runs a file through an MD5 implementation, the signature emerges as a
32-character value. It looks like this:
2d50b2bffb537cc4e637dd1f07a187f4
Many
sites that distribute security fixes for the UNIX operating system employ this
technique. Thus, as we browse the directories, we can examine the original
digital signature of each file. If, upon downloading that file, it can be found
out that the signature is different, there is a 99.9% chance that something is
terribly muddled.