Zines/phrack/42/4.txt

                         ==Phrack Magazine==

             Volume Four, Issue Forty-Two, File 4 of 14

                          Prelude to a Kiss

    - Lessons Unlearned Are Doomed To Bring Misery Ad-Infinitum -


The following is an article I wrote for a mainstream computer security
periodical called ISPNews.  At the time, I had been discussing the idea
of a bi-monthly column with the editor at that time, Len Spitz. (Now the
editor is Michael Alexander, ex-of Computerworld)

The following article, although very, very tame by my standards, and
admittedly lacking in enough hardcore information to help security
professionals to apply a quick fix to their many problems, caused quite
a stir among the folks at ISPNews.

Since this article was from me, a self-proclaimed hacker, it
underwent an extraordinary amount of scrutiny.  Rather than be
accepted or denied by the editor, my article got the dubious honor of
being sent before an editorial advisory board.  I checked every back
issue of ISPNews and could find no mention of such an entity until the
November/December 1991 issue, the issue immediately following an length
interview with none other than myself.

When I questioned Len Spitz about this rather odd fact, he maintained
that this committee had indeed existed, but stammered his way through my
question to name any other article that they had convened to judge in
the past, and to explain the duties of such a group.  He could not give
me any answers.

The group itself was obviously geared to be a type of kangaroo-court.
It consisted of:

William J. Cook -- The man who less than two years prior had ordered my
                   privacy and civil rights violated by the Secret
                   Service solely on the basis of two bulletin board
                   posts and my association with members of the Legion
                   of Doom and the Phrack Magazine staff.

William H. Murray -- A senior consultant with Deloitte & Touche who had
                     two weeks prior stood up before my presentation to
                     the MIS Training Institute's 11th Annual Conference
                     and said loudly "I can't take this any more, I'm leaving,"
                     to the astounded audience.  The man who went on to
                     state in his own column in ISPNews, "Can we lie
                     down with dogs and get up without fleas?"  and "Ask
                     yourself if you wish to work in a profession
                     populated by rogues.  Ask yourself if you want your
                     reputation mixed with theirs."

Winn Schwartau -- A security consultant with a broad view and an open
                  mind, undoubtedly resulting from his background in the
                  music industry, as opposed to the bean-counting world
                  of MIS.

David J. Stang -- Director of research, NCSA.  Noted virus specialist.

This was the group.  Here is what they said about my article:

Bill Cook --  "It's very well-written and informative, but shouldn't be
published for legal reasons."  (What those reasons might have been were
not stated, nor did Mr. Cook return my call to his office.)

Bill Murray -- Was not even given the file to read, as his response was
deemed to predictable.

Winn Schwartau -- "Publish it.  This is valuable information."

