Os UEFI shims esquecidos comprometem o Secure Boot

A equipe de pesquisa da ESET identificou 11 shim bootloaders UEFI antigos e esquecidos, nas versões 0.9 e anteriores, que podem ser usados para contornar o UEFI Secure Boot em qualquer equipamento baseado em UEFI que confie no certificado da autoridade certificadora (CA) de terceiros Microsoft Corporation UEFI CA 2011, independentemente do sistema operacional (SO) instalado. Os shims relatados podem ser explorados para executar código não confiável durante a inicialização do sistema, permitindo que cibercriminosos implantem bootkits UEFI maliciosos (como Bootkitty, HybridPetya ou BlackLotus) mesmo em sistemas com o UEFI Secure Boot habilitado. Reportamos nossas descobertas ao CERT/CC em fevereiro de 2026, e os aplicativos UEFI vulneráveis foram revogados na Patch Tuesday da Microsoft de 9 de junho de 2026.

Embora dois identificadores CVE tenham sido atribuídos a este caso para cobrir os shims relatados, CVE-2026-8863 e CVE-2026-10797, a exploração de cada shim relatado não se limita a um ou dois erros específicos presentes diretamente nesses shims antigos. Na verdade, a superfície de ataque é ampliada pelos bootloaders de segunda etapa nos quais esses shims confiam (principalmente o GRUB 2), os quais, assim como os próprios shims, podem incluir versões obsoletas com vulnerabilidades conhecidas. Os shims descobertos provêm de diversas ferramentas e pacotes de software, incluindo programas de diagnóstico de PC, distribuições Linux e outros utilitários baseados em UEFI. É importante destacar que a exploração não se limita a sistemas com o software ou o SO afetado instalado, já que os atacantes podem levar sua própria cópia dos shims vulneráveis para qualquer sistema UEFI que tenha o certificado UEFI de terceiros da Microsoft registrado.

A lista completa de produtos de software que dependem dos shims relatados, junto com suas versões afetadas, está disponível na Vulnerability Note do CERT/CC. Em resposta ao relato da equipe de pesquisa da ESET, os shim bootloaders UEFI com os seguintes hashes PE Authenticode foram revogados na atualização de dbx incluída na Patch Tuesday de 9 de junho:

• AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
• 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
• EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
• FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
• A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
• 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
• 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
• 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
• 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
• 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
• 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

Principais pontos desta publicação:

• A equipe de pesquisa da ESET descobriu 11 aplicativos UEFI antigos assinados pela Microsoft que permitem contornar o UEFI Secure Boot na maioria dos sistemas baseados em UEFI.
• Cibercriminosos que explorem um desses aplicativos vulneráveis podem executar código não confiável durante a inicialização do sistema, permitindo a implantação de bootkits UEFI maliciosos ou outros malwares.
• A exploração não se limita a sistemas com o software ou o SO afetado instalado, já que os cibercriminosos podem levar sua própria cópia dos binários vulneráveis para qualquer sistema UEFI que tenha o certificado UEFI de terceiros da Microsoft registrado.
• Todos os sistemas UEFI com a assinatura UEFI de terceiros da Microsoft habilitada estão afetados (os PCs Windows 11 Secured-core devem ter essa opção desabilitada por padrão).
• Os binários vulneráveis foram revogados pela Microsoft na atualização da Patch Tuesday de 9 de junho de 2026.

A seguir, apresentamos a cronologia da divulgação coordenada. Agradecemos ao CERT/CC por sua ajuda na coordenação do processo de divulgação, e aos fornecedores afetados por sua comunicação transparente e cooperação durante a mitigação do problema. Para proteger seus sistemas contra essa ameaça, instale as atualizações mais recentes do dbx da Microsoft. As instruções podem ser consultadas na seção Proteção e detecção.

Cronologia da divulgação coordenada

