シュレディンガーの信頼のブーツ。 インテルブートガード

私たちは、もう一度低レベルに戻って、ファームウェア x86 互換コンピューター プラットフォームのセキュリティについて話すことを提案します。 今回の研究の主な要素は、インテル ブート ガード (インテル BIOS ガードと混同しないでください!) です。これは、コンピューター システム ベンダーが製造段階で永続的にオンまたはオフにできる、ハードウェアでサポートされる BIOS トラステッド ブート テクノロジです。 そうですね、私たちはすでに研究のレシピを知っています。リバース エンジニアリングによってこのテクノロジーの実装を細かく切り出し、そのアーキテクチャを説明し、文書化されていない詳細を埋め込み、攻撃ベクトルで味付けして混ぜ合わせます。 数年にわたって複数のベンダーの製品にクローン化されたバグが原因で、潜在的な攻撃者がこのテクノロジを使用して、システム内に (プログラマであっても) 削除できない隠しルートキットを作成できるようになったという話で、さらに火を付けてみましょう。

ちなみにこの記事はカンファレンス「On Guard for Rootkits: Intel BootGuard」のレポートを基にしています。 ゼロナイツ 2016 そして29回目の会合 デフコンロシア (どちらのプレゼンテーションも ここで).

Intel 64 アーキテクチャを備えたコンピュータ プラットフォーム用のファームウェア

まず、「Intel 64 アーキテクチャを備えた最新のコンピューター プラットフォームのファームウェアは何ですか?」という質問に答えましょう。 もちろんUEFI BIOS。 しかし、この答えは正確ではありません。 このアーキテクチャのデスクトップ (ラップトップ) バージョンを示す図を見てみましょう。

リンクが基礎です:

• プロセッサー (CPU、中央処理装置)。メインコアに加えて、グラフィックスコア (すべてのモデルにあるわけではありません) とメモリーコントローラー (IMC、統合メモリーコントローラー) が組み込まれています。
• チップセット (PCH、プラットフォーム コントローラー ハブ)。周辺デバイスと対話し、サブシステムを管理するためのさまざまなコントローラーが含まれています。 その中には、悪名高いインテル マネジメント エンジン (ME) もあり、これにもファームウェア (インテル ME ファームウェア) があります。

ラップトップには、上記に加えて、電源サブシステム、タッチパッド、キーボード、Fn キー (画面の明るさ、音量、キーボード) の操作を担当する統合コントローラー (ACPI EC、アドバンスト コントロールおよび電源インターフェイス組み込みコントローラー) が必要です。バックライトなど）。）など。 そして彼は独自のファームウェアも持っています。

したがって、上記のファームウェアを組み合わせたものがコンピュータ プラットフォームのファームウェア (システム ファームウェア) となり、一般的な SPI フラッシュ メモリに保存されます。 このメモリのユーザーがどこに誰かが横たわっているのか混乱しないように、このメモリの内容は次の領域に分割されています (図に示すように)。

• UEFI BIOS;
• ACPI EC ファームウェア (Skylake プロセッサ マイクロアーキテクチャ (2015) では別の領域が登場しましたが、実際にはその使用例がまだ確認されていないため、組み込みコントローラー ファームウェアは依然として UEFI BIOS の一部です)。
• インテル ME ファームウェア。
• 内蔵 GbE (ギガビット イーサネット) ネットワーク アダプターの設定 (MAC アドレスなど)。
• フラッシュ記述子 - フラッシュ メモリのメイン領域。他の領域へのポインタと、それらへのアクセス許可が含まれます。

領域へのアクセスの区別 (指定された許可に従って) は、SPI バス マスター (チップセットに組み込まれた SPI コントローラー) によって処理され、これを通じてこのメモリにアクセスします。 アクセス許可が Intel によって推奨される値 (セキュリティ上の理由) に設定されている場合、各 SPI フラッシュ ユーザーは自分のリージョンに対してのみフル アクセス (読み取り/書き込み) を持ちます。 残りは読み取り専用であるかアクセスできません。 既知の事実: 多くのシステムでは、CPU は UEFI BIOS および GbE への完全なアクセス権を持ち、フラッシュ記述子への読み取りアクセスのみがあり、Intel ME 領域にはまったくアクセスできません。 なぜ全員ではなく多くの人がいるのですか？ 推奨されるものはオプションです。 詳細については、記事の後半で説明します。

