Analysis of Microsoft WebDAV Elevation of Privilege Vulnerability (cve-2016-0051)

Analysis of Microsoft WebDAV Elevation of Privilege Vulnerability (cve-2016-0051)

1. About cve-2016-0051
The official description of Microsoft is as follows:
If the Microsoft Web Distributed creation and Version Management (WebDAV) Client Authentication input is inappropriate, the privilege escalation vulnerability exists. Successful exploits allow attackers to execute arbitrary code with elevated privileges.
To exploit this vulnerability, attackers must first log on to the system. Then, attackers can run an application specially designed to exploit this vulnerability to control the affected system.
Workstations and servers are most vulnerable to this attack. This security update program fixes this vulnerability by correcting WebDAV verification input.
According to Microsoft, this vulnerability is a privilege escalation vulnerability that triggers BSOD on win8 or higher systems, in Windows and below, the privilege can be obtained successfully. Therefore, Microsoft sets the security level of this vulnerability to medium. Even so, we should pay attention to it. After all, vulnerabilities that can gain administrator privileges are still very harmful.
Through basic research, this article roughly explores the process of vulnerability repair and execution for your reference.
2. Analysis and Verification
Microsoft fixed this issue in the patch released in February 9, 2016. Patch name: Windows6.1-KB3124280-x86. Later, after comparing the patch, we found that Microsoft added the MRxDavIsCallerPrivileged function to mrxdav. sys and modified the execution process of DAVFastIoDeviceControl and DAVDevFcbXXXControlfile.
The process diagram of the execution of marxdav. sys before and after the patch. (The red box shows the patch version)


 
1) The MRxDavIsCallerPrivileged function verifies the access permission of the process by calling the SeAccessCheck function. In this way, all files controlled by functions and file control blocks distributed by fastio need to be verified with permissions to check whether there are sufficient administrator permissions for execution. If not, the MRxDavIsCallerPrivileged function returns false, then call the failed route.

2) In the call history function, the MrxDAVEfsControl function adds a verification of whether the passed device_object is null. See the thumbnail shown in the red box:

The enlarged image is as follows:

According to IDA's analysis:


Is the MRX_SRV_OPEN + 0 × 18 object struct verified in the patch. If it is not NULL, The MRX_SRV_OPEN + 0 × 18 + 0xC object is verified. if the object is normal, verify the device object. If one is NULL, the transfer fails, and RxReleaseFcbResourceInMRx is called to release MrxFCB.
The entire function derivation shows that the device_object passed into the iofcalldriver function comes from:
Device_object = rx_context + 0 × 38 + 0 × 18 + 0 × 10 (win7 sp1x86 System)



This struct is not found in windbg, but is found in windws driver kits. in the header file h, we can see the structure of rx_context. The following is a personal derivation (for win7 sp1 x86 only ):
MRX_SRV_OPEN = rx_context + 0 × 38;
MRX_FCB = MRX_SRV_OPEN + 0 × 10;
Currently, AAA indicates the structure = MRX_SRV_OPEN + 0 × 18;
DEVICE_OBJECT = AAA + 0 × 10;
Assume FILE_OBJECT = AAA + 0x0C
Through windbg, we can see the process of device_object in the verification and judgment process. The esi value is the rx_context structure. MRX_SRV_OPEN is bc4381f8; the structure AAA is 9920f508; for example, please correspond in sequence.

The verification and determination process is as follows: first verify whether the AAA structure is null, then verify AAA + 0x0C in sequence, and finally verify AAA + 0 × 10, that is, DEVICE_OBJECT.

3. About the vulnerability Program
While Microsoft released patches, the hacker koczkatamas announced the vulnerability source code program.
Vulnerability principle:
When rdbss calls mrxdav, rdbss is used! RxCreateRxContext creates a rx_context struct parameter, while the default device_object object initialization of the rx_context struct is null. In the memory, null can be 0x00000000. Therefore, as long as the author carefully constructs a device_object structure starting with the address 0x00000000, fill in the address of the function corresponding to MajorFunction (user's function address ). However, to execute the command, you still need to call the IoCallDriver distribution function. To call the IoCallDriver distribution function, the author uses NtFsControlFile as the trigger to enter the mrxdav! The MrxDAVEfsControl condition is called to IoCallDriver.

Therefore, in the source code published by the author, a piece of memory starting with 0 × 00000000 is applied, and the structure of device_object is complete through the Marshal. Copy function. For example:

Through windbg; we can see that the address of shellcode is 71c91150. It is also the place to be executed. For example:

For example, the original function IofCallDriver is executed in the following way:
DriverObject-> MajorFunction [irpSp-> MajorFunction] (DeviceObject, Irp );
The modified function is executed as follows:
DriverObject-> shellcode (DeviceObject, Irp );
The red box is where the r3 program is executed. (The number of debugging times is different, and the address of the shellcode Execution function is also different. The address of shellcode is 6ae91150 .) In this way, any r3 function is executed from the kernel, and the system Token is assigned to the eprocess Token of the application to obtain the permission.

4. Summary
Through preliminary vulnerability analysis, we found that windows is profound and profound. This vulnerability does not search for breakthrough points through coverage, overflow, or other methods. Instead, it uses NULL in the memory to construct the vulnerability as 0 × 00000000. At the same time, how can we get the greatest security with the smallest changes when dealing with vulnerabilities. What Microsoft has done is worth learning and thinking.