What is a RangeAmp attack?

In early 2020, a team of Chinese researchers found a new way to abuse HTTP packets to amplify web traffic and bring down websites and content delivery networks (CDNs). Named “RangeAmp”, the attack exploits the HTTP range requests attribute that allows clients (usually browsers) to request only a specific portion (range) of a file from a server.

Two types of RangeAmp attacks were identified. The first, known as a RangeAmp Small Byte Range (SBR) attack, is accomplished by sending a malformed HTTP range request to a CDN provider, which amplifies the traffic towards the destination server, eventually overwhelming the targeted site.

The second type is called a RangeAmp Overlapping Byte Range (OBR) attack. To exploit the RangeAmp OBR attack, the attacker also sends a malformed HTTP range request to a CDN provider, but in this case, the web traffic is funnelled through other CDN servers. This attack method amplifies the web traffic inside the CDN networks and not only crashes CDN servers, but also renders the CDNs and many other destination sites inaccessible.

Nexusguard RangeAmp Policy

HTTP Range Requests are part of the HTTP standard that allow web clients to request only a specific range of a file from the web server. This feature was created for pausing and resuming traffic in controlled (pause/resume actions) or uncontrolled (network congestion/disconnection) situations. RangeAmp attacks exploit the incorrect implementations of the HTTP range requests attribute by manipulating CDN servers to amplify traffic towards destination servers and ultimately crash targeted sites.

Nexusguard’s “RangeAmp Rule” is designed specifically to mitigate invalid requests that exploit this vulnerability.

To safeguard against RangeAmp attacks, Nexusguard’s Application Protection (AP) is bolstered by the addition of the following RangeAmp Rule checks:

1. Min Range Bytes checks incoming requests for minimum accepted HTTP range.

2. Max Range Count checks incoming requests for maximum accepted HTTP range.

3. Invalid Byte Pos checks for invalid byte position in the byte-range-response that has:
(a) last-byte-pos value less than its first-byte-pos value
(b) a complete-length value less than or equal to its last-byte-pos value
(c) a range containing negative integer
This checking rule cannot be disabled and must be adhered to.

4. Overlapping checks for overlapping ranges in the message body. This checking rule cannot be disabled and must be adhered to.

If one or more of the above checking rule conditions are met, the TCP connection is closed by default, thereby nullifying any threat instantly. Alternatively, it can be configured to redirect to an HTTP error page.

Unlike a typical CDN provider that seeks to absorb and serve all requests legitimate or otherwise, Nexusguard’s mitigation methodology involves filtering and stringent rule checking techniques that inspect all HTTP requests so that malicious or invalid requests never reach the backend server.

To learn more about Nexusguard’s RangeAmp Policy, please read about our Application Protection.