Pesquisa sobre CVE-2025-3052, uma vulnerabilidade de firmware Insyde que expõe uma primitiva de escrita arbitrária capaz de modificar ponteiros críticos de segurança.
Este repositório centraliza material de pesquisa relacionado à CVE-2025-3052, uma vulnerabilidade de corrupção de memória em um módulo UEFI assinado com o certificado de terceiros da Microsoft que permite a um atacante corromper estruturas de firmware críticas para a segurança, neutralizar a aplicação do Secure Boot e executar código arbitrário não assinado antes do carregamento do sistema operacional. Inclui análise técnica da causa raiz e da técnica de exploração, binários vulneráveis reais e educacionais, e documentação de apoio destinada a ajudar pesquisadores a compreender, reproduzir e experimentar com esta classe de vulnerabilidade.
A CVE-2025-3052 foi originalmente descoberta e divulgada de forma responsável pela Binarly Research Team. Referências oficiais e da comunidade:
Este repositório inclui dois binários vulneráveis, fornecidos com diferentes objetivos de pesquisa e aprendizagem.
Este binário representa a vulnerabilidade tal como existia em ambiente real.
A CVE-2025-3052 é uma vulnerabilidade de bypass do Secure Boot que afeta sistemas UEFI, causada pelo tratamento inseguro de dados obtidos de uma variável NVRAM dentro de uma aplicação UEFI assinada. A vulnerabilidade permite a um atacante corromper estruturas de firmware críticas para a segurança durante o processo de boot, quebrando efetivamente a cadeia de confiança da UEFI e permitindo a execução de código não assinado antes do carregamento do sistema operacional.
O que torna esta vulnerabilidade particularmente impactante não é apenas a natureza do bug em si, uma primitiva de corrupção de memória, mas o contexto em que existe: um módulo UEFI assinado com o certificado UEFI de terceiros da Microsoft, confiável por padrão na grande maioria dos sistemas modernos. Como resultado, a exploração ocorre em um dos estágios de execução mais precoces e privilegiados da plataforma, antes dos controles de segurança em nível de SO.
O Secure Boot é um recurso de segurança central da UEFI concebido para impor a cadeia de confiança da plataforma desde o firmware até o sistema operacional. Seu propósito principal é impedir que componentes de boot não autorizados ou maliciosos, como bootkits, sejam executados durante o processo de boot.
Em alto nível, o Secure Boot funciona validando criptograficamente executáveis UEFI antes que lhes seja permitido executar. Esta validação é realizada usando dois bancos de dados mantidos pelo firmware:
Uma aplicação UEFI tem permissão para executar se:
Por padrão, a maioria dos sistemas vem com os seguintes certificados confiáveis em db:
Os módulos vulneráveis associados à CVE-2025-3052 foram assinados usando o certificado Microsoft Corporation UEFI CA 2011. Como este certificado é amplamente confiável entre fornecedores e plataformas, qualquer aplicação assinada que o utilize pode executar na maioria dos sistemas UEFI sem interação do usuário. Esta confiança ampla amplifica significativamente o impacto de uma vulnerabilidade dentro de tal módulo, pois efetivamente contorna as garantias de proteção pretendidas pelo Secure Boot.
O módulo UEFI vulnerável foi inicialmente descoberto durante análise em larga escala de binários UEFI enviados a repositórios públicos de malware, mais notavelmente o VirusTotal. Embora o primeiro envio público do módulo tenha ocorrido em novembro de 2024, a inspeção de sua assinatura Authenticode revelou que ele havia sido assinado já em outubro de 2022, indicando que o binário pode ter circulado por um período considerável antes da detecção.
O nome de arquivo original observado durante a análise foi Dtbios-efi64-71.22.efi. O exame de strings embutidas, metadados de certificado e comportamento do arquivo sugeriu fortemente que o módulo foi desenvolvido pela DT Research, Inc, um fornecedor especializado em dispositivos móveis de computação robustos.
Engenharia reversa adicional revelou que o módulo é um utilitário de gravação de BIOS, concebido para ler uma imagem de firmware do disco e gravá-la na ROM do sistema. Embora originalmente destinado ao hardware da DT Research, o módulo não é restrito a uma plataforma específica e pode executar em qualquer sistema que confie no certificado UEFI de terceiros da Microsoft.
Uma pista crítica durante o reconhecimento foi a presença da variável NVRAM IhisiParamBuffer. Esta variável está intimamente associada a implementações de firmware baseadas em Insyde e já havia estado envolvida em outras vulnerabilidades divulgadas pela Binarly (por exemplo, BRLY-2022-023 e BRLY-2023-005). Sua presença sugeriu imediatamente uma potencial classe de problemas relacionados a NVRAM.
A causa raiz da CVE-2025-3052 reside no uso inseguro de dados lidos de uma variável NVRAM sem validação. Especificamente:
Como resultado, um atacante que consiga controlar a variável IhisiParamBuffer ganha a capacidade de influenciar onde na memória essas escritas ocorrem. Embora a primitiva de escrita seja um tanto restrita, tipicamente permitindo escritas de zero ou pequenas constantes em um endereço arbitrário, ela ainda é poderosa o suficiente para corromper estado crítico do firmware.
No proof of concept da Binarly, o ataque tem como alvo a variável global gSecurity2, que contém um ponteiro para o Security2 Architectural Protocol (para uma explicação detalhada desta técnica específica de exploração, consulte o seguinte repositório "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). Este protocolo é consultado pelo serviço LoadImage para impor a política de Secure Boot, o que significa que sobrescrever gSecurity2 com um ponteiro nulo efetivamente desabilita as verificações de Secure Boot em tempo de execução. Crucialmente, este bypass é transparente para o sistema operacional: uma vez inicializado, o Secure Boot ainda aparece habilitado no nível do SO, mesmo tendo sido totalmente neutralizado no nível do firmware.
Uma nuance importante é que, em plataformas baseadas em Insyde, a variável IhisiParamBuffer é tipicamente bloqueada como somente leitura, o que efetivamente impede a exploração nesses sistemas sem uma vulnerabilidade adicional. Ironicamente, isso significa que o fornecedor cujo IBV introduziu o padrão de variável vulnerável em primeiro lugar está entre os menos expostos, enquanto todas as outras plataformas permanecem em risco. Nos casos em que a variável está bloqueada, um bypass como o BRLY-2023-005 pode ser encadeado para obter acesso de escrita à variável antes de prosseguir com a exploração. Em sistemas onde a variável é diretamente gravável, o ataque é direto e altamente confiável.
O seguinte descreve o ataque ponta a ponta aproveitando a CVE-2025-3052, assumindo um atacante privilegiado com acesso em nível de SO:
A Microsoft determinou que 14 módulos UEFI diferentes foram afetados e mitigou o problema adicionando seus hashes ao dbx do Secure Boot.
| Module Name | Authenticode SHA-256 Hash |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
Trabalhando em algo semelhante? Pesquisando UEFI, segurança de Kernel, exploração, ou outro tópico de segurança interessante? Se precisar de ajuda para desenvolver um exploit, explorar uma técnica, ou apenas trocar ideias, não hesite em entrar em contato. Estou sempre aberto a discutir pesquisa, ajudar no que puder, e colaborar em projetos interessantes. Sinta-se à vontade para me contatar no LinkedIn.
