Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how TCP reset attacks work". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The TCP reset attack is performed using a single packet, which is only a few bytes in size. The attacker creates and sends a fake TCP reset packet to interfere with the connection between the user and the website and deceive both sides of the communication to terminate the TCP connection. Our great xx Great Wall uses this technology to block TCP keywords.

Understanding TCP reset attacks does not require deep network knowledge, you only need a laptop to simulate attacks on yourself. This article will take you to understand the principle of TCP reset attack, and will help you understand a lot of features about the TCP protocol. The main contents of this paper are as follows:

Review the basics of TCP protocol

Understand the principle of TCP reset attack

Use a simple Python script to simulate an attack

Let's begin to analyze the principle of TCP reset attack.

1. How did the great xx Great Wall use TCP reset attacks?

You know the reason for skipping this paragraph. If you are interested, please read the original text directly.

2. How TCP reset attacks work

In a TCP reset attack, an attacker sends a fake message to one or both parties of the communication, telling them to disconnect immediately, thus breaking the connection between the two sides of the communication. Normally, if the client receives and finds that the arrived message segment is incorrect for the relevant connection, the TCP will send a reset message segment, which leads to the rapid disassembly of the TCP connection.

The TCP reset attack uses this mechanism to deceive both parties into closing the TCP connection ahead of time by sending fake reset message segments to the communicator. If the fake reset message is fully realistic, the recipient considers it valid and closes the TCP connection to prevent the connection from being used for further exchange of information. The server can create a new TCP connection to restore communication, but the connection may still be reset by an attacker. Fortunately, attackers need a certain amount of time to assemble and send forged messages, so in general, this kind of attack is only lethal to long connections. For short connections, you haven't attacked yet, and the exchange of information has been completed.

In a sense, it is easy to forge TCP message segments because TCP/IP does not have any built-in methods to verify the identity of the server. Some special IP extension protocols, such as IPSec, do authenticate, but are not widely used. The client can only receive message segments and, if possible, use a higher-level protocol, such as TLS, to authenticate the server. However, this method does not apply to the TCP reset package because the TCP reset package is part of the TCP protocol itself and cannot be verified using a higher-level protocol.

Although it is easy to forge a TCP message, it is not easy to forge the correct TCP reset message and complete the attack. To understand the difficulty of this task, we need to first understand how the TCP protocol works.

3. Working principle of TCP protocol

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 stack should be able to output HTML in the form and order in which I sent it.

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

Rebuilding packets into byte streams is not easy because the network is unreliable. TCP packets may be discarded, may not arrive at the client in the order in which they are sent, may be repeatedly sent, messages may be corrupted, and so on. Therefore, the responsibility of the TCP protocol is to provide reliable communication over unreliable networks. TCP achieves reliable communication by requiring both parties to keep in close contact and continuously report what data they have received so that the server can infer the data that has not been received by the client and resend the lost data.

To further understand this process, we need to understand how the server and client use serial numbers (sequence numbers) to mark and track data.

TCP serial number

Both sides of the TCP protocol must maintain a serial number (sequence numbers). For the client, it uses the serial number of the server to arrange the received data in the order in which it is sent.

When both sides of the communication establish a TCP connection, both the client and the server send each other a random initial sequence number that identifies the first byte of the data stream they send. The TCP message segment contains the TCP header, which is the metadata appended to the beginning of the message segment, and the sequence number is contained in the TCP header. Because the TCP connection is bidirectional and both parties can send data, both sides of the TCP connection are both senders and receivers, and each side must assign and manage its own serial number.

Confirm reply

When the receiver receives a TCP segment, it returns an ACK reply message to the sender (along with the ACK flag position 1 of the TCP header), which 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 is ACK.

The format of the TCP header is shown below:

The TCP header of an acknowledgement reply message must contain two parts:

ACK flag position bit 1

Contains confirmation answer number (ACK number)

TCP has a total of six flag bits, of which the RST flag bit is discussed below.

The TCP header contains several options, including a selection confirmation option (SACK). If you use this option, the receiver will send a SACK notification when it receives a range of bytes instead of consecutive bytes. For example, only 1000 '3000 and 4000' 5000 bytes were received, but not 3001 '3999. For simplicity, the selection confirmation option will be ignored when the TCP reset attack is discussed below.