コンピュータ プラットフォームのファームウェアを変更から保護するメカニズム

明らかに、コンピュータ プラットフォームのファームウェアは、潜在的な攻撃者がそこに足場を築き（OS の更新や再インストールに耐える）、最も特権モードでコードを実行するなどの可能性がある侵害から保護される必要があります。 もちろん、SPI フラッシュ メモリ領域へのアクセスを制限するだけでは十分ではありません。 したがって、ファームウェアを変更から保護するために、各実行環境に固有のさまざまなメカニズムが使用されます。

そのため、インテル ME ファームウェアは完全性と信頼性の制御のために署名されており、ME UMA メモリにロードされるたびに ME コントローラーによってチェックされます。 この検証プロセスについては、次のいずれかの記事ですでに説明しました。 物品インテル ME サブシステム専用。

また、ACPI EC ファームウェアは、原則として、整合性のみがチェックされます。 ただし、このバイナリは UEFI BIOS に含まれているため、ほとんどの場合、UEFI BIOS が使用するのと同じ保護メカニズムの対象になります。 それらについて話しましょう。

これらのメカニズムは XNUMX つのカテゴリに分類できます。

UEFI BIOS 領域への書き込み保護

1. 書き込み保護ジャンパによる SPI フラッシュ メモリの内容の物理的保護。
2. チップセットの PRx レジスタを使用した、CPU アドレス空間内の UEFI BIOS 領域の投影の保護。
3. ブロックでは、チップセット レジスタの BIOS_WE / BLE および SMM_BWP ビットを設定して、対応する SMI 割り込みを生成および処理することにより、UEFI BIOS 領域への書き込みを試行します。
4. この保護のより高度なバージョンは、Intel BIOS Guard (PFAT) です。

これらのメカニズムに加えて、ベンダーは独自のセキュリティ対策を開発および実装できます (たとえば、UEFI BIOS アップデートによるカプセルへの署名)。

特定のシステム (ベンダーによって異なります) では、上記の保護メカニズムのすべてが適用されるわけではない、まったく適用されない、または脆弱な方法で実装されている可能性があることに注意することが重要です。 これらのメカニズムとその実装状況について詳しくは、「 この記事。 興味のある方は、UEFI BIOS セキュリティに関する一連の記事をすべて読むことをお勧めします。 コードラッシュ.

UEFI BIOS 認証の検証

トラステッド ブート テクノロジについて話すとき、最初に思い浮かぶのはセキュア ブートです。 ただし、アーキテクチャ的には、ファームウェア自体ではなく、UEFI BIOS の外部のコンポーネント (ドライバー、ローダーなど) を認証するように設計されています。

したがって、Intel は、Bay Trail マイクロアーキテクチャ (2012) を備えた SoC に、ハードウェアの切り替え不可能なセキュア ブート (検証済みブート) を実装しました。これは、前述のセキュア ブート テクノロジとは何の関係もありません。 その後 (2013 年)、このメカニズムは改良され、Intel Boot Guard という名前で、Haswell マイクロアーキテクチャを備えたデスクトップ用にリリースされました。

Intel Boot Guard について説明する前に、Intel 64 アーキテクチャの実行環境を見てみましょう。これらの組み合わせが、このトラステッド ブート テクノロジの信頼のルートとなります。

インテルのCPU

Cap 氏は、プロセッサーが Intel 64 アーキテクチャーの主要な実行環境であると示唆していますが、なぜそれが信頼のルートでもあるのでしょうか? その理由は、次の要素を備えているためであることがわかりました。

