忘れ去られたUEFIシムがSecure Bootを無力化

ESETの研究者は、バージョン0.9以下の古い、忘れ去られた11個のUEFIシムブートローダーを特定しました。これらのシムは、MicrosoftのMicrosoft Corporation UEFI CA 2011サードパーティUEFI証明機関(CA)証明書を信頼するすべてのUEFIベースのマシン上で、インストールされているオペレーティングシステム(OS)を問わず、UEFI Secure Bootを回避するために悪用可能です。報告されたシムを悪用すれば、システム起動時に信頼されていないコードを実行できるため、攻撃者はUEFI Secure Bootが有効なシステムであっても、悪意のあるUEFIブートキット(Bootkitty、HybridPetya、BlackLotusなど)を展開できてしまいます。ESETは2026年2月にこの調査結果をCERT/CCに報告し、脆弱なUEFIアプリケーションはMicrosoftの2026年6月9日のPatch Tuesdayで失効処理されました。

今回報告したシムをカバーするために2つのCVE ID、CVE-2026-8863およびCVE-2026-10797が割り当てられましたが、報告した各シムの悪用は、これらの古いシム自体に見つかる単一または2つのバグに限った話ではありません。実際には、シムが信頼する第2段階のブートローダー(主にGRUB 2)によって攻撃対象領域はさらに拡大しています。これらのブートローダーも、シム自体と同様に、既知の脆弱性を抱えた古いバージョンが含まれている場合があります。今回発見されたシムは、PC診断ソフトウェア、Linuxディストリビューション、その他のUEFIベースのユーティリティなど、さまざまなツールやソフトウェアパッケージに由来しています。重要な点として、悪用は影響を受けるソフトウェアやOSがインストールされたシステムに限定されません。攻撃者は、Microsoftのサードパーティ製UEFI証明書が登録されている任意のUEFIシステムに、脆弱なシムのコピーを自ら持ち込むことができるためです。

報告されたシムに依存するソフトウェア製品と影響を受けるバージョンの全リストは、CERT/CCの脆弱性ノートで確認できます。ESET研究者の報告を受け、以下のPE Authenticodeハッシュを持つUEFIシムブートローダーが、Microsoftの6月9日のPatch Tuesdayに含まれるdbxアップデートで失効処理されました。

AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

本ブログ記事の要点:

ESETの研究者は、大多数のUEFIベースのシステムでUEFI Secure Bootの回避を可能にする、Microsoft署名済みの古いUEFIアプリケーション11個を発見

これらの脆弱なアプリケーションのいずれかを悪用する攻撃者は、システム起動中に信頼されていないコードを実行でき、悪意のあるUEFIブートキットやその他のマルウェアの展開が可能になる

悪用は影響を受けるソフトウェアやOSがインストールされたシステムに限定されない。攻撃者はMicrosoftのサードパーティ製UEFI証明書が登録されている任意のUEFIシステムに、脆弱なバイナリのコピーを持ち込める

Microsoftのサードパーティ製UEFI署名が有効なすべてのUEFIシステムが影響を受ける(Windows 11のSecured-core PCではこのオプションがデフォルトで無効になっているはず)

脆弱なバイナリは2026年6月9日のPatch Tuesdayアップデートでマイクロソフトにより失効処理された

以下は協調的な情報開示のタイムラインです。脆弱性開示プロセスの調整にご協力いただいたCERT/CC、そして開示・修復プロセス全体を通じてスムーズかつ透明性のあるコミュニケーションとご協力をいただいた影響を受けたベンダー各社に感謝いたします。この脅威からシステムを保護するには、最新のMicrosoft dbxアップデートをインストールしてください。手順は対策と検知セクションで確認できます。

協調的な情報開示のタイムライン:

2026年2月16日 – ESETが調査結果と概念実証(PoC)をCERT/CCに報告

2026年3月18日 – dbxアップデートと一般公開日を2026年5月19日(Microsoftの5月のPatch Tuesday)に設定

2026年3月30日 – dbxアップデートと一般公開日を2026年6月9日(Microsoftの6月のPatch Tuesday)に延期

