JSON响应泄露oVirt管理面板凭证，一个漏洞如何导致虚拟化基础设施沦陷

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。
声明：本文搬运自互联网，如您是原作者，请联系我们！

类型：不安全的APP接口

第一幕：从ISO启动按钮开始监听

在研究一个虚拟化管理面板时，我尝试点击了“从ISO启动”的按钮，并随即开始监控网络活动。观察前端与后端交互的请求类型，是理解系统行为的有效方式。

首先发出的请求是启动指令，其格式如下：

POST /eq.php HTTP/1.1
Host: panel.[REDACTED].com
Content-Type: application/x-www-form-urlencoded

module=eq&action=boot_dev&media=cd&attempts=50&timeout=1000&token=b68cefcf4349d9c9e45ec1132da3e4e4&id=82674&api_key=MY_API_KEY

这个请求的目的很明确：指示特定的虚拟机从已挂载的CD-ROM镜像启动。随后，前端会发起轮询请求来检查启动状态：

POST /eq_callback.php?action=check HTTP/1.1
Host: panel.[REDACTED].com
Content-Type: application/x-www-form-urlencoded
Referer: https://panel.[REDACTED].com/controlpanel.html?key=MY_API_KEY

第二幕：泄露内部秘密的JSON响应

轮询请求的JSON响应看似普通，但仔细观察后，我在 scope 字段中发现了一些异常。这个字段不仅包含了操作状态，还嵌套了一段看起来像是完整的内部HTTP请求记录。

从一张开发者工具的截图中可以看到，这个POST请求的响应头显示状态为200 OK，服务器由PHP/8.0.24驱动，响应体是一个JSON对象。该对象的核心部分如下，其中scope字段的值是一个被转义后嵌入的字符串，包含了惊人的信息：

{
  "result": "OK",
  "scope": "{\"result\":\"OK\",\"message\":\"VM is boot for cdrom\"}&{POST https://ovr-client-nl2.[REDACTED].com/ovirt-engine/api/vms/.../start HTTP/1.1 1 1 map[Accept:[application/xml] Authorization:[Basic aW5mcmE6QGdudG9yYmFzdGQ0QVZVaHRlZWM==] Content-Type:[application/xml] Version:[4]] ...}",
  ...
}

关键点在于，这段泄露的文本里包含了一个完整的 Authorization 请求头：

Authorization:[Basic aW5mcmE6QGdudG9yYmFzdGQ0QVZVaHRlZWM==]

我立刻对这段Base64编码的字符串进行了解码：

echo "aW5mcmE6QGdudG9yYmFzdGQ0QVZVaHRlZWM==" | base64 -d
# 输出：infra:@gntorbastd4AVUhtec

解码结果是 infra:@gntorbastd4AVUhtec，格式为用户名:密码。这组有效的内部服务凭证，就这样毫无遮拦地出现在了返回给前端的响应报文里。

沿着泄露的路径直抵管理面板

不仅如此，泄露的 scope 信息还揭示了完整的内部API端点路径。我据此访问了oVirt引擎的管理门户登录地址 ovr-client-nl2.[REDACTED].com/ovirt-engine/webadmin/sso/login。

访问后，一个深色背景的oVirt网站登录页面呈现出来，页面上清晰地标注着版本号为4.5.6-1.el8。页面主要分为三个导航区域：Portals（包含管理门户、虚拟机门户、监控门户）、Downloads（控制台客户端资源和引擎CA证书）以及Technical Reference（REST API指南）。

我尝试使用刚刚获取的凭证登录：

• 用户名：infra
• 密码：@gntorbastd4AVUhtec
• 域/Profile：internal

点击登录后，成功进入了Open Virtualization Manager的管理仪表盘。

仪表盘界面布局清晰，左侧是导航菜单，包括Dashboard、Compute、Network、Storage、Administration和Events。主界面展示了全局资源利用率，包含三个圆形进度图：CPU可用62%，内存可用8.2 TiB（总计14.4 TiB），存储可用79.0 TiB（总计189.8 TiB）。下方还有一个集群利用率柱状图，按百分比区间展示了CPU、内存和存储的使用分布。至此，我已获得了对整个虚拟化控制平面的完全访问权限，这无疑是安全领域的重大失误。

漏洞原理深度剖析

这个漏洞链条清晰地展示了从用户操作到完全沦陷的全过程：

1. 触发内部调用：面向用户的“启动虚拟机”功能，触发了一个后端服务（如oVirt）的内部API调用。
2. 泄露内部行为：用于状态检查的响应，错误地将内部调用的原始HTTP请求详情（包括完整的请求头和认证信息）作为调试信息包含在内。
3. 暴露敏感凭证：这些内部请求头中，包含了用于服务间认证的高权限Basic Auth凭证。
4. 缺乏安全过滤：在将包含这些调试信息的JSON返回给前端用户之前，系统未进行任何敏感信息过滤、编辑或访问控制检查。

这好比在给客户开具消费小票时，不小心把仓库管理员的账号密码和仓库后门的钥匙编码也一并打印了上去。

根据CVSS v3.1标准，此漏洞评分为9.9（危急）。评分向量为：AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H，意味着攻击者可以通过网络低复杂度地利用此漏洞，造成机密性、完整性、可用性的全面高危影响，并且影响范围可波及整个基础设施。

修复方案与最佳实践

针对此类因信息泄露导致基础设施沦陷的严重漏洞，应立即采取以下措施：

1. 凭证紧急撤销：立即撤销所有在泄露的调试信息中出现的内部凭证，并进行全面轮换。
2. 净化生产环境输出：建立严格的代码审查和测试流程，确保所有返回给客户端的响应数据（包括错误信息、调试日志、跟踪数据等）在生产环境中都被彻底清理，移除任何内部调用详情、路径、令牌和凭证。
3. 隔离内部通信：绝不向外部用户暴露原始的内部HTTP请求或响应。内部服务间的通信详情应记录在受保护的服务器日志中，而非传递给客户端。
4. 全面接口审计：对所有提供状态、回调或调试信息的API端点进行全面的安全审计，检查是否存在类似的信息泄露模式。
5. 强化身份与访问管理：采用更安全的服务间认证方式，如使用短期令牌而非长期静态凭证，并实施最小权限原则。考虑在云原生架构中引入服务网格来管理安全的服务间通信。

额外的收获

在遵循负责任的漏洞披露流程，将这一严重问题报告给相关厂商后，我获得了 1500美元 的漏洞赏金。这个赏金数额反映了该漏洞的严重性——它直接暴露了客户的整个虚拟化集群，如果不被发现和修复，攻击者可以利用泄露的凭证破坏整个基础设施。

这次事件再次证明，一个看似无害的、信息过于“详尽”的JSON响应字段，一个暴露在公网的管理面板，再加上一个被无意间泄露的认证头，就足以构成一条通往核心资产的致命攻击链。

参考资料

[1] 0122.如何通过一段冗长的 JSON 响应接管一家公司的整个基础设施。, 微信公众号：mp.weixin.qq.com/s/C3-RZNHplCZLH8NGZd99fg

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。