TCP hijacking

TCP Hijacking - A man-in-the-middle attack, when an attacker is able to view packets of network participants and send their own packets to the network. The attack uses the features of establishing a connection in the TCP protocol, and can be carried out both during the “triple handshake” and when the connection is established.

The problem of possible substitution of TCP messages is important, since the analysis of the FTP and TELNET protocols implemented on the basis of the TCP protocol has shown that the problem of identifying FTP and TELNET-packages is entirely the responsibility of these protocols on the transport layer, that is, on TCP.

Establish TCP connection

To identify a TCP packet, there are two 32-bit identifiers in the TCP header, which also play the role of a packet counter, the Sequence Number and Acknowledgment Number. In case if host A wants to establish a TCP connection with host B, the so-called occurs. “Triple handshake”, during which hosts exchange the following packets:

• host A sends to host B a packet with the SYN bit set and the 32-bit ISSa value in the Sequence Number field
• host B responds to host A with a set of SYN and ACK bits, a 32-bit ISSb value in the Sequence Number field, and a value (ISSa + 1) in the ACK field
• Host A responds to Host B with a packet with the ACK bit set, a value (ISSa + 1) in the Sequence Number field, and a value (ISSb + 1) in the ACK field.

This packet completes the connection setup, so in the next packet, host A sends useful information to host B

• Host A responds to Host B with a packet with the ACK bit set, a value (ISSa + 1) in the Sequence Number field, and a value (ISSb + 1) in the ACK field. This package includes useful information.

Principle of attack

Having considered the connection setup scheme described above, you can see that the only identifiers by which the end host can distinguish between TCP subscribers and TCP connections are the Sequence Number and Acknowledge Number fields. Thus, if an attacker determines the ISSa and ISSb values ​​for a given connection, then it will be able to form a false TCP packet that will be received and processed by the end host.

One type of attack implies that the attacker embeds the control bit RST (Reset) into the TCP packet. According to RFC 793, this flag tells the target host to reset the connection without any further interaction. According to the Sequence Number field, the target host determines whether to process or ignore the com *** at the reset, and the target is prohibited from sending a response with the RST bit set. It is important to note that the target host authenticates the RST request only by the Sequence Number, and closes the connection if it falls into the current TCP window. And, despite the fact that the target host can calculate the acknowledgment number, it is not obliged to do this, and, as Paul Watson discovered, most TCP stacks simply ignore this step.

An accepted RST packet will always terminate the connection. Connections designed for a long time, such as BGP connections between routers, are extremely vulnerable to such attacks. First of all, the attacker will have enough time to implement a carefully planned package, and, on the other hand, DoS will cause huge losses. Routers have to reconfigure the table of neighbors, which can take several minutes in real conditions.

Less obvious is the fact that the SYN flag can also bring down the connection. According to RFC 793, when the SYN flag is set when a connection is established, the Sequence Number field contains an initial value that will be used later. If a SYN packet is subsequently received on this connection, RFC 793 will interpret this as an error. The result is that the recipient will have to cancel the connection by sending the RST packet. Unlike the RST packet, the host will respond to the SYN packet by sending the RST packet. This opens up the possibility of another DoS attack. The attacker may subsequently use the victim's bandwidth. This attack is particularly successful in ADSL lines.

While RST and SYN attacks do not use the payload of an IP datagram, the third technology embeds data into an existing connection. The attacker can insert any data that will lead to the disconnection of the connection, or accurately form the data that will lead to an error condition, or will perform some function for the benefit of the attacker. The victim may not even notice these manipulations. For example, the FTP and TelNET protocols do not check the sender's IP address, and therefore, if a false TCP request is successfully generated, they will respond to the attacker's real IP address, which will allow you to completely intercept the connection.

So, to launch an attack, you need to know two TCP connection parameters. In the event that an attacker can directly listen on a communication channel between hosts A and B, these parameters are determined by a simple traffic analysis. Otherwise, it is necessary to resort to more complex methods.

Mathematical estimation of the ISN parameter

This method is based on the assumption that the selection of the initial parameters ISSa and ISSb (the so-called ISN - Initial Sequence Number) when establishing a connection in some way depends on time. From the point of view of security, the choice of ISN would be absolutely arbitrary, which would make the prediction practically inapplicable, however, in the description of the TCP protocol in RFC 793, it is recommended to increase the value of this counter by 1 every 4 microseconds, which makes the prediction of this value trivial. In practice, the analysis of the source code of old Linux kernels, as well as the behavior of the Windows NT 4.0 operating system and younger, confirms the functional dependence of the selected ISN value on time.

