RangeAmp attacks can take down websites and CDN servers

A team of Chinese academics has found a new way to abuse HTTP packets to amplify web traffic and bring down websites and content delivery networks (CDNs).

Named RangeAmp, this new Denial-of-Service (DoS) technique exploits incorrect implementations of the HTTP "Range Requests" attribute.

HTTP Range Requests are part of the HTTP standard and allow clients (usually browsers) to request only a specific portion (range) of a file from a server. The feature was created for pausing and resuming traffic in controlled (pause/resume actions) or uncontrolled (network congestion or disconnections) situations.

The HTTP Range Requests standard has been under discussion at the Internet Engineering Task Force (IETF) for more than half a decade, but, due to its usefulness, has already been implemented by browsers, servers, and CDNs.

Two RangeAmp attacks discovered

Now, a team of Chinese academics says that attackers can use malformed HTTP Range Requests to amplify how web servers and CDN systems react when having to deal with a range request operation.

The team says two different RangeAmp attacks exist.

The first is called a RangeAmp Small Byte Range (SBR) attack. In this case [see (a) in the image below], the attacker sends a malformed HTTP range request to the CDN provider, which amplifies the traffic towards the destination server, eventually crashing the targeted site.

The second is called a RangeAmp Overlapping Byte Ranges (OBR) attack. In this case [see b) in the image below], the attacker sends a malformed HTTP range request to a CDN provider, and in the case, the traffic is funneled through other CDN servers, the traffic is amplified inside the CDN networks, crashing CDN servers and rendering both the CDNs and many other destination sites inaccessible.

Academics said they tested RangeAmp attacks against 13 CDN providers and found that all were vulnerable to the RangeAmp SBR attack, and six were also vulnerable to the OBR variant when used in certain combinations.

Researchers said the attacks were very dangerous and required a minimum of resources to carry out. Of the two, RangeAmp SBR attacks could amplify traffic the most.

The research team found that attackers could use a RangeAmp SBR attack to inflate traffic from 724 to 43,330 times the original traffic.

RangeAmp OBR attacks were a little harder to carry out, as the six vulnerable CDNs needed to be in specific (master-surrogate) configurations, but when conditions were met, reserchers said OBR attacks could also be used to inflate traffic inside a CDN network with amplification factors of up to nearly 7,500 times the initial packet size.

Of the two, OBR attacks were considered more dangerous, as attackers could take down entire chunks of a CDN provider's network, bringing down connectivity for thousands of websites at a time.

CDN vendors notified seven months ago

Academics said that for the past few months they have been silently contacting the affected CDN providers and disclosing the details of the RangeAmp attack.

Of the 13 CDN providers, researchers said that 12 responded positively and either rolled out or said they planned to roll out updates to their HTTP Range Request implementation.

The list includes Akamai, Alibaba Cloud, Azure, Cloudflare, CloudFront, CDNsun, CDN77, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, and Tencent Cloud.

"Unfortunately, although we have sent them emails several times and have tried to reach out to their customer services, StackPath did not provide any feedback," the research team said.

"In general, we have tried our best to responsibly report the vulnerabilities and provide mitigation solutions. The related CDN vendors have had nearly seven months to implement mitigation techniques before this paper was published."

Each CDN provider's reply, along with technical details about the RangeAmp attacks, are available in the research team's paper, entitled "CDN Backfired: Amplification Attacks Based on HTTP Range Requests," available for download in PDF format from here .

The paper will be presented in July at the IEEE/IFIP DSN 2020 virtual conference , where it's one of the three papers nominated for the Best Paper Award.