Until August 2023, the largest DDoS attack ever recorded sent 46 million requests per second (rps). This attack was mitigated by Google Cloud, which stated that its scale was comparable to receiving all the daily requests to Wikipedia at once. What could top that?
A new vulnerability in HTTP/2 exposed the potential for a DDoS attack that could, in fact, top that. CVE-2023-44487 — a flaw allowing repeated requests and cancellations — was exploited starting August 2023 and reached a peak of 398 million rps.
What’s even more terrifying is that this attack currently does not have a concrete fix! Since it exploits a feature in HTTP/2, the most that can be done is to take preventive measures to mitigate the attacks. Some steps are detailed in Microsoft’s security guide.
What is this vulnerability?
HTTP is a Layer 7 protocol using it to transmit information between networked devices. HTTP/2, its newest version, has a feature that allows clients to cancel requests without requiring any server response. This means that attackers can send requests and cancel them before the server can acknowledge the requests… over and over again. Of course, the result is an overwhelmed server with far too many requests and cancellations coming in, which causes it to crash.
CVE-2023-44487 has a High Severity rating and given a CVSS score of 7.5.
Technical Details
In HTTP/2, some features were added to increase efficiency and reduce the chance of bottlenecks present in HTTP/1.1. One feature is stream multiplexing, which allows many requests to go over multiple streams within a single TCP connection. There is a server-defined limit to the number of concurrent streams that can exist, moderated by the RST-STREAM frame that a server uses to terminate streams that exceed the maximum limit. Clients can also send RST-STREAM frames to cancel a particular request stream.
Servers and clients have a lifecycle. They can either be Idle, Open, Half-Closed or Closed. Here is an image illustrating this lifecycle.
As stated by HTTP, “Streams that are in the “open” state or in either of the “half-closed” states count toward the maximum number of streams that an endpoint has permission to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting.”
While clients in half-closed states can receive anything, they can no longer send HEADERS or DATA but can still send WINDOW_UPDATE, PRIORITY, and RST_STREAM frames. The opposite holds true for servers; they can send anything but can only receive WINDOW_UPDATE, PRIORITY, and RST_STREAM frames.
As seen in the illustration, canceling a request means that the stream quickly passes through all states of the cycle; in other words, it performs a rapid reset. The moment the stream enters a closed state, it no longer counts towards the maximum concurrent streams, which means that the client can instantly open another stream to replace it and perform the same request cancelation procedure again.
Processing client-sent frames and tearing down streams consumes server resources. When attackers carry out the above set of steps at a rate much faster than servers can handle, the servers become incapable of processing any other incoming requests. This culminates in a massive number of 502 errors and the inability of legitimate clients to access the server.
Affected Products
Providing a comprehensive list of products affected by this flaw is almost impossible. If the product uses HTTP/2, it’s probably vulnerable! Check the solutions section for some tips regarding how you can secure your devices.
Impact
The most severe rapid reset attacks impacted 12% of all Cloudflare requests, causing affected clients to receive 502 Bad Gateway errors. As mentioned above, Google Cloud mitigated an attack that reached 398 million rps . According to them, that’s more requests than Wikipedia receives in a month!
Solutions
As stated earlier, this vulnerability has no fix yet. However, there are plenty of steps provided by various advisories that can help mitigate the issue.
Both Google Cloud and Cloudflare responded promptly to the attacks, with Cloudflare implementing a large-scale system known as “IP Jail”. This system identifies machines participating in attacks and stops them from connecting to the victim server. Ideally, legitimate clients sharing the IP should only see a slight performance decrease, but the chance of false positives and the fact that botnets rarely keep IPs signify that this system is not viable in the long term.
Along with the security guide linked in the introduction, Microsoft released a blog detailing actions taken and user recommendations. Some tips include disabling or rate-limiting HTTP/2.
It is important to check vendor sites and advisories for installing products to see which product-specific steps is best. NIST recommends discontinuing the usage of vulnerable products if no mitigations are available.
Many vendors will have released updates that include mitigations for their products. SanerNow Vulnerability Management and SanerNow Patch Management can detect flaws and update your software, saving you the hassle of manually installing updates! Use SanerNow and keep your systems updated and secure.