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:
