Rapid Reset HTTP/2 vulnerability: When streaming leads to flooding

What you need to know

 

• The Rapid Reset HTTP/2 vulnerability tracked as CVE-2023-44487 allows distributed denial of service (DDoS) attacks on an unprecedented scale.
• Starting in late August 2023 and continuing through October, the vulnerability has been exploited multiple times in attacks that ranged from 120 million to nearly 400 million requests per second.
• The weakness is in the HTTP/2 protocol itself, making it necessary to patch or reconfigure all web servers, load balancers, proxies, and other appliances that support HTTP/2 connections.
• As of this writing, some attacks are still happening. Google, AWS, Cloudflare, and other major industry players have coordinated a response to minimize the impact of further attacks while patches are rolled out.
• All organizations running services that accept HTTP/2 traffic are advised to follow their internet service provider’s guidance to patch or otherwise mitigate the vulnerability.

Invicti’s cloud services, including the on-demand versions of Invicti and Acunetix products, are not at risk. Invicti is following all recommended mitigation measures, and no service disruptions are expected.

“Biggest DDoS attack ever” headlines have long stopped catching anyone’s eye – but this time was different. On August 25, 2023, and in the days that followed came a flood of DDoS attacks over HTTP/2 that surpassed anything seen in the past. By abusing a feature of the HTTP/2 protocol that was designed to maximize throughput, relatively small botnets were sending hundreds of millions of requests every second. Only the world’s largest internet and cloud providers could possibly stand up to the intense bombardment – and mitigation wouldn’t be easy.

What is HTTP/2 and who uses it?

The HTTP protocol was created as the backbone of the World Wide Web way back in 1989 and was designed to transmit static, hyperlinked documents. The most widely used and supported version today is HTTP/1.1, which includes some concessions to complex, high-performance modern web use cases like streaming but still imposes serious limitations.

HTTP/2 was designed to address these shortcomings and incorporate current needs into the protocol to cut down traffic overhead and increase throughout, especially for data streaming. As of this writing, HTTP/2 is supported by just over 35% of all websites (source: W3Techs), which may not look like much – but that number includes all the world’s highest-traffic services and applications.

What is the Rapid Reset HTTP/2 vulnerability?

In a nutshell, attacks that exploit the Rapid Reset HTTP/2 vulnerability flood a server with potentially millions of HTTP/2 requests, immediately followed by request cancellations (resets). Unlike with HTTP/1.1, the client doesn’t have to wait for a response before sending the next request (and next reset). Even though no actual data is sent or received and connections will eventually be abandoned, the server still has to prepare to receive each request and potentially expect further requests from the same client. With huge request volumes arriving from thousands of hosts in a short time, this can rapidly exhaust server resources, resulting in a denial of service.

The vulnerability is not a typical security flaw in some specific application but the result of a lack of security foresight in the HTTP/2 specification itself. One of the major requirements for HTTP/2 was to make streaming easier and more efficient. With HTTP/1.1, only one HTTP request at a time can be processed over a single TCP connection, meaning that the client needs to wait for a response before sending the next request. This is fine when fetching a web page but very inefficient for sending continuous data streams.

Even though HTTP/1.1 added request pipelining to address this limitation, the feature proved troublesome and unreliable in practice, and dealing with the problem properly was one of the main requirements for HTTP/2. The newer protocol allows clients to open multiple concurrent streams within the same TCP connection, typically up to 100 streams at a time. This multiplexing feature is great for efficient streaming but, if abused, could also allow attackers to send 100 times more malicious requests from a single host – and the protocol specification doesn’t impose any security-minded limitations.

The HTTP/2 protocol also allows the client to cancel (reset) a connection and carry on without waiting for any server response. Again, the specification doesn’t limit this behavior, and so we get to the vulnerability. By combining multiple streams per connection with the freedom to unilaterally reset any number of requests, attackers can generate massive amounts of malicious traffic using botnets that are much smaller than usual, making them easier to build and deploy. In effect, the attacks abuse the request reset feature at an extreme intensity and then use multiplexing as a force multiplier. As it turns out, when you give great power to all users, you need to remember some of them could be malicious.

Can you test if a system is vulnerable to Rapid Reset HTTP/2?

Because the vulnerability is caused by the lack of security guardrails in the protocol and only manifests itself by resource exhaustion, safely testing for it is hard, if not impossible. Whether a specific server is vulnerable depends on a complex combination of rate limit settings on the server and whatever appliances and services stand between it and an attacking botnet. The only thing anyone can be sure of at this stage is that without immediate mitigation, any service that supports HTTP/2 connections could be vulnerable.

Mitigations and the future of HTTP/2

If you run an HTTP/2 server, look for product-specific patches and mitigation guidance to configure rate limits that block known malicious traffic patterns by capping the number of concurrent streams. Major providers like Google, AWS, and Cloudflare have also coordinated a response to detect and block attack attempts, as they do for other types of DDoS attacks. Combining such application-layer shielding with patches and configuration updates should be sufficient to keep HTTP/2 servers safe from currently known attacks without a major impact on performance. As a last resort, if you cannot apply suitable patches and use runtime DDoS protection, you may want to consider disabling HTTP/2 altogether – keeping in mind that (to quote Microsoft guidance) this can “significantly influence performance and user experience.”  

HTTP/2 has long attracted criticism for being something of a rushed effort and a missed opportunity to properly address deep underlying issues with request pipelining and multiplexing. Considering that they exploit this very functionality, the Rapid Reset attacks seem to validate these concerns. Many of the shortcomings are addressed by the HTTP/3 protocol, which was published as a proposed standard in 2022 and, though not yet widely used, is already supported by most major web servers and browsers. Seeing as attacks against HTTP/2 are likely to continue and evolve, moving to HTTP/3 definitely seems the way of the future.