ASK WOODY about SPOOFING ATTACKS

Bill Woodcock, Zocalo Engineering (woody@zocalo.com)



Q: I have a consulting client that wants to get connected to the Internet, but I've been reading in the
popular press about the many security concerns that entails. What are the potential risks and
vulnerabilities my client would face? What is a firewall, and how could one protect my client? What's
an Ethernet data encryptor, and would that be any help? 

Michael Lipson, Macintosh Consultant, TeamNet Technologies, San Francisco, California. 

Q: Alright; I give up; I've read much about the spoofing incident that occurred recently, but none of
the reporters had any idea what they were talking about; can you explain what spoofing really is, and
what happened that got the press all excited? 

Q: How could a router get confused, and think that an external address is actually an internal
address? I know I'm gonna read shortly in Wired's Jargon-Watch column that someone in the office
spoofed the job of his superior or that some marketeer spoofed his competitors presentation; I'd like
to understand what it really means before it's too late. 

Stuart Fischbach, Networking Consultant, S'Ware, Danbury, Connecticut. 

Q: A recent CERT advisory describes an IP spoofing attack that relies on the predictability of TCP
sequence numbers generated by Berkeley kernels. Does the fact that A/UX is System V based
exempt it from this kind of attack? 

Fred Condo, System Administrator, Lightside Corporation, Covina, California. 

A: The press' recent reports on the spoofing attack on a diskless workstation at the San Diego
Supercomputer Center last December 25 have spurred a great many people to reexamine security at
their Internet-connected sites, and a general lack of understanding of the issues involved has lead the
non-technically inclined press to propagate misinformation about the specific attack and about
security on the Internet in general. 

An unfortunate result is that during the past few weeks a great many network administrators have
suddenly been told to do something about this spoofing thing by people who know only what they've
gleaned from alarmist reports in the press. 

The first and most important thing to understand in connection with the explosion of paranoia is that
Macintoshes running the Macintosh operating system, even if theyre running MacTCP and operating
as servers on the Internet, are not vulnerable to this threat in any way. 

The specific attack which prompted the flurry of press coverage relied upon three factors: 

1. The network on which the target machine resided was connected to the Internet by means of a
router which allowed packets with local IP source addresses to enter from its Internet side. Despite
widespread knowledge that this is a security hole, this has been standard behavior heretofore,
although in the wake of the press attention paid this attack, many network administrators are
emplacing filters to discard such packets in the future. 

2. The target machine used a predictable method of generating TCP sequence numbers. A sequence
number is the numerical tag common to a stream of packets between any two devices that serves to
identify those packets as belonging to a transaction unique from any others. In other words, they tell a
machine which of the many conversations it's conducting an incoming packet is associated with.
Sequence numbers were intended to be random, but under Berkeley Software Distribution-based
Unix systems, they're actually very predictable, since the Unix host simply increments the number by
a fixed amount each second, and for each new transaction. This is an unfortunate feature common to
many Unix implementations 

3. The target machine was part of a web of trusted hosts, which had special permissions with respect
to each other. The collection of software which implements the trusted-host relationships is
sometimes referred to as the r-utilities, since most of the individual pieces begin with the letter r, short
for remote. Specifically, utilities like rsh, which opens a shell on a remote host, and rlogin, which
opens a terminal session on a remote host, are points of vulnerability. These utilities are commonly
used on Unix machines everywhere. 

Each of these three criteria must be met for this particular sort of attack to succeed. 

This combination of factors, while common enough on Unix hosts at large sites, does not occur at all
on MacOS-using Macintoshes, since they don't meet the third criterion: none of the Unix utilities
which are exploited after the first two conditions are met can run under the Macintosh operating
system. Even ported versions, if they were to become available, would not make the Macintosh
vulnerable, since the vulnerability is really not in the utilities themselves, but in the nature of a multiuser
permissions-based operating system. 

Apple's A/UX based Workgroup Servers and workstations are potentially at risk, if both the other
conditions are met, and utilities like rlogin, rsh, and the like are running. Since these utilities aren't
necessary to the operation of a purely AppleTalk-serving Workgroup Server, they can be safely
turned off if that's all youre using your server for, by disabling the appropriate ports in /etc/servers or
/etc/services. 

