Uma assinatura válida deixou de significar código seguro
O Secure Boot fez exatamente aquilo para que foi construído, e esse foi o problema. A 14 de julho a empresa de segurança ESET publicou uma investigação, dirigida por Martin Smolar, que mostra onze carregadores de arranque assinados pela Microsoft, todos na versão 0.9 ou inferior, que uma máquina executa de bom grado porque a assinatura é autêntica. O código por trás dessa assinatura tem uma década e está comprometido, mas o Secure Boot verifica quem assinou, não a segurança do que foi assinado.
O resultado é um atacante capaz de executar código não verificado no arranque de quase qualquer computador UEFI. A ESET comunicou a descoberta ao centro de coordenação CERT/CC em fevereiro, e a Microsoft acrescentou os onze ficheiros à sua lista de revogação a 9 de junho. A distância entre uma assinatura de confiança e um código digno de confiança é toda a história, e a correção por si só não a fecha.
Como funciona o contorno
O atacante não arromba nada; fornece algo em que já se confia. A maioria dos sistemas UEFI transporta o certificado de terceiros da Microsoft, o Microsoft Corporation UEFI CA 2011, na sua lista de signatários permitidos. Um atacante copia um dos antigos carregadores assinados para a partição de sistema EFI, a pequena zona de arranque do disco, e o firmware aceita-o porque a assinatura remonta a esse certificado de confiança. Não são precisos privilégios de administrador, apenas a capacidade de escrever esse ficheiro.
A partir daí, três falhas antigas fazem o trabalho. Os carregadores confiam em código GRUB 2 desatualizado com uma falha de 2015 que executa módulos não verificados; as versões abaixo de 0.9 não têm a lista de revogação que bloquearia certificados reconhecidos como maliciosos; e as anteriores a 15.3 ignoram o SBAT, o mecanismo mais recente concebido para retirar binários vulneráveis. Registada como CVE-2026-8863 e CVE-2026-10797, a cadeia termina com o código do atacante a correr antes de o sistema operativo carregar, o lugar ideal para se esconder.
Porque a correção é a parte fácil
Uma revogação só protege a máquina que a recebeu de facto. A correção da Microsoft de 9 de junho acrescenta os onze ficheiros à dbx, a lista de exclusão do firmware, e nas frotas Windows geridas essa atualização corre pelos canais normais. O senão é que muitas organizações retêm de propósito as alterações à lista do firmware, porque uma entrada dbx errada pode deixar um dispositivo sem arrancar, e esse risco é maior em hardware antigo ou de arranque duplo. A revogação existe; se chegou às suas máquinas é outra questão.
O problema de fundo é contar. O registo público de revisão de carregadores só começou em 2017, e não há uma lista comparável do que foi assinado antes disso, pelo que ninguém pode afirmar com certeza quantos carregadores antigos e ainda de confiança andam por aí. Onze é o número que a ESET conseguiu nomear, não o número que existe. Um controlo que depende de conhecer cada signatário de confiança é fraco precisamente onde o inventário se esgota.
O que convém verificar esta semana
Trate isto como uma tarefa de higiene de revogações, não como uma única correção. Confirme que a atualização dbx de 9 de junho foi mesmo aplicada em todo o parque em vez de o presumir; a ESET aponta para ferramentas de auditoria e verificações em PowerShell que reportam o estado de revogação atual. Alargue a verificação para além do Windows, porque os servidores Linux e os equipamentos recebem a mesma correção através do Linux Vendor Firmware Service, e os portáteis de arranque duplo são o ponto cego clássico.
Para os operadores europeus o enquadramento é agora tanto regulatório como técnico. Sob a NIS2, a integridade da cadeia de arranque cabe nas medidas de segurança que uma entidade essencial deve conseguir demonstrar, e um bootkit no firmware é exatamente o tipo de persistência sobre o qual um supervisor perguntará após um incidente. A ação do responsável é simples de enunciar e fácil de saltar: verifique em que o seu firmware ainda confia e prove que o bloqueio chegou.
Leia a seguir: 570 correções do Windows num dia, duas já exploradas | Uma falha da Cisco com 18 anos tem agora um prazo de 3 dias



