Chinese - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

支持 HackTricks

H2C 欺骗

明文 HTTP2 (H2C)

H2C，或称为 明文 HTTP2，通过将标准 HTTP 连接升级为持久连接，偏离了瞬态 HTTP 连接的常规。这种升级的连接利用 http2 二进制协议进行持续通信，而不是明文 HTTP 的单请求特性。

欺骗问题的关键在于使用 反向代理。通常，反向代理处理并转发 HTTP 请求到后端，然后返回后端的响应。然而，当 HTTP 请求中存在 Connection: Upgrade 头时（通常在 websocket 连接中看到），反向 代理在客户端和服务器之间保持持久连接，促进某些协议所需的持续交换。对于 H2C 连接，遵循 RFC 需要存在三个特定的头部：

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

漏洞产生于在升级连接后，反向代理停止管理单个请求，假设其路由工作在连接建立后已完成。利用 H2C Smuggling 可以绕过在请求处理期间应用的反向代理规则，例如基于路径的路由、身份验证和 WAF 处理，前提是成功发起 H2C 连接。

易受攻击的代理

该漏洞依赖于反向代理对 Upgrade 和有时 Connection 头的处理。以下代理在代理传递期间固有地转发这些头，从而固有地启用 H2C smuggling：

  • HAProxy

  • Traefik

  • Nuster

相反，这些服务在代理传递期间并不固有地转发这两个头。然而，它们可能被不安全地配置，允许不经过过滤地转发 Upgrade 和 Connection 头：

  • AWS ALB/CLB

  • NGINX

  • Apache

  • Squid

  • Varnish

  • Kong

  • Envoy

  • Apache Traffic Server

利用

需要注意的是，并非所有服务器都固有地转发符合 H2C 连接升级所需的头。因此，像 AWS ALB/CLB、NGINX 和 Apache Traffic Server 等服务器自然会阻止 H2C 连接。尽管如此，值得测试不合规的 Connection: Upgrade 变体，该变体从 Connection 头中排除了 HTTP2-Settings 值，因为某些后端可能不符合标准。

无论在 proxy_pass URL 中指定的具体 路径（例如 http://backend:9999/socket.io）是什么，建立的连接默认为 http://backend:9999。这允许与该内部端点内的任何路径进行交互，利用此技术。因此，在 proxy_pass URL 中指定路径并不限制访问。

工具 h2csmuggler by BishopFox 和 h2csmuggler by assetnote 通过建立 H2C 连接来帮助尝试 绕过代理施加的保护，从而访问被代理保护的资源。

有关此漏洞的更多信息，特别是关于 NGINX 的信息，请参阅 此详细资源。

Websocket Smuggling

Websocket smuggling 与通过代理创建 HTTP2 隧道到可访问的端点不同，它建立一个 Websocket 隧道以绕过潜在的代理限制并促进与端点的直接通信。

场景 1

在此场景中，后端提供公共 WebSocket API，同时有一个无法访问的内部 REST API，恶意客户端试图访问内部 REST API。攻击分为几个步骤：

  1. 客户端通过向反向代理发送带有错误的 Sec-WebSocket-Version 协议版本的 Upgrade 请求来启动。代理未能验证 Sec-WebSocket-Version 头，认为 Upgrade 请求有效并将其转发给后端。

  2. 后端以状态码 426 响应，指示 Sec-WebSocket-Version 头中的协议版本不正确。反向代理忽视后端的响应状态，假设已准备好进行 WebSocket 通信，并将响应转发给客户端。

  3. 因此，反向代理被误导认为客户端和后端之间已建立 WebSocket 连接，而实际上后端已拒绝 Upgrade 请求。尽管如此，代理在客户端和后端之间保持开放的 TCP 或 TLS 连接，允许客户端通过此连接无限制访问私有 REST API。

受影响的反向代理包括 Varnish，该代理拒绝解决此问题，以及 Envoy 代理版本 1.8.0 或更早版本，后续版本已更改升级机制。其他代理也可能易受攻击。

场景 2

此场景涉及一个后端，既有公共 WebSocket API，也有用于健康检查的公共 REST API，以及一个无法访问的内部 REST API。攻击更复杂，涉及以下步骤：

  1. 客户端发送 POST 请求以触发健康检查 API，包括额外的 HTTP 头 Upgrade: websocket。NGINX 作为反向代理，将其解释为基于 Upgrade 头的标准 Upgrade 请求，忽略请求的其他方面，并将其转发给后端。

  2. 后端执行健康检查 API，联系由攻击者控制的外部资源，该资源返回状态码为 101 的 HTTP 响应。此响应在被后端接收并转发给 NGINX 后，欺骗代理认为已建立 WebSocket 连接，因为它仅验证了状态码。

警告： 此技术的复杂性增加，因为它需要能够与能够返回状态码 101 的端点进行交互。

最终，NGINX 被欺骗认为客户端和后端之间存在 WebSocket 连接。实际上，并不存在这样的连接；健康检查 REST API 是目标。尽管如此，反向代理保持连接开放，使客户端能够通过它访问私有 REST API。

大多数反向代理在此场景中易受攻击，但利用取决于存在外部 SSRF 漏洞，通常被视为低严重性问题。

实验室

检查实验室以测试这两种场景 https://github.com/0ang3el/websocket-smuggle.git

参考文献

支持 HackTricks
PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated