摘要

  • Lava 在 5 月 6 日测得 36872 个唯一公网 IPMI 端点;这是一次 IP 地址计数,不是数据中心、服务器、运营商或客户数量。
  • 其中 24650 个、占 66.9%,在客户端认证前返回了至少一份由口令派生的 RAKP 响应。
  • 6240 个端点在空用户名条件下与弱口令候选匹配,另有 2340 个端点的具名账户与常见口令候选匹配。
  • 研究人员在一家未具名 GPU 提供商的两台现代 Supermicro X13DEM 系统上恢复了文档所述出厂格式口令,但没有登录;对方随后完成整改。
  • CVE-2013-4786 早在 2013 年就记录了 RAKP 机制;2026 年的新信息是旧机制仍通过多少公网接口提供响应。
  • 首要措施是让 IPMI 退出公网,边界阻断 UDP 623,隔离管理网,轮换出厂口令,并建立独立监控。

第一个不等号:IP 地址不等于一座数据中心

36872 首先是一次外部测量看到的唯一公网 IPMI 端点数。一个公网地址可能随后被回收,也可能对应不同规模和结构的设备。扫描并不知道地址背后有几台物理服务器、属于几个客户,或者位于多少座建筑。

因此,不能把这个数字改写成“36872 座数据中心”或“36872 家运营商”。这不仅是措辞严谨问题,还关系到风险分母。没有全网部署总量,就算不出某个厂商或行业的暴露率;没有持续观测,也不能断言每个地址长期保持相同状态。

但端点计数仍然有明确含义:在 5 月 6 日那个时点,来自公网的请求能够抵达这些管理接口,并让它们开始 IPMI 交互。它衡量的是外部可达面,不是受害者数量。

对运营方而言,这也是最先能够消除的风险。如果 BMC 只存在于不对公网路由的管理网络,外部扫描者就无法进入下一步。无需等待口令被恢复,第一道边界就可以关闭。

第二个不等号:返回认证材料不等于破解口令

IPMI 2.0 的 RAKP 认证流程会在客户端证明身份之前返回一份由口令计算的 HMAC。CVE-2013-4786 在 2013 年已说明,拿到这份材料的人可以把它带走,在自己的计算设备上离线比较候选口令。

Lava 在 24650 个端点获得了至少一份这样的响应,占测量端点的 66.9%。这意味着猜测机会已经形成,却不意味着响应里包含可直接读取的明文口令。更不意味着 24650 个端点都找到了匹配候选。

离线猜测改变了防守条件。设备上的登录限速或多次失败锁定,无法限制另一台机器本地进行的计算。真正稳固的补偿控制,是不让不可信网络取得那份起始材料。

因此,“24650 份登录前响应”是准确结论,“24650 个口令被破解”则跨越了来源没有提供的证据。风险并未因此变小:一个拥有电源、控制台、虚拟介质和固件权限的界面,本就不应向未知请求者提供可离线验证的材料。

第三个不等号:恢复口令不等于已经入侵

从公网响应到系统入侵,中间至少还有候选匹配、口令恢复、口令仍然有效、认证会话成功、执行未授权操作等环节。Lava 量化了前面若干环节,并在关键位置主动停下。

研究分别记录了两类匹配。6240 个端点在空用户名条件下返回的材料与弱口令候选吻合;2340 个端点的具名账户与常见口令字典候选吻合。两组的账户条件和候选集合不同,不能混成一个模糊的“全部哈希破解比例”。

对于两台现代 Supermicro X13DEM 系统,研究人员恢复了文档所述十位大写字母出厂格式口令。设备属于一家未具名的 GPU 提供商。Lava 明确表示没有用口令登录,并在披露后看到运营方修复暴露。

这证明有限格式会削弱唯一口令的抗猜测成本,也证明整改可以在不跨越登录边界的情况下完成。它不证明这两台机器遭到控制,更不能外推到所有 X13DEM、所有 Supermicro 设备或所有 GPU 基础设施。

BMC 位于操作系统之下,也可能位于常规防线之外

BMC 的价值在于独立于主机操作系统。即使服务器不能启动,管理员仍可远程开关机、查看控制台、挂载虚拟介质、修改配置或处理固件。它是故障恢复通道,也是一条权限很高的控制通道。

这种独立性意味着常规主机安全措施未必覆盖它。操作系统账户、主机防火墙和端点检测工具可以全部正常,BMC 却使用另一块网络接口、另一套口令和另一组日志。管理面出问题时,主机本身甚至可能无法留下完整证据。

