浪潮IDI默认口令漏洞复现

Wayyt 4小时前

浪潮IDI默认口令漏洞复现

0x00 漏洞概述

浪潮IDI-浪潮聚数是浪潮推出的数据集成产品，基于全新架构，采用流程化设计思想，可支撑从数据抽取、清洗、转换再到加载的数据集成全过程，其 Web 端承担集成任务的配置、调度与状态管理职能。

该 Web 系统存在默认口令问题：登录凭据 cluster/cluster 为出厂预设的默认组合，部署环节未强制修改。该漏洞的公开描述中提及，在用户没更改默认口令的情况下，攻击者可利用默认口令登录该系统，查看系统信息，修改系统配置，或配合其他漏洞攻击，获取服务器权限。

0x01 影响范围

受影响产品为浪潮IDI。系统的 Web 服务基于 Kettle 数据集成引擎构建，采用 HTTP Basic 认证方式，认证域（realm）标识为 Kettle，状态接口路径为 /Kettle/status。受影响版本官方未公开说明。

资产识别特征方面，对系统任意受保护路径发起请求时，响应头会返回 WWW-Authenticate: Basic realm="Kettle"，该特征可直接用于定位暴露在外的浪潮IDI Web 服务。作为背景，Kettle 的 Carte 子系统以 HTTP 服务形式对外提供状态查询等接口，/Kettle/status 用于返回转换与作业的运行状态，访问凭据以加密形式存储在 kettle.pwd 文件中——浪潮IDI 正是沿用了这一服务形态，并将默认凭据预设为 cluster/cluster。

0x02 漏洞分析

HTTP Basic 认证的机制决定了凭据形态高度可预测：客户端将「用户名:密码」字符串经 ba se64 编码后放入 Authorization 请求头。默认凭据 cluster:cluster 编码后即为 Y2x1c3RlcjpjbHVzdGVy，这段固定值构成了利用的载荷核心。

利用过程分两步形成完整闭环：第一步以无凭据请求 /Kettle/status，预期收到 HTTP 401 响应，既确认接口存在并处于 Basic 认证保护之下，也通过 realm 特征进一步确认产品形态；第二步在 Authorization 头中携带默认凭据对应的 ba se64 值再次请求同一地址，若返回 HTTP 200，则表明默认口令未被修改，认证已被通过。

认证通过后，/Kettle/status 接口会返回数据集成环境中转换与作业的运行状态信息，攻击者据此可掌握系统信息；在该服务的其他管理接口上（推断），持同一凭据的访问者可以查看和修改集成任务配置，若配置中包含可执行的外部组件调用，还存在配合其他漏洞获取服务器权限的空间。整个利用过程不需要任何预先掌握的账户信息，仅依赖公开可知的默认凭据组合。

0x03 利用链与请求包

以下以示意地址 192.168.10.40 指代目标主机，请求需跟随重定向。

第一步：无凭据探测，确认接口与认证形态。请求包：

GET /Kettle/status HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

预期响应状态码为 401，表示接口存在且要求 Basic 认证。

第二步：携带默认凭据发起登录，Authorization 头的取值为 cluster:cluster 的 ba se64 编码。请求包：

GET /Kettle/status HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Authorization: Basic Y2x1c3RlcjpjbHVzdGVy

成功判定标准：响应状态码为 200。状态码由 401 变为 200，即表明默认凭据 cluster/cluster 通过了认证，利用完成。此时响应体中将包含该数据集成环境的状态信息，攻击者可在已认证会话中继续查看系统信息或修改系统配置。若口令已被修改（推断），第二步请求仍会返回 401，可据此判断目标是否处于风险状态。

0x04 检测与修复建议

检测方面：对资产测绘识别出的浪潮IDI Web 服务，可先以无凭据请求 /Kettle/status 确认 401 响应与 realm="Kettle" 特征，再携带默认凭据组合重复请求，依据状态码是否变为 200 判断默认口令风险；同时排查访问日志中携带 Y2x1c3RlcjpjbHVzdGVy 凭据头的非授权来源请求。

修复方面：

1. 立即修改默认管理员密码，新密码应包含大小写字母、数字和特殊字符，且长度不小于 12 位；

2. 禁止将管理界面暴露到公网，通过防火墙限制访问来源；

3. 谨慎启用自定义工具等高权限功能，限制可执行代码的权限；

4. 启用操作日志审计，记录所有管理操作和 API 调用；

5. 定期检查用户账户和 API 密钥的使用情况。