HTTP/2 Rapid Reset DDoS Attack

http2-rapid-reset-ddos-attack.md

Introduction

This Gist aims to centralise the most relevant public sources of information related to the HTTP/2 Rapid Reset vulnerability. This vulnerability has been disclosed jointly by Google, Amazon AWS, and Cloudflare on 10 October 2023 at 12:00 UTC.

Please help us make this page as comprehensive as possible by contributing relevant references, vendor advisories and statements, mitigations, etc.

References

• CVE-2023-44487, CIRCL CVE Search
• How AWS protects customers from DDoS events, AWS
• How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack, Google
• HTTP/2 Rapid Reset: deconstructing the record-breaking attack, Cloudflare
• Microsoft Response to Distributed Denial of Service (DDoS) Attacks against HTTP/2, Microsoft
• Potential mention of a similar issue in 2018 concerning HAproxy
• RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
• Security Advisory 2023-074 HTTP/2 Rapid Reset DDoS Vulnerability, CERT-EU
• HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487, CISA
• Using HTTP/3 Stream Limits in HTTP/2 - IETF draft to backport the HTTP/3 steam limits in HTTP/2

Vendor advisories and statements

• Apache Tomcat - Fixed in 8.5.94
• AWS
• F5
• Golang
• HAPROXY - HAProxy is not affected by the HTTP/2 Rapid Reset Attack
• Kong
• Microsoft IIS
• Microsoft MsQuic - Fixed in 2.2.3
• Netscaler
• Nginx
• nghttp2 library - Fixed in 1.57.0

Testing if HTTP/2 is enabled

OpenSSL

echo 1 | openssl s_client -alpn h2 -connect google.com:443 -status 2>&1  | grep "ALPN"

Nmap

nmap -p 443 --script=tls-nextprotoneg www.google.com

curl

curl -Is --http2-prior-knowledge https://example.com/| head -1

Testing if it's vulnerable (use at your own risk)

• Basic vulnerability scanning tool to see if web servers may be vulnerable to CVE-2023-44487
• Rapid Reset Client is a tool for testing mitigations and exposure to CVE-2023-44487 (Rapid Reset DDoS attack vector)

Potential remediation

NGINX

can be configured to mitigate the vulnerability

• Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

  • keepalive_requests should be kept at the default setting of 1000 requests
  • http2_max_concurrent_streams should be kept at the default setting of 128 streams
  • limit_conn and limit_req should be set "with a reasonable setting balancing application performance and security"

If you want to remove http2 support

• Remove reference to http2 in the listening part

DDoS protection / CDNs

Web apps that are behind the following DDoS protection providers / CDNs should not be impacted:

• AWS
• Cloudflare
• Google Cloud
• Microsoft Azure

Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

• keepalive_requests should be kept at the default setting of 1000 requests
• http2_max_concurrent_streams should be kept at the default setting of 128 streams

Full details in the blog:
https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

@lcrilly Thank you for the updates!

You can prevent the openssl command from hanging by echoing input. Can also remove stderr output by redirecting stderr to stdout.

echo 1 | openssl s_client -alpn h2 -connect google.com:443 -status 2>&1 | grep "ALPN"

@rwhitworth Thanks a lot. It’s updated.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-44487 - For IIS

@adulau for your consideration. I reworked the MD, adding a source, some mitigations, and additional text for clarity etc.

Introduction

This Gist aims to centralise the most relevant public sources of information related to the HTTP/2 Rapid Reset vulnerability. This vulnerability has been disclosed jointly by Google, Amazon AWS, and Cloudflare on 10 October 2023 at 12:00 UTC.

Please help us make this page as comprehensive as possible by contributing relevant references, vendor advisories and statements, mitigations, etc.

References