数据中心的责任链也不只属于一方。厂商决定协议实现、初始口令格式和安全选项;集成商接线并设置管理网络;运营商决定 VLAN、访问控制和边界路由;托管客户有时获得委托控制台权限。某个临时安装通道如果没有明确移交责任,就可能在投产后继续留在公网。

因此,修复不能只写成“让用户改密码”。它至少包括网络可达性、身份凭据、权限配置、固件维护和独立监控五层。某一层更强,不能替代另一层缺失。

唯一出厂口令解决的是共用问题,不自动解决搜索空间

Supermicro 称,自 2019 年 11 月起,相关新系统不再统一使用ADMIN,而是预设每台设备独有的 BMC 口令。这项变化切断了“一把钥匙开一批机器”的共享默认口令风险。

不过,“每台不同”和“难以穷举”是两个属性。前者限制横向影响,后者取决于格式的可能组合数。如果格式范围有限,而 RAKP 材料又可从公网获取,攻击者仍可能逐台离线搜索。

HPE 部分的数字来自受控实验。Lava 称,在八块 RTX 6000 PRO GPU 上,对文档所述八字符 iLO 出厂格式进行完整搜索,每份捕获响应约需 32 秒。这是特定硬件和特定格式下的计算成本,不是对公网所有 HPE 设备的实测入侵结果。

把实验成本写清楚,才能避免两种错误。不能因为计算很快就宣称全部 HPE 系统失守;也不能因为厂商已使用唯一口令,就忽略格式约束和公网交互共同造成的风险。

厂商占比不是厂商故障率

Lava 数据集中,Supermicro 硬件占返回响应的 BMC 一半以上。这个比例的分母是扫描中得到响应的设备,不是 Supermicro 全球装机总量。缺少各厂商部署基数、型号构成和网络策略,无法由此计算厂商漏洞率。

厂商仍然掌握重要控制面。它可以扩大口令空间、改善默认配置、修订固件,并把隔离要求写进部署流程。Supermicro 自己的 BMC 安全指南已指出标准 RAKP 哈希较弱,要求不要把 BMC 暴露给公网或防火墙外的未授权用户,并建议阻断不安全网络上的 UDP 623。

运营方掌握另外一些控制:管理接口是否获得公网路由,哪些源地址可访问,出厂口令是否在上线时轮换,异常请求是否进入告警。把所有责任归给硬件品牌,会掩盖这些能够立即改变的部署决策。

外部占比最适合作为一次盘点触发器。每家运营方应该用自己的资产清单、地址记录、防火墙规则和负责人信息建立真实分母,而不是用别人的全网扫描猜测自己是否安全。

先隔离,再谈口令和新协议

Supermicro 指南建议把 BMC 放在独立管理 VLAN,通过防火墙和已知 IP 访问控制保护子网,并在不安全网络边界阻断 UDP 623。实际部署还可以要求管理员先进入受控 VPN 或堡垒机,再访问内部管理接口。

这类架构先取消陌生来源获取 RAKP 材料的机会。之后仍要轮换出厂口令、删除不需要的账户、在设备支持时关闭弱旧机制,并保持固件更新。凭据治理是第二道控制,不是保留公网暴露的许可证。

Redfish 通过 TLS 可以改善传输安全和现代管理能力,但也只应在隔离管理网内使用。加密能保护会话内容,不能决定谁有资格抵达登录界面。把公网 IPMI 换成公网 Redfish,不等于重新建立信任边界。

监控必须独立。BMC 登录尝试、配置变化、固件操作和网络流量应进入专门日志和告警,不能只依靠主机操作系统报告。资产清单还要把物理设备、控制器地址、客户归属和边界规则绑定起来,避免设备或客户更换后遗留旧通道。

下一次测量应回答“是否还在”,而不是虚构“谁已被攻破”

5 月 6 日的结果是一张快照。可比复测可以观察公开端点和登录前响应是否减少,但需要区分地址轮换、设备下线和真正整改。否则,数字下降也可能只反映测量对象变化。

更有价值的运营指标包括:多少 BMC 只接受私网路由,多少部署限制已知源地址,多少设备在投产时轮换出厂口令,多少异常认证能被独立发现。这些指标都对应明确责任人和可验证控制。

若要证明实际攻击,则需要另一类证据:成功认证日志、未授权命令、配置或固件变化,以及已确认事件。当前研究没有声称拥有这些材料。

Lava 此次发现的核心不是 24650 起入侵,而是 24650 个管理端点在不知道对方身份时开始了一场不该发生在公网的口令对话。对于位于操作系统之下的控制面,最好的登录防护往往是让陌生网络根本到不了登录之前。

来源