CHIPSECを用いたUEFIファームウェア監査 は何をしますか?
許可された使用のみ: CHIPSECはカーネルドライバをロードし、低レベルのハードウェアレジスタ、SPIフラッシュ、SMMを読み書きします。所有しているシステム、または明示的に評価を許可されたシステムでのみ実行し、理想的には専用のテストハードウェアを使用してください。誤用(特に書き込み/変更モジュール)はマシンを文鎮化させる可能性があります。本番システムでは書き込み可能なモジュールを決して実行しないでください。
概要
CHIPSECは、Intelの高度脅威研究チームによって作成されたオープンソースのプラットフォームセキュリティ評価フレームワークです。これは、x86プラットフォームのファームウェアとハードウェアの低レベルセキュリティ構成(ブートキットやファームウェアインプラントが潜むOSより下のレイヤー)を検査します。CHIPSECは、署名されたカーネルドライバ(Linux、Windows、またはUEFIシェルから実行可能)をロードして、ハードウェアレジスタ、モデル固有レジスタ(MSR)、PCIコンフィグスペース、SPIフラッシュ、UEFI変数を読み書きし、プラットフォームの防御ロックが実際に有効になっているかをチェックする自動テストスイートを実行します。
CHIPSECが対処する脅威は、MITRE ATT&CK T1542.001 — プリOSブート:システムファームウェアです。攻撃者がシステムファームウェア(SPIフラッシュ上のBIOS/UEFIイメージ)を変更して、ステルスで永続的なOSを生き延びる制御を獲得する脅威です。ファームウェアインプラントはOS再インストールやディスク交換後も存続し、ほとんどの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/)。
使用すべき状況
- 新しいラップトップ/サーバープラットフォームまたはフリートイメージのベースラインファームウェアセキュリティ評価
- BIOS書き込み保護とSPIフラッシュロックがOEMによって正しく有効化されていることの確認
- ファームウェアフォレンジック:既知の良品イメージと比較するためのSPIフラッシュのダンプ
- セキュアブート変数保護とS3ブートスクリプト保護の検証
- ファームウェアインプラント、またはそれを可能にする設定ミスの証拠の探索
前提条件
- ターゲットのx86プラットフォーム(IntelまたはAMD)への物理的、あるいは管理者/rootアクセス
- Linux(root)またはWindows(管理者)、あるいはUEFIシェル環境
- カーネルドライバをロードできること(セキュアブートが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 | プリOSブート:システムファームウェア | 永続化 / 防御回避 |
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→ ファームウェアがOSから書き換え可能: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 | ダンプされた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/log出力が保存されている -
common.bios_wpの結果が解釈されている(書き込み保護の状態) -
common.spi_lock/spi_accessの結果が解釈されている(ディスクリプタロック) - SMRR/SMMモジュールの結果が記録されている
- セキュアブート変数保護がチェックされている
- SPIフラッシュがダンプされ、オフライン分析用にデコードされている
- UEFI変数が列挙され、トリアージされている
- すべてのFAIL/WARNINGの所見がプラットフォーム/BIOSバージョンとともに文書化されている
- 書き込み/変更モジュールが本番ハードウェアで実行されていない