谁在免密登录你的光伏电站？

2025年10月7日，安全研究员 Marlon Starkloff 公开披露 Sungrow（阳光电源）iSolarCloud 管理平台的一个严重认证绕过漏洞——不需要任何有效密码，就能登入普通用户甚至管理员账户。几乎同一时间窗口，Citrix NetScaler 正处于两个被确认在野利用的严重漏洞的处置周期中，客户网络陷入混乱。两件事指向同一个判断：关键基础设施的攻击面，正在从终端设备上移到管理平台与接入层，而认证，成了最薄的那块板。

“📋 信源与核查说明：本文涉及的关键事实均可通过公开渠道核实，包括 Starkloff 的原始披露博客与媒体的后续报道（TechCrunch 等）、Sungrow 对媒体的公开回应、Citrix 官方安全公告。原文所载“据多位人士”类不可核查的转述已删除或替换为可验证信息。iSolarCloud 漏洞截至披露时未分配 CVE 编号、无厂商官方 CVSS 评分，下文相关表述已据实修正。

🔓 一把万能钥匙：iSolarCloud 的免密登录

最危险的漏洞，往往不是被暴力破解出来的，而是被设计出来的。

10月7日，Marlon Starkloff 披露了 iSolarCloud 平台上的这个严重漏洞。它不是弱口令，不是撞库，而是一个业务逻辑缺陷：研究者可以在不携带有效密码的情况下，直接访问普通用户和管理员账户。从披露的技术细节看，问题出在登录流程的服务端校验环节——特定请求序列下，认证接口未正确验证口令，攻击者仅需掌握一个用户名（如注册邮箱或手机号），即可获得对应账户的有效会话。这正是 OWASP 在 API Security Top 10 中列首位的风险类型：失效的对象级授权（BOLA）——接口相信了“请求格式正确”，却没验证“请求者有权”。

更具冲击力的是影响范围——该缺陷波及 iSolarCloud 全部四个区域实例。换句话说，无论电站运营方在哪个区域接入这套平台，逻辑漏洞都是同一把钥匙。

iSolarCloud 是 Sungrow 光伏电站与储能资产的管理中枢，连着电站、逆变器、电池储能系统。认证被绕过，意味着攻击者理论上获得了对这些物理资产的未授权控制能力。从攻击链视角看，这是一条极短、极干净的路径：

⚠️ 值得注意的是，这类漏洞的利用成本极低。它不依赖零日武器化，不需要复杂的社会工程，只要平台逻辑存在缺陷，一组普通请求序列就可能完成越权。OWASP API Security Top 10（2023 版）连续多年将对象级授权失效列为 API 类风险第一位，原因与行业普遍观察一致：逻辑授权问题恰恰是自动化扫描器最不擅长覆盖的盲区，只能依靠人工测试与架构审计。

厂商状态：Sungrow 在媒体问询后公开回应称，相关缺陷已经修复，并表示未发现该漏洞被恶意利用的证据。但需要指出两点保留意见：其一，厂商未分配 CVE 编号、未公布 CVSS 评分，第三方与研究者的评级为“严重（Critical）”；其二，厂商未披露缺陷的具体技术细节与受影响版本范围，客户无法独立验证自身暴露面。修复透明度的欠缺，本身就是供应链风险的一部分。

产业判断：管理平台正在成为能源行业事实上的“总开关”。当发电资产通过云平台集中纳管，平台认证的强度就直接等同于电网边缘的物理防护强度。这不是 Sungrow 一家的问题，而是所有“设备上云”赛道共同的课。

⚡ 暴露的不只是账户：电站侧的攻击面清单

在能源行业，账号就是物理世界的遥控器。

把镜头拉远一点看，这次漏洞暴露的不只是一个登录接口，而是一整张正在快速扩张的攻击面：

过去十年，分布式光伏与储能装机高速增长，电站资产散布在屋顶、田间、戈壁。运营方不可能派人驻守每个站点，远程集中管理成了唯一现实选择。于是出现一个结构性矛盾：资产越分散，平台越集中；平台越集中，单点失陷的爆炸半径就越大。而运营方的设备台账与权限台账建设，普遍跟不上装机速度——资产清单不清，恰恰是认证绕过类漏洞杀伤力被放大的前提。这也是下文自查清单里“盘点”被排在最前位置的原因。

产业判断：能源行业的安全预算，过去主要投在厂区边界和工控终端上，而云端管理平台这一层，长期处在 IT 安全与 OT 安全的责任交界处，双方都默认对方在看。这次的漏洞提醒所有人：责任交界的缝隙，就是攻击者的入口。

🧨 同一周的另一场地震：NetScaler 的骨架钥匙

零日不可怕，可怕的是默认配置就把门敞开。

几乎在同一时间，Citrix 客户正经历一场另一种性质的混乱：NetScaler ADC 与 NetScaler Gateway 的两个严重漏洞被确认已在野利用——CVE-2025-5777（CVSS 9.2，输入校验缺陷导致会话令牌泄露，外界俗称"CitrixBleed 2"）与 CVE-2025-6543（CVSS 9.2，内存溢出可致控制流劫持）。用安全社区的比喻说，这两个漏洞给了攻击者一把“骨架钥匙”——不是撬开某一扇门，而是配得了整栋楼的通用钥匙：前者能直接带走合法用户的会话令牌，等于绕过认证“续用”别人的钥匙；后者则可能直接拿下设备控制权。

