企業向けハードウェアにおけるSecure Bootを回避するためのMicrosoft署名済みShimの流用

UbuntuなどのLinuxディストリビューションから正当な「shim-signed」パッケージを使用することで、攻撃者はMicrosoftのサードパーティ証明書を既に信頼している企業用ノートPCのSecure Boot保護を回避できる。この手法により、カスタム署名されたオペレーティングシステムがハードウェアのファームウェアによって承認され、許可されていないブートソフトウェアを防止するための整合性チェックを事実上無効化することができる。

Secure BootにおけるShimの役割

Secure Bootは、オペレーティングシステムの署名を承認済みキーのデータベースと照合することで機能する。Linuxディストリビューションはカーネルやブートローダーを頻繁に更新するため、「shim」と呼ばれる、ファームウェアとLinuxブートローダーの間の遷移を処理する、Microsoft署名済みの小さなソフトウェアを使用する。

shimは有効なMicrosoft署名を持っているため、BIOSによって信頼される。shimが実行されると、ユーザーが新しいキーをシステムの信頼データベースに手動で登録できるMOK（Machine Owner Key）登録というメカニズムが提供される。

「Secure Bootが存在する実際の理由は以下の通りである：ブートOSの整合性を確保すること。」

— Leo Smith - Not So Secure Boot

カスタムキー登録のための信頼の流用

この脆弱性は、MOK登録プロセスにBIOSパスワードなしでアクセスできる場合が多いという事実に起因する。攻撃者はUbuntuやFedoraなどのディストリビューションから正当な「shim-signed」ファイルを使用して、最初のSecure Bootチェックをパスすることができる。

この視覚資料は、MOK登録プロセスにBIOSパスワードなしでアクセスできる場合が多いという主張を裏付けるものである。

信頼されたshimが実行されると、攻撃者はMOK登録ソフトウェアを起動できる。このインターフェースにより、攻撃者は独自のカスタム証明書を選択して登録することができ、その証明書は攻撃者が自身の悪意のある、あるいは許可されていないカーネルを署名するために使用されたものである。登録後、ハードウェアは攻撃者のカスタムOSをブートチェーンの信頼されたコンポーネントとして扱う。

この画像は、本文で説明されているMOK登録ソフトウェアのインターフェースを例示したものである。

制限事項と企業による防御

この手法はカスタムOSの起動を可能にするが、データがTPMで保護されたディスク暗号化によって保護されている場合、既存のOSのデータへのアクセスを自動的に許可するわけではない。ディスク暗号化キーが特定のPlatform Configuration Registers（PCR）に紐付けられている場合、ブートチェーンが変更されたことを検知したTPMはキーの解放を拒否する。

さらに、多くの現代的な企業環境では、Microsoft IntuneやAutopilotなどの管理ツールを使用してUEFI制御をロックダウンしている。これらの制御が厳格に適用されている場合、MOK登録インターフェースにアクセスできず、高セキュリティの企業用フリートでは攻撃が成功しない可能性がある。