auditing-uefi-firmware-with-chipsec

CHIPSEC による UEFI ファームウェアの監査

許可された用途のみ： CHIPSEC はカーネルドライバーを読み込み、低レベルのハードウェアレジスター、SPI フラッシュ、SMM の読み書きを行います。所有しているシステム、または評価を明示的に許可されたシステムでのみ実行してください。可能であれば、専用のテスト用ハードウェアを使用してください。誤用（特に書き込み／変更モジュールの使用）によって、マシンが起動不能になる可能性があります。本番システムでは、書き込み可能なモジュールを絶対に実行しないでください。

概要

CHIPSEC は、Intel の Advanced Threat Research チームが開発したオープンソースの プラットフォームセキュリティ評価フレームワークです。x86 プラットフォームのファームウェアとハードウェアの低レベルのセキュリティ設定を検査します。ここはオペレーティングシステムの下層に位置し、ブートキットやファームウェアインプラントが潜む領域です。CHIPSEC は署名済みのカーネルドライバーを読み込み（Linux、Windows、または UEFI シェルから実行可能）、ハードウェアレジスター、モデル固有レジスター（MSR）、PCI コンフィグレーション空間、SPI フラッシュ、UEFI 変数を読み書きします。その後、自動テストスイートを実行し、プラットフォームの防御用ロックが実際に有効になっているかを確認します。

CHIPSEC が対処する脅威は、MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware です。これは、システムファームウェア（SPI フラッシュ上の BIOS／UEFI イメージ）を改変し、検出されにくく、永続的で、OS の再インストール後も存続する制御を得ようとする攻撃者を指します。ファームウェアインプラントは、OS の再インストールやディスクの交換後も残存し、ほとんどの EDR からは見えません。CHIPSEC の価値は、こうしたインプラントを防ぐための 前提条件 を検証できることです。具体的には、SPI フラッシュの BIOS 領域が書き込み保護されていること（BIOS_CNTL の BLE／SMM_BWP、SPI 保護範囲）、フラッシュディスクリプターが領域へのアクセスをロックしていること、SMRAM／SMRR が設定されていること、Secure Boot 変数が保護されていることを確認します。また、オフラインでのフォレンジック比較用に SPI フラッシュをダンプします。

ソース：Intel／CHIPSEC プロジェクト（https://github.com/chipsec/chipsec）、CHIPSEC ドキュメント（https://chipsec.github.io/）。

使用する場面

• 新しいラップトップ／サーバープラットフォームまたはフリートイメージのファームウェアセキュリティのベースライン評価
• BIOS 書き込み保護と SPI フラッシュロックが OEM によって正しく有効化されていることの確認
• ファームウェアのフォレンジック：SPI フラッシュをダンプし、既知の正常なイメージと比較
• Secure Boot 変数の保護と S3 ブートスクリプトの保護の検証
• ファームウェアインプラントの痕跡、またはインプラントを可能にする設定ミスの捜索

前提条件

• 対象の x86 プラットフォーム（Intel または AMD）への物理アクセス、または管理者／root 権限
• Linux（root）または Windows（Administrator）、もしくは UEFI シェル環境
• カーネルドライバーを読み込めること（Secure Boot で CHIPSEC ドライバーの読み込みを許可する必要がある場合があります。または、限定的なチェックには --no_driver を使用してください）
• Python 3.8 以降、および Linux 上でカーネルモジュールをビルドするための C コンパイラー／ビルドツール
• 専用のテスト用ハードウェアを強く推奨

CHIPSEC をインストールします：

# From PyPI
pip install chipsec

# Or from source (builds the kernel helper/driver)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install        # builds and installs, including the Linux driver

# Verify
sudo chipsec_main --help
sudo chipsec_util --help

目標

• プラットフォームセキュリティの自動テストスイートをすべて実行し、PASS／FAIL／WARNING を解釈する
• BIOS 書き込み保護（BIOS_CNTL）と SPI 保護範囲を検証する
• SPI フラッシュディスクリプターが領域への読み書きアクセスをロックしていることを検証する
• SMRAM／SMRR と SMI ハンドラーの保護を検証する
• Secure Boot 変数の保護と S3 ブートスクリプトの保護を検証する
• SPI フラッシュをダンプし、デコードしてオフライン分析を行う
• UEFI 変数を列挙し、異常なエントリーや予期しないエントリーを検出する

