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.