From hackers_guild-request@euler.Berkeley.EDU Mon Jan 23 13:25:43 1995
From: Brian Pinkerton
Date: Mon, 23 Jan 95 10:12:13 -0800
To: Wendell Craig Baker
Subject: Re: Security Warning article in the NYT
Cc: hackers_guild@euler.Berkeley.EDU
Status: RO
ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.Spoofing.Attacks...
=============================================================================
CA-95:01 CERT Advisory
January 23, 1995
IP Spoofing Attacks and Hijacked Terminal Connections
-----------------------------------------------------------------------------
The CERT Coordination Center has received reports of attacks in which
intruders create packets with spoofed source IP addresses. These attacks
exploit applications that use authentication based on IP addresses. This
exploitation leads to user and possibly root access on the targeted system.
Note that this attack does not involve source routing. Recommended solutions
are described in Section III below.
In the current attack pattern, intruders may dynamically modify the
kernel of
a Sun 4.1.X system once root access is attained. In this attack, which is
separate from the IP spoofing attack, intruders use a tool to take
control of
any open terminal or login session from users on the system. Note that
although the tool is currently being used primarily on SunOS 4.1.x systems,
the system features that make this attack possible are not unique to SunOS.
As we receive additional information relating to this advisory, we will place
it, along with any clarifications, in a CA-95:01.README file. CERT advisories
and their associated README files are available by anonymous FTP from
info.cert.org. We encourage you to check the README files regularly for
updates on advisories that relate to your site.
-----------------------------------------------------------------------------
I. Description
This description summarizes both the IP spoofing technique that can
lead to root access on a system and the tool that intruders are
using to
take over open terminal and login connections after they get root
access.
We are currently seeing attacks in which intruders combine IP spoofing
with use of the tool. However, these are two separate actions. Intruders
can use IP spoofing to gain root access for any purpose; similarly, they
can highjack terminal connections regardless of their method of gaining
root access.
IP spoofing
To gain access, intruders create packets with spoofed source IP
addresses. This exploits applications that use authentication
based on
IP addresses and leads to unauthorized user and possibly root access
on the targeted system. It is possible to route packets through
filtering-router firewalls if they are not configured to filter
incoming packets whose source address is in the local domain. It
is important to note that the described attack is possible even if
no reply packets can reach the attacker.
Examples of configurations that are potentially vulnerable include
- routers to external networks that support multiple internal
interfaces
- routers with two interfaces that support subnetting on the
internal network
- proxy firewalls where the proxy applications use the source
IP address for authentication
The IP spoofing attacks we are currently seeing are similar to those
described in two papers: 1) "Security Problems in the TCP/IP Protocol
Suite" by Steve Bellovin, published in _Computer Communication
Review_
vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD
Unix TCP/IP Software" by Robert T. Morris. Both papers are available
by anonymous FTP from
ftp.research.att.com:/dist/internet_security
Bellovin paper: ipext.ps.Z
Morris paper: 117.ps.Z
Services that are vulnerable to the IP spoofing attack include
SunRPC & NFS
BSD UNIX "r" commands
anything wrapped by the tcp daemon wrappers - site dependent;
check
your configuration
X windows
other applications that use source IP addresses for authentication
Hijacking tool
Once the intruders have root access on a system, they can use a tool
to dynamically modify the UNIX kernel. This modification allows them
to hijack existing terminal and login connections from any user
on the
system.
In taking over the existing connections, intruders can bypass
one-time
passwords and other strong authentication schemes by tapping the
connection after the authentication is complete. For example, a
legitimate user connects to a remote site through a login or terminal
session; the intruder hijacks the connection after the user has
completed the authentication to the remote location; the remote site
is now compromised. (See Section I for examples of vulnerable
configurations.)
Currently, the tool is used primarily on SunOS 4.1.x systems.
However,
the system features that make this attack possible are not unique to
SunOS.
II. Impact
Current intruder activity in spoofing source IP addresses can lead to
unauthorized remote root access to systems behind a filtering-router
firewall.
After gaining root access and taking over existing terminal and login
connections, intruders can gain access to remote hosts.
III. Solutions
A. Detection
IP spoofing
If you monitor packets using network-monitoring software such as
netlog, look for a packet on your external interface that has
both its source and destination IP addresses in your local domain.
If you find one, you are currently under attack. Netlog is
available by anonymous FTP from
net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz
MD5 checksum: 1dd62e7e96192456e8c75047c38e994b
Another way to detect IP spoofing is to compare the process
accounting logs between systems on your internal network. If
the IP spoofing attack has succeeded on one of your systems,
you may get a log entry on the victim machine showing a remote
access; on the apparent source machine, there will be no
corresponding entry for initiating that remote access.
Hijacking tool
When the intruder attaches to an existing terminal or login
connection, users may detect unusual activity, such as commands
appearing on their terminal that they did not type or a blank
window
that will no longer respond to their commands. Encourage your
users
to inform you of any such activity. In addition, pay particular
attention to connections that have been idle for a long time.
Once the attack is completed, it is difficult to detect. However,
the intruders may leave remnants of their tools. For example, you
may find a kernel streams module designed to tap into existing TCP
connections.
B. Prevention
IP spoofing
The best method of preventing the IP spoofing problem is to
install
a filtering router that restricts the input to your external
interface (known as an input filter) by not allowing a packet
through if it has a source address from your internal network. In
addition, you should filter outgoing packets that have a source
address different from your internal network in order to prevent
a source IP spoofing attack originating from your site.
The following vendors have reported support for this feature:
Bay Networks/Wellfleet routers, version 5 and later
Cabletron - LAN Secure
Cisco - RIS software all releases of version 9.21 and later
Livingston - all versions
If you need more information about your router or about firewalls,
please contact your vendor directly.
If your vendor's router does not support filtering on the inbound
side of the interface or if there will be a delay in incorporating
the feature into your system, you may filter the spoofed IP
packets
by using a second router between your external interface and your
outside connection. Configure this router to block, on the
outgoing
interface connected to your original router, all packets that
have a
source address in your internal network. For this purpose, you can
use a filtering router or a UNIX system with two interfaces that
supports packet filtering.
NOTE: Disabling source routing at the router does not protect you
from this attack, but it is still good security practice to
do so.
Hijacking tool
There is no specific way to prevent use of the tool other than
preventing intruders from gaining root access in the first place.
If you have experienced a root compromise, see Section C for
general
instructions on how to recover.
C. Recovery from a UNIX root compromise
1. Disconnect from the network or operate the system in
single-user mode during the recovery. This will keep users
and intruders from accessing the system.
2. Verify system binaries and configuration files against the
vendor's media (do not rely on timestamp information to
provide an indication of modification). Do not trust any
verification tool such as cmp(1) located on the compromised
system as it, too, may have been modified by the intruder.
In addition, do not trust the results of the standard UNIX
sum(1) program as we have seen intruders modify system
files in such a way that the checksums remain the same.
Replace any modified files from the vendor's media, not
from backups.
-- or --
Reload your system from the vendor's media.
3. Search the system for new or modified setuid root files.
find / -user root -perm -4000 -print
If you are using NFS or AFS file systems, use ncheck to
search the local file systems.
ncheck -s /dev/sd0a
4. Change the password on all accounts.
5. Don't trust your backups for reloading any file used by
root. You do not want to re-introduce files altered by an
intruder.
---------------------------------------------------------------------------
The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith
Bostic,
Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our
understanding of these problems and their solutions.
---------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in Forum of Incident
Response and Security Teams (FIRST).
If you wish to send sensitive incident or vulnerability information to
CERT staff by electronic mail, we strongly advise that the e-mail be
encrypted. The CERT Coordination Center can support a shared DES key, PGP
(public key available via anonymous FTP on info.cert.org), or PEM (contact
CERT staff for details).
Internet E-mail: cert@cert.org
Telephone: +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
Fax: +1 412-268-6989
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
USA
Past advisories, CERT bulletins, information about FIRST representatives,
and other information related to computer security are available for
anonymous
FTP from info.cert.org.
CERT is a service mark of Carnegie Mellon University.
From firewalls-owner@GreatCircle.COM Tue Jan 24 07:26:54 1995
From: smb@research.att.com
Date: Tue, 24 Jan 1995 07:09:04 -0500
To: firewalls@GreatCircle.COM
Subject: new CERT advisory
Status: RO
There's a great deal of confusion about what kind of attack the
recent CERT advisory is referring to. Let me try to clear things
up.
The specific attack is a sequence number guessing attack, originally
described by R.T. Morris in Bell Labs Computer Science Technical
Report #117, February 25, 1985. I generalized (and publicized)
the attack in my 1989 paper ``Security Problems in the TCP/IP
Protocol Suite'', Computer Communications Review 19:2, April 1989,
pp. 32-48 (URLs below). Both his attack and my generalizations
are special cases of a more general attack, IP source address
spoofing, in which the attacker illegitimately uses a trusted
machine's IP address in conjunction with some protocol (such as
rsh) that does address-based authentication.
In order to understand the particular case of sequence number
guessing, you have to look at the 3-way handshake used in the TCP
open sequence. Suppose client machine A wants to talk to rsh server
B. It sends the following message:
A->B: SYN, ISSa
That is, it sends a packet with the SYN (``synchronize sequence
number'') bit set and an initial sequence number ISSa.
B replies with
B->A: SYN, ISSb, ACK(ISSa)
In addition to sending its own initial sequence number, it acknowledges
A's. Note that the actual numeric value ISSa must appear in the
message.
A concludes the handshake by sending
A->B: ACK(ISSb)
The initial sequence numbers are intended to be more or less random.
More precisely, RFC 793 specifies that the 32-bit counter be
incremented by 1 in the low-order position about every 4 microseconds.
Instead, Berkeley-derived kernels increment it by 128 every second,
and 64 for each new connection. Thus, if you open a connection to
a machine, you know to a very high degree of confidence what sequence
number it will use for its next connection. And therein lies the
attack.
The attacker X first opens a real connection to its target B --
say, to the mail port or the TCP echo port. This gives ISSb. It
then impersonates A and sends
A->B: SYN, ISSx
B's response to X's original SYN (so to speak)
B->A: SYN, ISSb', ACK(ISSx)
goes to the legitimate A, about which more anon. X never sees that
message but can still send
A->B: ACK(ISSb')
using the predicted value for ISSb'. If the guess is right -- and
usually it will be -- B's rsh server thinks it has a legitimate
connection with A, when in fact X is sending the packets. X can't
see the output from this session, but it can execute commands as
more or less any user -- and in that case, the game is over and X
has won.
There is a minor difficulty here. If A sees B's message, it will
realize that B is acknowledging something it never sent, and will
send a RST packet in response to tear down the connection. There
are a variety of ways to prevent this; the easiest is to wait until
the real A is down (possibly as a result of enemy action, of course).
There are several possible defenses. Most obvious is to take
advantage of topological knowledge: don't let packets purporting
to be from a local machine arrive on an outside interface. That
works very well if you only trust local machines. If trust is
granted to outside machines (say, via .rhosts files) and if the
attacker can identify the patterns of trust (which isn't that
difficult), the topological solution won't work. In that case,
you have to block all protocols that use TCP and address-based
authentication. (UDP is a separate can of worms.)
Best of all, don't use address-based authentication; it's a disaster
waiting to happen. The only real solution is cryptographic
authentication.
Firewalls based on tcpd have a special problem: address-based
authentication is their business. If you have a set of rules that
grants special permission to inside addresses, and you don't use
a screening router as well, you may be vulnerable. The question
is this: can an attacker do damage by just sending commands and
not seeing any output? If the answer is yes, you are vulnerable.
--Steve Bellovin
For further information, see the two papers cited above:
ftp://ftp.research.att.com/dist/internet_security/117.ps.Z
ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
From firewalls-owner@GreatCircle.COM Tue Jan 24 10:00:49 1995
Date: Tue, 24 Jan 1995 09:10:08 -0500
From: bret@real.com (Bret McDanel)
To: firewalls@GreatCircle.COM
Subject: Re: NYT Article this morning
Status: RO
> To quote from the article:
> "The new attack makes us of a flaw in the design of a network to fool the
> router computers into believing that a message is coming in from a trusted
> source. By masquerading as a familiar computer, an attacker can gain
> access to protected computer resources and seize control of an otherwise
> well-defended system."
> It also states that the "the new type of attack can in many cases easily
> penetrate these common defenses (various types of hardware & software
> defenses known as 'fire walls'),..."
> It does also state that the security warning to be issued today will
> include a list of "brands of router computers that can use a computer
> program to protect against the new attack, whic is called IP, or Internet
> protocol, spoofing."
It sounds to me that 'they' are doing what Robert T. Morris wrote about in
February 25, 1985 (which means that this is hardly new)...
in a nutshell:
you are A, you want to get into B, which trusts C..
Swamp port 21 on C with connection requests
Create a real connection on B and record sequence number
Create a raw IP socket, change its protocol to TCP and its source to C
(by writing in the kernel)
Send a SYN packet ftom port 21 (suposedly from C) to port 514 (rshd) on B
(B then sends a SYN to port 21 on C, which is ignored because
queue is full)
Send an ACK packet to B with the ack number equal to the sequence number
previously recorded, plus 64
Send data to B, increment the sequence number each time by the ammount of
data sent.
If B trusts C, then B will execute the command..
This is not really difficult, you do have to have root on the sending machine
(and with linux you get all the source, so you could even rewrite some of
it to make it easier to spoof IP)..
From not-for-mail Wed Jan 25 15:57:54 EST 1995
From: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura)
Subject: Technical details of the attack described by Markoff in NYT
Date: 25 Jan 1995 04:36:37 -0800
Status: RO
Greetings from Lake Tahoe.
There seems to be a lot of confusion about the IP address spoofing and
connection hijacking attacks described by John Markoff's 1/23/95 NYT article,
and CERT advisory CA-95:01.
Here are some technical details from my presentation on 1/11/95 at CMAD 3
in Sonoma, California. Hopefully this will help clear up any
misunderstandings
as to the nature of these attacks.
Two different attack mechanisms were used. IP source address spoofing
and TCP sequence number prediction were used to gain initial access to a
diskless workstation being used mostly as an X terminal. After root access
had been obtained, an existing connection to another system was hijacked by
means of a loadable kernel STREAMS module.
Included in this note are excerpts from actual tcpdump packet logs generated
by this attack. In the interest of clarity (and brevity!), some of the data
has been omitted.
I highly recommend Steve Bellovin's paper and posts on IP spoofing, as he
describes in more detail the semantics of the TCP handshake, as well as
making
some suggestions on how to defeat this attack.
My configuration is as follows:
server = a SPARCstation running Solaris 1 serving my "X terminal"
x-terminal = a diskless SPARCstation running Solaris 1
target = the apparent primary target of the attack
-----
The IP spoofing attack started at about 14:09:32 PST on 12/25/94. The first
probes were from toad.com (this info derived from packet logs):
14:09:32 toad.com# finger -l @target
14:10:21 toad.com# finger -l @server
14:10:50 toad.com# finger -l root@server
14:11:07 toad.com# finger -l @x-terminal
14:11:38 toad.com# showmount -e x-terminal
14:11:49 toad.com# rpcinfo -p x-terminal
14:12:05 toad.com# finger -l root@x-terminal
The apparent purpose of these probes was to determine if there might be
some kind of trust relationship amongst these systems which could be
exploited
with an IP spoofing attack. The source port numbers for the showmount and
rpcinfo indicate that the attacker is root on toad.com.
-----
About six minutes later, we see a flurry of TCP SYNs (initial connection
requests) from 130.92.6.97 to port 513 (login) on server. The purpose of
these SYNs is to fill the connection queue for port 513 on server with
"half-open" connections so it will not respond to any new connection
requests. In particular, it will not generate TCP RSTs in response to
unexpected SYN-ACKs.
As port 513 is also a "privileged" port (< IPPORT_RESERVED), server.login
can now be safely used as the putative source for an address spoofing
attack on the UNIX "r-services" (rsh, rlogin). 130.92.6.97 appears to be
a random (forged) unused address (one that will not generate any response
to packets sent to it):
14:18:22.516699 130.92.6.97.600 > server.login: S
1382726960:1382726960(0) win 4096
14:18:22.566069 130.92.6.97.601 > server.login: S
1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602 > server.login: S
1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603 > server.login: S
1382726963:1382726963(0) win 4096
14:18:22.886128 130.92.6.97.604 > server.login: S
1382726964:1382726964(0) win 4096
14:18:22.943514 130.92.6.97.605 > server.login: S
1382726965:1382726965(0) win 4096
14:18:23.002715 130.92.6.97.606 > server.login: S
1382726966:1382726966(0) win 4096
14:18:23.103275 130.92.6.97.607 > server.login: S
1382726967:1382726967(0) win 4096
14:18:23.162781 130.92.6.97.608 > server.login: S
1382726968:1382726968(0) win 4096
14:18:23.225384 130.92.6.97.609 > server.login: S
1382726969:1382726969(0) win 4096
14:18:23.282625 130.92.6.97.610 > server.login: S
1382726970:1382726970(0) win 4096
14:18:23.342657 130.92.6.97.611 > server.login: S
1382726971:1382726971(0) win 4096
14:18:23.403083 130.92.6.97.612 > server.login: S
1382726972:1382726972(0) win 4096
14:18:23.903700 130.92.6.97.613 > server.login: S
1382726973:1382726973(0) win 4096
14:18:24.003252 130.92.6.97.614 > server.login: S
1382726974:1382726974(0) win 4096
14:18:24.084827 130.92.6.97.615 > server.login: S
1382726975:1382726975(0) win 4096
14:18:24.142774 130.92.6.97.616 > server.login: S
1382726976:1382726976(0) win 4096
14:18:24.203195 130.92.6.97.617 > server.login: S
1382726977:1382726977(0) win 4096
14:18:24.294773 130.92.6.97.618 > server.login: S
1382726978:1382726978(0) win 4096
14:18:24.382841 130.92.6.97.619 > server.login: S
1382726979:1382726979(0) win 4096
14:18:24.443309 130.92.6.97.620 > server.login: S
1382726980:1382726980(0) win 4096
14:18:24.643249 130.92.6.97.621 > server.login: S
1382726981:1382726981(0) win 4096
14:18:24.906546 130.92.6.97.622 > server.login: S
1382726982:1382726982(0) win 4096
14:18:24.963768 130.92.6.97.623 > server.login: S
1382726983:1382726983(0) win 4096
14:18:25.022853 130.92.6.97.624 > server.login: S
1382726984:1382726984(0) win 4096
14:18:25.153536 130.92.6.97.625 > server.login: S
1382726985:1382726985(0) win 4096
14:18:25.400869 130.92.6.97.626 > server.login: S
1382726986:1382726986(0) win 4096
14:18:25.483127 130.92.6.97.627 > server.login: S
1382726987:1382726987(0) win 4096
14:18:25.599582 130.92.6.97.628 > server.login: S
1382726988:1382726988(0) win 4096
14:18:25.653131 130.92.6.97.629 > server.login: S
1382726989:1382726989(0) win 4096
server generated SYN-ACKs for the first eight SYN requests before the
connection queue filled up. server will periodically retransmit these
SYN-ACKs as there is nothing to ACK them.
-----
We now see 20 connection attempts from apollo.it.luc.edu to x-terminal.shell.
The purpose of these attempts is to determine the behavior of x-terminal's
TCP sequence number generator. Note that the initial sequence numbers
increment by one for each connection, indicating that the SYN packets are
*not* being generated by the system's TCP implementation. This results in
RSTs conveniently being generated in response to each unexpected SYN-ACK,
so the connection queue on x-terminal does not fill up:
14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell: S
1382726990:1382726990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S
2021824000:2021824000(0) ack 1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R
1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S
1382726991:1382726991(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S
2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R
1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R
1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S
1382726992:1382726992(0) win 4096
14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S
2022080000:2022080000(0) ack 1382726993 win 4096
14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R
1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S
1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S
2022208000:2022208000(0) ack 1382726994 win 4096
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R
1382726994:1382726994(0) win 0
14:18:28.054114 apollo.it.luc.edu.996 > x-terminal.shell: S
1382726994:1382726994(0) win 4096
14:18:28.224935 x-terminal.shell > apollo.it.luc.edu.996: S
2022336000:2022336000(0) ack 1382726995 win 4096
14:18:28.305578 apollo.it.luc.edu.996 > x-terminal.shell: R
1382726995:1382726995(0) win 0
14:18:28.564333 apollo.it.luc.edu.995 > x-terminal.shell: S
1382726995:1382726995(0) win 4096
14:18:28.734953 x-terminal.shell > apollo.it.luc.edu.995: S
2022464000:2022464000(0) ack 1382726996 win 4096
14:18:28.811591 apollo.it.luc.edu.995 > x-terminal.shell: R
1382726996:1382726996(0) win 0
14:18:29.074990 apollo.it.luc.edu.994 > x-terminal.shell: S
1382726996:1382726996(0) win 4096
14:18:29.274572 x-terminal.shell > apollo.it.luc.edu.994: S
2022592000:2022592000(0) ack 1382726997 win 4096
14:18:29.354139 apollo.it.luc.edu.994 > x-terminal.shell: R
1382726997:1382726997(0) win 0
14:18:29.354616 apollo.it.luc.edu.994 > x-terminal.shell: R
1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 > x-terminal.shell: S
1382726997:1382726997(0) win 4096
14:18:29.755054 x-terminal.shell > apollo.it.luc.edu.993: S
2022720000:2022720000(0) ack 1382726998 win 4096
14:18:29.840372 apollo.it.luc.edu.993 > x-terminal.shell: R
1382726998:1382726998(0) win 0
14:18:30.094299 apollo.it.luc.edu.992 > x-terminal.shell: S
1382726998:1382726998(0) win 4096
14:18:30.265684 x-terminal.shell > apollo.it.luc.edu.992: S
2022848000:2022848000(0) ack 1382726999 win 4096
14:18:30.342506 apollo.it.luc.edu.992 > x-terminal.shell: R
1382726999:1382726999(0) win 0
14:18:30.604547 apollo.it.luc.edu.991 > x-terminal.shell: S
1382726999:1382726999(0) win 4096
14:18:30.775232 x-terminal.shell > apollo.it.luc.edu.991: S
2022976000:2022976000(0) ack 1382727000 win 4096
14:18:30.852084 apollo.it.luc.edu.991 > x-terminal.shell: R
1382727000:1382727000(0) win 0
14:18:31.115036 apollo.it.luc.edu.990 > x-terminal.shell: S
1382727000:1382727000(0) win 4096
14:18:31.284694 x-terminal.shell > apollo.it.luc.edu.990: S
2023104000:2023104000(0) ack 1382727001 win 4096
14:18:31.361684 apollo.it.luc.edu.990 > x-terminal.shell: R
1382727001:1382727001(0) win 0
14:18:31.627817 apollo.it.luc.edu.989 > x-terminal.shell: S
1382727001:1382727001(0) win 4096
14:18:31.795260 x-terminal.shell > apollo.it.luc.edu.989: S
2023232000:2023232000(0) ack 1382727002 win 4096
14:18:31.873056 apollo.it.luc.edu.989 > x-terminal.shell: R
1382727002:1382727002(0) win 0
14:18:32.164597 apollo.it.luc.edu.988 > x-terminal.shell: S
1382727002:1382727002(0) win 4096
14:18:32.335373 x-terminal.shell > apollo.it.luc.edu.988: S
2023360000:2023360000(0) ack 1382727003 win 4096
14:18:32.413041 apollo.it.luc.edu.988 > x-terminal.shell: R
1382727003:1382727003(0) win 0
14:18:32.674779 apollo.it.luc.edu.987 > x-terminal.shell: S
1382727003:1382727003(0) win 4096
14:18:32.845373 x-terminal.shell > apollo.it.luc.edu.987: S
2023488000:2023488000(0) ack 1382727004 win 4096
14:18:32.922158 apollo.it.luc.edu.987 > x-terminal.shell: R
1382727004:1382727004(0) win 0
14:18:33.184839 apollo.it.luc.edu.986 > x-terminal.shell: S
1382727004:1382727004(0) win 4096
14:18:33.355505 x-terminal.shell > apollo.it.luc.edu.986: S
2023616000:2023616000(0) ack 1382727005 win 4096
14:18:33.435221 apollo.it.luc.edu.986 > x-terminal.shell: R
1382727005:1382727005(0) win 0
14:18:33.695170 apollo.it.luc.edu.985 > x-terminal.shell: S
1382727005:1382727005(0) win 4096
14:18:33.985966 x-terminal.shell > apollo.it.luc.edu.985: S
2023744000:2023744000(0) ack 1382727006 win 4096
14:18:34.062407 apollo.it.luc.edu.985 > x-terminal.shell: R
1382727006:1382727006(0) win 0
14:18:34.204953 apollo.it.luc.edu.984 > x-terminal.shell: S
1382727006:1382727006(0) win 4096
14:18:34.375641 x-terminal.shell > apollo.it.luc.edu.984: S
2023872000:2023872000(0) ack 1382727007 win 4096
14:18:34.452830 apollo.it.luc.edu.984 > x-terminal.shell: R
1382727007:1382727007(0) win 0
14:18:34.714996 apollo.it.luc.edu.983 > x-terminal.shell: S
1382727007:1382727007(0) win 4096
14:18:34.885071 x-terminal.shell > apollo.it.luc.edu.983: S
2024000000:2024000000(0) ack 1382727008 win 4096
14:18:34.962030 apollo.it.luc.edu.983 > x-terminal.shell: R
1382727008:1382727008(0) win 0
14:18:35.225869 apollo.it.luc.edu.982 > x-terminal.shell: S
1382727008:1382727008(0) win 4096
14:18:35.395723 x-terminal.shell > apollo.it.luc.edu.982: S
2024128000:2024128000(0) ack 1382727009 win 4096
14:18:35.472150 apollo.it.luc.edu.982 > x-terminal.shell: R
1382727009:1382727009(0) win 0
14:18:35.735077 apollo.it.luc.edu.981 > x-terminal.shell: S
1382727009:1382727009(0) win 4096
14:18:35.905684 x-terminal.shell > apollo.it.luc.edu.981: S
2024256000:2024256000(0) ack 1382727010 win 4096
14:18:35.983078 apollo.it.luc.edu.981 > x-terminal.shell: R
1382727010:1382727010(0) win 0
Note that each SYN-ACK packet sent by x-terminal has an initial sequence
number
which is 128,000 greater than the previous one.
-----
We now see a forged SYN (connection request), allegedly from server.login
to x-terminal.shell. The assumption is that x-terminal probably trusts
server, so x-terminal will do whatever server (or anything masquerading
as server) asks.
x-terminal then replies to server with a SYN-ACK, which must be ACK'd in
order for the connection to be opened. As server is ignoring packets sent
to server.login, the ACK must be forged as well.
Normally, the sequence number from the SYN-ACK is required in order to
generate a valid ACK. However, the attacker is able to predict the
sequence number contained in the SYN-ACK based on the known behavior of
x-terminal's TCP sequence number generator, and is thus able to ACK the
SYN-ACK without seeing it:
14:18:36.245045 server.login > x-terminal.shell: S
1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096
-----
The spoofing machine now has a one-way connection to x-terminal.shell
which
appears to be from server.login. It can maintain the connection and send
data provided that it can properly ACK any data sent by x-terminal. It
sends the following:
14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096
which corresponds to:
14:18:37 server# rsh x-terminal "echo + + >>/.rhosts"
Total elapsed time since the first spoofed packet: < 16 seconds
-----
The spoofed connection is now shut down:
14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096
14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096
14:18:43.165874 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > x-terminal.shell: R
1382727043:1382727043(0) win 4096
14:18:52.236452 server.login > x-terminal.shell: R
1382727044:1382727044(0) win 4096
-----
We now see RSTs to reset the "half-open" connections and empty the connection
queue for server.login:
14:18:52.298431 130.92.6.97.600 > server.login: R
1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server.login: R
1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R
1382726962:1382726962(0) win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R
1382726963:1382726963(0) win 4096
14:18:52.536573 130.92.6.97.604 > server.login: R
1382726964:1382726964(0) win 4096
14:18:52.600899 130.92.6.97.605 > server.login: R
1382726965:1382726965(0) win 4096
14:18:52.660231 130.92.6.97.606 > server.login: R
1382726966:1382726966(0) win 4096
14:18:52.717495 130.92.6.97.607 > server.login: R
1382726967:1382726967(0) win 4096
14:18:52.776502 130.92.6.97.608 > server.login: R
1382726968:1382726968(0) win 4096
14:18:52.836536 130.92.6.97.609 > server.login: R
1382726969:1382726969(0) win 4096
14:18:52.937317 130.92.6.97.610 > server.login: R
1382726970:1382726970(0) win 4096
14:18:52.996777 130.92.6.97.611 > server.login: R
1382726971:1382726971(0) win 4096
14:18:53.056758 130.92.6.97.612 > server.login: R
1382726972:1382726972(0) win 4096
14:18:53.116850 130.92.6.97.613 > server.login: R
1382726973:1382726973(0) win 4096
14:18:53.177515 130.92.6.97.614 > server.login: R
1382726974:1382726974(0) win 4096
14:18:53.238496 130.92.6.97.615 > server.login: R
1382726975:1382726975(0) win 4096
14:18:53.297163 130.92.6.97.616 > server.login: R
1382726976:1382726976(0) win 4096
14:18:53.365988 130.92.6.97.617 > server.login: R
1382726977:1382726977(0) win 4096
14:18:53.437287 130.92.6.97.618 > server.login: R
1382726978:1382726978(0) win 4096
14:18:53.496789 130.92.6.97.619 > server.login: R
1382726979:1382726979(0) win 4096
14:18:53.556753 130.92.6.97.620 > server.login: R
1382726980:1382726980(0) win 4096
14:18:53.616954 130.92.6.97.621 > server.login: R
1382726981:1382726981(0) win 4096
14:18:53.676828 130.92.6.97.622 > server.login: R
1382726982:1382726982(0) win 4096
14:18:53.736734 130.92.6.97.623 > server.login: R
1382726983:1382726983(0) win 4096
14:18:53.796732 130.92.6.97.624 > server.login: R
1382726984:1382726984(0) win 4096
14:18:53.867543 130.92.6.97.625 > server.login: R
1382726985:1382726985(0) win 4096
14:18:53.917466 130.92.6.97.626 > server.login: R
1382726986:1382726986(0) win 4096
14:18:53.976769 130.92.6.97.627 > server.login: R
1382726987:1382726987(0) win 4096
14:18:54.039039 130.92.6.97.628 > server.login: R
1382726988:1382726988(0) win 4096
14:18:54.097093 130.92.6.97.629 > server.login: R
1382726989:1382726989(0) win 4096
server.login can again accept connections.
-----
After root access had been gained via IP address spoofing, a kernel module
named "tap-2.01" was compiled and installed on x-terminal:
x-terminal% modstat
Id Type Loadaddr Size B-major C-major Sysnum Mod Name
1 Pdrv ff050000 1000 59. tap/tap-2.01 alpha
x-terminal% ls -l /dev/tap
crwxrwxrwx 1 root 37, 59 Dec 25 14:40 /dev/tap
This appears to be a kernel STREAMS module which can be pushed onto an
existing STREAMS stack and used to take control of a tty device. It was
used to take control of an already authenticated login session to target
at about 14:51 PST.
-----
Of course, no attack would be complete without the personal touch. Check
out:
ftp://ftp.sdsc.edu/pub/security/sounds/tweedle-dee.au
ftp://ftp.sdsc.edu/pub/security/sounds/tweedle-dum.au
These are in Sun audio file format, 8-bit u-law, 8 khz sample rate.
---
Tsutomu Shimomura tsutomu@ucsd.edu +1 619 534 5050
University of California at San Diego/San Diego Supercomputer Center, USA
From owner-ids@uow.edu.au Wed Jan 25 09:30:49 1995
From: ziese@trex3.csap.af.mil
Date: Wed, 25 Jan 1995 08:04:31 cst
Subject: Re: IP spoofing -- assessment
To: ids@uow.edu.au
Status: RO
Frank Swift mentions:
>Of interest also was that the tools were subsequently posted at an .edu
>site and then taken off the net by their administrators.
Tsutomu and I discussed this attack in depth, over dinner, and he never
mentioned his tools being posted somewhere; I think what may have
happened is
confusing definitions -- tools like "gimme which is the ankle-biters
weapon of
choice' vs tools like 'the interface builder builder, which I defy anyone to
execute outside Tsutomu's lab having seen it in operation firsthand. It's
sweet, but it's just not going to be a compressed tar file you download and
uncompress, it requires a great deal of careful planning and preprocessing
before use. And my comments are based on sitting with Tsutomu last
summer and
having him show me how the 'advanced' tools work.
>This incident is just the tip of the iceberg. I'm fear that we all may get
>spooled off in a router discussion eddy and miss the importance of what the
>other tools were and what they do.
>How's that for another catalyst?
>frank
>Frank Swift L-321 (Sent from Home)
>Unclassified Computer Security Coordinator
>Lawrence Livermore National Laboratory (LLNL)
>7000 East Avenue L-321 Livermore CA 94550-9516
>Voice: (510) 422-1463 FAX: (510) 423-0913
Tsutomu Shimomura and I were on the system vulnerabilities session of the
conference referenced in the article -- and it was his system that was
attacked. We discussed, privately, the attack at length. The 'tools' that
were stolen are far less significant than might be expected for three
reasons:
(1) this attack, in an even more elementary form, was launched,
successfully,
on his system last summer and most of the tools were originally pilfered then
AF testing has verified that 50% of the systems on the net, within the
.af.mil
domain, are vulnerable to penetration with the simplest techniques. On
80% of
those 50% my team can get root use equally simple techniques. Although
the IP
spoofing is interesting let's work the math, because our metric data
indicates
that 95% of what's reported is ankle-biting not roicket science. There's no
denying that IP spoofing is severe and it could hurt a lot of us and it
should
be fixed, unfortunately so should world hunger -- the problem is you
can't fix
everything, nor can you fix a lot of things at once -- you have to prioritize
based on what is happening, not what might happen. For instance, if
experience data indicates that sendmail is still wide open on most systems,
even if you prevent IP spoofing sendmail is still vulnerable. This is
important because yopu'll have stopped one IP spoofer, but 95 others crackers
will have snatched the code you built using sendmail. It's a hollow argument
to say sendmail should be updated because as 8lgm will demonstrate at
midnight
on 6 Feb -- the newest version of sendmail is still vulnerable. We need to
identify the tope ten problems, and proactively prevent them. I know,
metrically, what the Air Force's top ten are and we are working on the short
term solution. Until that's fixed, I'm willing to bite the bullet and accept
what I cannot change -- for the moment.
Were am I going? First, the tools taken from Tsutomu will most likely
not be
seen for a while because unlike the gimme program, there were code snippets
not functional shell scripts AND they can be easily attributed to him. Two,
ip spoofing is bad, but the ankle biters are worse because our systems (yours
and mine) are vulnerable to the most elementary attacks and as long as that
stands, the exotic ones should be counted but not obsessed over.
Finally, I wonder if the people on this list would share metric data? Since
things like number of attacks, number of successes, and number of compromises
(along with things like the top ten attacks you've seen) would not hold a
site
up to the microscope and would not compromise site data -- but it would
let us
identify the top ten, real world, problems. If we could achieve even a
modest
goal like this, we could confidently say "these are the immediate
countermeasures that must be built." I am willing to share AF metric
data at
this level to help strengthen the community as a whole. I'm also willing to
accept and maintain this data in something like an email server were yopu
email your new input and the list gets emailed the new metrics. Any thoughts
on this?
I'd like to thank Frank for being a catalyst. Often times I'm reluctant to
post anything because I like to listen to everyone else's thoughts
first. It
just seemed like everyone was thinking the same thing I was so I decided to
'share' ;)
Kevin
=========================================================
Capt Kevin J. Ziese ziese@chaos.csap.af.mil
Chief, Countermeasures Development 1-210-377-0477 Voice
AF Information Warfare Center 1-210-377-1326 Fax
1100 NW Loop 410, Suite 607 1-800-217-0570 Pager
San Antonio, Texas 78213
=========================================================
From owner-ids@uow.edu.au Wed Jan 25 10:28:17 1995
From: paul@hawksbill.sprintmrn.com (Paul Ferguson)
Subject: Re: IP spoofing -- assessment
To: ids@uow.edu.au
Date: Wed, 25 Jan 1995 10:02:11 -0500 (EST)
Status: RO
ziese@chaos.csap.af.mil writes -
> Were am I going? First, the tools taken from Tsutomu will most likely
not be
> seen for a while because unlike the gimme program, there were code snippets
> not functional shell scripts AND they can be easily attributed to him.
Two,
> ip spoofing is bad, but the ankle biters are worse because our systems
(yours
> and mine) are vulnerable to the most elementary attacks and as long as that
> stands, the exotic ones should be counted but not obsessed over.
I'm not so concerned about the attacks themselves, per se, as I am
about the detection methodology (which is why I subscribed to this
list in the first place) to determine the usage of the tools themselves.
I received this interesting e-mail yesterday concerning TAP. Apologies
to those on the list who have already read it on the firewalls list.
forwarded message:
TAP could be a program that was posted in 1992 by Simon Ney in alt.sources.
There is another varient called advise that does the same thing.
If it is a streams based program like tap ... provided that pstat hasn't
been compromised, the following will show a tap:
here an example output from ,pstat -S'' while one tapmon is running:
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
f05461e f05583c f0cdb94 59, 0 0 0 R
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
tapc 0 R 0 INF 0 0
Read side:
tapc 0 R 0 INF 0 0
strrhead 0 R 0 INF 5120 1024
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
f0543e0 f0550ec f0cc9f4 12, 1 905 0
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
tap 0 R 0 INF 0 0
ttcompat 0 R 0 INF 300 200
ldterm 0 R 0 INF 1 0
zs 0 R 0 INF 2048 128
Read side:
zs 0 R 0 INF 2048 128
ldterm 0 R 0 128 500 200
ttcompat 0 R 0 INF 2048 128
tap 0 R 0 INF 0 0
strrhead 0 0 INF 300 200
Here is what TAP says:
DESCRIPTION:
- the device is a monitor/manipulator for other STREAMS-devices
such as standard UNIX control-terminals.
- this driver is a kernel-loadable-module. (==>no reboot required)
- it is a combination of a STREAMS-module and a STREAMS-driver.
tap - is the name of the pushable/poppable
STREAMS-modules.
tapc* - are the names of the STREAMS-driver nodes (special
files)..
- the tap-modules must first manually pushed/popped on each stream
to be monitored or manipulated, independ if the tapc-driver is
open or not. see also ioctl(fd,I_PUSH|I_POP,"tap").
- the first module pushed become the id 0, the second 1, and so on...
if any of these modules are popped the next pushed will become
the old id of the previous popped module. the module ids are
always unique, and are assigned first fit.
the maximal number of tap-modules pushed is NTAP (see tap.h).
- a pushed-tap-module act as NULL-streams-MODULE (pass data from
below
to above and data from above to below) unless it is connected with
the tapc-driver.
- now if a minor device of the tapc-driver is opened the minor
device-number is used to check if such tap-module is pushed
(minor number = tap-id). if no such module id is present a
ENETUNREACH (Network is unreachable) error is returned by open().
if the module id (minor device number) can be found, a connection
to the pushed-tap-module is established.
- all minor-device-nodes can only open by one user at a time,
the second open() on the same minor device returns a EBUSY (Device
busy) error.
- if the open() has the O_NDELAY flag set a TAP_REVERSE flag
is internal set in the driver. the TAP_REVERSE flag can only
set by the super-user, a non-superuser open() returns a EACCES
(Permission denied) error.
- now data can be received/send from/to the pushed-tap-module
with read() and write().
- if the TAP_REVERSE flag is not set, data received by the tap-module
from the above modules/streamshead (upper-stream) is duplicated
and send to the read-side of the tapc-driver, and can be read by
the user process that opened the tapc-driver.
data written with write() by the process that opened the
tapc-driver
are send to modules/streamshead above the tap-module
(upper-stream).
- if the TAP_REVERSE flag is set, data received by the tap-module
from the module/driver below the tap-module (lower-stream) is
duplicated and send to the read-side of the tapc-driver, and can
be read by the user process that opened the tapc-driver.
data written with write() by the process that opened the
tapc-driver
are send to the modules/driver below the tap-module (lower-stream).
- if the tapc-driver is closed the messages are not dupclicated as
long as the tapc-driver is re-open. (the tap-modules remains
pushed)
- if data is written by the tapc-driver and the connected module
was popped a ENETCONNRESET (Connection reset by peer) error is
return to the write().
- if the stream that has the tap-module pushed is closed, all modules
on this stream are popped by the system. but there is a
configuration
option in sunos to autopush any modules on open() (that's different
in a SYSV environment).
---------------
FIGURES:
(USER PROCESS) (BIG BROTHER)
(csh,vi) (tapmon) (tapmon -r) (tip/cu/uucico)
/dev/ttya /dev/tapc0 /dev/tapc1 /dev/cua1
--------------------------------------------------------------------------------
|ttya HEAD | |tapc HEAD| |tapc HEAD| |cua1 HEAD |
+----------+ +---------+ +---------+ +----------+
| ^ | ^ | ^ | ^
| | | | | | | |
| | ........... ........... | |
| | . MORE . . MORE . | |
| | . MODULES . . MODULES . | |
| | ........... ........... | |
| | | | | | | |
v | v | v | | |
............ +---------+ +---------+ ............
. MORE (2). |TAPC 0 | |TAPC 1 | . MORE (2) .
. MODULES . |DRIVER | |DRIVER(1)| . MODULES .
............ +---------+ +---------+ ............
(3)| ^(4) | ^ | ^ | | UPPER
v | | | | | v |
STREAMS
+----------+ | | | | +----------+
| \ \ | | | | | | TAP 1 |
| \ \--|<---------/ | | \--------|\ MODULE |
| TAP 0\---|------------/ \--------->| \ PUSHED|
| MODULE | |\ \REVERSE|
| PUSHED | | \ \ OPEN |
| | <--- NORMAL REVERSE---> | \ \ |
+----------+ +----------+
| ^ (4)| ^(3) LOWER
v | v |
STREAMS
............ ............
. MORE (2). . MORE .
. MODULES . . MODULES .
............ ............
| ^ | ^
v | v |
+----------+ +----------+
| zs DRIVER| | zs DRIVER|
--------------------------------------------------------------------------------
physical STREAMS device physical STREAMS device
(terminal) (modem)
(intruder) (other systems)
----------
(1) - opened by O_NDELAY from root
(2) - e.g. ttcompat,ldterm,kb,ms,
slip,ax25,pf,nbuf
(3) - duplicated streams
(4) - multiplexed streams
NOTE: the ,,physical STREAMS device'' above shown can be any streams device
e.g.: /dev/{tty*,console,nit,tcp,loop,mux,mti,kbd,mouse,*CLONE*}
(nit and tcp is a clone device !)
slip cant monitored because itself pops all modules pushed.
the only way is to modify sliplogin.c to push the tap module below
the slip module.
- ---
_______________________________________________________________________________
Paul Ferguson
US Sprint tel: 703.689.6828
Managed Network Engineering internet:
paul@hawk.sprintmrn.com
Reston, Virginia USA
http://www.sprintmrn.com
From cactus@hks.net Wed Jan 25 16:58:54 1995
Date: Wed, 25 Jan 1995 16:51:26 -0100
From: Todd Masco
To: hks-spooge@hks.net
Subject: Text of NYT article
Status: RO
------- start of forwarded message (RFC 934 encapsulation) -------
The New York Times
January 23, 1995, pp. A1, D4.
Data Network Is Found Open To New Threat
By John Markoff
San Francisco, Jan. 22 -- A Federal computer security
agency has discovered that unknown intruders have developed
a new way to break into computer systems, and the agency
plans on Monday to advise users how to guard against the
problem.
The new form of attack leaves many ot the 20 million
government, business, university and home computers on the
global Internet vulnerable to eavesdropping and theft.
Officials say that unless computer users take the
complicated measures they will prescribe, intruders could
copy or destroy documents or even operate undetected by
posing as an authorized user of the system.
For computer users, the problem is akin to homeowners
discovering that burglars have master keys to all the front
doors in the neighborhood.
The first known attack using the new technique took place
on Dec. 25 against the computer ot a well-known computer
security expert at the San Diego Supercomputer Center. An
unknown individual or group took over his computer for more
than a day and electronically stole a large number of
security programs he had developed.
Since then several attacks have been reported, and there is
no way of knowing how many others may have occurred.
Officials at the Government-financed Computer Emergency
Response Team say that the new assaults are a warning that
better security precautions will have to be taken before
commerce comes to the Internet, a worldwide web of
interconnected computers that exchange electronic messages,
documents and computer programs.
It is expected that by the end of this year such businesses
as florists, supermarkets, credit card companies and banks
will peddle wares to customers via the Internet and the
new intruders could be able to steal credit card numbers
merchandise and money.
The response team, based at Carnegie-Mellon University in
Pittsburgh, plans on Monday to post an advisory on the
Internet, alerting computer users to the attacks and urging
them to take a variety of protective measures involving
software and hardware security mechanisms.
"This was a sophisticated attack," said James Settle, a
former F.B.I. computer crime expert who is now an executive
at the Inet Corporation, a computer security firm.
"Essentially everyone is vulnerable."
The Internet works by breaking computer messages into
groups of digital packets of data, each of which has an
electronic "envelope" that provides "to" and "from"
addressing information used by special network computers
known as routers that deliver the data.
The new attack makes use of a flaw in the design of the
network to fool the router computers into believing that a
message is coming from a trusted source. By masquerading as
a familiar computer, an attacker can gain access to
protected computer resources and seize control of an
otherwise well-defended system.
Computer administrators at several organizations that have
been broken into by individuals using the technique said
they had been contacted by Federal law-enforcement
officials as part of an investigation into the break-ins,
but Justice Department officials refused to comment.
The lack of tight security on the Internet has remained a
well-known risk, even as thousands of companies have been
flocking to the global network in the last year hoping do
business in cyberspace.
However, many computer security experts point out that the
basic Internet software was never designed with this use in
mind. It was originally created by academic researchers to
exchange computer data conveniently with little thought to
the problems that are now emerging in which anonymous
individuals, hidden by a web of computer links, can
eavesdrop and steal electronically.
Classified Government military computer systems are not
thought to be at risk because they are not directly
connected to the Internet.
And until now, most companies and other organizations with
computers directly connected to the Internet have assumed
they could protect themselves from intruders by creating
various types of hardware and software defenses known as
"fire walls."
But the new type of attack can in many cases easily
penetrate these common defenses, according to officials of
the Computer Emergency Response Team.
"Out of all the sites on the Internet, there are only some
small fraction that care enough about security," said Tom
Longstaff, manager of research and development for the
security agency.
The security warning to be issued on Monday will include a
list of brands of router computers that can use a computer
program to protect against the new attack, which is called
IP, or Internet protocol, spoofing. The new defense works
by recognizing packets that have been forged and rejecting
them. But the advisory will also list brands of routers
that have no way of protecting against the attack.
Computer security experts said there was no good way of
estimating what fraction of the Internet computers have
routers or fire wall software capable of protecting against
the attack.
"This is a really tough problem because it is an attack
based on the way things work normally," said Marcus Ranum,
a senior scientist at Trusted Information Systems, a
computer security firm.
The flaw, which has been known as a theoretical possibility
to computer experts for more than a decade, but has never
been demonstrated before, is creating alarm among security
experts now because of the series of break-ins and attacks
in recent weeks.
The weakness, which was previously reported in technical
papers by AT&T researchers, was detailed in a talk given by
Tsutomu Shimomura, a computer security expert at the San
Diego Supercomputer Center, at a California computer
security seminar sponsored by researchers at the University
of California at Davis two weeks ago.
Mr. Shimomura's computer was taken over by an unknown
attacker who then copied documents and programs to
computers at the university of Rochester where they were
illegally hidden on school computers.
Most computer security experts say that real security on
the Internet awaits the widespread adoption of encryption
technology for scrambling data and aulhenticating messages.
Internet veterans also expressed anger at the new style of
attack because it would cause many organizations to
strengthen their security systems, thus making the network
less convenient and less useful.
"These guys are striking the basis of trust that makes the
network work," Mr. Ranum said, "and I hate that."
[Sidebar]
Security Breaches
Companies and individuals connected to the Internet have to
contend with a new threat to data security. Posing as
"friendly" computers, intruders have figured out ways to
break into computers and computer networks connected to the
Internet and steal data and security codes. The intruders
are able to gain access to normally secure networks by
finding and then using the identity of a computer that a
network recognizes as being an authorized user.
Network Security -- Normally, networks only allow access to
authorized computers and users. The network is able to
distinguish "friend" from "foe" by looking at a computer's
Internet protocol address, an ID number specific to each
computer. When an unknown computer tries to get into a
network, its access is barred.
Finding a Disguise -- To break into a network, an intruder
must locate the IP address of a computer known to the
network. There are a number of methods an intruder can use
to find a "trusted" computer. In one case, an intruder used
a program that listed the names and addresses of all the
computers on a network to obtain an IP address that another
computer would recognize as friendly.
Sneaking In -- Once a "trusted" computer has been found,
the intruder sends a message to a computer on the network
using the "trusted" computer's IP address to ask for
certain rights and privileges for the intruder. The host
computer network, having no reason to deny the requested
privileges, then allows the intruder full access. Once the
intruder has gained access to a network, there are in many
cases no secondary security systems to prevent the intruder
from looking at and stealing whatever is on the network.
Source: Computer Emergency Response Team
----------
End
------- end -------
From cactus@hks.net Sat Jan 28 23:42:59 1995
Date: Sat, 28 Jan 1995 23:36:49 -0100
From: Todd Masco
To: hks-spooge@hks.net, bressen@cs.columbia.edu, elbows@mc.lcs.mit.edu
Subject: NYT article, for your amusement
Status: RO
I really, really love Shimomura's attitude.
(Summary: It's talking about the reaction of the 'victim' of the IP
spoofing attack that raised the hooplah.)
The New York Times
January 28, 1995, pp. 33, 42.
Taking a Computer Crime to Heart
[Photo] Tsutomu Shimomura, a computer security expert, was
the victim of a computer break-in that has raised an alarm
about Internet intrusion. He is a computational physicist
at the San Diego Supercomputer Center.
By John Markoff
It was as if the thieves, to prove their prowess, had
burglarized the locksmith. Which is why Tsutomu Shimomura,
the keeper of the keys in this case, is taking the break-in
as a personal affront -- and why he considers solving the
crime a matter of honor.
Mr. Shimomura, one of the country's most skilled computer
security experts, is the person who prompted a Government
computer agency to issue a chilling warning on Monday.
Unknown intruders, the agency warned, had used a
sophisticated break-in technique to steal files from Mr.
Shimomura's own well-guarded computer in his home near San
Diego. And the stealth and style of the attack indicated
that many of the millions of computers connected to the
global Internet network could be at risk. There have been
at least four other known victims so far, including
computers at Loyola University of Chicago, the University
of Rochester and Drexel University in Philadelphia.
Since Monday, as the F.B.I. has continued to investigate
the crime and look for evidence of break-ins elsewhere, Mr.
Shimomura has been answering telephone calls and E-mail
from government, corporate and university computer
administrators seeking advice on how to arm themselves.
Between replies, he has been working feverishly to perfect
a new type of protective software that would thwart the
burglars. Once it is finished, he intends to distribute the
software free over the Internet.
But more than anything else, Mr. Shimomura, who is 30,
wants to help the Government catch the crooks. And while he
acknowledges that the thieves were clever, Mr. Shimomura
has also uncovered signs of ineptitude that he says will be
the intruders' eventual undoing.
"Looks like the ankle-biters have learned to read technical
manuals," Mr. Shimomura said derisively. "Somebody should
teach them some manners. "
Already, investigators working with Mr. Shimomura's
assistance say they may have traced the source of the
break-ins to a computer somewhere in Ihe Philadelphia area.
But the burglars' identities remain unknown.
Until last week, Mr. Shimomura, a computational physicist
at the federally financed San Diego Supercomputer Center,
was primarily known only to an elite circle of the
country's computer security specialists. He is considered
an expert in safeguarding computers from anonymous
intruders -- whether pranksters out for a network joy ride,
or more malevolent types intent on industrial espionage,
stealing data or spreading software viruses.
The software security tools that he has designed have made
him a valuable consultant to the F.B.I., the Air Force and
the National Security Agency, as well as companies
including Sun Microsystems Inc. The tools have also
occasionally made him a target for computer burglars out to
test his and their own mettle.
That is how Mr. Shimomura interprets what happened on
Christmas Day, when computer burglars used the Internet to
hack their way into the network of powerful work stations
he keeps at his beach cottage. Having established this
connection, the intruders then assumed Mr. Shimomura's
electronic identity to move through the circuits that
connect his cottage to the San Diego Supercomputer Center
five miles away. The center is one of five around the
nation whose mission is to develop advanced computer
technology and use supercomputers to conduct research.
The thieves stole thousands of Mr. Shimomura's electronic
mail messages and other computer files, leaving behind
voice mail threatening his life and bragging about their
technical skills. He considers the voice mail to be among
the amateur mistakes, because truly skilled burglars would
leave the premises as silently as they had entered.
Mr. Shimomura said the attack symbolized a basic tension at
a time when millions of people are using the Internet and
thousands of businesses are flocking to the network with
visions of digital commerce dancing in their heads.
Ideally, access to and from the Internet is a freely
swinging two-way door. Practically speaking, however,
security measures are necessary to insure that those who
use the Internet have legitimate business to conduct on any
of the millions of computers with which they may try to
interact. The tightest security comes from erecting
so-called software fire walls; but the more secure the
wall, the less free the flow of information.
The balance that Mr. Shimomura chose to strike at his beach
house proved too lax.
"I thought I was reasonably secure," he said, "but I wanted
to be able to use my computer without hiding behind a fire
wall."
A Japanese citizen who has lived most of his life in the
United States, and who once studied with the Nobel
Prize-winning physicist Richard Feynman at the California
Institute of Technology, Mr. Shimomura is not the
stereotypical computer nerd. He was not home on Christmas
Day because he was on his way to the Sierra Nevada, where
he spends most of the winter as a self-described ski bum
and a volunteer for the cross-country ski patrol near Lake
Tahoe.
All the more reason he derides the geeks who had nothing
better to do on Christmas than sit at a computer and pry
into his electronic life.
"Gentlemen are not supposed to read each other's mail," he
said.
The Christmas attack exploited a flaw in the Internet's
design by fooling a target computer into believing that a
message was coming from a trusted source. Bv masquerading
as a familiar computer, an attacker can gain access to
protected computer resources and seize control of an
otherwise well-defended system.
In this case, intruders gained electronic entry into a
small Internet computer in the San Francisco Bay area and
used it as a staging area to look for weaknesses in the
computers in Mr. Shimomura's home and the San Diego
Supercomputer Center. Once this scouting mission was
completed, the intruders used a computer they had remotely
commandeered at Loyola University of Chicago to start a
full-scale attack on Mr. Shimomura's machines.
Though the vandals were deft enough to gain control of Mr.
Shimomura's computers, they made a clumsy error. One of his
machines routinely mailed a copy of several record-keeping
files to a safe computer elsewhere on the network -- a fact
that the intruders did not notice. That led to an automatic
warning to the San Diego Supercomputer Center employees
that an attack was under way. This allowed the center's
staff to throw the burglars off the system within a day; it
also later allowed Mr. Shimomura to reconstruct the attack.
So far, the only known defense against this form of
break-in involves making sophisticated hardware or software
modifications to computer sites connected to the Internet.
But Mr. Shimomura is now at work on a software filter that
he hopes will make it easier to ward off such attacks. When
it is finished, it could make it virtually impossible for
an outsider to masquerade as a trusted computer to gain
entry to his system or any other computer armed with the
software.
"It keeps detailed records of attempted attacks and
immediately sets off an alarm," Mr. Shimomura said.
The ankle-biters, he warned, will test it at their peril.
From not-for-mail Mon Jan 30 18:05:10 EST 1995
From: dean@tbone.biol.scarolina.edu (Dean Pentcheff)
Subject: Re: CERT advisory -- details
Date: 30 Jan 1995 02:32:44 -0500
Status: RO
A few days ago I posted a plea to the cognoscenti to help the clueless
(like me) on the exact implications of the "new" security problem. I'm
in a situation where I know a little about TCP/IP networking, but not
enough to know offhand which services are really involved in the
problem.
One of the most helpful replies I received (from Charles Hedrick
) is appended. With his permission, I'm
posting it to the groups for the edification of others.
Of course, if something here is incorrect, we'd appreciate hearing
about it!
-Dean
--
N. Dean Pentcheff
Biological Sciences, Univ. of South Carolina, Columbia SC 29208
(803-777-3936)
Internet addresses: pentcheff@pascal.acm.org or dean@tbone.biol.scarolina.edu
WWW link: home page
P.S. Although I made a despairing comment (below) about the likelihood of
our organization reworking its routers to address the problem, I've since
found out that computer services is, in fact, investigating how to do
so.
=============================================================================
Quoted sections are from my query, unquoted text is Charles Hedrick's reply.
One corrected (I think) typo is in square brackets within the text.
=============================================================================
>From hedrick@farside.rutgers.edu Sun Jan 29 22:16:26 1995
Return-Path:
Date: Sun, 29 Jan 1995 22:16:17 -0500
From: Charles Hedrick
To: dean@tbone.biol.scarolina.edu
Subject: Re: CERT advisory -- details
In comp.security.unix you write:
>OK, but I'm in the middle. I am responsible for the administration of
>a small collection of Internet-connected machines (Suns and others). I
>have precisely no control over router policies here. How should I
>proceed?
A lot of sites are betting that they won't become targets, and that
the hackers are mostly benign. Keep good backups. If you are
worried, than I think any serious defense is going to require at least
some kind of firewall. At the moment disabling the r protocols would
be enough, but if you use NFS or X, you're eventually going to become
vulnerable. Without some kind of router that you control, you're
stuck -- if problems develop, you have no options other than pulling
the plug.
This is a discouraging view, because I am a senior manager in a campus
computing organization that doesn't let departments control the
routers in their area, and doesn't have the manpower to do any filters
of our own. So we're leaving our departments with no solution. I
happen to manage computing for computer science personally, so I'm in
a position to install filters in the CS router. I've done so. I
think if I were in another department I'd be seriously considering
buying a router of my own to sit between the campus router and my
network. But that's a matter of how critical the information is, and
your attitude towards risk. People can come in and plant bombs too,
but we don't all put armor plate on our doors.
>- What remote access procedures actually use the targeted form
> of authentication?
> Telnet?
> FTP?
> rsh?
> others?
only rsh, rlogin, rdist, etc, at the moment. telnet and ftp are OK,
though they rely on passwords, and those have their own problems.
Probably the best compromise for academic security is to allow rsh and
NFS without [within?] your site, but allow only telnet and ftp from
outside, and requires one-time passwords for that. Enforcing that
requires a router or other firewall. But I have to say that I haven't
gone that far yet in CS (though I have on the subnet that my staff
use).
>- What are "risky" procedures?
> Any logins at all, even from the console?
no
> Logins from within the local net?
> Logins from remote sites?
mostly remote (though you have to look at your user community. Our
student machines are generally pretty full of hackers, so inside
logins are a problem too). But the problem is that there's no
reliable way to tell what's remote. That's the whole point of
the attack.
>- Short of getting my institution to rework all its routers (yeah,
> right), what can I do, as a lone administrator, to minimize the risks
> from this "new" form of attack?
That's very unclear. Here's what I'd suggest:
- rcommands: see if you can do something with tcpd. I don't know
it very well, but I think you may be able to get it to
call authd on the host the connection is coming from.
It's not entirely secure, but I'd be inclined to see if
I could set up tcpd to only accept connections if you can
authenticate the user at the other end with authd, and
run authd on all your machines. Make sure you don't allow
r commands from off your network. (You need to either look
at all users .rhosts or something. But beware that this
attack makes it hard to know whether things are from off
your network or not.) authd is far from secure, but
it has the advantage that you're initiating the query
from your side. If you only allow a list of hosts that
you control, then authd authentication stuck on top of
the r protocols ought to be good enough. But you may
have to hack tcpd to do this yourself. (This is not a bad
thing. Net-wide attacks would be much harder if each site
took a slightly different approach.)
- NFS: make sure you've followed all the security bulletins, e.g.
not exporting to your own address. You might try using
secure NFS, if it doesn't cause too much of a performance
problem. It's been cryptographically broken, but I doubt
the attackers we're doing with are going to mount a
cryptographic attack.
- X: make sure you use at least MIT magic cookie, not xhost.
If your users have the same home directory on all machines
this is easy. Otherwise, you need to use xrsh, which will
send the info to the remote machine. Note that X is likely
to become an area of attack in the future. There are lots
of scary problems with it, but so far people haven't been
doing as much as they could.
But I have to say that our site isn't going even this far.
==============================================================================
Note: my signature will get tacked on the end here, but the substantive text
above was written by Charles Hedrick .
From lefebvre Thu Feb 16 23:54:53 EST 1995
From: lefebvre@dis.anl.gov (William LeFebvre)
Subject: "Most wanted" Cracker caught!
Date: 16 Feb 1995 19:53:30 GMT
Status: RO
Yesterday morning they arrested someone whom they believed was
responsible for the Christmas breakin of Tsutomu Shimomura's machine.
This was the attack that combined denial of service with IP source
address spoofing. It was analyzed post-mortem by Shimomura and the
analysis was posted here not too long ago. This was the attack that
got everyone in the Internet community really worried about IP source
address spoofing (see CERT advisory 95:01).
The guy arrested is Kevin Mitnick of Raleigh, NC, and according to the
news article was a "convicted computer felon on the run from federal
law enforcement officials since November 1992".
According to the article, after the breakin Shimomura made it his
personal crusade to track the guy down, even going so far as to fly
out to Raleigh to help local officials track the cracker thru the
phone system there.
Grab a paper and read all about it!
William LeFebvre
Decision and Information Sciences
Argonne National Laboratory
lefebvre@dis.anl.gov
==========================================================
From not-for-mail Thu Feb 16 12:42:51 EST 1995
From: tomkaiser@aol.com (Tomkaiser)
Subject: Re: hacker kevin metnick caught in nc
Date: 16 Feb 1995 10:05:34 -0500
Status: RO
This can be found at http://www.nando.net/newsroom/nt/nation7.html:
Slippery cybervandal caught in his own electronic web
-----------------------------------------------------
(c) Copyright the News & Observer Publishing Co.
How a computer sleuth traced a digital trail
New York Times
RALEIGH, N.C. (9:05 p.m.) -- After a search of more than two years, a team
of FBI agents early Wednesday morning captured a 31-year-old computer expert
accused of a long crime spree that includes the theft of thousands of data
files and at least 20,000 credit card numbers from computer systems
around the
nation.
The arrest of Kevin D. Mitnick, one of the most wanted computer criminals,
followed a 24-hour stakeout of a Raleigh apartment building here.
A convicted computer felon on the run from federal law enforcement
officials since November 1992, Mitnick has used his sophisticated skills
over the years to worm his way into many of the nation's telephone and
cellular telephone networks and vandalize government, corporate and
university computer systems. Most recently, he had become a suspect in a
rash of break-ins on the global Internet computer network.
"He was clearly the most wanted computer hacker in the world," said Kent
Walker, an assistant U.S. attorney in San Francisco who helped coordinate
the investigation. "He allegedly had access to corporate trade secrets
worth billions of dollars. He was a very big threat."
But federal officials say Mitnick's confidence in his hacking skills may
have been his undoing. On Christmas Day, he broke into the home computer of
a computer security expert, Tsutomu Shimomura, a researcher at the
federally financed San Diego Supercomputer Center.
Shimomura then made a crusade of tracking down the intruder, an obsession
that led to Wednesday's arrest.
It was Shimomura, working from a monitoring post in San Jose, Calif., who
determined last Saturday that Mitnick was operating through a computer
modem connected to a cellular telephone somewhere near Raleigh, N.C.
Sunday morning, Shimomura flew to Raleigh, where he helped telephone
company technicians and federal investigators use cellular-frequency
scanners to home in on Mitnick.
Mitnick was arrested at 2 o'clock Wednesday morning in his apartment in the
Duraleigh Hills neighborhood of northwest Raleigh, after FBI agents used
their scanners to determine that Mitnick, in keeping with his nocturnal
habits, had connected once again to the Internet.
Shimomura was present Wednesday at Mitnick's pre-arraignment hearing at the
federal courthouse in Raleigh. At the end of the hearing, Mitnick, who now
has shoulder-length brown hair and was wearing a black sweat suit and
handcuffs, turned to Shimomura, whom he had never met face to face.
"Hello, Tsutomu," Mitnick said. "I respect your skills."
Shimomura, who is 30 and also has shoulder-length hair, nodded solemnly.
Mitnick, already wanted in California for a federal parole violation, was
charged Wednesday with two federal crimes. The first, illegal use of a
telephone access device, is punishable by up to 15 years in prison and a
$250,000 fine.
The second charge, computer fraud, carries potential penalties of 20 years
in prison and a $250,000 fine. Federal prosecutors said they were
considering additional charges related to Mitnick's reported Internet spree.
Federal officials say Mitnick's motives have always been murky. He was
recently found to have stashed thousands of credit card numbers on
computers in the San Francisco Bay area -- including the card numbers of
some of the best-known millionaires in Silicon Valley. But there is no
evidence yet that Mitnick had attempted to use those credit card accounts.
Indeed, frequently ignoring the possibility of straightforward financial
gain from the information he has stolen, Mitnick has often seemed more
concerned with proving that his technical skills are better than those
whose job it is to protect the computer networks he has attacked.
Federal officials say the arrest of Mitnick does not necessarily solve all
the recent Internet crimes, because his trail of electronic mail has
indicated that he may have accomplices. One of them is an unknown computer
operator, thought to be in Israel, with whom Mitnick has corresponded
electronically and boasted of his Internet exploits, investigators said.
Still, the capture of Mitnick gives the FBI custody of a notoriously
persistent and elusive computer break-in expert. Raised in the San Fernando
Valley near Los Angeles by his mother, Mitnick has been in and out of
trouble with the law since 1981.
It was then, as a 17-year-old, that he was placed on probation for stealing
computer manuals from a Pacific Bell telephone switching center in Los
Angeles.
Those who know Mitnick paint a picture of a man obsessed with the power
inherent in controlling the nation's computer and telephone networks.
The recent break-ins he is accused of conducting include forays into
computer systems at Apple Computer Inc. and Motorola Inc. and attacks on
commercial services that provide computer users with access to the
Internet, including the Well in Sausalito, Calif., Netcom in San Jose,
Calif., and the Colorado Supernet, in Boulder, Colo.
To make it difficult for investigators to determine where the attacks were
coming from, Mitnick is said to have used his computer and modem to
manipulate a local telephone company switch in Raleigh to disguise his
whereabouts.
In recent weeks, as an elite team of computer security experts tightened an
invisible electronic net around the fugitive, Mitnick continued to taunt
his pursuers, apparently unaware of how close they were to capturing him.
About 10 days ago, for example, someone whom investigators believe to have
been Mitnick left a voice-mail message for Shimomura, a Japanese citizen.
The message reprimanded Shimomura for converting the intruder's earlier
voice-mail messages into computer audio files and making them available on
the Internet.
"Ah Tsutomu, my learned disciple," the taunting voice said. "I see that you
put my voice on the Net. I'm very disappointed, my son."
But the continued attempts at one-upmanship simply gave the pursuers more
electronic evidence.
"He was a challenge for law enforcement, but in the end he was caught by
his own obsession," said Kathleen Cunningham, a deputy marshal for the U.S.
Marshals Service who has pursued Mitnick for several years.
Mitnick first came to national attention in 1982 when, as a teen-age prank,
he used a computer and a modem to break into a North American Air Defense
Command computer.
He subsequently gained temporary control of three central offices of
telephone companies in New York City and all the phone switching centers in
California.
This gave him the ability to listen in on calls and pull pranks like
reprogramming the home phone of someone he did not like so that each time
the phone was picked up, a recording asked for a deposit of a coin.
But the break-ins escalated beyond sophomoric pranks. For months in 1988,
Mitnick secretly read the electronic mail of computer security officials at
MCI Communications and Digital Equipment Corp., learning how their
computers and phone equipment were protected.
Officials at Digital later accused him of causing $4 million in damage to
computer operations at the company and stealing $1 million of software. He
was convicted in July 1989 and sentenced to a year in a low-security
federal prison in Lompoc, Calif.
One of his lawyers convinced the court that Mitnick had an addiction to
computers. In July 1989, after his release from prison, he was placed in a
treatment program for compulsive disorders, the Beit T'Shuvah center in Los
Angeles. During his six months there, he was prohibited from touching a
computer or modem.
That restriction was a condition of his probation when he was released in
mid-1990, and it was for reportedly violating this condition that federal
officials were pursuing him when he dropped out of sight in November 1992.
In September 1993, the California Department of Motor Vehicles also issued
a warrant for his arrest. The warrant stated that Mitnick had wiretapped
calls from FBI agents. He then used law-enforcement access codes obtained
by eavesdropping on the agents to illegally gain access the drivers'
license data base in California.
Federal law enforcement officials believe that Mitnick has conducted a long
string of computer and phone telephone network break-ins during more than
two years on the run.
And they say his ability to remain at large until now illustrates the new
challenges that law enforcement officials face in apprehending criminals
who can cloak themselves behind a curtain of forged electronic data.
--------------------------------------------------------------------------
... From San Jose Mercury, www.sjmercury.com/today/...
INTERNET FUGITIVE CAUGHT
** Most wanted: Arrest of cyberspace criminal ends two-week electronic
manhunt.
By Rory J. O'Connor
and David Bank
Mercury News Staff Writers
Federal authorities arrested the nation's most wanted cyberspace
fugitive, Kevin Mitnick, early Wednesday, after a two-week electronic
manhunt that led the FBI from a San Diego computer security expert to
an eclectic on-line service in Sausalito and finally to an apartment
in Raleigh, N.C.
Authorities arrested Mitnick there at 1:30 a.m. Wednesday, and charged
him with breaking into the Internet computer of one of the country's
foremost computer security experts. The break-in netted Mitnick a
wealth of confidential data on the latest security techniques.
They also charged Mitnick, known in hacker circles by his handle
``Condor,'' for breaking into several other computer systems,
including The WELL service in Sausalito and San Jose-based Netcom
Inc., stealing credit card numbers, cellular phone codes, security
tools and other proprietary information from several high-technology
companies.
His arrest may calm, at least temporarily, panicky Internet users who
feared a dangerous hacker was loose on the world-wide network of
computers, armed with tools that would let him break into computers
protected by even the most sophisticated measures.