M
_mAkA_
Guest
When the network that is now the Internet was first designed, it was assumed
that all users wanted to be found. No one had reason to hide, and it seemed
sensible that researchers should be able to locate each other. Utilities
were therefore created to facilitate such finding.
Since those early days, the rise of multiple protocols has made finding
people even more convenient. As you will see later in this chapter, the old
days demanded a high level of networking knowledge from the user. Today,
finding or identifying most individuals is trivial. Throughout this chapter,
I examine those techniques, as well as some concepts about wholesale tracing
(tracing many individuals at one time).
You may wonder why this is deemed a security issue.
In truth, it really isn't--not yet. As you read this chapter, however, you
will learn that the Internet is a powerful tool for domestic spying.
Law-enforcement and intelligence agencies already conduct such practices on
the Internet, and for them, the Network is a bonanza. No search warrant is
needed to "study" the activity of someone on the Internet. Likewise, no
warrant is needed to compile lists of individuals who law enforcement
perceive to be involved in illegal (or even seditious) activity. This is not
a joke. If you harbor radical political views, by the end of this chapter,
you may elect to forever keep those views to yourself (or gain a decent
education in cryptography).
Before I begin, I need to make one statement regarding screenshots and
diagnostic network information contained within this chapter. Certain
methods of finding individuals demand the use of search engines.
Unfortunately, to my knowledge, the law has not been adequately settled
regarding the reprinting of an individual's e-mail address without his
consent. Because of this, I cannot provide screenshots of searches because
they necessarily contain the e-mail addresses of users unknown.
Therefore, the searches have to be described rather than illustrated. I do
apologize for this. However, upon reflection, I would not want my e-mail
address published, and I see no reason why anyone else would, either. The
argument is often made that anyone who posts to a Usenet newsgroups has at
least given an implied form of consent. I do not support that view. So, I am
afraid that we shall have to get along as best we can by description as
opposed to screenshot. I have taken pains to explain each step carefully
to provide the utmost clarity. I hope that will suffice.
So, let us begin at the beginning, at the heart of your server. We will
start at home base and work our way outward.
What's in a Name?
There are two forms of user identification that apply to all platforms:
your e-mail address and your IP address. It is often theorized that if one
is obscured, the other can never be found. That is untrue. Without chaining
messages through a series of trusted anonymous remailers (remailers that are
purportedly secure), anonymity on the Internet is virtually impossible.
Anonymous remailers are discussed in Chapter 7,
"Birth of a Network: The Internet."
It is possible, however, to make yourself relatively invisible, and that is
probably what most individuals would like to do. Before I get more specific,
however, there are some utilities you need to know about, as well as methods
of tracing individuals. I'll start with finger.
finger
The finger service is a utility common to the UNIX platform. Its purpose is
to provide information about users on a given system. In practical operation,
finger works like most other services available in UNIX. Figure 13.1
demonstrates the use of Finger32, a popular finger client for the Microsoft
Windows platform.
Figure 13.1.
The finger query process.
Cross Reference: Finger32 is a small application port of the UNIX
utility finger. It is available here:
ftp://hyper.net.au/Win95nt-apps/Finger/Wsfinger/Wsfngr32.zip
The finger service relies on the client/server model, which is a recurring
theme in Internet applications. This model works as follows: machines
running server applications distribute information to clients. Clients are
programs designed to accept and interpret information from server
applications. For example, you use a Web browser (or client) to read
information forwarded by a Web server (the HTTP server).
In any event, the finger client-server relationship works as follows:
On the targeted machine (almost always a UNIX system), there is a server
running called fingerd. This is more commonly referred to as the finger
daemon. Its purpose is to answer requests from finger clients from the void.
The finger daemon can return different information, depending largely on the
configuration of the server and the user's personalized settings. For
example, sometimes an "open" UNIX server (that is, one not running a firewall)
will disallow finger access. This is done by disabling the finger daemon,
removing it from the file /etc/inetd.conf. In this case, the finger service
is never started. Any client-issued finger request forwarded to such a
machine will meet with a blank response (or perhaps, Connection Refused.).
Many organizations, particularly ISPs, government sites, and private
corporations, disable finger services. Each has an interest in preserving
the privacy of its users, and that is usually the reason given for disabling
the service. As you will learn later, however, their motivation may also be
system security.
TIP: Certain vital information about the system can be culled by
fingering system IDs such as root, bin, FTP, and so on. On that account,
some sites will disable finger services altogether. It is thought that
by killing the finger and RPC services, one can restrict the amount of
revealing information available to crackers in the void. To some
extent, this is true.
Cross Reference: An excellent paper written by Dan Farmer and
Wietse Venema addresses this issue:
"Improving the Security of Your Site by Breaking Into It." The
paper is so widely distributed on the Internet. Here is a very
reliable source:
*www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html.
(This is a government site, so with all probability, this link will
be good for many years to come.)
Some sites do not disable finger services altogether, but instead put
restrictions on what type of information can be accessed. For example,
by default, the finger daemon allows a systemwide finger. Anyone can be
fingered, including special or privileged accounts. When systemwide fingering
is allowed, one can gather information on all users currently logged to the
machine. This is done by issuing the following command at a UNIX command
prompt:
finger @my_target_host.com
The @ symbol has essentially the same effect as the asterisk does in regular
expression searches. When it is used, the user is fingering all users
currently logged to the target machine. This is most useful when targeting
small providers that have few customers, or when conducting such a finger
query late at night. Certainly, fingering a company as large as Netcom in
this manner would be foolish. (The response forwarded by the server would
likely be many pages in length. The only valid reason for doing this would
be to generate a database of Netcom users.) At any rate, some organizations
will disallow such a request, instead forcing the requesting party to specify
a particular user.
Other sites make use of hacked finger daemons, either created in-house or
available as distributions from other sites across the Internet. These are
finger daemons that have enhanced features, including advanced configuration
options.
Cross Reference: One such hacked finger daemon is the Configurable
Finger Daemon, or cfingerd. Written by Ken Hollis, cfingerd
provides security functions not available in garden-variety finger
servers. It is considered to be an excellent replacement to the
standard distribution of finger. It is available free of charge at
ftp://ftp.bitgate.com/pub/cfingerd/.
Cross Reference: For more generalized understanding of the finger
daemon process, I suggest viewing the source for any public-domain
finger client. There is a nice online resource for this at
*araneus.york.ac.uk/owtwaww/finger.htm.
At any rate, taking you through the process of a finger inquiry will take
just a few moments, but in order for you to exploit the example, you need
a finger client. UNIX users, however, have no need for a finger client,
because this is included in the basic distribution. The same is true of
Windows NT. So this little section is primarily for Windows, Mac, and
OS/2 users. The finger clients are listed in Table 13.1.
Table 13.1. Finger clients for non-UNIX, non-NT users.
Platform
Client
Location
Windows
(All)
WSFinger
ftp://papa.indstate.edu/winsock-l/finger/wsfngr14.zip
Macintosh
Macfinger
ftp://ftp.global.net.id/pub/mac/internet/finger-15.hqx
OS/2
FFEU
*www.musthave.com/OS2/ftp/ffeu101.zip
For demonstration purposes, I will use Finger32, a popular finger application
for Windows 95. The application is simple to use; it presents the user with a
self-explanatory screen from which you choose your host. (See Figure 13.2.)
Figure 13.2.
The Finger32 opening screen--choosing a host.
When you choose this option, a dialog box appears, requesting a host and
username. (See Figure 13.3.)
Figure 13.3.
Specifying your target.
Providing the target is running a finger server, the return output should
read something like this:
Login name: root In real life: 0000-Admin(0000)
Directory: / Shell: /sbin/sh
Last login Tue Feb 18 19:53 on pts/22
New mail received Wed Feb 19 04:05:58 1997;
unread since Wed Feb 19 03:20:43 1997
No Plan.
This tells you several things, including the directory where root@samshack
resides (/), the shell he or she is using (/sbin/sh), and some details on
last login and mail. (Hard-core hackers will know that it also tells you
that root@samshack.com is using Solaris as an operating system. Note the
0000-Admin[0000] string.)
This information does not appear to be particularly revealing; however,
in 70% of all cases, the field In real life is filled with a name. Worse
still, at some universities, you can get the name, telephone number, dorm
room number, and major of students enrolled there (not that the major
matters particularly, but it provides some interesting background).
The information available on a finger query is controlled primarily by the
system administrator of a given site, as well as what information you provide
on your initial signup. Most new users are not aware of this and provide all
the information they can. Most people have no reason to hide, and many
provide their office telephone number or even their home address. It is
human nature to be mostly honest, especially when the entity they are
providing information to seems benign.
So the process of identification usually either starts or ends with a finger
query. As noted previously, the finger query uses your e-mail address as an
index. This leads us immediately into an area of some controversy. Some
individuals believe that by changing their e-mail address in the Netscape
Navigator or Microsoft Internet Explorer Options panels, they obscure their
identity. This is not true. It simply makes your e-mail address more
difficult to obtain. I will get to this subject momentarily. For now, I want
to continue with finger, offering a little folklore. The following is a
classic Internet story. (If you've ever fingered coke@cs.cmu.edu, skip these
next few paragraphs.)
Years ago, the computer science department staff at Carnegie-Mellon
University had a gripe about their Coke machine. Often, staffers would
venture down to the basement, only to find an empty machine. To remedy this
problem, they rigged the machine, connecting it to the Internet (apparently,
they did this by wiring the machine to a DEC 3100). They could then issue a
finger request and determine the following things:
How many sodas were in each slot
What those sodas were--Coke, Diet Coke, Sprite, and so on
Whether the available sodas were cold
Today, you can still issue a finger request to the Coke machine at CMU.
If you were to do so, you would receive output very similar to the following:
[ Forwarding coke as "coke@l.gp.cs.cmu.edu" ]
[L.GP.CS.CMU.EDU]
Login: coke Name: Drink Coke
Directory: /usr/coke Shell: /usr/local/bin/tcsh
Last login Sun Feb 16 18:17 (EST) on ttyp1 from GS84.SP.CS.CMU.EDU
Mail came on Tue Feb 18 14:25, last read on Tue Feb 18 14:25
Plan:
M & M Coke Buttons
/----\ C: CCCCCCCCCCC.............
|?????| C: CCCCCCCC.... D: CCCCCCCCCC..
|?????| C: CCCCCCCCCCCC D: CCCCCCCC....
|?????| C: CCCCCCCC.... D: CCCCCCCCC...
|?????| C: C...........
\----/ S: C...........
| Key:
| 0 = warm; 9 = 90% cold; C = cold; . = empty
| Beverages: C = Coke, D = Diet Coke, S = Sprite
| Leftmost soda/pop will be dispensed next
--^-- M&M status guessed.
Coke status heuristics fit data.
Status last updated Wed Feb 19 00:20:17 1997
As you can see, there is no end to the information available with a finger
query. The story of this Coke machine was told by Terence Parr, President
and Lead Mage of MageLang Institute (*www.magelang.com/), at the 1996
Netscape Developer's Conference at Moscone Center in San Francisco.
Reportedly, Parr was demonstrating a Java application that could emulate
this Coke machine hack when suddenly, a former CMU student, Michael Adler,
rose to the occasion. Adler explained the hack in detail, having firsthand
knowledge of the Coke machine in question. In fact, Adler was largely
responsible for adding the temperature index function.
At any rate, many administrators insist on supporting finger, and some have
legitimate reasons. For example, a finger server allows easy distribution of
information. In order for the finger server to support this functionality,
the targeted user (or alias) must have a plan file. (The Coke machine at
CMU certainly does!) This file is discussed in the next section.
The Plan File (.plan)
On most UNIX servers, user directories are kept beneath the /home/ or /usr
directory hierarchies. For example, a user with a username of cracker will
have his home directory in /home/cracker. (This is not set in stone. System
administrators are responsible for where such directories are kept. They
could specify this location as anywhere on the drive, but the typical
placement is /usr or /home.)
Typically, in that home directory are a series of special files that are
created when the user accesses his account for the first time. For example,
the first time he utilizes the mail program Pine, a series of files are
established, including .pinerc, which is the configuration file for this mail
client.
These files are referred to as dot files, because they are preceded by a
period. Most dot files are created automatically. The .plan file, however,
is not. The user must create this file himself, using any text editor
(for example, vi or pico). This file can be closely correlated with
the plan.txt file on a VAX system. Its purpose is to print user-specified
information whenever that user becomes the target of a finger query. So,
if the user saves into the .plan file a text recounting his life history, that
text will be printed to the STDOUT of the party requesting finger information.
The .plan file is one way that information can be distributed via the finger
server. (Note that you, the user, must create that .plan file. This is not
automatically generated by anyone else.) If you examine Figure 13.1 again,
this will seem a bit clearer.
TIP: You may have encountered servers or users that suggest that you
Finger for more info. Usually, this entails issuing a finger request to
an address like info@targethost.com. Most often, the information you
receive (which could be pages of plain text) comes from the .plan file.
There are other reasons that some administrators keep the finger service
operational. Entire programs can be launched by specifying a particular
address to be fingered. In other words, one could (although it is not
recommended) distribute text files this way. For example, you could write an
event handler to trap finger queries aimed at a particular user; if user A
were fingered, the server would send a specified text file to the requesting
party. I have seen more than one server configured this way, although it is
more common to see mail lists designed in this manner.
For whatever reason, then, finger services may be running on the server at
which you have an account. If you have never bothered to check what
information is available there, you can check now by issuing a finger
request to your own account. You can also examine this information (the
majority of it, anyway) by issuing the following command at a shell prompt:
grep your_username /etc/passwd
TIP: This technique will only work on servers that use non-shadowed
password files, or those that are not employing NIS. In those
instances, you may have to issue a command more like this:
ypcat passwd || cat /etc/passwd | grep user_name
This command will print the information the server holds on you in the
/etc/passwd file. Note that this information will be visible even if the
server makes use of shadowed password entries.
So now you know: The names of the majority of Net citizens are there for
the taking. If your system administrator insists on using finger, there
are several things you can do to minimize your exposure:
Use the popular utility chfn to alter the finger information available
to outsiders
If chfn is not available, request that the sysad change your information
Cancel your current account and start a new one
NOTE: If you believe in harsh solutions and you want to discourage
people from repeatedly fingering your account, write a .plan file
that forwards a few megabytes of garbage. This is most useful if
your sysad refuses to assist, chfn is unavailable, and some joker is
trying to clock your movements using finger.
Of course, perhaps you are not concerned with being fingered as much as you
are concerned with who is doing the fingering. If so, you need MasterPlan.
MasterPlan
MasterPlan is an excellent utility. Written by Laurion Burchall and released
in August 1994, this product takes an aggressive approach to protecting your
privacy. First and foremost, MasterPlan identifies who is trying to finger
you. Each time a finger query is detected, MasterPlan attempts to get the
hostname and user ID of the fingering party. These variables are piped to
an outfile called finger_log. MasterPlan will also determine how often you
are fingered, so you can easily detect if someone is trying to clock you.
(Clocking refers to the practice where user A attempts to discern
the habits of user B using various network utilities, including finger and
the r commands.)
TIP: The r commands consist of a suite of network utilities that can
glean information about users on remote hosts. I will discuss one of
these, a utility called rusers, in a moment.
Typically, a cracker writes a shell or Perl script to finger (or otherwise
query) the target every specified number of minutes or hours. Reasons for
such probing can be diverse. One is to build a profile of the target; for
example, when does the user log in? How often does the user check mail? From
where does the user usually log in? From these queries, a cracker (or other
nosy party) can determine other possible points on the network where the
user can be found.
Consider this example: A cracker I know was attempting to intercept e-mail
trafficked by a nationally renowned female journalist who covers hacking
stories. This journalist had more than one account and frequently logged
into one from another. (In other words, rather than directly logging in,
she would chain her connections.) This is a common practice by individuals
in the public eye. They may want to hide from overly enthusiastic fans
(or perhaps even legitimate foes). Thus, they preserve at least one account
to receive public mail and another to receive private mail.
By running a probing script on the journalist, the cracker was able to
identify her private e-mail address. He was also able to compromise that
network and ultimately capture all the journalist's mail. The mail was
primarily discussions between the journalist and a software engineer in
England. The subject matter concerned a high-profile cracking case in the
news. (That mail was later distributed to crackers' groups across the
Internet.)
In any event, MasterPlan can help to identify these patterns, at least with
respect to finger queries. The utility is small, and easily unpacked and
configured. The C source is included, and the distribution is known to
compile cleanly on most UNIX systems. (The exceptions are reportedly Ultrix
and the NeXT platform.) One nice amenity for Linux users is that a
pre-compiled binary comes with the distribution. The standard distribution
of MasterPlan is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z
The Linux compiled version is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z
As you've now seen, the finger utility is dangerous and revealing. More and
more sites are now disabling finger services, at least with respect to
external queries. For various reasons, however, many providers simply do
not bother to shut it down.
TIP: If you want to see an example of mapping an IP address to a
username dynamically, trying fingering ppp@wizard.com. This host has
apparently aliased out the PPP connections so that the entire list of
users connected via PPP can be examined using the finger command. Thus,
if you receive a message from a user in that domain, but the user
obscured his e-mail address, it could still be culled using the finger
command. By fingering the entire block of current PPP addresses, you can
map the IP to a username and from there, finger the username. By going
through this process, you can easily obtain the e-mail address of a
user in that domain, even if he is trying to hide.
Note that MasterPlan will not prevent someone from fingering you; it will
simply identify that party and how many times the finger request has been
issued.
But all this assumes that your provider allows finger requests from the void.
Suppose for a moment that it doesn't. Does this mean that you are safe and
that you shouldn't worry about your name being revealed? Hardly. It simply
means that a standard finger query will fail to render any information about
you.
Suppose that someone is attempting to finger you and discovers that finger
requests from the void are prohibited. Suppose further that this person is
determined to find your real name and is willing to risk an angry message
from your provider to his own. In such a case, the nosy party will initiate
a Telnet session to your provider's mail server. (This is done by initiating
a Telnet request to port 25.)
In most cases (except those where the provider is paranoid or running a
firewall), a server will accept a Telnet connection to port 25 (the port
that sendmail runs on). Such a connection looks like this:
220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800
TIP: The preceding piece of a started Telnet session was initiated on a
Solaris 2.5 SPARC station 20. Different flavors of UNIX will provide
different strings at the beginning of the session. However, almost all
reveal the operating system and version number.
If the nosy party can get to such a prompt, there is better than an 80
percent chance that he will have your name momentarily. The information is
collected by issuing the following command:
expn username
This command requests that the mail package expand a username into an e-mail
address and real name. This is a feature (not a bug) of the sendmail package.
The response will typically expand into something similar to
username <username@target_of_probe.com> Real Name
The first field will report back the username or user ID that you request to
be expanded. This will be followed by the person's e-mail address and finally,
his "real" name.
Note that the expn function can be disabled by the system administrator,
although few actually do it. There are reasons for this, and the most
probable is that administrators simply fear fiddling with the sendmail
configuration. Sendmail is a notoriously complex and powerful program that
has evolved into a huge package. There are so many options for it that an
entire book could be written just on its configuration. It is for this reason,
no doubt, that sendmail has consistently been the source of holes in Internet
security. So you might wonder why the program is even used at all. That is
easy to explain. Sendmail is the most successful program for transport of
electronic mail ever created. Millions of users all over the world send
mail each day using this program.
In any event, if the expn function is operable, the nosy individual will
still get your real name, if it is available. Unfortunately, even if the
expn function has been disabled, the snooping party can still verify the
existence of your account using the vrfy function. This is academic, however;
if your provider's sendmail system honors Telnet sessions, there is a
greater than 70 percent chance that one or both of these functions is
available.
TIP: You will find that many other versions of sendmail-- which has now
been ported to almost every platform-- will also render this information.
Currently, other than rewriting your account so that your real name does not
appear in the /etc/passwd database, there is no way for you to exercise
control over these remote functions. sendmail issues must be resolved by
root. Moreover, it is highly unlikely that a system administrator will
fiddle with his or her sendmail configuration just to satisfy the needs of
a paranoid user. Thus, the rule of thumb is this: If you intend to remain
untouchable on the Net, you must never, ever allow your real name to fill
that field within the /etc/passwd file.
A Few Words About Cookies
You have seen the message many times. You land on a WWW site and a dialog
box appears. The server at the other end says it wants to set a cookie.
Most users have no idea what this means, so they simply click the OK button
and continue. Other users actually read the dialog box's contents and get a
little worried. (This is especially true when the cookie is going to be set
for sometime into the year 2000. The user may not be sure what a cookie is,
but almost all users balk when that cookie is going to hang around for 3 or
4 years.)
TIP: If you have never seen such a dialog box, you need to set your
options to warn you before cookies are being set. Personally, I prefer
to at least be notified when anything is being written to my hard disk
drive. You should watch all such activities closely, monitoring any
code or other device that is arbitrarily forwarded to your machine.
What are cookies? The cookie concept is very much like getting your hand
stamped at a dance club. You can roam the club, have some drinks, dance,
and even go outside to your car for a few minutes. As long as the stamp is
on your hand, you will not have to pay again, nor will your access be
restricted. But cookies go much further than this. They record specific
information about the user, so when that user returns to the page, the
information (known as state information) can be retrieved. The issue
concerning cookies, though, isn't that the information is retrieved.
The controversy is about where the information is retrieved from: your
hard disk drive.
Cookies (which Netscape calls persistent client state HTTP cookies) are now
primarily used to store options about each user as he browses a page. The
folks at Netscape explain it this way:
This simple mechanism provides a powerful new tool which enables a host
of new types of applications to be written for Web-based environments.
Shopping applications can now store information about the currently
selected items, for fee services can send back registration information
and free the client from retyping a user-id on next connection, sites
can store per-user preferences on the client, and have the client
supply those preferences every time that site is connected to.
Cross Reference: The article from which the previous quote is excerpted,
"Persistent Client State HTTP Cookies," can be found at
*home.netscape.com/newsref/std/cookie_spec.html.
To understand the way cookies work, please examine Figure 13.4.
Figure 13.4.
Setting cookies.
As you can see, when the remote server is contacted, it requests permission
to set a cookie. (One wonders why some sites set a cookie on their opening
page. Just what state information are they recording? You haven't specified
any preferences yet, so there is essentially nothing to record.) Prior to
the setting of the cookie, however, the user is generally confronted with
the advisory shown in Figure 13.5.
Figure 13.5.
Cookie warning!
TIP: Note that this advisory will only be shown if you choose this
option (Warn on Cookie) in your preferences. In Netscape Navigator,
this option can be toggled in the Network Preferences menu under the
Protocols tab. In Microsoft Internet Explorer, it can be set in the
Options menu under the Advanced tab.
Advocates of cookies insist that they are harmless, cannot assist in
identifying the user, and are therefore benign. That is not true, as
explained by D. Kristol and L. Montulli in RFC 2109:
An origin server could create a Set-Cookie header to track the path of
a user through the server. Users may object to this behavior as an
intrusive accumulation of information, even if their identity is not
evident.(Identity might become evident if a user subsequently fills out
a form that contains identifying information.)
I know many programmers who are exploring techniques for using cookies for
user authentication. This is disturbing. There has not been enough scrutiny
of the privacy issues surrounding cookies, and there needs to be some method
developed to manage them. That is, perhaps some cookies are desirable to a
particular user and some are not. The user may visit certain sites regularly.
If those sites use cookie conventions, the user will unnecessarily be
confronted with a cookie warning each time he visits, unless that cookie
remains on the drive. However, other cookies (from sites that the user may
never visit again) should be easily removed. This is also discussed in
RFC 2109:
User agents should allow the user to control cookie destruction. An
infrequently used cookie may function as a "preferences file" for
network applications, and a user may wish to keep it even if it is the
least-recently-used cookie. One possible implementation would be an
interface that allows the permanent storage of a cookie through a
checkbox (or, conversely, its immediate destruction).
Briefly, to find the cookies on your hard disk drive, search for the file
cookies.txt. This file will contain a list of cookies and their values.
It looks like this:
www.webspan.net FALSE /~frys FALSE 859881600 worldohackf 2.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID
1000e010,107ea15f.adobe.com TRUE / FALSE 946684799 INTERSE 207.171.18.182 6852855142083822www.ictnet.com FALSE / FALSE 946684799 Apache pm3a-4326561855491810745.microsoft.com TRUE / FALSE 937422000
MC1 GUID=260218f482a111d0889e08002bb74f65.msn.com TRUE / FALSE 937396800 MC1 ID=260218f482a111d0889e08002bb74f65comsecltd.com FALSE / FALSE 1293753600 EGSOFT_ID 207.171.18.176-3577227984.29104071
.amazon.com TRUE / FALSE 858672000 session-id-time 855894626.amazon.com TRUE / FALSE 858672000 session-id 0738-6510633-772498
This cookie file is a real one, pulled from an associate's hard disk drive.
You will see that under the GUID, the leading numbers are an IP address.
(I have added a space between the IP address and the remaining portion of
the string so that you can easily identify the IP. In practice, however, the
string is unbroken.) From this, you can see clearly that setting a cookie
may involve recording IP addresses from the target. Now, this does not mean
that cookies are a major threat to your privacy. Many JavaScript scripts
(and Perl scripts) are designed to "get" your IP. This type of code also
can get your browser type, your operating system, and so forth. Following
is an example in JavaScript:
<script language=javascript>
function Get_Browser() {
var appName = navigator.appName;
var appVersion = navigator.appVersion;
document.write(appName + " " + appVersion.substring (0,appVersion.indexOf(" ")));
}
</script>
This JavaScript code will get the browser and its version. Scripts like this
are used at thousands of sites across the Internet. A very popular one is
the "Book 'em, Dan-O" script. This script (written in the Perl programming
language) will get the time, the browser, the browser's version, and the
user's IP.
Cross Reference: The "Book 'em, Dan-O" script was written by an
individual named Spider. It is currently available for download at
Matt's Script Archive, at
*worldwidemart.com/scripts/dano.shtml.
Cross Reference: One site that will get many of your environment
variables, particularly if you use UNIX, is located at
*hoohoo.ncsa.uiuc.edu/cgi-bin/test-env. What is interesting is
that it will catch both the PPP-based address
(as in ppp32-vn074.provider.com) as well as your actual IP.
Also, nearly all Web server packages log access anyway. For example,
NCSA HTTPD provides an access log. In it, the IP address of the requesting
party is logged. The format of the file looks like this:
- - [12/Feb/1997:17:20:59 -0800] "GET /~user/index.html i HTTP/1.0" 200 449
The major difference between these devices and the cookie implementation,
however, is that cookies are written to a file on your hard disk drive.
Many users may not be bothered by this, and in reality, there is nothing
threatening about this practice. For example, a cookie can only be read by
the server that set it. However, I do not accept cookies as a rule, no
matter how persistent the server may be at attempting to set one.
(Some programmers provide for this process on every page, hoping that
eventually the user will tire of dealing with dialog boxes and simply
allow the cookie to be set.)
It is interesting to note that some clients have not been preconfigured to
deny cookies. In these instances, a cookie may be written to the drive
without the user's consent, which is really the default configuration, even
for those browsers that support screening of cookies. Early versions of both
Netscape Navigator and Microsoft Internet Explorer shipped with the Deny
Cookies checkbox unchecked. Absentmindedness on the part of the vendors?
Perhaps. If you have a problem denying cookies, for whatever reason, there
is an action you can undertake to prevent these items from being written to
your drive. One is to make the file cookies.txt read-only. Thus, when a
foreign Web server attempts to write to the file, it will fail.
TIP: It has been reported that this can be done in MacOS by first
deleting and then re-creating the cookie file and subsequently
placing it into the Preferences folder.
I recommend denying cookies, not so much because they are an invasion,
but because they leave a trail on your own hard disk drive. That is, if you
visit a page that you have been forbidden to access and it sets a cookie,
the evidence will be in cookies.txt. This breaks down to cache issues as
well: even if your cookies file is clean, your cache will betray you.
NOTE: Although this is a well-known issue, new users may not be aware
of it, so I will explain. To retrieve the sites you have most recently
visited, type about:cache in the Open Location box in Netscape's
Navigator. A new page will appear, showing Web pages you have recently
visited. So, if you browse the Net at work when you are supposed to be
performing your duties, you will want to kill that cache every few
minutes or set its value to 0.
Currently, denying a cookie does not dramatically influence your ability to
access a page, although that may change in the future. At best, the cookie
issue has assisted in heightening public awareness that a remote Web server
can cull your IP address and, in certain instances, your location, your
operating system, your browser, and so forth.
NOTE: If you are uncomfortable with denying cookies from all sites,
perhaps you should check out a program called Cookie Jar. Cookie Jar
allows you to specify what servers you will accept cookies from. The
program was written by Eric Murray, a member of the Sams technical
editorial team. Cookie Jar is located at
*www.lne.com/ericm/cookie_jar/. The main amenity of Cookie Jar is
convenience. Many sites require that you accept a cookie to access
certain services. Cookie Jar can perform filtering for you.
Public Postings
We will now assume that no one knows who you are. They are about to find out,
however, because you are about to post a message to a Usenet newsgroup.
From the moment you post a message to Usenet, your name and e-mail address
are fair game.
The Usenet news network is somewhat different from other forms of
communication on the Internet. For a start, it is almost entirely public,
with a very few exceptions. Moreover, many Usenet news newsgroups are
archived--that is, the articles posted to such groups are bundled and
stored for later use. I have seen archived messages ranging back to 1992,
some of which are reachable by WAIS, FTP, Telnet, and other, antiquated
interfaces.
TIP: Note that these are private archives and have nothing to do with
search engines. The big search engines generally archive Usenet
messages for a few weeks only. In contrast, private archives (maintained
by non-commercial, special interest groups), especially those that have
listservers in addition to newsgroups, may be maintained for a long,
long time.
Because these messages are kept, your e-mail address (and identity, because
your identity can be traced with it) has a shelf life. Hucksters like list
brokers routinely tap such archives, searching for leads--collections of
e-mail addresses of persons who share a particular interest, such as all
females over 40 years of age who smoke a pipe, have an eye patch, and voted
Republican in the last election. If you think that this level of refinement
is ludicrous, think again. Applying various search spiders (and a number of
personal robots), one can narrow the search to something that specific.
The first step in developing such a list is to capture e-mail addresses. To
do this, any garden-variety search engine will do, although AltaVista
(altavista.digital.com) and DejaNews (www.dejanews.com) have the most
malleable designs. Even though these engines are well known to most users,
I am providing screen captures of their top-level pages, primarily for
reference purposes as I explain Usenet snooping.
Figure 13.6.
The top-level page of AltaVista.
AltaVista is one of the most powerful search engines available on the
Internet and is provided as a public service by Digital Equipment Corporation
(DEC). It accepts various types of queries that can be directed toward WWW
pages (HTML) or Usenet postings. (The Usenet postings are archived, actually.
However, DEC reports that these are kept only for a period of "a few weeks.")
One key point about the AltaVista engine is that it was coded nicely. By
enclosing strings in quotation marks, you can force a case-sensitive, exact
regex (regular expression) match. As a result, you can isolate one page out
of millions that contains the exact string you're seeking. Similarly, you can
isolate all Usenet postings made by a particular author. By taking each of
those postings and analyzing them, you can identify that person's chief
interests. (Perhaps the person is a militia member, for example.)
The DejaNews search engine is a very specialized tool. It is solely a Usenet
robot/spider. The DejaNews archive reportedly goes back to March 1995, and
the management indicates that it is constantly trying to fill gaps and get
older articles into the database. It claims that it is working on providing
all articles posted since 1979. Figure 13.7 shows the top page of DejaNews.
Figure 13.7.
The top-level page of DejaNews.
DejaNews has some more advanced functions for indexing, as well.
For example, you can automatically build a profile on the author of a
Usenet article. (That is, the engine will produce a list of newsgroups
that the target has posted to recently.)
Defeating the archiving of your Usenet messages on both AltaVista and
DejaNews is relatively simple--for direct posting, at least. Either in
the X headers of your Usenet article or as the first line of your article,
issue the following string:
x-no-archive: yes
This will ensure that your direct postings made to Usenet will not be
archived. This does not, however, protect you from third-party postings
that contain your e-mail address. For example, if you belong to a mailing
list and that list is archived somewhere on the WWW (or even at FTP sites),
your e-mail address is already compromised. If your e-mail address appears
in a thread of significant interest (and your reply was sufficiently
enlightening), it is guaranteed that the entire thread (which contains your
address) will be posted somewhere. And it will be somewhere other than Usenet;
perhaps a WWW page or a Gopher server.
Let us continue to suppose that you have no knowledge of how Usenet indexing
works. Let us further assume that although your real name does not appear on
Usenet postings, it does appear in the /etc/passwd file on the UNIX server
that you use as a gateway to the Internet. Now you are a viable target. Here
are some steps that will lead the snooping party not simply to your real name,
but to the front door of your home. The steps are as follows:
1. The snooping party sees your post to Usenet. Your e-mail address
is in plain view, but your name is not.
2. The snooping party tries to finger your address, but as it happens,
your provider prohibits finger requests from the void.
3. The snooping party Telnets to port 25 of your server. There, he
issues the expn command and obtains your real name.
Having gotten that information, the snooping party next needs to find the
state in which you currently reside. For this, he turns to the WHOIS service.
The WHOIS Service
The WHOIS service (centrally located at rs.internic.net) contains the domain
registration records of all Internet sites. This registration database
contains detailed information on each Internet site, including domain name
server addresses, technical contacts, the telephone number, and the address.
Here is a WHOIS request result on the provider Netcom, a popular Northern
California Internet service provider:
NETCOM On-Line Communication Services, Inc (NETCOM-DOM)
3031 Tisch Way, Lobby Level
San Jose, California 95128
US
Domain Name: NETCOM.COM
Administrative Contact:
NETCOM Network Management (NETCOM-NM) dns-mgr@NETCOM.COM
(408) 983-5970
Technical Contact, Zone Contact:
NETCOM DNS Administration (NETCOM-DNS) dns-tech@NETCOM.COM
(408) 983-5970
Record last updated on 03-Jan-97.
Record created on 01-Feb-91.
Domain servers in listed order:
NETCOMSV.NETCOM.COM 192.100.81.101
NS.NETCOM.COM 192.100.81.105
AS3.NETCOM.COM 199.183.9.4
Here, the snooping party has discovered that the provider is in the state
of California. (Note the location at the top of the WHOIS return listing,
as well as the telephone points of contact for the technical personnel.)
This information will help tremendously; the snooping party now proceeds
to *www.worldpages.com/. WorldPages is a massive database with a
design very similar to the average White Pages. It holds the names, e-mail
addresses, and telephone numbers of several million Internet users.
(See Figure 13.8 for a screenshot of the top-level page of WorldPages.)
Figure 13.8.
The top-level page of WorldPages.
At WorldPages, the snooping party funnels your real name through a search
engine, specifying the state as California. Momentarily, he is confronted
with a list of matches that provide name, address, and telephone number.
Here, he may run into some trouble, depending on how common your name is.
If your name is John Smith, the snooping party will have to do further
research. However, let us assume that your name is not John Smith. Let's
assume that your name is common, but not that common. So the snooping party
uncovers three addresses, each in a different California city: One is in
Sacramento, one is in Los Angeles, and one is in San Diego. How does he
determine which one is really you? He proceeds to the host utility.
The host utility (discussed briefly in Chapter 9, "Scanners") will list all
the machines on a given network and their relative locations. With large
networks, it is common for a provider to have machines sprinkled at various
locations throughout a state. The host command can identify which workstations
are located where. In other words, it is generally trivial to obtain a listing
of workstations by city. These workstations are sometimes even named for the
cities in which they are deposited. Therefore, you may see an entry such as
chatsworth1.target_provider.com
Chatsworth is a city in southern California. From this entry, we can assume
that chatsworth1.target_provider.com is located within the city of Chatsworth.
What remains for the snooper is to reexamine your Usenet post.
By examining the source code of your Usenet post, he can view the path the
message took. That path will look something like this:
news2.cais.com!in1.nntp.cais.net!feed1.news.erols.com!howland.erols.net! Âix.netcom.com!news
By examining this path, the snooping party can determine which server was
used to post the article. This information is then coupled with the value
for the NNTP posting host:
grc-ny4-20.ix.netcom.com
The snooping party extracts the name of the posting server (the first entry
along the path). This is almost always expressed in its name state and not
by its IP address. For the snooping party to complete the process, however,
the IP address is needed. Therefore, he next Telnets to the posting host.
When the Telnet session is initiated, the hard, numeric IP is retrieved
from DNS and printed to STDOUT. The snooping party now has the IP address
of the machine that accepted the original posting. This IP address is then
run against the outfile obtained by the host query. This operation reveals
the city in which the machine resides.
TIP: If this information does not exactly match, the snooping party can
employ other methods to get the location of the posting machine. One
such technique is to issue a Traceroute request. When tracing the route
to a machine that exists in another city, the route must invariably take
a path through certain gateways. These are main switching points through
which all traffic passes when going in or out of a city. Usually, these
are high-level points, operated by telecommunication companies like MCI,
Sprint, and so forth. Most have city names within their address.
Bloomington and Los Angeles are two well-known points. Thus, even if
the reconciliation of the posting machine's name fails against the host
outfile, a Traceroute will reveal the approximate location of the
machine.
Having obtained this information (and having now differentiated you from the
other names), he returns to WorldPages and chooses your name. Within seconds,
a graphical map of your neighborhood appears. The exact location of your home
is marked on the map by a circle. The snooping party now knows exactly where
you live and how to get there. From this point, he can begin to gather more
interesting information about you. For example:
The snooping party can determine your status as a registered voter and
your political affiliations. He obtains this information at
*www.wdia.com/lycos/voter-records.htm.
From federal election records online, he can determine which
candidates you support and how much you have contributed. He gets
this information from
*www.tray.com/fecinfo/zip.htm.
He can also get your Social Security number and date of birth. This
information is available at
*kadima.com/.
Many users are not bothered by this. Among those people, the prevailing
attitude is that all such information is available through sources other
than the Internet. The problem is that the Internet brings these sources of
information together. Integration of such information allows this activity
to be conducted on a wholesale basis, and that's where the trouble begins.
It is now possible (using the techniques described here) to build models of
human networks--that is, it is now possible to identify all members of a
particular class. It is also possible to analyze the relationships between
them. This changes the perspective for intelligence agencies.
Years ago, gathering domestic intelligence was a laborious process. It
required some element, however slim, of human intelligence. (Human
intelligence here refers to the use of human beings to gather information
as opposed to machines or other, automated processes.) Thus, to get the
low-down on the Students for a Democratic Society, for example, intelligence
agencies had to send agents on foot. These agents had to mix with the crowd,
record license plate numbers, or gather names at a rally. Today, those
methods are no longer necessary.
Today, the Internet provides a superb tool to monitor the public sentiment
(and perhaps to identify those who conspire to take up arms). In some
respects, one might concede that this is good. Certainly, if individuals
are discussing violence or crime, and they contemplate these issues online,
it seems suitable that law-enforcement agencies can take advantage of this
emerging technology. However, it should be recognized here that the practice
of building models of human networks via the Internet violates no law. It
amounts to free spying, without a warrant. Put more bluntly, we Americans
do often have big mouths. Some of us would do better to keep quiet.
Before I continue, I want to make one point clear: Complete anonymity on the
Internet is possible, but not legally. Given enough time, for example,
authorities could trace a message posted via anonymous remailer (although,
if that message were chained through several remailers, the task would be
far more complex). The problem is in the design of the Internet itself. As
Ralf Hauser and Gene Tsudik note in their article "On Shopping Incognito":
From the outset the nature of current network protocols and applications
runs counter to privacy. The vast majority have one thing in common:
they faithfully communicate end-point identification information.
`End-point' in this context can denote a user (with a unique ID), a
network address or an organization name. For example, electronic mail
routinely communicates sender's address in the header. File transfer
(e.g., FTP), remote login (e.g. Telnet), and hypertext browsers
(e.g. WWW) expose addresses, host names and IDs of their users.
Indeed, the process starts at the very moment of connection. For example,
workstations connected to a network that is directly wired to the Net all
have permanent addressing schemes. Certainly, an Ethernet spoof will not
carry when crossing the bridge to IP; therefore, fixed stations permanently
strung to the Internet will always have the same IP. And, short of the
operator of such a workstation getting root access (and altering the
routing tables), there is little that can be done in this regard.
Similarly, the average user's IP is dependent solely upon his server.
Consider the exchange that occurs in a dial-up account. (See Figure 13.9.)
Figure 13.9.
A little case study: dynamic IP allocation.
Most servers are now running some form of dynamic IP allocation. This is a
very simple but innovative system. Examine the Ethernet arrangement to the
right of Figure 13.9 (a garden-variety rack of headless workstations).
Each machine on that network can allocate a certain number of IP addresses.
Let's make it simple and say that each workstation can allocate 254 of them.
Think of each address as a spoke in a bicycle wheel. Let's also assume that
the IP address for one of these boxes is 199.171.180.2 (this is an imaginary
address). If no one is logged on, we say that the available addresses (on
that box) range from 199.171.180.3 to 199.171.180.255.
As long as only a portion of these address are occupied, additional addresses
will be allocated. However, what if they are all allocated? In that case, the
first one to be disengaged will be the next available IP. That is, suppose
they are all allocated and you currently occupy 199.171.180.210. As soon as
you disconnect (and if no one else does before the next call), the very next
customer will be allocated the address 199.171.180.210. It is a free slot
(left free because you have disconnected), and the next caller grabs it.
The spokes of the wheel are again fully occupied.
TIP: In practice, the process is more complex, involving more hardware
and so forth. However, here we are just concerned with the address
allocation, so I have greatly simplified the process.
This demonstrates that in dynamic IP allocation, you will likely have a
different address each time you connect. Many individuals who run illegal
BBS systems on the Internet take advantage of this phenomenon.
NOTE: The term illegal here refers to those BBS systems that distribute
unlawful software. This does not have to be warez (pirated software)
either. Certain types of cellular cloning software, for example, are
unlawful to possess. Distribution of such software will bring the
authorities to your door. Likewise, "illegal" BBS activity can be where
the operator and members engage in cracking while logged on. Lastly,
those BBS systems that distribute child pornography are, quite
obviously, illegal.
The dynamic allocation allows users to perform a little parlor trick of sorts.
Because the IP is different each time, an illegal BBS can be a moving target.
That is, even if law-enforcement officials suspect the activity being
undertaken, they are not sure where it is happening without further research.
Typically, this type of setup involves the perpetrators using a networked
operating system (almost always Linux or FreeBSD) that allows remote logins.
(These logins may include FTP, Telnet, Gopher, and so on. It is also fairly
common to see at least sparse HTTP activity, although it is almost always
protected using htpasswd.) It is also common for the operator of such a
board to request that users use SSH, S/Key, or some other, secure
remote-login software so that third parties cannot snoop the activity there.
Typically, the operator connects using the networked operating system and,
after having determined the IP for the night, he mails out the network
address to the members of the group. (This is usually an automated process,
run through a Perl script or some other shell language.) The mailed message
need be no more than a blank one, because all that is important is the source
address.
For the brief period that this BBS is connected, it effectively serves as a
shadowed server in the void. No one would know of its existence unless they
scanned for it. Most often, the operator will kill both finger and the r
services, therefore blocking the prying eyes of third parties from determining
who is logged to the server. Moreover, the operator has usually gained some
privileged access to his provider's network and, having done so, can obscure
his presence in system logs.
For the individuals in these groups, relative anonymity is realized because,
even if an outside party later questions the sysad of the provider, the logs
may be very sparse. Most system administrators are reluctant to kill an
account without adequate proof. True, the logs at any outside network would
show some activity and the IP it originated from, but that is not enough.
If the system administrator cannot say with certainty who perpetrated the
activity, he has no case. Meanwhile, during the period when users are
logged in to this hidden server, they, at least, are shielded in terms of
identity. They can then Telnet back out of that machine (or connect to IRC)
and from there, they have some level of shielding. But what about the
average Joe?
The average user does not implement such schemes. He connects using mostly
client software, on the IBM or Mac platform, and is not looking to provide
services. The difference is considerable. Certainly, anyone using the
configuration described here has more options with regard to sending, say,
fakemail. Because that person controls the server (and the sendmail
application is local), even a simple message sent from the console will
appear differently from one sent from a Windows client. Such a message
cannot be trusted, and only by reviewing the full headers can you
reliably determine where it came from.
TIP: You will recall that in Chapter 9, I discussed this point.
The technique for identifying the source of fakemail involves using
Traceroute. Generally, the second-to-last listing in the Traceroute
results will reveal the actual source. In other words, the
second-to-last line will reveal the provider network, and from that you
can deduce that the user was at least temporarily connected to that
server. A discussion with the sysad at that location should give you
the username--providing, of course, that you can convince the sysad
that there is a reason for him to release such information.
My point is this: During the period when a shadowed server is up, those who
log in from the void are safe and hidden, but only as long as the operator
of the box refuses to provide their identities.
For example, say a kid establishes such a box in California. His friends
from Philadelphia connect to the box and use it as a launching pad. From
there, the folks from Philadelphia Telnet back out and begin cracking some
server in the void. Our boy in California may later have to answer for this
activity. However, if he has erased his logs (and keeps his mouth shut), the
people from Philadelphia will never be found. Which leads to this advice: If
you run such a server, never, ever allow individuals you do not know to use
it. When you destroy the logs, you are sealing your own fate. These
individuals are using an IP address that can be traced to you (unless you
have root access on your provider's box). Thus, if you meet someone on IRC
and he begs you for a shell account, it is best that you refuse until you
know him. Otherwise, it is you and not he who will suffer.
At any rate, because of the inherent design of the Internet, the IP address
is a universal identification index. It has to be, because without it, how
could information be routed across the network? Therefore, be advised that
although you may change your mail address in Netscape Navigator or other
programs containing mail packages, this does not obscure your identity.
True, inexperienced users will be dumbfounded as to the origin of the
message, but anyone familiar with UNIX can trace the message right to its
source.
I imagine that the majority of my readers are not criminals and simply want
to keep their name out of Usenet screens or mailing lists. However, for
those inclined to break the law (who are scouring this chapter for that one,
single answer), I say this: To totally shield yourself from the law (and
other, interested parties), you will need these items:
A cloned cellular telephone or other means of initiating a digital
connection (seizing a circuit, perhaps)
A laptop (loaded with either FreeBSD or Linux)
Credit card numbers stolen from a clean source
A PCICMA modem
A reason for all this
Certain individuals are available for hire to perform various crimes over
the Internet. When they conduct their activity, this is how they do it. The
credit card numbers are usually bought outright from an underground, or a
"clean," source; one that law enforcement can neither readily identify or
reach. Most of these are on microfiche, taken from a financial institution
or other source that has a quantity of numbers. (Note that only those
individuals who are doing high-volume work will buy microfiche. This is
because using microfiche-based numbers is in itself a risk. Later analysis
by law enforcement will reveal that sets of numbers used may have or appear
to have originated from the same source.)
Those involved in this activity generally explain that banks are poor sources
for the numbers, as are Internet service providers, car rental agencies, and
retail chains. It is argued that the best source is from mail-order lists or
department store databases. These are the reasons:
These lists contain many different types of credit cards, not just one.
These card numbers belong to accounts that are underwritten by many
institutions, not just one.
The rightful owners of such credit cards live at locations sprinkled
throughout the United States; therefore, the activity initially
appears to be unconnected.
Law-enforcement agents will initially be dumbfounded as to the seed
source of the numbers, for all these reasons.
Having obtained the numbers, the next step is to choose a provider. Most
individuals who do this on a regular basis have lists of providers that
allow "instant access," where you provide your vitals, your credit card,
your desired login, your password, and so forth. Within minutes, you are
surfing the Net.
Using this technique, you can reliably obtain total anonymity for short
periods of time, periods long enough to perform the desired task. The only
hope that authorities have of catching you is to elicit corroborative
testimony of a coconspirator, or if you establish a pattern of activity
--for example, if spend your nights breaking into machines owned or operated
by security specialists who are also talented hackers.
NOTE: I have not suggested here that any reader undertake the action
described here. If you do so, you do it at your own peril. These
actions amount to crime--or, in fact, a series of crimes. Here, I
have merely explained one technique, and no more. Neither I nor Sams
Publishing advocate, support, or condone such activity.
F
that all users wanted to be found. No one had reason to hide, and it seemed
sensible that researchers should be able to locate each other. Utilities
were therefore created to facilitate such finding.
Since those early days, the rise of multiple protocols has made finding
people even more convenient. As you will see later in this chapter, the old
days demanded a high level of networking knowledge from the user. Today,
finding or identifying most individuals is trivial. Throughout this chapter,
I examine those techniques, as well as some concepts about wholesale tracing
(tracing many individuals at one time).
You may wonder why this is deemed a security issue.
In truth, it really isn't--not yet. As you read this chapter, however, you
will learn that the Internet is a powerful tool for domestic spying.
Law-enforcement and intelligence agencies already conduct such practices on
the Internet, and for them, the Network is a bonanza. No search warrant is
needed to "study" the activity of someone on the Internet. Likewise, no
warrant is needed to compile lists of individuals who law enforcement
perceive to be involved in illegal (or even seditious) activity. This is not
a joke. If you harbor radical political views, by the end of this chapter,
you may elect to forever keep those views to yourself (or gain a decent
education in cryptography).
Before I begin, I need to make one statement regarding screenshots and
diagnostic network information contained within this chapter. Certain
methods of finding individuals demand the use of search engines.
Unfortunately, to my knowledge, the law has not been adequately settled
regarding the reprinting of an individual's e-mail address without his
consent. Because of this, I cannot provide screenshots of searches because
they necessarily contain the e-mail addresses of users unknown.
Therefore, the searches have to be described rather than illustrated. I do
apologize for this. However, upon reflection, I would not want my e-mail
address published, and I see no reason why anyone else would, either. The
argument is often made that anyone who posts to a Usenet newsgroups has at
least given an implied form of consent. I do not support that view. So, I am
afraid that we shall have to get along as best we can by description as
opposed to screenshot. I have taken pains to explain each step carefully
to provide the utmost clarity. I hope that will suffice.
So, let us begin at the beginning, at the heart of your server. We will
start at home base and work our way outward.
What's in a Name?
There are two forms of user identification that apply to all platforms:
your e-mail address and your IP address. It is often theorized that if one
is obscured, the other can never be found. That is untrue. Without chaining
messages through a series of trusted anonymous remailers (remailers that are
purportedly secure), anonymity on the Internet is virtually impossible.
Anonymous remailers are discussed in Chapter 7,
"Birth of a Network: The Internet."
It is possible, however, to make yourself relatively invisible, and that is
probably what most individuals would like to do. Before I get more specific,
however, there are some utilities you need to know about, as well as methods
of tracing individuals. I'll start with finger.
finger
The finger service is a utility common to the UNIX platform. Its purpose is
to provide information about users on a given system. In practical operation,
finger works like most other services available in UNIX. Figure 13.1
demonstrates the use of Finger32, a popular finger client for the Microsoft
Windows platform.
Figure 13.1.
The finger query process.
Cross Reference: Finger32 is a small application port of the UNIX
utility finger. It is available here:
ftp://hyper.net.au/Win95nt-apps/Finger/Wsfinger/Wsfngr32.zip
The finger service relies on the client/server model, which is a recurring
theme in Internet applications. This model works as follows: machines
running server applications distribute information to clients. Clients are
programs designed to accept and interpret information from server
applications. For example, you use a Web browser (or client) to read
information forwarded by a Web server (the HTTP server).
In any event, the finger client-server relationship works as follows:
On the targeted machine (almost always a UNIX system), there is a server
running called fingerd. This is more commonly referred to as the finger
daemon. Its purpose is to answer requests from finger clients from the void.
The finger daemon can return different information, depending largely on the
configuration of the server and the user's personalized settings. For
example, sometimes an "open" UNIX server (that is, one not running a firewall)
will disallow finger access. This is done by disabling the finger daemon,
removing it from the file /etc/inetd.conf. In this case, the finger service
is never started. Any client-issued finger request forwarded to such a
machine will meet with a blank response (or perhaps, Connection Refused.).
Many organizations, particularly ISPs, government sites, and private
corporations, disable finger services. Each has an interest in preserving
the privacy of its users, and that is usually the reason given for disabling
the service. As you will learn later, however, their motivation may also be
system security.
TIP: Certain vital information about the system can be culled by
fingering system IDs such as root, bin, FTP, and so on. On that account,
some sites will disable finger services altogether. It is thought that
by killing the finger and RPC services, one can restrict the amount of
revealing information available to crackers in the void. To some
extent, this is true.
Cross Reference: An excellent paper written by Dan Farmer and
Wietse Venema addresses this issue:
"Improving the Security of Your Site by Breaking Into It." The
paper is so widely distributed on the Internet. Here is a very
reliable source:
*www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html.
(This is a government site, so with all probability, this link will
be good for many years to come.)
Some sites do not disable finger services altogether, but instead put
restrictions on what type of information can be accessed. For example,
by default, the finger daemon allows a systemwide finger. Anyone can be
fingered, including special or privileged accounts. When systemwide fingering
is allowed, one can gather information on all users currently logged to the
machine. This is done by issuing the following command at a UNIX command
prompt:
finger @my_target_host.com
The @ symbol has essentially the same effect as the asterisk does in regular
expression searches. When it is used, the user is fingering all users
currently logged to the target machine. This is most useful when targeting
small providers that have few customers, or when conducting such a finger
query late at night. Certainly, fingering a company as large as Netcom in
this manner would be foolish. (The response forwarded by the server would
likely be many pages in length. The only valid reason for doing this would
be to generate a database of Netcom users.) At any rate, some organizations
will disallow such a request, instead forcing the requesting party to specify
a particular user.
Other sites make use of hacked finger daemons, either created in-house or
available as distributions from other sites across the Internet. These are
finger daemons that have enhanced features, including advanced configuration
options.
Cross Reference: One such hacked finger daemon is the Configurable
Finger Daemon, or cfingerd. Written by Ken Hollis, cfingerd
provides security functions not available in garden-variety finger
servers. It is considered to be an excellent replacement to the
standard distribution of finger. It is available free of charge at
ftp://ftp.bitgate.com/pub/cfingerd/.
Cross Reference: For more generalized understanding of the finger
daemon process, I suggest viewing the source for any public-domain
finger client. There is a nice online resource for this at
*araneus.york.ac.uk/owtwaww/finger.htm.
At any rate, taking you through the process of a finger inquiry will take
just a few moments, but in order for you to exploit the example, you need
a finger client. UNIX users, however, have no need for a finger client,
because this is included in the basic distribution. The same is true of
Windows NT. So this little section is primarily for Windows, Mac, and
OS/2 users. The finger clients are listed in Table 13.1.
Table 13.1. Finger clients for non-UNIX, non-NT users.
Platform
Client
Location
Windows
(All)
WSFinger
ftp://papa.indstate.edu/winsock-l/finger/wsfngr14.zip
Macintosh
Macfinger
ftp://ftp.global.net.id/pub/mac/internet/finger-15.hqx
OS/2
FFEU
*www.musthave.com/OS2/ftp/ffeu101.zip
For demonstration purposes, I will use Finger32, a popular finger application
for Windows 95. The application is simple to use; it presents the user with a
self-explanatory screen from which you choose your host. (See Figure 13.2.)
Figure 13.2.
The Finger32 opening screen--choosing a host.
When you choose this option, a dialog box appears, requesting a host and
username. (See Figure 13.3.)
Figure 13.3.
Specifying your target.
Providing the target is running a finger server, the return output should
read something like this:
Login name: root In real life: 0000-Admin(0000)
Directory: / Shell: /sbin/sh
Last login Tue Feb 18 19:53 on pts/22
New mail received Wed Feb 19 04:05:58 1997;
unread since Wed Feb 19 03:20:43 1997
No Plan.
This tells you several things, including the directory where root@samshack
resides (/), the shell he or she is using (/sbin/sh), and some details on
last login and mail. (Hard-core hackers will know that it also tells you
that root@samshack.com is using Solaris as an operating system. Note the
0000-Admin[0000] string.)
This information does not appear to be particularly revealing; however,
in 70% of all cases, the field In real life is filled with a name. Worse
still, at some universities, you can get the name, telephone number, dorm
room number, and major of students enrolled there (not that the major
matters particularly, but it provides some interesting background).
The information available on a finger query is controlled primarily by the
system administrator of a given site, as well as what information you provide
on your initial signup. Most new users are not aware of this and provide all
the information they can. Most people have no reason to hide, and many
provide their office telephone number or even their home address. It is
human nature to be mostly honest, especially when the entity they are
providing information to seems benign.
So the process of identification usually either starts or ends with a finger
query. As noted previously, the finger query uses your e-mail address as an
index. This leads us immediately into an area of some controversy. Some
individuals believe that by changing their e-mail address in the Netscape
Navigator or Microsoft Internet Explorer Options panels, they obscure their
identity. This is not true. It simply makes your e-mail address more
difficult to obtain. I will get to this subject momentarily. For now, I want
to continue with finger, offering a little folklore. The following is a
classic Internet story. (If you've ever fingered coke@cs.cmu.edu, skip these
next few paragraphs.)
Years ago, the computer science department staff at Carnegie-Mellon
University had a gripe about their Coke machine. Often, staffers would
venture down to the basement, only to find an empty machine. To remedy this
problem, they rigged the machine, connecting it to the Internet (apparently,
they did this by wiring the machine to a DEC 3100). They could then issue a
finger request and determine the following things:
How many sodas were in each slot
What those sodas were--Coke, Diet Coke, Sprite, and so on
Whether the available sodas were cold
Today, you can still issue a finger request to the Coke machine at CMU.
If you were to do so, you would receive output very similar to the following:
[ Forwarding coke as "coke@l.gp.cs.cmu.edu" ]
[L.GP.CS.CMU.EDU]
Login: coke Name: Drink Coke
Directory: /usr/coke Shell: /usr/local/bin/tcsh
Last login Sun Feb 16 18:17 (EST) on ttyp1 from GS84.SP.CS.CMU.EDU
Mail came on Tue Feb 18 14:25, last read on Tue Feb 18 14:25
Plan:
M & M Coke Buttons
/----\ C: CCCCCCCCCCC.............
|?????| C: CCCCCCCC.... D: CCCCCCCCCC..
|?????| C: CCCCCCCCCCCC D: CCCCCCCC....
|?????| C: CCCCCCCC.... D: CCCCCCCCC...
|?????| C: C...........
\----/ S: C...........
| Key:
| 0 = warm; 9 = 90% cold; C = cold; . = empty
| Beverages: C = Coke, D = Diet Coke, S = Sprite
| Leftmost soda/pop will be dispensed next
--^-- M&M status guessed.
Coke status heuristics fit data.
Status last updated Wed Feb 19 00:20:17 1997
As you can see, there is no end to the information available with a finger
query. The story of this Coke machine was told by Terence Parr, President
and Lead Mage of MageLang Institute (*www.magelang.com/), at the 1996
Netscape Developer's Conference at Moscone Center in San Francisco.
Reportedly, Parr was demonstrating a Java application that could emulate
this Coke machine hack when suddenly, a former CMU student, Michael Adler,
rose to the occasion. Adler explained the hack in detail, having firsthand
knowledge of the Coke machine in question. In fact, Adler was largely
responsible for adding the temperature index function.
At any rate, many administrators insist on supporting finger, and some have
legitimate reasons. For example, a finger server allows easy distribution of
information. In order for the finger server to support this functionality,
the targeted user (or alias) must have a plan file. (The Coke machine at
CMU certainly does!) This file is discussed in the next section.
The Plan File (.plan)
On most UNIX servers, user directories are kept beneath the /home/ or /usr
directory hierarchies. For example, a user with a username of cracker will
have his home directory in /home/cracker. (This is not set in stone. System
administrators are responsible for where such directories are kept. They
could specify this location as anywhere on the drive, but the typical
placement is /usr or /home.)
Typically, in that home directory are a series of special files that are
created when the user accesses his account for the first time. For example,
the first time he utilizes the mail program Pine, a series of files are
established, including .pinerc, which is the configuration file for this mail
client.
These files are referred to as dot files, because they are preceded by a
period. Most dot files are created automatically. The .plan file, however,
is not. The user must create this file himself, using any text editor
(for example, vi or pico). This file can be closely correlated with
the plan.txt file on a VAX system. Its purpose is to print user-specified
information whenever that user becomes the target of a finger query. So,
if the user saves into the .plan file a text recounting his life history, that
text will be printed to the STDOUT of the party requesting finger information.
The .plan file is one way that information can be distributed via the finger
server. (Note that you, the user, must create that .plan file. This is not
automatically generated by anyone else.) If you examine Figure 13.1 again,
this will seem a bit clearer.
TIP: You may have encountered servers or users that suggest that you
Finger for more info. Usually, this entails issuing a finger request to
an address like info@targethost.com. Most often, the information you
receive (which could be pages of plain text) comes from the .plan file.
There are other reasons that some administrators keep the finger service
operational. Entire programs can be launched by specifying a particular
address to be fingered. In other words, one could (although it is not
recommended) distribute text files this way. For example, you could write an
event handler to trap finger queries aimed at a particular user; if user A
were fingered, the server would send a specified text file to the requesting
party. I have seen more than one server configured this way, although it is
more common to see mail lists designed in this manner.
For whatever reason, then, finger services may be running on the server at
which you have an account. If you have never bothered to check what
information is available there, you can check now by issuing a finger
request to your own account. You can also examine this information (the
majority of it, anyway) by issuing the following command at a shell prompt:
grep your_username /etc/passwd
TIP: This technique will only work on servers that use non-shadowed
password files, or those that are not employing NIS. In those
instances, you may have to issue a command more like this:
ypcat passwd || cat /etc/passwd | grep user_name
This command will print the information the server holds on you in the
/etc/passwd file. Note that this information will be visible even if the
server makes use of shadowed password entries.
So now you know: The names of the majority of Net citizens are there for
the taking. If your system administrator insists on using finger, there
are several things you can do to minimize your exposure:
Use the popular utility chfn to alter the finger information available
to outsiders
If chfn is not available, request that the sysad change your information
Cancel your current account and start a new one
NOTE: If you believe in harsh solutions and you want to discourage
people from repeatedly fingering your account, write a .plan file
that forwards a few megabytes of garbage. This is most useful if
your sysad refuses to assist, chfn is unavailable, and some joker is
trying to clock your movements using finger.
Of course, perhaps you are not concerned with being fingered as much as you
are concerned with who is doing the fingering. If so, you need MasterPlan.
MasterPlan
MasterPlan is an excellent utility. Written by Laurion Burchall and released
in August 1994, this product takes an aggressive approach to protecting your
privacy. First and foremost, MasterPlan identifies who is trying to finger
you. Each time a finger query is detected, MasterPlan attempts to get the
hostname and user ID of the fingering party. These variables are piped to
an outfile called finger_log. MasterPlan will also determine how often you
are fingered, so you can easily detect if someone is trying to clock you.
(Clocking refers to the practice where user A attempts to discern
the habits of user B using various network utilities, including finger and
the r commands.)
TIP: The r commands consist of a suite of network utilities that can
glean information about users on remote hosts. I will discuss one of
these, a utility called rusers, in a moment.
Typically, a cracker writes a shell or Perl script to finger (or otherwise
query) the target every specified number of minutes or hours. Reasons for
such probing can be diverse. One is to build a profile of the target; for
example, when does the user log in? How often does the user check mail? From
where does the user usually log in? From these queries, a cracker (or other
nosy party) can determine other possible points on the network where the
user can be found.
Consider this example: A cracker I know was attempting to intercept e-mail
trafficked by a nationally renowned female journalist who covers hacking
stories. This journalist had more than one account and frequently logged
into one from another. (In other words, rather than directly logging in,
she would chain her connections.) This is a common practice by individuals
in the public eye. They may want to hide from overly enthusiastic fans
(or perhaps even legitimate foes). Thus, they preserve at least one account
to receive public mail and another to receive private mail.
By running a probing script on the journalist, the cracker was able to
identify her private e-mail address. He was also able to compromise that
network and ultimately capture all the journalist's mail. The mail was
primarily discussions between the journalist and a software engineer in
England. The subject matter concerned a high-profile cracking case in the
news. (That mail was later distributed to crackers' groups across the
Internet.)
In any event, MasterPlan can help to identify these patterns, at least with
respect to finger queries. The utility is small, and easily unpacked and
configured. The C source is included, and the distribution is known to
compile cleanly on most UNIX systems. (The exceptions are reportedly Ultrix
and the NeXT platform.) One nice amenity for Linux users is that a
pre-compiled binary comes with the distribution. The standard distribution
of MasterPlan is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z
The Linux compiled version is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z
As you've now seen, the finger utility is dangerous and revealing. More and
more sites are now disabling finger services, at least with respect to
external queries. For various reasons, however, many providers simply do
not bother to shut it down.
TIP: If you want to see an example of mapping an IP address to a
username dynamically, trying fingering ppp@wizard.com. This host has
apparently aliased out the PPP connections so that the entire list of
users connected via PPP can be examined using the finger command. Thus,
if you receive a message from a user in that domain, but the user
obscured his e-mail address, it could still be culled using the finger
command. By fingering the entire block of current PPP addresses, you can
map the IP to a username and from there, finger the username. By going
through this process, you can easily obtain the e-mail address of a
user in that domain, even if he is trying to hide.
Note that MasterPlan will not prevent someone from fingering you; it will
simply identify that party and how many times the finger request has been
issued.
But all this assumes that your provider allows finger requests from the void.
Suppose for a moment that it doesn't. Does this mean that you are safe and
that you shouldn't worry about your name being revealed? Hardly. It simply
means that a standard finger query will fail to render any information about
you.
Suppose that someone is attempting to finger you and discovers that finger
requests from the void are prohibited. Suppose further that this person is
determined to find your real name and is willing to risk an angry message
from your provider to his own. In such a case, the nosy party will initiate
a Telnet session to your provider's mail server. (This is done by initiating
a Telnet request to port 25.)
In most cases (except those where the provider is paranoid or running a
firewall), a server will accept a Telnet connection to port 25 (the port
that sendmail runs on). Such a connection looks like this:
220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800
TIP: The preceding piece of a started Telnet session was initiated on a
Solaris 2.5 SPARC station 20. Different flavors of UNIX will provide
different strings at the beginning of the session. However, almost all
reveal the operating system and version number.
If the nosy party can get to such a prompt, there is better than an 80
percent chance that he will have your name momentarily. The information is
collected by issuing the following command:
expn username
This command requests that the mail package expand a username into an e-mail
address and real name. This is a feature (not a bug) of the sendmail package.
The response will typically expand into something similar to
username <username@target_of_probe.com> Real Name
The first field will report back the username or user ID that you request to
be expanded. This will be followed by the person's e-mail address and finally,
his "real" name.
Note that the expn function can be disabled by the system administrator,
although few actually do it. There are reasons for this, and the most
probable is that administrators simply fear fiddling with the sendmail
configuration. Sendmail is a notoriously complex and powerful program that
has evolved into a huge package. There are so many options for it that an
entire book could be written just on its configuration. It is for this reason,
no doubt, that sendmail has consistently been the source of holes in Internet
security. So you might wonder why the program is even used at all. That is
easy to explain. Sendmail is the most successful program for transport of
electronic mail ever created. Millions of users all over the world send
mail each day using this program.
In any event, if the expn function is operable, the nosy individual will
still get your real name, if it is available. Unfortunately, even if the
expn function has been disabled, the snooping party can still verify the
existence of your account using the vrfy function. This is academic, however;
if your provider's sendmail system honors Telnet sessions, there is a
greater than 70 percent chance that one or both of these functions is
available.
TIP: You will find that many other versions of sendmail-- which has now
been ported to almost every platform-- will also render this information.
Currently, other than rewriting your account so that your real name does not
appear in the /etc/passwd database, there is no way for you to exercise
control over these remote functions. sendmail issues must be resolved by
root. Moreover, it is highly unlikely that a system administrator will
fiddle with his or her sendmail configuration just to satisfy the needs of
a paranoid user. Thus, the rule of thumb is this: If you intend to remain
untouchable on the Net, you must never, ever allow your real name to fill
that field within the /etc/passwd file.
A Few Words About Cookies
You have seen the message many times. You land on a WWW site and a dialog
box appears. The server at the other end says it wants to set a cookie.
Most users have no idea what this means, so they simply click the OK button
and continue. Other users actually read the dialog box's contents and get a
little worried. (This is especially true when the cookie is going to be set
for sometime into the year 2000. The user may not be sure what a cookie is,
but almost all users balk when that cookie is going to hang around for 3 or
4 years.)
TIP: If you have never seen such a dialog box, you need to set your
options to warn you before cookies are being set. Personally, I prefer
to at least be notified when anything is being written to my hard disk
drive. You should watch all such activities closely, monitoring any
code or other device that is arbitrarily forwarded to your machine.
What are cookies? The cookie concept is very much like getting your hand
stamped at a dance club. You can roam the club, have some drinks, dance,
and even go outside to your car for a few minutes. As long as the stamp is
on your hand, you will not have to pay again, nor will your access be
restricted. But cookies go much further than this. They record specific
information about the user, so when that user returns to the page, the
information (known as state information) can be retrieved. The issue
concerning cookies, though, isn't that the information is retrieved.
The controversy is about where the information is retrieved from: your
hard disk drive.
Cookies (which Netscape calls persistent client state HTTP cookies) are now
primarily used to store options about each user as he browses a page. The
folks at Netscape explain it this way:
This simple mechanism provides a powerful new tool which enables a host
of new types of applications to be written for Web-based environments.
Shopping applications can now store information about the currently
selected items, for fee services can send back registration information
and free the client from retyping a user-id on next connection, sites
can store per-user preferences on the client, and have the client
supply those preferences every time that site is connected to.
Cross Reference: The article from which the previous quote is excerpted,
"Persistent Client State HTTP Cookies," can be found at
*home.netscape.com/newsref/std/cookie_spec.html.
To understand the way cookies work, please examine Figure 13.4.
Figure 13.4.
Setting cookies.
As you can see, when the remote server is contacted, it requests permission
to set a cookie. (One wonders why some sites set a cookie on their opening
page. Just what state information are they recording? You haven't specified
any preferences yet, so there is essentially nothing to record.) Prior to
the setting of the cookie, however, the user is generally confronted with
the advisory shown in Figure 13.5.
Figure 13.5.
Cookie warning!
TIP: Note that this advisory will only be shown if you choose this
option (Warn on Cookie) in your preferences. In Netscape Navigator,
this option can be toggled in the Network Preferences menu under the
Protocols tab. In Microsoft Internet Explorer, it can be set in the
Options menu under the Advanced tab.
Advocates of cookies insist that they are harmless, cannot assist in
identifying the user, and are therefore benign. That is not true, as
explained by D. Kristol and L. Montulli in RFC 2109:
An origin server could create a Set-Cookie header to track the path of
a user through the server. Users may object to this behavior as an
intrusive accumulation of information, even if their identity is not
evident.(Identity might become evident if a user subsequently fills out
a form that contains identifying information.)
I know many programmers who are exploring techniques for using cookies for
user authentication. This is disturbing. There has not been enough scrutiny
of the privacy issues surrounding cookies, and there needs to be some method
developed to manage them. That is, perhaps some cookies are desirable to a
particular user and some are not. The user may visit certain sites regularly.
If those sites use cookie conventions, the user will unnecessarily be
confronted with a cookie warning each time he visits, unless that cookie
remains on the drive. However, other cookies (from sites that the user may
never visit again) should be easily removed. This is also discussed in
RFC 2109:
User agents should allow the user to control cookie destruction. An
infrequently used cookie may function as a "preferences file" for
network applications, and a user may wish to keep it even if it is the
least-recently-used cookie. One possible implementation would be an
interface that allows the permanent storage of a cookie through a
checkbox (or, conversely, its immediate destruction).
Briefly, to find the cookies on your hard disk drive, search for the file
cookies.txt. This file will contain a list of cookies and their values.
It looks like this:
www.webspan.net FALSE /~frys FALSE 859881600 worldohackf 2.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID
1000e010,107ea15f.adobe.com TRUE / FALSE 946684799 INTERSE 207.171.18.182 6852855142083822www.ictnet.com FALSE / FALSE 946684799 Apache pm3a-4326561855491810745.microsoft.com TRUE / FALSE 937422000
MC1 GUID=260218f482a111d0889e08002bb74f65.msn.com TRUE / FALSE 937396800 MC1 ID=260218f482a111d0889e08002bb74f65comsecltd.com FALSE / FALSE 1293753600 EGSOFT_ID 207.171.18.176-3577227984.29104071
.amazon.com TRUE / FALSE 858672000 session-id-time 855894626.amazon.com TRUE / FALSE 858672000 session-id 0738-6510633-772498
This cookie file is a real one, pulled from an associate's hard disk drive.
You will see that under the GUID, the leading numbers are an IP address.
(I have added a space between the IP address and the remaining portion of
the string so that you can easily identify the IP. In practice, however, the
string is unbroken.) From this, you can see clearly that setting a cookie
may involve recording IP addresses from the target. Now, this does not mean
that cookies are a major threat to your privacy. Many JavaScript scripts
(and Perl scripts) are designed to "get" your IP. This type of code also
can get your browser type, your operating system, and so forth. Following
is an example in JavaScript:
<script language=javascript>
function Get_Browser() {
var appName = navigator.appName;
var appVersion = navigator.appVersion;
document.write(appName + " " + appVersion.substring (0,appVersion.indexOf(" ")));
}
</script>
This JavaScript code will get the browser and its version. Scripts like this
are used at thousands of sites across the Internet. A very popular one is
the "Book 'em, Dan-O" script. This script (written in the Perl programming
language) will get the time, the browser, the browser's version, and the
user's IP.
Cross Reference: The "Book 'em, Dan-O" script was written by an
individual named Spider. It is currently available for download at
Matt's Script Archive, at
*worldwidemart.com/scripts/dano.shtml.
Cross Reference: One site that will get many of your environment
variables, particularly if you use UNIX, is located at
*hoohoo.ncsa.uiuc.edu/cgi-bin/test-env. What is interesting is
that it will catch both the PPP-based address
(as in ppp32-vn074.provider.com) as well as your actual IP.
Also, nearly all Web server packages log access anyway. For example,
NCSA HTTPD provides an access log. In it, the IP address of the requesting
party is logged. The format of the file looks like this:
- - [12/Feb/1997:17:20:59 -0800] "GET /~user/index.html i HTTP/1.0" 200 449
The major difference between these devices and the cookie implementation,
however, is that cookies are written to a file on your hard disk drive.
Many users may not be bothered by this, and in reality, there is nothing
threatening about this practice. For example, a cookie can only be read by
the server that set it. However, I do not accept cookies as a rule, no
matter how persistent the server may be at attempting to set one.
(Some programmers provide for this process on every page, hoping that
eventually the user will tire of dealing with dialog boxes and simply
allow the cookie to be set.)
It is interesting to note that some clients have not been preconfigured to
deny cookies. In these instances, a cookie may be written to the drive
without the user's consent, which is really the default configuration, even
for those browsers that support screening of cookies. Early versions of both
Netscape Navigator and Microsoft Internet Explorer shipped with the Deny
Cookies checkbox unchecked. Absentmindedness on the part of the vendors?
Perhaps. If you have a problem denying cookies, for whatever reason, there
is an action you can undertake to prevent these items from being written to
your drive. One is to make the file cookies.txt read-only. Thus, when a
foreign Web server attempts to write to the file, it will fail.
TIP: It has been reported that this can be done in MacOS by first
deleting and then re-creating the cookie file and subsequently
placing it into the Preferences folder.
I recommend denying cookies, not so much because they are an invasion,
but because they leave a trail on your own hard disk drive. That is, if you
visit a page that you have been forbidden to access and it sets a cookie,
the evidence will be in cookies.txt. This breaks down to cache issues as
well: even if your cookies file is clean, your cache will betray you.
NOTE: Although this is a well-known issue, new users may not be aware
of it, so I will explain. To retrieve the sites you have most recently
visited, type about:cache in the Open Location box in Netscape's
Navigator. A new page will appear, showing Web pages you have recently
visited. So, if you browse the Net at work when you are supposed to be
performing your duties, you will want to kill that cache every few
minutes or set its value to 0.
Currently, denying a cookie does not dramatically influence your ability to
access a page, although that may change in the future. At best, the cookie
issue has assisted in heightening public awareness that a remote Web server
can cull your IP address and, in certain instances, your location, your
operating system, your browser, and so forth.
NOTE: If you are uncomfortable with denying cookies from all sites,
perhaps you should check out a program called Cookie Jar. Cookie Jar
allows you to specify what servers you will accept cookies from. The
program was written by Eric Murray, a member of the Sams technical
editorial team. Cookie Jar is located at
*www.lne.com/ericm/cookie_jar/. The main amenity of Cookie Jar is
convenience. Many sites require that you accept a cookie to access
certain services. Cookie Jar can perform filtering for you.
Public Postings
We will now assume that no one knows who you are. They are about to find out,
however, because you are about to post a message to a Usenet newsgroup.
From the moment you post a message to Usenet, your name and e-mail address
are fair game.
The Usenet news network is somewhat different from other forms of
communication on the Internet. For a start, it is almost entirely public,
with a very few exceptions. Moreover, many Usenet news newsgroups are
archived--that is, the articles posted to such groups are bundled and
stored for later use. I have seen archived messages ranging back to 1992,
some of which are reachable by WAIS, FTP, Telnet, and other, antiquated
interfaces.
TIP: Note that these are private archives and have nothing to do with
search engines. The big search engines generally archive Usenet
messages for a few weeks only. In contrast, private archives (maintained
by non-commercial, special interest groups), especially those that have
listservers in addition to newsgroups, may be maintained for a long,
long time.
Because these messages are kept, your e-mail address (and identity, because
your identity can be traced with it) has a shelf life. Hucksters like list
brokers routinely tap such archives, searching for leads--collections of
e-mail addresses of persons who share a particular interest, such as all
females over 40 years of age who smoke a pipe, have an eye patch, and voted
Republican in the last election. If you think that this level of refinement
is ludicrous, think again. Applying various search spiders (and a number of
personal robots), one can narrow the search to something that specific.
The first step in developing such a list is to capture e-mail addresses. To
do this, any garden-variety search engine will do, although AltaVista
(altavista.digital.com) and DejaNews (www.dejanews.com) have the most
malleable designs. Even though these engines are well known to most users,
I am providing screen captures of their top-level pages, primarily for
reference purposes as I explain Usenet snooping.
Figure 13.6.
The top-level page of AltaVista.
AltaVista is one of the most powerful search engines available on the
Internet and is provided as a public service by Digital Equipment Corporation
(DEC). It accepts various types of queries that can be directed toward WWW
pages (HTML) or Usenet postings. (The Usenet postings are archived, actually.
However, DEC reports that these are kept only for a period of "a few weeks.")
One key point about the AltaVista engine is that it was coded nicely. By
enclosing strings in quotation marks, you can force a case-sensitive, exact
regex (regular expression) match. As a result, you can isolate one page out
of millions that contains the exact string you're seeking. Similarly, you can
isolate all Usenet postings made by a particular author. By taking each of
those postings and analyzing them, you can identify that person's chief
interests. (Perhaps the person is a militia member, for example.)
The DejaNews search engine is a very specialized tool. It is solely a Usenet
robot/spider. The DejaNews archive reportedly goes back to March 1995, and
the management indicates that it is constantly trying to fill gaps and get
older articles into the database. It claims that it is working on providing
all articles posted since 1979. Figure 13.7 shows the top page of DejaNews.
Figure 13.7.
The top-level page of DejaNews.
DejaNews has some more advanced functions for indexing, as well.
For example, you can automatically build a profile on the author of a
Usenet article. (That is, the engine will produce a list of newsgroups
that the target has posted to recently.)
Defeating the archiving of your Usenet messages on both AltaVista and
DejaNews is relatively simple--for direct posting, at least. Either in
the X headers of your Usenet article or as the first line of your article,
issue the following string:
x-no-archive: yes
This will ensure that your direct postings made to Usenet will not be
archived. This does not, however, protect you from third-party postings
that contain your e-mail address. For example, if you belong to a mailing
list and that list is archived somewhere on the WWW (or even at FTP sites),
your e-mail address is already compromised. If your e-mail address appears
in a thread of significant interest (and your reply was sufficiently
enlightening), it is guaranteed that the entire thread (which contains your
address) will be posted somewhere. And it will be somewhere other than Usenet;
perhaps a WWW page or a Gopher server.
Let us continue to suppose that you have no knowledge of how Usenet indexing
works. Let us further assume that although your real name does not appear on
Usenet postings, it does appear in the /etc/passwd file on the UNIX server
that you use as a gateway to the Internet. Now you are a viable target. Here
are some steps that will lead the snooping party not simply to your real name,
but to the front door of your home. The steps are as follows:
1. The snooping party sees your post to Usenet. Your e-mail address
is in plain view, but your name is not.
2. The snooping party tries to finger your address, but as it happens,
your provider prohibits finger requests from the void.
3. The snooping party Telnets to port 25 of your server. There, he
issues the expn command and obtains your real name.
Having gotten that information, the snooping party next needs to find the
state in which you currently reside. For this, he turns to the WHOIS service.
The WHOIS Service
The WHOIS service (centrally located at rs.internic.net) contains the domain
registration records of all Internet sites. This registration database
contains detailed information on each Internet site, including domain name
server addresses, technical contacts, the telephone number, and the address.
Here is a WHOIS request result on the provider Netcom, a popular Northern
California Internet service provider:
NETCOM On-Line Communication Services, Inc (NETCOM-DOM)
3031 Tisch Way, Lobby Level
San Jose, California 95128
US
Domain Name: NETCOM.COM
Administrative Contact:
NETCOM Network Management (NETCOM-NM) dns-mgr@NETCOM.COM
(408) 983-5970
Technical Contact, Zone Contact:
NETCOM DNS Administration (NETCOM-DNS) dns-tech@NETCOM.COM
(408) 983-5970
Record last updated on 03-Jan-97.
Record created on 01-Feb-91.
Domain servers in listed order:
NETCOMSV.NETCOM.COM 192.100.81.101
NS.NETCOM.COM 192.100.81.105
AS3.NETCOM.COM 199.183.9.4
Here, the snooping party has discovered that the provider is in the state
of California. (Note the location at the top of the WHOIS return listing,
as well as the telephone points of contact for the technical personnel.)
This information will help tremendously; the snooping party now proceeds
to *www.worldpages.com/. WorldPages is a massive database with a
design very similar to the average White Pages. It holds the names, e-mail
addresses, and telephone numbers of several million Internet users.
(See Figure 13.8 for a screenshot of the top-level page of WorldPages.)
Figure 13.8.
The top-level page of WorldPages.
At WorldPages, the snooping party funnels your real name through a search
engine, specifying the state as California. Momentarily, he is confronted
with a list of matches that provide name, address, and telephone number.
Here, he may run into some trouble, depending on how common your name is.
If your name is John Smith, the snooping party will have to do further
research. However, let us assume that your name is not John Smith. Let's
assume that your name is common, but not that common. So the snooping party
uncovers three addresses, each in a different California city: One is in
Sacramento, one is in Los Angeles, and one is in San Diego. How does he
determine which one is really you? He proceeds to the host utility.
The host utility (discussed briefly in Chapter 9, "Scanners") will list all
the machines on a given network and their relative locations. With large
networks, it is common for a provider to have machines sprinkled at various
locations throughout a state. The host command can identify which workstations
are located where. In other words, it is generally trivial to obtain a listing
of workstations by city. These workstations are sometimes even named for the
cities in which they are deposited. Therefore, you may see an entry such as
chatsworth1.target_provider.com
Chatsworth is a city in southern California. From this entry, we can assume
that chatsworth1.target_provider.com is located within the city of Chatsworth.
What remains for the snooper is to reexamine your Usenet post.
By examining the source code of your Usenet post, he can view the path the
message took. That path will look something like this:
news2.cais.com!in1.nntp.cais.net!feed1.news.erols.com!howland.erols.net! Âix.netcom.com!news
By examining this path, the snooping party can determine which server was
used to post the article. This information is then coupled with the value
for the NNTP posting host:
grc-ny4-20.ix.netcom.com
The snooping party extracts the name of the posting server (the first entry
along the path). This is almost always expressed in its name state and not
by its IP address. For the snooping party to complete the process, however,
the IP address is needed. Therefore, he next Telnets to the posting host.
When the Telnet session is initiated, the hard, numeric IP is retrieved
from DNS and printed to STDOUT. The snooping party now has the IP address
of the machine that accepted the original posting. This IP address is then
run against the outfile obtained by the host query. This operation reveals
the city in which the machine resides.
TIP: If this information does not exactly match, the snooping party can
employ other methods to get the location of the posting machine. One
such technique is to issue a Traceroute request. When tracing the route
to a machine that exists in another city, the route must invariably take
a path through certain gateways. These are main switching points through
which all traffic passes when going in or out of a city. Usually, these
are high-level points, operated by telecommunication companies like MCI,
Sprint, and so forth. Most have city names within their address.
Bloomington and Los Angeles are two well-known points. Thus, even if
the reconciliation of the posting machine's name fails against the host
outfile, a Traceroute will reveal the approximate location of the
machine.
Having obtained this information (and having now differentiated you from the
other names), he returns to WorldPages and chooses your name. Within seconds,
a graphical map of your neighborhood appears. The exact location of your home
is marked on the map by a circle. The snooping party now knows exactly where
you live and how to get there. From this point, he can begin to gather more
interesting information about you. For example:
The snooping party can determine your status as a registered voter and
your political affiliations. He obtains this information at
*www.wdia.com/lycos/voter-records.htm.
From federal election records online, he can determine which
candidates you support and how much you have contributed. He gets
this information from
*www.tray.com/fecinfo/zip.htm.
He can also get your Social Security number and date of birth. This
information is available at
*kadima.com/.
Many users are not bothered by this. Among those people, the prevailing
attitude is that all such information is available through sources other
than the Internet. The problem is that the Internet brings these sources of
information together. Integration of such information allows this activity
to be conducted on a wholesale basis, and that's where the trouble begins.
It is now possible (using the techniques described here) to build models of
human networks--that is, it is now possible to identify all members of a
particular class. It is also possible to analyze the relationships between
them. This changes the perspective for intelligence agencies.
Years ago, gathering domestic intelligence was a laborious process. It
required some element, however slim, of human intelligence. (Human
intelligence here refers to the use of human beings to gather information
as opposed to machines or other, automated processes.) Thus, to get the
low-down on the Students for a Democratic Society, for example, intelligence
agencies had to send agents on foot. These agents had to mix with the crowd,
record license plate numbers, or gather names at a rally. Today, those
methods are no longer necessary.
Today, the Internet provides a superb tool to monitor the public sentiment
(and perhaps to identify those who conspire to take up arms). In some
respects, one might concede that this is good. Certainly, if individuals
are discussing violence or crime, and they contemplate these issues online,
it seems suitable that law-enforcement agencies can take advantage of this
emerging technology. However, it should be recognized here that the practice
of building models of human networks via the Internet violates no law. It
amounts to free spying, without a warrant. Put more bluntly, we Americans
do often have big mouths. Some of us would do better to keep quiet.
Before I continue, I want to make one point clear: Complete anonymity on the
Internet is possible, but not legally. Given enough time, for example,
authorities could trace a message posted via anonymous remailer (although,
if that message were chained through several remailers, the task would be
far more complex). The problem is in the design of the Internet itself. As
Ralf Hauser and Gene Tsudik note in their article "On Shopping Incognito":
From the outset the nature of current network protocols and applications
runs counter to privacy. The vast majority have one thing in common:
they faithfully communicate end-point identification information.
`End-point' in this context can denote a user (with a unique ID), a
network address or an organization name. For example, electronic mail
routinely communicates sender's address in the header. File transfer
(e.g., FTP), remote login (e.g. Telnet), and hypertext browsers
(e.g. WWW) expose addresses, host names and IDs of their users.
Indeed, the process starts at the very moment of connection. For example,
workstations connected to a network that is directly wired to the Net all
have permanent addressing schemes. Certainly, an Ethernet spoof will not
carry when crossing the bridge to IP; therefore, fixed stations permanently
strung to the Internet will always have the same IP. And, short of the
operator of such a workstation getting root access (and altering the
routing tables), there is little that can be done in this regard.
Similarly, the average user's IP is dependent solely upon his server.
Consider the exchange that occurs in a dial-up account. (See Figure 13.9.)
Figure 13.9.
A little case study: dynamic IP allocation.
Most servers are now running some form of dynamic IP allocation. This is a
very simple but innovative system. Examine the Ethernet arrangement to the
right of Figure 13.9 (a garden-variety rack of headless workstations).
Each machine on that network can allocate a certain number of IP addresses.
Let's make it simple and say that each workstation can allocate 254 of them.
Think of each address as a spoke in a bicycle wheel. Let's also assume that
the IP address for one of these boxes is 199.171.180.2 (this is an imaginary
address). If no one is logged on, we say that the available addresses (on
that box) range from 199.171.180.3 to 199.171.180.255.
As long as only a portion of these address are occupied, additional addresses
will be allocated. However, what if they are all allocated? In that case, the
first one to be disengaged will be the next available IP. That is, suppose
they are all allocated and you currently occupy 199.171.180.210. As soon as
you disconnect (and if no one else does before the next call), the very next
customer will be allocated the address 199.171.180.210. It is a free slot
(left free because you have disconnected), and the next caller grabs it.
The spokes of the wheel are again fully occupied.
TIP: In practice, the process is more complex, involving more hardware
and so forth. However, here we are just concerned with the address
allocation, so I have greatly simplified the process.
This demonstrates that in dynamic IP allocation, you will likely have a
different address each time you connect. Many individuals who run illegal
BBS systems on the Internet take advantage of this phenomenon.
NOTE: The term illegal here refers to those BBS systems that distribute
unlawful software. This does not have to be warez (pirated software)
either. Certain types of cellular cloning software, for example, are
unlawful to possess. Distribution of such software will bring the
authorities to your door. Likewise, "illegal" BBS activity can be where
the operator and members engage in cracking while logged on. Lastly,
those BBS systems that distribute child pornography are, quite
obviously, illegal.
The dynamic allocation allows users to perform a little parlor trick of sorts.
Because the IP is different each time, an illegal BBS can be a moving target.
That is, even if law-enforcement officials suspect the activity being
undertaken, they are not sure where it is happening without further research.
Typically, this type of setup involves the perpetrators using a networked
operating system (almost always Linux or FreeBSD) that allows remote logins.
(These logins may include FTP, Telnet, Gopher, and so on. It is also fairly
common to see at least sparse HTTP activity, although it is almost always
protected using htpasswd.) It is also common for the operator of such a
board to request that users use SSH, S/Key, or some other, secure
remote-login software so that third parties cannot snoop the activity there.
Typically, the operator connects using the networked operating system and,
after having determined the IP for the night, he mails out the network
address to the members of the group. (This is usually an automated process,
run through a Perl script or some other shell language.) The mailed message
need be no more than a blank one, because all that is important is the source
address.
For the brief period that this BBS is connected, it effectively serves as a
shadowed server in the void. No one would know of its existence unless they
scanned for it. Most often, the operator will kill both finger and the r
services, therefore blocking the prying eyes of third parties from determining
who is logged to the server. Moreover, the operator has usually gained some
privileged access to his provider's network and, having done so, can obscure
his presence in system logs.
For the individuals in these groups, relative anonymity is realized because,
even if an outside party later questions the sysad of the provider, the logs
may be very sparse. Most system administrators are reluctant to kill an
account without adequate proof. True, the logs at any outside network would
show some activity and the IP it originated from, but that is not enough.
If the system administrator cannot say with certainty who perpetrated the
activity, he has no case. Meanwhile, during the period when users are
logged in to this hidden server, they, at least, are shielded in terms of
identity. They can then Telnet back out of that machine (or connect to IRC)
and from there, they have some level of shielding. But what about the
average Joe?
The average user does not implement such schemes. He connects using mostly
client software, on the IBM or Mac platform, and is not looking to provide
services. The difference is considerable. Certainly, anyone using the
configuration described here has more options with regard to sending, say,
fakemail. Because that person controls the server (and the sendmail
application is local), even a simple message sent from the console will
appear differently from one sent from a Windows client. Such a message
cannot be trusted, and only by reviewing the full headers can you
reliably determine where it came from.
TIP: You will recall that in Chapter 9, I discussed this point.
The technique for identifying the source of fakemail involves using
Traceroute. Generally, the second-to-last listing in the Traceroute
results will reveal the actual source. In other words, the
second-to-last line will reveal the provider network, and from that you
can deduce that the user was at least temporarily connected to that
server. A discussion with the sysad at that location should give you
the username--providing, of course, that you can convince the sysad
that there is a reason for him to release such information.
My point is this: During the period when a shadowed server is up, those who
log in from the void are safe and hidden, but only as long as the operator
of the box refuses to provide their identities.
For example, say a kid establishes such a box in California. His friends
from Philadelphia connect to the box and use it as a launching pad. From
there, the folks from Philadelphia Telnet back out and begin cracking some
server in the void. Our boy in California may later have to answer for this
activity. However, if he has erased his logs (and keeps his mouth shut), the
people from Philadelphia will never be found. Which leads to this advice: If
you run such a server, never, ever allow individuals you do not know to use
it. When you destroy the logs, you are sealing your own fate. These
individuals are using an IP address that can be traced to you (unless you
have root access on your provider's box). Thus, if you meet someone on IRC
and he begs you for a shell account, it is best that you refuse until you
know him. Otherwise, it is you and not he who will suffer.
At any rate, because of the inherent design of the Internet, the IP address
is a universal identification index. It has to be, because without it, how
could information be routed across the network? Therefore, be advised that
although you may change your mail address in Netscape Navigator or other
programs containing mail packages, this does not obscure your identity.
True, inexperienced users will be dumbfounded as to the origin of the
message, but anyone familiar with UNIX can trace the message right to its
source.
I imagine that the majority of my readers are not criminals and simply want
to keep their name out of Usenet screens or mailing lists. However, for
those inclined to break the law (who are scouring this chapter for that one,
single answer), I say this: To totally shield yourself from the law (and
other, interested parties), you will need these items:
A cloned cellular telephone or other means of initiating a digital
connection (seizing a circuit, perhaps)
A laptop (loaded with either FreeBSD or Linux)
Credit card numbers stolen from a clean source
A PCICMA modem
A reason for all this
Certain individuals are available for hire to perform various crimes over
the Internet. When they conduct their activity, this is how they do it. The
credit card numbers are usually bought outright from an underground, or a
"clean," source; one that law enforcement can neither readily identify or
reach. Most of these are on microfiche, taken from a financial institution
or other source that has a quantity of numbers. (Note that only those
individuals who are doing high-volume work will buy microfiche. This is
because using microfiche-based numbers is in itself a risk. Later analysis
by law enforcement will reveal that sets of numbers used may have or appear
to have originated from the same source.)
Those involved in this activity generally explain that banks are poor sources
for the numbers, as are Internet service providers, car rental agencies, and
retail chains. It is argued that the best source is from mail-order lists or
department store databases. These are the reasons:
These lists contain many different types of credit cards, not just one.
These card numbers belong to accounts that are underwritten by many
institutions, not just one.
The rightful owners of such credit cards live at locations sprinkled
throughout the United States; therefore, the activity initially
appears to be unconnected.
Law-enforcement agents will initially be dumbfounded as to the seed
source of the numbers, for all these reasons.
Having obtained the numbers, the next step is to choose a provider. Most
individuals who do this on a regular basis have lists of providers that
allow "instant access," where you provide your vitals, your credit card,
your desired login, your password, and so forth. Within minutes, you are
surfing the Net.
Using this technique, you can reliably obtain total anonymity for short
periods of time, periods long enough to perform the desired task. The only
hope that authorities have of catching you is to elicit corroborative
testimony of a coconspirator, or if you establish a pattern of activity
--for example, if spend your nights breaking into machines owned or operated
by security specialists who are also talented hackers.
NOTE: I have not suggested here that any reader undertake the action
described here. If you do so, you do it at your own peril. These
actions amount to crime--or, in fact, a series of crimes. Here, I
have merely explained one technique, and no more. Neither I nor Sams
Publishing advocate, support, or condone such activity.
F
