使用CHIPSEC审计UEFI固件 是做什么的?
仅限授权使用: CHIPSEC会加载内核驱动并读写底层硬件寄存器、SPI闪存和SMM。仅可在您拥有或明确获得评估授权的系统上运行,最好在专用测试硬件上运行。误用(尤其是写/修改模块)可能导致设备变砖。切勿在生产系统上运行可写模块。
概述
CHIPSEC是Intel高级威胁研究团队创建的开源平台安全评估框架。它检查x86平台固件和硬件的底层安全配置——即操作系统之下、启动套件和固件植入物存活的层次。CHIPSEC加载一个签名的内核驱动(Linux、Windows,或从UEFI shell运行)来读写硬件寄存器、模型特定寄存器(MSR)、PCI配置空间、SPI闪存和UEFI变量,然后运行自动化测试套件检查平台的防御锁是否实际生效。
CHIPSEC应对的威胁是MITRE ATT&CK T1542.001——预操作系统启动:系统固件:攻击者修改系统固件(SPI闪存上的BIOS/UEFI镜像)以获得隐蔽、持久、可存活于操作系统的控制。固件植入物会跨越操作系统重装和磁盘更换而持续存在,且大多数EDR无法检测。CHIPSEC的价值在于验证阻止此类植入物所需的前提条件:SPI闪存BIOS区域是否写保护(BIOS_CNTL BLE/SMM_BWP、SPI保护范围)、闪存描述符是否锁定区域访问、SMRAM/SMRR是否配置,以及安全启动变量是否受保护。它还可以转储SPI闪存以进行离线取证比较。
来源:Intel/CHIPSEC项目 (https://github.com/chipsec/chipsec)、CHIPSEC文档 (https://chipsec.github.io/)。
何时使用
- 新笔记本电脑/服务器平台或镜像的基线固件安全评估
- 验证OEM是否正确启用了BIOS写保护和SPI闪存锁
- 固件取证:转储SPI闪存与已知良好镜像进行比较
- 验证安全启动变量保护和S3启动脚本保护
- 寻找固件植入物或可能允许植入物的配置错误的证据
前提条件
- 目标x86平台(Intel或AMD)的物理或管理员/root访问权限
- Linux(root)或Windows(管理员),或UEFI shell环境
- 能够加载内核驱动(安全启动可能需要允许CHIPSEC驱动,或使用
--no_driver进行有限检查) - Python 3.8+ 以及用于Linux内核模块的C编译器和构建工具
- 强烈建议使用专用测试硬件
安装CHIPSEC:
# 从PyPI安装
pip install chipsec
# 或从源码安装(构建内核助手/驱动)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install # 构建并安装,包括Linux驱动
# 验证
sudo chipsec_main --help
sudo chipsec_util --help
目标
- 运行完整的自动化平台安全测试套件并解释PASS/FAIL/WARNING结果
- 验证BIOS写保护(BIOS_CNTL)和SPI保护范围
- 验证SPI闪存描述符是否锁定区域读/写访问
- 验证SMRAM/SMRR和SMI处理程序保护
- 验证安全启动变量保护和S3启动脚本保护
- 转储SPI闪存并解码以进行离线分析
- 枚举UEFI变量并检测异常/意外条目
MITRE ATT&CK映射
| 技术ID | 名称 | 战术 |
|---|---|---|
| T1542.001 | 预操作系统启动:系统固件 | 持久化 / 防御规避 |
CHIPSEC通过验证防止未经授权固件修改的控制措施是否启用,从而防御T1542.001。如果common.bios_wp(BIOS未写保护)或chipsec.modules.common.spi_lock(闪存描述符未锁定)出现FAIL,意味着具有OS权限的攻击者可以重写SPI闪存并植入持久固件——这正是该技术的先决条件。
工作流程
步骤1:运行完整自动化测试套件
chipsec_main不带模块参数会针对检测到的平台运行所有适用的安全检查,并打印PASS/FAIL/WARNING/INFORMATION结果的摘要。
sudo chipsec_main
# 保存机器可读的输出以便报告/差异比较
sudo chipsec_main -j results.json -x results.xml -l chipsec.log
步骤2:单独运行核心固件保护模块
common模块组包含与OEM无关的安全检查。运行组或特定模块:
# 运行整个common组
sudo chipsec_main -m common
# BIOS写保护:检查BIOS_CNTL BLE/SMM_BWP和SPI保护范围
sudo chipsec_main -m common.bios_wp
# SPI闪存描述符锁(FLOCKDN)——闪存区域访问是否锁定?
sudo chipsec_main -m common.spi_lock
# SMRR编程——保护SMRAM免受基于缓存的攻击
sudo chipsec_main -m common.smrr
# SMM BIOS写保护
sudo chipsec_main -m common.smm
# S3恢复启动脚本保护(防止启动脚本表攻击)
sudo chipsec_main -m common.uefi.s3bootscript
步骤3:验证安全启动变量保护
# 检查安全启动UEFI变量是否得到适当保护
sudo chipsec_main -m common.secureboot.variables
# 主动测试变量的写保护(仅限测试硬件):
sudo chipsec_main -m common.secureboot.variables -a modify
步骤4:检查SPI闪存区域访问权限
# 报告SPI闪存区域、描述符和访问权限
sudo chipsec_util spi info
# 检查SPI访问控制模块
sudo chipsec_main -m common.spi_access
步骤5:转储SPI闪存以进行离线取证
转储闪存允许您解码固件卷并与已知良好的OEM镜像进行比较。
# 将整个SPI闪存转储到文件
sudo chipsec_util spi dump rom.bin
# 解码转储的镜像:提取固件卷、文件、NVRAM变量等。
sudo chipsec_util decode rom.bin
步骤6:枚举和分类UEFI变量
# 从运行时接口列出所有UEFI变量
sudo chipsec_util uefi var-list
# 直接从SPI镜像列出变量(离线)
sudo chipsec_util uefi var-find PK
sudo chipsec_util uefi var-read db <GUID> db.bin
# 解码UEFI固件结构
sudo chipsec_util uefi decode rom.bin
步骤7:无需内核驱动的有限评估
当无法加载驱动时(例如锁定状态的安全启动),某些检查仍可以只读方式运行。
sudo chipsec_main -n # --no_driver:跳过需要驱动的检查
sudo chipsec_main -p <PLATFORM> # 如果自动检测失败,强制指定平台代码
步骤8:分类结果并报告
- FAIL on
bios_wp/spi_lock→ 固件可从操作系统重写:T1542.001高风险。 - FAIL on
secureboot.variables→ 安全启动策略可能被篡改。 - 将
spi dump与OEM已知良好镜像(对固件卷进行哈希)比较,以检测未经授权的修改。 - 记录平台、BIOS版本以及每个FAIL/WARNING及其相关寄存器值,用于报告。
工具和资源
| 工具 | 用途 | 来源 |
|---|---|---|
| chipsec_main | 自动平台安全测试套件 | https://github.com/chipsec/chipsec |
| chipsec_util | 手动硬件/固件访问(spi、uefi、decode) | https://chipsec.github.io/ |
| UEFITool | GUI/CLI解析转储的UEFI镜像 | https://github.com/LongSoft/UEFITool |
| Binarly fwhunt | 固件漏洞/植入物检测规则 | https://github.com/binarly-io/fwhunt-scan |
| NSA UEFI安全启动指南 | 加固参考 | https://media.defense.gov/ |
核心模块参考
| 模块 | 检查内容 |
|---|---|
| common.bios_wp | BIOS_CNTL BLE / SMM_BWP 和 SPI 保护范围 |
| common.spi_lock | SPI闪存描述符 FLOCKDN |
| common.spi_access | SPI闪存区域读/写权限 |
| common.smrr | 系统管理范围寄存器编程 |
| common.smm | SMM BIOS写保护 |
| common.secureboot.variables | 安全启动变量保护 |
| common.uefi.s3bootscript | S3恢复启动脚本保护 |
验证标准
- CHIPSEC已安装且驱动加载(如果未加载则记录使用
-n的情况) - 已执行完整的
chipsec_main套件,并保存了JSON/XML/日志输出 - 已解释
common.bios_wp结果(写保护状态) - 已解释
common.spi_lock/spi_access结果(描述符锁) - 已记录SMRR/SMM模块结果
- 已检查安全启动变量保护
- 已转储并解码SPI闪存以进行离线分析
- 已枚举和分类UEFI变量
- 所有FAIL/WARNING发现已记录平台/BIOS版本
- 写/修改模块未在生产硬件上运行