Google has recorded the largest DDoS attack on its infrastructure, with an intensity of 398 million requests per second. The new attack surpasses the previous record DDoS attack by seven times in intensity, where the attackers managed to generate a flow of 47 million requests per second. For comparison, the total web traffic is estimated to be between 1-3 billion requests per second. In addition to Google, companies such as Amazon and Cloudflare also faced the attack. The possibility of this new attack is associated with the discovery of a vulnerability in the HTTP/2 protocol (CVE-2023-44487), which allows a massive stream of requests to be directed at the server with minimal client load.
The new attack technique has been named 'Rapid Reset' and takes advantage of the multiplexing capabilities provided by HTTP/2, allowing a stream of requests to be formed within an already established connection without opening new network connections and without waiting for confirmation of packet receipt. The vulnerability is considered a consequence of the shortcomings in the HTTP/2 protocol, in which the specification states that when attempting to open too many streams, only those exceeding the limit should be canceled, rather than closing the entire network connection.
Similar to previously used methods for attacking HTTP/2, the new attack also creates a large number of streams within a single connection. The key difference in the new attack is that instead of waiting for a response after each sent request, a frame with the RST_STREAM flag is sent immediately after each request, canceling it right away. Cancelling the request at an early stage allows for the elimination of return traffic to the client and bypasses the limitations present on HTTP servers regarding the maximum number of streams that can be opened simultaneously within a single HTTP/2 connection. Thus, in the new attack, the volume of requests sent to the HTTP server ceases to depend on the delays between sending a request and receiving a response (RTT, round-trip time) and is solely limited by the bandwidth of the communication channel.
Since launching an attack from the client side requires simply sending requests without receiving responses, the attack can be executed with minimal overhead. For instance, the attack recorded by Cloudflare at 201 million requests per second was carried out using a relatively small botnet of 20,000 computers. On the client side, server the costs of processing incoming requests are significantly higher, despite their cancellation, as operations such as allocating data structures for new streams, parsing the request, unpacking the header, and matching the URL to the resource need to be performed. When attacking reverse proxies, the attack can spread to the backends, as the proxy may successfully forward the request to the backend before processing the RST_STREAM frame.
An attack can only be executed against vulnerable servers supporting HTTP/2 (a script to check for vulnerability manifestation in servers, a toolkit for conducting attacks). No attacks have been recorded for HTTP/3 so far, and the possibility of their execution has not been fully analyzed, but representatives from Google recommend developers servers to include protective measures in HTTP/3 implementations similar to those implemented to block attacks on HTTP/2.
Vulnerability susceptibility and the availability of patches for HTTP servers and proxies:
- nginx (announcement, clarification that the vulnerability does not fully manifest in nginx in the default configuration, as the attack will hit the limit on the number of requests per connection (i.e., after every 1000 requests, the connection will be reset). The fix includes additional protection by limiting the intensity of requests through the 'limit_req' directive).
- In HAProxy, effective protection against exceeding the limit on the number of HTTP/2 streams was added as early as 2018 and has been in effect since version 1.9-dev.
- Apache httpd (a certain load is created on httpd, but it does not spread to the backends and is limited by the client connection limits in place since 2016).
- mod_h2 for Apache httpd.
- caddy
- envoy
- golang (the issue was fixed in releases Go 1.21.3 and 1.20.10).
- h2o (patch).
- grpc-go
- hyper (vulnerability does not manifest).
- jetty (fixed in 12.0.2, 11.0.17, 10.0.17, and 9.4.53.v20231009).
- netty
- nghttp2 (fixed in version 1.57.0).
- Facebook proxygen
- .NET and ASP.NET Core (the vulnerabilities affect the ASP.NET Core Kestrel HTTP server).
- Node.js
- proxygen
- swift-nio-http2 (fixed in version 1.28.0).
- Apache Tomcat (fixed in versions 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (fixed in the 9.2.x branch).
Source: opennet.ru
