UEFIセキュリティパート5

短い休憩の後、UEFIセキュリティについて引き続き説明します。 今回は、SecureBootテクノロジー、その長所と短所、その攻撃とそれらに対する保護について説明します。



2011年に初めてUEFI 2.2規格にSecureBootが導入されましたが、2012年の初めにすべての側面がバージョン2.3.1Cで実装されました。 この技術の主な開発者はマイクロソフトであり、 Windows 8 Ready証明書を受け取るには、まだリリースされていない新しいOSの場合、すべての新しいPCにデフォルトでSecureBootを実装して含める必要があるとすぐに述べました。 この声明は、フリーソフトウェアの支持者から鋭い批判の波を引き起こしました。

MSとコミュニティとの対立がどのように終わったか、SecureBootがほぼ4年の成長を遂げた後にどのように見えるか、そしてどんな種類の攻撃がまだ可能かについて興味がある場合は、catへようこそ。



止めて、私はほとんど忘れていました：良い伝統によると、それらをスキップすることができた人々のために、前の 部分 へ の リンクの セット 。

パート5 セキュアブート

それは何ですか？

Habréに関する12件の記事を読んだ後、SecureBootについて詳しく説明する価値があるとは思いません。これは、私なしですでに何度も行われています。 それでも、このトピックに不慣れな読者に対しては、まったく何も言わないことは犯罪になります。そこで私たちは2階に行き、すべてを知りたいすべての人を仕様に送ります。



SecureBootは、UEFI互換ファームウェアが外部コンポーネント（ブートローダー、ドライバー、およびUEFI OptionROM）の信頼性を検証できるソフトウェアテクノロジーです。 これらの実行可能コンポーネントは、起動時にチェックされる電子デジタル署名で署名する必要があり、完全に存在しない、破損している、信頼できるリストに存在しない（ db ）、または禁止リストに存在する（ dbx ）場合、対応するコンポーネントは起動しません（この動作が構成されている場合もあります）トリックをするかもしれませんが、それについては後で詳しく説明します）。 現在、EDSアルゴリズムとして、標準ではRSA2048とSHA256の組み合わせを推奨しています。RSA2048とSHA256は、生きているシステムで見たほとんどすべてのシステムで使用されています。

キーについて少し

SecureBootは次のキー階層を使用します。











上部にあるPKは、プラットフォームユーザーとそのファームウェア間の信頼を確立するメインキーです。 RSAキーと同様に、 PKpub公開キーとPKpriv秘密キーで構成され、 自己署名証明書としてNVRAMに保存されます。 仕様は、 プラットフォーム所有者によってPKprivプライベートパートの所有者と呼ばれる理由がないわけではありません。



必要なセキュリティレベルに応じて、PKは次のように生成できます。

• 各PCの独自のキー。 最大限のセキュリティ、キー管理による最大のhemo核ですが、リークは実際にはひどくありません。また、リークしたキーでシステムを侵害しても、隣接するキーを侵害することにはなりません。
• 各モデルマットの共通キー。 ボード。 安全性は劣りますが、特に艦隊が同じボード上で組み立てられている場合、保守が容易です。
• 各ラインマットの共通キー。 回路基板。 前の段落と同じように、セキュリティは少し低くなりますが、利便性は少し高くなりますが、セキュリティと利便性のトレードオフの典型的なケースです。
• すべてのメーカーのボードに共通のキー。 セキュリティに関して最もばかげていますが、同時に、残念なことに、ほとんどの最も一般的なソリューションです。 キーはソースツリーに直接保存され、キーと共にリークします。その後、このメーカーのボード上のSecureBootはもはや障害になりません。 同時に、発生源はほとんどの場合静かに漏れ、製造業者は明らかに脆弱な製品を数年間生産する可能性があります。

