倾听低语：实际有效的Web时序攻击

网站充满了时序预言机，渴望泄露其最内部的秘密。是时候开始倾听它们了。在本文中，我将释放新颖的攻击概念，以诱出服务器秘密，包括掩蔽的配置错误、盲目的数据结构注入、通往禁区的隐藏路由，以及广阔的无形攻击面。

这不是理论威胁；每种技术都将通过多个真实案例研究在不同目标上进行说明。前所未有的进步使这些攻击既准确又高效；在十秒内，您现在可以可靠地检测到亚毫秒级的差异，无需事先配置或“实验室条件”。换句话说，我将分享您可以实际使用的时序攻击。

为了帮助您，我将为您配备一套经过实战测试的开源工具，支持免提自动利用和自定义攻击脚本。我还将分享一个小型CTF，以帮助您磨练新技能。

想更进一步？我将通过分享在数千个网站上测试无数概念后提炼的方法论，帮助您将自己的攻击想法从理论转化为现实。我们忽视这种无处不在且极其强大的侧信道太久了。

本研究论文伴随Black Hat USA和DEF CON的演讲。

背景

Web时序攻击因两件事而臭名昭著：做出大承诺和未能兑现。例子通常是理论性的，即使某种技术被称为“实用”，每个人都知道一旦尝试在实验室环境之外应用它，它就会停止工作。

这种声誉可能是我们忽略了一个巨大机会的原因。

我首次研究时序攻击的结果 firmly 属于“理论”桶。对于我的第二次尝试，我开始回顾我成功在野外应用的攻击，以及我读到的其他攻击：

从顶部开始，这些是以下示例：

• 跨站搜索
• 用户名枚举
• 潜在竞争条件的探测
• 实验室证明的攻击
• 理论攻击，如果实际有效，将绝对惊人…

在寻找在野外有效的新技术时，我专注于两个类别之间的巨大鸿沟：

时序攻击研究通常专注于单个目标，但这限制了其真实世界价值。我想要可以应用于任意实时目标的技术。为了确保我的新攻击概念符合这一标准，我在一个包含30,000个实时网站的测试平台上进行了验证。基于bbscope和Rapid7的Project Sonar DNS数据库，测试平台是一个20 GB的Burp Suite项目文件，包含每个已知有漏洞赏金计划的网站。

在这项研究之前，我个人利用的最小时间间隙是30,000μs。现在，是200μs。这是通过时序攻击准确性的大幅进步实现的，并实现了多个强大的新技术。

三种关键攻击技术脱颖而出，在多种实时系统上提供了有价值的发现：发现隐藏的攻击面、服务器端注入漏洞和配置错误的反向代理。在本文中，我将深入探讨每一种。

使时序攻击在任何地方都有效

所有三种技术现在都在Param Miner中可用，所以，如果您愿意，可以停止阅读并立即尝试。这项研究的真正价值在于理解它不止于此；这些只是可能性的样本。时序攻击几乎可以带您去任何地方，但为了把握这种潜力，我们需要从头开始。

让我们仔细看看现实世界时序攻击成败的关键因素，以及如何克服它们。在本节中，我将展示如何使时序攻击“本地化”、可移植和可行。

回答困难问题

很容易假设所有Web时序攻击都是利用，但这是一个错误，因为它限制了您对潜在应用的思考。在其核心，Web时序攻击仅仅是关于回答困难问题——那些无法通过观察服务器响应来回答的问题。

我通过尝试基于时序的密码重置利用开始了这项研究。它进行得很糟糕，但很好地说明了理论与现实之间的差距。许多网站通过在其数据库中存储秘密令牌并在链接中发送令牌到用户的注册电子邮件地址来实现密码重置。当用户点击链接时，网站将用户提供的令牌与数据库中的令牌进行比较。

在底层，字符串比较通常一次比较一个字符，直到完成字符串或遇到不匹配的字符对。这意味着匹配的字符越多，比较所需的时间越长：

在此图示中，我们使用两个HTTP请求来问问题“数据库是否包含以d7e开头的密码重置令牌？”服务器需要一秒钟来比较每个字符，因此通过比较响应时间，攻击者可以判断令牌以“d7e”而不是“d7f”开头。