In the general case, if such a dependency exists, it will be expressed by some formula of the form ISN = F (mcsec), where mcsec is the number of microseconds per hardware clock of the operating system under study.

Thus, the attacker needs to conduct some analysis of the function of the dependence of the assigned value of ISN on time. To do this, a series of normal requests for creating a TCP connection is transmitted to the investigated network OS and the corresponding number of responses are received with the current ISN values ​​of the operating system at any given time. At the same time, time intervals (in microseconds) of incoming responses to requests are measured. By constructing a table of dependencies of the obtained ISN on time t, passed from the beginning of the experiment, and approximating it with any mathematical tools, we obtain with an error comparable to the error of the original data, a continuous function of changing ISN from t, valid for a given time interval: ISN (t) = F (t);

This formula will give us the opportunity, by measuring the previous value of the ISN, by measuring the time elapsed since his appointment, to obtain the current value of the moment of time ISN.

In the future, the attacker can only monitor the behavior of the hosts studied, and, by calculating the moment of connection creation, approximately estimate the range of values ​​of the ISSa and ISSb values ​​chosen by the hosts. Since this method is approximate, we cannot avoid some sorting, however, mathematical modeling allows many orders of magnitude (s ~ before ~ a) reduce the number of packets required by an attacker to conduct a successful attack.

Window replacement

However, it is not always possible to conduct a preliminary mathematical assessment of the values ​​of ISN. Also, in some cases, the value is chosen more or less time-dependent, and, therefore, the mathematical evaluation is difficult or impossible. In this case, it is necessary to resort to more crude methods as a search of all possible values ​​of these parameters. However, a careful study of the standard RFC 793, the situation is somewhat simplified.

The first thing to mention is the window mechanism in the TCP protocol. Packages distributed over the Internet can overtake each other. In order not to lose the packets arriving earlier than its predecessors, the recipient establishes a so-called window in which he can restore the order of the packets. Thus, if the value of the Sequence Number field lies within the receiver's window, the TCP protocol will accept and process this packet. This significantly reduces the number of attempts that an attacker will have to make: it decreases with before .

Depending on the operating system, the window size may vary from bytes (Windows XP with SP2) and 5840 bytes (Linux kernel 2.4 and 2.6).

The window will reduce the number of sequence numbers that the attacker needs to use. In the case of Windows XP, this number drops to . In other words, an attacker will only have to generate attacking packages to inject the RST package and, thus, bring down the connection. This is a very small number.

Everything gets worse if the members of the connection support a resizable window. This TCP function increases the probability of finding the appropriate sequence number in a short time. Window resizing is intended for connections that require a larger window due to large delays or busy bandwidth. To allow everyone to transmit without overlays, this technology expands the window dimension to 14 bits (Microsoft Windows), that is, to .

However, the attacker will have to overcome another obstacle: the four IP address / port of the sender and recipient. An IP address is hardly a problem — an attacker usually knows who he is targeting; the destination port is also easily determined. It is slightly more difficult to determine the port of the sender, which theoretically could be in the range from 0 to 65535. In practice, ports below 1024 and above the threshold determined by the operating system are reserved for special tasks.

Linux with a 2.4 or 2.6 kernel version uses as the sender port numbers from before .

To the delight of the attacker, the rest options are not randomly distributed; the kernel distributes them according to a specific scheme. Thus, the attacker will not have any problems with the prediction of the port of the sender. There are only a few exceptions, for example, OpenBSD, which distributes them in an arbitrary way. For example, Windows XP starts with port for the first connection, and increases the port by 1 for each subsequent. Linux (Fedora Core3 with kernel 2.6.9 in particular) with again increases in order. Cisco systems increase the port value by 512 for each new connection, but this does not make the mechanism safer.

The attacker does not need to guess the port number if the number of connections on the victim’s machine is known. All that is usually necessary for an attacker to do is start at the first value and try, say, 50 ports. Also for the attacker is not difficult to know the operating system of the victim. So, in essence, the definition of a port is not a serious obstacle.