ESETの研究者は、UEFIセキュアブートをバイパスできる脆弱性を発見しました。この脆弱性は、UEFIを利用している多くのシステムに影響します。この脆弱性は、Microsoft のサードパーティUEFI証明書（Microsoft Corporation UEFI CA 2011）によって署名されたUEFIアプリケーションで見つかっており、CVE-2024-7344が割り当てられました。この脆弱性が悪用されると、システムブート中に信頼されていないコードが実行されます。攻撃者は、インストールされているオペレーティングシステムに関係なく、UEFIセキュアブートが有効になっているシステムであっても、悪意のあるUEFIブートキット（BootkittyやBlackLotusなど） を簡単に展開できる可能性があります。

この脆弱性の影響を受けるのは、Howyar Technologies Inc.、Greenware Technologies、Radix Technologies Ltd.、SANFONG Inc.、Wasay Software Technology Inc.、Computer Education System Inc.、およびSignal Computer GmbHが開発した複数のリアルタイムシステム復旧ソフトウェアに組み込まれているUEFIアプリケーションです。脆弱性なソフトウェア製品のリストを以下に示します。

• バージョン10.2.023_20240919以前のHowyar SysReturn
• バージョン10.2.023-20240927以前のGreenware GreenGuard
• バージョン11.2.023-20240927以前のRadix SmartRecovery
• バージョン10.3.024-20241127以前のSanfong EZ-back System
• バージョン8.4.022-20241127以前のWASAY eRecoveryRX
• バージョン10.1.024-20241127以前のCES NeoImpact
• バージョン10.3.021-20241127以前のSignalComputer HDD King

この脆弱性は、一般的に使用されている安全なUEFI関数LoadImageとStartImageを使用する代わりに、独自のPEローダーを使用することによって引き起こされます。この独自のPEローダーが使用されると、アプリケーションはcloak.datという名前の特別に細工されたファイルから、UEFIセキュアブートの状態に関係なく、システムブート時に任意のUEFIバイナリ（署名されていない場合でも）をロードするようになります。

ESETは、2024 年 6 月に調査結果をCERT Coordination Center（CERT/CC）に報告し、CERT/CCは影響を受けるベンダーに問題を報告し、対応するように求めています。現在、各製品でこの問題は修正され、古い脆弱なバイナリは2025年1月14日の月例パッチでMicrosoftによって無効になりました。

本ブログの要点：

• ESETの研究者は、UEFIセキュアブートをバイパスできる新しい脆弱性（CVE-2024-7344）を発見しました。この脆弱性は、UEFIを利用している多くのシステムに影響します。
• この脆弱性が悪用されると、システムブート時に信頼できないコードが実行され、悪意のあるUEFIブートキットの展開が可能になります。
• MicrosoftのサードパーティUEFI署名が有効になっているすべてのUEFIシステムが、この脆弱性の影響を受けます（Windows 11 Secured-Core PCでは、このオプションはデフォルトで無効になっています）。
• 現在、影響を受けるベンダーによってこの問題は修正され、古い脆弱なバイナリは2025年1月14日の月例パッチでMicrosoftによって無効になりました。

協調的な脆弱性開示プロセスのタイムラインを以下に示します。CERT/CCには、脆弱性開示プロセスの調整に協力していただきました。また、この脆弱性の影響を受けるベンダーには、脆弱性開示および修復プロセスにおいて、円滑で透明性のある協力をいただきました。この場を借りて感謝の意を表します。

協調的な脆弱性開示のタイムライン：

• 2024年7月8日：ESETが脆弱性を発見。
• 2024年7月9日：ESETはこの脆弱性をCERT/CCに報告。
• 2024年7月23日：CERT/CCが、脆弱性開示プロセスの調整に協力することに合意。
• 2024年8月5日：CERT/CCが、影響を受けるベンダーに連絡。
• 2024年8月20日：ベンダーが、検証用の最初のパッチを提供。
• 2024年8月20日：ESETは、報告された問題が正しく対処されていることを確認したが、同じ根本原因で新たに発生した別の問題を発見。
• 2024年8月28日：ベンダーが、検証用に2つ目のパッチを提供。
• 2024年9月23日：ESETはMicrosoftと、脆弱性を公開する新しい日付を2025年1月14日で合意。
• 2025年1月14日：Microsoftが、影響を受ける脆弱なUEFIアプリケーションを無効化。
• 2025年1月16日：ESETがブログを公開。

脆弱性を説明する前に、実際のデバイスでUEFIセキュアブートによる検証がどのように機能するか、また、デバイスでUEFIセキュアブートのデータベースを管理する責任は誰にあるのかを見ていきましょう。