Since those utilities are often essential to the way Unix-users work, and removing them doesn't guard
against other methods of intrusion anyway, most sites may more profitably address the first criterion
on the list, IP packets with local trusted source addresses (i.e. spoofed packets) entering the network
from outside. 

Spoofing/TCP Sequence Prediction Attack Explained

The attack on the SDSC workstation rigorously followed the steps outlined in Robert Morris' (Sr.,
the security expert, not Jr., author of the Internet Worm) 1985 paper "A Weakness in the 4.2BSD
Unix TCP/IP Software". That paper described a security hole in the r-utilities, which use IP address
as a means of authenticating trusted hosts. Users or machine administrators can define a list of hosts
which can execute commands or open shells remotely with special privileges, as though by a user
operating from within a local account. This is a great convenience in a low-security atmosphere with a
high degree of trust, where users maintain accounts on multiple hosts, and must work back and forth
between them frequently. Unfortunately, it also creates a potential problem, spoofing, wherein an
unauthorized host sends packets purporting to be from a trusted host, and takes advantage of the
special permissions allotted the trusted host. 

Two mechanisms exist to prevent this in even an otherwise unprotected network. 

First and most simply, when a packet seeking to initiate a TCP circuit (TCP SYN) is sent to the
target host using the forged address of a trusted host, the target host will acknowledge the request
with a response (TCP SYN_RCVD) directed to the trusted host, not the machine which actually
forged and sent the packet. The trusted host, seeing an acknowledgment of a packet it has no record
of having sent, will send a packet (TCP RST) back to the target, telling it to tear down the circuit. 

Second, and slightly more complicated, IP hosts use a 32-bit number to uniquely identify TCP
circuits, such that it can determine which of many open circuits any newly-received TCP packet
belongs to. If a host uses forgery to open a TCP connection putatively between the target and a
trusted host, it will never see any packets sent by the target host, including the one which assigns the
sequence number, necessary to correctly tag packets so that the target will recognize them as
belonging to the forged circuit. 

In addition, there's the more general difficulty of maintaining a useful connection to a remote host
when you can't see any replies from that host. 

Both of the two technical problems are unfortunately surmountable, as documented in Morris' paper. 

To nullify the problem of the trusted host tearing down any circuit a forger requests, and generally
prevent it from responding to packets sent to it through a forged circuit, a port on that host is chosen
which is only intended to listen for incoming connections. Such ports have limited capacity to deal
with unanticipated problems like unrequested circuits being acknowledged. Specifically, they have a
queue of limited length for dealing with incoming connection requests; since a host which requests a
circuit of the trusted host has, by definition, IP connectivity with the trusted host, the trusted host
assumes that a small queue will be all that's necessary for stacking up such packets, since they'll be
quickly dealt with. If, however, it receives connection requests from hosts which are unreachable, not
normally a possibility, this queue can be overrun, and the trusted host will no longer be able to deal
with new connection requests on that port. Thus the forger must send a flurry of also-forged
connection requests to the port it wishes to emulate on the trusted host, using bogus and unreachable
sender addresses. This busies out that port on the trusted host, leaving it unable to send a TCP RST
packet to the target. 

Unfortunately it turns out that the second problem, determining the sequence number of a circuit you
cannot see, is easier than it should be. Whereas sequence numbers should be pseudorandom, most
types of Unix actually generate them by simply adding some number to the sequence number
assigned to the most recently created circuit. Thus by attempting several sequential new connections
to the target host using its own real address, the forging machine can determine the pattern by which
sequence numbers are being generated, and predict the next one to be assigned with reasonable
accuracy. 

To put these parts together into a whole attack, the forger first uses utilities like finger, showmount,
and rpcinfo to determine what relationships of trust may exist between the target host and other
hosts. Next, the forger chooses a machine which has a trusted host relationship to the target machine,
and busies out one of its listener ports. Port 513, the login port, was chosen in the actual attack. To
busy out the port, it sends a series of TCP SYNs with bogus, but unreachable, sender addresses.
These quickly fill the queue which the trusted host uses to deal with incoming login requests, since it's
busily failing to reach the purported senders with its SYN_RCVD responses. Any additional
incoming packets overflow this queue and are ignored. 

Next, the forger sends a series of perfectly valid TCP SYNs to the target, which the target responds
to with a series of SYN_RCVDs, each including a sequence number. The sequence numbers are
analyzed, and the next one is predicted. 

