TCP/IP Suite Weaknesses

TCP/IP Suite Weaknesses

Communication on the Internet is based on the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. The TCP/IP protocol suite was developed in the mid-1970s as part of research by the Defense Advanced Research Projects Agency (DARPA). With the introduction of personal computers as standalone devices, the strategic importance of interconnected networks was quickly realized. The strategic importance of networks was first realized in the development of local-area networks (LANs) that shared printers and hard drives. The importance of networks increased in a second phase with the development of worldwide applications such as e-mail and file transfers. The globalization of business caused web applications to be developed to support customers and clients all over the world with a focus on increasing efficiency and productivity for organizations. Now TCP/IP is seen as the de jure standard for Internet communication, enabling millions of users to communicate globally. Computer systems in general communicate with each other by sending streams of data (bytes), as displayed in Figure 1.

Figure 1. Internet Communication

NOTE

A byte is a sequence of 8 bits, which is often represented as a decimal number from 0 to 255. Bytes are used by computer systems to communicate with each other. Multiple bytes characterize a data stream of information. Errors in a data stream are detected by a checksum, which is a mathematic/arithmetic sum of a sequence of numbers.

This section presents a brief overview of the IP protocol and TCP protocol characteristics and then examines some of the TCP/IP weaknesses. Readers should not expect a full description of the TCP/IP protocol suite, but rather information relevant to a discussion of the weaknesses. Figure 2 maps the TCP/IP protocol stack to the OSI model and serves as a framework for the discussion.

Figure 2. TCP/IP Protocol Mapped to the OSI Model

As you can see from Figure 2, four layers of the TCP/IP protocol stack map to seven layers of the OSI model.

IP

The IP layer of the TCP/IP stack corresponds to the OSI network layer. IP is a connectionless protocol providing routing of datagrams in a best-effort manner. The following sections present topics that will help you to further understand the design weaknesses of the protocol.

The IP datagram is a combination of a number of bytes (IP header) that prefixes the data received from the transport (and higher) layer. Figure 3 shows the complete IP header format, but only the relevant fields are discussed.

Figure 3. IP Datagram Format

IP addressing (both the source IP address and the destination IP address) is used to identify the end stations involved in the transport of datagrams for communication.

End stations with source IP addresses and destination IP addresses on the same segment have direct delivery of packets. When source and destination end stations are not on the same network, there can be multiple paths. Path selection and decision is made by specialized computer systems whose primary function is routing network traffic. These systems are referred to as routers for the remainder of this book.

IP fragmentation offset is used to keep track of the different parts of a datagram. Splitting larger datagrams may be necessary as they travel from one router to the next router in a small packet network, for example, because of interface hardware limitations. The information or content in the offset field is used at the destination to reassemble the datagrams. All such fragments have the same Identification field value, and the fragmentation offset indicates the position of the current fragment in the context of the original packet. Also important to keep in mind is the existence of the IP Options field. This makes the IP header variable in length. Table 1 illustrates all the fields of the IP Header.

Table 1. IP Header Fields

