Using TCP/IP against itself

April 10, 2001 —

TCP/IP is the collection of protocols that manages connectivity across the Internet. Because system attacks that take advantage of flaws and weaknesses in the protocol generally do not get as much attention as the likes of the "ILOVEYOU" virus, many people are unaware of the type and the severity of attacks that can be launched. In this month's column, we will look at why the TCP/IP protocol family is vulnerable to abuse and consider what, if anything, can be done to reduce the likelihood of attack.

Attacks against TCP/IP use the protocol's own capabilities to disrupt its activities -- just as you might disrupt traffic in a large city by staging a major downtown event to begin at 6:00 p.m. or by fiddling with the timing of traffic signals. The weaknesses in TCP/IP exist primarily because the protocol designers could not have anticipated the degree to which intelligent people would abuse the Internet, any more than the designers of federal and regional laws could have anticipated the many ways in which crafty lawyers would find loopholes. Laws are designed to be fair, but are not necessarily fairly applied. Protocols are engineered to be robust, resilient, and to some degree self-correcting, but are not immune to abuse. In addition, not only are the algorithms that describe how protocols work complicated, but the specifications that describe their inner workings often leave a little too much room for interpretation. As a result, some of the same mechanisms that permit the Internet to continue working under random stresses and failures also allow the protocols to be abused.

Last month's column described denial-of-service attacks. These include anything from disabling a system (e.g., by pulling the plug or corrupting a vital configuration file) to overwhelming a system with so many requests that it is unable to respond to its normal, and legitimate, workload. Denial of service defines a broad category of attacks. It includes some all too familiar attack scenarios -- like SYN flooding -- along with a lot of other types of attack (e.g., desynchronization attacks) with which even the typical system or network manager may be unfamiliar.

Denial-of-service attacks are only one variety of attacks that use the protocol against itself. Denial-of-service attacks involving TCP/IP interfere with the normal timing and sequencing of state changes (e.g., OPEN, SYN_RCVD) that occur as connections are established, used, and then closed. By stalling or hanging these connections, the attack depletes resources on the victim's system.

Other types of attacks against TCP/IP include:

IP spoofing (falsifying an IP address to gain access to restricted systems or data)
Connection hijacking (stealing ongoing connections)
Source-routing and RIP attacks (redirecting connections by changing or adding routes)
ICMP attacks (using the management protocol of TCP/IP to deny service or close legitimate connections)
Desynchronization attacks (stealing or breaking an existing connection by pushing packet sequence numbers outside the valid range)

IP spoofing

In IP spoofing attacks, an attacker uses a forged IP address and the victim accepts this address without questioning it (because the protocol does not perform any checking). The attacker also forges sequence numbers -- the numbers inserted into packets to enable the packets to be properly sequenced if they arrive at the target out of order. (These numbers are an essential component of an ongoing connection and spoofing cannot occur if attackers cannot forge these numbers along with their own IP addresses.) Though forging sequence numbers may not seem like an easy task, methods of doing this were described as far back as 1985. In fact, the algorithms used to compute sequence numbers can be easily duplicated, making it possible to create packets including sequence numbers that will fall within the valid range.

So, when a targeted system is sent a request with an IP address and a valid sequence number, it responds by sending a reply to the system that the request appears to have come from. After all, it cannot reply to the system from which the request actually derived because the falsified IP address will cause the reply to be routed to the real system. This third system ignores these acknowledgment packets (i.e., from the victim) because it did not initiate the connection. In fact, it will likely respond with a FIN (a request to close the connection). For this reason, a successful attack often involves quieting the "real" system by first launching a denial-of-service attack against it or ensuring that it isn't available to participate in the communications with the target.

Source routing

In a source-routing attack, packets are sent to a system with the source-routing bit set. If the target system responds to this directive, it accepts whatever path is designated in the connection request and responds to the client using this path instead of its normal routing-table entries. This creates the perfect opportunity for hijacking a connection.

Connection hijacking

Connection hijacking involves stealing an established connection and is especially useful if the attacker lacks the means to establish a connection in the first place -- for example, if SecurID cards or one-time passwords are used. Connection hijacking disrupts communications between two systems. It takes advantage of the forgiving way in which packets are sequenced (allowing them to arrive out of order). By closing a connection that is not fully established and then starting another (changing the sequence numbers) or by inserting innocuous packets into the communications (looking as if they are coming from the third system) and pushing the sequence numbers beyond the acceptable range, the attacker leaves the target and the third system unable to communicate, while retaining proper communications with the target.

RIP attacks

RIP (Routing Information Protocol) attacks provide the basis for another form of connection hijacking or denial of service. Though RIP is not strictly part of the TCP/IP protocol, it plays a role in routing. Initially built to distribute routing information to facilitate flexible and efficient routing, RIP is also easily abused. There is no authentication -- no checking -- whether the route information that it provides is correct or from a reputable source. Your router will accept RIP updates or not. By changing routes, RIP can determine where data is sent (what we could not do in the IP spoofing scenario described earlier). By using RIP to advertise an efficient route, an attacker can then use it to "steal" any number of connections or to effect a different form of denial-of-service attack. If the new route redirects particular connections, the attacker can take over ongoing sessions. If it redirects the bulk of a router's connections, the systems currently connected will no longer receive any communications from hosts sending packets through the compromised router (i.e., because they will be sent elsewhere). If the targeted system is a Website, visitors may find themselves at another site altogether or with broken connections. Because the consequences of RIP compromises are severe, RIP is usually disallowed on routers.