Next, the forger sends a TCP SYN to the target, this time using the sender address of the trusted
host, rather than the forger's own address. The target acknowledges the TCP SYN with a
SYN_RCVD, including the sequence number for the circuit, but it sends this packet to the trusted
host, rather than to the forger. The trusted host ignores the packet, because the packet is replying to
port 513, its busied-out login port. The forger, however, operating on the assumption that the
SYN_RCVD packet was sent, acknowledges it with an ESTABLISHED packet, using the sequence
number it predicted. If the sequence number was predicted correctly, there will now be a valid circuit
open into the target host, albeit one from which the forger will never see a reply packet. 

To finish the attack, the forger must take advantage of the privileges accorded the trusted host, and
secure some means of logging back into the target host with a full bi-directional connection. In the
actual attack, this was accomplished by adding a line to the .rhosts file in the target machines root
directory according trusted host status to all comers. 

Lastly, the forger cleans up by forging ESTABLISHED packets in acknowledgment of all the
SYN_RCVDs presumably sent by the trusted host, and then tears down those connections with
RSTs; and does the same for the circuits used to determine the sequence number generation method
on the target host. 

As you can see, this process, while conceptually simple, would be immensely difficult to actually
carry out, given the necessity of operating completely in the dark, as it were, without ever receiving
acknowledgment from the target host. Nonetheless, as with the sendmail security holes of the past,
once its been demonstrated feasible once, no matter how difficult, it will undoubtedly be repeated by
other crackers. This is sufficient reason to assure yourself that your site won't be vulnerable to such
an attack. As I said before, this attack relied upon the forgers ability to insert forged packets into the
target hosts local network, the predictability of TCP sequence numbers generated by the target host,
and the unfortunate dependency of the r- utilities upon IP addresses for authentication. 

Macintoshes running the MacOS aren't vulnerable as they don't run the r-utilities, but nearly all of you
run multi-platform networks, or have A/UX hosts, and would be loath to give up all the utilities which
employ IP-based authentication, so that's not sufficient security. 

Predictability of TCP sequence numbers is something we can't do anything about as network
administrators, save demand that vendors use a more sensible scheme. Worse, regardless of the
scheme vendors employ, pseudorandom numbers will always be vulnerable, given that the forger has
an unlimited amount of time to determine the mechanism. 

This leaves firewalling the network, such that packets which are forged with the address of a local
host cannot enter the network in the first place. Although firewalls are normally a very bad alternative
to real system security, since they generally present a greater inconvenience to the valid users than to
skilled crackers, this is one case in which a filter presents no inconvenience at all to authorized users
while acting as an effective barrier to attackers. 

Quite a few routers are capable of acting as firewalls; those in most common use seem to be made
by Cisco and Livingston, so for the sake of convenience, I'll present the steps necessary to add
trusted-address-spoofing protection to routers made by those two vendors. If you follow the
examples, you should be able to apply the same methods to any other router which supports the
same functionality, albeit through a slightly different configuration interface. 

Configuring Cisco Access Lists to Confound Spoofing

Cisco packet filters are defined in one group of commands, and then applied within the applicable
interface. To create a firewall to protect against spoofing, use the commands 

    access-list  X  deny    Net-Address  Inverted-Mask
    access-list  X  permit  0.0.0.0      255.255.255.255

where X is the number of the access list (which for IP filters must be chosen from the range 1-100),
Net-Address is your IP network number, and Inverted-Mask is the inverse of the mask which would
ordinarily define the type of network youre using. 

For instance, at my site, one class B network (157.22.0.0) and two class C nets (198.182.167.0
and 198.207.242.0) are protected behind our firewall. Inverting the net-masks which would
ordinarily be used to define class B and class C nets gives us 0.0.255.255 and 0.0.0.255,
respectively, so we have the following access-list definition: 

    access-list  1  deny    157.22.0.0     0.0.255.255
    access-list  1  deny    198.182.167.0  0.0.0.255
    access-list  1  deny    198.207.242.0  0.0.0.255
    access-list  1  permit  0.0.0.0        255.255.255.255

The last line is an explicit permission to pass any packets which are not discarded by the preceding
rules. This is necessary, since Cisco's default action is to discard any packets which aren't explicitly
permitted. 