2026年6月9日 – Microsoftの6月のPatch Tuesdayアップデート、CERT/CCの脆弱性ノートが公開

2026年7月14日 – ESETのブログ記事を公開

UEFIシムブートローダーとUEFI Secure Boot

このような脆弱なシムがUEFI Secure Bootで保護されたシステムに与える影響を理解するには、まずUEFI Secure Bootの仕組みと、署名済みUEFIシムブートローダーがどのようにSecure Bootの信頼チェーンを拡張するのかを理解する必要があります。本セクションでは、UEFI Secure Bootの基本、UEFIシムがUEFI Secure Bootの信頼チェーンをどう拡張するか、そしてシムに関連する2つの機能であるMachine Owner Key(MOK)とSecure Boot Advanced Targeting(SBAT)について解説します。理論的な部分にすでに詳しい方は、古いシムを使ったUEFI Secure Bootの回避のセクションへ直接進むことをお勧めします。

UEFI Secure Boot

図1に示すように、UEFIファームウェアがWindows Boot ManagerやUEFIシムのようなブートアプリケーションをロードする際には、そのバイナリを2つのSecure Bootデータベースと照合して検証します。

db(許可された証明書とAuthenticodeハッシュ)、および
dbx(禁止された証明書とAuthenticodeハッシュ)

イメージはdbによって信頼されており、かつdbxにリストされていない必要があります。そうでなければ、ブートマネージャーはそのイメージを実行する代わりにセキュリティ違反を発生させます。UEFI Secure Bootが有効な新規購入デバイスでこの仕組みをそのまま機能させるため、ほとんどのOEMは以下のMicrosoft UEFI証明書一式をdbデータベースに登録しています。

Microsoft Windows Production PCA 2011およびWindows UEFI CA 2023(Microsoft自身のUEFIブートアプリケーションの署名に使用。2011年の証明書は近日中にdbxに追加される予定で、これはBlackLotus関連の脆弱性を受けたもの)
Microsoft Corporation UEFI CA 2011およびMicrosoft UEFI CA 2023(Linuxシムやリカバリツール、ディスク暗号化ユーティリティなど、サードパーティ製のUEFIブートソフトウェアの署名に使用)

つまり、自社のブート時ソフトウェアをデフォルトでUEFI Secure Bootに対応させたい人は誰でも、Windows Hardware Dev Centerを通じてバイナリをMicrosoftに提出し署名を受けることができ、承認されればその署名済みファイルは大多数のUEFIシステムで信頼されるようになります。その結果、Microsoftはほとんどのuefiベースデバイスのセキュリティにおいて中心的な役割を担っており、事実上、起動時に何を実行してよく、何を実行してはいけないかを決定していることになります。

UEFIの失効処理(dbx)

UEFI Secure Bootの失効処理の設計はシンプルです。それまで信頼されていたブートアプリケーション(そのPE Authenticodeハッシュ、あるいはそれに署名した証明書がdbに存在するもの)が脆弱であると判明した場合、そのPE Authenticodeハッシュは、Microsoftが管理する禁止署名データベースであるdbxに追加されます(最新のdbxの内容は通常、MicrosoftのGitHubリポジトリで公開されます)。証明書自体が失効処理されるのは稀なケースに限られます。

Secure Bootが導入された当時は、脆弱な個々のバイナリをハッシュ単位で失効させるという当初の考え方は合理的だったかもしれませんが、BootHoleやBlackLotusのような事例は、このアプローチが決して理想的ではないことを示しています。根本的な問題は規模の大きさであり、Red Hat Bootloader TeamのSBAT提案・仕様書がこの点をうまく捉えています。

最近の「BootHole」セキュリティインシデントCVE-2020-10713の一環として、広く使われているx64アーキテクチャにおいて、3つの証明書と150個のイメージハッシュがUEFI Secure Bootの失効データベースdbxに追加された。この1回の失効イベントだけで、UEFIプラットフォームで通常利用可能な32kBの失効ストレージのうち10kB、つまりおよそ3分の1を消費する。UEFIが失効リストをマージする方法により、これに過去の失効イベントが加わると、dbxのサイズはほぼ15kBに達し、容量の50%近くに迫ることになる。

