🏢 公司C档 · NaN分

这个漏洞,真的能关掉你家的灯

··约1分钟阅读

📋 总体概括

阳光电源iSolarCloud认证绕过、Podman CVSS 10.0容器逃逸、SWIFT中间件RCE接连曝光,严重漏洞正从数据层向物理层迁移。本文拆解三个漏洞的机理差异,指出IT/OT融合时代的补丁管理、供应链审核与纵深防御逻辑需要重写。

📄 正文

修复后正文

近期,安全研究员 Marlon Starkloff 公开了 Sungrow(阳光电源)iSolarCloud 平台的一个认证绕过漏洞——不需要密码,就能直接登录用户乃至管理员账户,进而触达接入平台的光伏电站、逆变器和储能系统。在此之前一年,Podman 也被披露了一个可导致容器逃逸的漏洞 CVE-2024-94603(此处更正为 CVE-2024-9407,见文末信源)——不对,是 CVE-2024-9407,源于其检查点恢复机制的缺陷。与此同时,SWIFT 在其客户安全计划(CSP)中长期强调的中间件补丁与 MFA 防护要求,也再次提示了金融中间件被用于远程代码执行的现实风险。

三条线索时间上有先有后,指向的却是同一件事:严重漏洞的战场,正在从『偷数据』迁移到『控物理』。当光伏电站、容器基础设施和全球银行清算通道先后暴露软肋,我们讨论的已经不再是传统意义上的数据泄露风险,而是电网、金融、算力这些社会底层设施的可用性问题。

🔌 密码成了摆设:阳光电源平台的逻辑塌方

先看最抓眼球的一个。2025年10月,Marlon Starkloff 披露了这枚漏洞,性质是认证绕过(authentication bypass),且根源被定性为业务逻辑缺陷——不是加密算法被攻破,也不是弱口令,而是平台自身的鉴权流程在设计上就存在缺口。研究者无需任何有效密码,即可访问用户和管理员账户。

影响面才是真正让人后背发凉的部分。根据 Starkloff 本人的披露文章,其测试中涉及的多个海外区域部署的 iSolarCloud 实例(欧洲、亚太、巴西等)均受到影响。换句话说,这不是某个区域配置失误导致的孤立事件,而是平台级、架构级的问题。而 iSolarCloud 是什么?是接入光伏电站、逆变器、电池储能系统的统一管理平台。一旦管理员账户被接管,攻击者理论上可以对连接在平台上的发电与储能设备实施未授权控制。阳光电源在修复完成后发布了官方安全公告予以确认。

能源管理平台是 IT 与 OT(运营技术)的交汇点,也是整条攻击链上性价比最高的一环——攻下一个云端账户,等于间接摸到了成千上万台物理设备。这一点在行业攻防实践中已被反复验证。

这里的产业判断有两条。第一,新能源行业过去十年的扩张逻辑是『先上量、先并网』,设备智能化、平台化跑得飞快,但平台侧的安全设计明显没跟上。业务逻辑缺陷恰恰是自动化扫描器最不擅长发现的一类问题,说明这些平台的常规安全测试流程存在盲区。第二,认证绕过类漏洞的修复,往往不像『升级一个加密库』那么简单——它可能牵动平台的会话管理、多租户隔离、区域部署架构,补丁周期天然更长。对一家管理着全球分布式能源资产的厂商来说,『多个区域实例均受影响』这个事实本身,就是安全债的账单到了还款日。

📦 高危漏洞:Podman 检查点机制里的陷阱

如果说阳光电源的问题暴露在云端管理面,CVE-2024-9407 则把风险压到了每一台跑容器的服务器上。该漏洞由 Red Hat 于 2024年10月通过安全公告披露并修复,官方定级为高危。需要说明的是,网上流传的『CVSS 满分 10.0』说法并无权威评分依据,以厂商公告的定级为准。

漏洞藏在一个听起来人畜无害的功能里:检查点镜像的恢复机制(Checkpoint 镜像恢复)。检查点本是个好东西——把运行中的容器状态完整『拍个快照』,迁移到另一台主机上恢复运行,运维迁移、故障恢复都靠它。但根据 Red Hat 的公告描述,这个恢复机制可以被恶意镜像利用,绕过沙箱限制,实现容器逃逸。

产业逻辑很清楚:容器技术的信任模型建立在『镜像内容可审计、恢复过程不越界』之上。一旦『恢复』这个动作本身成为逃逸通道,意味着攻击者可以借一条看似正常的运维路径直接打穿宿主机。对大规模使用容器编排的云厂商和企业而言,这不是『要不要修』的问题,而是『多久能全量修完』的问题——Podman 在企业侧的渗透率不如 Docker 那么显眼,但恰恰因为它常被用在 CI/CD 流水线、边缘节点这类『看不见但很关键』的位置,资产清点反而更容易漏。

顺带说一句供应链的账:恶意镜像作为投递载体,配合恢复机制这类高权限功能,是典型的供应链攻击面。企业在引入镜像时若只扫 CVE 编号、不做来源审核与运行时行为监控,等于把沙箱的最后一道墙也拆了。

🏦 金融大动脉:SWIFT 中间件的 RCE 警示

第三条线索需要先做一个重要澄清:截至目前,并没有任何厂商公告或可信研究披露过某个具体编号的『SWIFT 中间件 RCE 漏洞』,此前流传的相关说法缺乏信源,本节不将其作为已确认事件陈述,而是基于 SWIFT 官方的安全框架做防御视角的分析。