• 16/02/2026 – A ESET reportou as descobertas, junto com uma prova de conceito, ao CERT/CC.
• 18/03/2026 – Foi fixado o dia 19 de maio de 2026 (Patch Tuesday de maio) como data para a atualização do dbx e a divulgação pública.
• 30/03/2026 – A atualização do dbx e a divulgação pública foram adiadas para 9 de junho de 2026 (Patch Tuesday de junho).
• 09/06/2026 – Publicação da atualização de junho da Microsoft e da Vulnerability Note do CERT/CC .
• 14/07/2026 – Publicação da postagem do blog da ESET.

UEFI shim bootloader e UEFI Secure Boot

Para compreender o impacto que esses shims vulneráveis podem ter em sistemas protegidos pelo UEFI Secure Boot, precisamos entender como funciona o UEFI Secure Boot e como os shim bootloaders UEFI assinados ampliam a cadeia de confiança do Secure Boot. Nesta seção, veremos os conceitos básicos do UEFI Secure Boot, como os shims UEFI ampliam a cadeia de confiança do UEFI Secure Boot e duas funcionalidades relacionadas aos shims: Machine Owner Key (MOK) e Secure Boot Advanced Targeting (SBAT). Para quem já estiver familiarizado com a teoria, recomendamos ir direto à seção "Como contornar o Secure Boot do UEFI usando shims antigos".

UEFI Secure Boot

Como mostrado na Figura 1, quando o firmware UEFI carrega um aplicativo de inicialização, como o Windows Boot Manager ou um shim UEFI, ele verifica o binário em relação a dois bancos de dados do Secure Boot:

• db (certificados e hashes Authenticode permitidos) e
• dbx (certificados e hashes Authenticode proibidos).

A imagem precisa ser confiável de acordo com o db e não estar listada no dbx. Caso contrário, o gestor de arranque aciona uma violação de segurança em vez de executá-la. Para que isso funcione por padrão em dispositivos recém-adquiridos com UEFI Secure Boot habilitado, a maioria dos OEMs registra um conjunto de certificados UEFI da Microsoft no banco de dados db, especificamente:

• Microsoft Windows Production PCA 2011 e Windows UEFI CA 2023 (usados para assinar os próprios aplicativos de inicialização UEFI da Microsoft; o certificado de 2011 será adicionado em breve ao dbx como consequência das vulnerabilidades relacionadas ao BlackLotus).
• Microsoft Corporation UEFI CA 2011 e Microsoft UEFI CA 2023 (usados para assinar software de inicialização UEFI de terceiros, como shims de Linux, ferramentas de recuperação e utilitários de criptografia de disco).

Isso significa que qualquer pessoa que queira que seu software de inicialização seja compatível com o UEFI Secure Boot por padrão pode enviar seus binários à Microsoft para que sejam assinados através do Windows Hardware Dev Center. Uma vez aprovados, os arquivos assinados passam a ser confiáveis na grande maioria dos sistemas UEFI. Como resultado, a Microsoft desempenha um papel central na proteção da maioria dos dispositivos baseados em UEFI, decidindo efetivamente o que é permitido e o que não é permitido executar durante a inicialização.

Revogação de UEFI (dbx)

O design de revogação do UEFI Secure Boot é simples: quando um aplicativo de inicialização anteriormente confiável, cujo hash PE Authenticode ou o certificado que o assinou está presente no db, se mostra vulnerável, seu hash PE Authenticode é adicionado ao dbx, o banco de dados de assinaturas proibidas administrado pela Microsoft (cujo conteúdo mais recente costuma ser publicado no repositório do GitHub da Microsoft). Os próprios certificados são revogados apenas ocasionalmente. Embora a ideia original de revogar binários vulneráveis individuais por meio de hash pudesse fazer sentido quando o Secure Boot foi introduzido, casos como o BootHole e o BlackLotus mostram que essa abordagem está longe de ser ideal. O problema fundamental é a escala, e isso fica bem refletido na proposta e especificação do SBAT feita pela equipe de Bootloader da Red Hat:

Como parte do recente incidente de segurança "BootHole" CVE-2020-10713, 3 certificados e 150 hashes de imagens foram adicionados ao banco de dados de revogação dbx do UEFI Secure Boot na popular arquitetura x64. Esse único evento de revogação consome 10 kB dos 32 kB, aproximadamente um terço, do armazenamento de revogações normalmente disponível nas plataformas UEFI. Devido à forma como o UEFI mescla as listas de revogação, isso, somado a eventos de revogação anteriores, pode resultar em um dbx de quase 15 kB de tamanho, chegando perto de 50% de sua capacidade.

