Content filtering devices abused for 65x DDoS amplification

DDoS

Researchers have identified an alarming new trend in DDoS attacks that target packet inspection and content filtering devices to attain enormous 6,533% amplification levels. With such an amplification level, threat actors can launch catastrophic attacks with limited bandwidth/equipment.

DDoS (distributed denial of service) attacks are used to take down a server or corporate network by overwhelming network devices such as servers and routers with a large number of bogus requests or very high volumes of garbage data.

When the device becomes overwhelmed, it can no longer accept legitimate traffic and thus fails to operate correctly. While DDoS attacks do not permanently destroy data or breach networks, they can still impose significant financial damage due to extended service outages and downtimes.

Being such a potent threat, Internet security service providers have developed advanced detection and mitigation solutions, to which DDoS actors have responded with new tricks and different approaches.

A new DDoS approach

In the context of this “cat and mouse” game, Akamai has seen a new DDoS attack method used in the wild called ‘TCP Middlebox Reflection,’ which was first examined by a team of American university researchers in August 2021.

A middlebox is a network device that performs packet inspection or content filtering by monitoring, filtering, transforming packet streams exchanged between two internet devices.

Middleboxes don’t just handle packet headers, but also the contents of packet, so they are employed in deep packet inspection (DPI) systems.

The idea is to abuse vulnerable firewalls and content filtering policy enforcement systems in middleboxes using specially crafted TCP packet sequences that cause the devices to spew a voluminous response.

Akamai analysts observed an actual SYN packet with a 33-byte payload triggering a 2,156-byte response, achieving an amplification factor of 65x.

“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,” explains Akamai’s report.

“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.”

With each reflection, a new amplification step is added, so the response size can quickly get out of hand, and these attacks can surpass even the well-established UDP vectors in potency.

Responses triggered from a vulnerable middlebox
Responses triggered from a vulnerable middlebox (Akamai)

Akamai describes an attack at a port with a running TCP service as follows:

“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.”

Akamai

From paper to reality

Akamai has observed TCP Middlebox Reflection attacks in the wild in campaigns targeting banking, travel, gaming, media, and web-hosting service providers.

Although the attacks are small for now, with the most significant reaching 11 Gbps (at 1.5 Mpps), the threat analysts consider it only a matter of time before the adversaries fine-tune their techniques and find the best reflecting patterns.

In response to this rising trend, Akamai suggests the following mitigation approaches:

  • Treat all SYN floods with a length greater than 0 bytes as suspicious.
  • Introduce SYN challenges to sabotage the handshake and drop malicious data flows before reaching apps and servers.
  • Use a combination of antispoofing and out-of-state mitigation modules.
  • Add Firewall ACLs (rules) to drop SYN packets with a length greater than 100.
Start a discussion …
Source link