单包攻击：让远程竞态条件变得"本地化"

James Kettle
研究总监
@albinowax

发布时间： 2023年10月18日 12:54 UTC
更新时间： 2023年10月18日 12:59 UTC

单包攻击是一种触发Web竞态条件的新技术。它通过使用单个TCP包完成多个HTTP/2请求来工作，这有效消除了网络抖动，意味着请求会被极其接近地处理。这使得远程竞态条件的利用变得与本地一样简单。

过去两个月看到社区使用单包攻击在发现竞态条件方面取得很大成功，这很棒。有人甚至用它攻击了我自己制作的网站。不少人询问它可能适用于哪些其他网络协议，因此在这篇文章中，我将探讨包括HTTP/3、HTTP/1.1、WebSocket和SMTP在内的协议。在不可行的地方，我会看看最佳替代方案是什么。我还将提供将其适配到您选择的协议的指南。

单包攻击回顾

我在《粉碎状态机：Web竞态条件的真正潜力》中介绍了单包攻击。如果您已经熟悉它，可以跳过本节。

为什么抖动会隐藏竞态条件

要触发竞态条件，通常需要网站在一个非常小的时间窗口内接收和处理多个HTTP请求。由于网络抖动（数据包传输中不可预测的网络引起延迟），同时发送到远程系统的请求并不能可靠地同时到达：

这使得在远程系统上检测竞态条件比在本地系统上困难得多。

用单包攻击解决抖动问题

单包攻击通过调整和结合"最后字节同步"和"无时间定时攻击"技术来解决网络抖动：

• 通过单个HTTP/2连接发出所有请求，保留每个请求的一小片段，这样服务器就不会开始处理它
• 等待短暂时间让数据包到达目标服务器
• 发出每个请求的最终片段
• 您的操作系统会将这些分组到单个TCP包中

您可以将结果可视化如下：

使用单个TCP包完成所有请求意味着它们总是在同一时间被处理，无论网络抖动延迟了它们的传递多少。这种方法可以轻松扩展到20-30个请求，并且实现起来非常容易。它通过标签组功能在Burp Suite的Repeater中可用，也在我的开源扩展Turbo Intruder中可用。

如果您想自己尝试这种技术，请尝试我们的免费竞态条件实验。

有关该技术开发和实现的更多细节以及一些基准测试，请查看原始白皮书或此演示片段。

将单包攻击应用于其他协议

鉴于单包攻击的强大功能，很自然地想知道它是否可以适配到其他网络协议，也许可以实现HTTP/3登录限制溢出、WebSocket竞态条件或SMTP定时攻击。让我们来看看。

HTTP/3

首先，让我们看看HTTP/3。HTTP/2和HTTP/3之间的主要区别是HTTP/2建立在TLS和TCP之上，而HTTP/3建立在QUIC和UDP之上。

要通过HTTP/3应用单包攻击，我们需要用单个UDP数据报完成多个HTTP请求。HTTP/3对多路复用的支持意味着这绝对是可能的，但有一个限制。UDP的最大数据包大小约为1,500字节，而TCP为65,535字节。这可能使HTTP/3听起来对单包攻击很糟糕，但实际上，TCP也有1,500字节的软限制，我从未探索如何突破这一点，因为20-30个请求对大多数竞态条件来说已经足够了。

最终，HTTP/3确实支持单包攻击，但现在可能不值得开发努力。如果您想推动HTTP上竞态条件利用的技术水平，您可能最好尝试改进HTTP/2实现以更接近TCP的最大数据包大小。这可以同时完成大约800个请求，这将相当有趣。

HTTP/1.1

HTTP/1.1允许您通过单个TCP连接发送多个请求，并且由于许多服务器上的TCP缓冲，您不需要等待响应就可以发送下一条消息。在不等待回复的情况下将多个请求塞入连接被称为流水线，这是使Turbo Intruder如此快的关键功能。使用流水线，技术上可以将多个完整的HTTP请求塞入单个TCP包中。

不幸的是，RFC规定服务器必须按照接收请求的顺序发送响应。这意味着尽管HTTP服务器技术上可以同时处理多个流水线请求，但它不会给服务器带来太多速度提升，因为对第一个请求的响应最终会阻塞对第二个请求的响应。这有时被称为"队头阻塞"问题。

由于这个问题，我认为您会发现尽管许多Web服务器支持流水线请求，但它们会按顺序处理，如果您想进行竞态条件攻击，最好使用带有最后字节同步的并行连接。Burp Repeater会自动为HTTP/1.1连接执行此操作。

SMTP

就像HTTP/1.1一样，您可以使用RFC 2920中定义的流水线扩展将多个SMTP消息塞入单个包中。不幸的是，响应必须按顺序发送，因此任何实现都不太可能并行处理这些请求。

这很遗憾，因为我期望在SMTP处理程序后面隐藏着一些有趣的竞态条件。

WebSocket

WebSocket协议比HTTP/1.1更有前途，因为没有"响应"的概念。这意味着服务器可以并发处理通过单个连接发送的多个消息，而不必担心发送任何结果消息的顺序。当然，一些实现可能仍然选择不这样做，以避免复杂性。

与HTTP/2不同，您不能滥用分片来增加可以用关键数据包完成的消息数量。这是因为虽然允许对消息进行分片，但不能同时有多个分片消息在传输中：

一个消息的片段不能与另一个消息的片段交错 RFC6455

好消息是，RFC 8441 - 使用HTTP/2引导WebSocket中有一个解决方案。这提议将WebSocket连接嵌套在HTTP/2流中，并将在支持它的服务器上启用全功率单包攻击。

我认为WebSocket竞态条件由于针对这个小众领域的工具很少而被广泛忽视，因此即使没有单包攻击，该领域也有很大潜力。

其他协议？

启用单包攻击的关键特性是多路复用 - 支持单个连接上的多个并发消息。许多协议支持单个包中的多个顺序消息，有时是无意的，但它们通常因服务器实现选择而失败。

支持交错片段是一个关键的性能因素，因为它增加了可以挤入一个包的消息数量。另一个主要性能因素是底层协议的最大数据包大小。

不同层的合并

将最终请求片段合并到单个TCP包中并不是唯一可行的选项。您也可以将最终片段放在单个TLS记录中。由于TLS分层在TCP之上，即使记录通过多个不同的TCP包传递，这也会工作。

我相信这将使攻击能够可靠地通过非解密隧道（如SOCKS代理）工作。但是，它可能需要定制的TLS实现，因此最终比经典的TCP方法更难实现。

结论

现在，有一堆在HTTP/2网站上的Web竞态条件，这些条件以前几乎无法检测和利用，现在已经成熟可供利用。我们使用基于RFC的分析评估了哪些其他协议可能支持单包攻击的变体。任何这些的下一步都是创建一个概念验证工具，然后对一些流行的服务器实现进行探测，看看它们是否兼容。一如既往，如果没有概念验证，就没有真正证明！

新工具可能会暴露更多影响WebSocket的漏洞，也许还有一些需要超过30个同时请求才能检测的基于HTTP的漏洞。如果您错过了，您可能还喜欢为Web安全自动化构建自定义扫描器。