A mesma pressão sobre a capacidade do dbx voltou a aparecer com as revogações relacionadas ao BlackLotus de binários vulneráveis do Windows Boot Manager. Os dois casos levaram a Microsoft, junto com seus parceiros, a introduzir mecanismos de revogação adicionais baseados em versões, cada um associado a um dos dois bootloaders compatíveis com Secure Boot mais amplamente implantados:

• Secure Boot Advanced Targeting (SBAT), usado pelo shim, um bootloader UEFI para Linux, a partir da versão 15.3.
• O «Secure Boot Security Version Number» (SVN) da Microsoft, usado pelo Windows Boot Manager (lançado em abril de 2024) e também chamado de «Revocation via Embedded Secure Version Information» (REVISE) na obra de Bill Demirkapi Booting with Caution, p. 62. Esse nome e essa sigla, porém, não parecem ser usados na documentação oficial da Microsoft.

Em resumo, enquanto o dbx revoga binários, o SBAT e o Secure Boot SVN da Microsoft revogam versões. Quando é encontrada uma vulnerabilidade em um aplicativo UEFI que oferece suporte a um desses mecanismos de revogação baseados em versão, o que realmente precisa ser bloqueado são todas as builds até e incluindo a vulnerável. E isso pode ser representado por um número de versão de forma muito mais simples do que por uma longa lista de hashes. Explicamos mais sobre o SBAT na seção Secure Boot Advanced Targeting (SBAT).

UEFI shim bootloader e Secure Boot

Com as distribuições Linux compatíveis com o UEFI Secure Boot, o mecanismo de Secure Boot descrito acima, construído em torno das chaves da Microsoft, traz alguns desafios. Cada distribuição Linux gera seus próprios binários de bootloader, e cada um tem um hash diferente. Conseguir que a Microsoft assine diretamente cada bootloader do Linux seria lento, burocrático e praticamente impossível de manter para todas as distribuições Linux.

A solução para esse problema é um shim: um bootloader pequeno e minimalista de primeira etapa que a Microsoft pode revisar e assinar uma única vez, e que então cria uma âncora de confiança secundária para o restante da cadeia de inicialização específica da distribuição Linux, normalmente o GRUB 2 e o kernel do Linux. Essa âncora de confiança é outro certificado, chamado vendor certificate (administrado pelo fornecedor da distribuição), que é adicionado ao binário do shim antes de a Microsoft assiná-lo.

Na Figura 2, é mostrada uma sequência de inicialização simplificada em um sistema Linux com Secure Boot habilitado que utiliza um shim.

O firmware UEFI carrega o shim e valida sua assinatura em relação à CA da Microsoft armazenada no firmware (a variável db). Em seguida, o shim assume o controle e valida o bootloader de segunda etapa (frequentemente o GRUB 2) usando seu próprio vendor certificate embutido: por exemplo, a chave UEFI da Debian para Debian, a chave UEFI da Canonical para Ubuntu ou a chave da Red Hat para RHEL e Fedora. Por sua vez, o GRUB 2 valida o kernel usando o mesmo vendor certificate antes de ceder o controle. Cada etapa é respaldada criptograficamente pela etapa anterior.

Essa indireção permite que uma distribuição Linux publique rapidamente atualizações do bootloader e do kernel, assinando-as com sua própria chave de fornecedor, sem precisar recorrer à Microsoft a cada atualização. Só o próprio shim exige uma assinatura da Microsoft, e ele muda com pouca frequência.

Além do vendor certificate, o shim geralmente contém outro certificado embutido associado só à build ou ao binário específico do shim. Esse certificado costuma ser chamado de shim certificate e é usado para assinar e verificar a integridade dos utilitários do shim que podem ser gerados durante o processo de compilação, como o MokManager (usado para gerenciar MOK e explicado com mais detalhes a seguir) ou o fallback do shim.

Machine Owner Key (MOK)

