Network Security Fundamentals [Electronic resources] نسخه متنی

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 2-1.

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-2 maps the TCP/IP protocol stack to the OSI model and serves as a framework for the discussion.

As you can see from Figure 2-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 2-3 shows the complete IP header format, but only the relevant fields are discussed.

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 2-1 illustrates all the fields of the IP header.

NOTE

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

NOTE

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 2-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.

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-2 shows some examples of well-known port numbers.

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 2-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.

For all DoS attacks launched against a host (the web server of Company XYZ in Figure 2-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 2-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 2-6 illustrates this 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 2-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 2-7 illustrates this three-way handshake in a little more detail, elaborating on some of the flags used.

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 2-3 illustrates some invalid combinations of these parameters.

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 2-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 2-8, an authorized user (Employee X) sends HTTP requests over a TCP session with the web server.

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 2-8:

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. Subsequent chapters in this book refer to these TCP/IP vulnerability issues, and more prevention and protection methods are discussed.