Version : Indicates the format of the Internet header (4 bits)
Internet Header Length (IHL) : Specifies the length of the Internet header in 32-bit words (4 bits)
Type of Service : Provides an indication of the abstract parameters of the quality of service desired (8 bits)
Total Length : Specifies the length of the datagram, measured in octets (16 bits
Identification : Value assigned by the sender to aid in assembling the fragments (16 bits)
Flags : Various control flags (3 bits)
Fragment Offset : Indicates where in the datagram this fragment belongs (13 bits)
Time to Live : Indicates the maximum time the datagram is allowed to remain in the Internet system (8 bits)
Protocol : Indicates the next level protocol used (8 bits)
Header Checksum : A checksum on the header (16 bits)
Source Address : The source IP address (32 bits)
Destination Address : The destination IP address (32 bits)
Options : The Options field is variable in length
Padding : Internet header padding used to ensure that the Internet header ends on a 32-bit boundary

NOTE

RFC 791 Internet Protocol, provides additional information on the IP protocol.

In current network designs, more flexibility is offered to the users. Mobile IP, for instance, maintains network transport layer connections for network hosts moving from one point of attachment to another. Therefore, the mobile end station uses two IP addresses: one home address, which is static, and a second address, which is the care-of address.

TCP

The TCP or transport layer of the TCP/IP stack corresponds to the OSI transport layer. TCP is a connection-oriented protocol providing delivery of segments in a reliable manner. Some TCP characteristics are highlighted in the next section because they might be used to exploit some vulnerability in the TCP/IP protocol suite.

The TCP segment is a combination of a number of bytes (TCP header) that prefixes the data received from the upper layers. Figure 4 shows the complete TCP header format, but as with the discussion of the IP header, only the relevant fields are covered in this chapter.

Figure 4. TCP Segment Format

TCP uses port or socket numbers to pass information to the upper layers. This mechanism enables the protocol to multiplex communication between different processes in the end stations. In other words, the port numbers keep track of the different conversations crossing the network at the same time. Port numbers assigned by the operating system are also called sockets.

Table 2 shows some examples of well-known port numbers.

Application layer >>Port Number
FTP ——-> 21
Telnet ——-> 23
SMTP ——-> 25
HTTP ——-> 80
HTTPS ——> 443

NOTE

The port numbers are divided into three ranges: the Well-Known Ports, the Registered Ports, and the Private Ports. All these ports can be found at the Internet Assigned Number Authority (IANA) website at http://www.iana.org/assignments/port-numbers.

An established connection between two end stations can be uniquely identified by four parameters: source and destination IP addresses and source and destination port numbers. It is important to understand the underlying mechanism in order to configure extended access lists on routers to implement pass/block filtering decisions based on these numbers. Firewalls can also be configured to filter based on TCP ports.

Data exchange using TCP does not happen until a three-way handshake has been successfully completed. The connection needs to be initialized or established first on sequence numbers. These numbers are used in multiple packet transmissions for reordering and to ensure that no packets are missing. The Acknowledgment number defines the next expected TCP octet and is used for reliability of the transmission. The sequence number in combination with the Acknowledgment number serves as a ruler for the sliding window mechanism. This sliding window mechanism uses the window field to define the size of the receiving buffers. In other words, the window field is used to define the number of octets that the sender is willing to accept.

NOTE

RFC 793 Transmission Control Protocol, and RFC 3168The Addition of Explicit Congestion Notification (ECN) to IP, provide additional information on the TCP protocol.

TCP/IP Security Issues

Now that you understand some parameters of the TCP/IP protocol stack, it is easy to understand that the TCP/IP suite has many design weaknesses. Most of its weaknesses are likely because the development of the protocol dates from the mid-1970s. Vendors of network equipment and operating systems have made code improvements over time to disable many of the attacks that are described in the following sections.

IP Address Spoofing

In this type of attack, the attacker replaces the IP address of the sender, or in some rare cases the destination, with a different address. IP spoofing is normally used to exploit a target host. In other cases, it is used to start a denial-of-service (DoS) attack. As shown in Figure 5, in a DoS attack, an attacker modifies the IP packet to mislead the target host into accepting the original packet as a packet sourced at a trusted host. The attacker must know the IP address of the trusted host to modify the packet headers (source IP address) so that it appears that the packets are coming from that host.

Figure 5. DoS Attack Using IP Spoofing

For all DoS attacks launched against a host (the web server of Company XYZ in Figure 5), the attacker is not interested in retrieving effective data or information from the intended victim. The attacker has only one goal: to deny the use of service that the web server provides to valid users without being revealed. Therefore, the return address or source IP address can be spoofed.

In Figure 5, the attacker has the IP address 168.12.25.5 and is connected to the Internet. For normal traffic interaction between a workstation with a valid source IP address (168.12.25.5) and the web server (132.12.25.1), the packet is constructed with a source IP address of 168.12.25.5 and a destination IP address of 132.12.25.1. The web server returns the web page using the source IP address specified in the request as the destination IP address, 168.12.25.5, and its own IP address as the source IP address, 132.12.25.1.

Let’s now assume that a DoS attack is launched from the attacker’s workstation on Company XYZ’s web server using IP spoofing. Imagine that a spoofed IP address of 156.12.25.4 is used by the workstation, which is a valid host. Company XYZ’s web server executes the web page request by sending the information or data to the IP address of what it believes to be the originating end station (156.12.25.4). This workstation receives the unwanted connection attempts from the web server, but it simply discards the received data. It’s becoming clear that multiple simultaneous attacks of this sort deny the use of service that the web server provides to valid users. As you can imagine, locating the origin of the attacker launching the DoS attack is very complex when IP address spoofing is used.

Covert Channels

A covert or clandestine channel can be best described as a pipe or communication channel between two entities that can be exploited by a process or application transferring information in a manner that violates the system’s security specifications.
More specifically for TCP/IP, in some instances, covert channels are established, and data can be secretly passed between two end systems. Let’s take Internet Control Message Protocol (ICMP) as an example. In the following types of circumstances, ICMP messages are sent to provide error and control mechanisms:

• Testing connectivity/reachability using datagramsecho and Echo-Reply messages
• Reporting unreachable destinations for datagramsDestination Unreachable message
• Reporting buffer capacity problems for forwarding datagramsSource Quench message
• Reporting route changes in the path for datagramsRedirect messages

ICMP resides at the Internet layer of the TCP/IP protocol suite and is implemented in all TCP/IP hosts. Based on the specifications of the ICMP Protocol, an ICMP Echo Request message should have an 8-byte header and a 56-byte payload. The ICMP Echo Request packet should not carry any data in the payload. However, these packets are often used to carry secret information. The ICMP packets are altered slightly to carry secret data in the payload. This makes the size of the packet larger, but no control exists in the protocol stack to defeat this behavior. The alteration of ICMP packets gives intruders the opportunity to program specialized client-server pairs. These small pieces of code export confidential information without alerting the network administrator. Blocking ICMP packets that exceed a certain limit size is the only solution to protect against this vulnerability.

An example of a tool that uses this covert channel technique is Loki. The concept of the Loki tool is simple: It is a client-server application that tunnels arbitrary information in the data portion of ICMP_ECHO and ICMP_ECHO REPLY packets. Loki exploits the covert channel that exists inside of ICMP_ECHO traffic. Figure 6 illustrates this tool.

Figure 6. Loki Tool

In general, covert channels are prevalent in nearly all the underlying protocols of the TCP/IP protocol suite.

IP Fragment Attacks

The TCP/IP protocol suite, or more specifically IP, allows the fragmentation of packets. As discussed in the previous sections, IP fragmentation offset is used to keep track of the different parts of a datagram. The information or content in this field is used at the destination to reassemble the datagrams. All such fragments have the same Identification field value, and the fragmentation offset indicates the position of the current fragment in the context of the original packet.

Many access routers and firewalls do not perform packet reassembly. In normal operation, IP fragments do not overlap, but attackers can create artificially fragmented packets to mislead the routers or firewalls. Usually, these packets are small and almost impractical for end systems because of data and computational overhead.

Let’s go into a little more detail. The ingeniously constructed second fragment of a packet can have an offset value that is less than the length of the data in the first fragment. Upon packet reassembly at the end station, the second fragment overrides several bytes of the first fragment. These malformed IP packets cause the operating system at the end station to function improperly or even to crash.

A good example of an IP fragmentation attack is the Ping of Death attack. The Ping of Death attack sends fragments that, when reassembled at the end station, create a larger packet than the maximum permissible length.

One of the uses of this attack is to get past intrusion detection system (IDS) sensors. The individual fragments do not match any known signature, but after the overlap addresses overwrite some data, the result is an attack that can be recognized. A decent IP filtering code and configuration are required at the access router and firewalls to be assured that these attacks are blocked. These devices need to enforce a minimum fragment offset for fragments that have nonzero offsets so that overlaps can be prevented.

TCP Flags

As discussed previously, data exchange using TCP does not happen until a three-way handshake has been successfully completed. This handshake uses different flags to influence the way TCP segments are processed. There are 6 bits in the TCP header that are often called flags. In Figure 4, six different flags are part of the TCP header: Urgent pointer field (URG), Acknowledgment field (ACK), Push function (PSH), Reset the connection (RST), Synchronize sequence numbers (SYN), and sender is finished with this connection (FIN).

Figure 7 illustrates this three-way handshake in a little more detail, elaborating on some of the flags used.

Figure 7. Three-Way Handshake Using TCP Flags

Bob wants to start talking with Alice, so he initiates the TCP session with the SYN bit (flag) set in the first TCP segment. If Alice is happy to talk to Bob, she responds with the SYN flag and ACK flag set to 1. If she is unwilling to talk to Bob, she responds with an RST (reset) flag set to 1.

Abuse of the normal operation or settings of these flags can be used by attackers to launch DoS attacks. This causes network servers or web servers to crash or hang. Table 3 illustrates some invalid combinations of these parameters.

Table 3. TCP Flags

SYN FIN PSH RST Validity
————————————————————-
1 1 0 0 Illegal combinations
1 1 1 0 Illegal combinations
1 1 0 1 Illegal combinations
1 1 1 1 Illegal combinations
————————————————————-

The attacker’s ultimate goal is to write special programs or pieces of code that are able to construct these illegal combinations resulting in an efficient DoS attack.

SYN Flood

The TCP/IP protocol suite relies on the use of multiple timers during the lifetime of a session. These timers include the Connection Establishment timer, the FIN_WAIT timer, and the KEEP_ALIVE timer. The following list elaborates on the three-way handshake mechanism presented in Figure 7:

• Connection Establishment timer Starts after SYN is sent during the initial connection setup (step 1 of the three-way handshake).
• FIN_WAIT timer Starts after FIN is sent and the originator is waiting for an acknowledgement to terminate the session.
• KEEP_ALIVE timer Counter restarts after every segment of data is transmitted. This timer is used to periodically probe the remote end.

All these timers are critical for proper and accurate data transmission using TCP/IP. These timers (or lack of certain timers) are often used and exploited by attackers to disable services or even to enter systems. For instance, after step 2 of the three-way handshake, no limit is set on the time to wait after receiving a SYN. The attacker initiates many connection requests to the web server of Company XYZ (almost certainly with a spoofed IP address). The SYN+ACK packets (Step 2) sent by the web server back to the originating source IP address are not replied to. This leaves a TCP session half-open on the web server. Multiple packets cause multiple TCP sessions to stay open.

Based on the hardware limitations of the server, a limited number of TCP sessions can stay open, and as a result, the web server refuses further connection establishments attempts from any host as soon as a certain limit is reached. These half-open connections need to be completed or timed out before new connections can be established.

This vulnerability can be exploited by the attacker to actually remove a host from the network for several seconds. In the meantime, this temporarily disabled platform can be used to deposit another exploit or to install a backdoor.

Closing a Connection by FIN

These types of attacks can be best described as connection-killing attacks. In normal operation, the sender sets the TCP FIN flag indicating that no more data will be transmitted and the connection can be closed down. This is a four-way handshake mechanism, with both sender and receiver expected to send an acknowledgement on a received FIN packet. During an attack that is trying to kill connections, a spoofed FIN packet is constructed. This packet also has the correct sequence number, so the packets are seen as valid by the targeted host. These sequence numbers are easy to predict. This process is referred to as TCP sequence number prediction, whereby the attacker either sniffs the current Sequence and Acknowledgment (SEQ/ACK) numbers of the connection or can algorithmically predict these numbers.

Once the packet is constructed and sent, the receiving host believes the spoofed sender has no more data to be transmitted. Any other packets received are ignored as false and dropped. The remaining packets for completing the four-way handshake are provided by the spoofed sender. Similar connection-killing attacks are launched using the RST flag.

Connection Hijacking

TCP connections can be hijacked by unauthorized users without much difficulty. In Figure 8, an authorized user (Employee X) sends HTTP requests over a TCP session with the web server.

Figure 8. Connection Hijacking

The web server accepts the packets from Employee X only when the packet has the correct SEQ/ACK numbers. As seen previously, these numbers are important for the web server to distingish between different sessions and to make sure it is still talking to Employee X. Imagine that the cracker starts sending packets to the web server spoofing the IP address of Employee X, using the correct SEQ/ACK combination. The web server accepts the packet and increments the ACK number.

In the meantime, Employee X continues to send packets but with incorrect SEQ/ACK numbers. As a result of sending unsynchronized packets, all data from Employee X is discarded when received by the web server. The attacker pretends to be Employee X using the correct numbers. This finally results in the cracker hijacking the connection, whereby Employee X is completely confused and the web server replies assuming the cracker is sending correct synchronized data.

The following steps outline the different phases of a connection-hijacking attack, as shown in Figure 8:

Step 1.	The attacker examines the traffic flows with a network monitor and notices traffic from Employee X to a web server.
Step 2.	The web server returns or echoes data back to the origination station (Employee X).
Step 3.	Employee X acknowledges the packet.
Step 4.	The cracker launches a spoofed packet to the server.
Step 5.	The web server responds to the cracker. The cracker starts verifying SEQ/ACK numbers to double-check success. At this time, the cracker takes over the session from Employee X, which results in a session hanging for Employee X.
Step 6.	The cracker can start sending traffic to the web server.
Step 7.	The web server returns the requested data to confirm delivery with the correct ACK number.
Step 8.	The cracker can continue to send data (keeping track of the correct SEQ/ACK numbers) until eventually setting the FIN flag to terminate the session.

TCP Connecting Hijacking is one of the Man-in-the-Middle attacks. With this attack, an attacker can allow normal authentication to proceed between the two hosts, and then seize control of the connection. There are two possible ways to do this: one is during the TCP three-way handshake, and the other is in the middle of an established connection. Connection hijacking exploits a “desynchronized state” in TCP communication. When two hosts are desynchronized enough, they will discard (ignore) packets from each other. An attacker can then inject forged packets with the correct sequence numbers (and potentially modify or add commands to the communication). This requires the attacker to be located on the communication path between the two hosts so that he may eavesdrop, in order to replicate packets being sent.

TCP Connection Hijacking allows attackers to view and change private information.
TCP Connection Hijacking Mitigation
The Connection Hijacking (Man-In-The-Middle) attacks rely upon IP spoofing. By utilizing IPsec VPN at the network layer and by using session and user (or host) authentication and data encryption technologies at the application layer and at the data link layer, the risk of IP Spoofing and then Connection Hijacking will be reduced significantly.

NOTE

Sniffing Internet traffic is not necessarily easily accomplished. Most hijacking attacks require access to the local wire or the broadcast domain. An excellent tool to monitor the local wire is Ethereal.

These connection-hijacking attacks often occur unnoticed. The Employee X session hangs, but most Internet users reconnect the session and observe this incident as a network problem. Luckily, it is true that not all session hangs are caused by connection-hijacking attacks but involve different causes.

Countermeasures

As a network administrator, it is important to understand the vulnerabilities that exist in your network in order to implement effective countermeasures. TCP/IP vulnerabilities are nothing new, but the number of TCP/IP attacks is increasing considerably with the growth of the Internet.