Mid 2021, an award-winning paper was published announcing the discovery of a network middlebox vulnerability, whereby these devices, such as firewalls used within Censorship Infrastructure, can be abused to launch massive distributed denial of service (DDoS) attacks.
The researchers provided a formidable explanation of the attack and the document is listed in Reference(1).
Over the following months, the Corero SOC team have observed these highly effective amplification attack vectors, at increasing frequency, across the Customer base. Here we share real life details of some of the attack characteristics observed.
Looking at real data from one event where middleboxes were weaponized to target a customer in the cloud services Industry in December-2021, TCP Reflective Amplification was used, with the event lasting over an hour. The attack duration of this significant time period is due either to the attacker continuing to send the attack to reflectors or due to the presence of an infinite loop between the middleboxes and the Victim IP).
- Attack Bandwidth: 1 Gbps to 2 Gbps
- Attack PPS: 1,000,000 PPS
- TCP flags: Multiple
Figure 1: Average Packet per Second by TCP Flags
Figure 2: Average Gbps by TCP Flags
Also of interest, is the geographical spread of the Source of the attack traffic.
Figure 3: Country Distribution
HTTP Responses
In normal scenarios, when users try to access to illegal or forbidden URLs, middleboxes will return a warning to the user that access to that URL is forbidden. To confirm that the attack was indeed the Middlebox Amplification Vector, packets which contained HTTP response pages were filtered and analyzed and then further filtered to isolate those sample packets where an HTTP Response Code and Content-Length field were present.
It was found that a significant quantity of the packet samples filtered contained HTTP response status codes of 403-Forbidden or 302-Moved/Redirect.
Figure 4: HTTP Responses
In packets where the HTTP response was badly formed, often the content is truncated html code of a forbidden page, or contained a reference id (Ref ID) of the application firewall.
Figure 5: Badly Formed HTTP Responses
Where the HTTP response is Forbidden, the URL is consistent during the attack and is commonly URLs which are blocked as standard by the middleboxes, such as porn sites.
Figure 6: HTTP Responses with Blocked URL
Loop
As described in the paper (1), when a victim receives an unexpected TCP packet from a middlebox, it responds with a TCP RST packet. A small number of amplifiers will resend forbidden pages when they process any additional packet, including a RST packet, and when this occurs it can create a loop effect.
Corero observed during lab testing that in some cases the amplifier only returns forbidden pages for the first request and only returns RST packets for any subsequent received packets from a source.
Looking at the sample data from the attack, specifically at the top source IP addresses, the same behavior as seen in the lab is repeated by the real-world source IP addresses.The chart below shows sample traffic from one single source IP, where all the samples are RST or RST:ACK. The duration is 40 mins.
Figure 7: Duration Traffic of a Single Source
Failed Reflectors
Instead of dropping unexpected packets from attackers, victims can respond by sending an ICMP message, which includes a partial amount of the original packet inside the ICMP payload.
By looking into the payload of those ICMP packets, it is possible to see how the attacker was sending the requests
Figure 8: Wireshark Decode of ICMP Response
SYN:ACK responses
In this example attack, most of the TCP packets where the SYN:ACK flags were of the same small packet length and had only one TCP option of mss present.
The explanation for this is that this option is set by a firewall or other network devices during transit. Attackers were most likely sending out optionless SYN requests. Also as previously discussed, in the ICMP message of failed reflectors, it’s visible that there is no TCP option used.
Figure 9: Table of TCP Option layout
Request Format
Although it is still unclear whether attackers are using tools or botnets to launch these attacks, it is possible to describe what the Requests used within the attack look like.
- IP layer:
source IP is the spoofed IP belonging to the Victim. The Destination is the IP or IP range/s which are behind the middleboxes, so that any request to those destination IP/s will be censored and reflected by the middleboxes.
- TCP layer:
- Flags: SYN
- Sequence Number: 100 – 300
- Window Size: 0 or 65365
- TCP Option: none
- Application layer:
Summary
The analysis of this single attack demonstrates the complexities we are now seeing in the DDoS sector.
Attacks are infrequently made up of a single set of characteristics, but often multiple different vectors changing within the lifespan of a single attack. This brings various challenges in how to effectively mitigate the malicious packets without causing harm to legitimate traffic.
To effectively block these attacks, it is key have an entire toolset of mechanisms which operate in a multitude of different ways, which are automatically deployed, operating in real-time. It is also important to have the flexibility of adding manual intervention to be able to adapt where necessary.
The process of Protection (or Mitigation), Detection and Response cycle requires constant maintenance to keep up with the growth and evolution of botnets and new DDoS vectors in the wild.
Reference
- Kevin Bock, Pranav Bharadwaj, Jasraj Singh, Dave Levin – “Your Censor is My Censor: Weaponizing Censorship Infrastructure for Availability Attacks” – University of Maryland
https://geneva.cs.umd.edu/papers/woot21-weaponizing-availability.pdf
Corero Network Security is a global leader in real-time, high-performance, automatic DDoS defense solutions. Corero’s industry leading SmartWall and SecureWatch technology protects on-premise, cloud, virtual and hybrid environments with a scalable solution that delivers a more cost-effective economic model than ever before.For more on Corero’s flexible deployment models, click here. If you’d like to learn more, please contact us.