If the sender does not receive the ACK within a period of time after sending the message, it is considered that the message has been lost, and the message is re-sent and marked with the same sequence number. This means that if the receiver receives a duplicate message, it can use the sequence number to determine whether the message has been seen or not, and if so, discard it directly. The network environment is complex, often not as we expected, the data packet sent first will arrive at the target host first, but it is very coquettish, and may make the old data packet arrive at the target host first due to messy reasons such as network congestion. There are generally two situations:

The packet sent is lost.

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

These two cases are actually the same for the sender, and the sender can't tell which case it is, so the sender can only resend the packet.

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

Select the serial number for the forged reset package

You need to select a serial number when building a fake reset package. The receiver can receive message segments whose sequence numbers are out of order, but this tolerance is limited, and if the sequence number of the message segment is far from what it expects, it will be discarded directly.

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

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 transmit data to this ancient computer at an eye-popping speed, far faster than the computer's processing power. But it is of no use, because only when the receiver receives and processes the message can it be considered that the message has been received.

The TCP stack has a buffer in which newly arrived data is placed for processing. However, the size of the buffer is limited, and 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 filled, the excess data is discarded directly and ACK is not returned. So 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 can not keep up, it is useless for the sender to send it as fast as possible.

How big is the buffer zone? How can the sender know when to send more data at a time and when to send less data at a time? This depends on the TCP sliding window. The sliding window size of the receiver refers to the maximum value at which the sender can continuously send data without waiting for a confirmation reply. Assuming that the receiver's notification window size is 100000 bytes, the sender can continue to send 100000 bytes without waiting for a confirmation reply. Suppose that when the sender sends the 100000 byte, the receiver has already sent the first 10000 bytes of ACK, which means that there are still 90000 bytes in the window that have not been acknowledged, and the sender can continue to send another 10000 bytes. If no ACK is received in the course of sending 10000 bytes, the receiver's sliding window will be filled and the sender will stop sending new data (you can continue sending previously lost data) until you receive the relevant ACK.

Both sides of the TCP connection will announce the size of their own window during the initial handshake stage of establishing the connection, which can be dynamically adjusted later. Servers with large TCP buffers may declare a large window to maximize throughput. A server with a small TCP buffer may be forced to declare a small window at the expense of some throughput, but it is necessary to prevent the receiver's TCP buffer from overflowing.

On the other hand, the size of the TCP sliding window is a hard limit on the amount of unacknowledged data that may exist in the network. We can use it to calculate the maximum serial number (max_seq_no) that the sender may send at a particular time:

Max_seq_no = max_acked_seq_no + window_size

Where max_acked_seq_no is the largest ACK number sent by the receiver, it indicates that the sender knows the maximum sequence number that the receiver has successfully received. Window_size is the window size that represents the maximum number of unacknowledged bytes that the sender is allowed to send. 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 serial numbers outside the receive window. For example, if the receiver acknowledges all bytes with sequence numbers less than 15000 and the receive window size is 300.000, then the receiver can only receive data with sequence numbers in the range of 15000 to 45000. If part of the data of a message segment is in the window and the other part is outside the window, the data in the window will be received and acknowledged, and the data outside the window will be discarded. Note: the option to select confirmation is ignored here, so emphasize it again!

For most TCP message segments, the sliding window rule tells the sender the range of sequence numbers that he or she can receive. But for reset messages, the sequence number is more restricted to defend against an attack called blind TCP reset attack (blind TCP reset attack), which will be explained below.

TCP resets the serial number of the message segment

For TCP reset message segments, the receiver is more stringent on the sequence number and can receive it only if it is exactly equal to the next expected sequence number. Continuing with the above example, the receiver sends an acknowledgement with the ACK number 15000. If a reset message is then received, its sequence number must be 15000 before it can be received.

If the sequence number of the reset message is beyond the range of the receive window, the receiver will directly ignore the message; if the sequence number is within the range of the receive window, the receiver will return a challenge ACK, telling the sender that the sequence number of the reset message segment is wrong and the correct sequence number, and the sender can use the information in the challenge ACK to reconstruct and send the reset message.