同様のdbx容量に対する圧力は、BlackLotus関連の脆弱なWindows Boot Managerバイナリの失効処理の際にも再び表面化しました。これら2つの事例はいずれも、Microsoftとそのパートナーに対し、広く展開されている2つのSecure Boot対応ブートローダーそれぞれに紐づく、追加のバージョンベースの失効メカニズムの導入を促しました。

Secure Boot Advanced Targeting(SBAT) – バージョン15.3以降、Linux用のUEFIブートローダーであるshimで使用
MicrosoftのSecure Boot Security Version Number(SVN) – 2024年4月にリリースされたWindows Boot Managerで使用。Bill DemirkapiのBooting with Caution, p. 62ではRevocation via Embedded Secure Version Information(REVISE)とも呼ばれているが、この名称・略称はMicrosoftの公式ドキュメントでは使われていないようだ

要するに、dbxがバイナリを失効させるのに対し、SBATとMicrosoftのSecure Boot SVNはバージョンを失効させます。これらのバージョンベースの失効メカニズムに対応するUEFIアプリケーションに脆弱性が見つかった場合、本当に締め出す必要があるのは問題のあるビルドまでのすべてのビルドであり、これはハッシュの長いリストよりもバージョン番号の方がはるかに簡潔に表現できます。SBATについてはSecure Boot Advanced Targeting(SBAT)セクションで詳しく説明します。

UEFIシムブートローダーとSecure Boot

Linuxディストリビューションでも UEFI Secure Bootに対応させようとすると、上述したMicrosoftの鍵を中心に構築されたSecure Bootの仕組みが、いくつかの課題を生みます。すべてのLinuxディストリビューションは独自のブートローダーバイナリを生成しており、それぞれ異なるハッシュ値を持ちます。すべてのLinuxブートローダーをMicrosoftに直接署名してもらうのは、動作が遅く煩雑な上、すべてのLinuxディストリビューションにわたって維持するのは非現実的(不可能ではないにしても)です。

この問題の解決策がシムです。シムとは、Microsoftが一度審査・署名すればよい、小さく最小限の第1段階ブートローダーであり、その後、GRUB 2やLinuxカーネルといった、Linuxディストリビューション固有のブートスタックの残りの部分に対する第2の信頼のアンカーを作り出します。この信頼のアンカーは別の証明書であり、ベンダー証明書(ディストリビューションのベンダーが管理)と呼ばれ、Microsoftによる署名前にシムバイナリに追加されます。

シムを使用したSecure Boot対応Linuxシステムの簡略化したブートシーケンスを図2に示します。

UEFIファームウェアはシムをロードし、ファームウェアに保存されているMicrosoftのCA(db変数)に対してその署名を検証します。次にシムが処理を引き継ぎ、埋め込まれた独自のベンダー証明書――例えばDebianのUEFI鍵、UbuntuのCanonicalのUEFI鍵、RHELやFedoraのRed Hatの鍵――に対して、第2段階のブートローダー(多くの場合GRUB 2)を検証します。GRUB 2は制御を引き渡す前に、同じベンダー証明書を使ってカーネルを検証します。各ステップは、その前のステップによって暗号学的に保証されているわけです。

この間接的な仕組みにより、Linuxディストリビューションは、更新のたびにMicrosoftへ戻る必要なく、独自のベンダー鍵で署名しながらブートローダーとカーネルの更新を迅速にリリースできます。Microsoftの署名が必要なのはシム自体だけであり、それも頻繁に変更されるわけではありません。

ベンダー証明書に加えて、シムには特定のシムビルド・バイナリのみに関連付けられた、もう一つの組み込み証明書が含まれていることがよくあります。この証明書はシム証明書と呼ばれることが多く、シムのビルド時に生成される可能性のあるユーティリティ、例えばMokManager(MOKの管理に使用され、後で詳しく説明します)やシムのfallbackの完全性の署名・検証に使用されます。

Machine Owner Key(MOK)

