Skip to content
KitploitKITPLOIT
工具博客
Log in
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

订阅源联系隐私© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
CVE-2026-52134-libiec61850 — 影响 libiec61850 v1.6 中 GOOSE 重放处理的 CVE-2026-52134 的公开技术通告与复现证据。 | Kitploit
工具/GitHubGitHub/if-forget/cve-2026-52134-libiec61850
漏洞分析SCADA/ICS安全网络安全学习与教育精选资源实验室与实践
GitHubif-forget/cve-2026-52134-libiec61850

CVE-2026-52134-libiec61850

影响 libiec61850 v1.6 中 GOOSE 重放处理的 CVE-2026-52134 的公开技术通告与复现证据。

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
查看仓库
172个月前尚未审核
分享

CVE-2026-52134:libiec61850 v1.6 中的 GOOSE 重放与消息新鲜度处理

状态

CVE-2026-52134 已被分配。相应 CVE 记录的发布尚待进行。

受影响产品

  • 厂商:MZ Automation GmbH
  • 产品:libiec61850
  • 已测试版本:1.6
  • 其他版本状态:未确认
  • 受影响文件:src/goose/goose_receiver.c
  • 受影响函数:parseGoosePayload()

摘要

libiec61850 v1.6 中的 GOOSE 订阅者接收路径在更新订阅者可见状态并调用已注册的监听器回调之前,未能充分拒绝某些重放或过期的 GOOSE 消息。

两项受控实验展示了同一接收路径中的相关行为:

  1. 较低 stNum 回滚: 在订阅者处理完 stNum=2 后,重放先前捕获的 stNum=1 帧会致使监听器再次报告较旧的状态和数据。
  2. 非递增 sqNum 重放: 当重放先前捕获的、具有相同 stNum 但较旧 sqNum 的帧时,该帧被标记为无效,但监听器回调仍会发生,且重放的数据依然可见。

这些是同一个重放/消息新鲜度处理问题的两个相关观察结果,而非两个独立的 CVE。

攻击先决条件

攻击者必须能够:

  • 访问相关的 IEEE 802.3 二层广播域或 VLAN
  • 捕获合法的 GOOSE 以太网帧
  • 使用 EtherType 0x88B8 注入以太网帧

这不是一种任意的、基于互联网的远程攻击。

技术依据

相关的接收逻辑在接收到的 stNum 与已存储的 stNum 相等时检查 sqNum。所测试的代码路径在订阅者状态更新和监听器被调用之前,不会拒绝较低的 stNum。

所测试的库文件未被修改。src/goose/goose_receiver.c 的原始副本和工作副本具有相同的 SHA-256 值:

c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b

源完整性检查

测试环境

  • Ubuntu 20.04.6 LTS
  • libiec61850 v1.6
  • Linux veth0 / veth1 隔离虚拟以太网对
  • tcpdump
  • TShark
  • Python 3 和 Scapy
  • 仅用作测试平台的已修改示例发布者和订阅者

该测试平台产生了受控的状态转换,并打印了回调可见的 stNum、sqNum、有效性和数据值。易受攻击的库文件本身未被修改。

实验 A:较低 stNum 回滚

基线

受控发布者发送了两种状态:

State A: stNum=1, sqNum=0, data=1111
State B: stNum=2, sqNum=0, data=2222

基线数据包捕获按以下顺序包含两个 GOOSE 帧:

Frame 1: stNum=1, sqNum=0
Frame 2: stNum=2, sqNum=0

基线字段与回调

订阅者输出还包含一个在状态 B 之前、针对 stNum=1, sqNum=0 的辅助回调,标记为 valid=false。该辅助回调保留在证据中,但不作为回滚结论的依据。决定性的重放前状态是稍后包含 stNum=2 和数据值 2222 的回调。

单次重放

重放脚本加载了两帧基线捕获,选择帧 1,并通过 veth0 发送了一次。

紧接重放之前,监听器已报告:

stNum=2, sqNum=0, valid=true, allData={2222}

旧帧被重放一次后,监听器报告:

stNum=1, sqNum=0, valid=true, allData={1111}

单次重放与 stNum 回滚

这表明在重放先前捕获的较低 stNum 帧后,观察到了订阅者状态从 stNum=2 回滚到 stNum=1。

额外的相同重放

另外发送了同一旧帧的四份副本。这四份均包含 stNum=1, sqNum=0。