• マイクロコード ROM は、マイクロコードを保存するための不揮発性で書き換え不可能なメモリです。 マイクロコードは、最も単純な命令に対するプロセッサ命令システムの実装であると考えられています。 マイクロコードでも発生します バグ。 そのため、BIOS では、マイクロコード更新を含むバイナリを見つけることができます (ROM は上書きできないため、バイナリは起動時に重ねて表示されます)。 これらのバイナリの内容は暗号化されているため、分析が非常に複雑になり (したがって、マイクロコードの具体的な内容は開発者のみに知られます)、完全性と信頼性を制御するために署名されます。
• マイクロコード更新の内容を復号化するための AES キー。
• マイクロコード更新の署名を検証する RSA 公開キーのハッシュ。
• RSA 公開キー ハッシュ。Intel が開発した ACM (Authenticated Code Module) コード モジュールの署名をチェックします。このコード モジュールは、BIOS の開始前 (Hello マイクロコード) または BIOS の動作中に、何らかのイベントが発生したときに CPU が実行できます。

インテル ME

私たちのブログのこのサブシステムは、 две 記事。 この実行可能環境は、チップセットに組み込まれたマイクロコントローラーに基づいており、システム内で最も隠蔽され、特権が与えられているということを思い出してください。

ステルス性にもかかわらず、インテル ME は以下の機能を備えているため、信頼のルートでもあります。

• ME ROM - 開始コードとインテル ME ファームウェアの署名をチェックする RSA 公開キーの SHA256 ハッシュを含む不揮発性、書き換え不可能なメモリ (更新方法は提供されていません)。
• 秘密情報を保存するための AES キー。
• コンピュータ システム ベンダーによって指定された情報を含む、一部の情報を永続的に保存するためにチップセットに統合された一連のヒューズ (FPF、フィールド プログラマブル ヒューズ) へのアクセス。

インテル ブート ガード 1.x

小さな免責事項。 この記事で使用するインテル ブート ガード テクノロジのバージョン番号は任意であり、インテルの内部ドキュメントで使用されている番号とは関係がない場合があります。 さらに、ここに記載されているこのテクノロジーの実装に関する情報は、リバース エンジニアリング中に取得されたものであり、公開される可能性が低いインテル ブート ガードの仕様と比較して不正確な部分が含まれている可能性があります。

つまり、Intel Boot Guard (BG) は、ハードウェアでサポートされる UEFI BIOS 認証テクノロジです。 書籍 [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot] の短い説明から判断すると、これは信頼できるブート チェーンとして機能します。 その最初のリンクは CPU 内のブート コード (マイクロコード) で、RESET イベントによってトリガーされます (BIOS の RESET ベクターと混同しないでください)。 CPU は、SPI フラッシュ メモリ上でインテルによって開発および署名されたコード モジュール (インテル BG スタートアップ ACM) を見つけ、それをキャッシュにロードして検証します (CPU が ACM 署名を検証する公開キー ハッシュを持っていることは上ですでに述べました) ）そして始まります。

このコード モジュールは、UEFI BIOS の小さな開始部分である初期ブート ブロック (IBB) を検証する役割を果たします。これには、UEFI BIOS の主要部分を検証するための機能が含まれています。 したがって、Intel BG を使用すると、OS を起動する前に BIOS の信頼性を検証できます (これはセキュア ブート テクノロジの監視下で実行できます)。

インテル BG テクノロジーは XNUMX つの動作モードを提供します (一方は他方と干渉しません。つまり、システム上で両方のモードを有効にすることも、両方を無効にすることもできます)。

メジャーブーツ

メジャード ブート (MB) モードでは、各ブート コンポーネント (CPU ブート ROM から始まる) は、トラステッド プラットフォーム モジュール (TPM) の機能を使用して次のコンポーネントを「測定」します。 知らない人のために説明しましょう。

TPM には PCR (プラットフォーム構成レジスタ) があり、次の式に従ってハッシュ操作の結果を記録します。

それらの。 現在の PCR 値は前の値に依存し、これらのレジスタはシステムがリセットされた場合にのみリセットされます。

したがって、MB モードでは、ある時点で、PCR は「測定」されたコードまたはデータの一意の (ハッシュ操作の機能内で) 識別子を反映します。 PCR 値は、一部のデータの暗号化 (TPM_Seal) 操作に使用できます。 その後、ロードの結果として PCR 値が変更されていない場合 (つまり、「測定された」コンポーネントが XNUMX つも変更されていない場合) にのみ、それらの復号化 (TPM_Unseal) が可能になります。

確認済みの起動

