分析 HTTP/2 分布式拒绝服务漏洞（CVE-2023-44487）

今天又看到了这个CVE-2023-44487 HTTP/2 的分布式拒绝服务 (DDoS) 攻击漏洞，因为的攻击方式是比较有趣的，目前根据微软官方以及一些研究团队以确认攻击详情。

漏洞情况：

此 HTTP/2 漏洞允许恶意行为者发起针对 HTTP/2 服务器的 DDoS 攻击。该攻击使用 HEADERS 发送一定数量的 HTTP 请求，后跟 RST_STREAM，并重复此模式以在目标 HTTP/2 服务器上生成大量流量。通过在单个连接中打包多个 HEADERS 和 RST_STREAM 帧，攻击者可能会导致每秒请求量显着增加，并导致服务器上的 CPU 利用率较高，最终导致资源耗尽。

Nginx产品影响

HTTP/2 流重置的问题

与服务器建立连接后，HTTP/2 协议允许客户端发起并发流进行数据交换。与协议的先前迭代不同，如果最终用户决定离开页面或出于任何其他原因停止数据交换，HTTP/2 提供了一种取消流的方法。它通过向服务器发出 RST_STREAM 帧来实现此目的，从而使其免于执行不必要的工作。

该漏洞是通过在已建立的连接上启动并快速取消大量 HTTP/2 流来利用的，从而绕过服务器的并发流最大值。发生这种情况是因为传入流的重置速度比后续流到达的速度快，从而允许客户端在不达到其配置阈值的情况下使服务器过载。

对 NGINX 的影响

出于性能和资源消耗的原因，NGINX 将并发流的数量限制为默认值 128（请参阅http2_max_concurrent_streams）。此外，为了最佳地平衡网络和服务器性能，NGINX 允许客户端默认使用 HTTP keepalive 保持最多 1000 个请求的 HTTP 连接（请参阅keepalive_requests）。

通过依赖默认的 keepalive 限制，NGINX 可以防止此类攻击。创建额外的连接来规避此限制会通过标准第 4 层监控和警报工具暴露不良行为者。

但是，如果 NGINX 配置的 keepalive 远高于默认和推荐的设置，则攻击可能会耗尽系统资源。当发生流重置时，HTTP/2 协议要求该流上没有后续数据返回到客户端。通常，重置会导致以优雅地处理取消的任务形式出现的服务器开销可以忽略不计。然而，绕过 NGINX 的流阈值使客户端能够利用这种开销，并通过快速启动数千个流来放大它。这会迫使服务器 CPU 达到峰值，从而拒绝向合法客户端提供服务。

针对于Nginx的防护措施

keepalive_requests应保持默认设置 1000 个请求

http2_max_concurrent_streams应保持默认设置 128 个流

HTTP2流量分析

通过上面的一个过程我们可以大概的了解到漏洞的一共过程是由HTTP2的HEADERS 和 RST_STREAM 帧而导致，目前研究团队给出的PCAP，进行一个分析。

通过wireshark的统计-》HTTP2中发现HEADERS 和 RST_STREAM 总数分别为1000和1001

下图根据左边的一个顺序，在15行的数据包中发现异常，在数据包的第6行HypeTexe Transfer Protocol 2和其它包中的TYPE的帧是什么，看下图我们简单了解一下？

在HTTP/2通信中，WINDOW_UPDATE帧和SETTINGS帧都起着重要的作用，但它们的功能不同。以下是它们的作用：

1. WINDOW_UPDATE帧：

作用：WINDOW_UPDATE帧用于调整流控制窗口的大小，以控制数据流的速率。每个HTTP/2流都有一个与之关联的窗口，表示可以发送给对方的数据量。当接收方处理数据时，窗口会逐渐减小。当窗口变得很小或为零时，发送方必须等待窗口变大，以继续发送数据。

使用场景：WINDOW_UPDATE帧通常由接收方发送给发送方，以告知发送方可以继续发送数据。这是流量控制的一部分，可以确保在拥塞或网络条件不佳的情况下不会丢失数据。

2. SETTINGS帧：

作用：SETTINGS帧用于在HTTP/2连接的建立过程中协商连接参数。它允许客户端和服务器之间传输一系列设置项，以协商各种连接参数，如初始窗口大小、是否启用服务器推送、流的最大数目等。

使用场景：SETTINGS帧通常在连接的初始阶段发送，以确保客户端和服务器之间的通信参数一致。这有助于优化连接的性能和可靠性。

WINDOW_UPDATE帧用于控制数据流的速率，而SETTINGS帧用于协商连接参数。这两种帧在HTTP/2协议中都扮演着重要的角色，以确保有效和可靠的数据传输。

当了解最开始数据包的帧那么重戏开始了，最基本协议WINDOW_UPDATE帧和SETTINGS帧，就轮到本文内容的重点漏洞帧Type: HEADERS (1)在数据包 15 中，客户端发送一些控制帧，然后开始发出快速重置的请求。第一个 HEADERS 帧长 26 个字节

所有后续的 HEADERS 只有 9 个字节。

这种大小差异是由于称为HPACK的压缩技术造成的。数据包 15 总共包含 525 个请求，直至流 1051。

看上图有趣的是，流 1051 的 RST_STREAM 不适合数据包 15，因此在数据包 16 中我们看到服务器以 404 响应进行响应。然后，在数据包 17 中，客户端发送 RST_STREAM，然后继续发送剩余的 三百多 个请求。

请注意，虽然服务器通告了 100 个并发流，但客户端发送的两个数据包发送的 HEADERS 帧比这多得多。客户端不必等待服务器的任何返回流量，它仅受其可以发送的数据包大小的限制。在此跟踪中没有看到服务器 RST_STREAM 帧，这表明服务器没有观察到并发流违规。

结束语：

涉及到服务器和客户端之间的并发流控制，以及对可能出现的 RST_STREAM 帧的观察。我将逐句分析它：

1. "虽然服务器通告了 100 个并发流，但客户端发送的两个数据包发送的 HEADERS 帧比这多得多。" 

   - 这句话表明服务器通告了它支持 100 个并发流（可能是HTTP/2或类似的协议），但客户端在发送了两个数据包的情况下，发送了更多的HEADERS帧。这意味着客户端在某个时刻似乎试图建立超过 100 个并发流。

2. "客户端不必等待服务器的任何返回流量，它仅受其可以发送的数据包大小的限制。"

   - 这意味着客户端不必等待服务器的响应来发送更多的数据包。它只受到它可以同时发送的数据包数量的限制，这可能是受到了某些并发流的限制。

3. "在此跟踪中没有看到服务器 RST_STREAM 帧，这表明服务器没有观察到并发流违规。"

   - 这是指在你所查看的网络跟踪中，没有看到服务器发送RST_STREAM帧，这表明服务器可能没有检测到并发流超过其承受范围的情况。RST_STREAM 帧通常用于重置某个流，以终止它。

然而客户端似乎试图建立更多的并发流，超过了服务器所通告的数量，但服务器没有采取行动（发送RST_STREAM帧）来终止这些额外的流。这可能是因为服务器允许更多的并发流，或者因为某些原因没有观察到这种违规行为。