A equipe de pesquisa da ESET descobriu uma vulnerabilidade que afeta a maioria dos sistemas baseados em UEFI e permite contornar o UEFI Secure Boot. Essa vulnerabilidade, identificada como CVE-2024-7344, foi encontrada em um aplicativo UEFI assinado pelo certificado de terceiros da Microsoft, Microsoft Corporation UEFI CA 2011. A exploração dessa falha possibilita a execução de código não confiável durante a inicialização do sistema, permitindo que potenciais atacantes implantem bootkits UEFI maliciosos (como Bootkitty ou BlackLotus) com facilidade, mesmo em sistemas com o UEFI Secure Boot ativado, independentemente do sistema operacional instalado.
O aplicativo UEFI afetado faz parte de várias suítes de software de recuperação de sistemas em tempo real desenvolvidas por Howyar Technologies Inc., Greenware Technologies, Radix Technologies Ltd., SANFONG Inc., Wasay Software Technology Inc., Computer Education System Inc. e Signal Computer GmbH. A seguir está a lista de produtos de software vulneráveis:
- Howyar SysReturn antes da versão 10.2.023_20240919
- Greenware GreenGuard antes da versão 10.2.023-20240927
- Radix SmartRecovery antes da versão 11.2.023-20240927
- Sanfong EZ-back System antes da versão 10.3.024-20241127
- WASAY eRecoveryRX antes da versão 8.4.022-20241127
- CES NeoImpact antes da versão 10.1.024-20241127
- SignalComputer HDD King antes da versão 10.3.021-20241127
Relatamos nossas descobertas ao Centro de Coordenação CERT (CERT/CC) em junho de 2024, que entrou em contato com os fornecedores afetados. O problema já foi corrigido em seus produtos, e os antigos binários vulneráveis foram revogados pela Microsoft na atualização de terça-feira de patches, em 14 de janeiro de 2025.
Pontos-chave deste artigo:
- Pesquisadores da ESET descobriram uma nova vulnerabilidade, CVE-2024-7344, que permite contornar o UEFI Secure Boot na maioria dos sistemas baseados em UEFI.
- A exploração dessa vulnerabilidade possibilita a execução de código não confiável durante a inicialização do sistema, permitindo a implantação de bootkits UEFI maliciosos.
- Todos os sistemas UEFI com a assinatura UEFI de terceiros da Microsoft ativada estão vulneráveis (os PCs com Windows 11 Secured-core devem ter essa opção desativada por padrão).
- O problema foi resolvido pelos fornecedores afetados, e os antigos binários vulneráveis foram revogados pela Microsoft na atualização de patches no dia 14 de janeiro de 2025.
A seguir, você pode conferir a cronologia coordenada da divulgação. Agradecemos ao CERT/CC pela ajuda na coordenação do processo de divulgação da vulnerabilidade e aos fornecedores afetados pela comunicação e cooperação ágeis e transparentes durante o processo de correção e divulgação.
Cronograma de divulgação coordenada:
- 8 de julho de 2024: A ESET descobre a vulnerabilidade.
- 9 de julho de 2024: A ESET informa a vulnerabilidade ao CERT/CC.
- 23 de julho de 2024: O CERT/CC aceita ajudar na coordenação do processo de divulgação da vulnerabilidade - a data de divulgação pública é definida para 21 de outubro de 2024.
- 5 de agosto de 2024: O CERT/CC entra em contato com os fornecedores afetados.
- 20 de agosto de 2024: Os fornecedores fornecem o patch inicial para revisão.
- 20 de agosto de 2024: A ESET confirma que o problema relatado foi corrigido corretamente, mas identifica outro problema recentemente introduzido com a mesma causa raiz.
- 28 de agosto de 2024: Os fornecedores fornecem um segundo patch para revisão.
- 23 de setembro de 2024: É acordada com a Microsoft a nova data de divulgação pública para 14 de janeiro de 2025.
- 14 de janeiro de 2025: Revogação das aplicações UEFI vulneráveis afetadas pela Microsoft.
- 16 de janeiro de 2025: Publicação deste artigo pela ESET.
UEFI Secure Boot no mundo real
Antes de descrevermos a vulnerabilidade, vamos analisar como funciona a verificação do UEFI Secure Boot em dispositivos reais e quem é responsável por gerenciar os bancos de dados do UEFI Secure Boot nesses dispositivos.
A lógica básica é bastante simples e está ilustrada na Figura 1. Quando o Gerenciador de Inicialização UEFI procede para carregar um aplicativo de inicialização, como o Windows Boot Manager, shim, GRUB2 ou similar, ele verifica o binário do aplicativo de inicialização em relação a dois bancos de dados do Secure Boot, entre outras verificações:
- db: Lista de certificados permitidos ou hashes PE Authenticode confiáveis para o firmware da plataforma.
- dbx: Lista de certificados proibidos ou hashes PE Authenticode bloqueados.
As condições para que uma imagem seja considerada confiável são: ela deve estar na db e, ao mesmo tempo, o hash do arquivo ou seu certificado não pode constar na base de dados dbx. Com base nos resultados dessa verificação, o Gerenciador de Inicialização UEFI pode causar uma violação de segurança ou executar a imagem verificada.
Para garantir que o UEFI Secure Boot proteja o processo de inicialização dos principais sistemas operacionais em dispositivos UEFI recém-adquiridos (por padrão e sem interação do usuário), a maioria dos dispositivos vem com um conjunto de certificados UEFI específicos registrados em sua base de dados db. Embora esses certificados possam variar conforme o OEM e os requisitos e finalidades específicos do dispositivo, na maioria dos dispositivos comuns (como laptops, desktops, servidores...), a Microsoft solicita aos OEMs que incluam seus próprios certificados. Por isso, a Microsoft desempenha um papel importante na segurança da maioria desses dispositivos baseados em UEFI, pois, com as chaves da Microsoft registradas na db, ela pode gerenciar o que é permitido ou não durante o processo de inicialização.
Certificados UEFI da Microsoft
Como explicado anteriormente, muitos dispositivos UEFI vêm com certificados UEFI da Microsoft registrados. Os seguintes são dois certificados específicos que geralmente estão presentes entre os certificados confiáveis nesses dispositivos:
- Microsoft Windows Production CA 2011
- CA UEFI de Microsoft Corporation 2011
Observe que a Microsoft deverá revogar em breve o certificado Microsoft Windows Production PCA 2011 e substituí-lo pelo certificado Windows UEFI CA 2023 (mais informações), como resposta aos bootloaders vulneráveis de Windows relacionados com o infame bootkit BlackLotus. Os dispositivos Windows novos ou atualizados já confiarão neste novo certificado.
Quanto ao certificado UEFI CA 2011 da Microsoft Corporation, parece que ele ainda está sendo usado para assinar novas aplicações UEFI, mas também deverá ser substituído futuramente por um novo certificado denominado Microsoft UEFI CA 2023.
Para quem estiver interessado no plano de renovação dos certificados UEFI da Microsoft, vale a pena conferir a apresentação Evolving the Secure Boot Ecosystem, ministrada na UEFI Fall 2023 Developers Conference & Plugfest.
Enquanto o primeiro certificado (o PCA) é utilizado pela Microsoft para assinar suas próprias aplicações de inicialização UEFI, o segundo é utilizado para assinar o software de inicialização UEFI desenvolvido por terceiros, o que inclui shims Linux, diversos softwares especializados em recuperação, backup, criptografia de disco, manutenção, entre outros.
Isso significa que qualquer pessoa interessada em garantir que seu software de inicialização seja compatível por padrão com o UEFI Secure Boot pode solicitar à Microsoft que assine seus binários (por meio do painel do Centro de Desenvolvimento de Hardware do Windows). Se os binários passarem pela revisão interna da Microsoft, ela os assinará com seu certificado UEFI de terceiros, fazendo com que os arquivos se tornem compatíveis com a maioria dos sistemas UEFI, que confiam no certificado de terceiros da Microsoft (nos PCs com Windows 11 Secured-core, o certificado UEFI de terceiros da Microsoft não deve ser considerado confiável por padrão).
A partir dos requisitos de assinatura do UEFI da Microsoft disponíveis on-line, não está claro o que está incluído no processo de revisão interna, embora certamente envolva uma análise mais profunda, em vez de apenas revisar os requisitos listados. Embora acreditemos que o processo de revisão manual esteja sendo aprimorado ao longo do tempo com cada nova vulnerabilidade descoberta, uma maior transparência sobre o que está realmente sendo assinado e quais verificações estão incluídas nesse processo de revisão manual poderia aumentar as chances de que binários tão evidentemente vulneráveis como o descrito neste relatório sejam descobertos e corrigidos mais rapidamente.
CVE-2024-7344
Quando encontramos o pacote de software SysReturn da Howyar no ano passado, o primeiro aspecto que chamou imediatamente nossa atenção foi a presença de um arquivo chamado cloak.dat, implantado junto com uma aplicação UEFI assinada pela Microsoft chamada reloader.efi. A seguir estão os hashes PE Authenticode da aplicação vulnerável reloader.efi:
- cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48 (64-bit version)
- e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9 (32-bit version)
Neste análise, utilizamos a versão de 64 bits de reloader.efi. Como mostrado na Figura 2, o arquivo cloak.dat contém uma estrutura de dados semelhante a um cabeçalho que começa com a string mágica ALRM. A esse cabeçalho seguem-se dados desconhecidos que visualmente lembram a estrutura de um cabeçalho de arquivo PE/COFF, criptografados por meio de uma simples operação de XOR. É fácil deduzir a chave com base na frequência dos bytes 0xB3, que correspondem à grande quantidade de bytes 0x00 encontrados em cabeçalhos PE/COFF normais. Ao descriptografar cloak.dat utilizando a operação XOR com a chave 0xB3, revela-se que, de fato, ele contém uma aplicação UEFI, e, além disso, sem assinatura.
Rapidamente descobrimos que o binário extraído não é malicioso, mas nos perguntamos: esse binário é utilizado de alguma forma pelo carregador de inicialização do SysReturn durante a inicialização do sistema? Se sim, o UEFI Secure Boot leva isso em consideração e se recusa a carregar esse binário não assinado se estiver ativado? Após investigar mais profundamente o reloader.efi, encontramos código responsável por carregar o arquivo cloak.dat na memória e descriptografar a imagem incorporada. Como mostrado na Figura 3, a função tenta carregar o arquivo a partir de uma das seguintes localizações na partição do sistema EFI:
- \EFI\Microsoft\boot\cloak64.dat
- \EFI\boot\cloak64.dat
- \EFI\Microsoft\boot\cloak.dat
- \Bootbootcloak.dat
Até aqui, não haveria nada de errado. O carregador de inicialização poderia passar o buffer que contém a imagem PE descriptografada para a função LoadImage da UEFI como argumento, o que garantiria que a imagem cumprisse com a política de UEFI Secure Boot da máquina, através do processo de verificação descrito na Figura 1. Infelizmente, esse não é o caso. Após descriptografar uma imagem PE do arquivo cloak.dat, o carregador de inicialização vulnerável chama sua própria função, representada na Figura 4, responsável por carregar e executar manualmente a imagem sem qualquer verificação de integridade relacionada ao Secure Boot.
No vídeo a seguir, é apresentada uma prova de conceito que demonstra a exploração da vulnerabilidade em um sistema com o UEFI Secure Boot ativado.
A exploração dessa vulnerabilidade não se limita aos sistemas com o software de recuperação afetado instalado, pois os atacantes podem levar sua própria cópia do binário vulnerável reloader.efi para qualquer sistema UEFI com o certificado UEFI de terceiros da Microsoft inscrito. Além disso, são necessários privilégios elevados para implantar os arquivos vulneráveis e maliciosos na partição do sistema EFI (administrador local no Windows; root no Linux). Para explorar a vulnerabilidade, um atacante precisaria:
- Substituir um binário do carregador de inicialização do sistema operacional padrão na partição do sistema EFI (ESP) pelo arquivo vulnerável reloader.efi.
- Copiar um arquivo cloak.dat especialmente projetado, contendo uma aplicação UEFI maliciosa, em um dos caminhos da ESP suportados pelo carregador de inicialização vulnerável.
- Reiniciar o sistema.
Após confirmar a vulnerabilidade por meio da criação de um conceito de prova funcional, percebemos que a aplicação vulnerável reloader.efi foi utilizada não apenas pelo software SysReturn da Howyar, mas também por vários outros produtos de software de recuperação. Uma lista completa dos pacotes de software afetados pode ser encontrada no início deste post. Como parecia haver mais de um produto de diferentes fornecedores afetados, entramos em contato com o CERT/CC, que nos ajudou a entrar em contato com as partes afetadas e a coordenar o processo de divulgação da vulnerabilidade.
Até agora, não detectamos nenhuma tentativa de exploração no mundo real em nossos dados telemétricos.
Proteção e detecção
A vulnerabilidade pode ser mitigada aplicando as últimas revogações UEFI da Microsoft. Os sistemas Windows devem ser atualizados automaticamente. O aviso da Microsoft sobre a vulnerabilidade CVE-2024-7344 pode ser encontrado aqui. Use os seguintes comandos do PowerShell (executados com permissões elevadas) para verificar se seu sistema está afetado pela vulnerabilidade e se as revogações necessárias foram instaladas:
# Sistemas UEFI: verifique se o seu sistema está afetado pela CVE-2024-7344:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
# Sistemas UEFI de 64 bits: Verifique se está protegido (o driver vulnerável está revogado no seu sistema):
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
# Sistemas UEFI de 32 bits: Verifique se está protegido (o driver vulnerável está revogado no seu sistema):
[BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
# Sistemas Linux: As atualizações devem estar disponíveis por meio do serviço Linux Vendor Firmware Service. Use os seguintes comandos para verificar se as revogações necessárias estão instaladas em seu sistema:
# Sistemas Linux de 64 bits:
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
# Sistemas Linux de 32 bits:
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
Enquanto as revogações de UEFI protegem eficazmente o seu sistema contra a CVE-2024-7344, existem outras formas mais ou menos eficazes de se proteger (ou pelo menos detectar) a exploração de bootloaders UEFI assinados vulneráveis desconhecidos e o uso de kits de inicialização UEFI, incluindo:
- Acesso gerenciado aos arquivos localizados na partição do sistema EFI. Na maioria dos cenários de instalação de kits de inicialização UEFI, um atacante precisa modificar o conteúdo da partição do sistema EFI para instalar um kit de inicialização UEFI ou explorar uma vulnerabilidade em um carregador de inicialização UEFI assinado no sistema alvo. A maioria dos produtos de segurança permite criar regras de acesso a arquivos personalizadas definidas pelo usuário, que bloqueiam o acesso a arquivos ou diretórios específicos do sistema (por exemplo, aqui e aqui).
- Personalização da inicialização segura UEFI. Como detalhado no relatório UEFI Secure Boot Customization da NSA, a personalização do Secure Boot pode ser usada para proteger eficazmente contra kits de inicialização UEFI ou, pelo menos, reduzir a superfície de ataque ou permitir revogações mais rápidas de aplicativos UEFI vulneráveis para os proprietários de sistemas, caso as atualizações de revogação oficiais demorem mais tempo. Embora eficaz, frequentemente exige administradores experientes (configurações incorretas do Secure Boot podem fazer com que os sistemas não inicializem temporariamente) e pode ser difícil de gerenciar em grande escala.
- Autenticação remota com TPM, onde as medições dos componentes de inicialização UEFI e a configuração podem ser validadas contra seus valores conhecidos e bons por um servidor remoto de confiança, e, portanto, utilizadas para detectar modificações de inicialização não autorizadas.
Conclusão
O número de vulnerabilidades UEFI descobertas nos últimos anos e as falhas em corrigir ou revogar os binários vulneráveis dentro de um prazo razoável demonstram que nem mesmo uma característica tão essencial quanto o Secure Boot UEFI deve ser considerada uma barreira impenetrável.
No entanto, o que mais nos preocupa no caso da vulnerabilidade relatada neste blogpost não é o tempo que levou para corrigir e revogar o binário, que foi relativamente bom em comparação com casos semelhantes, mas o fato de que não é a primeira vez que se descobre um binário UEFI assinado tão obviamente inseguro. Na realidade, uma aplicação UEFI vulnerável assinada pela Microsoft muito semelhante (CVE-2022-34302), que implementava seu próprio carregador PE inseguro, foi descoberta há cerca de dois anos pela Eclypsium em One Bootloader to Load Them All.
Isso nos leva a questionar quão comum é o uso dessas técnicas inseguras entre os fornecedores de software UEFI de terceiros, e quantos outros bootloaders obscuros, mas assinados, podem estar por aí. Entramos em contato com a Microsoft para informar sobre a situação, com a esperança de que a empresa possa trazer mais transparência para as aplicações UEFI de terceiros que assina, para que qualquer pessoa possa descobrir e denunciar rapidamente essas aplicações UEFI obviamente inseguras, caso tenham passado (ou tenham passado há muito tempo) pela revisão de assinatura de código UEFI de terceiros da Microsoft. Acreditamos que o lançamento planejado pela Microsoft de novos certificados UEFI oferece uma grande oportunidade para que isso aconteça, avançando a transparência da assinatura de terceiros UEFI e a segurança UEFI.
Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.
IoCs
Como os carregadores vulneráveis fazem parte de pacotes de software legítimos que estão potencialmente presentes em milhares de sistemas que nunca foram comprometidos por esses carregadores, não estamos fornecendo indicadores de comprometimento para evitar identificações erradas em massa.