UEFI BIOS を変更したい人にとって最も怖いのは、各ブート コンポーネントが次のブート コンポーネントの整合性と信頼性を暗号的に検証する検証ブート (VB) モードです。 検証エラーが発生した場合、(次のいずれか) が発生します。

• 1 分から 30 分のタイムアウトによってシャットダウンします (ユーザーが自分のコンピュータが起動しない理由を理解する時間を確保し、可能であれば BIOS の復元を試みます)。
• 即時シャットダウン（ユーザーが理解する時間がなく、さらに実行する時間がないため）。
• 真顔で作業を継続する（他にやるべきことがあり、安全を確保する時間がない場合）。

アクションの選択は、指定されたインテル BG 構成 (つまり、いわゆる強制ポリシー) によって決まります。この構成は、コンピューター プラットフォーム ベンダーによって特別に設計されたストレージであるチップセット ヒューズ (FPF) に永続的に記録されます。 この点については後ほど詳しく説明します。

構成に加えて、ベンダーは 2048 つの RSA XNUMX キーを生成し、XNUMX つのデータ構造を作成します (図を参照)。

1. ベンダー ルート キー マニフェスト (KEYM、OEM ルート キー マニフェスト)。このマニフェストの SVN (セキュリティ バージョン番号)、次のマニフェストの公開キーの SHA256 ハッシュ、RSA 公開キー (つまり、ベンダー ルート キー) を使用して、このマニフェストの署名と署名自体を検証します。
2. IBB マニフェスト (IBBM、初期ブート ブロック マニフェスト)。このマニフェストの SVN、IBB の SHA256 ハッシュ、このマニフェストの署名を検証するための公開キー、および署名自体が含まれます。

OEM ルート キーの SHA256 ハッシュは、Intel BG 構成と同様に、チップセット ヒューズ (FPF) に永続的に書き込まれます。 Intel BG 構成にこのテクノロジを含めることができる場合、今後、このシステムでは、OEM ルート キーのプライベート部分の所有者のみが BIOS を更新できます (つまり、これらのマニフェストを再計算できます)。 ベンダー。

この図を見ると、これほど長い検証チェーンの必要性についてすぐに疑問が生じます。マニフェストを XNUMX つ使用することもできたはずです。 なぜ複雑になるのでしょうか？

実際、インテルは、ベンダーに対し、異なる製品ラインに異なる IBB キーを使用し、XNUMX つをルートとして使用する機会を提供します。 IBB キーのプライベート部分 (XNUMX 番目のマニフェストに署名する) が漏洩した場合、そのインシデントは XNUMX つの製品ラインにのみ影響し、ベンダーが新しいペアを生成し、次回の BIOS アップデートで再計算されたマニフェストを有効にするまでのみ影響します。

ただし、ルート キー (最初のマニフェストの署名に使用されたキー) が侵害された場合、それを置き換えることはできず、失効手順は提供されません。 このキーの公開部分のハッシュは、FPF に完全にプログラムされます。

インテル ブート ガードの構成

ここで、Intel BG の構成とその作成プロセスを詳しく見てみましょう。 インテル システム ツール キット (STK) のフラッシュ イメージ ツールの GUI の対応するタブを見ると、インテル BG 構成にベンダー ルート キーの公開部分のハッシュが含まれていることがわかります。価値観など。 インテル BG プロファイル。

このプロファイルの構造は次のとおりです。

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

一般に、Intel BG 構成は非常に柔軟なエンティティです。 たとえば、Force_Boot_Guard_ACM フラグを考えてみましょう。 これをクリアすると、SPI フラッシュ上で BG 起動 ACM モジュールが見つからない場合、トラステッド ブートは実行されません。 それは信頼できなくなります。

検証が失敗した場合に再び信頼できないダウンロードが発生するように、VB モードの強制ポリシーを構成できることは上ですでに書きました。

こういう事は業者さんに任せてしまいましょう…

このユーティリティの GUI には、次の「既製の」プロファイルが用意されています。

いいえ。
政権
説明

0
いいえ_FVME
インテル BG テクノロジーが無効になっています

1
VE
VB モード有効、タイムアウトによるシャットダウン

2
VME
両方のモード (VB と MB) が有効になっており、タイムアウトによってシャットダウンされます。

