AC
AC
3 min read

HTTP/2 Rapid Reset Attack Deepdive

Understanding the HTTP/2 'Rapid Reset' DDoS Attack and Its Mitigations

The Distributed Denial of Service (DDoS) attack vectors are ever-changing. The recent spike in HTTP/2-based DDoS attacks has been notable for its sheer volume, with some attacks surpassing a staggering 398 million requests per second. Peakhour observed the devastating nature of these attacks and took steps to understand and mitigate them. Here's an in-depth look at the nature of these attacks and how to defend against them.

1. The Rise of HTTP/2 in DDoS Attacks

HTTP/2 was designed to make web traffic more efficient. However, the same features that boost its performance for legitimate users also enhance its potential as a DDoS weapon.

The heart of HTTP/2's efficiency lies in "stream multiplexing." It allows multiple messages to be sent over a single TCP connection. While HTTP/1.1 processes each request serially, HTTP/2 can manage multiple concurrent streams on a single connection. This means a client can send multiple requests in a single round trip, greatly increasing the efficiency of each connection.

2. The 'Rapid Reset' Attack Explained

The "Rapid Reset" attack is a particular breed of DDoS attack tailored for HTTP/2. The attacker starts by opening multiple streams, much like in a standard HTTP/2 attack. However, instead of waiting for responses, they cancel each request immediately.

This is achieved by the client sending a RST_STREAM frame, indicating that a previous stream should be cancelled. The rapid sequence of request-and-reset means the server invests resources processing the request, only for it to be cancelled before a response is generated. This tactic amplifies the server's workload without needing to wait for responses, thus exacerbating the attack's potency.

3. Variants of the Rapid Reset Attack

Attackers soon began experimenting with variations of the Rapid Reset attack:

  • One variant involves delaying the reset action. The attacker opens multiple streams, waits, then cancels the streams and instantly opens new ones. This method can evade some rate-based defences.

  • Another variant eschews stream cancellations. Instead, the attacker tries to open more streams than the server allows. This aims to keep the server continually busy, processing a near-constant influx of requests.

4. Effective Mitigation Techniques

The solution isn't as simple as blocking individual malicious requests. A more effective approach is to close the entire TCP connection when malicious activity is detected. The HTTP/2 protocol supports connection termination through the GOAWAY frame. Still, it's crucial that this feature be used aggressively to prevent Rapid Reset attacks, rather than relying on the more passive, standard implementation.

Deciding which connections to treat as malicious is a challenge. One potential strategy is to monitor connection statistics. If a connection exceeds a set threshold of cancelled requests, it might be deemed malicious. Reponses to suspect activity could range from sending a GOAWAY frame to terminating the TCP connection.

For the non-cancelling variant, the best approach is to shut down connections that breach the concurrent stream limit, either immediately or after a few violations.

5. Broader Protocol Implications

Though these attack techniques are specific to HTTP/2, it's worth noting the wider implications. The HTTP/3 (QUIC) protocol isn't directly vulnerable in the same way. However, as a precaution, server implementations should consider limiting the work done by a single connection.

6. The Importance of Industry Collaboration

When the threat of the Rapid Reset attack became apparent, the industry collaborated to address the issue. They disclosed the vulnerability to key HTTP/2 implementers, helping to devise and distribute effective countermeasures. The vulnerability is logged against CVE-2023-44487

The novel HTTP/2 'Rapid Reset' DDoS attacks pose a significant threat to any service utilising the protocol. To safeguard against these attacks, service providers should promptly apply available software patches and updates.

© PEAKHOUR.IO PTY LTD 2024   ABN 76 619 930 826    All rights reserved.