Um novo método de ataque pode ser usado para contornar o Microsoft Driver Signature Enforcement (DSE) em sistemas Windows totalmente corrigidos, resultando em um ataque ao sistema operacional (SO).
“Esse desvio permite carregar drivers de kernel não registrados, permitindo que invasores usem rootkits personalizados que podem desabilitar controles de segurança, ocultar processos e atividades de rede, manter sigilo e muito mais”, disse o pesquisador do SafeBreach, Alon Leviev, em um relatório compartilhado com The Hacker News.
As descobertas mais recentes baseiam-se em análises anteriores que revelaram duas falhas de elevação de privilégio no processo de atualização do Windows (CVE-2024-21302 e CVE-2024-38202) que podem ser usadas para reverter o software Windows atual para uma versão mais antiga. que contém um risco de segurança não associado.
A exploração apareceu na forma de uma ferramenta chamada Windows Downdate, que, de acordo com Leviev, poderia ser usada para sequestrar o processo do Windows Update para realizar um downgrade completamente invisível, persistente e irreversível dos principais componentes do sistema operacional.
Isso pode ter consequências graves, pois oferece aos invasores uma alternativa melhor ao ataque Traga seu próprio driver vulnerável (BYOVD), permitindo-lhes comprometer módulos primários, incluindo o próprio kernel do sistema operacional.
A Microsoft então abordou CVE-2024-21302 e CVE-2024-38202 em 13 de agosto e 8 de outubro de 2024, respectivamente, como parte das atualizações do Patch Tuesday.
O método mais recente desenvolvido por Leviev usa uma ferramenta de downgrade para fazer o downgrade do patch de desvio DSE “ItsNotASecurityBoundary” em um sistema Windows 11 totalmente atualizado.
ItsNotASecurityBoundary foi escrito pela primeira vez pelo pesquisador do Elastic Security Labs Gabriel Landau em julho de 2024 junto com PPLFault, descrevendo-o como uma nova classe de bug codificado de falsa imutabilidade de arquivo. A Microsoft corrigiu isso no início de maio.
Resumindo, ele usa uma condição de corrida para substituir um arquivo de catálogo de segurança verificado por uma versão mal-intencionada contendo a assinatura authenticode de um driver de kernel não assinado, que então solicita ao invasor que diga ao kernel para carregar o driver.
O mecanismo de integridade de código da Microsoft, que é usado para autenticar o arquivo usando a biblioteca de modo kernel ci.dll e, em seguida, passar um forte catálogo de segurança para verificar a assinatura do driver e carregá-lo, efetivamente deu ao invasor a capacidade de executar código que não é adequado para o núcleo.
O desvio do DSE é obtido usando a ferramenta de downgrade para substituir a biblioteca “ci.dll” por uma versão mais antiga (10.0.22621.1376.) para reverter o patch colocado pela Microsoft.
Dito isto, existe uma barreira de segurança que pode impedir que tal passagem seja bem-sucedida. Quando a segurança baseada em virtualização (VBS) está em execução no host de destino, a verificação do catálogo é executada pela DLL de integridade de código do kernel seguro (skci.dll), em oposição ao ci.dll.
No entanto, é importante observar que a configuração padrão é VBS sem bloqueio de interface de firmware extensível unificada (UEFI). Como resultado, um invasor pode desativá-lo alterando as chaves de registro EnableVirtualizationBasedSecurity e RequirePlatformSecurityFeatures.
Mesmo nos casos em que o bloqueio UEFI está habilitado, um invasor pode desabilitar o VBS incluindo um dos arquivos base com uma contraparte inválida. Finalmente, as etapas de exploração que um invasor precisa seguir estão abaixo:
- Desative o VBS no registro do Windows ou desative o SecureKernel.exe
- Faça downgrade de ci.dll para uma versão não publicada
- Reinicia a máquina
- Usando o desvio ItsNotASecurityBoundary DSE para obter execução de código em nível de kernel
A única instância em que falha é quando o VBS é habilitado com a chave UEFI e o sinalizador “Obrigatório”, o último dos quais causa uma falha de inicialização quando os arquivos VBS são corrompidos. O modo obrigatório é ativado por padrão por meio de uma alteração no registro.
“A configuração obrigatória impede que o carregador do sistema operacional continue a inicializar caso o hipervisor, o kernel seguro ou um de seus módulos dependentes falhe ao carregar”, observa a Microsoft em seu documento. “Deve-se ter especial cuidado antes de habilitar este modo, pois, caso haja alguma falha dos módulos de virtualização, o sistema se recusará a iniciar.”
Portanto, para mitigar totalmente o ataque, é importante que o VBS esteja habilitado com bloqueio UEFI e sinalização obrigatória definida. Em qualquer outro modo, torna possível que um adversário desabilite o recurso de segurança, execute degradação de DDL e obtenha desvio de DSE.
“Grande lição […] que as soluções de segurança devem tentar detectar e prevenir processos de hacking mesmo em coisas que não excedam os limites de segurança”, disse Leviev ao Hacker News.
