ch11.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,114 行 · 第 1/4 页

</BLOCKQUOTE>

<P>As you can see, a trojan might crop up anywhere. Even a file originating from
a reasonably trusted source could be trojaned.
<H2><FONT COLOR="#000077"><B>Where Might One Find a Trojan?</B></FONT></H2>
<P>Technically, a trojan could appear almost anywhere, on any operating system or
platform. However, with the exception of the inside job mentioned previously, the
spread of trojans works very much like the spread of viruses. Software downloaded
from the Internet, especially shareware or freeware, is always suspect. Similarly,
materials downloaded from underground servers or Usenet newsgroups are also candidates.</P>
<P>Sometimes, one need not travel down such dark and forbidden alleys to find a trojan.
Trojans can be found in major, network-wide distributions. For example, examine this
excerpt from a CIAC security advisory (&quot;E-14: Wuarchive Ftpd Trojan Horse&quot;),
posted to the Net in 1994:

<DL>
	<DD>CIAC has received information that some copies of the wuarchive FTP daemon (ftpd)
	versions 2.2 and 2.1f have been modified at the source code level to contain a trojan
	horse. This trojan allows any user, local or remote, to become root on the affected
	UNIX system. CIAC strongly recommends that all sites running these or older versions
	of the wuarchive ftpd retrieve and install version 2.3. It is possible that versions
	previous to 2.2 and 2.1f contain the trojan as well.
</DL>

<P>wftpd is one of the most widely used FTP servers in the world. This advisory affected
thousands of sites, public and private. Many of those sites are still at risk, primarily
because the system administrators at those locations are not as security conscious
as they should be.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Pick 100 random hosts in the void
	and try their FTP servers. I would wager that out of those hosts, more than 80% are
	using wftpd. In addition, another 40% of those are probably using older versions
	that, although they may not be trojaned, have security flaws of some kind. 
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>C'mon! How Often Are Trojans Really Discovered?</B></FONT></H2>
<P>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.</P>
<P>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 <TT>STDOUT</TT> at specified points within the program:</P>
<PRE><FONT COLOR="#0066FF">my_function() 
{
cout &lt;&lt; &quot;The value you have entered is out of range!\n&quot;;
cout &lt;&lt; &quot;Please enter another:&quot;
} 
</FONT></PRE>
<P>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.</P>
<P>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 &quot;Get the patch now and replace the bogus binary.&quot; 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.</P>
<P>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 <TT>passwd</TT> 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.</P>
<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>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.
	
<HR>


</BLOCKQUOTE>

<P>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.</P>
<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>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.
	
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>What Level of Risk Do Trojans Represent?</B></FONT></H2>
<P>Trojans represent a very high level of risk, mainly for reasons already stated:</P>

<UL>
	<LI><FONT COLOR="#000000">Trojans are difficult to detect.<BR>
	<BR>
	</FONT>
	<LI><FONT COLOR="#000000">In most cases, trojans are found in binaries, which remain
	largely in non-human-readable form.<BR>
	<BR>
	</FONT>
	<LI><FONT COLOR="#000000">Trojans can affect many machines.</FONT>
</UL>

<PRE></PRE>
<P>Let me 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.
<H2><FONT COLOR="#000077"><B>How Does One Detect a Trojan?</B></FONT></H2>
<P>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.</P>
<P>If your environment is such that sensitive data resides on your server (which
is never a good idea), you will want 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 you were not the person who performed the upgrade or update,
and the program is sufficiently obscure, you might end up chasing a phantom trojan.
These situations are rare, true, but they do occur.</P>
<P>Most forms of protection against (and prevention of) trojans are based on a technique
sometimes referred to as <I>object reconciliation</I>. Although the term might sound
intimidating, it isn't. It is a fancy way of asking &quot;Are things still just the
way I left them?&quot; Here is how it works: <I>Objects</I> are either files or directories.
<I>Reconciliation</I> is the process of comparing those objects against themselves
at some earlier (or later) date. For example, take a backup tape and compare the
file PS as it existed in November 1995 to the PS that now resides on your drive.
If the two differ, and no change has been made to the operating system, something
is amiss. This technique is invariably applied to system files that are installed
as part of the basic operating system.</P>
<P>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).


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>PC users who have used older machines
	can easily understand this. Sometimes, when the CMOS battery fails, the system may
	temporarily fail. When it is brought back up, you will see that a few files have
	the date January 1, 1980. 
<HR>


</BLOCKQUOTE>

<P>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 I continue, let me explain the process by which a file becomes trojaned.</P>
<P>The most common scenario is when a semi-trusted (<I>known</I>) 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 <TT>csh</TT> in UNIX or <TT>command.com</TT>
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.</P>
<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>When an original operating-system
	distributed file is the target, the attacker may or may not have to go through this
	process. If the file has not yet been distributed to anyone, the attacker need not
	concern himself or herself with this problem. This is because no one has yet seen
	the file or its size. Perhaps only the original author of the file would know that
	something was amiss. If that original author is not security conscious, he or she
	might not even know. If you are a programmer, think now about the very last binary
	you compiled. How big was it? What was its file size? I bet you don't remember. 
<HR>


</BLOCKQUOTE>

<P>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 <TT>sunsite.unc.edu</TT>, which houses one of the largest collection of
UNIX software on the planet). From there, the file finds its way into workstations
across the void.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B><TT>sunsite.unc.edu</TT> is the
	Sun Microsystems-sponsored site at UNC Chapel Hill. This site houses the greater
	body of free software on the Internet. Thousands of individuals--including me--rely
	on the high-quality UNIX software available at this location. Not enough good can
	be said about this site. It is a tremendous public service. 
<HR>


</BLOCKQUOTE>