Crédito: Mixvale.com.br
Uma vulnerabilidade significativa no sistema Secure Boot, um mecanismo de segurança desenvolvido pela Microsoft e amplamente adotado na indústria para proteger dispositivos Windows e Linux contra infecções de firmware, foi recentemente exposta. Especialistas em segurança revelaram que essa falha, de fácil exploração, esteve ativa e passível de ser contornada por impressionantes treze dos quatorze anos de existência da tecnologia. A descoberta, feita pela empresa de segurança ESET, apontou para a existência de onze imagens de firmware problemáticas, uma delas datada de 2013, que, apesar de suas fragilidades conhecidas, continuaram a ser aprovadas e confiáveis pela gigante de software, representando um risco persistente e de longo prazo para a integridade dos sistemas.
Essas imagens, conhecidas como “shims”, foram originalmente criadas para estender a funcionalidade do Secure Boot a sistemas operacionais baseados em Linux e a diversas ferramentas utilitárias. Utilizando um método que pode ser executado até mesmo por cibercriminosos com pouca experiência, esses shims antigos e que foram negligenciados se tornaram um vetor para burlar completamente a segurança da UEFI (Unified Extensible Firmware Interface), um componente fundamental presente na placa-mãe dos computadores modernos. A raiz do problema residiu na falha da Microsoft, encarregada de validar e gerenciar a aprovação desses shims, ao não revogar a confiança nessas imagens públicas mesmo após a identificação de suas fraquezas críticas.
A amplitude dessa ameaça se estende de maneira preocupante a um vasto universo de usuários que dependem tanto do ecossistema Windows quanto do Linux para suas operações diárias.
O perigo iminente atinge os utilizadores de ambos os sistemas operacionais, uma vez que um shim comprometido pode ser instalado com sucesso em máquinas que rodam Windows ou Linux. Uma vez implantado, um agente mal-intencionado é capaz de interceptar e desviar a sequência de inicialização do firmware, que é digitalmente assinada, introduzindo um software malicioso que é ativado nas fases mais primárias do boot do sistema. O mais alarmante é que esse tipo de infecção persiste no dispositivo mesmo após a reinstalação completa do sistema operacional ou a substituição do disco rígido, tornando a remoção extremamente complexa e exigindo intervenções de baixo nível para restaurar a segurança.
Martin Smolár, pesquisador da ESET, esclareceu em um comunicado divulgado na última terça-feira, a natureza peculiar dessa falha. Segundo ele, “o que torna esses shims antigos perigosos não é a descoberta de uma vulnerabilidade inédita. É o fato de que nenhuma vulnerabilidade nova é sequer necessária para contornar a Inicialização Segura UEFI. Um atacante não precisa de técnicas de exploração complexas; basta uma cópia de um binário shim antigo, que ainda é considerado confiável, mas não foi revogado, e um entendimento básico de como os shims UEFI operam. Essa simplicidade é suficiente para comprometer um recurso de segurança tão vital como a Inicialização Segura UEFI, demonstrando uma falha processual grave.”
Lançado em 2012, o Secure Boot foi concebido com o objetivo primordial de mitigar o risco de “bootkits”, que são tipos de firmware maliciosos capazes de se infiltrar profundamente no processo de inicialização de um sistema. Sem essa funcionalidade de segurança, cibercriminosos com acesso físico rápido a um dispositivo, mesmo que este esteja desligado, poderiam instalar esses bootkits. Ao longo dos anos, diversos exemplos notórios de bootkits foram identificados e utilizados em ataques sofisticados, incluindo o LoJax, empregado por hackers russos em 2018; o MosaicRegressor, detectado em 2020; o CosmicStrand, em 2022; e o BlackLotus, que surgiu em 2023. Outros bootkits conhecidos e ainda ativos incluem ESpecter, FinSpy e MoonBounce, que continuam a representar ameaças persistentes.
É importante ressaltar que a maioria dos softwares maliciosos de inicialização, embora não a totalidade, exige que os invasores obtenham acesso físico direto aos dispositivos que serão comprometidos. Este cenário de acesso físico é precisamente um dos tipos de ameaça que o Secure Boot foi especificamente projetado para combater e neutralizar, servindo como uma barreira crucial contra manipulações no nível mais baixo do sistema.
Uma investigação detalhada conduzida pelo CERT (Computer Emergency Response Team) revelou que alguns dos shims vulneráveis foram utilizados por importantes distribuições Linux, como Red Hat, OpenSUSE e Oracle, ampliando a superfície de ataque potencial. Outros shims foram incorporados a softwares de terceiros, como o da PC-Doctor Finland’s Matriculation Examination Board, mostrando a capilaridade da falha. Muitos desses componentes foram desenvolvidos antes da implementação de salvaguardas mais robustas, como as listas de bloqueio SBAT (Secure Boot Advanced Targeting) e MOK (Machine Owner Key). Além disso, alguns continham falhas acumuladas em seu próprio código-fonte ou nos binários de segunda etapa que eles tinham a autorização para carregar, exacerbando o risco.
No caso específico dos computadores com sistema operacional Windows, o carregador de inicialização UEFI da Microsoft, que possui uma assinatura digital exclusiva, atua como o único e principal fator de confiança inicial. Para que qualquer componente seja ativado durante o complexo processo de boot do sistema, seu certificado deve assinar explicitamente todo o código que será executado nessa fase crucial, garantindo uma cadeia de confiança ininterrupta desde o hardware até o sistema operacional.
A maneira como os shims operam, no entanto, é fundamentalmente diferente. Eles funcionam como um ponto de confiança secundário, sendo validados inicialmente pela Microsoft por meio de um de seus certificados UEFI alternativos. A partir desse ponto de validação, um certificado específico do fabricante da placa-mãe ou do próprio software, já embutido dentro do shim, é que concede a autorização para todos os programas subsequentes que serão carregados na sequência de inicialização. Essa arquitetura de confiança aninhada é o ponto onde a falha se manifestou.
Normalmente, quando falhas de segurança são identificadas em shims, a Microsoft prontamente os revoga para proteger seus usuários. Contudo, em relação aos onze shims em questão, a empresa não tomou as medidas necessárias para desativá-los, permitindo que eles permanecessem ativos e confiáveis por mais de uma década em alguns cenários de uso. A Microsoft só procedeu ao cancelamento de sua aprovação em sua atualização mensal de patches, lançada em junho, e isso ocorreu apenas após a ESET ter alertado o CERT e a própria empresa sobre a seriedade da vulnerabilidade, evidenciando uma resposta tardia a um risco de longa data.
A Microsoft, até o momento, não divulgou detalhes específicos sobre como ou por que essa falha crítica se manifestou e permaneceu sem correção por tanto tempo. Uma das principais hipóteses levantadas pelos especialistas aponta para a intrínseca complexidade do funcionamento do Secure Boot como um fator contribuinte. O Gerenciador de Inicialização do Windows e os módulos UEFI utilizam dois bancos de dados essenciais para gerenciar a confiança: o “db”, que contém a lista de todos os certificados de assinatura e hashes Authenticode que são permitidos para execução; e o “dbx”, que armazena os certificados e hashes que não são mais considerados confiáveis e, portanto, devem ser bloqueados. Para que qualquer componente seja carregado com sucesso, ele deve ser autorizado pelo banco de dados “db” e, simultaneamente, não estar listado como revogado no banco de dados “dbx”, garantindo um controle rigoroso.
Diante da vasta quantidade de componentes do sistema Linux que são executados durante o processo de inicialização, catalogar cada um deles individualmente nesses bancos de dados torna-se uma tarefa inviável. Essa dificuldade é agravada pela limitação de tamanho do arquivo dbx, que possui uma capacidade restrita de apenas 32 KB, tornando-o inadequado para gerenciar o volume de revogações necessárias para um ecossistema tão dinâmico quanto o Linux. Para contornar essa limitação e garantir a segurança, a Microsoft implementou outros mecanismos de revogação mais avançados, como o SBAT (Secure Boot Advanced Targeting) e o Secure Boot Security Version Number (SVN), que visam oferecer uma proteção mais abrangente e escalável.
“Em termos simplificados, enquanto o dbx tem a função de revogar binários específicos, os mecanismos SBAT e o Secure Boot SVN da Microsoft são projetados para revogar versões inteiras de software”, explicou Smolár. Ele complementou que “quando uma vulnerabilidade é descoberta em um aplicativo UEFI que já suporta um desses mecanismos de revogação baseados em versão, o que realmente precisa ser protegido é toda a compilação anterior à versão vulnerável, incluindo-a. Isso pode abranger um grande número de iterações e exige uma gestão cuidadosa para garantir que nenhuma versão comprometida possa ser executada, destacando a complexidade de manter a segurança em sistemas de inicialização tão intrincados.”