3
VM
システムをオフにすることなく、両方のモードが有効になります

4
FVE
VB モード有効、即時シャットダウン

5
FVME
両方のモードが有効、即時シャットダウン

すでに述べたように、Intel BG 構成は、システム ベンダーによってチップセット ヒューズ (FPF) に一度だけ書き込まれる必要があります。FPF は、チップセット内の小さな (未検証の情報によると、わずか 256 バイト) ハードウェア情報ストレージであり、外部でプログラムすることができます。インテルの生産施設の フィールドプログラマブル ヒューズ）。

次の理由から、構成を保存するのに最適です。

• ワンタイムプログラム可能なデータストレージ領域 (Intel BG 構成が書き込まれる場所) を備えています。
• Intel ME だけがそれを読み取ってプログラムすることができます。

したがって、特定のシステム上でインテル BG テクノロジーの構成を設定するために、ベンダーは運用中に次のことを行います。

1. Flash Image Tool ユーティリティ (Intel STK の) を使用して、Intel ME 領域 (FPF のいわゆる一時ミラー) 内の変数として、特定の Intel BG 構成を持つファームウェア イメージを作成します。
2. フラッシュ プログラミング ツール (Intel STK 製) を使用して、このイメージをシステムの SPI フラッシュ メモリに書き込み、いわゆるファイルを閉じます。 製造モード (この場合、対応するコマンドがインテル ME に送信されます)。

これらの操作の結果、インテル ME は、ME 領域の FPF のミラーから指定された値を FPF にコミットし、SPI フラッシュ記述子のアクセス許可をインテルが推奨する値に設定します (本書の冒頭で説明)記事) を実行し、システム リセットを実行します。

Intel Boot Guard 実装の分析

特定の例でのこのテクノロジーの実装を分析するために、次のシステムでインテル BG テクノロジーの痕跡を確認しました。

システム
注意

ギガバイトGA-H170-D3H
Skylake、サポートがあります

ギガバイト GA-Q170-D3H
Skylake、サポートがあります

ギガバイト GA-B150-HD3
Skylake、サポートがあります

MSI H170A ゲーミング プロ
Skylake、サポートなし

Lenovo ThinkPad 460
Skylake、サポートが利用可能、テクノロジーが有効

レノボヨガ2プロ
ハスウェル、サポートなし

レノボU330p
ハスウェル、サポートなし

「サポート」とは、インテル BG スタートアップ ACM モジュール、上記のマニフェスト、および BIOS 内の対応するコードの存在を意味します。 分析用の実装。

例として、オフィスからダウンロードしたものを見てみましょう。 Gigabyte GA-H170-D3H (バージョン F4) の SPI フラッシュ メモリのベンダー サイトのイメージ。

インテルCPUブートROM

まず最初に、インテル BG テクノロジーが有効になっている場合のプロセッサーの動作について説明します。

復号化されたマイクロコードのサンプルを見つけることはできませんでした。したがって、以下で説明するアクションがどのように (マイクロコードまたはハードウェアで) 実装されるかは未解決の問題です。 それにもかかわらず、最新の Intel プロセッサがこれらのアクションを「実行できる」という事実は事実です。

RESET 状態を終了した後、プロセッサ (そのアドレス空間にはフラッシュ メモリの内容がすでにマップされています) は FIT (ファームウェア インターフェイス テーブル) を見つけます。 それを見つけるのは簡単です。それへのポインタはアドレス FFFF FFC0h に書き込まれます。

この例では、このアドレスには値 FFD6 9500h が含まれています。 このアドレスに目を向けると、プロセッサは FIT テーブルを参照します。その内容はレコードに分割されています。 最初のエントリは、次の構造の見出しです。

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

何らかの理由で、これらのテーブルではチェックサムが常に計算されるわけではありません (フィールドは null のままです)。

残りのエントリは、BIOS が実行される前に解析/実行する必要があるさまざまなバイナリを指します。 従来の RESET ベクトル (FFFF FFF0h) に切り替える前に。 このような各エントリの構造は次のとおりです。

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

EntryType フィールドは、このエントリが指すブロックのタイプを示します。 私たちはいくつかのタイプを知っています:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

