Voltar às atualizações
UpdatedSep 3, 2026

CVE-2026-25250 — Updated!

Análise e exploit para CVE-2026-25250, uma bypass do Secure Boot no Horizon DataSys Reboot Restore, onde o shdloader.efi carrega o Shield.efi sem verificação.

Compartilhar

🕷️ CVE-2026-25250: Validação Incorreta da Cadeia de Bootloader Confiável

Um bootloader de terceiros assinado pela Microsoft que carrega um binário EFI secundário sem verificação de assinatura ou integridade, colapsando a cadeia de confiança do Secure Boot a partir de dentro.




📑 Índice




🧠 Contexto da Pesquisa

Este repositório documenta a pesquisa sobre CVE-2026-25250, uma vulnerabilidade de bypass do Secure Boot divulgada à Microsoft e à qual foi atribuído um CVE em abril de 2026. Rapidamente se destacou como um dos problemas de segurança de firmware mais significativos do ano, precisamente porque o componente vulnerável é assinado pela Microsoft e, portanto, incondicionalmente confiável na grande maioria dos sistemas Windows habilitados para UEFI.

A vulnerabilidade foi descoberta por Mickey Shkatov e Stanislav Lyakhov na Eclypsium, uma das principais equipes de pesquisa de segurança de firmware e cadeia de suprimentos da indústria. Mickey Shkatov é uma figura de longa data na pesquisa ofensiva de UEFI, autor do BootHole (CVE-2020-10713, um bypass crítico do Secure Boot do GRUB2 que afetou praticamente todas as distribuições Linux e configurações de dual-boot com Windows), e apresentador de "One Bootloader to Load Them All" na DEF CON 30 ao lado de Jesse Michael, uma palestra que catalogou sistematicamente como bootloaders de terceiros assinados pela Microsoft representam uma fraqueza de classe no ecossistema do Secure Boot.

O CVE-2026-25250 se enquadra exatamente nessa classe.

O que o torna particularmente instrutivo é a sua simplicidade: sem corrupção de memória, sem falha criptográfica no próprio firmware, apenas um binário confiável tomando uma decisão insegura sobre o que carrega em seguida. Um único elo fraco é suficiente para colapsar todo o modelo do Secure Boot para um sistema alvo.




📌 Referências Oficiais

O CVE-2026-25250 foi descoberto durante a análise de componentes de boot UEFI de terceiros implantados em ambientes empresariais de recuperação. O produto afetado é a solução Reboot Restore da Horizon DataSys.

A vulnerabilidade foi atribuída pela MITRE em vez da Microsoft, porque a falha reside em firmware de terceiros (shdloader.efi), não no Windows ou em qualquer código de autoria da Microsoft.

Referências oficiais:




🔬 Reproduza Você Mesmo

A divulgação da Eclypsium, publicada no LinkedIn pela equipe descobridora, fornece contexto suficiente para identificar o software afetado e baixá-lo diretamente do site do fornecedor.

O instalador do Horizon DataSys Reboot Restore está disponível publicamente, e instalá-lo em um sistema de teste coloca tanto o shdloader.efi quanto o Shield.efi na Partição do Sistema EFI, onde podem ser examinados estaticamente ou observados em tempo de execução.

Configuração de laboratório recomendada:

VM Windows 10/11 (QEMU ou VMware)
├── Secure Boot: Ativado
├── Horizon DataSys Reboot Restore: Instalado
├── ESP acessível via: mountvol X: /S
└── Alvos:
	HorizonDataSys
        X:\EFI\shdloader.efi ← assinado, confiável, carrega o próximo estágio
        X:\EFI\Shield.efi    ← carregado sem qualquer verificação

Uma vez instalado, o shdloader.efi pode ser confirmado como assinado pela Microsoft CA 2011 via sigcheck.exe (Sysinternals) ou pesign. A ausência de qualquer chamada LoadImage / StartImage no caminho de carregamento do Shield.efi é visível imediatamente na análise estática.




🐜 Cadeia de Boot Vulnerável

Esta vulnerabilidade afeta uma cadeia de boot em múltiplos estágios, não um único binário.


🧨 Estágio 1 - Bootloader Confiável

  • shdloader.efi
    • Assinado digitalmente com Microsoft UEFI CA 2011
    • Incondicionalmente confiável pela política de firmware do Secure Boot
    • Instalado na ESP pelo software Horizon DataSys

