ch14.htm

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

You can "tell" the machine what each function is, what it does, and how
it does it.</P>
<P>Assembly language is only one step removed from machine language and is therefore
a very low-level language. And, because it speaks so directly to the machine's hardware,
the resulting programs are very small. (In other words, the translation process is
minimal. This is greatly different from C, where substantial translation must occur
to get the plain English into machine-readable code. The less translation that has
to be done, the smaller the binary that results.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>If you want to learn
	more about Assembly Language, there is an excellent page on the Web that sports a
	search engine through which you can incisively search terms, functions and definitions.
	That site is <TT>http://udgftp.cencar.udg.mx/ingles/tutor/Assembler.html</TT>. 
<HR>


</BLOCKQUOTE>

<P>Programs written in assembly language execute with great speed, often many times
faster than those written in higher-level languages. So, viruses are small, fast,
and, to users who are unprepared, difficult to detect.</P>
<P>There are many different types of viruses, but one of the most critical is the
boot sector virus. To get you started on understanding how viruses work, I have picked
the boot sector virus as a model.</P>
<P>Many users are unaware of how their hard disk drive works in conjunction with
the rest of the system. I want to explore that process for just a moment. Please
examine Figure 14.6.</P>
<P><A NAME="06"></A><A HREF="06.htm"><B>Figure 14.6.</B></A><B><BR>
</B><I>Location of the master boot record.</I></P>
<P>Hard disks drives rely upon data stored in the master boot record (MBR) to perform
basic boot procedures. The MBR is located at cylinder 0, head 0, sector 1. (Or, Logical
Block Address 0. LBA methods of addressing vary slightly from conventional addressing;
Sector 1=LBA 0.)</P>
<P>For such a small area of the disk, the MBR performs a vital function: It explains
the characteristics of the disk to every other program that happens by. To do this,
it stores information regarding the structure of the disk. This information is referred
to as the <I>partition table</I>.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>If this sounds confusing, think
	about when you partition a disk. DOS/Windows users do this using a program called
	<TT>FDISK.EXE</TT>. UNIX users also have several similar utilities, including <TT>fdisk</TT>,
	<TT>cfdisk</TT>, and so on. Before partitioning a disk, it is customary to examine
	the partition table data. (At least, you will if you want to be safe!) These programs
	read the partition information from the MBR partition table. This information characteristically
	tells you how many partitions there are, their size, and so forth. (UNIX users will
	even see the <I>type</I> of partition. DOS/Windows users cannot identify partitions
	not commonly used on the AT platform. Whenever these are present, the type is listed
	as <TT>UNKNOWN</TT>.) 
<HR>


</BLOCKQUOTE>

<P>When a machine boots up, it proceeds, assuming that the CMOS settings are correct.
These values are read and double-checked. If it finds that the default boot disk
is actually 1GB when the BIOS settings suggest 500MB, there will be a problem. (The
machine will not boot, and an error message will be generated.) Similarly, the RAM
is tested for bad memory addresses. Eventually, when no errors have been encountered,
the actual boot process begins. At that stage, the MBR takes the helm and the disk
boots. When the boot sector has been infected by a virus, a critical situation develops.</P>
<P>As explained by the specialists at McAfee, the leading virus protection vendor:

<DL>
	<DD>Master Boot Record/Boot Sector (MBR/BS) infectors are those viruses that infect
	the MBR and/or boot sector of hard drives and the boot sector of floppy diskettes.
	These viruses are the most successful viruses in the world. This is because they
	are fairly simple to write, they take control of the machine at a very low level,
	and are often &quot;stealthy.&quot; Eighty percent of the calls McAfee Support receives
	are on this type of virus.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from an article titled &quot;Top Master Boot Record/Boot Sector Infecting
	Viruses,&quot; produced by McAfee Associates. This paper can be found online at <A
	HREF="http://www.mcafee.com/support/techdocs/vinfo/1101.html"><TT>http://www.mcafee.com/support/techdocs/vinfo/1101.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>MBR viruses are particularly insidious because they attack floppy disks whenever
they are accessed by your machine. It is for this reason that MBR viruses are so
commonly seen in the wild--because they infect floppies, they can travel from machine
to machine fairly easily.</P>
<P>In any event, assume for the moment that you have a &quot;clean&quot; MBR. How
does a virus manage to infect it? The infection process happens when you boot with
an infected floppy diskette. Consider this situation: You decide that you are going
to load a new operating system onto the drive. To do this, you use a boot floppy.
(This boot floppy will contain a small boot routine that guides you through the installation.)
Fine. Take a look at Figure 14.7.</P>
<P><A NAME="07"></A><A HREF="07.htm"><B>Figure 14.7.</B></A><B><BR>
</B><I>The infection illustrated.</I></P>
<P>During the boot process, the virus loads itself into memory, although generally
not the upper memory. In fact, very few viruses are known to reside in upper memory.
When one does, it is usually because it has <I>piggybacked</I> its way there; in
other words, it has attached itself to an executable or a driver that always loads
high. This is rare.</P>
<P>Once loaded into memory, the virus reads the MBR partition information. In some
cases, the virus programmer has added a routine that will check for previous infection
of the MBR. It checks for infection not only by his own virus, but by someone else's
as well. This procedure is usually limited in scope, because the programmer wants
to save resources. A virus that could check for many other viruses before installing
would characteristically be larger, more easily detected, less easily transmitted,
and so forth. In any event, the virus then replaces the MBR information with its
own, modified version. The installation procedure is complete.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>The majority of boot sector viruses
	also contain some provision for storing the original MBR elsewhere on the drive.
	There is a good reason for this. It isn't because the virus programmer is a nice
	person and intends to eventually return the MBR to its original state. Rather, it
	is because he has to. Many important functions require that the MBR be read on initialization.
	Typically, a virus will keep a copy of the original and offer it up whenever other
	processes request it. In this way, the virus remains hidden because these functions
	are never alerted to the fact that the MBR was in any way altered. Sneaky, right?
	When this technique is used correctly, it is referred to as <I>stealth</I>. 
<HR>


</BLOCKQUOTE>

<P>I have personal experience with just such a virus, called antiexe. A friend came
to my office so I could assist him in preparing a presentation. He brought with him
a small laptop that had been used at his company. Apparently, one of the employees
had been playing a game on the laptop that required a boot disk. (Some games have
strange memory-management routines that are not compatible with various user configurations.
These typically request that you generate a boot disk and undertake other annoying
procedures.) Through a series of unfortunate events, this virus was transferred from
that laptop to one of my machines. The curious thing is this: I did have a terminate-and-stay-resident
(TSR) virus checker installed on the infected machine. This was a well-known product,
but I will not mention its name here lest I cause a panic. For some inexplicable
reason, the TSR virus checker did not catch antiexe when it infected my MBR, but
only after the machine was rebooted a day or so later. At any rate, I woke to find
that my machine had been infected. Antiexe is described in the CIAC database as follows:

<DL>
	<DD>The virus hides in the boot sector of a floppy disk and moves the actual boot
	sector to cyl: 0, side: 1, sector: 15. On the hard disk, the virus infects the partition
	table, the actual partition table is on cyl: 0, side: 0, sector: 13. These are normally
	unused sectors, so disk data is not compromised by the virus insertion. The virus
	uses stealth methods to intercept disk accesses for the partition table and replaces
	them with the actual partition table instead of the virus code. You must boot a system
	without the virus in memory to see the actual virus code.
</DL>

<P>It was no problem to eliminate the virus. The same product that initially failed
to detect antiexe destroyed it without event. The time I lost as a result was minimal.</P>
<P>Most viruses do not actually destroy data; they simply infect disks or files.
There are, however, many occasions on which infection alone is enough to disrupt
service; for example, some drivers operate erratically when infected. This is not
to say, however, that there are no destructive viruses.</P>
<P>Who writes viruses? Many different types of programmers from many different walks
of life. Kids are a common source. There are kits floating around on the Internet
that will assist budding programmers in creating viruses. It has been theorized that
young people sometimes write viruses to &quot;make their mark&quot; on the computing
communities. Because these young people do not actually work in computer programming,
they figure that writing a virus is one way to make a name for themselves. (A good
percentage of virus authors take a pseudonym or &quot;handle&quot; and write under
that. This moniker is sometimes found within the code of the virus.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>There is a fascinating
	paper on the Internet regarding the rise of virus- development groups in Eastern
	Europe that describes how the virus took these programming communities by storm.
	Ultimately, bulletin board systems were established where virus authors could exchange
	code and ideas. The paper is extremely thorough and makes for absorbing reading,
	giving a bird's eye view of virus development in a noncapitalist environment. It
	is called &quot;The Bulgarian and Soviet Virus Factories&quot;; it was written by
	Vesselin Bontchev, Director of the Laboratory of Computer Virology at the Bulgarian
	Academy of Sciences in Sofia, Bulgaria. The paper can be found at <A HREF="http://www.drsolomon.com/ftp/papers/factory.txt"><TT>http://www.drsolomon.com/ftp/papers/factory.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>One interesting aspect of the virus-writing community is that vanity, envy, and
fierce competition often influence the way such viruses are written. For example:

<DL>
	<DD>Some computer viruses are designed to work not only in a &quot;virgin&quot; environment
	of infectable programs, but also on systems that include anti-virus software and
	even other computer viruses. In order to survive successfully in such environments,
	those viruses contain mechanisms to disable and/or remove the said anti-virus programs
	and &quot;competitor&quot; viruses. Examples for such viruses in the IBM PC environment
	are Den_Zuko (removes the Brain virus and replaces it with itself), Yankee_Doodle
	(the newer versions are able to locate the older ones and &quot;upgrade&quot; the
	infected files by removing the older version of the virus and replacing it with the
	newer one), Neuroquila (disables several anti-virus programs), and several other
	viruses.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The preceding paragraph
	is excerpted from an article by Vesselin Bontchev (a research associate at the Virus
	Test Center at the University of Hamburg) titled &quot;Are `Good' Computer Viruses
	Still a Bad Idea?&quot; This paper can be found online at <A HREF="http://www.virusbtn.com/OtherPapers/GoodVir/"><TT>http://www.virusbtn.com/OtherPapers/GoodVir/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>As I have already noted, many programmers develop viruses using <I>virus kits</I>,
or applications that are designed specifically to generate virus code. These kits
are circulated on the Internet. Here are the names of a few:

<UL>
	<LI>Virus Creation Laboratories
	<LI>Virus Factory
	<LI>Virus Creation 2000
	<LI>Virus Construction Set
	<LI>The Windows Virus Engine
</UL>

<P>These kits are usually quite easy to use, thereby allowing almost anyone to create
a virus. (This is in contrast to the &quot;old days,&quot; when advanced programming
knowledge was required.) This has resulted in an increase in viruses in the wild.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>A virus is deemed <I>in the wild</I>
	when it has escaped or been released into the general population. That is, <I>the</I>
	<I>wild</I> refers to any computing environment outside the academic or development
	environment where the virus was created and tested. This term is purportedly derived
	from lingo used in reference to environments where biological warfare experiments
	are conducted. These studies are typically conducted under controlled circumstances,
	where no danger is posed to the surrounding communities. However, when a biological
	virus escapes its controlled environment, it is deemed to have entered the wild.