BlueKeep 漏洞利用分析

2019-09-20

作者：SungLin@知道创宇404实验室
时间：2019年9月18日

0x00 信道的创建、连接与释放

通道的数据包定义在MCS Connect Inittial PDU with GCC Conference Create Request中，在rdp连接过程如下图所示：

信道创建数据包格式如下：

在MCS Connect Inittial中属于Client Network Data数据段，MS_T120将会在连接一开始的时候通过函数termdd!_IcaRegisterVcBin创建一个虚拟通道id是0x1f大小为0x18的结构体，之后就调用termdd!IcaCreateChannel开始创建大小为0x8c的信道结构体之后将会与虚拟通道id是0x1f绑定，也就是这个结构体将会被我们利用

信道的定义字段主要是名字加上配置，配置主要包括了优先级等

在server对MCS Connect Inittial应答包，将会依次给出对应虚拟通道的id值：

在rdp内核中依次注册的值对应应该是0、1、2、3, MS_T120信道将会通过我们发送的用户虚拟id为3的值再一次绑定，首先通过termdd!_IcaFindVcBind找到了刚开始注册的虚拟通道id是0x1f，如下所示：

但是在termdd!_IcaBindChannel时，却将我们自定义的id值为3与信道结构体再一次绑定在一起了,此信道结构体就是MS_T120

同时我们自己的用户id将内部绑定的0x1f给覆盖了

我们往信道MS_T120发送数据主动释放其分配的结构体，其传入虚拟通道id值为3通过函数termdd!IcaFindChannel在channeltable中查找返回对应的信道结构体：

下图为返回的MS_T120信道结构体，其中0xf77b4300为此信道可调用的函数指针数组：

在这个函数指针数组中主要存放了三个函数，其中对应了termdd!IcaCloseChannel、termdd!IcaReadChannel、termdd!IcaWriteChannel

我们传入释放MS_T120信道的数据如下，字节大小为0x12，主要数据对应了0x02

之后将会进入nt! IofCompleteRequest函数，通过apc注入后，将会通过nt! IopCompleteRequest和nt!IopAbortRequest进行数据请求的响应，最终在termdd!IcaDispatch完成我们发送数据的的请求，_BYTE v2就是我们发送的数据，所以我们发送的数据0x02将会最终调用到IcaClose函数进入IcaCloseChannel函数，最后主动释放掉了MS_T120信道结构体

0x01 通过RDPDR信道进行数据占位

我们先来了解下rdpdr信道，首先rdpdr信道是文件系统虚拟通道扩展，该扩展在名为rdpdr的静态虚拟通道上运行。目的是将访问从服务器重定向到客户端文件系统，其数据头部将会主要是两种标识和PacketId字段组成：

在这里我们刚好利用到了rdpde客户端name响应的数据来进行池内存的占位

在完全建立连接后，将会创建rdpdr信道的结构体

在window7中，在建立完成后接收到server的rdpdr请求后，通过发送客户端name响应数据，将会调用到termdd! IcaChannelInputInternal中的ExAllocatePoolWithTag分配非分页池内存，并且其长度是我们可以控制的，基本满足了UAF利用的需求：

可是在windowsxp中，直接发送client name request将会导致内存分配失败，直接进入termdd! _IcaCopyDataToUserBuffer,并且在Tao Yan and Jin Chen[1]一文中也提到了通过发送client name request在触发一定的条件后将会绕过termdd!_IcaCopyDataToUserBuffer而进入ExAllocatePoolWithTag分配我们想要的非分页内存，而打破条件如下：

我们先来看看最开始信道结构体的创建，我们可以发现从一开始创建信道结构体的时候，将会出现两个标志，而这两个标志是按照地址顺序排列的，而在上面需要打破的条件中，只要channelstruct +0x108的地址存放的是同一个地址，循环就会被break

我们发送一个正常的rdpdr的name request数据包，头部标识是0x7244和0x4e43

经过termdd!_IcaCopyDataToUserBuffer之后，将会进入nt!IofCompleteRequest，在响应请求后进入rdpdr!DrSession::ReadCompletion,此函数处理逻辑如下，其将会遍历一个链表，从链表中取出对应的vftable函数数组

遍历第一次取出第一张函数数组

传入我们发送的数据后，通过函数数组调用rdpdr!DrSession::RecognizePacket进行读取

判断头部标志是否为（RDPDR_CTYP_CORE）0x7244

接着将会读取函数vftable第二个地址，进行转发

如下图可以看到rdpdr的数据包处理逻辑

rdpdr经过一系列数据包处理后最终进入了我们关心的地方，将会传入channelstruct通过调用termdd! _IcaQueueReadChannelRequest进行标志位的处理

最初rdpdr的channelstruct的标志位如下

经过函数termdd! _IcaQueueReadChannelRequest对此标志的处理后变成如下，所以下一个数据依然会进入termdd!_IcaCopyDataToUserBuffer，导致我们进行池喷射的失败

回到rdpdr头部处理函数rdpdr!DrSession::RecognizePacket，我们发现在链表遍历失败后将会进行跳转，最后将会进入读取失败处理函数rdpdr!DrSession::ChannelIoFailed，然后直接return了

我们构造一个头部异常的数据包发送，头部标志我们构造的是0x7240，将会导致rdpdr!DrSession::RecognizePacket判断失败，之后将会继续遍历链表依次再取出两张函数数组

最后两个函数数组依次调用rdpdr!DrExchangeManager::RecognizePacket和rdpdr!DrDeviceManager::RecognizePacket，都会判断错误的头部标志0x7240，最后导致链表遍历完后进行错误跳转，直接绕过了termdd! _IcaQueueReadChannelRequest对标志位的修改，将会打破循环

最后我们连续构造多个错误的数据包后将会进入ExAllocatePoolWithTag，分配到我们需要的非分页内存！

0x02 win7 EXP 池喷射简要分析

首先被释放的MS_T120池大小包括是0x170,池的标志是TSic

分析Win7 exp 可以知道数据占位是用的rdpsnd信道，作者没有采用rdpdr信道，应该也和喷射的稳定性有关，rdpsnd喷射是再建立完了rdpdr初始化后开始的，在free掉MS_T120结构体前，发送了1044个数据包去申请0x170大小的池内存，这样做可以说应该是为了防止之后被free掉的内存被其他程序占用了，提高free后内存被我们占用的生存几率