初期段階セキュリティという幻想
セキュアブート機構は、WindowsやLinuxが起動する前の段階で悪意あるコードを阻止する役割を担っています。しかし、ESETの研究者たちは最近、衝撃的な事実を発見しました。攻撃者たちは、この保護機能の登場以来、ほぼ絶え間なくこれを回避できていたのです。彼らは古いブートファイルを悪用することでこれを実現していました。驚くべきことに、Microsoftはこれらの古いファイルを信頼できる存在として認識し続けていました。その結果、これらのファイルの一部は、脆弱性の存在が公表されてから10年以上にわたって、完全に有効なままだったのです。詳細な技術情報はESETの元の調査レポートで確認できます。
シムというコンポーネントについて
この重大な問題には、シム(shim)と呼ばれる特殊なソフトウェアコンポーネントが関わっています。開発者たちは元々、Linuxシステムや初期段階のユーティリティプログラムにセキュアブート機能を拡張するためにシムを作成しました。当初、Microsoftはこれら特定のファイルに公式のデジタル証明書で署名を行っていました。その後、コンピューターのファームウェアは、起動プロセスの重要な段階でこれらの署名済みファイルの実行を許可していました。調査の過程で、研究者たちは明らかに脆弱な11個のシムイメージを特定しました。この危険なグループの中で最も古いファイルは2013年にまで遡り、セキュアブートの正式な発表からわずか1年後のものでした。
残存する信頼のリスク
セキュリティ専門家たちは、これらのコンポーネントに含まれる脆弱性について長年前から把握していました。それにもかかわらず、Microsoftはそれらを公式の失効リストに追加しませんでした。その結果、コンピューターは暗黙のうちにこれらの旧バージョンを信頼し続けていました。一方で、悪意ある攻撃者たちは容易にこれらを悪用し、署名されていない、あるいは極めて有害なコードを実行できていました。さらに、この攻撃を仕掛けるにあたって、新たなゼロデイ脆弱性を発見する必要はありませんでした。高度に洗練された技術的操作も必要ありませんでした。攻撃者はただ、いまだ有効な状態にある古いシムファイルのコピーを1つ入手すればよかったのです。
バイパスの手口
もちろん、侵入者はUEFIの起動シーケンス全般に関する基本的な理解も必要としていました。この脆弱なコンポーネントを起動すると、攻撃者は意図的にデジタル署名の検証チェーンを破壊できます。最終的に、これによってコンピューターの電源投入の最も初期の段階で危険なマルウェアをインストールできてしまいます。重要なのは、この深刻な脅威がLinux環境とWindows環境の双方を等しく脅かすという点です。シムは元々主にLinux向けに作られたものでしたが、UEFIファームウェアは信頼された起動ファイルを特定のオペレーティングシステムに紐付けているわけではありません。
持続的なブートキットの脅威
したがって、あるコンポーネントが有効なMicrosoftの署名を持ってさえいれば、攻撃者はそれをWindowsマシン上で容易に実行できてしまいます。セキュアブートの回避に成功した後、侵入者はブートキットをインストールするという恐ろしい能力を手に入れます。ブートキットとは、メインのオペレーティングシステムが読み込まれる前に実行される特殊なマルウェアの一種です。その結果、コンピューターの起動シーケンス全体に対して積極的に干渉を行います。従来型のウイルス対策ソフトウェアでは、こうしたソフトウェアを検出することが困難です。これは、ほとんどの標準的なセキュリティツールが起動するよりもずっと前の段階で、ブートキットが活動を開始してしまうためです。
深いシステムアクセスの維持
さらに、ブートキットはWindowsやLinuxを完全に再インストールした後でも、しぶとく生き残ることがあります。場合によっては、主要なハードドライブを完全に交換しても生存し続けることさえあります。これは、マルウェアがマザーボードのファームウェアや隠れたシステムパーティションに直接組み込まれた場合に発生します。その結果、攻撃者は感染したデバイスに対して非常に持続性の高い、長期にわたるアクセスを確保することになります。彼らはコアシステムコンポーネントを自由に改変したり、重要なセキュリティ機能を完全に無効化したりできます。さらに、追加の悪意あるペイロードを継続的にダウンロードし、展開することも可能です。
セキュアブートが本来約束していたもの
Microsoftは元々、こうした深いレベルの攻撃からまさに防御するために、2012年にセキュアブートを導入しました。この機構は、コンピューターの電源投入時に実行されるあらゆるコンポーネントについて、デジタル署名を厳密に検証します。あるファイルが信頼できる証明書を持っていない場合、ファームウェアは直ちに起動プロセスを停止しなければなりません。同様に、システムが以前にその証明書を失効させていた場合にも停止しなければなりません。過去10年の間に、セキュリティ専門家たちはいくつもの危険な実在のブートキットを発見してきました。
実在するブートキットの事例
こうした注目すべき脅威には、LoJax、MosaicRegressor、CosmicStrand、BlackLotusなどが含まれます。研究者たちは、これらの高度なツールの一部を国家支援を受けたハッキンググループに直接関連付けています。一方で、サイバー犯罪者たちはその他の亜種をアンダーグラウンドのハッキングフォーラムで公然と販売していました。これらの攻撃の大多数は、標的デバイスへの物理的アクセスを絶対的に必要とします。しかし、一部の複雑な感染チェーンでは、攻撃者が高権限のシステム権限を確保した後にリモートでブートキットをインストールすることも可能です。短時間の、機会主義的な物理アクセスから防御することが、セキュアブートの主要な目的の一つであり続けています。
脆弱なファイルの範囲
例えば、攻撃者は電源が切られたノートパソコンを短時間だけ手に入れることがあります。彼らは外部USBドライブから脆弱なコンポーネントを素早く読み込むことができます。こうして、正当な所有者にデバイスを返却するよりもずっと前に、悪意あるコードをインストールしてしまうのです。CERTが作成した包括的なリストには、危険にさらされたシムファイルの詳細が記載されています。このリストには、Red Hat、openSUSE、Oracle、および様々なサードパーティ製アプリケーションに関連するコンポーネントが含まれています。驚くべきことに、フィンランドの企業PC-Doctorのコンポーネントまでもが含まれていました。当局は以前、この特定のソフトウェアを国家試験システム内で使用していました。
欠陥と第2段階のエクスプロイト
開発者たちは、これらの欠陥あるファイルの一部を、最新の失効メカニズムが考案されるよりもずっと以前にリリースしていました。逆に、他のファイルには、それ自体のソースコード内に深刻な論理的エラーが含まれていました。さらに、一部のバージョンは、極めて脆弱な第2段階の起動コンポーネントの実行を危険にも許可していました。Windowsのエコシステムにおいて、信頼の主要な源泉は公式のMicrosoftブートローダーであり続けています。同社はこの重要なファイルに、自社のルート証明書を用いて直接署名を行います。その結果、後続のすべてのコンポーネントは、実行前に厳格なセキュリティチェックを通過しなければなりません。
Linux起動の複雑さ
Linuxは大きく異なる構造的アプローチを採用しています。当然ながら、Microsoftは既存のあらゆるLinuxディストリビューション向けの、あらゆるブートローダー、カーネル、ユーティリティプログラムに個別に署名することはできません。そこで、シムはこの物流上の問題を、信頼の中間層を導入することで巧妙に解決しています。Microsoftは小さく、汎用的に互換性のあるブートローダーに安全に署名を行います。そして、特定のLinux開発者やソフトウェアメーカーが、その中に自社独自の証明書を埋め込みます。最初の起動後、シムは残りのシステムコンポーネントを独自に検証します。
シムという諸刃の剣
この洗練されたアーキテクチャ設計により、開発者はLinuxディストリビューションをシームレスに更新できるようになります。彼らは、些細なファイル修正のたびにMicrosoftに新たな署名を絶えず要請するという煩わしい手間を避けられます。しかし同時に、これは重大な二次的リスクの発生源にもなります。脆弱なシムが不適切に信頼された状態を保持し続けると、その内部に埋め込まれた証明書が、他の極めて安全性の低いコンポーネントの実行を意図せず認可してしまう恐れがあります。危険にさらされたシムファイルを失効させる最終的な責任は、Microsoftが負っています。
失効の仕組み
脆弱性を発見した際、同社はそのコンポーネントのデジタルフィンガープリントを特別なブロックリストに速やかに追加しなければなりません。あるいは、関連する証明書を追加することもできます。衝撃的なことに、今回発見された11個のイメージのケースでは、この重要な失効措置が一切行われていませんでした。一部のバージョンは10年以上にわたって危険なほど有効なままでした。同社は最終的に、6月の更新パッケージの中でのみこれらを失効させました。彼らが行動を起こしたのは、ESETが詳細な調査結果をMicrosoftおよびCERTの専門家たちと直接共有した後のことでした。この10年に及ぶ大幅な遅延の正確な理由は、現時点では明らかにされていません。
データベースの管理
信頼できるセキュアブートコンポーネントを管理することは、途方もなく複雑な物流上の取り組みです。システムファームウェアは、2つの主要なデータベースに大きく依存しています。「db」データベースは、明示的に許可された証明書とデジタルファイルフィンガープリントを安全に保存します。一方、「dbx」データベースには、システムがもはや信頼してはならないコンポーネントに関する詳細情報が含まれています。ファイルを実行する前に、システムはこれら2つの重要なリストの両方を厳密にチェックします。ファイルは、許可されたデータベースからの有効な署名を持っていなければなりません。
ストレージ容量の限界という課題
同時に、そのファイルは失効したコンポーネントのリストに一切含まれていない状態でなければなりません。脆弱なブートローダーが「db」リストに残ったまま「dbx」リストを回避していると、コンピューターは一貫してそれを完全に安全なものとみなしてしまいます。すべての安全性の低いLinuxコンポーネントを個別に「dbx」データベースへ追加することは、極めて非現実的であることが判明しました。エンジニアたちは、この重要なデータベースに対してわずか32キロバイトの総ストレージ容量しか割り当てていませんでした。一方で、利用可能なブートローダー、カーネル、ユーティリティファイルの数は絶えず増加し続けています。
高度な失効戦略
そこで、開発者たちは補完的な、バージョンベースの失効メカニズムを巧みに考案しました。代表的な解決策の一つが、一般にSBATとして知られるSecure Boot Advanced Targetingシステムです。個々のファイルの巨大なデジタルフィンガープリントを保存する代わりに、このシステムは単純にコンポーネント名とその世代番号を保存します。開発者が脆弱性を修正すると、彼らはバージョン番号を段階的に引き上げます。その後、更新されたセキュアブートポリシーは、以前の脆弱な世代すべての実行を自動的に禁止します。
バージョンチェックと残存する欠陥
これと類似した保護原理を利用するのが、しばしばSVNと略されるSecurity Version Number指標です。これら2つの高度なメカニズムはいずれも、管理者が脆弱なビルドのグループ全体を一括して失効させることを可能にします。これにより、限られた容量しかないデータベースを複雑なハッシュ値の膨大なリストで埋め尽くしてしまう事態を効率的に回避できます。互換性のある各コンポーネントには、その名称と世代番号を詳細に記した、安全に署名されたメタデータが含まれています。起動シーケンスの過程で、シムはこの情報を最低限許容されるバージョンのしきい値と綿密に照合します。
古いコードの危険性
ファイル番号が定められたセキュリティしきい値を下回っている場合、システムはそれを起動することを絶対に拒否します。決定的に重要なのは、この厳格なチェックがシム自体にも直接適用されるという点です。理論上、更新されたセキュリティポリシーは、旧式のブートローダーに自らの実行を拒否させることさえ可能です。その後、システムは起動チェーン内の後続のすべてのファイルに対して、まったく同一の厳格な手順を適用します。核心的な問題は、発見されたコンポーネントの一部がSBATやその他の現代的な防御メカニズムよりも前の時代のものだったという事実に起因していました。
セキュリティの今後の道筋
さらに、一部の特定のシムファイルは、Machine Owner Keyの拒否リストをまったくチェックしていませんでした。専門家たちは一般的にこれをMOK denyリストと呼んでいます。他の欠陥のあるバージョンは、以前から知られていた脆弱性を含む旧式のプログラムの起動を明示的に許可していました。例えば、あるOracle製の特定のシムは、CVE-2015-5381攻撃に対して極めて脆弱な状態のままだった二次コンポーネントを暗黙的に信頼していました。ESETの厳密な評価によれば、比較的経験の浅い専門家でさえも、この特定のエラーを首尾よく悪用できてしまうとのことです。
未来のセキュリティを守るために
一部の孤立したファイルには、それ自体に固有の内部的な欠陥が含まれていました。これらの特定の欠陥により、攻撃者は起動チェーンの検証を完全にバイパスすることができました。さらに、Microsoftの証明書が自然に期限切れとなっても、問題が自動的に解決されるわけではありませんでした。UEFIファームウェアは、管理者が正式に失効リストへ追加するまで、以前に署名されたファイルをしぶとく信頼し続けます。したがって、古いシムコンポーネントに署名した証明書が単に期限切れになったというだけでは、その危険な実行を阻止することはできませんでした。包括的な6月の更新プログラムのインストール後、Microsoftは影響を受けるWindowsデバイス上でようやくこれらの脆弱なファイルを無効化しました。Secured-core Windows 11搭載のコンピューターは、標準設定下では、高度な組み込み保護機能のおかげでこの攻撃に対しておそらく安全な状態を保っていたと考えられます。しかし、Linuxユーザーは、自分が使用しているディストリビューションが提供する具体的な推奨事項を至急確認する必要があります。また、重要な更新情報についてはLinux Vendor Firmware Serviceにも問い合わせるべきです。ユーザーはuefi-dbx-auditスクリプトを使って、自身の失効データベースの現在の状態を積極的に確認できます。製造元が特定のデバイスのハードウェア向けに新しいセキュアブートポリシーをまだ配布していない場合、単にオペレーティングシステムを更新するだけでは十分でない可能性があります。この脆弱なシムファイルをめぐる憂慮すべき経緯は、セキュリティモデル全体に潜む根深い弱点を如実に浮き彫りにしています。結局のところ、セキュアブートの真の信頼性は、強固な暗号技術だけに支えられているわけではありません。それは、何千もの個別に署名されたコンポーネントに対する、完璧かつ継続的な管理を根本的に必要としているのです。たった一つの忘れられたブートローダーが、何年にもわたって危険なままシステムの信頼を保持し続けてしまうことがあります。この破滅的な見落としは、まさにシステムが阻止するために設計された悪意あるコードに対して、破壊的な侵入経路を容易に開いてしまう可能性があるのです。
翻訳元: https://meterpreter.org/uefi-shims-secure-boot-vulnerability/