• CVE-2023-44487, CIRCL CVE Search
• How AWS protects customers from DDoS events, AWS
• How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack, Google
• HTTP/2 Rapid Reset: deconstructing the record-breaking attack, Cloudflare
• Microsoft Response to Distributed Denial of Service (DDoS) Attacks against HTTP/2, Microsoft
• Potential mention of a similar issue in 2018 concerning HAproxy
• RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
• Security Advisory 2023-074 HTTP/2 Rapid Reset DDoS Vulnerability, CERT-EU

Vendor advisories and statements

• Apache Tomcat - Fixed in 8.5.94
• AWS
• F5
• Nginx

Testing if HTTP/2 is enabled

OpenSSL

echo 1 | openssl s_client -alpn h2 -connect google.com:443 -status 2>&1  | grep "ALPN"

Nmap

nmap -p 443 --script=tls-nextprotoneg www.google.com

Testing if it's vulnerable (use at your own risk)

• Basic vulnerability scanning tool to see if web servers may be vulnerable to CVE-2023-44487

Potential remediation

NGINX

can be configured to mitigate the vulnerability

• Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

  • keepalive_requests should be kept at the default setting of 1000 requests
  • http2_max_concurrent_streams should be kept at the default setting of 128 streams

If you want to remove http2 support

• Remove reference to http2 in the listening part

DDoS protection / CDNs

Web apps that are behind the following DDoS protection providers / CDNs should not be impacted:

• AWS
• Cloudflare
• Google Cloud
• Microsoft Azure

@cert-olivier Thank you it's updated.
@saadkadhi Thank a zillion for the clean-up and the improvement. It's now included.

CISA advisory: https://www.cisa.gov/news-events/alerts/2023/10/10/http2-rapid-reset-vulnerability-cve-2023-44487

Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

* keepalive_requests should be kept at the default setting of 1000 requests
* http2_max_concurrent_streams should be kept at the default setting of 128 streams

Full details in the blog: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

The blog also says that, in addition of keeping those at its default values, you should add limit_conn and limit_req "with a reasonable setting balancing application performance and security"

@INCIBE-CERT Thanks a lot for the feedback. It's updated.

Anyone able to provide any PCAP's? We could design some suricata rules to detect and prevent the attacks

There's draft proposal (from Mozilla engineer) for backporting QUIC (HTTP/3) stream id limits to HTTP/2
https://martinthomson.github.io/h2-stream-limits/draft-thomson-httpbis-h2-stream-limits.html

@marcin-gryszkalis Thanks for the info. It's updated.
@ion-storm There is a pcap from Cloudflare. Suricata rule would be indeed a good idea. Suricata seems to support HTTP/2 framing (not sure if it's complete) - https://docs.suricata.io/en/suricata-6.0.0/rules/http2-keywords.html

Netscaler has a blog post available:
https://www.netscaler.com/blog/news/how-to-mitigate-the-http-2-rapid-reset-vulnerability-on-netscaler/

NGINX mitigation: please note the nginx.com blog has been updated to separate essential configuration from recommended.

Testing if HTTP/2 is enabled with curl(1)

curl -Is --http2-prior-knowledge https://example.com/| head -1

@lcrilly Thank you. it’s updated.

@ravager-dk Thank you it’s updated.

I wrote a tool that implements a sparse HTTP/2 client and emulates this attack. It can be used to test system behavior to rapid HEADERS + RST_STREAM frames.

@secengjeff Thank you. It's included.

Kong has a blog post too:

https://konghq.com/blog/product-releases/novel-http2-rapid-reset-ddos-vulnerability-update

@crstian19 Thank you it's updated.

Apache Tomcat apache/tomcat@9cdfe25 was backported to the released 11.1.14. However, this version had a regression. So, it is better to use 11.1.15

Hello, besides this information is there any public datasets related to this attacks? Im currently doing research about the topic and would be very useful to check traffic generated by this kind of attack. Thank you in advance.

Thanks you for docs. it's lightspeed rapid reset blog.
https://blog.litespeedtech.com/2023/10/11/rapid-reset-http-2-vulnerablilty/