これで、エントリの XNUMX つがインテル BG スタートアップ ACM バイナリの場所を指していることは明らかです。 このバイナリのヘッダー構造は、インテルが開発したコード モジュール (ACM、マイクロコード アップデート、インテル ME コード セクションなど) に典型的なものです。

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

プロセッサはこのバイナリをキャッシュにロードし、検証して起動します。

インテル BG スタートアップ ACM

この ACM の動作を分析した結果、次のことを行うことが明らかになりました。

• チップセット ヒューズ (FPF) に書き込まれたインテル BG 構成をインテル ME から受信します。
• KEYM および IBM マニフェストを検索し、検証します。

これらのマニフェストを見つけるために、ACM は FIT テーブルも使用します。このテーブルには、これらの構造を指す XNUMX 種類のエントリがあります (上記の FIT_ENTRY_TYPES を参照)。

マニフェストを詳しく見てみましょう。 最初のマニフェストの構造には、いくつかの不明瞭な定数、XNUMX 番目のマニフェストの公開キーのハッシュ、およびネストされた構造として署名された公開 OEM ルート キーが表示されます。

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

OEM ルート キーの公開キーを検証するには、ヒューズからの SHA256 ハッシュが使用されることを思い出してください。このハッシュは、現時点ではすでに Intel ME から受信されています。

第二のマニフェストに移りましょう。 これは XNUMX つの構造で構成されます。

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

最初のものにはいくつかの定数が含まれています。

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

256 番目には、IBB の SHAXNUMX ハッシュと、IBB の内容 (つまり、ハッシュの計算元) を記述する記述子の数が含まれています。

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB 記述子はこの構造に従います。 コンテンツの形式は次のとおりです。

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

それは簡単です。各記述子には IBB チャンクのアドレス/サイズが含まれています。 したがって、これらの記述子によって指定されるブロックを (記述子自体の順序で) 連結したものが IBB です。 また、原則として、IBB は SEC フェーズと PEI フェーズのすべてのモジュールを組み合わせたものです。

256 番目のマニフェストは、IBB 公開キー (最初のマニフェストの SHAXNUMX ハッシュによって検証される) とこのマニフェストの署名を含む構造で終わります。

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

そのため、UEFI BIOS の実行が開始される前であっても、プロセッサは ACM を起動し、SEC および PEI フェーズ コードを使用してセクションの内容の信頼性を検証します。 次に、プロセッサは ACM を終了し、RESET ベクトルに沿って移動し、BIOS の実行を開始します。

PEI 検証済みパーティションには、BIOS の残りの部分 (DXE コード) をチェックするモジュールが含まれている必要があります。 このモジュールは、IBV (Independent BIOS Vendor) またはシステム ベンダー自体によってすでに開発されています。 なぜならLenovo と Gigabyte システムのみが自由に使用でき、Intel BG をサポートしていることが判明しました。これらのシステムから抽出されたコードを考えてみましょう。

UEFI BIOS モジュール LenovoVerifiedBootPei

Lenovo の場合、Lenovo が開発した LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} モジュールであることが判明しました。

その仕事は、(GUID によって) DXE のハッシュ テーブルを検索し、DXE を検証することです。

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS モジュール BootGuardPei

Gigabyte の場合、これは AMI によって開発された BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} モジュールであることが判明したため、Intel BG をサポートするすべての AMI BIOS に存在します。

動作アルゴリズムは多少異なりますが、要するに同じです。

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

検索するハッシュ テーブル {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} の形式は次のとおりです。

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

インテル ブート ガード 2.x

Intel Boot Guard の別の実装について簡単に説明します。これは、Apollo Lake マイクロアーキテクチャを備えた Intel SoC に基づく新しいシステム、ASRock J4205-IT に組み込まれています。

このバージョンは SoC でのみ使用されますが (Kaby Lake プロセッサ マイクロアーキテクチャを備えた新しいシステムは引き続き Intel Boot Guard 1.x を使用します)、Intel SoC に基づくプラットフォームの新しいアーキテクチャ オプションを検討する上で非常に興味深いものであり、これは具体的なものとなっています。変更例:

