The HTTP/2 Fast Reset Attack Vulnerability: What You Need To Know

nA resource consumption attack vector related to sites that use thenHTTP/2 protocol. The impact of leveraging the vulnerability is a denial of service (DoS) resulting from the consumptionnof system resources when dealing with a large volume of HTTP/2 resetnmessages.

The vulnerability is widespread as the core method (Reset) is a part of thenHTTP/2 protocol and many systems implement the handling of resetnrequests in a way that may be vulnerable to triggering consuming servernresources faster than they can be released when dealing with a massnof requests. Ultimately, exploiting the vulnerability results in the failure/off-lining ofnthe server.

At the core of the issue is that HTTP/2 allows multiplexing of multiple requests fromna single client (an endpoint). An attacker establishes a HTTP/2 connectionnand immediately issues a ‘Reset’ message to clear the connection. While this costs the client very little in terms of effort and resource, typically on the server side this will consume resources whilst thenconnection is ‘tidied up’ and released.

If a large number of these ‘connection then Reset’ requests are received the net affect on the server side is one of creating a backlog of clearing processes that consume resources, causing resource depletion and a probable DoS-like failure of the service.

How may it affect me?

n

The effect of this will manifest in the following ways:

n
• Unusual amounts of traffic to a single web service
n
• Sporadic error messages being returned to clients
n
• Slow running of services
n
• Ultimately a DoS of one or more targeted vulnerable systemsn (those that accept and process HTTP/2)
n
• If you have a firewall/content delivery network (CDN) that traps traffic, you may seen a spike or abnormally large amounts of dropped traffic as a result of attempts to exploit this vulnerability.
n

n

What should I do about it?

n

nProfile where you may be vulnerable:

n
• Inventory all systems and services that use HTTP/2, especially those that can ben reached via the internet
n
• For systems that do and are critical to operation, consult then vendor and see if they have recommendations on mitigations, or available patches
n

Harden where possible:

n
• Some CDNs and firewall productsn now have mitigations in place – see if you are covered by one ofn those
n
• If you can configure the HTTP protocol type, do so and look ton restrict to HTTP/1.1 (There may be performance implications related to restricting to HTTP/1.1) or HTTP/3 as these are not known to be vulnerable
n

Monitor:

n
• Be vigilant on network traffic and look for spikes in HTTP/2n traffic that may indicate an attack
n
• Monitor services for degradation/slow response as this mayn indicate an attack
n
• Monitor for unusually high numbers of HTTP error states (499n ‘Client Closed request’ or 502 ‘Bad gateway’)
n

Finally, regularly check with vendors and monitor their advice and available software updates.

n

Where can I find out more?

n

nThe CVE and related information can be found at https://www.cve.org/CVERecord?id=CVE-2023-44487.

For additional training and professional development support in dealing with DoS and vulnerability exploits, take a look at our Skill Builder courses for Network Security and Security Operations: https://www.isc2.org/professional-development/skill-builders.