Ao falar sobre shims, vale mencionar outro mecanismo importante que permite que um shim utilize chaves externas administradas pelo usuário, conhecidas como Machine Owner Keys (MOKs). Uma allowlist de MOK (pode ser vista como uma "extensão" específica do shim para o banco de dados UEFI db) fica armazenada em uma variável NVRAM somente de inicialização chamada MokList, e uma lista de negação (a "extensão" específica do shim para o banco de dados UEFI dbx) fica armazenada em uma variável NVRAM somente de inicialização chamada MokListX;. É necessário acesso físico para modificar as duas variáveis em um sistema com UEFI Secure Boot habilitado (as variáveis somente de inicialização só podem ser modificadas durante a inicialização, antes de o carregador do SO invocar a função de serviços de inicialização UEFI ExitBootServices). Para gerenciar essas listas, o shim usa o aplicativo UEFI MokManager. Um guia sobre como gerenciar MOK pode ser encontrado aqui. A Figura 3 mostra como um MOK amplia a cadeia de confiança do UEFI Secure Boot do shim.

Como descrevemos em nossas descobertas do BlackLotus e do Bootkitty, devido à natureza não autenticada das variáveis NVRAM somente de inicialização usadas pelo mecanismo MOK, os bootkits costumam abusar dos MOKs para obter persistência assim que conseguem contornar o UEFI Secure Boot.

Secure Boot Advanced Targeting (SBAT)

Cada aplicativo UEFI (componente) que oferece suporte ao SBAT contém um pequeno conjunto de metadados em uma seção dedicada.sbat de seu arquivo PE, protegida pela mesma assinatura do próprio binário. Os metadados identificam o componente (por exemplo, shim ou grub) e atribuem a ele um número de geração que aumenta a cada vez que uma correção de segurança é publicada.

O que transforma esses números em um mecanismo de revogação é uma política correspondente no próprio sistema UEFI: uma variável UEFI somente de inicialização chamada SbatLevel, que registra o número mínimo de geração aceitável para cada componente conhecido. É importante notar que essa variável é gerenciada e aplicada pelo shim, e não pelo firmware, o que permite atualizações de revogação mais rápidas se comparadas a uma atualização de dbx. O shim traz a política incorporada, então sua aplicação não depende só da variável externa e incorpora qualquer política mais recente fornecida por meio de SbatLevel. A cada inicialização, o shim primeiro verifica seus próprios metadados SBAT em relação à política (de modo que um shim desatualizado pode acabar se recusando) e, em seguida, aplica a mesma verificação a cada binário que carrega, rejeitando qualquer elemento cujo número de geração seja inferior ao mínimo exigido pela política.

Exemplos de revogações SBAT são mostrados na Figura 4. Eles foram retirados do arquivo SbatLevel_Variable.txt, localizado no repositório do shim, que serve como fonte única para as revogações SBAT.

O nível aplicado não fica oculto do SO: o shim publica uma cópia somente leitura do SbatLevel em uma variável de execução chamada SbatLevelRT. O SO pode inspecionar qual política de revogação está atualmente em vigor, mas não pode modificá-la. No Windows, a mesma informação também está disponível pelo valor de registro HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevel.

Contornando o UEFI Secure Boot usando shims antigos

Com a teoria sobre a cadeia de confiança do Secure Boot de um shim explicada na seção anterior, agora podemos nos concentrar no impacto prático que binários UEFI esquecidos e antigos, mas ainda confiáveis, podem ter sobre a segurança dos sistemas UEFI.

Ilustramos isso examinando alguns problemas específicos dos shims relatados: problemas fáceis de explorar e que mostram bem a amplitude da superfície de ataque que expõem.

Bootloaders de segunda etapa vulneráveis

Cada um dos shims relatados traz tanto um certificado gerenciado pelo fornecedor quanto um shim certificate embutido, que servem como âncora de confiança para os bootloaders de segunda etapa ou os utilitários do shim: binários do GRUB 2, MokManager, fallback loaders e, às vezes, outros shims assinados por fornecedores que ampliam ainda mais a cadeia de confiança. A quantidade de binários em que um determinado shim confia varia bastante: de menos de dez, no caso de software especializado e dedicado, a quase uma centena, no caso de distribuições Linux amplamente conhecidas.

Os carimbos de data e hora de assinatura e compilação dos aplicativos em que os shims relatados confiam abrangem de 2013 a 2025, o que já confirma que boa parte desses binários era antiga e provavelmente estava afetada por várias vulnerabilidades já conhecidas publicamente, incluindo o já citado BootHole no caso do GRUB 2. Embora a maioria desses componentes confiáveis seja antiga o suficiente para representar algum risco de segurança, o GRUB 2 parece ser o elo mais fraco. É um software complexo, e por isso versões mais antigas acumulam vulnerabilidades.

Vejamos o shim do Oracle Linux, que está entre os que relatamos. Ele confia em binários assinados por meio de um certificado emitido para a Oracle Corporation (impressão digital SHA 1: 2E434A724B4759C981E4189AA5AD3D635096DD2F). Um dos binários assinados com esse certificado é um binário do GRUB 2 presente na ISO de instalação do Oracle Linux 7.1 (V74844-01.iso). Esse binário é afetado pela CVE-2015-5281, que, citando a nota de vulnerabilidade, "quando usado em sistemas UEFI, permite que usuários locais contornem as restrições pretendidas do arranque seguro (Secure Boot) e executem código não verificado por meio de um módulo (1) multiboot ou (2) multiboot2 manipulado". Os dois módulos mencionados, multiboot e multiboot2, permitem carregar código não assinado durante a inicialização do sistema por meio dos comandos homônimos e deveriam ser proibidos em binários do GRUB 2 assinados e compatíveis com o UEFI Secure Boot, já que contornam o UEFI Secure Boot por design.

A exploração é simples: não há erros de corrupção de memória a explorar, nem cadeias ROP a construir, nem engenharia reversa complexa envolvida. O único pré-requisito é construir uma imagem de kernel personalizada, compatível com multiboot2 e sem assinatura, na prática pouco mais do que um binário ELF com os cabeçalhos exigidos e alguns outros elementos específicos. Depois que o atacante constrói esse binário e o copia para a EFI System Partition (ESP) junto com o shim vulnerável e o GRUB 2, um único comando GRUB 2 multiboot2 pode ser usado para carregá-lo e executá-lo durante a inicialização, com o Secure Boot habilitado ou não. Uma prova de conceito que demonstra a exploração da CVE-2015-5281 por meio do antigo shim do Oracle Linux relatado, em um sistema com UEFI Secure Boot habilitado (sem os patches mais recentes da Microsoft aplicados), é mostrada no vídeo a seguir:

Ausência de funcionalidades mais recentes

Ao longo dos anos, o shim bootloader UEFI evoluiu naturalmente, com novas melhorias e funcionalidades de segurança introduzidas em versões sucessivas do repositório upstream do "shim" UEFI. Ao mesmo tempo, muitos fornecedores externos usaram versões disponíveis do código-fonte do shim para criar seus próprios binários, que depois enviaram à Microsoft para assinatura. Esse comportamento é esperado e está alinhado com o design original dos shims. O problema é que não tem sido dada atenção suficiente à revogação de shims obsoletos assinados pela Microsoft, muitos dos quais podem ser usados, por design, para contornar mecanismos de segurança mais recentes. Ilustramos essa lacuna com alguns exemplos concretos.

Aplicação da lista de exclusão de MOK

A MokList (allowlisting baseado em MOK) é suportada pelo shim UEFI upstream desde praticamente o início (versão 0.3). Já as revogações MOK (MokListX)) só começaram a ser aplicadas na versão 0.9. Por que isso é um problema? Vejamos o seguinte cenário.

Uma organização registrou seu próprio MOK para assinar ferramentas UEFI e bootloaders personalizados que implanta em toda a sua rede. É descoberta uma vulnerabilidade em vários desses binários e, em resposta, os administradores revogam o certificado de assinatura antigo, adicionando-o à denylist de MOK (MokListX)). Em seguida, registram um novo MOK e assinam novamente as versões corrigidas dos binários afetados usando a nova chave. Os binários antigos e vulneráveis agora são rejeitados pelo shim, enquanto os recém-assinados carregam normalmente, e assim os dispositivos da organização parecem seguros. O certificado antigo continua presente e confiável na MokList, mas está revogado na MokListX, onde é aplicado como uma regra de maior prioridade.