• BIOS および Intel ME 領域 (Intel SoC の用語によれば、むしろ Intel TXE) は、XNUMX つの IFWI 領域になりました。
• Intel BG はプラットフォームで有効になっていましたが、FIT、KEYM、IBBM などの構造がフラッシュ メモリ内に見つかりませんでした。
• TXE および ISH コア (x86) に加えて、電源サブシステムの操作性の確保とパフォーマンス監視に関連する XNUMX 番目のコア (ちなみに、これも ARC) がチップセットに追加されました - PMC (電源管理コントローラー)。

新しい IFWI リージョンのコンテンツは、次のモジュールのセットです。

オフセット
名前
説明

0000時間
SMIP
ベンダーによって署名された一部のプラットフォーム構成

0000時間
RBEP
Intel TXE ファームウェア コード セクション (x86、Intel によって署名)

0001時間
PMCP
ファームウェア コード セクション Intel PMC、ARC、Intel による署名

0002時間
FTPR
Intel TXE ファームウェア コード セクション (x86、Intel によって署名)

0007B000h
ユーコッド
Intel によって署名された CPU マイクロコードの更新

0008時間
IBBP
UEFI BIOS、SEC/PEI フェーズ、x86、ベンダー署名済み

0021時間
ISC
ベンダーによって署名されたインテル ISH ファームウェア x86 のコード セクション

0025時間
FTP
Intel TXE ファームウェア コード セクション (x86、Intel によって署名)

0036時間
IUNP
未知数

0038時間
OBBP
UEFI BIOS、DXE フェーズ、x86、未署名

TXE ファームウェアの分析中に、RESET 後、CPU のアドレス空間の基本的な内容 (FIT、ACM、RESET ベクトルなど) を準備するまで、TXE がプロセッサをこの状態に維持することが明らかになりました。 さらに、TXE はこのデータを SRAM に配置し、その後一時的にプロセッサにそこへのアクセスを提供し、RESET から「解放」します。

ルートキットを警戒する

さて、次は「ホット」に移りましょう。 私たちはかつて、多くのシステムで SPI フラッシュ記述子が SPI フラッシュ メモリの領域にアクセスする権限を持っていることを発見しました。そのため、このメモリのすべてのユーザーは任意の領域に書き込みと読み取りの両方を行うことができます。 それらの。 とんでもない。

MEinfo ユーティリティ (Intel STK 製) で確認したところ、これらのシステムの製造モードが閉じられていないため、チップセット ヒューズ (FPF) が不定の状態のままになっていることがわかりました。 はい、そのような場合、Intel BG は有効にも無効にもなりません。

ここでは次のシステムについて説明します (Intel BG とこの記事で後述する内容については、Haswell プロセッサ マイクロアーキテクチャ以上のシステムについて説明します)。

• すべてのギガバイト製品。
• すべての MSI 製品。
• 21 台の Lenovo ラップトップ モデルと 4 台の Lenovo サーバー モデル。

もちろん、私たちはこの発見をインテルだけでなくこれらのベンダーにも報告しました。

からのみ適切な対応が行われます。 レノボ誰が問題を認めたのか、そして パッチをリリースしました.

ギガバイト 脆弱性に関する情報は受け入れたようだが、特にコメントはしなかった。

とのコミュニケーション MSI (暗号化されたセキュリティ勧告を送信するため) PGP 公開キーを送信するという私たちの要求により、完全に停止してしまいました。 彼らは「自社はハードウェアメーカーであり、PGP キーを製造しているわけではない」と述べています。

