| Previous | Table of Contents | Next |
Sequence Number Guessing
Each side of the connection chooses an initial number and then transmits this value to the other half of the connection. The two sides of the connection depend on these sequence numbers for packet reassembly because some packets may be delivered out of order. To acknowledge receipt of the packet containing the sequence number, the recipient responds with the sequence number incremented by one and the ACK flag turned on in the packet.
A clever hacker can exploit a TCP connection during the initial handshake for the protocol if sequence numbers can be guessed. This attack was exploited frequently on the Internet in the last couple of years. Blind guessing of sequence numbers is possible but has a low probability of success. The favored choice is for the hacker to spend some time gathering information about sequence numbers chosen by the target for various connections. Network traffic sniffing is especially useful here, but not a necessity. How does someone gain information about sequence numbers without sniffing? If the victim is on a public network, you can send it as many TCP connection attempts as you like. Each packet you receive will contain a sequence number. If the algorithm for choosing sequence numbers is predictable, the game is over. Because a CERT advisory was issued for this attack, most vendors have chosen some pseudorandom method for selecting initial sequence numbers. If you like to dabble in statistics and discrete mathematics, you might be able to predict the period of the random number generator in use by a vendor.
It should be obvious that if the hacker’s network location is between the communicating endpoints, network sniffing trivially provides the sequence numbers.
Session Hijacking
If the socket addresses and sequence numbers are known, a node that is in between the endpoints of a TCP connection can hijack one or both halves of the session. Sometimes, this attack also is referred to as the bucket brigade attack. All the impostor must do is ensure that the two endpoints receive the appropriate protocol messages during the hijack. Because the attacking node is in the middle, intercepted packets can be easily altered, discarded, or substituted. Due to some protocol unique features of Token Ring networks, session hijacking is harder on these networks than it is on other networks such as Ethernet.
Other TCP/IP Protocol Problems
Protocols are designed as state machines. Each side of the protocol starts in an initial state and transitions to other states depending on the type of input received. Designing a protocol that is resistant to attacks is a challenging task because of tradeoffs. TCP/IP was designed to be an open protocol. A node running TCP/IP or UDP/IP is listening for inbound network traffic from almost anywhere. Some initial trust was designed into the protocol to support this open behavior, but this choice has led to some bothersome attacks.
The SYN Flood attack is one example. TCP sessions begin with a three-way handshake between the two endpoints of the connection. Packet header fields are set to different values depending on the state of the connection (remember this is a state machine). One of the fields in the TCP connection requests an initial synchronization (SYN) by sending a message with the beginning sequence number as identified previously. To drag a machine’s performance down, a well-known trick is to send the victim a large number of SYN requests. Not only does the attacked machine spend time sending back acknowledgment messages, but it also remains in a state that is waiting for the third part of the handshake. Depending on the machine’s capabilities, a few hundred or few thousand outstanding connections can really slow things down.
Other similar attacks exist. If you can impersonate an IP address and see the traffic between two nodes, it’s not difficult to cancel either half of the session by sending a properly formed packet with the FIN bit set. You also can reset either side of the session in the same way by setting the RST bit.
Because it is such a useful network service layer, TCP/IP is the basis for many popular Internet applications including HTTP and FTP. These applications have their own protocols that sit on top of TCP/IP and often provide their own additional security models. FTP allows files to be transferred between systems but requires a complete login process in order to gain access to the remote system. The login portion of FTP is almost always based on the same underlying mechanisms used for base operating system login.
HTTP, on the other hand, introduces its own security model. Web servers provide configuration files that are modified to define a virtual file tree whose meaning is only relevant to the Web server. Most Web servers can be set up to require an authentication dialogue before access is allowed to particular portions of the file tree. The users and passwords can be defined in a repository independent of that used by base operating system. Other settings enable the Web administrator to specify access control rules that are applicable only to the objects which exist in the virtual file tree. In reality, files from the operating system’s file system populate the virtual Web file tree. However, the operating system permission bits are not interrogated by the Web server when an access request is evaluated. Instead, the Web server consults its own configuration files. The Web server is thus providing an application specific security layer above the security provided by the operating system.
UNIX networks have a convenience feature that simplifies distributed computing. Rather than requiring an authentication phase for every connection, some TCP/IP applications will honor a trust relationship if it has been defined by the administrator on a machine. UNIX systems support several configuration files with contents consisting of hostnames, IP addresses, and optionally usernames. These files are as follows:
The trust relationship is defined according to the IP addresses or hostnames of the communicating parties. Depending on the configuration file chosen from this list, the trust can apply only to specific users or to all users on a particular host. The hosts.lpd file is meaningful for the UNIX lpd remote printing protocol, so that some of these trust relationships are application specific.
Addressed-based authentication is the basis for these network authentication alternatives. However, because you have seen that address impersonation is a problem in networks, these weaker authentication facilities should not be deployed across untrusted networks.
| Previous | Table of Contents | Next |