What do you think the sequence number of a TCP reset message is?

This article is reprinted from the WeChat public account "Cloud Native Lab". Please contact the Cloud Native Lab public account for reprinting this article.

A TCP reset attack is performed using a single packet of only a few bytes. The attacker crafts and sends a forged TCP reset packet to interfere with the connection between the user and the website, tricking both parties into terminating the TCP connection. Our great xx Great Firewall uses this technique to perform TCP keyword blocking [1].

To understand TCP reset attacks, you don't need to have a deep knowledge of network. You can simulate attacks on yourself with just a laptop. This article will show you how TCP reset attacks work and help you understand many features of the TCP protocol.

• Review the basics of TCP protocol
• Understanding the Principles of TCP Reset Attacks
• Use a simple Python script to simulate the attack

Now let's analyze the principle of TCP reset attack.

1. How does the great xx Great Wall use TCP reset attacks? This paragraph is skipped because you know the reason. If you are interested, please read the original text directly.

2. How TCP Reset Attack Works

In a TCP reset attack, the attacker disconnects the communicating parties by sending a forged message to one or both parties, telling them to disconnect immediately. Normally, if the client receives and finds that the arriving segment is incorrect for the relevant connection, TCP will send a reset segment, resulting in the rapid disassembly of the TCP connection.

TCP reset attacks use this mechanism to trick the communicating parties into closing the TCP connection early by sending forged reset segments to the communicating parties. If the forged reset segment is completely realistic, the receiver will think it is valid and close the TCP connection to prevent the connection from being used to exchange further information. The server can create a new TCP connection to resume communication, but the connection may still be reset by the attacker. Fortunately, it takes a certain amount of time for the attacker to assemble and send the forged message, so in general this attack is only effective against long connections. For short connections, you haven't attacked them yet, but they have already completed the information exchange.

In a sense, it is easy to forge TCP segments because TCP/IP does not have any built-in method to verify the identity of the server. Some special IP extensions (such as IPSec) do allow for authentication, but they are not widely used. The client can only receive segments and use higher-level protocols (such as TLS) to verify the identity of the server when possible. However, this method does not work for TCP reset packets because TCP reset packets are part of the TCP protocol itself and cannot be verified using higher-level protocols.

Although it is easy to forge a TCP segment, it is not easy to forge a correct TCP reset segment and complete the attack. In order to understand the difficulty of this work, we need to first understand how the TCP protocol works.

3. How TCP works

The goal of the TCP protocol is to send a complete copy of the data to the client. For example, if my server sends the HTML of my website to your computer over a TCP connection, your computer's TCP protocol stack should be able to output the HTML in the form and order that I sent it.

However, in real life, my HTML content is not sent in order, it is broken down into many small pieces (called TCP packets), each of which is sent separately on the network and reassembled into the order in which it was originally sent. This reassembled output is called a TCP byte stream.

Reconstructing packets into a byte stream is not simple because the network is unreliable. TCP packets may be dropped, may not arrive at the client in the order they were sent, may be sent repeatedly, messages may be damaged, and so on. Therefore, the responsibility of the TCP protocol is to provide reliable communication over an unreliable network. TCP achieves reliable communication by requiring both parties of the connection to keep in close contact and continuously report what data they have received, so that the server can infer the data that the client has not received and resend the lost data.

To further understand this process, we need to understand how servers and clients use sequence numbers to mark and track data.

TCP sequence numbers

Both communicating parties of the TCP protocol must maintain a sequence number. For the client, it will use the server's sequence number to arrange the received data in the order in which it was sent.

When the two communicating parties establish a TCP connection, the client and the server will send a random initial sequence number to each other. This sequence number identifies the first byte of the data stream they send. The TCP segment contains the TCP header, which is metadata attached to the beginning of the segment. The sequence number is included in the TCP header. Since the TCP connection is bidirectional and both parties can send data, the two parties of the TCP connection are both senders and receivers, and each party must allocate and manage its own sequence number.

Confirmation Response

When the receiver receives a TCP segment, it returns an ACK response message to the sender (and sets the ACK flag in the TCP header to 1). The ACK number indicates the sequence number of the next byte that the receiver expects to receive from the sender. The sender uses this information to infer that the receiver has successfully received all bytes before the sequence number ACK.

The TCP header format is shown in the figure below:

The TCP header of a confirmation response message must contain two parts:

• ACK flag is set to 1
• Contains the ACK number

TCP has a total of 6 flags, and the RST flag will be discussed below.

The TCP header contains multiple options, one of which is the Selective Acknowledgement option (SACK). If this option is used, when the receiver receives bytes within a certain range instead of continuous bytes, it will send SACK to inform the other party. For example, only bytes 1000~3000 and 4000~5000 were received, but 3001~3999 were not received. For simplicity, the Selective Acknowledgement option will be ignored when discussing TCP reset attacks below.

