A team of researchers from Peking University, Tsinghua University and the University of Texas at Dallas
The Range header allows the client to specify a range of positions in the file that should be downloaded instead of serving the full file. For example, the client can specify "Range: bytes=0-1023" and the server will only send the first 1024 bytes of data. This feature is in demand when downloading large files - the user can pause the download, and then continue it from the interrupted position. When specifying "bytes=0-0", the standard prescribes to give the first byte in the file, "bytes=-1" - the last, "bytes=1-" - starting from 1 byte to the end of the file. It is allowed to pass several ranges in one header, for example "Range: bytes=0-1023,8192-10240".
Additionally, a second attack option has been proposed, aimed at increasing the network load when traffic is forwarded through another CDN, which is used as a proxy (for example, when Cloudflare acts as the front end (FCDN) and Akamai as the back end (BCDN). The method resembles the first attack, but is localized inside CDN networks and allows you to increase traffic when accessed through other CDNs, increasing the load on the infrastructure and reducing the quality of service.
The idea is that the attacker sends multi-range Range requests to the CDN, such as "bytes=0-,0-,0-β¦", "bytes=1-,0-,0-β¦" or "bytes=-1024,0 ,0-,0-β¦β. Requests contain a large number of "0-" ranges, implying the return of the file from position zero to the end. Due to incorrect implementation of range parsing, when the first CDN addresses the second one, a full file is given for each β53-β range (the ranges are not aggregated, but sequentially sorted), if there is duplication and overlapping of ranges in the initially sent attacking request. The degree of traffic amplification in such an attack ranges from 7432 to XNUMX times.
During the study, the behavior of 13 CDNs was studied -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath and Tencent Cloud. All of the considered CDNs allowed the first type of attack on the final server. The second version of the attack on the CDN turned out to be subject to 6 services, of which four can act in the attack as a front-end (CDN77, CDNsun, Cloudflare and StackPath) and three as a back-end (Akamai, Azure and StackPath). The greatest gain is achieved in Akamai and StackPath, which allow more than 10 thousand ranges in the Range header. CDN owners were notified about the vulnerabilities about 7 months ago, and by the time the information was publicly disclosed, 12 out of 13 CDNs had fixed the identified problems or expressed their willingness to fix them (only StackPath did not respond).
Source: opennet.ru