図1に示すように、基本的な概念は極めてシンプルです。UEFIブートマネージャーが、Windowsブートマネージャー、shim、GRUB2などのブートアプリケーションをロードするときにさまざまチェックを行いますが、ブートアプリケーションのバイナリを2つのセキュアブートデータベースと照合して確認します。

• db - プラットフォームのファームウェアによって信頼される、許可された証明書またはPE Authenticodeハッシュのリスト。
• dbx - 禁止される証明書またはPE Authenticodeハッシュのリスト。

ブートアプリケーションが信頼される条件は、検証されたイメージがデータベース（db）によって信頼されており、同時にファイルのハッシュまたはその証明書がdbxデータベースにリストされていないことです。検証結果に基づいて、UEFIブートマネージャーは、セキュリティ違反としてイメージを拒否するか、検証されたイメージを実行します。

UEFIセキュアブートが新しく購入したUEFIデバイスの主なオペレーティングシステムのブートプロセスを（デフォルトでユーザーの操作なしに）保護できるように、多くのデバイスには特定のUEFI証明書のセットが付属しており、それらはdbデータベースに登録されています。これらの証明書は、OEMや特定のデバイスの要件および目的によって異なる場合がありますが、MicrosoftはOEMに、通常のデバイス（ノートPC、デスクトップ、サーバーなど）にMicrosoftの証明書を含めるように求めています。そのため、Microsoftは多くのUEFIベースのデバイスを保護するために重要な役割を果たしています。Microsoftのキーがdbに登録されていることから、Microsoftはブート時に実行を許可する対象と許可しない対象を管理できます。

上記で説明したように、多くのUEFIデバイスにはMicrosoftのUEFI証明書が登録されています。このようなデバイスで信頼される証明書には、通常、次の2つがあります。

• Microsoft Windows Production PCA 2011
• Microsoft Corporation UEFI CA 2011

Microsoftは、悪名高いBlackLotusブートキットに関連する脆弱なWindowsブートローダーへの対応として、Microsoft Windows Production PCA 2011証明書をまもなく無効にし、Windows UEFI CA 2023証明書に置き換える予定です（詳細はこちら）。新規のデバイスや更新されたWindowsデバイスは、すでにこの新しい証明書を信頼して使用しています。Microsoft Corporation UEFI CA 2011証明書は、新しいUEFIアプリケーションに署名するためにまだ使用されているようですが、将来的には新しい証明書であるMicrosoft UEFI CA 2023に置き換える必要があります。UEFI証明書をローリングするMicrosoftの計画に関心がある方は、UEFI Fall 2023 Developers Conference & Plugfestで発表された「Evolving the Secure Boot Ecosystem」（セキュアブートエコシステムの進化）のスライドを参照してください。

以前の証明書（PCA証明書）はMicrosoftが自社のUEFIブートアプリケーションに署名するために使用され、後者はサードパーティが開発したUEFIブートソフトウェアにMicrosoftが署名するために使用されます。これには、Linux shim、さまざまな専門の復旧ソフトウェア、バックアップ、ディスク暗号化、またはメンテナンスソフトウェアなどが含まれます。

つまり、ブート時のソフトウェアをデフォルトでUEFIセキュアブートに対応させる場合は、Microsoftにバイナリの署名を依頼することができ（Windowsハードウェアデベロッパーセンターのダッシュボードを通じて）、そのバイナリがMicrosoftの審査に合格すれば、MicrosoftはそれらのバイナリにサードパーティUEFI証明書で署名します。それにより、ファイルは、Microsoftのサードパーティ証明書を信頼する多くのUEFIシステムとの互換性が確保されます（ただし、Windows 11 Secured-Core PCでは、MicrosoftのサードパーティUEFI証明書はデフォルトでは信頼されないことに注意してください）。

MicrosoftがUEFI署名の要件についてオンラインで公開している情報では、内部の審査プロセスで何を行っているのかが明確に示されておらず、リストに記載された要件を確認しているだけではなく、さらに深い分析を実施している可能性があります。ESETは、手動による審査プロセスが新たな脆弱性が発見されるたびに改善されていると信じていますが、実際に署名の対象となったバイナリや、その手動の審査プロセスのチェック内容についての透明性を高めることで、このレポートで説明しているような脆弱なバイナリがより早期に発見され、修正される可能性が高くなると考えています。

昨年、HowyarのSysReturnソフトウェアパッケージをESETが確認したときに、最初に注意を引いたのは、reloader.efiというMicrosoftが署名したUEFIアプリケーションとともに展開されていたcloak.datという名前のファイルの存在でした。以下は、脆弱なreloader.efiアプリケーションのPE Authenticodeハッシュです。

• cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48（64ビット版）
• e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9（32ビット版）

この分析では、64ビット版のreloader.efiを使用しています。図2に示しているように、cloak.datファイルはALRMというマジックストリングで始まるヘッダーのようなデータ構造を含んでいます。このヘッダーの後に、PE/COFFファイルヘッダーの構造に視覚的に似ている不明なデータが続き、単純なXOR暗号で暗号化されています。0xB3バイトが出現する頻度に基づいてキーを推測するのは簡単です。0xB3バイトは、通常のPE/COFFヘッダーに存在する多数の0x00バイトに対応しています。0xB3というキーを使ってXOR操作を行ってcloak.datを復号すると、UEFIアプリケーションが実際に含まれており、署名されていないアプリケーションであることが分かります。

ESETの研究者はすぐに、抽出したバイナリに悪意がないことを確認しましたが、SysReturnのブートローダーがシステムブート時に何らかの形で使用しているバイナリではないかとう疑問が浮かび上がりました。そうであれば、UEFIセキュアブートが有効な場合に、署名されていないバイナリのロードが拒否されるのかを調べることにしました。reloader.efiをさらに深く調べた結果、 cloak.datファイルをメモリにロードし、埋め込まれたイメージを復号するコードが見つかりました。図3に示すように、この関数はEFIシステムパーティション上の以下の場所のいずれかからファイルをロードします。

• \EFI\Microsoft\boot\cloak64.dat
• \FEFIbootcloak64.dat
• \Microsoftboot
• \FEFIbootcloak.dat

これまでのところは何も問題はありません。ブートローダーは、復号されたPEイメージを含むバッファを引数としてUEFIのLoadImage関数に渡すことができ、図1に記載された検証プロセスによってイメージがマシンのUEFIセキュアブートポリシーを満たしていることが確認されることになります。残念ながら、そうなってはいませんでした。cloak.datファイルからPEイメージを復号した後、脆弱なブートローダーは図4で説明している独自の関数を呼び出し、セキュアブートによる整合性チェックなしにイメージを手動でロードして実行します。

UEFIセキュアブートが有効なシステムでこの脆弱性を悪用する方法の概念実証については、以下のビデオを参照してください。

この脆弱性が悪用されるのは、影響を受ける復旧ソフトウェアがインストールされているシステムに限定されません。攻撃者は、MicrosoftのサードパーティUEFI証明書が登録されているUEFIシステムであれば、脆弱なreloader.efiバイナリのコピーを持ち込むことができます。また、脆弱で悪意のあるファイルをEFIシステムパーティションに展開するには、権限を昇格（Windowsではローカル管理者、Linuxではroot）する必要があります。脆弱性を攻撃するには、攻撃者は以下の処理を実行する必要があります。

1. EFIシステムパーティション（ESP）のデフォルトのOSブートローダーのバイナリを、脆弱なreloader.efiに置き換える。
2. 悪意のあるUEFIアプリケーションを含み特別に細工されたcloak.datファイルを、脆弱なブートローダーがサポートしているESP上のパスの一つにコピーする。
3. システムを再起動する。

ESETは、概念実証を作成してこの脆弱性を攻撃できることを確認した後に、脆弱なreloader.efiアプリケーションがHowyarのSysReturnソフトウェアだけでなく、いくつかの別の復旧ソフトウェア製品でも使用されていることに気づきました。この脆弱性の影響を受けるソフトウェアパッケージのリストは、このブログの最初に掲載しています。異なるベンダーが開発した複数の製品が影響を受ける可能性があったため、ESETはCERT/CCにこの問題を報告しました。CERT/CCは、影響を受けるベンダーへの連絡を取り、脆弱性の公開プロセスを調整するために支援を行いました。

これまでのところ、ESETのテレメトリ（監視）データでは、実際にこの脆弱性が悪用されたケースは検出されていません。

この脆弱性は、Microsoftから提供される最新のUEFI失効リストを適用することで緩和できます。Windowsシステムは自動的にアップデートされます。MicrosoftのCVE-2024-7344の脆弱性に関するアドバイザリは、こちらを参照してください。以下のPowerShellコマンド（権限を昇格して実行）を使用して、自社のシステムがこの脆弱性に影響を受けるかどうか、また必要な失効リストがインストールされているかを確認してください。

デバイスのセキュリティを軽視せず、デジタル環境に潜むリスクに常に注意を払うことが重要です。サイバーセキュリティはいつでも、一寸先は闇の世界です。