If the sender does not receive an ACK within a period of time after sending a message, it considers the message lost and resends the message with the same sequence number. This means that if the receiver receives a duplicate message, it can use the sequence number to determine whether it has seen the message before. If it has, it will be discarded directly. The network environment is complex and often does not arrive at the target host first as we expect. Instead, it may be very complicated. Due to network congestion and other messy reasons, the old data packet may arrive at the target host first. Generally, there are two situations:

1. The sent packet was lost
2. The sent packet was received successfully, but the returned ACK was lost

These two situations are actually the same for the sender, and the sender cannot distinguish which one it is, so it can only resend the data packet.

As long as the data is not sent repeatedly and frequently, the additional overhead can be basically ignored.

Select a serial number for the fake reset package

When constructing a forged reset packet, a sequence number needs to be selected. The receiver can accept segments with sequence numbers that are not in order, but this tolerance is limited. If the sequence number of the segment is far from what it expects, it will be discarded directly.

Therefore, a successful TCP reset attack requires the construction of a credible sequence number. But what is a credible sequence number? For most segments (except reset packets, i.e. RST packets), the sequence number is determined by the receiver's receive window size.

TCP sliding window size

Imagine connecting an ancient computer from the early 1990s to a modern gigabit fiber-optic network. The lightning-fast network can deliver data to this ancient computer at an astonishing rate, far faster than the computer can process it. But it's useless because the message can only be considered received if the recipient receives and processes it.

The TCP protocol stack has a buffer, and newly arrived data is placed in the buffer to wait for processing. However, the size of the buffer is limited. If the processing speed of the receiver cannot keep up with the sending speed of the sender, the buffer will be filled. Once the buffer is full, the excess data will be directly discarded and no ACK will be returned. Therefore, once there is space in the receiver's buffer, the sender must resend the data. In other words, if the processing speed of the receiver cannot keep up, it is useless for the sender to send faster.

How big is the buffer? How does the sender know when to send more data at a time and when to send less data at a time? This is where the TCP sliding window comes in. The receiver's sliding window size is the maximum value of data that the sender can continue to send without waiting for an acknowledgment. Assume that the receiver's advertised window size is 100,000 bytes, so the sender can continue to send 100,000 bytes without waiting for an acknowledgment. Assume that when the sender sends the 100,000th byte, the receiver has already sent the ACK for the first 10,000 bytes, which means that there are still 90,000 bytes in the window that have not been acknowledged, and the sender can continue to send 10,000 bytes. If no ACK is received during the process of sending 10,000 bytes, the receiver's sliding window will be filled, and the sender will stop sending new data (it can continue to send previously lost data) until it receives the relevant ACK.

Both parties in a TCP connection will notify each other of their window sizes during the initial handshake phase of establishing a connection, and can adjust them dynamically later. A server with a large TCP buffer may declare a large window to maximize throughput. A server with a small TCP buffer may be forced to declare a small window, which will sacrifice some throughput, but is still necessary to prevent the receiver's TCP buffer from overflowing.

From another perspective, the TCP sliding window size is a hard limit on the amount of unacknowledged data that may exist in the network. We can use it to calculate the maximum sequence number (max_seq_no) that the sender may send in a certain period of time:

 max_seq_no = max_acked_seq_no + window_size

Where max_acked_seq_no is the maximum ACK number sent by the receiver, which indicates the maximum sequence number that the sender knows the receiver has successfully received. window_size is the window size, which indicates the maximum number of unacknowledged bytes allowed to be sent by the sender. So the maximum sequence number that the sender can send is: max_acked_seq_no + window_size.

The TCP specification states that the receiver should ignore any data with a sequence number outside the receive window. For example, if the receiver confirms all bytes with sequence numbers below 15,000 and the receive window size is 30,000, then the receiver can only receive data with sequence numbers between 15,000 and 45,000. If part of a segment is within the window and part is outside the window, the data within the window will be confirmed and the data outside the window will be discarded. Note: The confirmation option is ignored here, so I emphasize it again!

For most TCP segments, the sliding window rules tell the sender the range of sequence numbers it can receive. But for reset messages, the sequence number restrictions are more stringent. This is to defend against an attack called a blind TCP reset attack, which will be explained below.

TCP reset segment sequence number

For TCP reset segments, the receiver has stricter requirements on the sequence number. It can only receive a segment if its sequence number is exactly equal to the next expected sequence number. Continuing with the above example, the receiver sends an acknowledgment with an ACK number of 15,000. If a reset segment is received next, its sequence number must be 15,000 to be received.

If the sequence number of the reset message exceeds the receive window range, the receiver will simply ignore the message; if its sequence number is within the receive window range, the receiver will return a challenge ACK to tell the sender that the sequence number of the reset message segment is wrong and the correct sequence number. The sender can use the information in the challenge ACK to rebuild and send the reset message.

In fact, before 2010, the sequence number restriction rules for TCP reset segments were the same as those for other segments, but they could not defend against blind TCP reset attacks. Only later were these measures taken to impose additional restrictions.