Next we have to apply the access-list to our upstream interface, the one which connects our net to
the Internet. Since in my case this is a T1 on serial interface 0, I use the following lines to assign the
access-list to the interface: 

    interface Serial0
    ip access-group 1 in

Note three things here: first, that Cisco uses the terminology access-group when referring to
assignment within an interface, as opposed to access-list when defining the component rules of the
list, since youre assigning the interface to a group of interfaces which share the characteristics of the
access list in common. Second, the last word is in, meaning that this filter is to be applied to packets
as they enter the router through the serial 0 interface, rather than as they exit the router. This is
crucial, since if you specified out, youd have just filtered all your own traffic, and disconnected
yourself from the Internet! Third, it's important that you apply the filter to inbound packets on the
upstream interface, rather than outbound packets on the local LAN interface, because your routers
LAN interface uses a local address; if you applied the filter to the LAN interface, you'd no longer be
able to receive packets from your own router. 

One last change you may wish to make in order to prevent crackers from taking advantage of a
related IP routing security hole is to disable IP source-routing, which could potentially allow the
rerouting of internal packets through external, unsecured, networks. 

In general configuration mode, enter the command: 

    no    ip    source-route

When you've finished applying your access-list, don't forget to write your changes back out to the
permanent configuration, and back them up to any other copies of your configuration file you may
keep outside the router. 

Configuring Livingston Packet Filters to Prevent Spoofing 

Livingston's method for creating and applying packet filters is much like Cisco's, if a little more terse.
As before, the first task is to create and name a filter, and then add the exclusion criteria to it: 

    add    filter    Name
    set    filter    Name    Rule-Number    deny    Net-Address/Mask-Bits
    0.0.0.0/0

Here, a filter is Named, rather than numbered, and a Rule-Number is used to uniquely identify each
component of the filter, a feature dictated mostly by the nature of Livingston's command-line
configuration editor. 

For instance, to create a filter which would work here, I'd use the following commands: 

    add  filter  internet.in
    set  filter  internet.in  1  deny  157.22.0.0/16     0.0.0.0/0
    set  filter  internet.in  2  deny  198.182.167.0/24  0.0.0.0/0
    set  filter  internet.in  3  deny  198.207.242.0/24  0.0.0.0/0

Note that the format of the masking is different, and a bit more standard, in Livingston's configuration
method than in Cisco's rather than specifying the inverse of a dotted-quad mask, you simply specify
the number of one-bits from the left side of the mask. Thus a class B mask, 255.255.0.0, which is
1111 1111 1111 1111 0000 0000 0000 0000 in binary, becomes /16, while a class C mask,
255.255.255.0, which is 1111 1111 1111 1111 1111 1111 0000 0000 in binary, becomes /24. 

To apply the filter to a specific interface, in this case serial port 0, use the set command as follows: 

    set  s0  ifilter  internet.in

Here, ifilter is used to indicate that the filter is to be applied to packets entering the interface, whereas
ofilter would indicate an output filter. 

IP source-routing need not be explicitly disabled on the Livingston. It's such a bad idea that they dont
let you do it in the first place. 

Again, remember to save your changes, and recall that on the Livingston, changes are saved to the
permanent configuration, rather than the currently-running one, so youll probably want to reset the
interface immediately to put them into effect: 

    save  all
    reset s0

Three-Quarters of the Way Through the Column, I Finally Get Around to Answering the
Questions

What are the potential risks an Internet-connected company faces? 

I'd say that most of them are human-factors sort of problems, better dealt with through policy and
management than via technical means. For example, one of the most common problems I see is
employees of Internet connected companies failing to appreciate the difference between replying to
the sender of a piece of electronic mail, and replying to all addressees of the mail. This can lead to
terrible embarrassment, particularly when an employee is perceived to be speaking on behalf of the
company, in official capacity. I've seen companies give up external electronic mail connections
entirely after an employee stupidly broadcasts some badmouthing of a person or product to a huge
mailing list, containing press, competitors, customers, and what-have-you. A variation of this is
hot-headed employees who spout off in public fora, while using their company electronic mail
accounts, again appearing to speak for the company, despite the fact that they may have no
authorization to do so at all. Many companies require that all postings from company machines
contain a disclaimer, unless theyre sent by a specifically authorized representative of the company,
like a public relations officer. 