MITRE ATT&CK との対応

テクニック ID	名前	戦術
T1542.001	Pre-OS Boot: System Firmware	永続化／防御回避

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

# Save machine-readable output for reporting / diffing
sudo chipsec_main -j results.json -x results.xml -l chipsec.log

ステップ 2：ファームウェア保護の中核モジュールを個別に実行する

common モジュールグループには、OEM に依存しないセキュリティチェックが含まれています。グループ全体または特定のモジュールを実行します。

# Run the whole common group
sudo chipsec_main -m common

# BIOS write protection: checks BIOS_CNTL BLE/SMM_BWP and SPI protected ranges
sudo chipsec_main -m common.bios_wp

# SPI flash descriptor lock (FLOCKDN) — are flash region accesses locked?
sudo chipsec_main -m common.spi_lock

# SMRR programming — protects SMRAM from cache-based attacks
sudo chipsec_main -m common.smrr

# SMM BIOS write protection
sudo chipsec_main -m common.smm

# S3 resume boot-script protection (against bootscript table attacks)
sudo chipsec_main -m common.uefi.s3bootscript

ステップ 3：セキュアブート変数の保護を検証する

# Checks that Secure Boot UEFI variables are properly protected
sudo chipsec_main -m common.secureboot.variables

# To actively test write protection of the variables (test hardware ONLY):
sudo chipsec_main -m common.secureboot.variables -a modify

ステップ 4：SPI フラッシュ領域のアクセス権限を調査する

# Report SPI flash regions, descriptor, and access permissions
sudo chipsec_util spi info

# Check the SPI access-control module
sudo chipsec_main -m common.spi_access

ステップ 5：オフラインフォレンジック用に SPI フラッシュをダンプする

フラッシュをダンプすると、ファームウェアボリュームをデコードし、既知の正常な OEM イメージと比較できます。

# Dump the entire SPI flash to a file
sudo chipsec_util spi dump rom.bin

# Decode the dumped image: extracts firmware volumes, files, NVRAM variables, etc.
sudo chipsec_util decode rom.bin

ステップ 6：UEFI 変数を列挙してトリアージする

# List all UEFI variables from the runtime interface
sudo chipsec_util uefi var-list

# List variables directly from the SPI image (offline)
sudo chipsec_util uefi var-find PK
sudo chipsec_util uefi var-read db <GUID> db.bin

# Decode the UEFI firmware structure
sudo chipsec_util uefi decode rom.bin

ステップ 7：カーネルドライバーを使わずに限定的な評価を行う

ドライバーを読み込めない場合（ロックダウンされたセキュアブート環境など）でも、一部のチェックは読み取り専用で実行できます。

sudo chipsec_main -n            # --no_driver: skip checks that need the driver
sudo chipsec_main -p <PLATFORM> # force platform code if auto-detect fails

ステップ 8：結果をトリアージして報告する

• bios_wp／spi_lock が FAIL → OS からファームウェアを書き換えられるため、T1542.001 の高リスクに該当します。
• secureboot.variables が FAIL → セキュアブートポリシーが改ざんされるおそれがあります。
• spi dump を OEM の既知の正常なイメージと比較し（ファームウェアボリュームのハッシュを確認）、不正な改変を検出します。
• レポートには、プラットフォーム、BIOS バージョン、および関連するレジスター値を添えて、すべての FAIL／WARNING を記録します。

ツールとリソース

ツール	目的	ソース
chipsec_main	プラットフォームセキュリティの自動テストスイート	https://github.com/chipsec/chipsec
chipsec_util	ハードウェア／ファームウェアへの手動アクセス（spi、uefi、decode）	https://chipsec.github.io/
UEFITool	ダンプした UEFI イメージの GUI／CLI 解析	https://github.com/LongSoft/UEFITool
Binarly fwhunt	ファームウェアの脆弱性／インプラントを検出するルール	https://github.com/binarly-io/fwhunt-scan
NSA UEFI Secure Boot guidance	強化のためのリファレンス	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 変数を列挙してトリアージした
• プラットフォーム／BIOS バージョンを添えて、すべての FAIL／WARNING の検出結果を記録した
• 書き込み／変更モジュールを本番ハードウェアで実行していない