不幸的是，实际比较每个字符的时间大约在5纳秒或0.000000005秒的范围内。祝你好运利用那个。

噪声与信号

每个时序攻击的成功归结为两个竞争变量——信号和噪声。信号指的是您想要检测的时序差异的大小，噪声指的是影响响应时序的所有其他因素。如果信号相对于背景噪声太安静，您将听不到它：

对于实际有效的攻击，您需要最大化信号并最小化噪声。本节的其余部分专注于如何做到这一点。

请注意，此方程不包括“测量次数”。您可以通过重复测量来尝试消除噪声，但这种方法扩展性差。一旦噪声严重超过信号，您将很快需要数十亿次测量，导致攻击耗时如此之长，以至于目标可能在完成之前被停用。

您可以将噪声分为两部分——网络噪声（抖动）和服务器噪声（内部抖动）：

网络抖动是延迟的变化——数据包到达目标系统并返回所需的时间。它是远程时序攻击的经典克星。当有人看到针对本地系统的时序攻击演示并说“那在远程系统上永远行不通”时，他们基本上是在说网络抖动将使攻击不可能。五年前，这可能是真的。

使时序攻击“本地化”

2020年，Timeless Timing Attacks表明，您可以使用HTTP/2完全消除测量中的网络抖动。您可以将两个HTTP/2请求放入单个TCP数据包中，确保它们同时到达服务器。然后，您可以查看响应到达的顺序，推断哪个在服务器上处理时间更长：

这一单一发现消除了最大的噪声源，并改变了可检测内容的边界。只是有一个小问题。

粘性请求顺序问题

在HTTP/2层，两个请求完全并发，但底层的TLS数据是流，因此一个请求仍然是“第一个”，即一个将在另一个之前完全解密。如果您尝试这种技术，您会注意到网站显示出显著偏向于先回答第一个请求。这种偏向可能源于多个因素，包括解密第二个请求所需的时间和资源可用性。不幸的是，这可以掩盖您试图检测的延迟：

作者注意到了这个问题，并通过添加虚拟参数来减慢第一个请求的解析来处理它，以尝试重新同步执行。

使时序攻击可移植

实验室环境以比真实目标噪声少而闻名，但还有第二个更微妙的问题。专注于单个目标通常会产生特定于目标的技术，需要大量调整才能应用于其他任何地方。这使得它们对于任何有截止日期的人来说价值显著降低。

不幸的是，虚拟参数填充是这个问题的一个例子——其有效性取决于目标如何实现参数解析，以及系统在那一刻有多少处理容量可用。由于备用处理容量受其他系统影响，参数填充实际上可能最终增加噪声水平。我观察到在单个实验室系统上，十分钟 apart，需要不同数量的参数。

我们真正需要的是解决粘性请求顺序问题的方法，不需要针对每个目标进行配置。单包攻击，我去年为竞争条件发现开发的，为此提供了一个良好的起点。单包攻击 fragmentation 请求以减少“关键数据包”的大小——完成请求并启动执行的数据包。

它通过在前几个数据包中发送大部分请求，然后使用微小的最终数据包完成请求并触发执行来工作。在此图中，最终关键数据包用黑色勾勒：

不幸的是，这引入了不同的陷阱——一些服务器在获得标头后立即开始处理HTTP请求，而不等待正文。为了解决这个问题，我们需要说服我们的操作系统网络堆栈将标头帧合并到单个数据包中，这样无论服务器开始处理哪个阶段，两个请求都同时得到处理：

您可能想知道为什么我选择将请求分成仅两个关键数据包，而不是每个HTTP标头一个数据包。那确实会是理想的，但不幸的是，HTTP/2 RFC禁止交错来自单独请求的标头帧，因此它不太可能工作。

实现这种双包同步结果非常容易——只需添加一个额外的ping帧！这种无害的牺牲数据包确保操作系统合并后续的标头帧。

禁用TCP_NODELAY 为每个没有正文的请求发送一个ping帧： 发送标头 保留一个空的数据帧 对于每个有正文的请求： 发送标头，和正文除最后一个字节外 保留一个包含最终字节的数据帧 等待100ms 发送一个ping帧 发送最终帧 我们一发现这种改进的技术，就将其集成到Burp Suite的内置单包攻击中，所以您可能已经从中受益！我目前正在与开源实现h2spacex的开发人员合作，以将其也纳入其中。