后续副本被报告为 valid=false,但回调编号持续增加,且重放的数据仍然可见:

重复重放仍触发回调

这一次要观察表明,在受测接收路径中,将重复帧标记为无效并不能阻止监听器交付。

实验 B:非递增 sqNum 重放

较早的一次复现使用了官方示例发布者和订阅者。发布者生成以下正常序列:

stNum=1
sqNum=0, 1, 2, 3

在订阅者已经处理了后续序列值之后,重放了首次捕获的帧(stNum=1, sqNum=0)。

原始 sqNum 基线

由于接收到的 sqNum=0 并不比已存储的序列值更新,重放的副本被报告为无效。然而,订阅者继续打印包含重放数据的监听器事件:

原始 sqNum 重放回调

该实验支持一个范围更窄但相关的观察结果:

  • 通过有效性标志检测到了同状态重放。
  • 在受测示例中,检测并未阻止重放消息的回调交付。

原始的未处理重放截图保留作为支持材料:

  • 12-original-sqnum-replay-command-raw.png
  • 13-original-sqnum-replay-terminal-raw.png

这些原始图像包含无关的 Scapy 可选模块导入警告。这些警告并未阻止脚本报告捕获的 GOOSE 帧并完成传输,但为了查看技术结果,更倾向于使用上面较清晰的截图。

两个实验之间的关系

这两个实验展示了同一个 GOOSE 重放/消息新鲜度问题的不同分支:

观察项接收到的消息观察到的结果
较低 stNum 重放已存储 stNum=2;接收到旧的 stNum=1旧状态和数据被传递给监听器,并在受测运行中被报告为有效
非递增 sqNum 重放相同 stNum;接收到较旧或重复的 sqNum消息被报告为无效,但监听器回调和重放数据交付仍在继续

第一个观察结果是主要的 CVE 发现,因为它展示了从较新状态回滚到较旧状态。第二个观察结果是关于无效的同状态重放如何继续通过监听器路径的支持性证据。

观察到的影响

已证明的软件层面影响是:

  • 在较新状态已被处理之后,先前已接受的 GOOSE 状态仍可被传递给监听器。
  • 订阅者可见状态可以从较新的 stNum 变为较旧的 stNum。
  • 即使后续副本被报告为无效,重复的过期帧仍可继续引发监听器活动。

在没有独立的新鲜度强制措施的情况下消费回调数据的应用程序,可能会处理过期或重放的值。

下游影响取决于订阅者应用程序、配置、联锁逻辑和保护逻辑。

在这些实验中,未测试或操作任何物理保护继电器、跳闸回路、断路器或生产变电站网络。

建议的修复方向

在更新订阅者状态或调用监听器之前:

  1. 拒绝接收到的、早于最后接受的 stNum 的 stNum。
  2. 当 stNum 未改变时,拒绝非递增的 sqNum。
  3. 确保被归类为无效的帧不能覆盖最后接受的状态,也不能通过正常监听器路径传递过期数据。
  4. 在最终实现中考虑合法的重启、重新同步和计数器处理行为。

临时风险缓解措施

  • 限制对 GOOSE 以太网段和 VLAN 的访问。
  • 防止未经授权的设备注入二层帧。
  • 监控意外的 stNum 回滚和重复的 sqNum 值。
  • 在关键逻辑中使用回调值之前,验证订阅者数据的新鲜度。
  • 在生产部署之前,在隔离的实验室环境中测试更改。

支持性证据

以下图像提供来源和环境信息。它们支持复现,但并非理解主要结果所必需。

测试平台检查

测试平台检查

构建成功

构建成功

隔离的 veth 网络

隔离的 veth 网络

基线捕获摘要

基线捕获摘要

工件校验和

工件校验和

建议分类

  • 弱点:重放和消息新鲜度验证弱点
  • 建议的 CWE:CWE-294,通过捕获重放绕过身份验证

已证明的结果是重放接受和过期状态交付。它不依赖于证明受测部署中启用了加密身份验证。

参考资料

  • libiec61850 官方仓库
  • v1.6 树中的受影响源文件
  • CVE.org 上的 CVE-2026-52134

致谢

报告者:

  • Wang Jing
  • Li Chen Yu
  • Guo Lu Lu
  • Guo Jia Xin
  • Zhang Jia Tu
下载工具