Abstract
In August 2021, Kevin Bock and his team from the University of Maryland and the University of Colorado Boulder proposed a new TCP reflective amplification attack method initiated by the middlebox at the USENIX conference. (See more details at https://geneva.cs.umd.edu/papers/usenix-weaponizing-ddos.pdf)
In mid-April this year, NSFOCUS spotted that one of its Cloud DDoS Protection Service customers in the APAC region was encountering a TCP-middlebox- reflective attack and captured an attack traffic sample. This article gives an in-depth analysis of the TCP-middlebox- reflective attack, both in theory and practice, and shares mitigation techniques to fend off such attacks.
What Is TCP Reflective Attack?
The figure above shows a typical distributed TCP reflective attack scenario:
- An attacker controls a botnet by sending instructions to compromised network devices including IoT devices, computers, services, and mobile devices.
- In most cases, the botnet constructs an SYN packet containing the spoofed source address of the victims and sends it to a TCP server on the public network.
- After receiving the forged SYN message, the TCP server will send the SYN-ACK, ACK, RST, or other response packets to the victim’s IP address.
- The victim at the spoofed IP address does not send ACK packets to respond as it didn’t send the original SYN packet.
- The number of half-open connections quickly grows on the victim’s server and eventually exhausts the resources allocated for keeping track of the connection, causing the server to refuse new connection requests.
The distributed TCP reflective attack adopts the mechanism of a TCP three-way handshake. From the perspective of the victim’s server, it can be extremely difficult to identify the distributed TCP reflective attack because the source of the attack is a legitimate TCP server. However, the limited amplification factors and the dependencies of SYN /ACK packet retransmission are obviously shortages of the distributed TCP reflective attack.
TCP Reflective Amplification Attack
Compared with UPD reflective amplification attack, the TCP reflective amplification attack is very difficult to launch.
According to the mechanism of TCP protection, the setup of a TCP connection is performed by a three-step handshake between a client that wants to establish the connection and the server that is contacted by the client. However, it is difficult to implement a successful spoofed three-step handshake in the TCP reflective amplification attack scenario, as shown in the figure below.
It is difficult to construct the ack_seq number of the ACK packets (as the third step in the figure above) that is consistent with the sequence number of the SYN/ACK packets (as the second step). Even if the ack_seq number can be consistent with the sequence number, the victim will respond to an RST packet to disconnect the TCP connection after receiving SYN/ACK packets which means the subsequent attack is unachievable.
There are a lot of middleboxes that have been used for various network functionality applications in today’s network environment, like Firewalls and Intrusion Perversion Systems (IPS). To ensure the reliability of the network, middleboxes usually support both Out-of-path deployment and Mirror deployment.
- Out-of-path Deployment: Middleboxes can only receive one-way traffic because traffic between two end-hosts traverses a different path.
- Mirror Deployment: Middleboxes can receive one-way traffic or traffic in both directions by mirror traffic and optical splitter.
According to the Out-of-path Deployment, only SYN packets and ACK packets can be passed through the middleboxes rather than SYN/ACK packets in the process of the TCP three-way handshake.
From a middlebox’s perspective, downlink traffic is the only way to determine whether the connection is established or not. Moreover, some of the middleboxes would abandon the connection checking because the temporary diversion of downlink traffic is unable to detect.
Most middleboxes usually have a censoring function that is typically used to identify forbidden keywords or domains in plaintext traffic, DNS requests, or TLS server name indication (SNI) fields. If there is any connection being identified as a malicious activity, the middleboxes will respond to a block page or close the connection directly by multiple methods: injecting false DNS responses to block pages in response to forbidden HTTP requests, injecting false DNS responses, or injecting RST packets to tear down the connection.
A process of the TCP reflective amplification attack based on middleboxes is shown below:
According to the Kevin Bock and his team’s report, there are several strategies of packets, matching different amplification factors and response percentages as shown below:
The most successful strategy is sending an SYN packet with sequence number N, followed by a second PSH+ACK packet containing sequence number N+1 and the forbidden GET request (referred to as SYN; PSH+ACK). It elicited responses from 69.6% of the middleboxes, with a maximum amplification factor of 7,455×. The single packets strategy can also elicit responses with an amplification factor, but the effect is relatively lower than SYN; PSH+ACK.
Analysis of Captured Packets
1) Packets Characteristics
For TCP reflective amplification attacks, the most noticeable is the HTTP response packet that is mainly used for amplification effect as shown below:
Most of these attack packets come from source port 80, but a few attack packets from source port 443 still be identified as HTTP protocol. Through careful analysis and supposition, missing the authentication of port numbers or an unprecise authentication process is probably the main cause of the misdescription. This has resulted in the failure of preventing TCP reflective amplification attacks by filtering certain source ports.
Compared with the legitimate HTTP packets, the most noticeable characteristic of attack packets is the sequence number equal to 0 or a fixed number. It is mainly due to the incomplete detection of TCP connections in middleboxes, therefore leading to the ack_seq value of reflective packet equal to the sequence value of attack packet.
Part of the pixelated source IP addresses has the same 3rd octet, packet length, and Time To Live as shown in the figure above. According to the characteristics of reflective packets, they are very likely generated by the same middleboxes. But after the verification of these source IP addresses, we found some of them have not been used or even have disabled ports 80. So we can infer that the packets will be censored and produce a reflective attack once the packets can be delivered to middleboxes.
From the perspective of attackers, they will probably implement a certain amplification factor by sending a large number of requests to the IP address within the protection zone of middleboxes. According to the analysis result, it is almost impossible to filter the source IP address of the attack accurately because the source IP addresses are relatively scattered over a wide area.
2) Packets Format And Amplification Factor
There are various packet formats because the reflective attacks involve a variety of middlebox devices.
According to the captured attack packets, we have obtained various blocking packets responded by middleboxes, as an example below:
In addition, there are also other types of reflective packets including 200 OK, 302 Moved, 403 Forbidden, and 503 Service Unavailable.
It’s worth noting that different reflective packets with different packets length will result in a variety of amplification factors. Therefore, finding out middleboxes providing higher amplification factors can be an important step in the attempt of launching such attacks. For example, the reflection source shown in the figure below could have a high amplification factor.
3) Other packets
Some middleboxes may send other packets, like FIN/ACK packets:
There are also some RST/ACK packets found in the result of captured packets analysis, leading to speculation that the RST/ACK packets are probably sent by the devices protected by middleboxes. That is to say, when an attacker sends an illegal request out, the middleboxes reply to stop it, but the protected target does not stop it. Instead, the target responds with RST/ACK packets.
There is also some evidence found about basic TCP reflective packets in the captured attack packets as the real server responded with SYN/ACK or ACK packets after receiving the spoofed SYN packets.
Mitigation Suggestions
Suggestions about middlebox devices:
- According to the deployment models of middleboxes, it could easily lead to the incompletion of connection checking. Please ensure the middleboxes can receive traffic in both directions.
- Create a filtering policy for certain types of packets that need censoring.
- Trying to simplify the block page for minimizing the amplification factor.
- According to the mechanism of source IP determination, middleboxes could tear down the connection by injecting RST packets when certain source IP exceeds the threshold value.
Suggestions about protective policies used specifically for TCP-middlebox- reflective attacks:
- Create a filtering policy to drop the SYN packets with payload.
- For other types of packets with payload, create a filtering policy to drop any TCP packets coming from port 80 or 443.
- GeoIP filtering would be an effective way to prevent TCP-middlebox- reflective attacks.
- If you have NSFOCUS Anti-DDoS solutions deployed, please open the ACK check algorithm of the TCP control policy. This algorithm would drop reflective traffic from middleboxes according to the authenticity identification of source connection by sending a challenge packet.
References
- Kevin Bock, Abdulrahman Alaraj, Yair Fax, Kyle Hurley, Eric Wustrow, Dave Levin. Weaponizing Middleboxes for TCP Reflective Amplification， Kevin Bock,2021.
