In August 2021, researchers from the University of Maryland and the University of Colorado Boulder published an award-winning paper detailing a potential DDoS attack vector that takes advantage of flaws within the middleboxes of TCP protocols and can be abused to launch massive Distributed Denial of Service (DDoS) attacks.
In March 2022, security researchers at Akamai Security Operations Command Center detected and analysed a series of TCP reflection attacks, peaking at 11Gbps at 1.5 million packets per second (Mpps). Upon examining the TCP packets used in the attack, they realized the attackers were leveraging the technique outlined in the above paper, which they termed TCP Middlebox Reflection attack. In this attack, the attacker abuses vulnerable firewalls and content filtering systems to reflect and amplify TCP traffic to a victim’s machine, creating a powerful DDoS attack.
Akamai has since observed multiple middlebox attack campaigns targeting banking, travel, gaming, media, and web-hosting industries.
In this post, I will review the attack vector with examples of how it works and what are the best current practices for defending against it.
How the attack works
To begin, it’s important to understand the basics, so, let’s review how a TCP three-way handshake establishes a reliable connection and what a middlebox is — if you’re familiar with both, skip to the ‘How attackers abuse middleboxes in these attacks‘ section.
TCP three-way handshake
The TCP three-way handshake comprises three steps:
- The client sends an initial connection request to a server. This is known as synchronization (SYN).
- The server can then choose to allow the connection and allocate resources (for example, network port) and respond with a synchronization acknowledgment (SYN+ACK).
- The client completes the handshake with an acknowledging (ACK) packet. This is often followed immediately by a request for content such as an HTML page.
Let’s consider the following packet capture for browsing a web page:
We can see that before establishing a reliable connection, the client sends a SYN packet — usually a legitimate SYN packet length is zero bytes (Figure 2).
Related SYN+ACK and ACK packet lengths are also zero bytes (Figure 3):
After completing a valid three-way handshake, the immediate packet may have a PSH+ACK flag (Figure 4) to request the content (in the situation below, a HTTP page) and this packet length is usually greater than zero bytes.
The three-way handshake protects TCP applications from being amplifiers because if an attacker sends a SYN packet with a spoofed source IP address, the SYN+ACK will go to the victim, and the attacker never learns critical information contained in the SYN+ACK, which is needed to complete the three-way handshake. Without receiving the SYN+ACK, the attacker can’t make valid requests on behalf of the victim.
What is a middlebox
A middlebox (as per RFC 3234) is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Firewalls, NAT devices, load balancers, and deep packet inspection (DPI) devices are common examples of middleboxes.
How do attackers abuse middleboxes in these attacks
Middleboxes usually have a filtering function that is typically used to identify forbidden keywords or domains. If there is any connection being identified as a forbidden request, the middleboxes will respond with a block page or close the connection directly. Middlebox systems are employed by enterprise content filtering systems to nation-state censors.
In some instances, middleboxes are deployed in a non-TCP-compliant mode, for example in asymmetric routing environments, where the middlebox can only see one direction of packets in a connection (packets from clients to servers).
Attackers can take advantage of this setup by sending a spoof source address via one side of a TCP three-way handshake packet to the not TCP-compliant middlebox. This would cause the middlebox to send amplified responses to the spoofed address (victim) resulting in a devastating DDoS attack (Figure 5). Note that this is the weakness of implementation, not the design of the TCP protocol itself.
So far, researchers have found five packet sequences that elicit amplified responses from middleboxes. Each of these contain a well-formed HTTP GET request for some domain that is forbidden by a middlebox such as a SYN packet with an HTTP GET payload request for a forbidden resource.
In Figure 6, we can see a single SYN carrying a forbidden web request (HTTP GET) payload to a vulnerable middlebox. We know this because the TCP payload is 44 bytes. These 44 bytes trigger a 3,426-byte response from the vulnerable middlebox, which is nearly a 77x amplification factor.
A vulnerable middlebox may respond with other types of reflective packets too, such as 200 OK, 302 Moved, 400 Bad Request, 403 Forbidden, 404 Not Found and 503 Service Unavailable. In Figure 7, the middlebox responds with the HTTP 400 Bad Request code and the amplified response is sent to the victim.
How to detect if your IP is vulnerable to middlebox attacks
As we’ve learnt, exploiting TCP Middlebox Reflection involves sending custom packets that push payloads in TCP packets, which normally do not contain payloads (for example, a normal TCP SYN packet). Simply running an ‘nmap’ scan or trying a telnet or netcat connection to the device with a destination port cannot verify the susceptibility of a device to attacks.
The researchers who first detailed the attack described two methods to detect potentially vulnerable middleboxes. These were to scan IPv4 addresses for:
- SYN packets with a sequence number s, followed by a PSH + ACK with a sequence number s+1 containing an HTTP GET payload request for a forbidden resource.
- SYN packets with an HTTP GET payload request for a forbidden resource. A forbidden resource in this case is a URL that the middlebox is configured to block.
The researchers also provided an open-source tool to help you do this.
Using these scanning methods, Shadowserver researchers found that more than 18.8 million IPs are vulnerable to Middlebox TCP Reflection DDoS attacks, which can also be leveraged to launch TCP-based DDoS Reflection attacks. You can get check if any of your IPs are on this list by subscribing to the Shadowserver ‘Vulnerable DDoS Middlebox Report’.
Recommendations for mitigating TCP Middlebox Reflection attacks
Anti-spoofing systems
One of the main reasons why this type of reflected amplification attack is so successful is because an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible this type of attack vector might be mitigated.
The Spoofer project shows that a good number of IPv4 Autonomous Systems (ASes) allow or partially allow spoofing. So, we should consider the anti-spoofing systems or modules to stop spoofed packets from leaving the network.
Firewall ACLs
Usually, SYN packets are used to initiate the TCP handshake; they’re not used for data transmission (recall Figure 2). This means that SYN floods with a length greater than zero bytes should be suspect. Akamai suggests firewall Access Control Lists (ACLs) can 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 100This rule would drop any SYN packets coming from port 80 with a packet length greater than 100. In a nutshell, any packet with a SYN flag exceeding a certain size should be detected and blocked.
Please note that simply mitigating for queries to port 80 is not enough as the middleboxes detect and respond to traffic on any port. Reconfiguration of the middlebox with proper TCP-compliant mode can resolve this issue.
Regularly check for patches and guidelines
Some security vendors have already developed support and patches for this issue. We should regularly check related vendor security advisories for such patching and guidelines.
Debashis Pal is an Information Security Specialist from Bangladesh.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Nice Write-Up also well explained.
Very informative article.
For the amplification example, I’m assuming this:
“These 44 bytes trigger a 3,426-byte response from the vulnerable middlebox, which is nearly a 77% amplification factor.”
…should read “is nearly a 77x amplification factor”, not a “77% amplification factor”?
Good spot Hugo. Now updated in the post.