Análise e exploração do CVE-2025-4275 (Hydr0ph0bia), uma fraqueza na cadeia de confiança do Secure Boot onde variáveis de firmware são usadas para introduzir certificados controlados pelo atacante que são confiados por componentes de boot subsequentes.
Este repositório contém material de pesquisa relacionado ao CVE-2025-4275, uma vulnerabilidade de bypass do Secure Boot que afeta firmwares compatíveis com UEFI baseados no Insyde H2O. Ele centraliza a análise técnica da vulnerabilidade, os binários envolvidos na questão, bem como documentação e ferramentas destinadas a ajudar pesquisadores a compreender melhor, estudar e experimentar essa vulnerabilidade em contextos tanto do mundo real quanto educacionais.
O CVE-2025-4275 foi originalmente descoberto e divulgado de forma responsável por Nikolaj Schlej, com a coordenação realizada através do CERT/CC. Referências oficiais e da comunidade:
O CVE-2025-4275, apelidado de Hydroph0bia (um trocadilho com Insyde H2O), é uma vulnerabilidade de bypass do Secure Boot que afeta firmwares compatíveis com UEFI construídos sobre a plataforma Insyde H2O. A vulnerabilidade decorre de uma falha de design no subsistema de atualização de firmware: um certificado de assinatura que deveria ser carregado em uma variável NVRAM volátil por um driver confiável pode, em vez disso, ser pré-populado como uma variável não volátil por um atacante, fazendo com que o firmware confie em código externo arbitrário como se tivesse sido assinado pela própria Insyde.
O que torna essa vulnerabilidade particularmente impactante é a combinação de sua simplicidade e seu alcance. A exploração exige apenas privilégios de administrador local, suficientes para gravar arquivos na EFI System Partition e criar variáveis NVRAM, e afeta qualquer sistema executando firmware Insyde H2O construído antes de 10 de junho de 2025. O ataque é agnóstico em relação ao OEM, ou seja, aplica-se amplamente a Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo e qualquer outro fornecedor que distribua firmware baseado em Insyde.
A UEFI fornece uma interface abstrata para armazenamento de variáveis não voláteis conhecida como NVRAM. Uma peculiaridade antiga dessa interface é que uma variável não volátil com um determinado nome e GUID pode coexistir com, e sombrear, uma variável volátil com a mesma identidade. Se o código espera uma variável volátil (criada em tempo de execução por um driver confiável), mas uma variável não volátil com o mesmo nome já existe, a versão não volátil pode ser consumida em seu lugar. Esse comportamento, às vezes chamado de shadowing de variáveis NVRAM, é a base dessa vulnerabilidade.
O subsistema de atualização de firmware do Insyde H2O depende de duas variáveis NVRAM para comunicar um certificado de assinatura entre drivers:
No fluxo esperado, ambas as variáveis são criadas como voláteis pelo BdsDxe durante o processo de atualização de firmware. O SecurityStubDxe então as consome para verificar se o isflash.bin é assinado pelo certificado da Insyde antes de permitir sua execução. A falha crítica é que o SecurityStubDxe não valida se essas variáveis são voláteis ou não voláteis antes de confiar em seu conteúdo.
A causa raiz do CVE-2025-4275 é que o SecurityStubDxe usa uma função de biblioteca genérica para ler SecureFlashSetupMode e SecureFlashCertData em vez de chamar o serviço de runtime GetVariable diretamente. Isso significa que ele não consegue distinguir entre uma variável volátil definida por um BdsDxe confiável e uma variável não volátil pré-populada por um atacante (para uma explicação detalhada dessa técnica específica, consulte o seguinte repositório "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
Como resultado, um atacante com privilégios de administrador local pode:
No próximo boot, o SecurityStubDxe encontrará ambas as variáveis, tratá-las-á como legítimas e confiará em qualquer executável UEFI assinado com o certificado do atacante, efetivamente contornando o Secure Boot por completo. Nenhuma interação em nível de firmware, acesso a hardware ou exploração de uma primitiva de corrupção de memória é necessária. A superfície de ataque é simplesmente a interface de escrita da NVRAM da UEFI, acessível a partir de uma sessão privilegiada do SO.
A vulnerabilidade foi descoberta durante uma revisão de segurança de um HUAWEI MateBook 14 2023, executando um firmware baseado em Insyde H2O com Secure Boot, senha de firmware e outros recursos de segurança modernos habilitados. Apesar dessas proteções, a exploração completa foi alcançada usando apenas privilégios de administrador em nível de SO.
O estágio inicial de exploração requer uma pequena ferramenta Windows (SFCD) que:
Após reiniciar, o SecurityStubDxe lê ambas as variáveis e começa a confiar em qualquer coisa assinada pelo certificado do atacante. Uma demonstração prática desse primeiro estágio é o carregamento de um driver UEFI CrScreenshotDxe assinado com certificado personalizado, que captura com sucesso uma captura de tela da tela do BIOS Setup, com o Secure Boot habilitado, como prova de execução de código arbitrário no ambiente de firmware.
Uma nuance importante: a variável IhisiParamBuffer presente no CVE-2025-3052 geralmente é bloqueada em plataformas baseadas em Insyde, tornando a exploração direta mais difícil nelas. O CVE-2025-4275 não exige que tal variável seja gravável e não depende de nenhuma primitiva de corrupção de memória. O ataque funciona em qualquer sistema Insyde H2O onde o atacante possa gravar na NVRAM, que é o comportamento padrão em firmware não corrigido.
O seguinte descreve o ataque de ponta a ponta para o estágio inicial de bypass do Secure Boot, assumindo um atacante privilegiado com acesso em nível de SO:
O bypass do Secure Boot alcançado na Parte 1 abre a porta para um segundo estágio significativamente mais impactante: a tomada de controle completa do volume DXE, alcançada ao sequestrar o próprio processo de atualização de firmware da Insyde.
O subsistema de atualização de firmware no Insyde H2O funciona da seguinte forma: o atualizador do SO coloca uma cápsula de firmware e o aplicativo atualizador assinado (isflash.bin) na EFI System Partition, então define um flag SecureFlashTrigger=1 dentro da variável NVRAM SecureFlashInfo. No próximo boot, o firmware detecta o gatilho, desabilita as proteções de escrita do flash durante o PEI e, eventualmente, chama LoadImage em isflash.bin após verificá-lo contra o certificado da Insyde, o mesmo mecanismo de certificado que o CVE-2025-4275 permite a um atacante substituir.
Três etapas técnicas adicionais são necessárias para escalar do bypass do Secure Boot para a tomada de controle do DXE:
Uma vez que todas as três condições sejam atendidas, o firmware reinicia em modo de atualização, carrega o isflash.bin personalizado do atacante (assinado com o certificado do atacante, agora confiável devido ao SecureFlashCertData sombreado) e o executa com o flash SPI desprotegido. A partir dessa posição, o atacante pode gravar conteúdo arbitrário no volume DXE, instalando drivers persistentes ou modificando componentes de firmware de maneiras que sobrevivem à reinstalação do SO e à maioria dos controles de segurança.
A Insyde lançou uma correção como parte do ciclo de patches de 10 de junho de 2025. A correção foi analisada comparando duas atualizações consecutivas de BIOS da Dell (uma pré-patch, uma pós-patch) usando relatórios gerados pelo UEFITool e diffing binário via Diaphora.
As mudanças concentraram-se em três drivers:
A correção é eficaz sob a suposição de que um atacante não pode contornar a VariablePolicy ou a LibSetSecureVariable. No entanto, a implementação padrão da VariablePolicy do EDK2 usa um flag global internamente, que é estruturalmente semelhante ao InsydeVariableLock derrotado na Parte 2. A edição física da NVRAM via hardware de programação SPI também contornaria a correção por completo, embora ataques físicos estejam convencionalmente fora do escopo dos modelos de ameaça do Secure Boot.
A remediação recomendada pelo pesquisador, remover completamente a NVRAM do mecanismo de retransmissão de certificados entre BdsDxe e SecurityStubDxe, foi tentada pela Insyde, mas causou regressões e foi adiada para um futuro ciclo de engenharia.
Qualquer fornecedor que distribua firmware baseado em Insyde H2O construído antes de 10 de junho de 2025 é potencialmente afetado. Status confirmado no momento da divulgação:
| Fornecedor | Status |
|---|---|
| Dell | Corrigido - atualizações de BIOS lançadas logo após o fim do embargo |
| Lenovo | Vulnerável - correções anunciadas, entrega a partir de 2025-07-30 |
| Framework | Vulnerável - nenhuma estimativa de entrega fornecida no momento da divulgação |
| Acer | Nenhum aviso ou correção publicado no momento da divulgação |
| Fujitsu | Nenhum aviso ou correção publicado no momento da divulgação |
| HP | Nenhum aviso ou correção publicado no momento da divulgação |
| Huawei | Fornecedor do dispositivo de teste original - status da correção desconhecido |
Trabalhando em algo semelhante? Pesquisando UEFI, segurança de Kernel, exploração ou outro tópico de segurança interessante? Se você precisa 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 pesquisas, ajudar no que puder e colaborar em projetos interessantes. Sinta-se à vontade para me contatar no LinkedIn.
