Windows Kernel Elevation of Privilege Vulnerability (CVE 2016-3371)

Introduction

The Windows registry is a hierarchical tree with nodes called keys and each key can contain subkeys or values, a logical group of keys is called a hive. By default Windows has 7 standard hives .There are many reasons to target the registry to gain persistence by modifying entries, to obtain user and system information by enumeration, DLL hijacking etc.. Many legitimate applications use hives to store application specific data. Application hives are loaded under a special built-in root registry node \Registry\A, which cannot be enumerated or traversed. This hive is loaded using RegLoadAppKey, which returns a handle for the corresponding hive. The only way to access the said hive is using this handle.

The vulnerability described here uses these registry keys to trick the operating system in to executing an application with higher privilege. In short windows allows unprivileged user account to load a per user registry hive to a location other than \Registry\A. This operation can be misused to gain System level privileges.

Similar to application hives, user hives do not support security token on the keys but rather for the whole hive. This means that the token for a system level user hive loaded under a traversable root like \Registry\User or \Registry\Machine can be used to elevate privilege. In our case we are trying to execute within the context of the LocalSystem Account, this is built-in default account and has extensive privileges.

Registry root nodes
Registry root nodes

A POC was created by James Forshaw of Google Project Zero. Basically it registers a type library, which executes the poc again to spawn a shell with System privileges. COM is Microsoft’s binary standard that defines the structure of a compiled module so that it can shared across various programming languages. The registry contains information about all COM objects on the system. It uses various keys to describe the COM object one such entry is TypeLib. An application can determine what a COM object supports based on the TypeLib key.

TypeLib
TypeLib

Exploit
A hive is registered under the \Registry\User\S-1-5-18_Classes . When this registry key is queried, the value is loaded as a system component. The registry with “Classes” keys are referred to find COM registrations. In this case the lookup is triggered using winlogon.exe and svchost.exe.

As soon as the exploit is executed it creates a scriptlet (code embedded on HTML). After which a dummy hive is created .

Creating dummy hive
Creating dummy hive

Next we create type library entries for \Registry\User\S-1-5-18_Classes and load the dummy hiv. Here it registers the scriptlet.

Adding keys
Adding keys

The exploit locks the computer to trigger winlogon.exe and svchost.exe to refer the all COM type libraries from the registry. After unlocking the computer we can see a command prompt window with System level integrity. Essentially this behavior can reproduced by triggering any service program which is running in the context of the built-in Local System account and refers to type libraries via the registry.

Command prompt with system level integrity
Command prompt with system level integrity
Referring type libraries
Referring type libraries

When svchost runs the scriptlet it spawns the command prompt. svchost uses LoadTypeLib function to parse the register values, as per documentation if the value is not a stand-alone type library or DLL or an executable it will be parsed into a COM moniker for a system component. Below we can see the exploit start with poc.exe followed by svchost creating a process with poc.exe and finally the second instance of poc.exe spawning cmd.exe.

Process flow
Process flow

The exploit can be made more stealthy by hiding the command prompt window, this can be done by using the CREATE_NO_WINDOW flag during createprocess call for ‘cmd.exe’. The cmd process can be further used as a launch pad for binaries of our choice. As a test we have executed notepad.

Notepad with system level integrity
Notepad with system level integrity

Post Patch Results
After applying the patch on Windows 10. We are unable to create per-user hives to default registry hives. We receive {Access Denied} message.

Post patch
Post patch

Conclusion
The vulnerability lies in the operation of the functions responsible for supporting and managing per-user registry hives in windows. The same behavior is observed in Windows 8.1 as well.

Exploit on Windows 81
Exploit on Windows 81

Microsoft has released security bulletin MS16-111 covering this vulnerability and providing kernel security updates to address the same. QID 91276 checks for the presence of said updates.

References
Windows Kernel Elevation of Privilege Vulnerability
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3371

Windows: NtLoadKeyEx User Hive Attachment Point EoP
https://bugs.chromium.org/p/project-zero/issues/detail?id=865

Application Hives
https://msdn.microsoft.com/en-us/library/windows/hardware/jj673019(v=vs.85).aspx

Registry Supporting Files – Registry Backups
http://www.herongyang.com/Windows/Registry-Supporting-Files-and-Backups.html

Leave a Reply

Your email address will not be published. Required fields are marked *