使时序攻击可行

随着网络噪声的出局，我们的下一个目标是服务器噪声。不要低估服务器噪声。它源于众多来源，包括目标服务器上的负载、与之交互的其他系统、在同一物理硬件上运行的其他虚拟系统，以及可能的数据中心附近的天气。服务器噪声是我没有对使用增强的单包攻击可以检测到什么时间延迟做出任何声称的原因——任何这样的声称都是如此特定于目标，以至于实际上毫无意义。

为了最小化服务器噪声，采取最短的代码路径，并充分利用性能特性，如缓存、对象重用和连接重用。 committed 攻击者还可能使用DoS技术（如CPDoS和资源消耗）减少来自其他用户的噪声。

为了最大化信号，专注于慢代码路径，并通过使用随机输入避免服务器端缓存、尽可能访问慢资源以及增加工作负载来使其更慢。例如，此请求使用多个具有固定前缀的标头，试图扩大服务器寻找以“X-U”开头的标头所引起的延迟：

GET / HTTP/1.1 X-Uaa: a X-Ubb: a X-Ucc: a {256}

现代Web技术，如ORM和GraphQL，也特别适合延迟扩展技术。请记住，DoS攻击只是一个非常容易的时序攻击，并采用经典技术，如ReDoS、批处理和递归XML实体。

隐藏的攻击面

漏洞经常潜伏在废弃和被遗忘的功能中，被开发人员和安全测试人员 alike 忽视。因此，漏洞发现旅程通常从检测隐藏参数、cookie或HTTP标头开始。

在其核心，发现这些隐藏输入涉及猜测潜在参数名称并观察它们是否改变响应。不改变响应的参数可能保持未被检测到，以及任何相关的漏洞。对于我的第一次批量时序攻击，我决定解决这个问题。

方便的是，我是Param Miner的核心开发人员——可能是第一个用于批量参数发现的工具。Param Miner使用“字数”、“状态”和“行数”等属性比较响应。对于这项研究，我简单地添加了“响应时间”作为额外属性，增加了重复计数，并开始扫描。

我可以让Param Miner使用单包攻击进行这些测量，但这将涉及 significant 重构，并且在研究未经验证的概念时，我采取 every possible 捷径以避免浪费时间，所以我没有 bother。

相反，我只是测量了从请求的最后一个字节到响应的第一个字节的时间，并比较了两组30次时序测量的下四分位数，看看它们是否 distinct（表示有效参数）或重叠。下四分位数是这种比较的理想选择，因为它反映了噪声最少的测量。

发现过载

在30,000个实时站点的测试平台上运行时间增强的Param Miner产生了大量隐藏参数，包括一些非常奇怪的参数。

一个亮点是一个Web服务器，对包含神秘HTTP标头“commonconfig”的请求响应时间长了5ms，除非标头值是有效的JSON：

另一个发现是在一个拒绝响应任何请求的Web服务器上——它总是重置连接。这种极其防御的行为不足以阻止我的扫描发现它支持某个HTTP标头，因为该标头使其重置连接的时间 significantly 更长！有趣，但不是非常有用。

一个频繁的发现 much more 实用：

这对响应告诉我们两件有价值的事情。首先，该站点仅将特定参数如“id”包含在缓存键中，因此它高度暴露于基于参数的缓存中毒攻击。其次，我们知道“id”参数被键控，并且这种配置通常是站点范围的。这意味着使用时间分析，Param Miner检测到了一个适用于不同页面的参数！

最困难的问题

当我尝试这个概念时，我 anticipated 两个问题。首先，我 expected 许多技术完全失败。其次，我 suspected 我遇到的任何有效结果都将隐藏在误报的泥潭中。

最大的挑战来自 neither。是时序攻击太强大了。它们可以检测到如此之多，以至于 incredibly 容易误解您检测到的内容。它们 incredibly 擅长检测“某物”，但那个某物不一定是您试图检测的。完美地说明了这一点。这个参数检测乍一看像RCE，然后结果证明是完全不同的东西（但仍然有用）。

