Cve-2017-7269-iis 6.0 WebDAV Remote Code execution Vulnerability Analysis

Vulnerability Description:

March 27, using IIS 6.0 on Windows 2003 R2 burst the 0Day Vulnerability (cve-2017-7269), the exploit POC began to circulate, but the bad thing is that the product has stopped updating. The download link to the POC online is as follows.

GitHub Address: Https://github.com/edwardz246003/IIS_exploit

Combined with the above POC, we analyze the cause of the vulnerability and the process of its utilization. In the analysis process, the POC exploit use of the technique is amazed, multiple use of the same vulnerability function triggered, and the same vulnerability exploit code for a different purpose, the end of the ROP way to bypass the GS protection, the implementation of Shellcode.

Debugging Environment:

Windows Server 2003 Enterprise Edition is installed in the virtual machine, and after you install iss6.0, the settings allow WebDAV extensions. The debugger used is: windbg:6.7.0005.1

The remote code performs the following effects:

By access, the exploit succeeds and can execute arbitrary code with network services privileges.

Vulnerability Analysis: Vulnerability function

The vulnerability is in the Scstoragepathfromurl function, which can be seen through code, when the memcpy function is called at the end of a function, the destination address of the copy is derived from the parameters of the function, and the function's parameters are local variables of the upper function, which are stored in the stack space of the upper function. When calling memcpy, the length of the source character to be copied is not determined, resulting in a stack overflow.

It is easier to see by pseudo-code:

Exploit:

In the POC, you can see that the header is sent with two parts <> tags, which will make each of the above loop body will run two times, for the following description is convenient, we define the label portion of the two headers as head_a and head_b.

Vulnerability Utilization Process:

1. In the Hrcheckifheader function, the head_b is assigned to the heap space address by using the head_a overflow.

2. In the Hrgetlockidforpath function, the heap address where the head_b is located is assigned to the virtual table pointer of the local object again by using the head_a overflow, which controls the EIP when the function is called.

3. The object that eventually calls the IECB class offsets the function pointer at 0x24, controlling the EIP

The exploits mainly lie in the Hrcheckifheader function and the function Hrgetlockidforpath.

function Hrcheckifheader main function is to determine the validity of the header that the user passes to. In the function, Hrcheckifheader passes through a while loop to traverse the data in the header of the user input.

The main function of Hrgetlockidforpath is to lock the path information that is passed. In the Hrgetlockidforpath function, the path information is also traversed through the while loop, which also corresponds to a two-time invocation of the vulnerability function.

Commissioning process: two overflow control EIP

Each of the 4 calls to the vulnerability function is broken down:

bp httpext!CParseLockTokenHeader::HrGetLockIdForPath+0x114 ".echo HrGetLockIdForPath_FIRST";bp httpext!CParseLockTokenHeader::HrGetLockIdForPath+0x14f ".echo HrGetLockIdForPath_SECOND";bp httpext!HrCheckIfHeader+0x11f ".echo HrCheckIfHeader_FIRST";bp httpext!HrCheckIfHeader+0x159 ".echo HrCheckIfHeader_SECOND";

Debugging program, the total will be broken down 6 times, we have these 6 breakpoints at the time of the function of the vulnerability in the use of the function to summarize:

First time:

Pause on Hrcheckifheader _first, no impact on exploits

Second time:

Broken in Hrcheckifheader _second, the purpose of calling the vulnerability function here is to use the head_a tag to overflow the vulnerability function to overwrite the address in the stack with the heap address in the head_a tag, which will be used later.

Before running the vulnerability function,

Once the vulnerability function has been run, you can see that the contents of the 0108f90c position in the stack space have been overwritten as 680312C0,680312C0 is exactly the address in a heap.

Third time:

Pause at Hrcheckifheader_first, at which point the function of the vulnerability is to copy the head_b tag to the heap address above. The normal program here will copy the user's incoming header into the stack space, but in the above because of overflow, the head_b tag is copied to the heap. You can see the heap address 680312c0 used.

Fourth time:

Pause to Hrcheckifheader_first, no impact on exploits

Fifth time:

Hrcheckifheader_second, the purpose of calling the vulnerability function here is to use the head_a tag to overflow the vulnerability function in order to overwrite the address in the stack with the heap address in the head_a tag, which will be used later. Overflow AAA DB ebp-14 the address in the stack to the address 680312c0 in the heap, where ebp-14 address is also overwritten, this address in the sixth overflow below, will be assigned to the object pointer, here control the value of ebp_14, you can control the next object pointer.

Sixth time:

Hrcheckifheader_first controls the EIP by invoking a virtual function in a sub-function below the function.

To summarize, in the above six calls, the need to pay attention to the use of the process is:

1) The second and third places are necessary, because there is no second place to use, there will be no third place to copy the head_b into the heap. No address in the heap can control the virtual table pointer when it is called for the sixth time. So there is no second overflow call, there will be no head_b memory in the heap. (originally Head_b is the end of the stack space, it is because of overflow to put head_b in the heap space)

2) The fifth time the stack overflow again, the address of the heap is written to the local variable, only to cause the sixth time can successfully call virtual function. Because the virtual function is called for the sixth time, it is the virtual function of the local variable being called. If there is no overflow at the fifth breakpoint, it is impossible to successfully write the address in the heap to the virtual function of the local variable, and the virtual function pointer cannot be controlled.

It can be seen that two times the vulnerability function overflow operation, where one overflow operation (at the second breakpoint) overwrites the stack address to the heap address, ensuring that Head_b is written to the heap, and another overflow operation (at the fifth breakpoint) points the pointer of the local variable object to the heap. Two times overflow code is the same, the purpose of the implementation is different, double sword wall, craftsmanship, skillfully combined to achieve the control of the EIP.

ROP

After controlling the EIP, use ROP technology to bypass the GS protection.

Execute a custom function using the Shareduserdata method

Come to Shellcode Place:

Shellcode a loop decoding:

After the decoding is done, it is the more beautiful shellcode.

Mitigation Scenarios:

L DISABLE the WebDAV service for IIS

L use WAF-related protective equipment

L recommend that users upgrade to the latest system Windows Server 2016.

Summarize

It can be seen from the analysis that the vulnerability principle is simply because the length of the copy function is not judged, which results in a stack overflow. This also reminds programmers of the use of unsafe memory manipulation functions to turn on all protections when compiling code. From the perspective of exploit, for stack overflow, the use of the method to modify the return address, cover virtual table pointers and other methods, but this use of stack overflow pointer to the heap space, when needed, and then through the overflow of the heap space address back to the stack space in the use of the technique is really unconventional, different, Using multiple overflows at the same vulnerability code is the ultimate implementation of exploit, even after the analysis has been completed with a long aftertaste.

Cve-2017-7269-iis 6.0 WebDAV Remote Code execution Vulnerability Analysis