David Stang -- Was not given the file because, according to Len Spitz
"David is just a virus expert, and this isn't in his arena, so we gave
it to Ray Kaplan."

    Ray Kaplan -- Did not want to comment on it because he said, "It's
    not my expertise, so I gave it to a friend."  I believe Ray did not
    want to get involved with anything having to do with hackers after
    the reactionary attitudes of the DECUS attendees towards his defense
    of Kevin Mitnik that nearly left him in bankruptcy.  I cannot blame
    him at all.  (Hell, I like the guy...he's certainly more brazen with
    attitude these days, I mean, he went to HoHoCon for God's-sake!)

      Ray's Friend -- "This is of absolutely no use to the information
      security professional, but of great use to the hacker community."
      I still do not know who Ray's "friend" was.  I hope his
      Alzeheimer's has subsided since this comment.

Needless to say, the article went unpublished.

Shortly thereafter I received a letter from Robert Fox, an assistant
vice-president at Sprint.  Somehow my little article had snaked its
way over to Kansas City.  It's amazing how one faxed copy of an article
could have reached so many people in such a short period of time.
Mr. Fox had the following to say:

------------------------------------------------------------------------

United Telecom/US Sprint
9221 Ward Parkway
Kansas City, Missouri 64114
816-822-6262

Robert F. Fox                                     January 13, 1992
Assistant Vice President
Corporate Security


VIA AIRBORNE EXPRESS

Mr. Chris Goggans
COMSEC
Suite 1470
7322 Southwest Freeway
Houston, TX 77074

    Re:  Your Article "Packet-switched Networks
          Security Begins With Configuration"

Dear Mr. Goggans:

    A copy of the referenced unpublished article, which is
enclosed with this letter, has come to our attention.  After
review, we believe the article is inaccurate and libelous.  If
published the contents of the article could cause damage to Sprint
customers, Sprint and our reputation, and we request that you not
publish or otherwise disseminate it.

     In addition, we believe some of the information contained in
the article has been obtained through violation of the property
rights of Sprint and/or our customers and we demand that you cease
any efforts or attempts to violate or otherwise compromise our
property whether or not for you personal financial gain.

                        Sincerely,

                        Robert F. Fox


Enclosure


------------------------------------------------------------------------


Regardless of how Mr. Fox came into possession of this article, i have to
question his letter based on his comments.   First he states that
the information is almost criminally incorrect and could cause harm to
Sprint's reputation.  Then he states that information in the article has
come to be known through the violation of the security of Sprintnet and/or
clients of Sprintnet.  In effect, I am both a thief and a liar according
to Mr. Fox.  Well, if I were a thief the information could not possibly
be inaccurate if it were obtained from Sprintnet or its clients.  If I
was a liar, why would they think the information came from themselves
and/or their clients?  Mr. Fox's thinly veiled threat caused me great
amusement.

I then decided no mainstream publication would touch this article.  I
don't know why everyone is so scared of the truth.  Perhaps if the truth
were known people would have to work, and perhaps if the truth were
known some people would be out of work.  None of this is of concern to
me anymore.  I am here to speak the truth and to provide uncensored
information gathered from a variety of sources to provide readers of
this magazine the facts they need to quench their thirst for knowledge.

This article is included as a prelude to a series of articles all based
on packet switched networks as related to information merely alluded to
in my harmless little article.  To our readers, "enjoy."  To the cowering
so-called security experts, "kiss my ass."

------------------------------------------------------------------------

Packet-switched Networks

Security Begins with Configuration


For many companies the use of packet-switched networks has
allowed for increased interconnectivity of systems and easy
remote access.  Connection to a major public packet-switched
network brings increased access points with local dialups in
many cities around the nation as well as access
points from foreign countries.

With the many obvious benefits provided by this service,
improper configuration of either the host's connection to the
network or of the network itself can lead to extreme security
problems.

The very connection to a public packet-switched network
immediately increases the exposure of that particular system.
America's two major commercial networks, BT-Tymnet and
Sprintnet, are probably the most popular US targets for hackers
around the world.  The wealth of systems available on
these two networks has provided hackers with a seemly endless
supply of sites on which to sharpen their skills.  The ease of use
inherent in both networks makes them popular for legitimate
users as well as illegitimate users.

The Telenet software utilized in the Sprintnet network allows
users to enter a network user address (NUA) in the standard
format as outlined in the X.121 numbering standard:

DDDDAAAHHHHHPP

Where D = the four digit data network identifier code (DNIC)
      A = the three digit area code corresponding to the host
      H = the host address
      P = the port or (sub) address

On domestic calls the DNIC for Sprintnet (3110) is stored in
all Sprintnet equipment and is used as the default.  By
merely picking an area code, most often corresponding to the standard
area codes of the North American Numbering Plan, and an
additional one to five digits a would-be intruder can
connect to any number of systems while looking for targets.

In the past many software packages have been written to
automate this process, and large scans of the network have
been published in a variety of underground media.

The Tymnet II software utilized in BT's Tymnet
prompts the user for a mnemonic which corresponds to a host
or number of hosts.  The mnemonic, or username, is referenced
to a fixed host address in the network's Master User
Directory (MUD).  This username may allow the caller to
connect to a variety of sites, as opposed to merely one, by
entering additional information in separate fields after the username.
It may also correspond to a network gateway thereby allowing
the user to enter a number in the X.121 format and connect to that
specific site.

This particular network, with its primary use of words as
opposed to numbers, has been compromised by intruders who
guess common words or names in their attempts to connect to
remote sites.

Each network has its own particular set of problems but
solutions to these problems are both simple and quick in
implementation.

SPRINTNET

The first deterrence in securing a host on this
network is to restrict access to the site.  This can be
accomplished in a number of ways.  The most obvious is to
have the site refuse collect calls.  All calls on Sprintnet
are reverse-billed, unless the site has specifically asked
that they not be billed for incoming calls.  This makes the
site accessible only through the use of a Network User
Identifier (NUI).

Another method of restricting access from intruders is to
place the host in a closed user group (CUG).  By electing to
have the host in a CUG, the administrator can allow only
certain NUIs to connect, and can also restrict the actual
addresses from which access is allowed.  For example:  A site
is placed in a CUG that will allow only calls from the
company's remote branch in Dallas to access the host and only
with the NUI created specifically for that branch.  All
attempts to access the site from an address outside the 214
area will result in an error message indicating an invalid
source address.  All attempts to connect with an invalid NUI
will result in an error indicating an invalid ID.  This
information is maintained in the networks main TAMS (TP
Access Management System) database, and is not subject to
manipulation under normal circumstances.

Many sites on the Sprintnet network have specific
subaddresses connecting to a debug port.  This is usually at
subaddress 99.  All connections to debug ports should be
restricted.  Allowing users access to this port will allow
them the ability to load and display memory registers of the
Sprintnet equipment connected to the port, and even reset
as well as enable or disable the host.  Most debug ports are
equipped with preset passwords from the vendor, but should be
changed.  These ports should also restrict connection from
all addresses except those specified by the company.

An additional measure that may foil intruders relying on
software programs to find all addresses in a given area code
is to request that the host be given an address above 10000.
The time involved in scanning the network is extensive and
most casual intruders will not look past the 10000 range.  In
fact, many will not venture past 2000.

BT-TYMNET

Any company having a host on the Tymnet network should choose
a username that is not easily associated with the company or
one that is not a common word or name.  If an intruder is aware that
XYZ Inc. has a UNIX based system on TYMNET he or she would
begin attempts to find this system with the obvious
usernames:  XYZ, XYZINC, XYZNET, XYZ1, XYZUNIX, UNIX, etc.

BT-Tymnet allows for these usernames to have additional
password security as well.  All hosts should have this option
enabled, and passwords should be changed frequently.
The password should always be a minimum of six
digits, should include letters, numbers and at least one symbol
character, and should not be associated in any way with the
corresponding username.

Many clients of BT-Tymnet have purchased the Tymnet II
software and have individual sub-networks that are linked to
the public network through gateways.  Each subnet is
personally configured and maintained through the use of a
package of utilities provided by Tymnet.  These utilities
each perform a specific task and are highly important to the
smooth operation of the network.  These utilities may be
accessed either directly from the host-end or remotely
through the network by entering a corresponding username.
Some of these utilities are:

XRAY : a monitoring utility
DDT : a debugging utility
NETVAL : a database of username to host correspondence
PROBE : a monitoring utility
TMCS : a monitoring utility

Under NO CIRCUMSTANCES should these utilities be left
without a password on the company's subnet.  These utilities should
also never be named similarly to their given name.  Should an
intruder gain access to any of these utilities the integrity
of your network will be at risk.

For example:

Allowing an outsider access to the XRAY utility, would give
he or she the ability to monitor both incoming and outgoing
data from the host using the "TA" command (display trace data
table in ASCII).  Use of certain XRAY commands are restricted
by a security function that allows only certain usernames to
execute commands on the basis of their existence in a
"Goodguy" list, which can be displayed by any XRAY user.
Should a user be of the highest privilege, (2), he or she can
add or delete from the "Goodguy" list, reset connections, and
display trace data on channels other than the default
channel.

Allowing a user access to DDT can result in complete
disruption of the network.  DDT allows the user the ability
to write directly to the network controller "node code" and
alter its configuration.

Allowing a user access to NETVAL will allow the user to
display all usernames active on the network and the
corresponding host addresses.

OTHER PROBLEMS

EXAMPLE ONE

On many networks users have the ability to connect to the
packet assembler/disassembler (PAD) of the network dial-ups.
This has led to significant problems in the past.

In the mid-1980's two American hackers were exploring the
German packet network DATEX-P.  One connected to a host in
Berlin and was immediately disconnected by the remote site.
Before the hacker could react, the German host connected to
the NUA corresponding to his Sprintnet PAD and sent him a
login prompt.  This alarmed the hacker greatly, as he assumed
that the proprietors of the German host had somehow noticed
his attempt to access their system.  He contacted his partner
and told him of the occurrence.  The two concluded that since
the NUA of the origination point is sent in the packet-header,
the remote site must have been programed to recognize the NUA and
then return the call.  The fact that it had returned a call to a
public PAD was intriguing to the pair, so they decided to
attempt to recreate the event by calling each other.  Both
individuals connected to the network and one entered the NUA
corresponding to the others PAD.  A connection resulted and
the two were able to interact with one another.  They then
decided that they would periodically meet in this fashion and
discuss their findings from Germany.  At the time of the next
meeting, the connection did not occur as planned.  One hacker
quickly received a telephone call from the second who
exclaimed rather excitedly that he had attempted to connect
to his partner as planned, but accidentally connected to
another PAD and intercepted a legitimate user typing his NUI.
Further investigation proved that one could connect to public
PADs during the idle period when the user was in network
mode, prior to making a connection to a remote site.  This
discovery was intended to remain secret, because of its
extremely dangerous applications.  Nevertheless, word of this
discovery soon reached the entire hacker community and what
came to be known as "PAD to PAD" was born.

The "PAD to PAD" technique became so wide-spread that hackers
were soon writing software to intercept data and emulate
hosts and capture login names and passwords from unsuspecting
network users.  Hackers were intercepting thousands of calls
every day from users connecting to systems ranging from
banking and credit to the Fortune 500 to government sites.

After nearly two years of "PAD to PAD" Sprintnet became
alerted to the crisis and disallowed all connections to
public PADs.  When Sprintnet expanded its service overseas
they once again left access to the overseas PADs
unrestricted.  The problem went unnoticed again until
their attention was brought to it by a hacker who called
Sprintnet security and told them that they ought to fix it
quickly before it became as wide-spread as before.
The problem was resolved much quicker this time.

This particular technique was not limited to Sprintnet.  All
networks using the Telenet software are at risk to this type
of manipulation.  This type of network manipulation was
integral in the recent compromise of a large Bell Company's packet
network in a much-publicized case.  Certain foreign
networks in countries such as Israel, England, Chile, Panama,
Peru and Brazil are also at risk.

EXAMPLE TWO

In the late 1980's hackers stumbled onto a packet network
owned and maintained by a large facilities maintenance
company.  This particular network had a huge flaw in its
setup.  It connected all calls placed through it as if they
were placed with an NUI.  This allowed hackers to place calls
to addresses that refused collect connections on networks
around the world.  This became a popular method for hackers
to access underground chat systems in Europe.  Additionally,
this network contained a score of computers belonging to a
major automobile manufacturer.  Most of these systems were
highly insecure.  The network also allowed unrestricted
access to network debug ports.  This particular network also
had a toll-free number on an MCI exchange.  At the time, MCI
was having some difficulty getting their equipment to accept
the ANI information to provide customers with a full call-
detail report on their monthly statement.  The hackers were
well aware of this fact and made frequent use of the network
with no fear of prosecution.  Eventually MCI was able to fix
their translation problem and were able to provide their
clients with full call-detail reports.  When this was
learned, many hackers abandoned use of the network, but
several others were later prosecuted for its usage when their
number turned up on the bill.

EXAMPLE THREE

Until quite recently intimate knowledge of the utilities
driving various packet-switched networks were known by an
exclusive few.  While investigating a network owned by an
extremely large Cleveland-based conglomerate hackers came
across a system where documentation on the usage of every
utility was kept online.  The hackers quickly downloaded all
the information and it soon became somewhat wide-spread among
the underground community.  With less-skilled and more
unscrupulous individuals in possession of this information
many networks began experiencing disruptions and system
integrity was quickly lost as hackers began monitoring data
traffic.

No information on the usage of packet networks or their
utilities should ever be kept online.  Hard copies should be
kept in the possession of the network administrator, and when
updated, obsolete versions must be destroyed.

WHAT TO DO

When a security violation stemming from a connection through
the packet network is noticed, Network Security should be
notified.  Clients of BT-Tymnet should notify Steve Matthews
at 408-922-7384.  Clients of Sprintnet should notify
Pat Sisson at 703-689-6913.

Once changes have been enacted in the network to prevent
further break-ins, the host computer should be checked
thoroughly for any changes or damages, and all individual
account passwords should be changed.

CONCLUSION

It is critical that the packet network be configured properly
and that all measures are taken to ensure its security.  Even
the most secure host computer can be easily compromised if it
is connected to an insecure packet network.
----------------------------------------------------------------------