升级头部走私

Reading time: 9 minutes

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 值，因为某些后端可能不符合标准。

工具 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

参考文献

• https://blog.assetnote.io/2021/03/18/h2c-smuggling/
• https://bishopfox.com/blog/h2c-smuggling-request
• https://github.com/0ang3el/websocket-smuggle.git