Demonstra o bypass do Secure Boot da CVE-2022-34301 através do UEFI Shell assinado pela Eurosoft (esdiags.efi), utilizando o comando mm para anular o gSecurity2 e carregar aplicações UEFI não assinadas.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (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-34301, uma vulnerabilidade de bypass do Secure Boot no ambiente de diagnóstico UEFI Eurosoft Pc-Check.
Neste caso, o componente confiado pelo Secure Boot é o esdiags.efi, um UEFI Shell distribuído como parte do produto de diagnóstico de hardware UEFI Pc-Check da Eurosoft, assinado por uma cadeia de certificados confiada pela Microsoft UEFI Third Party Certificate Authority. Uma vez executado, este shell 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 ativado.
BYOVUA é o equivalente UEFI da técnica BYOVD (Bring Your Own Vulnerable Driver) usada ao nível do 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 é assinada com uma cadeia de certificados confiada pelo Secure Boot, é aceite sem questionar, tornando-se confiável em qualquer sistema que inclua a Microsoft UEFI Third Party Certificate Authority na sua base de dados Secure Boot (db) - o que é praticamente todos os PCs com capacidade UEFI enviados na última década. Uma vez em execução, os seus comandos incorporados fornecem ao atacante acesso direto ao hardware e à memória que opera antes do sistema operativo carregar, num ambiente onde os controlos de segurança modernos (ASLR, DEP, proteções do kernel) simplesmente não existem.
esdiags.efi é um UEFI Shell distribuído como parte do Eurosoft Pc-Check UEFI, um produto de diagnóstico de hardware pré-boot usado por fabricantes de PCs, organizações de serviço e equipas de TI para testes de sistemas bare-metal.
| Propriedade | Valor |
|---|---|
| Ficheiro | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Fornecedor | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Assinatura | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Descoberta | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Apresentação | DEF CON 30 - "One Bootloader to Load Them All" |
| Revogação | Adicionado ao DBX via Microsoft KB5012170 (Agosto 2022) |
A vulnerabilidade não é um bug - é uma falha de design. Os UEFI Shells são ferramentas de diagnóstico legítimas que nunca foram concebidas para serem executadas em ambientes Secure Boot. No entanto, ao assiná-los com um certificado confiado pela Microsoft e distribuí-los como parte de produtos comerciais, os fornecedores criaram inadvertidamente um bypass assinado para o Secure Boot.
A questão central: um binário assinado que é confiado pelo Secure Boot fornece capacidades irrestritas de leitura/escrita de memória através dos seus comandos incorporados. Esta combinação quebra todo o modelo de confiança do Secure Boot.
O comando mm (memory modify) é um comando incorporado padrão do UEFI Shell que fornece acesso direto de leitura e escrita à memória do sistema. Está documentado na UEFI Shell Specification (Secçã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 já não é aplicado**. Aplicações UEFI não assinadas podem então ser carregadas livremente.
Para uma compreensão técnica profunda desta técnica, incluindo uma aplicação UEFI criada especificamente para localizar e corrigir automaticamente o gSecurity2, 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 o BYOVD do Kernel***