シムについて語る上で欠かせないもう一つの重要な仕組みが、ユーザーが管理する外部の鍵をシムが利用できるようにするMachine Owner Key(MOK)です。MOKの許可リスト(いわばUEFIのdbデータベースをシム固有に「拡張」したもの)は、MokListというブート専用のNVRAM変数に保存され、禁止リスト(UEFIのdbxデータベースのシム固有の「拡張」)はMokListXというブート専用のNVRAM変数に保存されます。UEFI Secure Bootが有効なシステムでこれら両方の変数を変更するには物理アクセスが必要です(ブート専用変数は、OSローダーがUEFIブートサービス関数のExitBootServicesを呼び出す前、つまりブート中にのみ変更可能です)。このリストを管理するために、シムはMokManagerというUEFIアプリケーションを使用します。MOKの管理方法についてのガイドはこちらで確認できます。図3は、MOKがシムのUEFI Secure Boot信頼チェーンをどのように拡張するかを示しています。

ESETがBlackLotusやBootkittyの発見で説明したとおり、MOKの仕組みが使用するブート専用NVRAM変数には認証機能がないため、ブートキットはUEFI Secure Bootの回避に成功すると、永続化のためにMOKを悪用する傾向があります。

Secure Boot Advanced Targeting(SBAT)

SBATに対応する各UEFIアプリケーション(コンポーネント)は、PEファイル内の専用.sbatセクションに小さなメタデータを保持しており、これはバイナリ自体と同じ署名によって保護されています。このメタデータには、コンポーネント名(例えばshimやgrub)と、セキュリティ修正がリリースされるたびに増加する世代番号が記されています。

この番号を失効処理の仕組みとして機能させているのが、UEFIシステム側のマッチングポリシーです。すなわち、既知の各コンポーネントについて許容される最小の世代番号を記録する、SbatLevelというブート専用のUEFI変数です。重要なのは、この変数はファームウェアではなくシムによって管理・強制されるため、dbxアップデートに比べてより迅速な失効更新が可能になる点です。シムはこのポリシーを内蔵しているため、強制処理は外部変数だけに依存せず、SbatLevel経由で提供されるより新しいポリシーも取り込みます。起動のたびに、シムはまず自身のSBATメタデータをポリシーと照合して検証します(そのため、古いシムは自らを拒否するよう仕向けることができます)。その後、ロードするすべてのバイナリに同じテストを適用し、世代番号がポリシーが要求する最小値を下回るものは拒否します。

SBATによる失効処理の例を図4に示します。これらは、SBATの失効処理の唯一の情報源となっているシムのリポジトリ内のSbatLevel_Variable.txtファイルから抜粋したものです。

強制されているレベルはOSから隠されているわけではありません。シムは、読み取り専用のコピーであるSbatLevelをランタイム変数SbatLevelRTとして公開しています。OSは現在有効になっている失効ポリシーを確認できますが、変更することはできません。Windowsでは、同じ情報がレジストリ値HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevelからも確認できます。

古いシムを使ったUEFI Secure Bootの回避

前セクションでシムのSecure Boot信頼チェーンに関する理論を説明したので、ここからは忘れ去られた古い(それでいて信頼されている)UEFIバイナリが、UEFIシステムのセキュリティに与える実際の影響に焦点を当てます。

これを示すため、報告したシムに存在するいくつかの具体的な問題を検証します。これらの問題は容易に悪用可能であり、シムがさらしている攻撃対象領域の広さを浮き彫りにしています。

脆弱な第2段階ブートローダー

報告した各シムには、ベンダーが管理する証明書と組み込みのシム証明書の両方が含まれており、これらはGRUB 2バイナリ、MokManager、フォールバックローダー、さらには時として信頼チェーンをさらに拡張する他のベンダー署名済みシムといった、シムの第2段階ブートローダーやユーティリティの信頼のアンカーとして機能します。特定のシムが信頼するバイナリの数はさまざまで、専用の特化型ソフトウェアの場合は10個未満、著名なLinuxディストリビューションの場合は100個近くに及びます。