Blind TCP reset attack If the attacker can intercept the information being exchanged between the two communicating parties, the attacker can read the sequence number and confirmation number on the data packet, and use this information to derive the sequence number of the disguised TCP reset segment. On the contrary, if the information of the two communicating parties cannot be intercepted, the sequence number of the reset segment cannot be determined, but reset messages with as many different sequence numbers as possible can still be sent in batches in the hope of guessing one of the sequence numbers correctly. This is the so-called blind TCP reset attack.

In the original version of TCP before 2010, an attacker only needs to guess any sequence number in the receive window, and generally only needs to send tens of thousands of segments to succeed. After taking additional restrictive measures, the attacker needs to send millions of segments to have a chance of guessing the sequence number correctly, which is almost impossible to succeed. For more details, please refer to RFC-5963[2].

4. Simulate an attack

The following experiments are completed in OSX system. Please test other systems by yourself.

Now let's summarize what needs to be done to forge a TCP reset message:

• Sniff the exchanged information between the two communicating parties.
• Intercept a message segment with the ACK flag set to 1 and read its ACK number.
• Forge a TCP reset segment (RST flag is 1), whose sequence number is equal to the ACK number of the message intercepted above. This is only an ideal solution, assuming that the speed of information exchange is not very fast. In most cases, in order to increase the success rate, you can send reset messages with different sequence numbers continuously.
• Send a forged reset message to one or both parties of the communication to interrupt the connection.

To keep the experiment simple, we can use the local computer to communicate with itself through localhost, and then perform a TCP reset attack on ourselves. The following steps are required:

Establish a TCP connection between two terminals.

Write an attack program that can sniff the data of both communicating parties.

Modify the attack program to forge and send a reset message.

Now let’s officially start the experiment.

Establishing a TCP connection

You can use the netcat[3] tool to establish a TCP connection. This tool is pre-installed on many operating systems. Open the first terminal window and run the following command:

 $ nc -nvl 8000

This command will start a TCP service, listening on port 8000. Then open a second terminal window and run the following command:

 $ nc 127.0.0.1 8000

This command will try to establish a connection with the above service. If you enter some characters in one window, they will be sent to the other window through the TCP connection and printed out.

Sniffing traffic

Write an attack program that uses the Python network library scapy to read the data exchanged between two terminal windows and print it to the terminal. For the complete code, please refer to my GitHub repository [4]. The core of the code is to call the scapy sniffing method:

 t = sniff(
 iface= 'lo0' ,
        lfilter=is_packet_tcp_client_to_server(localhost_ip, localhost_server_port, localhost_ip),
 prn=log_packet,
 count =50)

This code tells scapy to sniff packets on the lo0 network interface and log details of all TCP connections.

• iface : tells scapy to listen on the lo0 (localhost) network interface.
• lfilter: This is a filter that tells scapy to ignore all packets that do not belong to the specified TCP connection (both communicating parties are localhost and the port number is 8000).
• prn: scapy uses this function to operate all packets that meet the lfilter rules. The above example just prints the packets to the terminal. The function will be modified below to forge a reset message.
• count : The number of packets that need to be sniffed before the scapy function returns.

Send a fake reset message

Now we start to modify the program and send a forged TCP reset message to perform a TCP reset attack. According to the above interpretation, we only need to modify the prn function to let it check the data packet, extract the necessary parameters, and use these parameters to forge a TCP reset message and send it.

For example, suppose the program intercepts a segment from (src_ip, src_port) to (dst_ip, dst_port), the ACK flag of the segment is set to 1, and the ACK number is 100,000. The next thing the attack program does is:

• Since the forged data packet is a response to the intercepted data packet, the source IP/Port of the forged data packet should be the destination IP/Port of the intercepted data packet, and vice versa.
• Set the RST flag of the forged data packet to 1 to indicate that this is a reset message.
• The sequence number of the forged packet is set to the ACK number of the intercepted packet, because this is the next sequence number the sender expects to receive.
• Call scapy's send method to send the forged data packet to the sender of the intercepted data packet.

For my program, just uncomment this line [5] and comment the line above it to start the full attack. Set up the TCP connection as in step 1, open a third window to run the attack program, and then enter some strings in one of the terminals of the TCP connection. You will find that the TCP connection is interrupted!

Further experiments

1. You can continue to use the attack program to experiment, add or subtract 1 from the sequence number of the forged data packet to see what happens and whether it really needs to be exactly the same as the ACK number of the intercepted data packet.
2. Open Wireshark, listen to the lo0 network interface, and filter out irrelevant data using the filter ip.src == 127.0.0.1 && ip.dst == 127.0.0.1 && tcp.port == 8000. You can see all the details of the TCP connection.
3. Sending data streams faster over a connection makes attacks more difficult to carry out.

Overall, the TCP reset attack is both profound and simple. I wish you good luck with your experiment.

Article link: https://mp.weixin.qq.com/s/crgraQv6qQ-aVJd9L2u1eg