A few days ago researchers announced a new http request amplification DoS attack called RangeAmp.
Amplification attack’s power lies in the ability to turn a few requests into many responses, or utilizing small requests that generate large responses.
Amplification is an “old-school” attack; SMURF, an ICMP amplification attack, was causing havoc on the internet since the late 1990s. It is also an effective attack. Smurf was capable of amplifying the traffic by 20 to 100 times in volume. Since then we have seen many variations of DNS, NTP, UDP amplification attacks each managing to achieve a greater and greater amplification factor culminating in the MEMCACHE attacks that were reported to achieve 51,000 times the amplification.
RangeAmp is not making news for it’s amplification factor, which does top out at a respectable 43,000 times. RangeAmp is making news because it is turning a company’s infrastructure against itself.
In my not-so humble opinion CDNs are too often used as anti-DDoS platform. In fact, the CDN is unable to differentiate between malicious and legitimate traffic, and simply throws more and more bandwidth at the attack until the attackers get bored. With their massive bandwidth capabilities, they give the impression that they are preventing these DoS attacks.
RangeAmp not only avoids the CDNs attempted mollification, it uses the CDN as the amplification mechanism.
How RangeAmp operates:
When transferring files across the internet sometimes things go wrong and the transmission is reset and the file transfer has to start all over again. For large files this can be horribly inefficient. Which is why the HTTP protocol allows for range requests, so only the interrupted portion of the file need be resent. CDNs typically handle range requests by either ignoring or expanding the range thereby requesting full documents from the origin for a range request of only a few bytes. Worse still is the responses for these byte range requests are discarded by the CDN because the CDN does not want to cache partial resources.
Furthermore, because the CDN does all the heavy lifting, this can be done with minimal resources on the attacker’s side. The requests are small, and as long as the CDN follows the protocol the responses will only be the bytes specifically requested. This behaviour of the CDN ensures there is minimal impact to the attacker and minimal traffic to be noticed by anyone administering the network the attacker is using. No need for a botnet; you can create this attack just from your laptop.
Fig 1.
How does DOSarrest deal with the Range Requests?
Assuming that you have enabled caching of the resources in question, and the resource is not already cached, DOSarrest will expand the range request to retrieve a full document from the origin, similar to many other CDNs; however DOSarrest will write this response to cache, and serve any future range requests from the cached document.
NOTE: This default approach does leave a small window while the resource is being transferred, before the cache write has completed where subsequent range requests might be received and because the resource does not yet exist in cache, they will be consequently be expanded and forwarded.
To mitigate this DOSarrest allows you to modify the default caching behaviour by setting a cache “lock” that only allows a single request to initiate a retrieval, all subsequent requests for that resource are held until the cache is populated. You can also set the cache to ignore any range requests altogether.
Fig 2.
Sean Power
Senior Application Security Architect, DOSarrest Internet Security