今回報告したシムが信頼するアプリケーションの署名・コンパイルのタイムスタンプは2013年から2025年にわたっており、これらのバイナリのかなりの部分が古く、既知の多数の公開脆弱性の影響を受けている可能性が高いことを裏付けるには十分です。その中には、GRUB 2の場合、すでに触れたBootHoleも含まれます。信頼されているこれらのコンポーネントのほとんどは、ある程度のセキュリティリスクを抱えるほど古いものですが、中でもGRUB 2が最も弱いリンクだと見られます。複雑なソフトウェアであるため、古いバージョンにはそれだけ脆弱性が蓄積されているのです。

今回報告したシムの一つである、Oracle Linuxのシムを例に見てみましょう。このシムは、Oracle Corporation宛に発行された証明書(SHA-1フィンガープリント: 2E434A724B4759C981E4189AA5AD3D635096DD2F)によって署名されたバイナリを信頼しています。この証明書によって署名されたバイナリの一つが、Oracle Linux 7.1インストールISO(V74844-01.iso)に含まれるGRUB 2バイナリです。このバイナリはCVE-2015-5281の影響を受けます。脆弱性ノートの記述を引用すると、これは「UEFIシステムで使用された場合、ローカルユーザーが意図されたSecure Bootの制限を回避し、細工した(1) multibootまたは(2) multiboot2モジュールを介して検証されていないコードを実行できてしまう」というものです。ここで言及されているmultibootとmultiboot2の両モジュールは、同名のコマンドを使ってシステム起動時に未署名のコードをロードできるものであり、設計上UEFI Secure Bootを回避してしまうため、署名済みのUEFI Secure Boot対応GRUB 2バイナリでは禁止されているべきものです。

この悪用は単純です。トリガーすべきメモリ破壊バグもなければ、構築すべきROPチェーンもなく、複雑なリバースエンジニアリングも必要ありません。唯一の前提条件は、独自の未署名のmultiboot2準拠カーネルイメージを構築することだけです。実際には、必要なヘッダーといくつかの詳細情報を含むELFバイナリを用意する程度で済みます。攻撃者がこのバイナリを構築し、脆弱なシムおよびGRUB 2とともにEFI System Partition(ESP)にコピーすれば、GRUB 2のmultiboot2コマンド一つで、Secure Bootの有効・無効を問わず、起動時にそのバイナリをロード・実行できてしまいます。UEFI Secure Bootが有効な(かつMicrosoftの最新パッチが未適用の)システム上で、報告した古いOracle Linuxのシムを介してCVE-2015-5281を悪用する概念実証を、以下の動画で紹介しています。

新機能の欠如

UEFIシムブートローダーは長年にわたり自然に進化を遂げ、上流のUEFIシムリポジトリの後続リリースでは新たな改善やセキュリティ機能が次々と導入されてきました。その一方で、多くのサードパーティベンダーは入手可能なシムのソースコードを使って独自のバイナリを構築し、それをMicrosoftに提出して署名を受けてきました。この動作自体は想定されたものであり、シムの本来の設計にも合致しています。しかし、古くなったMicrosoft署名済みシムを失効処理することへの注意は十分に払われてきませんでした。これらの多くは、設計上、新しいセキュリティメカニズムを回避するために悪用され得るものです。ここでは、この隙間を具体的な例で示します。

MOK拒否リストの強制

MokList(MOKベースの許可リスト)は、上流のUEFIシムでほぼ最初期の頃から(バージョン0.3)サポートされてきました。しかし、MOKの失効処理(MokListX)が強制されるようになったのはバージョン0.9以降です。これがなぜ問題になるのでしょうか。次のシナリオを考えてみましょう。

ある企業が、社内ネットワーク全体に展開する独自のUEFIツールやブートローダーに署名するために、自社のMOKを登録しているとします。それらのバイナリの複数に脆弱性が見つかり、これを受けて管理者は古い署名証明書をMOK拒否リスト(MokListX)に登録して失効させます。その後、新しいMOKを登録し、影響を受けたバイナリの修正版をその新しい鍵で再署名します。古い脆弱なバイナリはシムによって拒否されるようになり、新しく署名されたものは正常にロードされるため、この企業のデバイスは安全に見えます。しかし古い証明書は、MokListには依然として存在し信頼されたままであり、MokListXで失効処理されている状態です。ここではMokListXの方が優先度の高いルールとして強制されます。

