themalwareguardian/cve-2022-34303Demonstra o bypass do Secure Boot da CVE-2022-34303 por meio do UEFI Shell assinado pela CryptoPro, usando o comando mm para anular o gSecurity2 e carregar aplicações UEFI não assinadas.
CryptoPro Secure Disk UEFI Shell - Traga Sua Própria Aplicação UEFI Vulnerável (BYOVUA) - Bypass do Secure Boot via UEFI Shell assinado e corrupção do gSecurity2.
Este repositório demonstra a técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explorando a CVE-2022-34303, uma vulnerabilidade de bypass do Secure Boot no ambiente de boot UEFI do CryptoPro Secure Disk.
Neste caso, o componente confiável para o Secure Boot é um shim personalizado assinado pela UEFI Third Party Certificate Authority da Microsoft. Uma vez executado, este shim carrega um UEFI Shell como segundo estágio, o que expõe o comando mm (memory modify) e, portanto, fornece capacidades de leitura e escrita arbitrária de memória durante a fase de boot pré-SO.
Esta primitiva pode então ser usada para localizar e anular o ponteiro global gSecurity2 no núcleo DXE. Como resultado, a verificação subsequente de imagens UEFI é desativada, permitindo que aplicações UEFI não assinadas, bootkits, sejam carregadas apesar do Secure Boot estar habilitado.
BYOVUA é o equivalente UEFI da técnica BYOVD (Bring Your Own Vulnerable Driver) usada no nível de kernel. Em vez de trazer um driver de kernel assinado com uma vulnerabilidade, o atacante traz uma aplicação UEFI assinada - neste caso, um UEFI Shell completo - que contém funcionalidades capazes de comprometer o Secure Boot.
Como a aplicação - neste caso, o shim personalizado que carrega o UEFI Shell como segundo estágio - é assinada com um certificado confiável da Microsoft, ela é aceita pelo Secure Boot sem questionamentos, tornando-se confiável em qualquer sistema que inclua este certificado em seu banco de dados do Secure Boot (db) - o que é praticamente todo PC com capacidade UEFI vendido na última década. Uma vez em execução, seus comandos integrados fornecem ao atacante acesso direto ao hardware e à memória que opera antes do sistema operacional carregar, em um ambiente onde controles de segurança modernos (ASLR, DEP, proteções de kernel) simplesmente não existem.
Shell_Full.efi é um UEFI Shell distribuído como parte do CryptoPro Secure Disk, um produto de autenticação pré-boot e criptografia de disco.
| Propriedade | Valor |
|---|---|
| Arquivo | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Fabricante | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Assinatura | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Descoberta | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto de 2022 |
| Apresentação | DEF CON 30 - "One Bootloader to Load Them All" |
| Revogação | Adicionado ao DBX via Microsoft KB5012170 (Agosto de 2022) |
A vulnerabilidade não é um bug - é uma falha de design. UEFI Shells são ferramentas de diagnóstico legítimas que nunca foram projetadas para serem executadas em ambientes com Secure Boot. No entanto, ao assiná-las com um certificado confiável da Microsoft e distribuí-las como parte de produtos comerciais, os fabricantes inadvertidamente criaram um bypass assinado para o Secure Boot.
A questão central: um binário assinado que é confiável para o Secure Boot fornece capacidades irrestritas de leitura/escrita de memória através de seus comandos integrados. Esta combinação quebra todo o modelo de confiança do Secure Boot.
O comando mm (memory modify) é um comando integrado padrão do UEFI Shell que fornece acesso direto de leitura e escrita à memória do sistema. Ele está documentado na UEFI Shell Specification (Seção 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parâmetro | Descrição |
|-----------|-------------|
| `Address` | Endereço de memória de destino |
| `Value` | Valor a escrever (omitir para somente leitura) |
| `-w` | Largura: 1, 2, 4 ou 8 bytes |
| `-MEM` | Acesso à memória do sistema |
| `-MMIO` | I/O mapeado em memória |
| `-IO` | Acesso à porta de I/O |
| `-n` | Não interativo (sem prompt para o próximo endereço) |
---
<div id='gsecurity2'/>
### ***gSecurity2 e o Security Architectural Protocol***
A verificação de imagem do Secure Boot em UEFI é imposta através dos [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definidos na Especificação UEFI Platform Initialization (PI).
O núcleo DXE (DxeMain) mantém um ponteiro global chamado [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), que aponta para a estrutura `EFI_SECURITY2_ARCH_PROTOCOL`. Este protocolo contém um único ponteiro de função - `FileAuthenticationState` - que é chamado por `LoadImage()` sempre que uma imagem UEFI é carregada:```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
Quando LoadImage() é chamado, o núcleo DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Ao definir `gSecurity2 = NULL`, a verificação `if` falha e `FileAuthenticationState` nunca é chamada. A verificação de imagem é completamente ignorada - **O Secure Boot permanece "ativado", mas deixa de ser aplicado**. Aplicações UEFI não assinadas podem então ser carregadas livremente.
Para uma compreensão técnica aprofundada desta técnica, incluindo uma aplicação UEFI criada especificamente para localizar e aplicar patch a gSecurity2 automaticamente, consulte o projeto complementar: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Paralelo com Kernel BYOVD***