Shulou(Shulou.com)05/31 Report--

This article is about how to analyze high-risk UAF vulnerabilities in Microsoft RDP services. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

I. brief introduction

CVE-2019-0708 has been disclosed, the following will focus on the following aspects of the vulnerability.

1. After analysis, it is proved that the vulnerability is a UAF vulnerability. When the pointer causing the UAF vulnerability was created and why the pointer was used again after Free is the focus of this article.

2. This vulnerability belongs to the implementation of RDP protocol, and the knowledge of RDP protocol related to this vulnerability will be listed in this paper.

II. Introduction of RDP Protocol 2.1Protocol introduction

Remote Desktop Protocol (RDP, RemoteDesktop Protocol) is a multichannel (multi-channel) protocol.

The RDP protocol is also the TCP S network structure, and the two sides communicate through the TCP connection, which is basically based on the data exchange mode such as request / response. Here is a sequence diagram of the RDP protocol released by Microsoft, which describes in detail the sequence and process of requests and responses in the RDP connection.

The document ([MS-RDPBCGR] .pdf) is located at: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/5073f4ed-1e93-45e1-b039-6e30c385867c.

The details of the communication are not introduced in this article, and interested readers can read the document by themselves.

2.2 static virtual channel (Static Virtual Channels)

Static virtual channels allow RDP Client and RDP Server to communicate over the primary RDP data connection. Virtual channel data is application-specific and opaque to RDP. Up to 31 static virtual channels can be created when connecting. RDP Client requests and confirms the list of required virtual channels in the Basic Settings Exchange phase of the connection sequence, and connects the channels in the ChannelConnection phase.

Each virtual channel acts as a separate data stream. RDP Client and RDP Server examine the data received on each virtual channel and route the data stream to the appropriate processing function for further processing.

III. The cause and debugging process of UAF

It has been confirmed that CVE-2019-0708 is a UAF vulnerability, and it is well known that UAF vulnerabilities are mainly caused by security problems caused by the re-use of object pointers after being released. So in this section, I'll describe when the pointer that caused the UAF vulnerability was created and why it was used again after Free.

3.1 the process of triggering UAF

1) RDP connection is established. By default, RDP Server calls IcaCreateChannel () to create a MS_T120 static virtual channel and bind it to the 0x1F channel number. This is the first time that the channel has been bound.

2) during the Channel Connecttion phase of communication, RDP Client tells RDPServer to bind the channel named "MS_T120" to the specified channel, then Server uses the IcaFindChannelByName () function to search the default created MS_T120 channel and binds the channel object to the channel number specified by the user. This is the second time that the MS_T120 channel is bound.

3) so far, the MS_T120 channel has been bound twice. RDP Client then tells RDP Server to disconnect the channel for the second binding, which causes RDP Server to call IcaFreeChannel () to release the channel and the space occupied by the object.

4) RDP Client then tells RDP Server to close the RDP connection, which causes Server to call the SingalBrokenConnection () function to release the MS_T120 channel object of channel number 0x1F. Since the object space has been freed, the IcaFreeChannel () function is called again to perform the cleanup operation, where ExDeleteResourceLite () references the object's member data and triggers the UAF vulnerability.

3.2 debugging process

The following figure is a comparison before and after the vulnerability patch is fixed:

The key modification is to add a conditional judgment before the call to the _ IcaBindChannel () function, which is the return value of stricmp (), that is, whether the string is equal.

To interpret icaFindChannelByName () literally is to find the channel by name. The following figure shows the implementation of this function. By traversing the list, you can determine that the location of the offset 0x94 in the channel object is the channel name.

Looking back at the code of the vulnerability patch, in fact, after the patch, the channel name is also determined before calling the icaBindChannel () function. When the channel name is "MS_T120", the third parameter of the subsequent call icaBindChannel () is forced to change to 0x1F.

Here, let's take a look at the implementation of the icaBindChannel () function. The key lies in line 12, where the channel pointer passed in to parameter 1 of the function is written to a memory address. It is obvious that the place of writing is calculated by parameters 2 and 3.

