升级头部劫持

从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS Red Team Expert）！

支持HackTricks的其他方式：

如果您想看到您的公司在HackTricks中做广告或下载PDF格式的HackTricks，请查看订阅计划!
获取官方PEASS & HackTricks周边产品
探索PEASS家族，我们的独家NFTs
加入 💬 Discord群 或 电报群 或关注我们的Twitter 🐦 @carlospolopm。
通过向HackTricks和HackTricks Cloud github仓库提交PR来分享您的黑客技巧。

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

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

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

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

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

Websocket Smuggling

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

场景 1

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

客户端通过在标头中使用不正确的 Sec-WebSocket-Version 协议版本向反向代理发送升级请求。代理未能验证 Sec-WebSocket-Version 标头，认为升级请求有效，并将其转发到后端。
后端以状态码 426 响应，指示 Sec-WebSocket-Version 标头中的不正确协议版本。反向代理忽略后端的响应状态，假设已准备好进行 WebSocket 通信，并将响应转发给客户端。
结果，反向代理被误导以为客户端和后端之间已建立了 WebSocket 连接，而实际上，后端已拒绝了升级请求。尽管如此，代理仍保持客户端和后端之间的开放 TCP 或 TLS 连接，使客户端通过此连接无限制地访问私有 REST API。

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

场景 2

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

客户端发送 POST 请求以触发健康检查 API，包括额外的 HTTP 标头 Upgrade: websocket。作为反向代理的 NGINX 仅基于 Upgrade 标头解释此请求为标准升级请求，忽略请求的其他方面，并将其转发到后端。
后端执行健康检查 API，访问由攻击者控制的外部资源，该资源返回带有状态码 101 的 HTTP 响应。一旦后端接收到此响应并将其转发到 NGINX，由于代理仅验证状态码，它被欺骗以为已建立 WebSocket 连接。