Begin by answering some basic questions, including;
What is a scanner?
What does a scanner do?
On what platforms are scanners available?
What system requirements are involved to run
a scanner?
Is it difficult to create a scanner?
What will a scanner tell me?
What won't a scanner tell me?
Are scanners legal?
Why are scanners important to Internet security?
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:
You might encounter problems if you are running
an older Macintosh or IBM compatible with
a slow Internet connection (as would be the case
if you used Windows 3.11 running
TCPMAN as a TCP/IP stack, via a 14.4 modem).
These configurations might cause stack
overflows or general protection faults, or they
might simply cause your machine to hang.
Generally, the faster your connection, the better
off you are. (And naturally, a true 32-bit
system contributes greatly to performance.)
RAM is another issue, mainly relevant to window-system-based
scanners. Command-line
scanning utilities typically require little memory.
Windowed scanners can require a lot. (For a
comparison, I suggest running ISS. First, try
the older, command-line version. Then run the
new Xiss, which operates through MIT's X Window
System, OpenWindows, or any
compatible UNIX-based windowing system. The difference
is very noticeable.)
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:
A step-by-step method of breaking in
The degree to which your scanning activity has
been logged
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
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:
Scanners are used only on the Internet or other
TCP/IP networks.
Scanners are more intelligent than war dialers.
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
The capability to find a machine or network
The capability, once having found a machine,
to find out what services are being run on the
host
The capability to test those services for known
holes
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
Graphics
Art
Indy
Indigo
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:
Start the scan, requesting the option to test
Telnet connections for the lp login.
Wait until a signal indicating that the scan
is completed is received.
Access the result file, exporting only those
results that show successful penetration.
Format these results into flat-file, database
format for easy management.
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:
ODIE.bu.edu is a possible target for the mount
-d -s bug, where if two successive mount
-d -s commands are sent within seconds of one
another (and before another host has issued
such a request), the request will be honored.
CHEEZEWIZ.bu.edu is a potential target for either
the lp login bug or the Telnet bug. Or
maybe, if we're on site, we can exploit the floppy
mounter bug in /usr/etc/msdos.
POLLUX.bu.edu is an old machine. Perhaps Sun
Patch-ID# 100376-01 hasn't been applied.
Maybe they put in a fresh install of SunOS 4.1.x
and the SPARC integer division is shredded.
I see that PSY81-PC150.bu.edu is running Windows
95. I wonder whether the SMB
protocol is running and if so, are any local
directories shared out? Using Samba on a Linux
box, perhaps I can attach one of the shared out
directories from anywhere on the Internet
simply by specifying myself as a guest.
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:
sendmail
Anon FTP
NFS Exports
TFTP
Hosts.equiv
Xhost
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:
AppleTalk scanning
Novell scanning
LAN manager networks
The capability to scan subnets
Briefly, the processes undertaken by NSS include
Getting the domain listing or reporting that
no such listing exists
Pinging the host to determine whether it's alive
Scanning the ports of the target host
Reporting holes at that location
Although this is not an exhaustive treatment of NSS, there are some minor
points I can offer here:
NSS does not run immediately after you unzip
and untar it. Several changes must be made to
the file. The environment variables must be set
to those applicable to your machine's
configuration. The key variables are
$TmpDir--The temporary
directory used by NSS
$YPX--The directory
where the ypx utility is located
$PING--The directory
where the executable ping is located
$XWININFO--The
directory where xwininfo is located
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.
NSS has parallel capabilities and can distribute
the scan among a number of workstations.
Moreover, it can fork processes. Those running
NSS on machines with limited resources (or
running it without permission) will want to avoid
these capabilities. These are options that can
set within the code.
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
Command-line option to specify starting and
ending ports
Command-line option to specify time after which
a scan will terminate if it receives no
response from a port or host
Command-line option to specify the number of
sockets to use
Command-line option to specify a file from which
Strobe will take its target hosts
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.
SATAN scans remote hosts for most known holes,
including but not limited to these:
FTPD vulnerabilities and writable FTP directories
NFS vulnerabilities
NIS vulnerabilities
RSH vulnerability
sendmail
X server vulnerabilities
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:
The intranet scanner
The Web scanner
The firewall scanner
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:
sendmail
FTP
NNTP
Telnet
RPC
NFS
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:
Machine: 486 DX-4 120 AT IBM compatible
Memory: 32 MB
Operating system: Linux 1.2.13 (Slackware)
Modem: 28.8
Network connection: PPP (pppd)
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:
Sun OS 4.1.3 or above
Solaris 2.3 or above
HP/UX 9.05 or above
IBM AIX 3.2.5 or above
Linux 1.2.x (with kernel patch)
Linux 1.3.x prior to 1.3.75 (with patch)
Linux 1.3.76+ (no patch required)
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.
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
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:
In an earlier scan, HTTPD was being run as root,
thereby making SamsHack.net vulnerable
to WWW attacks.
SamsHack.net is vulnerable to RSH attacks.
SamsHack.net's FTP directory allows anonymous
users to access the passwd file.
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).
Figure 9.2.
The Network Toolbox opening screen.
Figure 9.3.
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).
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.
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.
E-Mail any questions, comments or deaththreats to:
ameister@vol.com
Copyright © AcidMeister...
Visit him at:
http://www.vol.com/~ameister
Disclaimer:
This is for Educational purposes only it should not be used as a guide
to
cause havoc or to hack. He He He, good luck!!! And don't get caught.
I
would hate to see you in a cell with your 300 pound Bruno The Gay Ax
murderer. He He He.
