A new TCP reflection amplification attack technique launched using middleboxes was proposed by Kevin Bock et al. at the University of Maryland USENIX conference in August 2021: an attacker can exploit a vulnerability in TCP session identification in some network middleboxes to achieve a new DDoS reflection amplification attack. Unlike the TCP reflection launched using protocol stacks that could not amplify attack traffic that appeared in 2018, this new attack achieves the effect of TCP protocol-based traffic amplification, which makes the attack technique spread rapidly in the black market and proliferate across the network after its birth.
2. The Past Life of the Reflection Amplification Attack
Before explaining this new attack technique, it is necessary to first explain the reflection amplification attack. The so-called reflection amplification attack is a very common and popular DDoS attack technique, its basic principle is very simple: the attacker through the control of the botnet forged target IP to send requests to a specific public server, the public server will receive the request to send a larger reply message to the target, so as to achieve the attack traffic amplification.
The public server here refers to the server that opens some protocol ports that can be used for reflection amplification, such as DNS, NTP, SNMP, Memcached and so on. These protocols are generally based on UDP, and the protocol itself is flawed, there is no verification of the authenticity of the source IP, and there are far more answer messages than request messages. This reflection amplification technique is simple, effective, and has been loved by hackers, so for a long time UDP reflection is the alias of reflection amplification attack.
Is there a reflection attack using TCP protocol? The answer is yes. Compared to UDP reflection amplification attacks, such reflection attacks using the TCP protocol stack do not actually have a significant traffic amplification effect because the source IP of the request is forged and cannot complete three TCP handshakes with the TCP server to establish a connection, so it cannot get an answer message from the application layer. However, this attack uses the protocol stack characteristics of TCP, so that the target machine sees that the attack traffic has the protocol stack behavior, and the composition is complex (synack, ack, rst and other mixed traffic), resulting in reverse challenge, protocol stack behavior verification and other traditional TCP protection algorithms can not protect, greatly increasing the difficulty of protection, so the birth of this TCP reflection soon became the mainstream of DDoS attacks attack technique.
3 New TCP Reflection Amplification Attack is Coming
3.1 A New TCP Reflection Attack is Born
Weaponizing Middleboxes for TCP Reflected Amplification," published in USENIX Security 2021 by Kevin Bock et al. at the University of Maryland in August 2021 and awarded the Distinguished Paper Award, introduces a new TCP reflective amplification attack launched using middleboxes. attack technique using middleboxes. Unlike the TCP reflection attacks that emerged in 2018, which were limited by the TCP triple handshake mechanism, which made it difficult to achieve traffic amplification, this new attack technique exploits the vulnerability that some middleboxes do not or cannot strictly follow the TCP stack, and finely constructs a specific request that triggers the middlebox to return an intercept page, and since the intercept page is often larger than the request itself, it eventually achieves the attack traffic amplification.
The reason why middleboxes do not or cannot strictly follow the TCP stack is that many middleboxes in the existing network, such as firewalls, compliance systems, etc., take into account the network architecture, performance, stability and other factors are deployed in a bypass, one-sided traffic detection architecture, that is, these systems themselves can only see the incoming traffic data of the server room, and eventually these middleboxes can only determine whether there is a TCP connection based on one-way traffic. There are even middleboxes that do not determine whether there is a TCP connection, and directly parse the request content and issue an interception policy. Therefore, the process of the attacker launching this new TCP rejection attack is simply summarized in the following steps.
- the attacker spoofs the public IP of the target machine, carefully forges a one-way TCP connection to the public IP of a middlebox (usually a compliant system) and sends a request containing an undocumented domain name.
- the middlebox does not do bi-directional traffic tracking of the TCP session, misjudges that the TCP triple handshake has completed, and detects an unrecorded domain name request, triggering an unrecorded domain name blocking action.
- many middleboxes intercept by returning a larger reply message containing a blocked page, the target machine receives a large amount of spam traffic, and eventually the hacker achieves a reflected amplification of the attack traffic.
Note: Of course this attack technique is not effective against middleboxes that are based on bidirectional traffic identification and strictly follow the TCP protocol stack.
3.2 Attack principle and effect details
According to the idea of the attack, if the attacker wants to use this technique in practice, he needs to meet 3 key conditions: 1.
- find an effective means to trick the middlebox into misjudging that a TCP connection has been established
- find an illegal domain name that is more likely to trigger the middlebox interception
- find a middlebox with the largest possible amplification factor
(1) Find an effective means to deceive middleboxes into misjudging that a TCP connection has been established
Since this new TCP rejection attack essentially exploits the weaknesses of some middleboxes, and there is an extremely wide variety of middleboxes in the global interconnection, with differences in the specific mechanisms of different types of middleboxes, it is necessary to find effective, efficient, and general methods to deceive middleboxes into mistakenly thinking that TCP connections have been established. Through testing and analysis, the following main TCP message types or combinations were eventually found to deceive middleboxes.
It is worth noting that a single message can trigger the interception of the scenario is generally the corresponding middlebox does not do any TCP handshake check, but based on a specific flag bit of the message directly extract the domain name and intercept, such middlebox is relatively small. The SYN;PUSH+ACK combination of request messages completely fakes the one-way TCP handshake and HTTP GET request scenario, which can deceive most middleboxes that can only see one-way traffic, so the success rate of triggering reflection amplification is higher.
(2) Find illegal domain names that are more likely to trigger middlebox interception
After finding a way to trick the middlebox into misjudging that a TCP connection has been established, it is necessary to find domain names that are more likely to cause the middlebox to issue an intercept. The so-called Internet censorship is due to political, religious, moral, economic and other reasons, many countries around the world will conduct different levels of Internet traffic censorship and block domain names that do not comply with local laws and regulations and requests for blocking. In general, countries in East Asia, Southeast Asia, and the Middle East have stricter Internet audits, so to some extent the audit systems in these countries and regions are more easily exploited.
While the scope of the review varies by country region, so it is difficult to find a domain that is blocked by all audit middleboxes, Kevin Bock et al. performed a test analysis of public data published in the Quack tool to find five domains that trigger responses from most middleboxes that coincidentally span five different regions.
- Porn-related domains
- Gambling-related domains
- Social media-related domains
- File-sharing related domains
- Sexual health/education-related domains
(3) Find the intermediate box with the largest possible amplification factor
In order to subject the target to a larger attack traffic, it is necessary to find an intermediate box with better amplification as a reflection amplifier, and the amplification factor is the main measure.
The amplification factor can be understood as the amplification of the traffic, and is calculated very simply as the total length of the response/the total length of the query. The amplification factor of traditional UDP reflection attacks is related to the specific protocol implementation, so the amplification factor is a relatively fixed value: except for Memcached reflection attacks, the amplification factor of other UDP reflections does not exceed 600, and is mainly within 200.
The current amplification of this new TCP reflection attack, however, is not a fixed value, because the interception methods of different regions, vendors, and types of middleboxes are not consistent, and can even be said to vary greatly. So in order to quantify and evaluate the amplification factor situation of this technique, we scanned the whole network segment and statistically analyzed the reflection amplifiers with amplification factor over 5: most of the reflection amplifiers have amplification factor between 5 and 100, while over 10,000 powerful amplifiers with amplification factor between 100 and 10,000 were found, but what is more surprising is that several amplification factors over 10,000 were also found However, it is more surprising to find several super amplifiers with amplification factor over 10,000 and even over 50,000.
Then the question arises, it is reasonable to say that the middlebox answer the blocking packet may be larger than the request packet, but the size of the blocking page is after all limited, so the appearance of hundreds of thousands of amplification is understandable, why would there be tens of thousands of times, or even more than 50,000 times the amplification effect? And this is the super amplifier we will discuss next.
In order to understand superamplifiers, we need a systematic understanding of the main reflection scenarios.
Scenario 1: Server Reflection
This scenario where the server receives a request and answers directly, usually returning synack or rst, this reflection scenario is actually a TCP reflection using the server stack that emerged in 2018 and has no significant amplification effect.
Scenario 2: Middlebox Reflection
The attack request triggers the middlebox interception, the middlebox instead of the server to the target machine to answer a larger blocking page, so as to achieve the attack traffic amplification, and the larger the blocking page, the greater the amplification factor. Of course, some middleboxes do not answer the blocking page, but directly return the rst instead of the server, in which case there is no amplification effect.
Scenario 3: server + middlebox reflection
The attack request triggers both the middlebox interception and the back-end server answer, so the target will receive both the middlebox interception page and the server synack or rst, and the amplification factor will be slightly larger than in scenario two.
Scenario 4: middlebox reflection + routing loop
This scenario is the most special, after the attack request arrives at the IDC room where the server is located, due to the routing loop makes the request loop between the two routers, eventually leading to the middle box received a large number of requests, and eventually to the target machine multiple answers to block the page. We know that there is a TTL field in the data message, each routing device will be reduced by one until it is reduced to 0 messages will not be discarded. The initial TTL of the attack request message is set to 255, which means that after the routing loop, the amplification factor will be increased by 200+ times than the original. (Figure below: Attack request loop causes the middlebox to receive a large number of duplicate requests)
Then this situation is not the worst, in some specific network environments, there will be TTL reset (for example, the network is running MPLS protocol and MPLS QOS is set, the MPLS QOS of some vendors’ devices will reset the TTL by default), after the loop the request packet will loop infinitely, and eventually the middlebox is forced to answer the blocked page at maximum capacity until the bandwidth of the egress where it is located is full. The above factors are the reason for the emergence of intermediate boxes with very large amplification factors, and these reflectors are also known as superamplifiers. Of course this loop or infinite loop situation will raise the alarm of IDC operations and security personnel, so the survival of super-reflectors is not stable. For example, after I found a super reflector in India, it was “deactivated” the next day and became a normal reflector.
In addition, there is a fifth reflection scenario mentioned by Kevin Bock et al. in “USENIX Security 2021”: the continuous reflection of the target machine and the middle box can also The ability to achieve infinite amplification, but because the author’s scan did not find this scenario, so this paper does not elaborate.
4. Protection Solutions
The middleboxes that are used as reflective amplifiers, such as firewalls and compliance systems, are generally deployed and operated by the enterprise/operator to which the IP segment belongs, so the amplification effect of the same IP segment is close, which means that if an attacker wants to launch such an attack externally, he will often launch a scanning request to the IP segment where the reflective amplifier is located, which is a sweeping segment for the IP segment where the reflective amplifier is located. DDoS attack. So there are actually two victims of this attack.
- the target machine being attacked.
- the IP segment being used as the amplifier.
What we need is to be able to effectively defend against this attack and at the same time avoid becoming a reflection amplifier for the attacker.
4.1 How to protect against the new TCP backfire attack
If we are targeted by an attacker and become a target machine, then there are two keys to protect against this attack:
- an effective protection strategy.
- adequate protection bandwidth.
In terms of protection strategies: Since middlebox reply messages are actually not significantly different from normal HTTP reply messages in terms of Layer 4 traffic, it is actually more difficult to protect against such attacks, which can generally be protected by the following methods:
- if there is no TCP service traffic on source port 80, TCP traffic on source port 80 can be blocked directly
- Blocking the non-customer region or IP segment
- Protect with the professional DDoS protection capability of cloud vendors, such as Volcano Engine based on years of massive business DDoS attack and defense accumulation of ByteBeat, combined with traffic fingerprinting, machine learning and other technical means to refine the traffic cleaning, cleaning success rate of 99.9% or more, can effectively protect against such new DDoS attacks, so that users can rest easy.
In terms of protection bandwidth: As this attack technique has a traffic amplification effect, the attack traffic is often very large and sufficient protection bandwidth is indispensable. So if the business is targeted by the attacker, when faced with such a large volume of DDoS attacks, very much to promote access to the cloud, through the cloud vendor’s massive amount of protection bandwidth for defense. For example, volcano engine DDoS high defense products rely on massive bandwidth reserve resources and high-quality BGP line type, can easily defend against high traffic DDoS attacks, see https://www.volcengine.com/product/AntiDDoS-pro for more information.
4.2 How to avoid becoming a reflection amplifier
If an enterprise’s middlebox (especially the compliance system) has TCP session identification vulnerabilities, and the compliance blocking page is too large, then it is very likely to be used as a “high-quality” reflection amplifier by external attackers, which will inevitably suffer frequent sweeping DDoS attacks, greatly wasting system performance, egress bandwidth The system performance, egress bandwidth and other valuable resources, and face the risk of complaints and even retaliation by the target machine. For this reason, optimizing the mechanism of middleboxes such as compliance systems to avoid being exploited will become an important security topic, for which we suggest that
- middleboxes can add legitimacy checking and discarding of TCP messages, e.g., syn placements but carrying loads are obviously illegal messages and can be discarded.
- the middlebox should improve the TCP session identification capability and avoid directly extracting domain names from TCP packets and sending them for interception. When the conditions are available, try to check the two-way session based on incoming and outgoing traffic, so that the risk can be completely avoided.