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.
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.
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.
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.
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.
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.
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.
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.
A scanner won't tell you the following:
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."
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.
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.
| 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 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.
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.
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.
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.
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.
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 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's name is quite descriptive. In short, it traces the route between two machines. As explained in the man (manual) page:
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 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.
| Process | Purpose |
| lp | The Line Printer daemon |
| UUCP | UNIX to UNIX copy |
| root | Root operator |
| 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 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.
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.
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.
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/.
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.
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) 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 (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/.
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 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.
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 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 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 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 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 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 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.
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:
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:
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.
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.
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.
| 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.
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.
Figure 9.1.
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 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.
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.
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.
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.
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.
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 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.
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
Figure 9.2.
The Network Toolbox opening screen.
Figure 9.3.
The Network Toolbox Options panel.
Figure 9.4.
The Network Toolbox Port Scanner Option tab.
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.
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.
© Copyright, Macmillan Computer Publishing. All rights reserved.