倾听低语：真正有效的Web时序攻击 | PortSwigger研究

网站充满了急于泄露其最深层秘密的时序预言。是时候开始倾听它们了。
在本文中，我将释放新颖的攻击概念，以诱出服务器秘密，包括掩蔽的错误配置、盲目的数据结构注入、通往禁止区域的隐藏路由以及大量不可见的攻击面。
这不是理论威胁；每种技术都将通过针对不同目标的多个真实案例研究进行说明。前所未有的进步使这些攻击既准确又高效；在十秒钟内，您现在可以可靠地检测到亚毫秒级的差异，无需事先配置或“实验室条件”。换句话说，我将分享您实际可以使用的时序攻击。
为了帮助您，我将为您配备一套经过实战检验的开源工具，支持免提自动化利用和自定义攻击脚本。我还将分享一个小型CTF，以帮助您磨练新技能。
想更进一步？我将通过分享在数千个网站上测试无数概念后提炼的方法论，帮助您将自己的攻击想法从理论转化为现实。我们忽视这种无处不在且极其强大的侧信道太久了。

这项研究论文伴随Black Hat USA和DEF CON的演讲：

您还可以以打印友好的PDF格式阅读此白皮书。

大纲

• 背景
• 制作随处可用的时序攻击
• 回答难题
• 使时序攻击“本地化”
• 使时序攻击可行
• 隐藏攻击面
• 发现过载
• 最困难的问题
• 证明概念
• 服务器端注入
  • 盲SQL注入
  • 盲JSON注入
  • 盲服务器端参数污染
• 反向代理错误配置
  • 范围限制的SSRF
  • 防火墙绕过
  • 隐藏目的地
  • 前端规则绕过
  • 前端冒充
• 研究路线图
• 防御
• 要点

背景

Web时序攻击因两件事而臭名昭著：做出大承诺和未能兑现。例子通常是理论性的，即使某种技术被称为“实用”，每个人都知道一旦尝试在实验室环境之外应用它，它就会停止工作。
这种声誉可能是我们忽略了一个巨大机会的原因。
我首次研究时序攻击的结果坚定地属于“理论”桶。对于第二次尝试，我开始回顾我成功在野外应用的攻击以及其他我读到的攻击：

从上到下，这些是以下示例：

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

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

时序攻击研究通常专注于单个目标，但这限制了其真实世界价值。我想要可以应用于任意实时目标的技术。为了确保我的新攻击概念符合这一标准，我在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数据是流，因此一个请求仍然是“第一个”，即一个将在另一个之前完全解密。如果您尝试这种技术，您会注意到网站显示出显著偏向于先回答第一个请求。这种偏向可能源于多个因素，包括解密第二个请求所需的时间和资源可用性。不幸的是，这可能掩盖您试图检测的延迟： 作者注意到了这个问题，并通过添加虚拟参数来减慢第一个请求的解析来处理它，试图重新同步执行。

使时序攻击可移植

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

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

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

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

不幸的是，这引入了不同的陷阱——一些服务器在获得标头后立即开始处理HTTP请求，而不等待正文。为了解决这个问题，我们需要说服我们的操作系统网络堆栈将标头帧合并到单个数据包中，以便无论服务器开始处理哪个阶段，两个请求都同时得到处理： 您可能想知道为什么我选择将请求分成仅两个关键数据包，而不是每个HTTP标头一个数据包。那确实理想，但不幸的是HTTP/2 RFC禁止交错来自单独请求的标头帧，因此它不太可能工作。

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

• 禁用 TCP_NODELAY
• 发送一个ping帧
• 对于每个无正文的请求：
  • 发送标头
  • 保留一个空数据帧
• 对于每个有正文的请求：
  • 发送标头和除最终字节外的正文
  • 保留一个包含最终字节的数据帧
• 等待100ms
• 发送一个ping帧
• 发送最终帧

我们一发现这种改进的技术，就将其集成到Burp Suite的内置单包攻击中，所以您可能已经从中受益！我目前正在与开源实现h2spacex的开发人员合作，以将其也纳入其中。

使时序攻击可行

随着网络噪声的出局，我们的下一个目标是服务器噪声。不要低估服务器噪声。它源于众多来源，包括目标服务器上的负载、与之交互的其他系统、在同一物理硬件上运行的其他虚拟系统，以及可能的数据中心附近的天气。服务器噪声是我没有对增强单包攻击可以检测到什么时间延迟做出任何声称的原因——任何这样的声称都是如此目标特定，以至于实际上毫无意义。
为了最小化服务器噪声，采取最短的代码路径，并充分利用性能特性，如缓存、对象重用和连接重用。坚定的攻击者还可能使用DoS技术（如CPDoS和资源消耗）减少来自其他用户的噪声。
为了最大化信号，专注于慢代码路径，并通过使用随机输入避免服务器端缓存、尽可能访问慢资源以及增加工作负载来使其更慢。例如，此请求使用多个具有固定前缀的标头来尝试扩大由服务器寻找以“X-U”开头的标头引起的延迟：

1
2
3
4
5

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使用单包攻击进行这些测量，但这将涉及重大的重构，并且在研究未经验证的概念时，我采取 every possible shortcut 以避免浪费时间，所以我没有麻烦。

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

发现过载

在30,000个实时站点的测试平台上运行时间增强的Param Miner产生了大量的隐藏参数，包括一些非常奇怪的参数。
一个亮点是一个Web服务器，对包含神秘HTTP标头“commonconfig”的请求需要5ms更长的时间响应，除非标头值是有效的JSON：

1
2
3
4