最初、PKはプラットフォームの製造元によって生成され、それ自体は実行可能コンポーネントの署名と署名の検証には関与しませんが、 KEKキーストアの管理に使用されます。 KEKpriv仕様の所有者は、 許可されたユーザーを呼び出します 。 各KEKキーは、実行可能コンポーネントのメーカーとファームウェアの間に信頼関係を確立します。 これらのキーは、dbストレージ（実行が許可されているコンポーネントの証明書とハッシュ）を見つけ、dbx（KEKpriv所有者が正しい署名にもかかわらず実行を禁止する必要があるコンポーネントの証明書とハッシュを入力できる場所）を管理するために使用されます。

ここで最初の王は誰ですか？

ほとんどのSecureBoot構成では、PKはデフォルトで製造者によって提供されます。 ボード、KEKはMicrosoft Corporation KEK CA 2011の唯一の証明書を持ち、dbはMicrosoft Windows Production CA 2011証明書を持っている必要がありますが、ファームウェアを更新するためのさまざまなユーティリティに署名したCanonical証明書とプラットフォームメーカーからの証明書を追加することもあります ほとんどのシステムのdbxリポジトリは空ですが、それほど前ではありませんが、MSはその中にいくつかのエントリを作成し、Windows 10 Ready証明書を取得するために新しいシステムでそれらを要求するようになりました。 デフォルト構成のSecureBootの観点から見ると、メーカーがシステムの所有者であることがわかります。 ボード、およびその唯一の承認されたユーザーはマイクロソフトです。 幸いなことに（そして、ほとんどの場合、オープンソースソフトウェアコミュニティのプレッシャーのため）、x86システムの大部分のこの悲しい情景は、標準キーを削除し、BIOSセットアップから自分のキーを追加することで破壊できますが、これについては別に書きます。

CSMとの非互換性

SecureBootは互換性がないため、 CSMと組み合わせて有効にしないでください。 CSMなしでは起動できない古いOSを引き続き使用する場合、SecureBootは役に立ちません。 最も興味深いのは、MSがまだWindows 7にGOPサポートを追加することを望まず、CSMなしでこのOSをロードすることはまったく機能しないか、盲目的に行われることです。これにより、ユーザーが独立してWindows 7をSecureBootと互換性のないものにすることはほぼ確実です彼女のブートローダーに署名します。 企業セグメントでのWindows 7のシェアは、新しいオペレーティングシステムのシェアをはるかに超えているため、SecureBootが有効になっているシステムは、実際に役立つ場所ではまだあまり人気がありません。

SecureBootへの攻撃

ベクターについて

最初に、SecureBootのどの部分が攻撃される可能性があり、攻撃の成功が何を脅かすかを正確に理解する必要があります。

• NVRAM PK、KEK、db、dbx、およびSecureBootに関連する他の変数はNVRAMに保存されるため、攻撃が成功すると、ほとんどの場合、SecureBootが無効または危険にさらされます。
• 実装。 NVRAMで問題がなければ、署名の検証、キーストレージなどの実装に問題がある可能性があります。
• キー。 攻撃は複雑で単純です。 必要なことは、信頼チェーンから誰かの秘密キーを盗み、それで悪意のあるブートローダーに署名することです。
• 信頼できるブートローダー。 前の段落よりもさらに単純です。特に、dbのCanonical証明書所有者の場合。 現在のブートローダを、Ubuntuリポジトリからの前述のGRUB2証明書で署名されたものに変更するだけで、あらゆる種類のマルウェアがダウンロードされます。

実際に攻撃する

PKを削除してSecureBootを無効にする

攻撃者がNVRAMリポジトリへの書き込みアクセス権を持っている場合（これは、いくつかのPRレジスタでSPIチップを保護したい人によく起こります）、現在のPKを簡単に削除できます。これにより、SecureBootが自動的に無効になり、新しいキーのインストールモードになります。

CurrentModeを編集してSecureBootを無効にする

