CVE-2025-4275 — 已更新!
分析并利用 CVE-2025-4275（Hydr0ph0bia），这是一个 Secure Boot 信任链弱点，其中固件变量被用来引入攻击者控制的证书，而这些证书会被后续启动组件所信任。
🐞 CVE-2025-4275：Hydroph0bia SecureFlash 证书遮蔽
本仓库包含与 CVE-2025-4275 相关的研究资料，这是一个影响基于 Insyde H2O 的 UEFI 兼容固件的 Secure Boot 绕过漏洞。它集中了对该漏洞的技术分析、涉及该问题的二进制文件，以及旨在帮助研究人员在真实环境和教育场景中更好地理解、研究和实验该漏洞的文档和工具。
📑 目录
🧠 原始发现与官方参考
CVE-2025-4275 最初由 Nikolaj Schlej 发现并负责任地披露，协调工作通过 CERT/CC 进行。官方和社区参考：
- 研究员博客 - 第 1 部分（Secure Boot 绕过）
- 研究员博客 - 第 2 部分（DXE 卷接管）
- 研究员博客 - 第 3 部分（补丁分析）
- Insyde 官方公告（2025 年 6 月 10 日）
- 社区参考合集
🧪 漏洞概述（分析、利用、PoC）
CVE-2025-4275，被称为 Hydroph0bia（对 Insyde H2O 的双关语），是一个影响基于 Insyde H2O 平台构建的 UEFI 兼容固件的 Secure Boot 绕过漏洞。该漏洞源于固件更新子系统中的一个设计缺陷：一个本应由受信任驱动程序加载到易失性 NVRAM 变量中的签名证书，反而可以被攻击者预先填充为非易失性变量，导致固件将任意外部代码视为由 Insyde 自己签名一样信任。
使该漏洞特别具有影响力的是其简单性与影响范围的结合。利用该漏洞仅需要本地管理员权限，足以将文件写入 EFI 系统分区并创建 NVRAM 变量，并且影响任何运行 2025 年 6 月 10 日之前构建的 Insyde H2O 固件的系统。该攻击与 OEM 无关，意味着它广泛适用于 Acer、Dell、Framework、Fujitsu、HP、Huawei、Lenovo 以及任何其他提供基于 Insyde 固件的厂商。
🔐 Insyde H2O 中的 NVRAM 与 Secure Boot
UEFI 为非易失性变量存储提供了一个抽象接口，称为 NVRAM。该接口的一个长期存在的特性是，具有给定名称和 GUID 的非易失性变量可以与具有相同标识的易失性变量共存，并遮蔽后者。如果代码期望一个易失性变量（由受信任驱动程序在运行时创建），但具有相同名称的非易失性变量已经存在，则可能反而会使用非易失性版本。这种行为有时被称为 NVRAM 变量遮蔽，是该漏洞的基础。
Insyde H2O 的固件更新子系统依赖两个 NVRAM 变量在驱动程序之间传递签名证书：
- SecureFlashSetupMode：由 SecurityStubDxe 读取的触发变量，用于激活基于证书的验证。
- SecureFlashCertData：以 EFI_SIGNATURE_LIST 格式携带签名证书的变量，用于验证固件更新程序（isflash.bin）。
在预期的流程中，这两个变量在固件更新过程中由 BdsDxe 创建为易失性变量。然后 SecurityStubDxe 使用它们来验证 isflash.bin 是否由 Insyde 的证书签名，然后才允许其执行。关键缺陷在于 SecurityStubDxe 在信任这些变量的内容之前，不会验证它们是易失性还是非易失性。
💣 NVRAM 变量遮蔽
CVE-2025-4275 的根本原因在于 SecurityStubDxe 使用通用库函数来读取 SecureFlashSetupMode 和 SecureFlashCertData，而不是直接调用 GetVariable 运行时服务。这意味着它无法区分由受信任的 BdsDxe 设置的易失性变量和由攻击者预先填充的非易失性变量（关于此特定技术的详细解释，请参考以下仓库“TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing”）。
因此，具有本地管理员权限的攻击者可以：
- 在固件更新流程开始之前创建一个非易失性 SecureFlashSetupMode 触发变量。
- 创建一个包含攻击者控制的、以 EFI_SIGNATURE_LIST 格式表示的证书的非易失性 SecureFlashCertData 变量。
在下次启动时，SecurityStubDxe 将找到这两个变量，将它们视为合法，并信任任何使用攻击者证书签名的 UEFI 可执行文件，从而有效地完全绕过 Secure Boot。不需要固件级交互、硬件访问或利用内存破坏原语。攻击面仅仅是 UEFI NVRAM 写入接口，可从特权操作系统会话访问。
💥 发现与利用该漏洞
该漏洞是在对一台 HUAWEI MateBook 14 2023 进行安全审查时发现的，该设备运行基于 Insyde H2O 的固件，并启用了 Secure Boot、固件密码和其他现代安全功能。尽管有这些保护，仅使用操作系统级管理员权限就实现了完全利用。
初始利用阶段需要一个小型 Windows 工具（SFCD），它：
- 获取调用 SetFirmwareEnvironmentVariable 所需的 SeSystemEnvironmentPrivilege 特权。
- 创建包含攻击者控制的证书的非易失性 SecureFlashCertData 变量。
- 创建设置为 1 的非易失性 SecureFlashSetupMode 触发变量。
重启后，SecurityStubDxe 读取这两个变量，并开始信任任何由攻击者证书签名的内容。第一阶段的实践演示是加载一个使用自定义证书签名的 CrScreenshotDxe UEFI 驱动程序，它成功捕获了 BIOS 设置屏幕的截图，且 Secure Boot 处于启用状态，作为固件环境中任意代码执行的证明。
一个重要细节：存在于 CVE-2025-3052 中的 IhisiParamBuffer 变量在基于 Insyde 的平台上通常被锁定，使得在那里直接利用更加困难。CVE-2025-4275 不需要该变量可写，也不依赖任何内存破坏原语。该攻击适用于任何攻击者可以写入 NVRAM 的 Insyde H2O 系统，这是未打补丁固件上的默认行为。
🎯 攻击（第 1 部分 - Secure Boot 绕过）
以下描述了初始 Secure Boot 绕过阶段的端到端攻击，假设攻击者具有操作系统级访问权限：
- 生成自定义证书：攻击者生成密钥对，并将公钥证书包装为 EFI_SIGNATURE_LIST 格式。
- 设置 NVRAM 变量：使用来自 Windows 管理员会话的 SFCD 工具，攻击者创建非易失性 SecureFlashCertData（包含自定义证书）和 SecureFlashSetupMode（设置为 1）。
- 签名载荷：攻击者使用其自定义私钥对任何 UEFI 应用程序或驱动程序进行签名。
- 注册载荷：已签名的载荷通过 DriverXXXX 启动选项机制注册为 UEFI 驱动程序，或作为启动项放置在 UEFI 启动管理器中。
- 重启：在下次启动时，SecurityStubDxe 读取被遮蔽的 NVRAM 变量，信任攻击者的证书，并允许已签名的载荷执行，无论 Secure Boot 状态如何。
🔺 升级（第 2 部分 - DXE 卷接管）
第 1 部分中实现的 Secure Boot 绕过为影响更大的第二阶段打开了大门：通过劫持 Insyde 固件更新过程本身，实现对 DXE 卷的完全接管。
Insyde H2O 中的固件更新子系统工作如下：操作系统更新程序将固件胶囊和已签名的更新程序应用程序（isflash.bin）放置在 EFI 系统分区上，然后在 SecureFlashInfo NVRAM 变量内设置 SecureFlashTrigger=1 标志。在下次启动时，固件检测到触发器，在 PEI 期间禁用闪存写保护，并最终在根据 Insyde 证书验证 isflash.bin 后对其调用 LoadImage，而 CVE-2025-4275 允许攻击者替换的正是这一证书机制。
从 Secure Boot 绕过升级到 DXE 接管需要三个额外的技术步骤：
- 绕过 SecureFlashCertData 删除：SecureFlashDxe 在调用 LoadImage 之前尝试删除证书变量，使用一个裸 SetVariable 调用，该调用无法删除 Insyde Authenticated Write (AW) 特殊变量。攻击者将证书重新设置为具有 AW 属性的特殊变量，以在此删除尝试中存活。
- 解锁 InsydeVariableLock：VariableRuntimeDxe 设置一个全局标志（InsydeVariableLock），阻止在 BDS 启动后创建 AW 变量。通过 DriverXXXX 注册一个 UEFI 驱动程序（它在此锁启用之前运行），攻击者通过解析 BdsArchProtocol->Entry 钩子链在内存中定位该标志，并将其从 1 翻转为 0。
- 设置 SecureFlashInfo：SecureFlashInfo 变量通常受 VariableLockProtocol 保护，但此锁仅在 ReadyToBoot 时启用。通过 DriverXXXX 注册的驱动程序在此事件之前运行，可以自由设置 SecureFlashTrigger=1 以启动固件更新流程。
一旦满足所有三个条件，固件将重启进入更新模式，加载攻击者的自定义 isflash.bin（使用攻击者的证书签名，由于被遮蔽的 SecureFlashCertData 现在被信任），并在 SPI 闪存未受保护的情况下执行它。从这个位置，攻击者可以将任意内容写入 DXE 卷，安装持久性驱动程序或修改固件组件，从而在操作系统重装和大多数安全控制下存活。
🩹 修复（第 3 部分 - 补丁分析）
Insyde 作为 2025 年 6 月 10 日补丁周期的一部分发布了修复。通过使用 UEFITool 生成的报告和通过 Diaphora 进行二进制差异比较，对两个连续的 Dell BIOS 更新（一个补丁前，一个补丁后）进行了分析。
更改集中在三个驱动程序中：
- BdsDxe：将裸 gRT->SetVariable 调用（无法删除 AW 属性的特殊变量）替换为使用 SMM 通信且可以删除此类变量的 LibSetSecureVariable 调用。
- SecureFlashDxe：应用了相同的 LibSetSecureVariable 替换，在驱动程序入口点添加了对 SecureFlashSetupMode 和 SecureFlashCertData 的显式删除，并为这两个变量注册了 VariablePolicy 以阻止从操作系统级代码创建它们。
- SecurityStubDxe：对 `ExitBootServices 事件处理程序进行了轻微的不相关修复；核心漏洞路径在结构上保持不变。
该修复在攻击者无法绕过 VariablePolicy 或 LibSetSecureVariable 的假设下是有效的。然而，VariablePolicy 的默认 EDK2 实现内部使用一个全局标志，这在结构上类似于第 2 部分中被击败的 InsydeVariableLock。通过 SPI 编程硬件进行物理 NVRAM 编辑也将完全绕过该修复，尽管物理攻击通常不在 Secure Boot 威胁模型的范围内。
研究人员建议的补救措施，即从 BdsDxe 和 SecurityStubDxe 之间的证书中继机制中完全移除 NVRAM，已被 Insyde 尝试，但导致了回归，并被推迟到未来的工程周期。
📦 受影响的厂商
任何提供 2025 年 6 月 10 日之前构建的基于 Insyde H2O 固件的厂商都可能受到影响。披露时的确认状态：
| 厂商 | 状态 |
|---|---|
| Dell | 已修复 - 禁运结束后不久发布了 BIOS 更新 |
| Lenovo | 存在漏洞 - 已宣布修复，从 2025-07-30 起交付 |
| Framework | 存在漏洞 - 披露时未提供交付估计 |
| Acer | 披露时未发布公告或修复 |
| Fujitsu | 披露时未发布公告或修复 |
| HP | 披露时未发布公告或修复 |
| Huawei | 原始测试设备厂商 - 修复状态未知 |
🤝 研究与协作
正在做类似的事情？正在研究 UEFI、内核安全、漏洞利用或其他有趣的安全主题？如果你需要帮助开发漏洞利用、探索技术，或者只是想交流想法，请随时联系。我总是乐于讨论研究、尽我所能提供帮助，并在有趣的项目上进行协作。欢迎通过 LinkedIn 联系我。