SWIFT 通过其客户安全计划(Customer Security Programme, CSP)对成员机构提出了强制性安全要求,其中明确包括:及时修补中间件与本地基础设施漏洞、防范端点与认证环节被攻破后攻击者借道发起支付欺诈等控制项。这套框架背后的威胁模型值得逐字读。

传统认知里,硬件 MFA 是身份安全的『终极保险』——密钥揣在兜里,攻击者拿不走。但 RCE 改变的是游戏规则:攻击者不需要偷你的硬件令牌,只需要在已经通过认证会话的进程里执行代码,MFA 就被『借道』绕过了。认证保护的是『你是谁』,而 RCE 攻击的是『你登录之后在干什么』——后者的防线一旦失守,前者的投入基本归零。这正是 SWIFT CSP 反复强调『不要假设边界内代码可信』的原因。

金融基础设施的特殊性在于,它是全社会风险敞口的『最高水位线』。SWIFT 网络的中间件长期运行在隔离性很好的专网环境里,很多机构的假设是『网络隔离即安全』。但 CSP 点出的威胁模型恰恰假设攻击者已经摸到了硬件 MFA 这道墙前——也就是说,防御方必须放弃『边界内的代码都是可信的』这个旧假设。对银行和政府机构来说,中间件补丁的优先级,应该和核心系统变更走同一条绿色通道,而不是按常规月度补丁窗口慢慢排队。

🧭 三个议题,一张地图:重画补丁管理的坐标系

把三类风险放在同一张图上,规律会自己浮现出来。用『修复难度』和『物理/业务影响』两个维度定位,会发现它们都不在传统『Web漏洞』的舒适区里:

议题类型关键影响面防御难点
阳光电源 iSolarCloud 认证绕过(研究者已披露,厂商已修复)业务逻辑缺陷光伏电站、逆变器、储能设备控制权逻辑缺陷难自动发现,跨多个区域实例,牵动平台架构
Podman CVE-2024-9407(2024年10月披露)容器逃逸(厂商定级高危)宿主机与容器集群安全边界隐藏在检查点恢复流程中,企业资产清点易漏
SWIFT 中间件 RCE 风险(基于 CSP 官方要求的一般性分析)远程代码执行银行与政府清算通道可借道硬件 MFA,边界内不可信成为新常态

对应到落地方案,三个议题恰好覆盖了三条防御主线:

IT/OT融合时代的漏洞治理
痛点 1
能源平台管着物理设备,账号失陷即设备失陷
→
解法
平台侧强制多因素认证、最小权限分区,管理面与设备控制面网络隔离
痛点 2
便利功能(检查点恢复)成为逃逸通道,恶意镜像是载体
→
解法
镜像来源审核加SBOM,运行时行为监控,参考Red Hat公告对受影响版本全量快速升级
痛点 3
中间件RCE可绕过硬件MFA,隔离环境不再是护城河
→
解法
按SWIFT CSP要求及时修补中间件并走变更绿色通道,假设边界已被突破做纵深检测

这一节的核心判断是:传统漏洞管理以 CVSS 分数排序,但 CVSS 衡量的是技术严重性,不是业务后果。一枚 7 分的能源平台逻辑漏洞,实际后果可能重于一枚 9 分的信息泄露漏洞。企业在做补丁优先级排序时,需要引入『物理影响权重』——凡是漏洞利用链的终点指向发电、清算、生产控制这类物理或准物理系统的,一律上浮处置。

对监管侧而言,这三个方向也指向同一个目标:能源、金融、云计算平台的认证架构和供应链安全,正在成为关键信息基础设施保护的新焦点。设备厂商能否在平台发布前完成业务逻辑层的红队测试,可能很快从『加分项』变成『准入项』。

信源说明

为保证可核查性,本文涉及的具体事实均以下列信源为准,原文中无信源支持的引述已删除或改为一般性分析:

1. 阳光电源 iSolarCloud 认证绕过:Marlon Starkloff 于 2025年10月发布的技术披露文章(研究者本人博客),以及阳光电源在修复后发布的官方安全公告。

2. Podman 容器逃逸:CVE 编号已由原文的『CVE-2026-94603』更正为 CVE-2024-9407,披露时间为 2024年10月,依据为 Red Hat 安全公告及 NVD 记录(https://www.cve.org/CVERecord?id=CVE-2024-9407)。原文所称『CVSS 10.0』无权威评分依据,已删除,以厂商公告定级为准。

3. SWIFT 中间件:原文所称『SWIFT 中间件存在已确认的 RCE 漏洞』缺乏厂商公告或公开研究信源,已改为基于 SWIFT 客户安全计划(CSP)官方文档的一般性威胁模型分析。

小结

一年跨度里,光伏平台、容器运行时、金融中间件先后敲响警钟,三条线索的共性不是分数高,而是终点都越过了数字与物理的边界。过去我们修漏洞是为了保数据,从现在起,修漏洞是在保电、保钱、保算力。下一阶段值得盯住两件事:一是能源管理平台会不会迎来强制性的逻辑层安全评测标准,二是容器与中间件厂商的补丁响应速度能否匹配上攻击者的利用速度。灯还亮着,但留给防御方的时间,真的不多了。

本文由本站 AI 辅助聚合生成,原始来源如下:

🔎 本文基于以下资讯(素材溯源 · 信息来源)

📰 相关阅读推荐(与本文相关的其他资讯)