Google Discloses Windows Lockdown Policy Zero-Day
A Windows 10 vulnerability that could bypass Windows Lockdown Policy and result in arbitrary code execution remains unpatched 90 days after Microsoft has been informed on the bug’s existence.
On systems with User Mode Code Integrity (UMCI) enabled, a .NET bug can be exploited to bypass the Windows Lockdown Policy check for COM Class instantiation, security researcher James Forshaw of Google’s Project Zero team.
The issue was reproduced on Windows 10S, but is said to impact all Windows 10 versions with UMCI enabled.
The vulnerability, the security researcher explains, resides in the manner in which the WLDP COM Class lockdown policy behaves when a .NET COM object is instantiated.
The policy contains a hardcoded list of 8 to 50 COM objects which enlightened scripting engines can instantiate. Thus, even if one would be able to register an existing DLL under one of the allowed COM CLSIDs, a good implementation should check the CLSID passed to DllGetObject against said internal list, and prevent attacks.
What the security researcher discovered was that, when a .NET COM object is instantiated, the CLSID passed to DllGetClassObject is only used to look up the registration information in HKCR, the CLSID is thrown away, and the .NET object created.
Because of that, an attacker can add registry keys, including to HKCU, to load an arbitrary COM visible class under one of the allowed CLSIDs.
“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,” the researcher notes.
For a successful exploitation, an attacker could use tools such as Forshaw’s DotNetToJScript, a free tool that allows users to generate a JScript which bootstraps an arbitrary .NET Assembly and class.
Forshaw also published a Proof-of-Concept as two files: an .INF to set-up the registry and a .SCT. The latter is an example built using DotNetToJScript to load an untrusted .NET assembly into memory to display a message box, but it could be used for more than that.
The flaw was reported to Microsoft on January 19, when the company acknowledged the flaw. As per Project Zero’s policy, vendors are given 90 days to patch flaws before they are made public, and Microsoft didn’t meet the deadline for this issue.
The bug, however, isn’t critical, this being one of the main reasons details on it were publicly released.
“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,” the security researcher explains.
To abuse the flaw, an attacker would require foothold on the impacted machine to install the needed registry entries. A remote code execution flaw in the operating system could be abused for that.
Considering that there are known Device Guard bypasses in the .NET framework that haven’t been fixed and continue to be usable, the security vulnerability is less serious than it would have been if all known avenues for bypass were fixed, Forshaw concludes.
