HTTP/2 Rapid Reset Attack: A Deep Dive |

HTTP/2 Rapid Reset Attack: A Deep Dive

Posted on Oct 11, 2023

HTTP/2, the second major iteration of the HTTP network protocol, was introduced to enhance the performance of websites and web applications by addressing the performance bottlenecks of its predecessor, HTTP/1.1. However, as with any technological advancement, it comes with its own set of vulnerabilities. One such vulnerability that has gained attention is the “Rapid Reset Attack.”

What is the HTTP/2 Rapid Reset Attack?

The Rapid Reset Attack specifically targets the HTTP/2 protocol’s “RST_STREAM” frames. These frames are designed to allow either the client or the server to abruptly terminate a particular stream, ensuring that resources aren’t squandered on redundant streams. However, malicious actors have found a way to misuse this feature by sending a barrage of RST_STREAM frames, leading to the premature termination of legitimate streams.

Unraveling the Attack Mechanism

  1. Initiation:

    • Connection Establishment: The attacker begins by setting up multiple HTTP/2 connections to the target server. This is typically done using botnets or compromised devices to amplify the scale of the attack.
    • Protocol Exploitation: The attacker leverages the inherent features of the HTTP/2 protocol, which allows multiple streams over a single connection, to maximize the potential impact.

  2. Stream Generation:

    • Stream Multiplication: For every established connection, the attacker initiates multiple streams. This is done by sending multiple requests over each connection, effectively multiplying the number of streams the server has to handle.
    • Overwhelming the Server: By creating an excessive number of streams, the attacker aims to stretch the server’s capacity to handle concurrent requests, thereby straining its resources.

  3. Rapid Reset Onslaught:

    • Misuse of RST_STREAM: The RST_STREAM frame in HTTP/2 is designed to allow the termination of a particular stream without closing the entire connection. The attacker abuses this feature by sending a barrage of RST_STREAM frames for each stream.
    • Premature Termination: The attacker doesn’t wait for the server to respond to the initial requests. Instead, they immediately send RST_STREAM frames, causing the server to terminate streams prematurely, even before any meaningful communication can occur.
    • Indefinite Requests in Flight: In the “Rapid Reset” attack, the client opens numerous streams at once but cancels each request immediately, rather than waiting for a response. This method allows each connection to have an indefinite number of requests in flight, limited only by the available network bandwidth.

  4. Resource Depletion:

    • Server Strain: As the server tries to manage the flood of rapid resets, it expends a significant amount of computational resources. This includes CPU cycles, memory allocation, and network bandwidth.
    • Potential System Crash: If the server is not equipped to handle such an onslaught, it may run out of resources, leading to system slowdowns or even crashes.

  5. Attacker’s Endgame:

    • Resource Starvation: The primary goal of the attacker is not just to disrupt the service momentarily but to exhaust the server’s resources to such an extent that it becomes unresponsive.
    • Denial of Service: By depleting the server’s resources, the attacker achieves a Denial of Service (DoS) state, where genuine users are unable to access the server or experience significant delays.

Consequences of the Attack

  1. Denial of Service (DoS): The most immediate consequence is a DoS state where the server either becomes unresponsive or crashes due to resource exhaustion.
  2. Service Deterioration: Even if the server remains operational, its performance can deteriorate, resulting in delayed response times for genuine users.
  3. Resource Overhead: Elevated CPU and memory consumption can lead to increased expenses for cloud-based services.

Counteracting the Rapid Reset Attack

  1. Rate Limiting: Introduce rate limiting for RST_STREAM frames. If a client dispatches these frames too frequently, temporarily restrict or limit their connection.
  2. Vigilant Monitoring: Keep a close watch on server resources and set up alerts for unusual activities, such as an unexpected surge in RST_STREAM frames.
  3. Software Updates: Ensure that the server software and HTTP/2 implementations are current. Some providers might release patches or updates to rectify this vulnerability.
  4. Connection Restrictions: Impose a limit on the number of simultaneous connections or streams from a single client IP.
  5. Leverage Web Application Firewalls (WAFs): Certain WAFs can detect and counteract rapid reset attacks by identifying and blocking malicious patterns.

Additional Insights from Cloudflare

Cloudflare, in collaboration with Google and Amazon AWS, recently disclosed a novel zero-day vulnerability termed the “HTTP/2 Rapid Reset” attack. This attack leverages a flaw in the HTTP/2 protocol to generate massive, hyper-volumetric Distributed Denial of Service (DDoS) attacks. Cloudflare has successfully mitigated several of these attacks in the past months, including one that surpassed any previous attack they’ve encountered, reaching a staggering 201 million requests per second (rps). The attack, named Rapid Reset, exploits the HTTP/2’s stream cancellation feature. By repeatedly sending a request and instantly canceling it, attackers can induce a denial of service, incapacitating any server or application running the standard HTTP/2 implementation. Cloudflare has developed and implemented new technology to counteract these DDoS attacks, enhancing their mitigation capabilities. They have also alerted web server software partners who are in the process of developing patches to prevent the exploitation of this vulnerability. For a more detailed technical breakdown of the attack, you can refer to Cloudflare’s article: HTTP/2 Rapid Reset: deconstructing the record-breaking attack.