⚠️ Estágio 2 - Payload Não Verificado

  • Shield.efi
    • Carregado dinamicamente pelo shdloader.efi no momento do boot
    • ❌ Sem verificação de assinatura
    • ❌ Sem verificação de integridade
    • ❌ Sem uso das APIs UEFI LoadImage / StartImage
    • ✅ Livremente substituível por qualquer Administrador local

📌 Observação Chave

A vulnerabilidade não reside no firmware. Ela reside na lógica de um bootloader confiável, um binário que o firmware já aprovou, que escolhe carregar um binário secundário através de um caminho de código que ignora todas as verificações de segurança.

Firmware
  └── verifica shdloader.efi          ✅ Microsoft CA 2011, confiável
        └── ManualPEParse(Shield.efi) ❌ sem LoadImage, sem verificação de assinatura
              └── EntryPoint()        💥 código controlado pelo atacante, pré-OS

O perímetro do Secure Boot é tão forte quanto o binário menos cuidadoso que ele confia.




🧪 Visão Geral da Vulnerabilidade

O CVE-2026-25250 é um bypass do Secure Boot causado pela validação incorreta de um binário EFI secundário carregado durante o processo de boot. O bootloader afetado (shdloader.efi) é assinado e confiável pelo Secure Boot, mas carrega o Shield.efi através de uma rotina manual de parsing de PE sem qualquer verificação criptográfica de nenhum tipo.

É uma falha de design e de modelo de confiança, um componente confiável tomando uma decisão insegura que anula todas as proteções a jusante.


🔐 Secure Boot e Modelo de Confiança

O Secure Boot impõe uma cadeia de confiança na qual cada componente executado durante a sequência de boot deve ser verificado antes que o controle seja transferido. O modelo só se mantém se cada binário confiável na cadeia honrar esse contrato:

Firmware → verifica bootloader → bootloader executa apenas código verificado

O CVE-2026-25250 quebra o segundo elo:

Firmware → verifica shdloader.efi (✅ confiável)
             ↓
           shdloader.efi → carrega Shield.efi (❌ não verificado)
                             ↓
                           Código arbitrário não assinado executa pré-boot

A aplicação do Secure Boot no nível do firmware torna-se irrelevante uma vez que um binário confiável introduz um caminho de execução não verificado.


🧬 Análise de Causa Raiz

Classificado como:

EtapaExecutadaObservações
Localizar Shield.efi na ESPAcesso padrão ao sistema de arquivos
Ler arquivo na memória-
Analisar cabeçalhos PE manualmenteImplementação personalizada
Verificar assinaturaNão executada
Verificar contra db / dbxNão executada
Chamar LoadImage / StartImageIgnorado completamente
Transferir execução para o entry pointChamada direta

A ausência de LoadImage / StartImage é a causa raiz. Esses Boot Services UEFI são o ponto de integração para a aplicação da política do Secure Boot; ignorá-los significa ignorar tudo.


💥 Processo de Exploração

A exploração requer acesso de Administrador local e uma única reinicialização.

  1. Montar a Partição do Sistema EFI
  2. Substituir Shield.efi por um binário EFI arbitrário não assinado
  3. Reiniciar

Na próxima inicialização, o shdloader.efi é executado (confiável pelo firmware), carrega o binário controlado pelo atacante e transfere a execução, pré-OS, pré-EDR, antes que qualquer política de boot medida seja aplicada, sem qualquer objeção do Secure Boot.

Permite:

  • Bootkits UEFI persistentes que sobrevivem a reinstalações do SO e limpezas completas de disco.
  • Implantes em estágio inicial invisíveis para qualquer ferramenta de segurança na camada do SO.
  • Evasão completa de proteções no modo kernel (EDR, PatchGuard, VBS/HVCI).



📚 Recursos




🤝 Pesquisa e Colaboração

Trabalhando em algo semelhante? Pesquisando segurança de UEFI, kernel, exploração ou outro tópico interessante de segurança? Se você precisar de ajuda para desenvolver um exploit, explorar uma técnica ou apenas quiser trocar ideias, não hesite em entrar em contato. Estou sempre aberto a discutir pesquisas, ajudar onde puder e colaborar em projetos interessantes. Sinta-se à vontade para me contatar no LinkedIn.

Categorias