Deconstructing HTTP/2 Rapid Reset Attack (CVE-2023-44487)

Deconstructing HTTP/2 Rapid Reset Attack (CVE-2023-44487)

Over the last few days, you might have heard about the 'rapid reset' vulnerability in the HTTP/2 protocol (known as CVE-2023-44487).

This post will break it down into a few sections, including how it works, the scale of the problem, and how fixes are being implemented.

Amazon Web Services, Cloudflare, and Google, have already announced their experiences of this vulnerability, and how it was detected, and what they are doing / have done to protect their clients' assets from this attack. Some providers detected this vulnerabiltiy as early as the 25th August 2023.

What is this vulnerability?

In HTTP/1.1, each request is processed sequentially. The server will read a request, process it, compose a response, and ONLY then, read and process the next request.

The 'Rapid Reset' technique exploits a feature of HTTP/2, called 'stream multiplexing'. Stream multiplexing is great because it enables clients to have multiple in-transition requests without the need for many individual connections, reducing round-trip times compared to the previous HTTP/1.1 version.

In essence, a large number of requests followed by swift cancellations can impose a significant workload on the server, all while incurring minimal costs for the attacker, essentially giving attackers with limited resources the ability to perform extremely powerful Denial of Service attacks.

A quote from Cloudflare:
"The attacker was able to generate such an attack with a botnet of merely 20,000 machines. There are botnets today that are made up of hundreds of thousands or millions of machines. Given that the entire web typically sees only between 1–3 billion requests per second, it's not inconceivable that using this method could focus an entire web’s worth of requests on a small number of targets."

This vulnerability has actually broken records by far, with some attacks detected at over 201 million requests per second, which is over 3x bigger than an attack mitigated by Cloudflare in February this year (2023), of over 71 million requests per second.

HTTP/1.1 and HTTP/2 request and response pattern (Google, 2023)

HTTP/2 does include a security feature aimed at restricting the number of active streams to safeguard against DoS attacks. However, this safeguard clearly isn't foolproof. The protocol permits clients to unilaterally cancel streams, and this vulnerability is exploited in the attack. Botnets are capable of generating an extensive volume of requests, thereby posing a significant threat to the web infrastructures they target.

How is it being fixed?

Most Big Tech platforms have all implemented patches for their service clients. If you are self-hosted, it is important to implement patches as soon as possible.

Nginx released a patch for their web server software today, which is actually an incredibly simple fix, with a total of 17 lines modified:

HTTP/2: per-iteration stream handling limit. · nginx/nginx@6ceef19
To ensure that attempts to flood servers with many streams are detected early, a limit of no more than 2 * max_concurrent_streams new streams per one event loop iteration was introduced. This limi…

.

Apache has also rolled out patches for its various software platforms, including Traffic Server:

Add an HTTP/2 related rate limiting by maskit · Pull Request #10564 · apache/trafficserver
Apache Traffic Server™ is a fast, scalable and extensible HTTP/1.1 and HTTP/2 compliant caching proxy server. - Add an HTTP/2 related rate limiting by maskit · Pull Request #10564 · apache/trafficserver

As always, keep your software/security patches up-to-date as soon as possible! Stay safe out there!

Helpful References/Resources