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

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 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 
     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
        - 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 
        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


           Bellovin paper:
           Morris paper:

        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; 
               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

        In taking over the existing connections, intruders can bypass 
        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

        Currently, the tool is used primarily on SunOS 4.1.x systems. 
        the system features that make this attack possible are not unique to

II. Impact

     Current intruder activity in spoofing source IP addresses can lead to
     unauthorized remote root access to systems behind a filtering-router

     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
              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 
           that will no longer respond to their commands. Encourage your 
           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

     B. Prevention

        IP spoofing
           The best method of preventing the IP spoofing problem is to 
           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 
           by using a second router between your external interface and your
           outside connection. Configure this router to block, on the 
           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 
           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

The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith 
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, or PEM (contact
CERT staff for details).

Internet E-mail:
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

Past advisories, CERT bulletins, information about FIRST representatives,
and other information related to computer security are available for 
FTP from

CERT is a service mark of Carnegie Mellon University.

From firewalls-owner@GreatCircle.COM Tue Jan 24 07:26:54 1995
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

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

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

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

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:

From firewalls-owner@GreatCircle.COM Tue Jan 24 10:00:49 1995
Date: Tue, 24 Jan 1995 09:10:08 -0500
From: (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 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 
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 
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 (this info derived from packet logs):

14:09:32 finger -l @target
14:10:21 finger -l @server
14:10:50 finger -l root@server
14:11:07 finger -l @x-terminal
14:11:38 showmount -e x-terminal
14:11:49 rpcinfo -p x-terminal
14:12:05 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 
with an IP spoofing attack.  The source port numbers for the showmount and
rpcinfo indicate that the attacker is root on


About six minutes later, we see a flurry of TCP SYNs (initial connection
requests) from 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). appears to be
a random (forged) unused address (one that will not generate any response
to packets sent to it):

