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

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

  • 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 BishopFoxh2csmuggler 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

Last updated