ICMP attacks

Called a management protocol for good reason, ICMP isn't used for client/server or peer-to-peer communications. Instead, it is used for extraneous information that must be communicated within the TCP/IP protocol -- like messages indicating that a destination is unreachable. Even the most well known yet seemingly innocuous of the ICMP utilities, the "ping" utility (used to check connectivity between systems), has been implicated in numerous attacks.

Like other protocols (e.g., RIP), ICMP's lack of authentication (and, therefore, accountability) makes it a candidate for abuse. Some attacks (like the Ping of Death) are a form of denial-of-service attacks. ICMP messages can also cause a valid connection to be dropped. Forged ICMP packets indicating that a destination is unreachable or that the trip time has been exceeded will close the connection. These messages are intended to make the protocol impervious to problems (such as a router going down or a remote system crashing), but can also be used to shut down legitimate connections.

Another vulnerability of the ICMP protocol is that it allows for "redirects." These can be used to hijack (or intercept) connections. Meant to be used when a host mistakenly assumes that another host is outside the local network (e.g., when its subnet mask is improperly set), redirects allow the router to direct packets back into the local network and to the intended system. Attackers on the local network can use redirects to deflect packets back to their own systems.

DNS attacks

Like RIP, DNS is not part of the TCP/IP protocol, but is an integral part of the Internet. The flexible cooperation of domain name servers makes communications among a vast number of unrelated systems possible. A bogus DNS entry, however, supplying an incorrect hostname when resolving an attacker's IP address provides the basis for another type of attack. That makes it possible for an attacker to circumvent hostname-based authentication schemes. For example, names of trusted hosts may be included in a /.rhosts file or an /etc/hosts.allow file. If an attacker's IP address resolves to a hostname included in one of these files, the attacker will be able to masquerade as the trusted host.

To take advantage of a DNS server, an attacker needs to be able to add an entry to a specific DNS server (after all, not just any DNS server will be involved in the IP address-to-name resolution). Attacks of this type are, therefore, not common and are made extremely unlikely if the authentication involves a second check to ensure that the hostname returned by the lookup resolves to the IP address that was first resolved.

Known vulnerabilities

If you read some of the initial papers describing TCP/IP vulnerabilities, you will notice that many of the protocol's weaknesses have been known for a very long time. Robert T. Morris first described the ability of an attacker to guess sequence numbers and steal connections in a paper written in 1985 (see Resources for a link).

You might think that vulnerabilities that have been recognized for more than 15 years would have been long solved. Unfortunately, someone would have to rebuild the protocol from the ground up to remove these vulnerabilities -- just as one might have to completely rethink a complex law to ensure that there is no possibility of loopholes.

Even experienced programmers and systems administrators might admit that they have no idea how to go about launching any of the attacks described in this column. Spoofing or connection hijacking, for example, involve a lot more than entering text on the command line or setting a parameter in a configuration file. This might lead you to believe that these attacks are, therefore, extremely unlikely. Unfortunately, those who make a hobby of attacking systems will have access to numerous tools specifically designed to attack systems. They do not launch these attacks from scratch any more than you need to build TCP/IP from scratch when you install a system.

Practical Prevention

There are a number of things that you can do to lessen the likelihood of TCP/IP attacks. Some of these involve changing the parameters that control TCP/IP timing and queue sizes. For denial-of-service attacks, altering certain parameters makes these attacks more difficult. For example, by enlarging the queue used to hold incomplete connections, a system will not be overwhelmed as easily or as quickly. Similarly, decreasing timeouts so that connections do not hang around as long will free up resources for additional connections.

Most security experts recommend configuring firewalls to make clear and effective distinctions between the inside and outside. Packets from the outside claiming to be from the inside and vice versa are dropped. This simple and irrefutably sensible rule set can deflect many (e.g., connection-hijacking) attacks.

You can also ensure that RIP is turned off at routers and that ICMP redirects are not permitted.

Adding tcpwrappers can provide authentication for services that have no, or weak, authentication. Wrappers are not foolproof, but the added layer will almost always add some security to your services.

The addition of authentication and encryption can make spoofing impossible. Since generated session keys (used for encryption) are based on secret keys known only by the communicating systems (and never transmitted), you can add significantly to network security.

TCP/IP is a complicated technology, but you don't have to know enough to have built it yourself to understand its basic workings and vulnerabilities or to effect some practical safeguards.

References

"Security Problems in the TCP/IP Protocol Suite," Bellovin, S. M. (Computer Communication Review, April 1989): http://www.ja.net/CERT/Bellovin/TCP-IP_Security_Problems.html

"TCP/IP Security," Chris Chambers, Justin Dolske, and Jayaraman Iyer (Department of Computer and Information Science, Ohio State University): http://www.linuxsecurity.com/resource_files/documentation/tcpip- security.html

"A Weakness in the 4.2BSD Unix[+ ]TCP/IP Software," Robert T. Morris: http://www.ja.net/CERT/Morris/r.t.morris-TCP.html

Unix Insider