14:18:22.516699 > server.login: S 
1382726960:1382726960(0) win 4096
14:18:22.566069 > server.login: S 
1382726961:1382726961(0) win 4096
14:18:22.744477 > server.login: S 
1382726962:1382726962(0) win 4096
14:18:22.830111 > server.login: S 
1382726963:1382726963(0) win 4096
14:18:22.886128 > server.login: S 
1382726964:1382726964(0) win 4096
14:18:22.943514 > server.login: S 
1382726965:1382726965(0) win 4096
14:18:23.002715 > server.login: S 
1382726966:1382726966(0) win 4096
14:18:23.103275 > server.login: S 
1382726967:1382726967(0) win 4096
14:18:23.162781 > server.login: S 
1382726968:1382726968(0) win 4096
14:18:23.225384 > server.login: S 
1382726969:1382726969(0) win 4096
14:18:23.282625 > server.login: S 
1382726970:1382726970(0) win 4096
14:18:23.342657 > server.login: S 
1382726971:1382726971(0) win 4096
14:18:23.403083 > server.login: S 
1382726972:1382726972(0) win 4096
14:18:23.903700 > server.login: S 
1382726973:1382726973(0) win 4096
14:18:24.003252 > server.login: S 
1382726974:1382726974(0) win 4096
14:18:24.084827 > server.login: S 
1382726975:1382726975(0) win 4096
14:18:24.142774 > server.login: S 
1382726976:1382726976(0) win 4096
14:18:24.203195 > server.login: S 
1382726977:1382726977(0) win 4096
14:18:24.294773 > server.login: S 
1382726978:1382726978(0) win 4096
14:18:24.382841 > server.login: S 
1382726979:1382726979(0) win 4096
14:18:24.443309 > server.login: S 
1382726980:1382726980(0) win 4096
14:18:24.643249 > server.login: S 
1382726981:1382726981(0) win 4096
14:18:24.906546 > server.login: S 
1382726982:1382726982(0) win 4096
14:18:24.963768 > server.login: S 
1382726983:1382726983(0) win 4096
14:18:25.022853 > server.login: S 
1382726984:1382726984(0) win 4096
14:18:25.153536 > server.login: S 
1382726985:1382726985(0) win 4096
14:18:25.400869 > server.login: S 
1382726986:1382726986(0) win 4096
14:18:25.483127 > server.login: S 
1382726987:1382726987(0) win 4096
14:18:25.599582 > server.login: S 
1382726988:1382726988(0) win 4096
14:18:25.653131 > 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 to
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 > S 
1382726990:1382726990(0) win 4096
14:18:26.094731 > S 
2021824000:2021824000(0) ack 1382726991 win 4096
14:18:26.172394 > R 
1382726991:1382726991(0) win 0
14:18:26.507560 > S 
1382726991:1382726991(0) win 4096
14:18:26.694691 > S 
2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 > R 
1382726992:1382726992(0) win 0
14:18:26.775395 > R 
1382726992:1382726992(0) win 0
14:18:27.014050 > S 
1382726992:1382726992(0) win 4096
14:18:27.174846 > S 
2022080000:2022080000(0) ack 1382726993 win 4096
14:18:27.251840 > R 
1382726993:1382726993(0) win 0
14:18:27.544069 > S 
1382726993:1382726993(0) win 4096
14:18:27.714932 > S 
2022208000:2022208000(0) ack 1382726994 win 4096
14:18:27.794456 > R 
1382726994:1382726994(0) win 0
14:18:28.054114 > S 
1382726994:1382726994(0) win 4096
14:18:28.224935 > S 
2022336000:2022336000(0) ack 1382726995 win 4096
14:18:28.305578 > R 
1382726995:1382726995(0) win 0
14:18:28.564333 > S 
1382726995:1382726995(0) win 4096
14:18:28.734953 > S 
2022464000:2022464000(0) ack 1382726996 win 4096
14:18:28.811591 > R 
1382726996:1382726996(0) win 0
14:18:29.074990 > S 
1382726996:1382726996(0) win 4096
14:18:29.274572 > S 
2022592000:2022592000(0) ack 1382726997 win 4096
14:18:29.354139 > R 
1382726997:1382726997(0) win 0
14:18:29.354616 > R 
1382726997:1382726997(0) win 0
14:18:29.584705 > S 
1382726997:1382726997(0) win 4096
14:18:29.755054 > S 
2022720000:2022720000(0) ack 1382726998 win 4096
14:18:29.840372 > R 
1382726998:1382726998(0) win 0
14:18:30.094299 > S 
1382726998:1382726998(0) win 4096
14:18:30.265684 > S 
2022848000:2022848000(0) ack 1382726999 win 4096
14:18:30.342506 > R 
1382726999:1382726999(0) win 0
14:18:30.604547 > S 
1382726999:1382726999(0) win 4096
14:18:30.775232 > S 
2022976000:2022976000(0) ack 1382727000 win 4096
14:18:30.852084 > R 
1382727000:1382727000(0) win 0
14:18:31.115036 > S 
1382727000:1382727000(0) win 4096
14:18:31.284694 > S 
2023104000:2023104000(0) ack 1382727001 win 4096
14:18:31.361684 > R 
1382727001:1382727001(0) win 0
14:18:31.627817 > S 
1382727001:1382727001(0) win 4096
14:18:31.795260 > S 
2023232000:2023232000(0) ack 1382727002 win 4096
14:18:31.873056 > R 
1382727002:1382727002(0) win 0
14:18:32.164597 > S 
1382727002:1382727002(0) win 4096
14:18:32.335373 > S 
2023360000:2023360000(0) ack 1382727003 win 4096
14:18:32.413041 > R 
1382727003:1382727003(0) win 0
14:18:32.674779 > S 
1382727003:1382727003(0) win 4096
14:18:32.845373 > S 
2023488000:2023488000(0) ack 1382727004 win 4096
14:18:32.922158 > R 
1382727004:1382727004(0) win 0
14:18:33.184839 > S 
1382727004:1382727004(0) win 4096
14:18:33.355505 > S 
2023616000:2023616000(0) ack 1382727005 win 4096
14:18:33.435221 > R 
1382727005:1382727005(0) win 0
14:18:33.695170 > S 
1382727005:1382727005(0) win 4096
14:18:33.985966 > S 
2023744000:2023744000(0) ack 1382727006 win 4096
14:18:34.062407 > R 
1382727006:1382727006(0) win 0
14:18:34.204953 > S 
1382727006:1382727006(0) win 4096
14:18:34.375641 > S 
2023872000:2023872000(0) ack 1382727007 win 4096
14:18:34.452830 > R 
1382727007:1382727007(0) win 0
14:18:34.714996 > S 
1382727007:1382727007(0) win 4096
14:18:34.885071 > S 
2024000000:2024000000(0) ack 1382727008 win 4096
14:18:34.962030 > R 
1382727008:1382727008(0) win 0
14:18:35.225869 > S 
1382727008:1382727008(0) win 4096
14:18:35.395723 > S 
2024128000:2024128000(0) ack 1382727009 win 4096
14:18:35.472150 > R 
1382727009:1382727009(0) win 0
14:18:35.735077 > S 
1382727009:1382727009(0) win 4096
14:18:35.905684 > S 
2024256000:2024256000(0) ack 1382727010 win 4096
14:18:35.983078 > R 
1382727010:1382727010(0) win 0

Note that each SYN-ACK packet sent by x-terminal has an initial sequence 
which is 128,000 greater than the previous one.


We now see a forged SYN (connection request), allegedly from server.login
to  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 > S 
1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > . ack 2024384001 win 4096


