DESCRIPTION LAST UPDATED: 2024-10-09
DEFAULT SEVERITY LEVEL: MEDIUM
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. We are not reporting open ports/services/applications!
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.
- 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.
- 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:
- SYN with GET: around 19.4
- SYN+PSH:ACK: around 7.6
The median amplification rates are as follows:
- SYN with GET: around 9
- SYN+PSH:ACK: around 6
Dashboard
You can track latest Middlebox DDoS scan results on the Shadowserver Dashboard.
Mitigation
NOTE: while you might be flagged for this issue in our reporting, it is possible that there is an intermediate service / country / ISP appliance in front of your resources that is generating a response we are seeing.
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.
Severity levels are described here.
Filename: scan_ddos_middlebox