𠓗 fù，疾也，从三兔。
在过去的兔年，我们将“最𠓗漏洞”的名号颁予HTTP2 Rapid Reset漏洞，其对新版协议缺陷的巧妙利用再次生动展现了漏洞利用中速度与激情的主旋律。
国外头部厂商的抱团和修复速度更堪比疯狂动物城中的兔警官朱迪，相比之下其他懵圈的受影响机构却没有及时收到通报，像闪电树懒一样成了慢动作背景版。
然而，这真的有利于整个生态么？
动物城中众物平等，漏洞面前似乎也应如此。
以下为本期深蓝洞察年度安全报告的第二篇。
02
2023年10月10日，一个关于 HTTP/2 协议的漏洞被公开 — CVE-2023-44487 (HTTP/2 Rapid Reset Attack）。
这个 CVE 的描述非常简洁：
HTTP/2 的请求取消功能可以快速重置大量的流（stream），利用此功能可以导致大量的服务端资源消耗进而造成拒绝服务，在 2023 年 8 月到 10 月期间已经有在野利用。
虽然 CVE 的信息只有寥寥几字，但是当天 Google、Cloudflare、Azure、AWS 等知名厂商都发布了关于此漏洞的博客或公告。
其中部分文章以大量篇幅给出了详细的漏洞原理，讲述了从流的重置到拒绝服务是如何发生的，并给出了修复建议。
这部分知名厂商的安全团队，其响应速度和协作速度为何能如此之快？
让我们先把时间线拉回到去年夏天。
2023 年 8 月，Google、Cloudflare、AWS 等都开始观测到异常的 HTTP/2 流量：
Google 报道峰值超过每秒 3.8 亿个请求，显著高于之前规模最大的攻击（每秒 4600 万个请求）；
Cloudflare 则报道峰值超过每秒 2 亿个请求，大约是历史规模最大的攻击的三倍之多；
AWS 公布的数据也显示峰值达到了每秒 1.55 亿个。
如此强大的攻击效果令人震惊。
经过分析，那些达到历史新高的异常峰值背后成因正是 HTTP/2 Rapid Reset Attack。这是一种全新的攻击方法，与历史攻击相比，该方法可以使用同样的资源产生更大规模的攻击后果。
让我们看一下，这种攻击是如何发生的：
在 HTTP/2 RFC 中，有一个 stream multiplexing 的功能定义，可以实现在单个 TCP 连接中包含多个并发的流，每个流可以理解成单独的 HTTP 请求和响应。
HTTP/2 RFC中，还规定了流的生命周期（见上图）和五种状态：idle、reserved、open、half-closed、closed。
通常情况下，一个流的状态会按照上图中的蓝色箭头流转，对应的客户端和服务端视角如下图所示：
Stream multiplexing 设计的初衷，是为了减少连接数、提高传输效率，且避免了 HTTP/1.1 的阻塞问题，降低延迟。
这种特性使 HTTP/2 天然地拥有更好的性能。
因此，与基于 HTTP/1.1 的 DDoS 攻击相比，基于 HTTP/2 的 DDoS 攻击能实现更多的 RPS (Request Per Second)。
那么客户端是不是可以在一个连接中无限制地发送大量请求呢？
答案是否定的。
为了不被滥用，HTTP/2 在设计上有一些防御机制，例如可以限制最大并发流数量：
然而，HTTP/2 RFC 中明确说明：
只有 open 和 half-closed 状态的流才会参与这个“最大并发流数量限制”的计数。
正常客户端行为所打开的流在服务端接收请求到发送响应的过程中都是 open 或 half-closed 状态，都会被计入并发流数量。
此外，“流的生命周期示意图”中还有一个红色箭头，表示流可以从 open 状态通过 RST_STREAM 直接流转到 closed 状态。
深蓝
利用这一规则，恶意客户端可以在发送完请求之后直接发送 RST_STREAM ，服务端处理过程中此请求对应的流从 idle 状态经历了一个极短暂的 open 状态后就变成了 closed 状态，从而并发流数量只在一个极短暂的时间内增加 1 又减少 1。
因此恶意客户端不需要等待服务端响应就可以继续发送新的请求，且不会受最大并发流数量的限制，从而实现比普通的 HTTP/2 DDoS 更高的 RPS。这在理想条件下相当于单个连接就可以无限制地快速发送大量请求去把服务端填满。
如果服务端正好无法优雅地处理 RST_STREAM，例如收到 RST_STREAM 后仍需要消耗资源去处理这个已经没有意义的请求，那就会出现资源的过度消耗。
这种新型攻击方法利用了 HTTP/2 协议本身的缺陷，假如服务端完全按照 HTTP/2 标准实现，没有添加额外的防御机制，就会存在被攻击的可能。
在 2023 年 8 月之后到漏洞公开之前，据信一个事先就存在的漏洞披露小组发挥了作用。
Google、Microsoft、Cloudflare 和 AWS 等都在其中，共同参与了向受影响的厂商披露攻击事件的协调工作。
因此在 10 月 10 日这一天，这个漏洞披露小组的成员和被通知的厂商应该都已经完成了漏洞的修复，做好了充足的准备。
那么在 CVE 公开之前，所有和 HTTP/2 有关的软件厂商都已经知情了吗？
显然不是。
LiteSpeed，一个 w3techs.com 网站上显示当时占有率排名第四的 web server，在 10 月 10 日漏洞公开之前毫不知情。
他们在博客中表示对此感到沮丧，并希望能提前收到关于漏洞消息的通知。
连当时占有率第四的 web server 都没收到提前通知，这让人不禁疑惑：
这个漏洞披露小组有哪些成员？
是谁最先确定这个大规模 DDoS 攻击背后的成因？
漏洞披露前有无国内厂商也遭受到了攻击？
漏洞披露的规则和协调过程是怎样的？
哪些厂商得到了提前通知？是否有国内厂商？
很遗憾，这些问题的答案从公开渠道都无从知晓。
在当今复杂的网络环境中，网络安全挑战日益严峻。某些漏洞关系到重要的基础设施，如反向代理和负载均衡服务，这对云服务厂商而言尤其致命。
为了确保服务的可用性和稳定性，在修复漏洞前，充分准备至关重要。如果预警不足，就很可能措手不及。
然而，信息孤岛现象增加了处理危机的难度。
正如我们在《深蓝洞察 | 2023 年度最野的漏洞》中所说，建立负责任和高效的威胁情报共享机制已经迫在眉睫。
参 考：
[3] https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack
[4] https://datatracker.ietf.org/doc/html/rfc9113
[5] https://blog.litespeedtech.com/2023/10/11/rapid-reset-http-2-vulnerablilty/
明日，请继续关注**《深蓝洞察 | 2023 年度安全报告》**第三篇。