In fact, before 2010, TCP reset message segments had the same sequence number restrictions as other message segments, but could not resist blind TCP reset attacks, and then these measures were taken to impose additional restrictions.

Blind TCP reset attack

If the attacker can intercept the information being exchanged between the two sides of the communication, the attacker can read the sequence number and acknowledgment response number on their packet and use this information to obtain the sequence number of the camouflaged TCP reset message segment. On the contrary, if the information of both sides of the communication cannot be intercepted, it is not possible to determine the sequence number of the reset segment, but it is still possible to send as many reset messages with as many different sequence numbers as possible in the hope of guessing one of the serial numbers. This is known as a blind TCP reset attack (blind TCP reset attack).

In the original version of TCP before 2010, attackers only needed to guess any sequence number in the receive window, typically sending tens of thousands of message segments to succeed. With additional restrictions, attackers need to send millions of message segments before they can guess the sequence number, which is almost impossible to succeed. Please refer to RFC-5963 for more details.

4. Simulated attack

The following experiments are completed in the OSX system, other systems please test by yourself.

Now let's summarize what you need to do to forge a TCP reset message:

Sniff the exchange of information between the two sides of the communication.

Intercept a message segment of ACK flag position 1 and read its ACK number.

Forge a TCP reset message segment (RST flag position 1) whose serial number is equal to the ACK number of the intercepted message above. This is only an ideal scenario, assuming that the exchange of information is not very fast. In most cases, in order to increase the success rate, continuous reset messages with different sequence numbers can be sent.

When a forged reset message is sent to one or both parties of the communication, the connection is interrupted.

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

Establish a TCP connection between the two terminals.

Write an attack program that can sniff the data of both sides of the communication.

Modify the attack program, forge and send reset messages.

Let's officially start the experiment.

Establish a TCP connection

You can use the netcat tool to establish a TCP connection, which is pre-installed with many operating systems. Open the first terminal window and run the following command:

$nc-nvl 8000

This command starts a TCP service with a listening port of 8000. Then open a second terminal window and run the following command:

$nc 127.0.0.1 8000

This command attempts to establish a connection with the above service, enter some characters in one of the windows, and send it to the other window over the TCP connection and print it out.

Sniffing traffic

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

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 record the details of all TCP connections.

Iface: tell scapy to listen on the lo0 (localhost) network interface.

Lfilter: this is a filter that tells scapy to ignore all packets that are not part of the specified TCP connection (both sides of the communication are localhost and the port number is 8000).

Prn: scapy uses this function to manipulate all packets that conform to lfilter rules. The above example only prints the packet to the terminal, and the following will modify the function to forge the reset message.

Count: the scapy function returns the number of packets that need to be sniffed before.

Send a fake reset message

Let's start to modify the program to send fake TCP reset messages to carry out TCP reset attacks. According to the above interpretation, you only need to modify the prn function to examine the packet, extract the necessary parameters, and use these parameters to forge the TCP reset message and send it.

For example, suppose the program intercepts a message segment sent from (src_ip, src_port) to (dst_ip, dst_port), and the ACK flag bit of the message segment has been set to 1MagACK number 100000. The next thing the attacker will do is:

Because the forged packet is a response to the intercepted packet, the source IP/Port of the forged packet should be the destination IP/Port of the intercepted packet, and vice versa.

The position of the RST flag of the forged packet is 1 to indicate that this is a reset message.

Set the sequence number of the forged packet to the ACK number of the intercepted packet, because this is the next sequence number that the sender expects to receive.

Call the send method of scapy to send the forged packet to the sender who intercepts the packet.

For my program, all I have to do is uncomment this line and comment the top line of this line, and I can make a full attack. Follow the method in step 1 to set up the TCP connection, open the 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 has been interrupted!

Further experiment

You can continue to experiment with the attack program and add or subtract 1 from the sequence number of the forged packet to see what happens and whether it really needs to be exactly the same as the ACK number of the intercepted packet.

Open Wireshark, listen on the lo0 network interface, and filter extraneous 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.

Send data streams faster on the connection, making the attack more difficult to execute.

Overall, the TCP reset attack is both esoteric and simple. Good luck with your experiment.

That's all for "how the TCP reset attack works". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.