このシナリオにおいて、攻撃者は被害者の最新のシムを、今回報告した古いMicrosoft署名済みUEFIシムに差し替えることができます。例えば、フィンランドのMatriculation Examination Board向けにMicrosoftが署名した、Abitti 1ソフトウェアのバージョン0.8です。このシムは依然として被害者のMokList変数に保存された証明書を信頼しており、古くなったMOK証明書もそこでは有効なままです。一方でこのシムは、MOK拒否リストの強制導入以前にビルドされたものであるため、MokListXを無視します。その結果、攻撃者のシムを使って脆弱なバイナリを制限なくロードでき、任意コード実行や悪意のあるUEFIブートキットのインストールが可能になってしまいます。

SBATの強制

同じ問題はSBATにも当てはまります。SBATのサポートは、シムのバージョン15.3で上流に導入されたため、それ以前のシムはこの仕組み自体を認識しません。つまり、SbatLevelの失効ポリシーを読み込むことも、ロードする第2段階ブートローダーの.sbatセクションを検査することもありません。その結果、脆弱なコンポーネントをブロックするために意図された、以降のSBAT失効処理をすべて無視してしまいます。

このケースでの攻撃シナリオは次のようになります。攻撃者は、今回の報告に含まれるRed Hat Enterprise Linux 7.2由来のバージョン0.9のシムのような、v15.3より前のMicrosoft署名済みシムを用意します。そして、そのシムが依然として信頼しているものの、SBATによってすでに失効処理されているGRUB 2バイナリの一つと組み合わせ、両方をESPにコピーします。システム起動時、シムは埋め込まれた証明書に対してGRUB 2バイナリを検証しますが、SBATを一切参照することなく、脆弱なバイナリを何の問題もなくロードしてしまいます。こうして攻撃者は、そのGRUB 2バイナリに存在する任意の脆弱性を自由に悪用できるようになります。

既知のシムの脆弱性

最後に、古いシムは単に古いコードであり、古いコードの多くは既知の脆弱性を抱えています。これを示す例として、バージョン0.9以下のシムに影響する古い問題を取り上げます。この脆弱性には、今回の報告があるまでCVE IDが割り当てられていませんでした。しかし実際には、シムリポジトリの上流コミットの一つであるd241bbbのメッセージの中で、ほぼちょうど10年前に修正され、詳しく説明されていたものです。現在はCVE-2026-10797として追跡されています。

問題は、Authenticode署名済みのPEバイナリが、その署名の長さを2つの独立した場所に記録している点にあります。

PEヘッダーのデータディレクトリ(IMAGE_DIRECTORY_ENTRY_SECURITY)、および
署名自体をカプセル化するWIN_CERTIFICATE構造体

影響を受けるシムでは、失効チェック機能と署名検証機能とで、どちらのサイズ値を信頼するかが食い違っていました。失効チェックは署名ヘッダーの値を使用する一方、署名検証機能はPEヘッダーの値を使用していたのです。

そのため、第2段階ブートローダーのWIN_CERTIFICATE構造体を改ざんすることで失効処理の仕組みを回避し、失効チェック機能がdbxやMokListXを、ブートローダーの実際の署名ではなく偽のデータと照合してしまうよう仕向けることが可能になります。

簡単に言えば、たとえ第2段階ブートローダーの証明書がdbxやMokListXで失効処理されていたとしても、シムはそれに気づかないということです。ここで重要な点が2つあります。

この回避手法は証明書ベースの失効処理にのみ有効であり(ハッシュベースの失効処理には効かない)、
第2段階ブートローダーは、シムに埋め込まれた証明書(シムのビルド時に生成される組み込み証明書、あるいはベンダー証明書)によって署名されている必要がある

これらの制約は、ハッシュベースの失効処理や(MokListやdb由来の)埋め込まれていない証明書についてはコードの別の箇所でチェックされており、この問題の影響を受けないという事実に起因します。

Microsoft UEFI証明書の有効期限切れでこの問題は解決しないのか