Another example is mismanagement of valid servers. Your company may have servers publicly
accessible via the net. There's no technical means of preventing server administrators or even users
from accidentally putting confidential information on public servers. Only an effective corporate
security policy can teach people to be careful. 

Last, and perhaps most trivial, any company that connects to the net will see some initial period of
lower productivity, while technically-unskilled employees come up to speed on using it, and the
technically-skilled go net-surfing. Soon enough the former will get things figured out, and the latter will
get bored and go back to work. 

What are reasonable firewall options? 

As I said, firewalls are generally a bad idea. Most firewalls I've seen are terrible overkill, making a
company's expensive network connection worthless for most of the purposes it's best suited for, and
annoying users and customers alike. The best network security is system security, making sure that all
the passwords on all your hosts are unguessable, and that known security holes in system and
networking software are plugged. The network is meant to transport packets, not hinder them. That
said, there may be a very few specific instances in which the most efficient and effective means of
achieving a security objective is to simply filter some sort of packet out at the point at which it enters
your network. If you're sure you've identified such a situation, and you can't think of any better way
to achieve the same goal on your hosts, then a filter is called for. 

What are Ethernet data encryptors? 

They're devices which are either implemented in software inserted below your IP protocol stack, or
in hardware between a network interface and the network wire itself. They take all outgoing Ethernet
packets and encrypt them, and decrypt all incoming packets. Obviously, this sort of solution is only
good against outside intrusion, since it's transparent to any hosts already on your network. As a
result, its generally used on point-to-point links, like the serial lines connecting portions of a
wide-area-network. Those links are relatively secure anyway (In the U.S. thats no longer the case,
since the NSA recently pushed a bill through Congress requiring all telecommunications and
encryption equipment vendors to put vulnerable back doors into all their equipment, to facilitate
tapping), so it's largely wasted effort. And since any communications across the Internet are likely to
be with random hosts belonging to other companies, no encryption is possible, at least until
public-key technology is integrated much more fully into our network infrastructure than it is today. 

How could a router get confused, and think an external address is really an internal
address? 

It's not quite so simple as that. First of all, a router has no way of determining the ultimate origin of a
packet; all it has to look at is the source IP address, which is written by the sender, and therefore not
necessarily trustworthy. The problem isn't external addresses being mistaken for internal addresses,
it's packets with internal addresses appearing within the router, and being routed normally. Routers
don't ordinarily check to see what port a packet arrives on, they just worry about delivering it out the
correct port to get it to its destination. Routers sometimes have to deal with many thousands of
packets each second, and it's speed optimizations like these that allow them to perform at that level.
In cases like we're discussing here, though, an input filter is practical, since it allows the router to
discard the forged packet before it would normally determine what port to deliver it to, and thus
doesn't take particularly longer to deal with than a normal packet would. Besides, such packets are
likely to be coming in over slower wide-area-network interfaces, where blazing performance isn't an
issue. 

Where to Find Additional Information 

Anyone interested in pursuing further reading on the subject of TCP Sequence Number cracks
should examine the two papers which first documented the security hole, and undoubtedly served to
guide the execution of the attack: 

     Bellovin, Steven M., Security Problems in the TCP/IP Protocol Suite, Computer
     Communications Review 19:2, April, 1989. 
     Morris Robert T., A Weakness in the 4.2BSD Unix TCP/IP Software, AT&T Bell Labs
     Computer Science Technical Report #117, February 25, 1985. 

and the documents which described the execution of the attack after the fact: 

     Shimomura, Tsutomu, Technical details of the attack described by Markoff in NYT, January
     25, 1995. 
     Bellovin, Steven M., Sequence Attacks, January 26, 1995. 
     CERT Advisory 95:01, IP Spoofing Attacks and Hijacked Terminal Connections, January 23,
     1995. 
     CERT Technical Tip, Packet Filtering for Firewall Systems, February 3, 1995. 


Ask Woody is reprinted here by permission from Volume 8, Issue 6 of Connections, the Journal
of Macintosh Connectivity, where's it's a regular feature. Copies of each of these documents,
as well as pointers to the sites containing the originals, are located on the Connections ftp
server, at ftp://ftp.mactivity.com/pub/ask-woody.