Nesse cenário, um atacante poderia substituir o shim atualizado da vítima por um shim UEFI mais antigo assinado pela Microsoft, de nosso relatório. Por exemplo, a versão 0.8 incluída no software Abitti 1, assinada pela Microsoft para o Finland's Matriculation Examination Board. Esse shim ainda confia nos certificados armazenados na variável MokList da vítima, onde o certificado MOK obsoleto continua válido, mas ignora a MokListX, já que foi compilado antes da introdução da aplicação da denylist de MOK. Como resultado, o shim do atacante poderia ser usado para carregar binários vulneráveis sem restrições, permitindo a execução arbitrária de código ou a instalação de um bootkit UEFI malicioso.

Aplicação de SBAT

O mesmo problema se aplica ao SBAT. O suporte a esse mecanismo foi introduzido upstream na versão 15.3 do shim, então qualquer shim anterior simplesmente desconhece sua existência: não lê a política de revogação SbatLevel nem inspeciona a seção .sbat do bootloader de segunda etapa que carrega. Como resultado, ele ignora qualquer revogação SBAT posterior destinada a bloquear componentes vulneráveis.

Nesse caso, o cenário de ataque seria o seguinte: um atacante pega um shim assinado pela Microsoft anterior à versão 15.3, como o shim versão 0.9 do Red Hat Enterprise Linux 7.2  incluído em nosso relatório, combina com um dos vários binários do GRUB 2 em que o shim ainda confia mas que já foram revogados pelo SBAT, e copia ambos para a ESP. Durante a inicialização do sistema, o shim valida o binário do GRUB 2 usando seu certificado embutido, nunca consulta o SBAT e carrega o binário vulnerável sem objeções, deixando o atacante livre para explorar qualquer vulnerabilidade presente nesse binário do GRUB 2.

Vulnerabilidades conhecidas no shim

Por fim, os shims antigos são simplesmente código antigo, e boa parte do código antigo traz vulnerabilidades conhecidas. Para ilustrar isso, usamos como exemplo um problema antigo que afeta os shims na versão 0.9 e inferiores. Essa vulnerabilidade não tinha um identificador CVE atribuído até o nosso relatório, embora já tivesse sido corrigida e descrita em detalhes há quase exatamente uma década na mensagem de um dos commits upstream do repositório do shim, d241bbb. Hoje é rastreada como CVE-2026-10797.

O problema é que um binário PE assinado com Authenticode registra o comprimento de sua assinatura em dois locais independentes:

• no diretório de dados de seu cabeçalho PE (IMAGE_DIRECTORY_ENTRY_SECURITY), e
• em sua estrutura WIN_CERTIFICATE, que encapsula a própria assinatura.

Nos shims afetados, a verificação de revogação e as funções de verificação de assinatura divergiam quanto a qual dos valores de tamanho deveria ser considerado confiável. A verificação de revogação usava o valor do cabeçalho da assinatura, enquanto a função de verificação de assinatura usava o valor do cabeçalho PE.

Por isso, é possível contornar o mecanismo de revogação manipulando a estrutura WIN_CERTIFICATE do bootloader de segunda etapa, fazendo com que a função de revogação compare o dbx e a MokListX com dados falsos, em vez da assinatura real do bootloader.

Em resumo: mesmo que o certificado do bootloader de segunda etapa estivesse revogado no dbx ou na MokListX, o shim não perceberia. Dois pontos importantes sobre isso:

• esse bypass funciona só com revogações baseadas em certificado (não com as baseadas em hash), e
• o bootloader de segunda etapa precisa estar assinado por um certificado embutido no shim (seja o certificado embutido do próprio shim, gerado durante seu processo de compilação, seja o certificado do fornecedor).

