Chinese researchers have outlined a way to abuse small requests to web servers hosted through content delivery networks that allows attackers to generate DDoS attacks.
Named RangeAmp [pdf] the attack exploits the hyper text transfer protocol (HTTP) Range Requests attribute to ask for a random, small amount of data from a large file on a server, like a byte out of gigabyte and terabyte sized resources.
Since a CDN is unlikely to have the small amount of data cached, it will have to request the entire large file from the origin server it is stored on, just to serve up a byte of it.
Once the server has transferred the large file to the CDN, the latter system then has to cache the data everywhere.
Meanwhile, the attacker's client that made the malicious request will only receive small amounts of data, making the attack cheap and efficient.
"Unlike other DDoS attacks that need to control a large scale of botnets, the attacker only needs an ordinary laptop to launch the RangeAmp attacks.
The ingress nodes of CDNs are scattered around the world, coming into a natural distributed ‘botnet’.
This makes a RangeAmp attacker able to easily congest the target network and even create a denial of service in seconds, while the attacker pays a small cost," the researchers wrote.
In the worst-case Small Byte Range (SBR) RangeAmp scenario, the researchers were able to generate over 43,000 times larger responses for CDNs and origin servers than the one received by the attacker.
The large amounts of traffic generated could be very costly for CDN customers, the researchers noted.
Flawed CDN implementations of unclear Request for Comment (RFC) internet standards documents are the root cause of the RangeAmp attacks, the researchers said.
Several CDNs were tested and found vulnerable to RangeAmp attacks, including Akamai, Microsoft Azure, Amazon Web Services' Cloudfront, Alibaba Cloud, Huawei Cloud, and Fastly.
Of the 13 CDNs the researchers tested and which were given seven months to work out mitigations against RangeAmp, only Cloudflare decided against implementing measures against the attack.
"Unfortunately, they won’t implement our mitigation solutions because Cloudflare does not want to cache partial responses of certain resources.
"And they [Cloudflare] insisted that they are not deviating away from the specifications," the researchers wrote.