这个视频显示，由于“exec”参数导致可见的响应延迟，最初看起来像潜在的远程代码执行漏洞。这个延迟结果是一个WAF对更可疑的请求进行额外处理的指标。然后我们看到，当参数重复时，延迟叠加，除非请求正文超过某个大小阈值。最终这导致了一个完整的WAF绕过发现。这个绕过发现对我来说 completely unexpected，但此后已被其他人发现，并现在在nowafpls工具中实现。它仍然是时序分析如何揭示目标控制流洞察的一个美丽演示。

那是简单的情况之一——有时您可能永远无法 fully 理解您检测到的内容。轻装携带您的假设，并尽可能从不同角度测试它们。

证明概念

为了避免被错误假设误导，我决定专注于提供明确安全影响的特定参数，无需任何耗时的手动调查，并有 straightforward 方式收集额外的确证证据。

通过HTTP标头的IP地址欺骗完美地满足了这些要求。这是一个相对常见的配置错误，并直接启用各种利用，包括速率限制绕过、伪造日志，甚至在某些情况下的访问控制绕过。通过将IP地址放在欺骗的前端标头中，您 effectively 冒充前端。我们将在后面更深入地探讨前端冒充攻击。

方便的是，如果您将域放在欺骗的标头中，易受攻击的服务器通常会执行带内DNS查找来解析它，导致 easily detectable 延迟。这是一个典型的检测：

第一个响应快速返回，因为它不触发DNS查找。第二个响应触发对xyz.example.com的DNS查找，所以它更慢，第三个响应更快到达，因为DNS响应已被缓存：

我们将在后面重新讨论DNS缓存。总共，扫描IP地址欺骗 revealed：

• 375个易受攻击的域
• 其中206个还导致DNS回显
• 217个 visibly 缓存了结果

这可能让您想知道大约170个没有导致DNS回显的易受攻击域——它们是误报吗？这是一个例子：

您认为这里发生了什么？ 这是一个线索——在您的登录历史中，网站指定了登录IP地址和位置：

我认为这个系统正在将欺骗的IP地址传递到库中，该库在将其传递给第三方地理查找服务之前验证格式。提供无效的IP地址如“x.psres.net”导致异常，并阻止慢速IP查找发生：

所以，我们获得了一种新的参数发现技术，证明了时序攻击可以在野外大规模工作，并且还注意到了一些 significant：触发错误的输入可以 shortcut 大代码路径，并导致 significantly 更快的响应。换句话说，时序攻击 exceptionally 擅长检测异常。

服务器端注入

触发和发现异常是测试服务器端注入漏洞的基础部分，从SQLi到OS命令注入。这使得时序分析成为服务器端注入检测的完美匹配。

我试图通过添加“时间”作为响应属性到Backslash Powered Scanner来复制我在Param Miner中的成功，但这失败了。没有单包攻击，我只能检测主要的时间差异，而这些主要来自WAF而不是真正的漏洞。此外，工具的复杂性使其难以适应以克服挑战。

对于我的第二次尝试，我重用了Param Miner的一些代码来构建一个 much simpler 测试，使用单包攻击。我每个探测发出最多50个请求对，并记录每对的响应顺序。如果响应顺序至少80%偏向一个有效载荷，我将其报告为有效发现。

完全盲SQLi

第一个发现是一个完全盲SQL注入，用经典的有效载荷对检测：

不幸的是，当我报告时，结果证明是重复的。回想起来，我应该预见到这一点——您可以使用众所周知的“||sleep(5)||”有效载荷轻松检测相同的漏洞。高级时序分析根本不需要检测您可以注入睡眠语句的漏洞。同样，时序对于寻找代码注入并不 great，因为您通常可以通过使用OAST技术更好地找到那些。

对于强大的漏洞，如命令注入、SQLi和代码注入，基于时序的检测 only really useful 当您有WAF或过滤阻止经典检测技术时。让我们看看别处。

盲JSON注入

时序在寻找注入底层时发挥作用；允许操纵数据结构和格式但停止 short of 完全代码执行的漏洞。这包括注入到格式如JSON、XML、CSV以及服务器端查询参数和HTTP标头中。许多这些错误很少被谈论，因为它们如此难以检测。

它们也难以利用，但有时您可以将时序信息与可见特征结合，以获得对幕后发生的事情的额外洞察。例如，我发现一个目标，其中无效的JSON转义序列使响应返回快200us（0.2ms）：