Essas limitações existem porque as revogações baseadas em hash e os certificados não embutidos (vindos da MokList e do db) são verificados em outras partes do código e não são afetados por esse problema.

Isso não seria resolvido com o vencimento dos certificados UEFI da Microsoft?

Levando em conta os vencimentos atuais dos certificados UEFI da Microsoft (como mostrado na Figura 5, o certificado Microsoft Corporation UEFI CA 2011 venceu em 27 de junho de 2026), dá pra pensar que relatar aplicativos UEFI vulneráveis assinados com esse certificado vencido só gera ruído desnecessário.

Mas a realidade é que a data de vencimento de um certificado UEFI não tem nenhum efeito sobre o processo de verificação do Secure Boot. Se o certificado Microsoft Corporation UEFI CA 2011 continuar no db e não estiver revogado no dbx, todos os bootloaders validamente assinados com esse certificado vencido continuarão sendo confiáveis, desde que não tenham sido revogados explicitamente por hash. É por isso que a Microsoft continuou assinando novos envios com o certificado antigo até sua data de vencimento.

Proteção e detecção

Esses shims vulneráveis podem ser bloqueados aplicando as revogações UEFI mais recentes da Microsoft. Os sistemas Windows devem se atualizar automaticamente. A Figura 6 mostra comandos do PowerShell (que precisam ser executados com privilégios elevados) para verificar se as revogações necessárias estão instaladas no seu sistema Windows.

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

Figura 6. Comandos do PowerShell para verificar as revogações de UEFI.

Em sistemas Linux, as atualizações devem estar disponíveis pelo Linux Vendor Firmware Service, e o status das revogações pode ser verificado usando o script uefi-dbx-audit.

Para recomendações mais gerais sobre como se proteger da exploração (ou pelo menos detectar a exploração) de bootloaders UEFI vulneráveis, assinados e desconhecidos, e da implantação de bootkits UEFI, veja nossa publicação Vulnerabilidade CVE-2024-7344 permite burlar o UEFI Secure Boot.

Conclusão

O que torna esses shims antigos perigosos não é uma vulnerabilidade nova. Na verdade, nenhuma vulnerabilidade nova é necessária para contornar o UEFI Secure Boot. Um atacante não precisa de técnicas complexas de exploração; basta uma cópia de um binário shim antigo, ainda confiável mas não revogado, e um conhecimento básico de como os shims UEFI funcionam. Isso já é suficiente para contornar uma funcionalidade de segurança tão essencial quanto o UEFI Secure Boot.

A revogação desses 11 shims resolveu o problema imediato, mas continua existindo um problema mais profundo: a visibilidade. O processo de assinatura de shims ficou bem mais transparente em 2017, com a criação do repositório, onde os envios dos fornecedores são revisados pelos mantenedores antes de a Microsoft assiná-los. Todos os shims aprovados desde então estão documentados, mas os assinados antes dessa data não estão, e ninguém pode afirmar com certeza quantos desses shims antigos, ainda confiáveis, continuam por aí. O que não foi catalogado de forma completa e transparente não pode ser retirado de forma eficaz.

Como ponto positivo, acreditamos que a tendência está indo na direção certa. Cada divulgação como essa reduz o conjunto de shims esquecidos, e graças a uma maior transparência na assinatura de shims e a mecanismos como o SBAT, o rastreamento do que precisa ser revogado e sua revogação efetiva podem ser gerenciados de forma bem mais eficiente do que no passado. O próximo passo é estender esse nível de transparência do ecossistema de assinatura UEFI de terceiros da Microsoft para os aplicativos UEFI de terceiros que não são shims, os quais, como já mostrado várias vezes (por exemplo, CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, entre outros), também podem servir como fonte direta para contornar o UEFI Secure Boot.

Indicadores de Comprometimento (IoC)

Como os shims vulneráveis fazem parte de pacotes de software legítimos que potencialmente estão presentes em milhares de sistemas que nunca foram comprometidos por meio desses loaders, não fornecemos indicadores de comprometimento, para evitar uma identificação errônea em massa. Em vez disso, os defensores devem seguir as recomendações incluídas na seção Proteção e detecção.

Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco em threatintel@eset.com.