ESET expõe 11 shims UEFI assinados pela Microsoft que contornam Secure Boot: bootkits ganham chave-mestra em milhões de máquinas
Pesquisadores da ESET revelaram 11 aplicações UEFI antigas assinadas pela Microsoft que permitem executar bootkits como Bootkitty e BlackLotus mesmo com Secure Boot ativado. O certificado expirou em junho, mas segue confiável em milhões de placas-mãe.
Pesquisadores da ESET revelaram nesta semana que 11 aplicações UEFI antigas assinadas pela Microsoft podem ser abusadas para contornar o Secure Boot em praticamente qualquer computador do mundo. A falha não exige uma nova vulnerabilidade: basta uma cópia de um shim antigo, ainda assinado e não revogado, para carregar bootkits como Bootkitty, HybridPetya ou BlackLotus antes mesmo do sistema operacional iniciar — e essa capacidade permanece ativa mesmo após a expiração do certificado “Microsoft Corporation UEFI CA 2011” em 27 de junho de 2026.
O que aconteceu
Em relatório publicado hoje (14 de julho de 2026), o pesquisador Martin Smolár, da ESET, detalhou como binários shim UEFI antigos — desenvolvidos originalmente para permitir que distribuições Linux inicializassem com Secure Boot ativado — se transformaram em uma porta escancarada para bootkits. Todos os 11 binários identificados foram assinados no passado pela autoridade certificadora da Microsoft, cuja chave “Microsoft Corporation UEFI CA 2011” expirou em 27 de junho de 2026, mas continua embarcada como raiz de confiança em milhões de placas-mãe fabricadas na última década.
O shim é um bootloader leve, de código aberto, 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 carreguem com o Secure Boot ativo, já que ele próprio é assinado por uma chave em que o firmware confia por padrão — geralmente a da Microsoft, cujos certificados vêm pré-instalados na maioria dos dispositivos UEFI.
A sequência de boot funciona assim: o firmware UEFI carrega o shim e valida sua assinatura contra a CA da Microsoft armazenada no firmware. Em seguida, o shim valida o bootloader de segunda etapa (normalmente o GRUB 2) contra o certificado do fornecedor incorporado. Por fim, o GRUB 2 valida o kernel usando o mesmo certificado. A empresa de segurança eslovaca ESET afirma que os shims antigos, mas ainda considerados confiáveis, podem ser explorados para executar código arbitrário durante a inicialização — abrindo caminho para bootkits UEFI como Bootkitty, HybridPetya ou BlackLotus, mesmo com Secure Boot habilitado.
Como o ataque funciona
O truque explora a natureza da confiança no ecossistema UEFI. O Linux possui uma lista MOK (Machine Owner Key) que permite ao usuário autorizar drivers não assinados enquanto o Secure Boot está ativo. Uma denylist MOK foi introduzida na versão 0.9 do shim como forma de revogar certificados antigos associados a binários vulneráveis. Mas o que a ESET demonstrou é elegantemente simples: um atacante substitui o shim atualizado da vítima por uma versão antiga, ainda assinada pela Microsoft, e ignora a aplicação da denylist porque a allowlist continua confiando no certificado antigo.
O ataque também subverte o Secure Boot Advanced Targeting (SBAT), mecanismo desenhado para revogar componentes vulneráveis por versão ao invés de manter uma lista massiva de hashes. Como o SBAT age no nível do binário, um shim antigo com uma métrica SBAT desatualizada acaba sendo aceito, permitindo que o invasor obtenha execução de código antes mesmo do carregamento do kernel — posição privilegiada para instalar um bootkit persistente que sobrevive a reinstalações do sistema operacional.
“A questão não é uma vulnerabilidade nova — é que nenhuma vulnerabilidade nova é necessária para contornar o UEFI Secure Boot. O atacante precisa apenas de uma cópia de um shim antigo, ainda confiável e não revogado, e um entendimento básico de como shims UEFI funcionam. Isso é suficiente para contornar um recurso de segurança tão essencial quanto o Secure Boot.”
ESET, em nota técnica
Quem é afetado
O escopo do problema é praticamente universal. Segundo a ESET, qualquer máquina baseada em UEFI que confie no certificado “Microsoft Corporation UEFI CA 2011” está exposta — independentemente do sistema operacional instalado (Windows, Linux ou variantes). Isso porque a raiz de confiança está no firmware da placa-mãe, não no SO carregado depois. Entre os fornecedores cujos shims antigos foram identificados como abusáveis estão distribuições populares e projetos derivados de terceiros que compilaram versões próprias assinadas pela Microsoft.
- PCs corporativos e desktops residenciais fabricados entre 2011 e 2026
- Servidores de datacenter que não migraram para o novo certificado “Microsoft UEFI CA 2023”
- Máquinas Linux com Secure Boot ativado (mesmo em distribuições atualizadas)
- Instalações Windows onde o firmware ainda confia na CA de 2011
- Sistemas embarcados e appliances industriais com firmware raramente atualizado
Análise: por que este achado importa
A descoberta ilumina um problema estrutural da cadeia de confiança UEFI que já apareceu em incidentes anteriores — BlackLotus (2023) e Bootkitty (2024) exploraram vetores similares para atingir persistência no nível do firmware. O padrão é sempre o mesmo: binários assinados no passado permanecem confiáveis porque atualizar o mecanismo de revogação exige distribuir uma nova versão do banco de dados DBX através dos fabricantes de firmware, um processo lento e fragmentado. Mesmo quando a Microsoft revoga um binário, dezenas de milhões de máquinas continuam operando com a lista antiga por meses ou anos.
Este achado é particularmente inconveniente porque o certificado “2011” expirou em junho, sendo substituído pelo “Microsoft UEFI CA 2023”. A expiração, porém, não retira automaticamente a confiança — ela apenas indica que novas assinaturas não devem ser emitidas com aquela chave. O firmware continua aceitando binários assinados enquanto a chave estiver na lista DB. Trocar a raiz de confiança em produção exigirá atualizações de firmware em cada dispositivo, algo que historicamente leva anos para atingir a maioria da base instalada.
Do ponto de vista defensivo, o ataque preserva uma característica que preocupa: ele não deixa rastros no sistema operacional. Um bootkit UEFI é carregado antes de qualquer solução EDR ou antivírus, e pode filtrar seletivamente o que os sistemas de detecção veem. Combinado com o fato de que, no Brasil, poucas organizações monitoram integridade de firmware, o vetor tende a ficar disponível para atacantes por muito tempo.
Recomendações práticas
- Atualizar firmware e Secure Boot DBX: aplicar as atualizações mais recentes do fabricante da placa-mãe, que devem incluir revogações para os binários vulneráveis identificados pela ESET.
- Migrar para a CA de 2023: verificar se o firmware suporta “Microsoft UEFI CA 2023” e configurar o sistema para confiar apenas na chave nova sempre que possível.
- Monitorar integridade de firmware: adotar ferramentas como CHIPSEC, fwupd (Linux) ou soluções comerciais que verificam hashes de firmware em runtime.
- Reduzir acesso físico e local privilegiado: a exploração exige capacidade de gravar no ESP (EFI System Partition), o que geralmente demanda privilégios administrativos. Endurecer o controle de administradores locais eleva significativamente o custo do ataque.
- Aplicar TPM measured boot e Attestation: com PCRs medidos, um bootkit deixa rastros criptográficos verificáveis remotamente por servidores de attestation.
- Inventariar máquinas em risco: use scripts para listar quais dispositivos ainda confiam na CA de 2011 e priorize aqueles em ambientes críticos.
Fonte: The Hacker News
