Vulnerable DDoS Middlebox Report

LAST UPDATED: 2022-04-26

Introduction

This report identifies devices that can be abused for TCP Middlebox reflection DDoS attacks. Reflection based attacks have been associated primarily with UDP services in the past, but in this case apply to TCP based services instead.

Please note that exploiting TCP Middlebox reflection involves sending custom packets that push payloads in TCP packets that normally do not contain payloads (such as for example a TCP SYN packet), so you cannot verify the susceptibility of a device to attacks by simply running an nmap scan or trying a telnet or netcat connection to the device.

TCP Middlebox Reflection was first disclosed in the Usenix paper “Weaponizing Middleboxes for TCP Reflected Amplification” authored by University of Maryland and University of Colorado Boulder researchers.

As described in the Usenix paper:

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).

Middlebox TCP reflection attacks are possible by taking advantage of TCP-noncompliance in network middleboxes: responding to out of state TCP packets. This behaviour, combined with the fact that middleboxes are commonly configured to block certain traffic, can be abused by an attacker to use the middlebox device as an amplifier and reflector for DDoS attacks when they send custom out of state TCP packets with the source IP address spoofed to the IP address of the DDoS victim.

As noted by Akamai:

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.

How we scan 

We identify abusable middleboxes through scanning with custom TCP packets, specially constructed to elicit the amplified responses.

We currently scan with 2 methods described in the Usenix paper.

  1. SYN packet with sequence number s, followed by a PSH + ACK with sequence number s+1 containing a HTTP GET payload request for a forbidden resource.
  2. SYN packet with a HTTP GET payload request for a forbidden resource.

A forbidden resource in this case is a URL that the middlebox is configured to block.

We base our scans on https://github.com/Kkevsterrr/zmap/blob/618f7dd2b2a0c79a71f00aabc40ab3f9addcc9bd/src/probe_modules/module_forbidden_scan.c.

The HTTP GET payload request embedded in the payloads is: GET / HTTP/1.1\r\nHost: www.you[redacted].com \r\n\r\n

Based on the response received, we also calculate the amplification factor. This amplification is is based solely on the payload size sent and payload size received (ie. without TCP/IP header sizes).

The top amplifier we found has an amplification rate of 6,583,549 with the TOP 10 all above 50,000.

When we remove the biggest amplifiers (there are 70 with an amplification factor over 10,000), the average amplification rates are:

  1. SYN with GET: around 19.4
  2. SYN+PSH:ACK: around 7.6

The median amplification rates are as follows:

  1. SYN with GET: around 9
  2. SYN+PSH:ACK: around 6

Mitigation

If you are notified of a device that is abusable, please consider countermeasures/mitigation techniques that have been described in both of the sources referenced above.

For example, Akamai suggests firewall ACLs can be used to block the known incorrect patterns.

Note however that the request can generally be sent on any port, simply mitigating for queries to 80 is not enough as the middleboxes detect and respond to traffic on any port.

Reconfiguration of the middlebox can also resolve the issue. Reach out to your appliance manufacturer/vendor for guidance.

For more information on our scanning efforts, check out our Internet scanning summary page.

This scan was first announced in our blog post: Over 18.8 million IPs vulnerable to Middlebox TCP reflection DDoS attacks.

Filename: scan_ddos_middlebox

Fields

  • timestamp
    Time that the IP was probed in UTC+0
  • ip
    The IP address of the device in question
  • protocol
    Protocol that the HTTP response came on (always TCP)
  • port
    Port that is being queried (port 80)
  • hostname
    Reverse DNS name of the device in question
  • tag
    Tag set to "ddos-middlebox"
  • asn
    ASN of where the device in question resides
  • geo
    Country where the device in question resides
  • region
    State / Province / Administrative region where the device in question resides
  • city
    City in which the device in question resides
  • naics
    North American Industry Classification System Code
  • sic
    Standard Industrial Classification System Code
  • source_port
    Ephemeral port that the probe was sent from
  • bytes
    Bytes received in response to query
  • amplification
    Amplification factor observed
  • method
    Scan method, ie. how we built the custom scan packets, for example: SYN + ACK:PSH with GET request in the payload or SYN with GET request method in the payload.

Sample

"timestamp","ip","protocol","port","hostname","tag","asn","geo","region","city","naics","sic","sector","source_port","bytes","amplification","method"
"2010-02-10 00:00:00",192.168.0.1,tcp,80,node01.example.com,ddos-middlebox,64512,ZZ,Region,City,0,0,,49002,99,2,SYN+ACK:PSH
"2010-02-10 00:00:01",192.168.0.2,tcp,80,node02.example.com,ddos-middlebox,64512,ZZ,Region,City,0,0,"Communications, Service Provider, and Hosting Service",41200,99,2,SYN+ACK:PSH
"2010-02-10 00:00:02",192.168.0.3,tcp,80,node03.example.com,ddos-middlebox,64512,ZZ,Region,City,0,0,,47492,99,2,SYN+ACK:PSH

Our 124 Report Types