しかし、もっと重要なことです。 ヒューズは未定義の状態のままであるため、ユーザー (または攻撃者) が自分でヒューズをプログラムできます (最も難しいのは インテル STK を見つける）。 これには次の手順が必要です。

1. Windows OS を起動します (一般に、目的の OS 用の Intel STK の類似物を開発している場合は、以下で説明する手順を Linux からも実行できます)。 MEinfo ユーティリティを使用して、このシステムのヒューズがプログラムされていないことを確認します。

2. フラッシュ プログラミング ツールを使用してフラッシュ メモリの内容を読み取ります。

3. 任意の UEFI BIOS 編集ツールを使用して読み取ったイメージを開き、必要な変更を加え (ルートキットの実装など)、ME 領域内の既存の KEYM および IBBM 構造を作成/編集します。

画像では RSA キーの公開部分が強調表示されており、そのハッシュはインテル BG 構成の残りの部分とともにチップセット ヒューズにプログラムされます。

4. Flash Image Tool を使用して、(Intel BG 構成を設定することにより) 新しいファームウェア イメージを構築します。

5. フラッシュ プログラミング ツールを使用して新しいイメージをフラッシュに書き込み、MEinfo を使用して ME 領域にインテル BG 構成が含まれていることを確認します。

6. フラッシュ プログラミング ツールを使用して、製造モードを閉じます。

7. システムが再起動した後、MEinfo を使用して、FPF がプログラムされたことを確認できます。

これらのアクション 永遠に このシステムでインテル BG を有効にします。 アクションを元に戻すことは不可能になります。これは、次のことを意味します。

• ルート キーのプライベート部分の所有者 (つまり、Intel BG を有効にした人) だけが、このシステムの UEFI BIOS を更新できます。
• たとえばプログラマを使用して元のファームウェアをこのシステムに戻しても、電源が入りません (検証エラーが発生した場合の強制ポリシーの結果)。
• このような UEFI BIOS を削除するには、プログラムされた FPF を備えたチップセットを「クリーンな」チップセットと交換する必要があります (つまり、車の価格で赤外線はんだ付けステーションを利用できる場合はチップセットを再はんだ付けするか、マザーボードを交換するだけです) ）。

このようなルートキットで何ができるかを理解するには、UEFI BIOS 環境でのコードの実行を可能にするものを評価する必要があります。 たとえば、プロセッサの最も特権のあるモードである SMM で考えます。 このようなルートキットには次の特性がある場合があります。

• OS と並行して実行されます (タイマーによってトリガーされる SMI 割り込みを生成することで処理を構成できます)。
• SMM モードの利点をすべて備えています (RAM およびハードウェア リソースの内容へのフル アクセス、OS からの秘密保持)。
• ルートキット コードは、SMM モードで起動すると暗号化および復号化できます。 SMM モードでのみ利用可能なデータはすべて暗号化キーとして使用できます。 たとえば、SMRAM 内の一連のアドレスからのハッシュです。 このキーを取得するには、SMM に入る必要があります。 これは XNUMX つの方法で実行できます。 SMM コードで RCE を見つけてそれを悪用するか、独自の SMM モジュールを BIOS に追加します。Boot Guard が有効になっているため、これは不可能です。

したがって、この脆弱性により、攻撃者は次のことを行うことができます。

• システム内に目的不明の削除不可能な隠されたルートキットを作成します。
• Intel SoC 内のチップセット コアの XNUMX つ、つまり Intel ISH でコードを実行します (図をよく見てください)。

Intel ISH サブシステムの機能はまだ調査されていませんが、Intel ME に対する興味深い攻撃ベクトルであるようです。

所見

1. この調査では、Intel Boot Guard テクノロジがどのように機能するかに関する技術的な説明が提供されました。 インテルのセキュリティー・スルー・オブスキュリティ・モデルにはいくつかの秘密があります。
2. システム内に削除不可能なルートキットを作成できる攻撃シナリオが示されています。
3. 最新の Intel プロセッサは、BIOS が起動する前でも多くの独自コードを実行できることがわかりました。
4. Intel 64 アーキテクチャを備えたプラットフォームは、ハードウェア検証、独自のテクノロジとサブシステム (SoC チップセットの 86 つのコア: x86 ME、xXNUMX ISH、および ARC PMC) の増加など、フリー ソフトウェアの実行にはますます適していません。

緩和

意図的に製造モードを開いたままにするベンダーは、必ずそれを閉じるべきです。 これまでのところ、彼らは目を閉じているだけであり、新しい Kaby Lake システムはそれを示しています。

ユーザーは、-closemnf オプションを指定してフラッシュ プログラミング ツールを実行することにより、システム (記載されている脆弱性の影響を受ける) で Intel BG を無効にすることができます。 まず、(MEinfo を使用して) ME 領域のインテル BG の構成が、FPF でのプログラミング後にこのテクノロジーを正確にオフにするように提供されていることを確認する必要があります。

出所： habr.com