关键细节在于受影响场景覆盖了大量默认部署。这意味着受影响的不是少数配置失误的倒霉蛋，而是所有未及时升级的存量设备。Citrix 在官方安全公告中确认了在野利用，并给出两项核心处置要求：升级至指定修复版本；强制登出所有活动与挂起会话——这一点至关重要，因为 CVE-2025-5777 泄露的是会话令牌，仅仅升级版本不清除存量会话，攻击者手中的“旧钥匙”依然有效。

从资产属性看，NetScaler 属于应用交付与接入网关类设备，天然部署在网络边界、直接面向互联网，握着通往内网的会话与凭证。一旦失守，攻击者不需要再去“打穿”边界——门从里面就是开的。把两起事件放进同一个风险坐标系：

iSolarCloud 认证绕过落在“高影响、低处置难度”区——逻辑缺陷由厂商侧修复，客户侧动作其实很轻；NetScaler 双漏洞落在另一端——影响面大，且处置链条长：升级窗口要与业务停机窗口对齐，升级后还要强制清会话、排查是否已被入侵，客户要自己走完全程。这段“公告已发、补丁未落”的时间差，正是攻击者最活跃的窗口。

产业判断：边界设备的“默认安全”应该是产品责任，而不是客户的选修课。厂商把复杂配置留给用户，等于把安全决策权外包给了最不掌握全局的那一方。

🛠️ 把认证当物理门禁：给行业的五条清单

认证不是登录框的事，而是整个控制平面的地基。

两起事件一软一硬、一云一网，根因却惊人一致：身份层被击穿。对企业和厂商，防御动作可以拆成一张可执行的清单：

🔍 受影响用户自查与缓解步骤

清单之外，两类受影响用户可以立刻执行以下具体动作。

如果你是 iSolarCloud 用户：

1. 改密码：立即修改平台所有账户密码，包括管理员和普通运维账户；确认所在区域实例已完成厂商侧修复。

2. 查账户：导出平台账户清单，逐项核对——有多少管理员账户？哪些是离职或外包人员遗留的？全部停用或降权。

3. 开 MFA：为所有账户启用多因子认证，并优先对管理员账户强制执行。

4. 查日志：在平台可用日志范围内，核对近期登录记录中的异常 IP、异常时段登录、账户参数变更操作。

5. 验设备：抽查逆变器和储能系统的关键参数——出力上限、充放电策略、遥控权限——确认未被篡改。

6. 留证据：如发现可疑操作记录，先保存证据再处置，并同步联系 Sungrow 官方支持渠道与属地监管机构。

如果你是 NetScaler 用户：

1. 对版本：确认部署的是 NetScaler ADC 还是 NetScaler Gateway，以及具体版本与构建号，对照 Citrix 官方公告（CVE-2025-5777、CVE-2025-6543）判断是否在受影响范围内。

2. 打补丁：按公告升级至修复版本；无法立即升级的设备，采用 Citrix 公告中的临时缓解措施，并评估是否先将其从互联网暴露面摘除。

3. 清会话：升级完成后，必须强制登出所有活动与挂起会话——这是针对会话令牌泄露的关键动作，只升级不清会话等于白干。

4. 查痕迹：审计设备日志与会话记录，重点排查升级前的异常会话、异常认证请求与配置变更，判断是否已被利用。

5. 换凭证：按“已失陷”假设处理，轮换与设备关联的后端应用凭证、证书与 API 密钥。

6. 缩暴露：管理接口不应直接面向互联网，检查并收紧管理面访问来源。

📌 三点补充判断：

第一，对厂商。业务逻辑测试必须进入 SDL 主流程。四个区域实例同源共享一套认证逻辑，意味着一处设计失误就是全球性事故——这种架构下，逻辑审计的优先级应高于任何单点功能开发。同时，修复通报应当包含 CVE 编号、影响范围与验证方法：缺了这三样，客户永远无法确认自己是否安全。

第二，对客户。不要把“平台方会负责”当作默认假设。至少要能回答三个问题：我接入了哪些设备？哪些账户能控制它们？平台失守时，我能不能第一时间切断远程通道？

第三，对行业。能源、制造这类重资产行业的云平台安全评估，应该被纳入准入门槛，而不是事后补救。负责任披露流程的成熟度，直接决定了客户能赢得多大的处置窗口——这是采购时应该写入合同条款的要求，而不是事后才知道的信息。

小结

iSolarCloud 的免密登录和 NetScaler 的骨架钥匙，发生在两个看似不相干的领域，讲的其实是同一个故事：当物理世界的基础设施被搬上云和网，认证就成了数字与物理之间的那道门闩。往后看，随着能源资产继续大规模上云，管理平台的认证与授权设计将不再只是一个安全问题，而会变成产业准入问题。谁的门闩结实，谁才有资格握住电网的边缘。