themalwareguardian/cve-2022-34302Demonstra CVE-2022-34302, um bypass do Secure Boot através do bootloader assinado da New Horizon Datasys, cujo carregador PE/COFF personalizado integrado executa aplicações UEFI não assinadas.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Bypass do Secure Boot através de um bootloader assinado com um carregador PE/COFF personalizado incorporado que carrega aplicações UEFI não assinadas.
Este repositório demonstra a técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explorando a CVE-2022-34302, uma vulnerabilidade de bypass do Secure Boot no boot loader da New Horizon Datasys.
Ao contrário das vulnerabilidades baseadas na UEFI Shell (CVE-2022-34301 e CVE-2022-34303), este bootloader não expõe uma UEFI Shell. Em vez disso, o shdloader.efi implementa o seu próprio carregador PE/COFF personalizado que carrega um binário de segunda fase (shdmgr.ef_) sem utilizar a função LoadImage() do firmware e sem realizar qualquer verificação de assinatura. Um atacante só precisa de substituir o shdmgr.ef_ por qualquer aplicação UEFI compatível para alcançar execução de código arbitrário com o Secure Boot ativado.
Esta é a mais perigosa das três vulnerabilidades divulgadas na investigação "One Bootloader to Load Them All". Como a Eclypsium observou: o bypass é incorporado, completamente silencioso, e não deixa qualquer indicação visual no ecrã - tornando-o invisível mesmo em sistemas com monitor e indetetável em sistemas sem cabeça, como servidores ou equipamentos industriais.
BYOVUA é o equivalente UEFI da técnica BYOVD (Bring Your Own Vulnerable Driver) utilizada 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 que contém funcionalidades capazes de comprometer o Secure Boot.
Como o shdloader.efi está assinado com um certificado de confiança da Microsoft, é aceite pelo Secure Boot sem questionar, tornando-o fidedigno em qualquer sistema que inclua este certificado na sua base de dados do Secure Boot (db) - o que é praticamente todos os PCs com capacidade UEFI lançados na última década. Uma vez em execução, o seu carregador PE personalizado incorporado proporciona ao atacante a capacidade de carregar e executar código arbitrário não assinado antes do sistema operativo carregar, num ambiente onde os controlos de segurança modernos (ASLR, DEP, proteções do kernel) simplesmente não existem.
O shdloader.efi é um boot loader UEFI distribuído como parte dos produtos de restauro e recuperação de sistema da New Horizon Datasys (Reboot Restore Rx, RollBack Rx). O seu papel na cadeia de arranque legítima é carregar um componente de gestão pré-SO (shdmgr.ef_) que trata de operações de snapshot e restauro antes do sistema operativo iniciar.
A vulnerabilidade é uma falha de design na arquitetura do boot loader. Em vez de utilizar os serviços de arranque do firmware LoadImage() e StartImage() - que impõem a verificação de assinatura do Secure Boot - o shdloader.efi implementa o seu próprio carregador PE/COFF personalizado que lê, relocaliza e executa o shdmgr.ef_ diretamente a partir dos bytes brutos do disco, contornando completamente as verificações de segurança do firmware.
A questão central: um binário assinado que é fidedigno para o Secure Boot contém o seu próprio carregador de imagens que não verifica assinaturas. O firmware valida o shdloader.efi como assinado, mas uma vez em execução, este carrega o shdmgr.ef_ sem qualquer verificação. Substituir o shdmgr.ef_ por uma aplicação UEFI arbitrária resulta nessa aplicação a ser executada com acesso total ao hardware, enquanto o Secure Boot reporta como ativado.
Isto é fundamentalmente diferente da CVE-2022-34301 e CVE-2022-34303, onde o atacante precisa de interagir com uma UEFI Shell e corromper manualmente o para desativar a verificação. Aqui, o bypass é - sem interação do utilizador, sem saída visível, sem prompt de shell.
| Propriedade | Valor |
|---|
| Ficheiro | shdloader.efi = EFI/Boot/bootx64.efi |
| Fabricante | New Horizon Datasys Inc |
| Produto | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Assinatura | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| 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) |
gSecurity2O shdloader.efi assinado contém a sua própria implementação de um carregador de imagens PE/COFF. Em vez de chamar o serviço de arranque LoadImage() do firmware, que invocaria os Security Architectural Protocols e verificaria a assinatura da imagem contra a base de dados do Secure Boot, o bootloader:
\EFI\Boot\shdmgr.ef_ utilizando o EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc e aplica as relocalizações de baseEm nenhum momento deste processo o carregador verifica a assinatura Authenticode da imagem, consulta a base de dados do Secure Boot (db/dbx), ou invoca o EFI_SECURITY2_ARCH_PROTOCOL. A imagem é carregada puramente com base na sua validade estrutural PE/COFF.```c
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.
EFI_STATUS LoadShdmgr(VOID) { // Step 1: Open the file File = OpenFile(L"\EFI\Boot\shdmgr.ef_");
// Step 2: Read raw bytes (no signature check)
ReadFile(File, &Buffer, &Size);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
---
<div id='LoadImageVsCustomLoader'/>
### ***LoadImage vs Custom Loader***
A diferença entre o `LoadImage()` do firmware e o carregador personalizado é a lacuna de segurança crítica:```
┌─────────────────────────────────────────────────────────────────────────┐
│ Firmware LoadImage() - How legitimate boot chains work │
│ │
│ bootx64.efi ──> LoadImage("shdmgr.ef_") │
│ │ │
│ ├── Parse PE/COFF headers │
│ ├── Verify Authenticode signature │
│ ├── Check signature against db (allowed) │
│ ├── Check hash against dbx (revoked) │
│ ├── Call gSecurity2->FileAuthenticationState() │
│ │ │ │
│ │ ├── Signature valid? ── YES ──> Load image │
│ │ └── Signature invalid? ── NO ──> REJECT │
│ └── StartImage() │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ Custom PE Loader - What shdloader.efi does │
│ │
│ shdloader.efi ──> OpenFile("shdmgr.ef_") │
│ │ │
│ ├── ReadFile() into buffer │
│ ├── Parse PE/COFF headers │
│ ├── Allocate memory │
│ ├── Copy sections │
│ ├── Apply .reloc relocations │
│ ├── *** NO SIGNATURE CHECK *** │
│ └── Jump to EntryPoint │
│ │
│ Result: ANY valid PE/COFF EFI application runs, signed or not │
└─────────────────────────────────────────────────────────────────────────┘
O carregador PE personalizado é uma implementação simplificada e espera um layout PE/COFF específico. Binários que não estejam em conformidade são rejeitados com erros:``` Reloc table overflows binary Relocation failed Invalid entry point
Um binário que não tenha nenhum destes será rejeitado pelo carregador personalizado.
| Campo | Valor Obrigatório | Razão |
|-------|---------------|--------|
| *Machine* | `0x8664` (x64) | O carregador só suporta imagens x86-64 |
| *Subsystem* | `10` (EFI Application) | Deve ser uma EFI Application |
| *secção .reloc* | `.reloc` deve existir com entradas de realocação base válidas | O carregador realiza a sua própria realocação de imagem. Sem .reloc, falha com "Reloc table overflows binary" |
| *Relocation Directory* | `VirtualAddress` != 0, Size != 0 (DATA_DIRECTORY[5]) | A entrada do diretório deve apontar para dados de realocação válidos |
É fornecido um script de verificação (Scripts/VerifyPE.py) para verificar a compatibilidade antes da implementação.
---
<div id='BYOVD'/>
### ***Paralelo com Kernel BYOVD***
O paralelo estrutural entre UEFI BYOVUA e kernel BYOVD é exato, embora CVE-2022-34302 represente a forma mais direta - o componente assinado **ele próprio** carrega código não assinado, em vez de fornecer uma primitiva para desativar a verificação:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA - CVE-2022-34302 (Custom PE Loader) │
│ │
│ Signed Bootloader ──> Custom PE Loader ──> Load unsigned │
│ (trusted by (no sig check) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ UEFI BYOVUA - CVE-2022-34301/34303 (Shell + gSecurity2) │
│ │
│ 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) │
└──────────────────────────────────────────────────────────────┘
CVE-2022-34302 é a variante mais perigosa porque o bypass é inerente ao design do bootloader - não há etapa intermediária onde o atacante precise corromper um mecanismo de segurança. O componente assinado carrega diretamente código não assinado como sua operação normal.
O shdloader.efi assinado é colocado na EFI System Partition (ESP) como o boot loader padrão. Como é assinado pelo certificado Microsoft UEFI Driver Publisher, o Secure Boot o valida e carrega sem problemas.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── bootx64.efi (shdloader.efi) ← Signed by Microsoft Windows UEFI Driver Publisher
└── shdmgr.ef_ (PAYLOAD) ← Unsigned, loaded by shdloader's custom PE loader
Quando o sistema inicializa, o firmware:
1. Lê `bootx64.efi` da ESP
2. Chama `LoadImage()` que verifica a assinatura Authenticode contra o banco de dados do Secure Boot
3. A assinatura corresponde ao certificado Microsoft UEFI CA 2011 no `db` → a imagem é aceita
4. Chama `StartImage()` para transferir a execução para `shdloader.efi`
---
<div id='Phase2'/>
### ***Fase 2 - Ativação do Carregador PE Personalizado***
Uma vez que `shdloader.efi` tem o controle, ele imprime uma mensagem de diagnóstico e ativa imediatamente seu carregador PE/COFF personalizado:```
Booting in insecure mode
O bootloader então:
\EFI\Boot\shdmgr.ef_ usando o protocolo de sistema de arquivos.text, .data, .reloc, etc.) para a memória alocadaLoadAddress - ImageBase) e aplica todas as relocações de base da seção .relocLoadAddress + AddressOfEntryPoint como o alvo de execuçãoNenhuma verificação de assinatura ocorre em nenhum ponto deste processo. O loader não chama LoadImage(), não invoca gSecurity2->FileAuthenticationState() e não verifica os bancos de dados db ou dbx. O arquivo é carregado puramente com base na validade estrutural.
Se o arquivo não for encontrado, o bootloader reporta:``` Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E Failed to load image
---
<div id='Phase3'/>
### ***Fase 3 - Execução de Código Não Assinado***
O carregador personalizado salta para o ponto de entrada de `shdmgr.ef_`. A aplicação UEFI não assinada agora é executada com:
- Acesso total ao hardware (memória direta, portas de I/O, PCI, MMIO)
- Nenhum sistema operacional carregado ainda
- Sem ASLR, DEP ou proteções de kernel
- Sem EDR ou monitoramento de segurança de endpoint
- Secure Boot reportado como **habilitado** para qualquer consulta subsequente do SO
O ataque é completamente silencioso. Diferente de CVE-2022-34301 e CVE-2022-34303, que exibem um prompt visível do UEFI Shell, este exploit não produz saída visual além da mensagem "Booting in insecure mode" (que, em um sistema legítimo, aparece brevemente e é rapidamente substituída pela tela de boot do SO). Em sistemas headless (servidores, IoT, equipamentos industriais), não há indicação alguma.
---
<div id='Phase4'/>
### ***Fase 4 - Persistência***
O ataque é persistente por padrão. Enquanto `shdloader.efi` permanecer em `\EFI\Boot\bootx64.efi` e o payload do atacante permanecer em `\EFI\Boot\shdmgr.ef_` na ESP, o payload não assinado é executado a cada boot.
Nenhum script `startup.nsh` é necessário. Nenhum endereço gSecurity2 precisa ser recalculado entre atualizações de firmware. O carregador PE personalizado carrega qualquer `shdmgr.ef_` que encontrar, incondicionalmente.
O sistema continua a reportar o Secure Boot como "habilitado" - apenas a cadeia de confiança foi quebrada no nível do bootloader. Isso torna o ataque invisível para consultas de status do Secure Boot em nível de SO e para qualquer software de segurança que dependa da atestação do Secure Boot.
> **Importante:** A persistência só é quebrada se o DBX for atualizado com a entrada de revogação para `shdloader.efi` (KB5012170), o que faz o firmware rejeitar o próprio `shdloader.efi` antes que o carregador personalizado seja ativado.
---
---
---
<div id='Exploit'/>
## ***Exploit***
O diretório `Exploit/` contém tudo o que é necessário para compilar um `shdmgr.ef_` compatível:```
Exploit/
|
├── README.md ← Build guide and PE/COFF requirements
|
├── PayloadShdmgr/
| |
│ ├── ForceReloc.nasm ← Force .reloc section generation
│ ├── shdmgr.ef_.c ← UEFI application source (EDK2)
│ ├── shdmgr.ef_.inf ← EDK2 module definition
│ ├── shdmgr.ef_.dsc ← EDK2 platform build configuration
│ └── shdmgr.ef_.dec ← EDK2 package declaration
|
└── Scripts/
└── VerifyPE.py ← PE/COFF compatibility verifier
O bootloader assinado foi adicionado à lista de revogação DBX da Microsoft através do KB5012170 (agosto de 2022). Em sistemas atualizados, o bootloader será rejeitado pelo Secure Boot antes que o carregador PE personalizado seja ativado.
Para o ambiente de laboratório, você precisa de um sistema onde:
O QEMU UEFI Research Environment fornece uma configuração automatizada para isso.
O CVE-2022-34302 é mais simples de explorar do que o CVE-2022-34301 e o CVE-2022-34303:
| Aspecto | CVE-2022-34302 (Carregador Personalizado) | CVE-2022-34301/34303 (Shell) |
|---|
| Técnica | Substituir shdmgr.ef_ pelo payload | Corromper gSecurity2 via comando mm |
| Interação | Nenhuma (totalmente automática) | Comandos manuais de shell ou startup.nsh |
| Visibilidade | Silenciosa ("Booting in insecure mode") | Prompt do UEFI Shell visível |
| Dependência de firmware | Nenhuma (o payload é autocontido) | O endereço de gSecurity2 muda a cada build de firmware |
| Complexidade | Baixa (substituição de arquivo) | Média (varredura e patch de memória) |
| Furtividade | Alta (sem saída visual em headless) | Baixa (shell visível na tela) |