themalwareguardian/cve-2022-34303Dé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.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Contournement de Secure Boot via un UEFI Shell signé et la corruption de gSecurity2.
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.
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.
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.
| Propriété | Valeur |
|---|---|
| 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) |
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 (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).
---