この攻撃は、NVRAMへの攻撃と実装の組み合わせです。 一部のシステムでは、現在のSecureBootモードはSetup変数への書き込みによって制御され、予期せずにRTフラグが設定されている場合、攻撃者は単に目的のオフセットでSetupにゼロを書き込むことでSecureBootを無効にできます。これは、IFRダンプを分析することで簡単に見つけることができます 攻撃はブーツのように馬鹿げていますが、依然として攻撃を受けやすいシステムがたくさんあります。

SecureBootバイパス編集ExecutionPolicy

以前の攻撃のバリエーションですが、今回はオフになっているのはSecureBoot自体ではなく、EDSが一致しないか存在しない場合にダウンロードを継続することの禁止です。 また、セットアップ変数にRTフラグが必要であり、以前のバージョンよりも少し一般的ではありませんが、SecureBootを切断せずに静かにバイパスできます。

SecureBootバイパスが破損したNVRAM

一部のシステムでは、SecureBootをバイパスするには、NVRAMを少し台無しにして（たとえば、ストレージを容量いっぱいに）、SecureBootを無効にするかバイパスするだけで十分です。 この動作はまれですが、攻撃は非常に単純なので、どのシステムでも試してみるのが理にかなっています。 極端な場合、NVRAMドライバーが本当に悪い場合、SecureBootをバイパスする代わりにDoSが発生する可能性があります。

PCI（e）デバイスを使用したSecureBootバイパス

理論的には、対応するOROMが検証に失敗した場合、SecureBootが有効になっているPCIデバイスからUEFI OptionROMを起動することはありませんが、実際には多数のシステムがPCIデバイスを無条件に信頼し、そこからすべてをチェックせずに起動します。 このような動作には多くの例があり、SecureBootを搭載していないシステムはすべてこの攻撃の影響を自動的に受けます。そのため、Thunderbolt、Firewire、PCMCIA、ExpressCardなどの外部コネクタへのPCI（e）が削除されます。 -プラットフォームのセキュリティに対する犯罪。PCIデバイスは、SMRAMを除く物理メモリの任意の領域でDMAを開始し（プラットフォームの製造元が保護をインストールすることを忘れていない場合のみ）、OSおよびユーザーからすべての秘密を盗むことができます。

ブートローダーをPEからTEに変換するSecureBootバイパス

古い実装攻撃。これは、実装の半分に突然有効であることが判明しました（ほとんどすべてのIBVがTianoCoreのリファレンス実装を使用しているため）。 攻撃の本質：UEFIローダー、および一般的にUEFI実行可能ファイルは、 PE形式またはTE形式（実際には同じPEであり、ヘッダーが切り捨てられているため、使用されるキャッシュスペースが少なくなります）。 TE形式は、PEIモジュールを除く一部のファームウェアコンポーネントで使用されることはほとんどありません（PEIの前半でのみ、RAMの初期化前に、ヘッダーに240hバイトを保存するのが理にかなっているため）、したがって、EDS検証の参照実装ではチェックされませんでした一般にTE形式の画像、および2つの小さなエラーの組み合わせにより、このような画像の検証は常に成功しています。 PE-> TEの変換は簡単であり、ブートローダーでファイルを少し変更するだけでSecureBootを回避できるため、問題は深刻で迅速に修正されたと認識されました。 ただし、この問題を抱えた古いシステムがまだ多数存在するため、この攻撃は依然として記憶されています。

外部メディアからの起動によるSecureBootバイパス

これは攻撃ではなく、SecureBootがブートローダーのなりすましをまったく保護せず、物理的に存在する攻撃者がメディアからシステムを起動できるという誤解です。 BIOSのパスワードとブートデバイス選択メニューでこれから身を守ろうとすることもありますが、優秀なMS開発者はWindowsからも選択でき、Shiftキーを押しながらログイン画面で「再起動」アクションを選択し、表示されるメニューで選択します起動デバイス。 MSの皆さん、ありがとうございます。

おわりに

さて、SecureBootでそれを整理しました。次の（最後の部分で）ソフトウェアとパーソナリティについて説明します。

SecureBoot、ご清聴ありがとうございました。