TCP Middlebox Reflection: Coming to a DDoS Near You
Written by: Akamai Security Intelligence Response Team
Executive summary
Over the past week, Akamai Security Researchers have detected and analyzed a series of TCP reflection attacks, peaking at 11 Gbps at 1.5 Mpps, that were leveled against Akamai customers.
The attack, amplified with a technique called TCP Middlebox Reflection, abuses vulnerable firewalls and content filtering systems to reflect and amplify TCP traffic to a victim machine, creating a powerful DDoS attack.
Middleboxes range from nation-state censors, such as the Great Firewall of China, to corporate enterprise content filtering systems, and can be found globally.
The novel technique was presented in theory last August by researchers from the University of Maryland and the University of Colorado; however, this is the first we’re seeing it live and in the wild.
This type of attack dangerously lowers the bar for DDoS attacks, as the attacker needs as little as 1/75th (in some cases) the amount of bandwidth from a volumetric standpoint.
Some middlebox implementations allow attackers to add SYN, ACK, or PSH+ACK flooding to the attack, on top of the volumetric TCP attack.
Attacks have been observed against organizations in the banking, travel, gaming, media, and web-hosting industries.
Although the current attack traffic is relatively small, we expect to see this type of attack to grow in the future, due to the significant amplification it offers an attacker.
Introduction
In recent weeks, Akamai researchers began observing multiple distributed denial of service (DDoS) attack campaigns against Akamai customers that had included SYN flooding and high volumes of traffic: up to 11 Gbps at 1.5 million packets per second (Mpps). Upon examining the TCP packets used in the attack, we realized that they are leveraging a new technique known as TCP Middlebox Reflection.
TCP Middlebox Reflection was first disclosed as a new DDoS attack vector in August 2021 in a paper authored by researchers from the University of Maryland and the University of Colorado Boulder. “Weaponizing Middleboxes for TCP Reflected Amplification” illustrated how devices like firewalls and content filtering systems can be leveraged in reflective TCP attacks. Middlebox DDoS amplification is an entirely new type of TCP reflection/amplification attack that is a risk to the internet.
This is the first time we’ve observed this technique in the wild. In this blog, we’ll discuss the attack vector, explain how it works, show examples from the attacks we’ve encountered, and share information on the threat it poses to a network, as well as mitigation techniques that may aid defenders during attacks.
TCP Middlebox Reflection — a new DDoS attack vector
A middlebox is an in-network device that sits on the path between two communicating end-hosts and can monitor, filter, or transform packet streams in-flight. Unlike traditional network devices like routers and switches, middleboxes operate not only on packets’ headers but also on their payloads using Deep Packet Inspection (DPI).
— “Weaponizing Middleboxes for TCP Reflected Amplification”
As mentioned, TCP Middlebox Reflection is first disclosed in the paper “Weaponizing Middleboxes for TCP Reflected Amplification.” In it, the authors attempt to demonstrate the viability, and effectiveness, of TCP-based amplification, compared with well-known UDP- based techniques. By taking advantage of TCP noncompliance in network middleboxes, the team was able to create highly effective TCP-based reflective amplification attacks.
The research authors discovered that some of these middlebox systems don’t take TCP stream states into account when attempting to enforce content filtering policies. These boxes can be made to respond to out-of-state TCP packets. These responses often include content in their responses meant to “hijack” client browsers in an attempt to prevent users from getting to the blocked content. This broken TCP implementation can in turn be abused to reflect TCP traffic, including data streams, to DDoS victims by attackers.
The research authors note that there are hundreds of thousands of middlebox systems vulnerable to this TCP reflection abuse around the globe. In their testing they discovered amplification rates that surpass popular and often abused UDP reflection vectors. Some of the vulnerable systems found in the wild offer an amplification rate greater than some of the hardest-hitting UDP vectors, such as NTP, RIPv1, and even the now infamous memcached.
The attack: abusing TCP non-compliance in middleboxes
Attackers can craft various TCP packet sequences that contain HTTP request headers; in these HTTP headers, a domain name for a blocked site is used as the host header. When these packets are received by the middlebox that is configured to not allow access to the site, the middlebox responds, typically with HTTP headers and in some cases entire HTML pages. These responses provide attackers with a reflection opportunity, and in some cases a significant amplification factor.
To abuse these boxes for distributed reflective denial of service (DRDoS) attacks, an attacker spoofs source IPs of the intended victim, resulting in response traffic directed at the victim from the middleboxes. Middlebox systems that have been configured in this way can be found on networks all around the internet as they’re commonly used by nation-states to enforce censorship laws or by corporate enterprise content filtering policies.
Fig. 1. Example responses from vulnerable middlebox
In the example traffic in Figure 1, you can observe a middlebox leveraged in real-world attacks impacted by this issue. Sending a single SYN packet with a 33-byte payload will trigger a 2,156-byte response; this is a 65x (6,533%) amplification factor. Amplification like this serves as a force multiplier because an attacker needs less bandwidth to launch the attack than defenders need to cope with it.
Volumetric TCP attacks previously required an attacker to have access to a lot of machines and a lot of bandwidth, normally an arena reserved for very beefy machines with high-bandwidth connections and source spoofing capabilities or botnets. This is because until now there wasn’t a significant amplification attack for the TCP protocol; a small amount of amplification was possible, but it was considered almost negligible, or at the very least subpar and ineffectual when compared with the UDP alternatives.
If you wanted to marry a SYN flood with a volumetric attack, you would need to push a 1:1 ratio of bandwidth out to the victim, usually in the form of padded SYN packets. With the arrival of middlebox amplification, this long-held understanding of TCP attacks is no longer true. Now an attacker needs as little as 1/75th (in some cases) the amount of bandwidth from a volumetric standpoint, and because of quirks with some middlebox implementations, attackers get a SYN, ACK, or PSH+ACK flood for free.
Fig. 2. Middlebox ignores RST
In Figure 2, we can see a middlebox responding to a SYN packet, but what’s important here is that in response to a SYN packet, the middlebox (for reasons unknown) is responding with a SYN packet of its own. To make things worse, it’s sending multiple SYN packets, all of which are loaded with data. Another important thing to note here is that the middlebox completely disregards the RST packets from the “victim” and continues pushing its data across the wire, continuing to pump data-packed SYN packets until it’s done.
Another concerning finding by the original authors is the existence of boxes that do handle RST packets. These boxes, when receiving a RST packet, react by resending the data packet they’d already transmitted that triggered the RST in the first place; this will in turn result in another RST, and another data packet. This means that there are cases in which a box can and will end up in what amounts to an “infinite loop” of self-perpetuation amplification.
In this demo, these RST packets are sent from the “victim” because no TCP service is listening on TCP/45678 — and this is actually a best-case scenario. As we’ll see in the following screenshot, if an attacker targets a port with a TCP service running, things only get worse.
Fig. 3. Example responses from vulnerable middlebox targeting a TCP service
In Figure 3, we see a TCP service is now running on TCP/45678. This volumetric attack now becomes a resource exhaustion attack: These SYN packets directed at a TCP application/service will cause that application to attempt to respond with multiple SYN+ACK packets, and hold the TCP sessions open, awaiting the remainder of the three-way handshake. As each TCP session is held in this half-open state, the system will consume sockets that will in turn consume resources, potentially to the point of complete resource exhaustion.
Observed attacks — a growing vector
The Akamai Security Operations Command Center has observed multiple middlebox attack campaigns targeting banking, travel, gaming, media, and web-hosting industries. The observed attacks leveraging this technique thus far are still small compared with other vectors, but they do appear to be growing in popularity and size.
The earliest attacks in the series reached a peak of 50 Mbps. The actors behind these recent campaigns appear to be honing the capability and/or fine-tuning their set of favored reflectors. More recent attacks targeting the same sets of victims using the same middlebox vector hit peaks 2.7 Gbps and 11 Gbps, with the 11 Gbps attack hitting 1.5 Mpps.
Although these attacks are relatively small as of right now, it does show that attackers are starting to pick up on the middlebox attack technique and beginning to leverage it as yet another tool in their DDoS arsenal.
Mitigation suggestions
Middlebox reflection attacks are new, but they’re not incredibly unique. Their real threat comes from the lowering of the bar for the attackers who wish to leverage them. That said, padded SYN floods have been a common technique leveraged by attackers for years. Mitigating a middlebox attack in that regard will employ the same techniques and tactics.
In real-world applications, with very few exceptions, SYN packets are used to initiate the TCP handshake; they’re not used for data transmission. This means that SYN floods with a length greater than 0 bytes should be suspect, and might be a metric that you can leverage for mitigation.
SYN challenges may also be effective at preventing middlebox resource exhaustion effects. The middlebox will not properly handle the resulting challenge packet, so the SYN packets won’t make it past mitigation gear, and since the handshake will never complete, data flows should also be dropped before making it to servers and applications.
Other methods would be using a combination of antispoofing and out-of-state mitigation modules that would be able to thwart the attack easily and using signature tools like snort to drop cleartext patterns as seen in the response traffic. Firewall ACLs can also be used to block the known incorrect patterns; for example, a rule like:
deny tcp any eq 80 host x.x.x.x match-all +syn -ack packet-length gt 100
This rule would drop any SYN packets coming from port 80 with a packet length greater than 100.
Conclusion
When new attack vectors are discovered, it’s always a toss-up if and when attackers will begin to leverage them. The middlebox attack remained theoretical for a lot longer than we initially anticipated, taking months before we saw it really leveraged in the wild.
Now that TCP Middlebox Reflection has been tested and verified against real-world networks, it’s likely that attacker adoption will continue. It’s also likely that attackers will attempt to improve and expand the attack’s capabilities and overall impact.
The Akamai Security Intelligence Response Team’s goal is to track, discover, document, and publish new discoveries to protect the security and stability of the internet as a whole. We will continue to monitor these attacks and update this blog accordingly.
References
