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

In this issue, the editor will bring you about how to analyze BlueKeep vulnerabilities. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Creation, connection and release of 0x00 Channel

The packet for the channel is defined in MCS Connect Inittial PDU with GCC Conference Create Request, and the rdp connection process is shown in the following figure:

The format of the channel creation packet is as follows:

It belongs to the Client Network Data data segment in MCS Connect Inittial. At the beginning of the connection, MS_T120 will create a virtual channel through the function termddpassIcaRegisterVcBin. Id is a structure with the size of 0x1f 0x18. After that, it will be bound to the virtual channel id by calling termddroomIcaCreateChannel. After that, it will be bound to the virtual channel VcBin, that is, this structure will be used by us.

The definition field of channel is mainly name plus configuration, and configuration mainly includes priority and so on.

For the MCS Connect Inittial response packet in server, the id value of the corresponding virtual channel will be given in turn:

The values registered in the rdp kernel in turn should be 0, 1, 2, 3. The MS_T120 channel will be bound again with the user virtual id value of 3 sent by us. First, the virtual channel id that just started registration is found through termddregistration IcaFindVcBind, as shown below:

However, when termddflooding IcaBindChannel is used, our custom id value of 3 is once again bound to the channel structure, which is MS_T120.

At the same time, our own user id overwrites the internally bound 0x1f.

We send data to the channel MS_T120 to actively release the assigned structure, and the ID value of the virtual channel is 3. Look up and return the corresponding channel structure in the channeltable through the function termddmatch IcaFindChannel:

The following figure shows the returned MS_T120 channel structure, where 0xf77b4300 can call an array of function pointers for this channel:

There are three main functions stored in this function pointer array, which correspond to termddcards IcaCloseChannel, termddcards IcaReadChannel, termddlists IcaWriteChannel

The data passed in and released from the MS_T120 channel is as follows. The byte size is 0x12, and the main data corresponds to 0x02.

After that, you will enter nt! The IofCompleteRequest function, when injected through apc, will pass through nt! IopCompleteRequest and ntasking IopAbortRequest respond to the data request, and finally complete our request to send data in termddnobody IcaDispatch. _ BYTE v2 is the data we send, so the data we send 0x02 will eventually call the IcaClose function to enter the IcaCloseChannel function, and finally actively release the MS_T120 channel structure.

0x01 occupies data space through RDPDR channel

Let's first take a look at the rdpdr channel. First, the rdpdr channel is a file system virtual channel extension that runs on a static virtual channel called rdpdr. The purpose is to redirect access from the server to the client file system, whose data header will be mainly composed of two kinds of identity and PacketId fields:

Here we happen to use the data of the name response of the rdpde client to occupy the pool memory.

After the connection is fully established, the structure of the rdpdr channel will be created

In window7, after receiving the rdpdr request of server after the establishment is completed, the termdd will be called by sending the client name response data. The ExAllocatePoolWithTag in IcaChannelInputInternal allocates non-paging pool memory, and its length can be controlled, which basically meets the needs of UAF utilization:

However, in windowsxp, sending client name request directly will cause memory allocation failure, and it is also mentioned in the article Tao Yan and Jin Chen [1] that sending client name request will bypass termddpaged IcaCopyDataToUserBuffer to allocate the non-paged memory we want after triggering certain conditions, and the breaking conditions are as follows:

Let's first look at the creation of the initial channel structure. We can find that when the channel structure is created, two flags will appear, and these two flags are arranged in address order. In the above conditions that need to be broken, as long as the address of channelstruct + 0x108 stores the same address, the loop will be break.

We send a normal rdpdr name request packet with the header identifiers 0x7244 and 0x4e43

After termddmatching IcaCopyDataToUserBuffer, you will enter ntasking IofCompleteRequest, and after responding to the request, you will enter rdpdrillDrSessionPlus ReadCompletion. The processing logic of this function is as follows. It will traverse a linked list and retrieve the corresponding array of vftable functions from the linked list.

Take out the first function array for the first time

After passing in the data we sent, call rdpdressionDrSessionVOGnizePacket through the function array to read it.

Determine whether the header flag is (RDPDR_CTYP_CORE) 0x7244

Then the second address of the function vftable will be read and forwarded.

You can see the packet processing logic of rdpdr in the following figure

After a series of packet processing, rdpdr finally enters our concern, and channelstruct will be passed to handle the flag bits by calling termdd! _ IcaQueueReadChannelRequest

The initial channelstruct flag for rdpdr is as follows

After the processing of this flag by the function termddspray _ IcaQueueReadChannelRequest, it becomes as follows, so the next data will still enter the termddflooding IcaCopyDataToUserBuffer, resulting in the failure of pool injection.

Going back to the rdpdr header processing function rdpdrillDrSessionvirtual RecognizePacket, we found that it will jump after a failed traversal of the linked list, and finally it will enter the read failure handler function rdpdrilled DrSessionVOF ChannelIoFailed, and then return directly

We construct a packet with a header exception, and the header flag we construct is 0x7240, which will cause the failure of the rdpdrilled DrSessionVOR RecognizePacket judgment. After that, we will continue to traverse the linked list and retrieve two function arrays in turn.

The last two function arrays call rdpdrillDrExchangeManagerVise RecognizePacket and rdpdrillDrDeviceManagerveRecognizePacket in turn, both of which will judge the wrong header flag 0x7240, resulting in an error jump after traversing the linked list, directly bypassing the modification of flag bits by termdd! _ IcaQueueReadChannelRequest, which will break the cycle.

Finally, after constructing multiple error packets in succession, we will enter the ExAllocatePoolWithTag and allocate the non-paged memory we need!

Brief Analysis of 0x02 win7 EXP Pool injection

The size of the MS_T120 pool that is first released includes 0x170, and the pool's flag is TSic

By analyzing the Win7 exp, we can know that the rdpsnd channel is used for data occupation. The author does not use the rdpdr channel, which should also be related to the stability of the injection. Rdpsnd injection starts after the rdpdr initialization is established. Before free drops the MS_T120 structure, 1044 packets are sent to apply for 0x170-sized pool memory. This should be done to prevent the memory lost by free from being occupied by other programs. Increase the chance of memory being occupied by us after free

The actual data size of the occupied free is 0x128, and the transit address used is 0xfffffa80ec000948.

After that, start the pool injection, and spray the payload to the place where you can call [rax] = = 0xfffffa80ec000948. The payload size of the injection is basically 0x400, and the total data size of the injection 200mb. Let's first take a look at the pool memory size occupied by the TSic with the mark before injection is about 58kib.

After injection, the memory size of the pool with the TSic flag is about 201mb, and the pool memory injection is basically successful. My win7 is sp1, and the total memory size is 1GB. There is no other interference in the injection process, so the injection is smooth.

In the figure, you can find that the pool jet payload of basically stable 0x400 size, the higher the address, the more stable the memory of 0x400 size.

Finally, when the connection was disconnected, the memory of the free was already occupied by the 0x128 size data that we jetted.

After executing the call instruction, it jumps steadily to our payload, which is executed successfully!

The above is the analysis of how to exploit BlueKeep vulnerabilities shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to 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.