In fact, this function is the key to the vulnerability, as to why it is critical, we will talk about it later. Let's first introduce when the object pointer that caused the UAF was created.

As mentioned earlier, the RDP protocol defines static virtual channels, and the channel named MS_T120 is one of them. At the beginning of the establishment of the RDP protocol, MS_T120 will be actively created by the RDP server. This vulnerability causes the object pointer of UAF to be the MS_T120 channel. The termddconstrucicaCreateChannel () function is used to create a channel, set a breakpoint in this function, connect using the Microsoft remote Desktop connection tool, and observe the channel establishment process.

Through the analysis of the function code, we can see that the position of parameter 2 offset 0xC is the channel name. To establish a RDP connection, WinDbg stops at IcaCreateChannel (), and the name in its parameters is MS_T120

Follow the function further and enter the key function _ IcaAllocateChannel (), as shown in the following figure, which first calls ExAllocatePoolWithTag () to apply for space, followed by object member initialization.

It is worth noting that after initializing some member variables, icaBindChannel () is called to trace the call in real time in windbg:

You can see that parameter 3 is 0x1F at this time, and call icaBindChannel () to place the newly created MS_T120 channel in the location of the array subscript 0x1F.

That is, the MS_T120 channel object pointer is established when the RDP connection is created and is immediately bound to the 0x1F channel number. This is where the pointer was created, where the channel is also bound to the 0x1F channel number.

Looking back at what the Microsoft patch fixed, before it was fixed, the program code called icaFindChannelByName () and then called icaBindChannel () to bind the channel to the specified channel number.

After repair, it is determined whether the channel is MS_T120, and if so, the bound channel number is redirected to 0x1F instead of the user-specified channel number. In fact, this is the key to the UAF vulnerability. We know that the MS_T120 channel has been bound to 0x1F at the beginning of the connection establishment. If you bind MS_T120 to another channel number again, there will be two pointer values in the critical array, that is, bound twice.

Currently, there is a POC on Github (https://github.com/n1xbyte/CVE-2019-0708/) that can cause a blue screen by UAF, which can be traced and verified below.

The POC is written in Python, and the POC can be run by installing the python environment on ubuntu

The POC triggers the code that causes the UAF vulnerability in icaBindVirtualChannel () in the RDP server by sending a MCS Connect Initial request.

Continue to step by step to observe the channel number when calling _ IcaBindChannel (). The following figure shows that the channel number is 3. The MS_T120 channel is bound to the channel number 3 specified in the POC.

The POC then sends a packet informing the RDP server to disconnect channel 3, which causes the server to call icaFreeChannel (), which calls ExFreePoolWithTag () to free up space.

POC then tells RDP Sever to close the RDP connection, and when the connection is closed, the default channel release operation located in the subscript 0x1F will be triggered, as shown in the following figure (the image is intercepted by multiple debugging, and different key pointer values do not cause confusion):

If you continue walking here, you can find that a kernel exception has been triggered.

F5 continues to run the system, causing blue. Display as follows

After intelligent analysis, the core reason is that the code at 0x83e9b362 writes the memory address saved by ecx. What you can see is that the ecx at that time is 0. According to the exception type, the current IRQL cannot read or write the address 0.

If you take a closer look at the two figures, you can see that ecx comes from edi, and edi is the input parameter to icaFreeChannel (), that is, the channel object pointer to be released. The released pointer is referenced again, resulting in a vulnerability.

The source of the reference here is ExDeleteResouceLite () called in icaFreeChannel (), which uses some data from the channel object before releasing it.

IV. Conclusion

From the above analysis, we can see that the MS_T120 channel is bound twice (once created and bound by RDPserver, and the second time we send packet binding). Since the channel is bound under two different ID, we get two separate references.

When one of the references is used to close the channel, the reference is deleted and the channel object is released. However, another reference still exists. If we can obtain the ability to fill custom data in the channel object through kernel POOL injection after the first release of the channel object space, when we call IcaFreeChannel () for space release the second time, because the function will refer to the controlled kernel object, there is a chance to read and write any kernel address to achieve the purpose of arbitrary code execution.

The above is how to analyze the high-risk UAF vulnerabilities of Microsoft RDP service. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.