現在のMicrosoft UEFI証明書の有効期限を踏まえると(図5に示すとおり、Microsoft Corporation UEFI CA 2011は2026年6月27日に期限切れとなりました)、この期限切れ証明書で署名された脆弱なUEFIアプリケーションを報告することに、実は意味がないのではないかと疑問に思う方もいるかもしれません。

実際のところ、UEFI証明書の有効期限はSecure Bootの検証プロセスには何の影響も及ぼしません。Microsoft Corporation UEFI CA 2011証明書がdbに残り続け、dbxで失効処理されない限り、この期限切れ証明書で正しく署名されたすべてのブートローダーは、ハッシュによって明示的に失効処理されない限り、信頼され続けます。これが、Microsoftが有効期限に至るまで、この古い証明書を使った新規提出への署名を継続していた理由です。

対策と検知

これらの脆弱なシムは、Microsoftが公開している最新のUEFI失効情報を適用することでブロックできます。Windowsシステムは自動的に更新されるはずです。図6は、お使いのWindowsシステムに必要な失効処理が適用されているかを確認するためのPowerShellコマンド(管理者権限で実行する必要があります)を示しています。

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

図6. UEFI失効処理を確認するPowerShellコマンド

Linuxシステムの場合、アップデートはLinux Vendor Firmware Serviceを通じて提供されるはずであり、失効状況はuefi-dbx-auditスクリプトを使って確認できます。

未知の脆弱な署名済みUEFIブートローダーの悪用やUEFIブートキットの展開を防ぐ(あるいは少なくとも検知する)ための、より一般的な推奨事項については、ESETのブログ記事「UEFI Secure Bootの陰に:CVE-2024-7344を紹介」をご覧ください。

結論

これらの古いシムを危険にしているのは、目新しい脆弱性ではありません。むしろ、UEFI Secure Bootを回避するのに新たな脆弱性がまったく不要である、という点が問題なのです。攻撃者に複雑な悪用手法は必要なく、必要なのは古くても依然として信頼されている、ただし失効処理されていないシムバイナリのコピーと、UEFIシムの仕組みに関する基本的な理解だけです。それだけで、UEFI Secure Bootという重要なセキュリティ機能を回避するのに十分なのです。

これら11個のシムを失効処理したことで当面の問題は解決しましたが、より根深い課題が残っています。それは可視性です。シムの署名プロセスは、ベンダーの提出物をMicrosoftが署名する前にメンテナーが審査するshim-reviewリポジトリが導入された2017年に、大幅に透明性が向上しました。それ以降に承認されたシムはすべて記録されていますが、それ以前に署名されたシムは記録されておらず、そうした古い、依然として信頼されているシムがどれだけ残っているのか、確実に把握できる人は誰もいません。完全かつ透明にカタログ化されていないものを、効果的に退役させることはできません。</p

明るい兆しとして、状況は正しい方向に向かっていると私たちは考えています。今回のような開示が一件あるたびに、忘れ去られたシムの母集団は縮小していきます。そして、シム署名の透明性の向上や、SBATのようなメカニズムのおかげで、何を失効処理すべきかを把握し、それを効果的に失効処理する作業は、これまでよりもはるかに効率的に行えるようになっています。次のステップは、この透明性のレベルを、Microsoftのサードパーティ製UEFI署名エコシステム全体、つまりシム以外のサードパーティ製UEFIアプリケーションにも拡張することです。これらは、これまでも繰り返し実証されてきたとおり(例: CVE-2022-34302、CVE-2023-28005、CVE-2024-7344、CVE-2026-25250など)、UEFI Secure Bootの回避手段として容易に悪用され得るものだからです。

侵害指標(IoC)

これらの脆弱なシムは正規のソフトウェアパッケージの一部であり、これらのローダーを介して一度も侵害されたことのない数千台ものシステムに存在している可能性があります。そのため、大規模な誤検知を避けるべく、侵害指標は提供していません。防御担当者は、対策と検知セクションの助言に従ってください。

WeLiveSecurityで公開している弊社調査に関するお問い合わせは、[email protected]までご連絡ください。

ESET Researchは、非公開のAPTインテリジェンスレポートおよびデータフィードを提供しています。このサービスに関するお問い合わせは、ESET Threat Intelligenceのページをご覧ください。

翻訳元: https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/