CVE-2019-0803

背景

日前对某APT组织的C2测试下，成功拿下shell

在提权过程中发现，该服务器系统为windos 2012 R2 x64

在Github找exp时发现，win7 和 2008的居多，针对2012的漏洞除了一些com组件产生的逻辑漏洞之外，内核相关的提权漏洞源码比较少

本着积累武器库的原则，选用了CVE-2019-0803漏洞进行分析，目标移植到windows 2012 R2

漏洞原理及利用方式

该漏洞属于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中找到泄露内核地址,具体计算公式为

注意：AcceleratorTabl句柄为CreateAcceleratorTableW的返回值，而非传入的参数

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

返回的句柄为0xd00d5

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

BitMap大小验证

实验中用到的poc地址

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

[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。