背景

日前对某APT组织的C2测试下，成功拿下shell。 在提权过程中发现，该服务器系统为windows 2012 R2 x64。

在Github找exp时发现，win7 和 2008的居多，针对2012的漏洞除了一些com组件产生的逻辑漏洞之外，内核相关的提权漏洞源码比较少。 本着积累武器库的原则，选用了CVE-2019-0803漏洞进行分析，目标移植到windows 2012 R2。

漏洞原理及利用方式[出自:jiwo.org]

该漏洞属于UAF(Use After Free)类型的漏洞。 漏洞存在于DDE通信中，在DDE通信时，Server返回数据时，会调用应用层的函数clientCopyDDEIn1，该函数会将一些数据填充到tagINTDDEINFO结构，后续会调用内核态hmgSetOwner函数，该函数会将tagINTDDEINFO中的成员hIndirect返还给Client。 因此可以通过对clientCopyDDEIn1函数进行InlineHook，在填充的数据改为gdi对象，这样当Server端退出的时候，gdi对象将会被释放，此时利用堆风水，可以成功占位，从而实现任意地址读写。

UAF整个过程中的堆布局过程

该漏洞对象的大小为0x350，为了避免后续Bitmap和DIB占坑出现问题，先塞满这些间隙：

占坑，构造0x1000-0x350=0xCB0大小的空间，给漏洞对象留下0x350的大小。

此时的堆空间布局如下图：

填充400个：

在NtGdiCreateBitmap中我们可以跟到申请对象的位置，可以清楚的看到其大小为0x350。 (upload/attach/202006/830989_8Z5AGEPN7VYGNG4.png) 通过泄露的gdi对象内核地址，我们可以看到，该漏洞对象刚好和0xCB0大小的AcceleratorTable表填满一页

此时的堆空间布局大至如下：

找到漏洞对象所在的位置（某个AcceleteratorTable下面）：

当DDE_SERVER退出时，我们可以看到，该堆空间已经被标记为FREE状态!

现在用0x350大小的AcceletratorTable去填充：

我们可以看到，加速表成功占用gdi对象的空间：

此时的堆空间布局如下：

该过程对象大小不一样，在2012中占位情况一致。如下： windosw 2012 R2 UAF占位流程Allocated--->Free--->Allocated

占位后即可利用GetDIBColorTable和SetDIBColorTable进行任意读写。 该poc是利用将shellcode写到hal表从而进行代码执行，可以看到成功将shellcode填充到hal表：

该利用方式在2012 R2不可行，win8.1之后开启了SMEP，因此我利用任意读写直接替换token。

成功在2012 R2弹出systme shell，在本程序退出时会蓝屏（可能是还有个有问题的hdc句柄,懒人法让程序不退出）。

除了内核对象以及token等相关结构体大小和偏移不一样之外，还需要对dde函数进行逆向。 下图为win7与2012的dde函数区别（InlieHook的时候要注意）： ![159063

ClientCopyDDEIn1 函数hook验证，红色框如果没有修改成功是利用不了漏洞的。

附录

gSharedInfo泄露内核地址验证

rax为内核地址 fffff900c3185970

找到gSharedInfo结构体

 dq user32!gSharedInfo

 dt win32k!tagSharedInfo

user object可以在user32.dll的导出函数gSharedInfo中找到泄露内核地址,具体计算公式为：

(SHAREDINFO->aheList+sizeOf(HANDLEENTRY)*(AcceleratorTabl句柄&0xffff))

（注意：AcceleratorTabl句柄为CreateAcceleratorTableW的返回值，而非传入的参数。）
返回的句柄为0xd00d5：

dq 0x450000+0x18*(0xd00d5&0xffff)可以看到与内核态对应：

BitMap大小验证

实验中用到的poc地址

https://gitee.com/cbwang505/CVE-2019-0803