Binários antigos não revogados permitem contornar mecanismos de segurança como SBAT e MOK, facilitando a implantação de bootkits persistentes.
| Componente | Shim bootloaders UEFI (versão 0.9 e anteriores) assinados pela autoridade certificadora 'Microsoft Corporation UEFI CA 2011'. |
| Vetor | Substituição do shim atual por uma versão antiga e vulnerável, explorando a confiança contínua no certificado CA 2011 e a ausência de revogação por hash, permitindo bypass de listas de revogação MOK e verificações SBAT. |
| Impacto | Bypass completo do UEFI Secure Boot, execução de código arbitrário durante a inicialização, instalação de bootkits (ex: BlackLotus, Bootkitty) e persistência que sobrevive à reinstalação do sistema operacional. |
| Prioridade | Aplicar atualizações do Patch Tuesday de junho de 2026 para revogar os binários vulneráveis no DBX e atualizar softwares que utilizam shims antigos. |
Pesquisadores de cibersegurança identificaram 11 aplicativos UEFI antigos, assinados pela Microsoft, que podem ser abusados para contornar o mecanismo Secure Boot na maioria dos sistemas que utilizam o padrão de firmware moderno. A falha central reside na confiança contínua depositada na autoridade certificadora de terceiros 'Microsoft Corporation UEFI CA 2011'. Embora este certificado tenha expirado em 27 de junho de 2026 e tenha sido substituído por novas CAs (Microsoft UEFI CA 2023 e Microsoft Option ROM UEFI CA 2023), binários assinados com a chave antiga continuam sendo aceitos por firmware que não possui revogações atualizadas.
O componente crítico envolvido é o 'shim', um bootloader UEFI de código aberto e leve que atua como intermediário entre o firmware da placa-mãe e o sistema operacional Linux. Sua função principal é permitir que distribuições Linux inicializem com o Secure Boot ativado, validando o carregador de segunda etapa (geralmente GRUB 2) e o núcleo (kernel). O problema detectado é que versões antigas do shim, especificamente até a versão 0.9, continham vulnerabilidades que nunca foram tratadas por fornecedores que utilizam esses binários em seus produtos comerciais.
Em um cenário de ataque, um adversário com privilégios administrativos ou capacidade de modificar o processo de boot pode substituir o shim atual e corrigido do sistema por uma das 11 variantes antigas e ainda assinadas pela Microsoft. Como o firmware valida a assinatura digital do shim contra o certificado Microsoft CA 2011 armazenado na memória não volátil, o binário antigo é aceito como confiável. A exploração subsequente depende de falhas presentes nessas versões legadas, rastreadas sob os identificadores CVE-2026-8863 e CVE-2026-10797.
A técnica de ataque subverte dois mecanismos de segurança defensiva: o Machine Owner Key (MOK) e o Secure Boot Advanced Targeting (SBAT). O MOK permite que usuários autorizem drivers não assinados, e versões mais recentes do shim implementam uma 'denylist' MOK para revogar certificados antigos associados a binários vulneráveis. No entanto, ao executar um shim antigo, o atacante contorna essa verificação, pois o binário legado não respeita as listas de revogação atuais. Além disso, o ataque anula o SBAT, um mecanismo projetado para revogar componentes de boot vulneráveis definindo uma geração mínima aceitável. Versões antigas do shim simplesmente não verificam os metadados SBAT ou a versão do componente, permitindo que carregadores de boot inseguros sejam executados.
A exposição afeta qualquer máquina baseada em UEFI que confie no certificado 'Microsoft Corporation UEFI CA 2011', independentemente do sistema operacional instalado, desde que o binário shim antigo possa ser introduzido. A situação cria um risco de longo prazo na cadeia de suprimentos, pois componentes de boot desatualizados e vulneráveis puderam ser executados em sistemas totalmente corrigidos devido à falta de revogação explícita na lista de revogação DBX assinada pela Microsoft.
Produtos específicos foram identificados utilizando versões vulneráveis do shim em suas instalações, incluindo o baramundi Management Suite (até 2024R1, usando shim 0.8), o WipeDrive da WhiteCanyon/Blancco (versões 8.0.0 a 8.1.3, usando shim 0.7), o sistema Abitti 1 do Conselho de Exames de Matrícula da Finlândia (1.0, usando shim 0.8) e o PC Doctor Service Center da PC-Doctor, Inc. (versões 15 e 16, usando shim 0.9).
- Sistemas Linux com shims não atualizados (versão ≤ 0.9).
- Softwares de gerenciamento e recuperação que empacotam o shim UEFI legado.
- Ambientes onde o controle MOK e SBAT depende de versões recentes do shim.
A detecção dessa atividade é complexa, pois a execução maliciosa ocorre antes do carregamento do sistema operacional e de quaisquer agentes de segurança ou EDR. A defesa deve focar na auditoria do ambiente de pré-boot e na verificação de versões de componentes. È essencial monitorar logs de firmware e Event Tracing for Windows (ETW) para tentativas de inicialização que falham inesperadamente ou que indicam a carga de versões de shim incompatíveis com as políticas atuais de SBAT.
Equipes de resposta a incidentes devem verificar a presença de arquivos de shim anteriores à versão 15 (que corresponde à versão do projeto 0.9 ou anteriores) nas partições EFI do sistema. A análise forense deve incluir o escaneamento do NVRAM em busca de tentativas de modificação das variáveis de boot ou da introdução de binários não autorizados na cadeia de inicialização.
- Verificar a versão do binário
shimx64.efi(ou arquiteturas correspondentes) na partição do sistema EFI. - Auditar variáveis de firmware UEFI para alterações não autorizadas em BootOrder ou Boot####.
- Revisar logs por erros de integridade de SBAT ou falhas de validação de assinatura de drivers.
A principal medida corretiva envolve a aplicação das atualizações de segurança lançadas pela Microsoft em junho de 2026 (Patch Tuesday). Essa atualização revoga as assinaturas dos 11 shims vulneráveis através da lista de revogação DBX, impedindo que eles sejam carregados, mesmo que possuam uma assinatura válida. Administradores de sistema devem garantir que atualizações de firmware e banco de dados de assinaturas (DBX) sejam aplicadas rigorosamente.
Para fornecedores e usuários de Linux, é imperativo atualizar para a versão mais recente do pacote shim fornecida pela distribuição, que inclui correções para as vulnerabilidades discutidas. No caso de produtos comerciais específicos listados como afetados, os usuários devem atualizar imediatamente para a versão mais recente fornecida pelo fabricante, que deve ter empacotado uma versão corrigida do bootloader.
- Aplicar atualizações de segurança de junho de 2026 para revogação de DBX.
- Atualizar o pacote shim para versões superiores a 0.9 em todas as distribuições Linux.
- Contactar fornecedores de softwarethird-party que utilizem UEFI para confirmar o uso de shims atualizados e seguros.
0 Comentários