# UEFI systems; returns True if your system is affected by the CVE-2024-7344
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
# 64-bit UEFI systems; returns True if you’re protected (the vulnerable driver is revoked on your system)
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
# 32-bit UEFI systems; returns True if you’re protected (the vulnerable driver is revoked on your system)
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Linuxシステムの場合、Linuxベンダーファームウェアサービスからアップデートを入手できます。以下のコマンドを使用して、必要な失効リストがシステムにインストールされているかどうかを確認してください。

dbxtool --list | grep
'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48' dbxtool --list | grep
'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

UEFIの失効リストはCVE-2024-7344からシステムを効果的に保護しますが、署名された未知の脆弱なUEFIブートローダーの悪用やUEFIブートキットの展開に対して保護（または少なくとも検出）するための他の方法もあります。これらの方法を以下に紹介します。

• EFIシステムパーティションにあるファイルへのアクセスを管理する。UEFIブートキットをインストールする大半のシナリオでは、攻撃者はUEFIブートキットをインストールするため、またはターゲットシステムの署名されたUEFIブートローダーの脆弱性を悪用するために、EFIシステムパーティションの内容を変更する必要があります。多くのセキュリティ製品では、システム上の特定のファイルやディレクトリへのアクセスをブロックするユーザー定義ファイルのアクセスルールを独自に作成できます（こちらやこちらの例を参照）。
• UEFIセキュアブートのカスタマイズアメリカ国家安全保障局（NSA）が公開したUEFIセキュアブートのカスタマイズに関するレポートで詳述されているように、セキュアブートをカスタマイズすることで、UEFIブートキットから効果的に保護することができるほか、攻撃対象領域を縮小したり、公式の失効リストが更新されたりするまでに長時間かかる場合に、システムの所有者が脆弱なUEFIアプリケーションを迅速に失効させることが可能になります。このカスタマイズは効果的ですが、経験豊富な管理者による操作が必要となることが多くあり、セキュアブートを正しく設定しなければシステムが一時的に起動しなくなることもあるため、大規模な管理が難しい場合があります。
• TPMによるリモート認証では、UEFIブートコンポーネントと設定の測定値が信頼されたリモートサーバーによって既知の正常値と照合され、不正なブート変更を検出するために使用されます。

近年UEFIの脆弱性が多く発見されていることと、これらの脆弱性を修正するためのパッチ適用や脆弱なバイナリの失効が迅速に行われていないことから、UEFIセキュアブートのようなセキュリティの基盤となる重要な機能であっても絶対的に安全と見なすべきではありません。

しかし、このブログで報告された脆弱性に関して最も懸念すべき点は、バイナリの修正や失効にかかった時間ではなく（類似のケースと比較してかなり迅速な対応でした）、明らかに安全でない署名済みのUEFIバイナリが再び発見された事実です。実際、約2年前にEclypsiumが公開し、UEFIブートローダーに関連するセキュリティの問題について詳しく分析したレポート「One Bootloader to Load Them All」では、Microsoftが署名した脆弱なUEFIアプリケーション（CVE-2022-34302）が安全でないPEローダーを実装していた非常によく似た問題が記載されています。

これは、サードパーティのUEFIソフトウェアベンダーの間で、このような安全でない手法がどれほど一般的に使われているのか、そして、リスクのある可能性があり署名されたブートローダーが他にも存在するのではないかという疑問を投げかけています。ESETは、この状況についてMicrosoftに報告しており、サードパーティのUEFIアプリケーションに対する署名の透明性が今後向上することを期待しています。これにより、明らかに安全でないUEFIアプリケーションを誰でも迅速に発見して報告できるようになり、もしアプリケーションが誤って（または以前に）、MicrosoftのUEFIサードパーティコード署名の審査を通過している場合でも、対応できるようになるはずです。ESETは、 Microsoftが予定している新しいUEFI証明書の導入は、これを実現する大きな機会となると考えています。これにより、UEFIサードパーティ署名の透明性とUEFIのセキュリティが一歩前進することになるはずです。

ESETのブログページに掲載されたリサーチに関するお問い合わせは、threatintel@eset.comまでご連絡ください。
ESET は、プライベートAPTインテリジェンスレポートとデータフィードを提供しています。サービスの詳細は、ESET 脅威インテリジェンスのページをご覧ください。

脆弱なローダーは、これらのローダーによって一度も侵害されたことがない可能性のある何千ものシステムに存在する正当なソフトウェアパッケージの一部であるため、誤解を避けるために、侵害の指標は提供していません侵害の指標の代わりに、「保護と検出」セクションに記載している対策に従ってください。

※本ブログ（英語版）は2025年1月16日にWeLiveSecurityで公開しました。