Um investigador do Google Project Zero divulgou uma vulnerabilidade zero-day no Windows 10 que podia ser explorada de forma a ignorar o Windows Lockdown Policy nos sistemas com User Mode Code Integrity (UMCI), e permitindo, assim, a execução de código arbitrário por parte dos atacantes.
O hacker do Projeto Zero, James Forshaw, divulgou publicamente o problema porque a vulnerabilidade não foi corrigida num período de 90 dias, e que está de acordo com a política de divulgação do Google.
A day-zero-vulnerability afeta todas as versões do Windows 10 com o UMCI ativo, e Forshaw explorou-a com sucesso no Windows 10S.
“The enlightened Windows Lockdown Policy check for COM Class instantiation can be bypassed by using a bug in .NET leading to arbitrary code execution on a system with UMCI enabled (e.g. Device Guard)” states the security advisory published by Google.
A falha está associada à maneira como a lockdown policy da classe WLDP COM reage quando um objeto COM .NET é instanciado.
Existe uma lista entre 8 e 50 COM objects na lockdown policy WLDP COM que outros objetos podem instanciar.
Para evitar um ataque, uma implementação correta da diretiva deve verificar o CLSID passado para DllGetObject na lista codificada acima referida.
The WLDP COM Class lockdown policy contains a hardcoded list of 8 to 50 COM objects which enlightened scripting engines can instantiate. Excluding issues related to the looking up of the correct CLSID (such as previously reported abuse of TreatAs case 40189).” continues the analysis.
“This shouldn’t be a major issue even if you can write to the registry to register an existing DLL under one of the allowed COM CLSIDs as a well behaved COM implementation should compare the CLSID passed to DllGetObject against its internal list of known objects.”
O especialista do Google descobriu que quando um objeto COM .NET é instanciado, o CLSID passado para o DllGetClassObject do mscoree é usado apenas para procurar as informações de registo no HKCR, o CLSID é descartado, e o objeto .NET é criado.
Isto significa que um atacante pode adicionar chaves de registo, incluindo a HKCU, que carregaria uma classe COM arbitrária em um dos CLSIDs confiáveis.
“This has a direct impact on the class policy as it allows an attacker to add registry keys (including to HKCU) that would load an arbitrary COM visible class under one of the allowed CLSIDs. As .NET then doesn’t care about whether the .NET Type has that specific GUID you can use this to bootstrap arbitrary code execution,” continues the analysis.
O investigador do Google publicou um código como prova de conceito para a vulnerabilidade, composta por dois ficheiros:
- an .INF to set-up the registry.
- a .SCT created with the DotNetToJScript free tool that could be used to load an untrusted .NET assembly into memory to display a message box.
O investigador comunicou a vulnerabilidade à Microsoft no dia 19 de janeiro, mas a gigante tecnológica não deu resposta em 90 dias.
“This issue was not fixed in April patch Tuesday therefore it’s going over deadline. This issue only affects systems with Device Guard enabled (such as Windows 10S) and only serves as a way of getting persistent code execution on such a machine. It’s not an issue which can be exploited remotely, nor is it a privilege escalation,” added the expert.