Header Response Time
foo: x HTTP/1.1 200 OK 50ms
commonconfig: x HTTP/1.1 200 OK 55ms
commonconfig: {} HTTP/1.1 200 OK 50ms

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

1
2
3

Header Response Time
foo: x --connection reset-- 30ms
authorization: x --connection reset-- 50ms

一个频繁的发现更实用：

1
2
3

Request Response Time
GET /?id=random HTTP/1.1 200 OK 310ms
GET /?foo=random HTTP/1.1 200 OK 22ms

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

最困难的问题

当我尝试这个概念时，我 anticipated 两个问题。首先，我预计许多技术会完全失败。其次，我怀疑我遇到的任何有效结果都会隐藏在大量误报中。
最大的挑战来自 neither。是时序攻击太强大了。它们可以检测到如此之多，以至于很容易误解您检测到的内容。它们非常擅长检测“某物”，但那个某物不一定是您试图检测的。完美地说明了这一点。这种参数检测乍一看像RCE，结果却是完全不同的东西（但仍然有用）。
此视频显示，由于“exec”参数导致可见的响应延迟，最初看起来像潜在的远程代码执行漏洞。这种延迟结果是一个WAF对更可疑请求进行额外处理的指标。然后我们看到，当参数重复时，延迟会叠加，除非请求正文超过某个大小阈值。最终这导致了一个完整的WAF绕过发现。这个绕过发现对我来说完全出乎意料，但后来被其他人发现，并现在在nowafpls工具中实现。它仍然是时间分析如何揭示目标控制流洞察的一个美丽演示。
那是简单的情况之一——有时您可能永远无法完全理解您检测到的内容。轻带您的假设，并尽可能从不同角度测试它们。

证明概念

为了避免被错误假设误导，我决定专注于提供明确安全影响的特定参数，无需任何耗时的手动调查，并有直接的方式收集额外的确证证据。
通过HTTP标头的IP地址欺骗完美满足了这些要求。这是一个相对常见的错误配置，并直接启用各种漏洞利用，包括速率限制绕过、伪造日志，甚至在某些情况下的访问控制绕过。通过将IP地址放在欺骗的前端标头中，您实际上是在冒充前端。我们将在后面更深入地探讨前端冒充攻击。
方便的是，如果您将域放在欺骗标头中，易受攻击的服务器通常会执行带内DNS查找来解析它，导致 easily detectable 延迟。这是一个典型的检测：

1
2
3
4

Header Time
Random-header: xyz.example.com 65ms
True-Client-IP: xyz.example.com 70ms
True-Client-IP: xyz.example.com 65ms

第一个响应快速返回，因为它不触发DNS查找。第二个响应触发对xyz.example.com的DNS查找，所以它更慢，第三个响应更快，因为DNS响应已被缓存：我们将在后面重新讨论DNS缓存。总共，扫描IP地址欺骗揭示了：

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

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

1
2
3
4

Header Time
Random-header: x.psres.net 170ms
True-Client-IP: x.psres.net 90ms
True-Client-IP: 1.1.1.1 170ms

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

1
2

Time Browser IP Location
5 minutes ago Chrome in Windows 1.1.1.1 Cloudflare

我认为这个系统正在将欺骗的IP地址传递给一个库，该库在将其传递给第三方地理查找服务之前验证格式。提供像“x.psres.net”这样的无效IP地址导致异常，并阻止了慢速IP查找的发生：
所以，我们获得了一种新的参数发现技术，证明了时序攻击可以在野外大规模工作，并且还注意到了一些重要的事情：触发错误的输入可以 shortcut 大代码路径，并导致显著更快的响应。换句话说，时序攻击 exceptionally good at detecting exceptions。

服务器端注入

触发和发现异常是测试服务器端注入漏洞的基础部分，从SQLi到OS命令注入。这使得时序分析成为服务器端注入检测的完美匹配。
我试图通过将“时间”添加为响应属性到Backslash Powered Scanner来复制我在Param Miner中的成功，但这失败了。没有单包攻击，我只能检测到主要的时间差异，而这些主要来自WAF而不是真正的漏洞。此外，工具的复杂性使其难以适应以克服挑战。
对于我的第二次尝试，我重用了Param Miner的一些代码来构建一个更简单的测试，使用单包攻击。我为每个探测发出最多50个请求对，并记录每对的响应顺序。如果响应顺序至少80%偏向一个有效负载，我将其报告为有效发现。

完全盲SQL注入

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

1
2
3

Request Response Time
GET /api/alert?mic=' {} 162ms
GET /api/alert?mic='' {} 170ms

不幸的是，当我报告时，结果发现是重复的。回想起来，我应该预见到这一点——您可以使用众所周知的“||sleep(5)||”有效负载轻松检测相同的漏洞。高级时序分析根本不需要检测您可以注入sleep语句的漏洞。同样，时序对于查找代码注入并不 great，因为您通常可以通过使用OAST技术更好地找到那些。
对于强大的漏洞如命令注入、SQLi和代码注入，基于时序的检测只有在您有WAF或过滤阻止经典检测技术时才有用。让我们看看别处。

盲JSON注入

时序在寻找注入底层时发挥作用；允许操纵数据结构和格式但停止 short of 完整代码执行的漏洞。这包括注入到格式如JSON、XML、CSV以及服务器端查询参数和HTTP标头中。许多这些错误很少被谈论，因为它们很难检测。
它们也很难利用，但有时您可以将时序信息与可见特征结合，以获得对幕后发生的事情的额外洞察。例如，我发现一个目标，其中无效的JSON转义序列使