The spoofing machine now has a one-way connection to 
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 > P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > 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 > . ack 2 win 4096
14:18:42.255978 server.login > . ack 3 win 4096
14:18:43.165874 server.login > F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > R 
1382727043:1382727043(0) win 4096
14:18:52.236452 server.login > 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 > server.login: R 
1382726960:1382726960(0) win 4096
14:18:52.363877 > server.login: R 
1382726961:1382726961(0) win 4096
14:18:52.416916 > server.login: R 
1382726962:1382726962(0) win 4096
14:18:52.476873 > server.login: R 
1382726963:1382726963(0) win 4096
14:18:52.536573 > server.login: R 
1382726964:1382726964(0) win 4096
14:18:52.600899 > server.login: R 
1382726965:1382726965(0) win 4096
14:18:52.660231 > server.login: R 
1382726966:1382726966(0) win 4096
14:18:52.717495 > server.login: R 
1382726967:1382726967(0) win 4096
14:18:52.776502 > server.login: R 
1382726968:1382726968(0) win 4096
14:18:52.836536 > server.login: R 
1382726969:1382726969(0) win 4096
14:18:52.937317 > server.login: R 
1382726970:1382726970(0) win 4096
14:18:52.996777 > server.login: R 
1382726971:1382726971(0) win 4096
14:18:53.056758 > server.login: R 
1382726972:1382726972(0) win 4096
14:18:53.116850 > server.login: R 
1382726973:1382726973(0) win 4096
14:18:53.177515 > server.login: R 
1382726974:1382726974(0) win 4096
14:18:53.238496 > server.login: R 
1382726975:1382726975(0) win 4096
14:18:53.297163 > server.login: R 
1382726976:1382726976(0) win 4096
14:18:53.365988 > server.login: R 
1382726977:1382726977(0) win 4096
14:18:53.437287 > server.login: R 
1382726978:1382726978(0) win 4096
14:18:53.496789 > server.login: R 
1382726979:1382726979(0) win 4096
14:18:53.556753 > server.login: R 
1382726980:1382726980(0) win 4096
14:18:53.616954 > server.login: R 
1382726981:1382726981(0) win 4096
14:18:53.676828 > server.login: R 
1382726982:1382726982(0) win 4096
14:18:53.736734 > server.login: R 
1382726983:1382726983(0) win 4096
14:18:53.796732 > server.login: R 
1382726984:1382726984(0) win 4096
14:18:53.867543 > server.login: R 
1382726985:1382726985(0) win 4096
14:18:53.917466 > server.login: R 
1382726986:1382726986(0) win 4096
14:18:53.976769 > server.login: R 
1382726987:1382726987(0) win 4096
14:18:54.039039 > server.login: R 
1382726988:1382726988(0) win 4096
14:18:54.097093 > 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

These are in Sun audio file format, 8-bit u-law, 8 khz sample rate.

Tsutomu Shimomura        +1 619 534 5050 
University of California at San Diego/San Diego Supercomputer Center, USA

From Wed Jan 25 09:30:49 1995
Date: Wed, 25 Jan 1995 08:04:31 cst
Subject: Re: IP spoofing -- assessment
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 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 
 (1) this attack, in an even more elementary form, was launched, 
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
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 
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 
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 
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 
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 
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' ;)


Capt Kevin J. Ziese                         
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 Wed Jan 25 10:28:17 1995
From: (Paul Ferguson)
Subject: Re: IP spoofing -- assessment
Date: Wed, 25 Jan 1995 10:02:11 -0500 (EST)
Status: RO 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.  
> ip spoofing is bad, but the ankle biters are worse because our systems 
> 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:

        - 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 
                tapc*   - are the names of the STREAMS-driver nodes (special

        - 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 
          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 
          are send to modules/streamshead above the tap-module 

        - 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 
          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

        - 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 
          option in sunos to autopush any modules on open() (that's different
          in a SYSV environment).


       (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 |         
        +----------+          | |          | |        +----------+
        |    \ \   |          | |          | |        | TAP 1    |
        |     \ \--|<---------/ |          | \--------|\  MODULE |
        | TAP 0\---|------------/          \--------->| \  PUSHED|
        | MODULE   |                                  |\ \REVERSE|
        | PUSHED   |                                  | \ \ OPEN |
        |          |  <--- NORMAL       REVERSE--->   |  \ \     |
        +----------+                                  +----------+
             | ^                                       (4)| ^(3)        LOWER

             v |                                          v |           
        ............                                  ............
        . 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,
                                        (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:
Reston, Virginia  USA                     

From Wed Jan 25 16:58:54 1995
Date: Wed, 25 Jan 1995 16:51:26 -0100
From: Todd Masco 
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 
   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." 

   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 -------

From Sat Jan 28 23:42:59 1995
Date: Sat, 28 Jan 1995 23:36:49 -0100
From: Todd Masco 
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 

   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 

   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 

   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 

   "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 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

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!

N. Dean Pentcheff 
Biological Sciences, Univ. of South Carolina, Columbia SC 29208 
Internet addresses: or
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 
 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  Sun Jan 29 22:16:26 1995
Date: Sun, 29 Jan 1995 22:16:17 -0500
From: Charles Hedrick 
Subject: Re: CERT advisory -- details

In 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

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

>- What are "risky" procedures?
>       Any logins at all, even from the console?
>       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: (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


From not-for-mail Thu Feb 16 12:42:51 EST 1995
From: (Tomkaiser)
Subject: Re: hacker kevin metnick caught in nc
Date: 16 Feb 1995 10:05:34 -0500
Status: RO

This can be found at

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

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

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

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

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,

                        INTERNET FUGITIVE CAUGHT

** Most wanted: Arrest of cyberspace criminal ends two-week electronic

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

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.