Login
CVE-2019-0708 漏洞在 Windows Server 2008 R2 上的利用分析
分析背景
cve-2019-0708是2019年一个rdp协议漏洞，虽然此漏洞只存在于较低版本的windows系统上，但仍有一部分用户使用较早版本的系统部署服务器（如Win Server 2008等），该漏洞仍有较大隐患。在此漏洞发布补丁之后不久，msf上即出现公开的可利用代码；但msf的利用代码似乎只针对win7，如果想要在Win Server 2008 R2上利用成功的话，则需要事先在目标机上手动设置注册表项。
在我们实际的渗透测试过程中，发现有部分Win Server 2008服务器只更新了永恒之蓝补丁，而没有修复cve-2019-0708。因此，我们尝试是否可以在修补过永恒之蓝的Win Server 2008 R2上实现一个更具有可行性的cve-2019-0708 EXP。
由于该漏洞已有大量的详细分析和利用代码，因此本文对漏洞原理和公开利用不做赘述。
分析过程
我们分析了msf的exp代码，发现公开的exp主要是利用大量Client Name内核对象布局内核池。这主要有两个目的，一是覆盖漏洞触发导致MS_T120Channel对象释放后的内存，构造伪造的Channel对象；二是直接将最终的的shellcode布局到内核池。然后通过触发IcaChannelInputInternal中Channel对象在其0x100偏移处的虚函数指针引用来达到代码执行的目的。如图1：
而这种利用方式并不适用于server2008r2。我们分析了server2008r2的崩溃情况，发现引起崩溃的原因是第一步，即无法使用Client Name对象伪造channel对象，从而布局失败。这是因为在默认设置下，server 2008 r2的
RDPSND/MS_T120 channel对象不能接收客户端Client Name对象的分片数据。根据MSF的说明（见图2），只有发送至RDPSND/MS_T120的分片信息才会被正确处理；win7以上的系统不支持MS_T120，而RDPSND在server 2008 r2上并不是默认开启的。因此，我们需要寻找其他可以伪造channel对象的方式。
在此期间，我们阅读了几篇详细分析cve-2019-0708的文章（见参考链接），结合之前的调试分析经历，我们发现的确可以利用RDPDR 的channelID（去掉MSF中对rdp_on_core_client_id_confirm函数的target_channel_id加一的操作即可）使Client Name成功填充MS_T120 channel对象，但使用RDPDR 有一个缺陷：RDPDR Client Name对象只能申请有限的次数，基本上只能完成MS_T120对象的伪造占用并触发虚函数任意指针执行，无法完成后续的任意地址shellcode布局。
我们再次研究了Unit 42发布的报告，他们利用之前发布的文章中提到的Refresh Rect PDU对象来完成内核池的大范围布局（如图，注：需要在RDP Connection Sequence之后才能发送这个结构）。虽然这种内存布局方式每次只能控制8个字节，但作者利用了一个十分巧妙的方式，最终在32位系统上完成漏洞利用。
在解释这种巧妙利用之前，我们需要补充此漏洞目前的利用思路：得到一个任意指针执行的机会后，跳转到该指针指向的地址中，之后开始执行代码。但在内核中，我们能够控制的可预测地址只有这8个字节。虽然此时其中一个寄存器的固定偏移上保存有一个可以控制的伪造对象地址，但至少需要一条语句跳转过去。
而文章作者就是利用了在32位系统上地址长度只有4字节的特性，以及一条极短的汇编语句add bl,al; jmp ebx，这两个功能的代码合起来刚好在8字节的代码中完成。之后通过伪造channel对象里面的第二阶段跳转代码再次跳转到最后的shellcode上。（具体参考Unite 42的报告）
我们尝试在64位系统上复现这种方法。通过阅读微软对Refresh Rect PDU描述的官方文档以及msf的rdp.rb文件中对rdp协议的详细注释，我们了解到，申请Refresh Rect PDU对象的次数很多，能够满足内核池布局大小的需求，但在之后多次调试分析后发现，这种方法在64位系统上的实现有一些问题：在64位系统上，仅地址长度就达到了8字节。我们曾经考虑了一种更极端的方式，将内核地址低位上的可变的几位复用为跳转语句的一部分，但由于内核池地址本身的大小范围，这里最多控制低位上的7位，即：
0xfffffa801“8c08000“ 7位可控
另外，RDPDR Client Name对象的布局的可控数据位置本身也是固定的（即其中最低的两位也是固定的），这样我们就只有更少的5位来实现第二阶段的shellcode跳转，即：
“8c080”0xfffffa801“8c080”00 5位可控,
由于伪造的channel对象中真正可用于跳转的地址和寄存器之间仍有计算关系，所以这种方法不可行，需要考虑其他的思路。
把利用的条件和思路设置得更宽泛一些，我们想到，如果目前rdp协议暂时不能找到这样合适的内核池布局方式，那其他比较容易获取的也比较通用的协议呢？结合以前分析过的协议类的多种代码执行漏洞，smb中有一个用得比较多的内核池布局方式srvnet对象。
无论是永恒之蓝还是之后的SMBGhost都使用到srvnet对象进行内存布局。最容易的方法可以借助于msf中ms17-010的代码，通过修改代码中对make_smb2_payload_headers_packet和make_smb2_payload_body_packet 大小和数据的控制，能够比较容易地获取一种稳定的内核池布局方式（相关代码参考图5）。
由于单个Client Name Request所申请的大小不足以存放一个完整的shellcode，并且如上面提到的，也不能申请到足够多的RDPDR Client Name来布局内核池空间，所以我们选择将最终的shellcode直接布局到srvnet申请的内核池结构中，而不是将其当作一个跳板，这样也简化了整个漏洞的利用过程。
最后需要说明一下shellcode的调试。ms17-010中的shellcode以及0708中的shellcode都有一部分是根据实际需求定制的，不能直接使用。0708中的shellcode受限于RDPDR Client Name大小的限制，需要把shellcode的内核模块和用户层模块分为两个部分，每部分shellcode头部还带有自动搜索另一部分shellcode的代码。为了方便起见，我们直接使用ms17-010中的shellcode，其中只需要修改一处用来保存进程信息对象结构的固定偏移地址。之后，我们仍需要在shellcode中添加文章中安全跳过IcaChannelInputInternal函数剩余部分可能崩溃的代码（参考Patch Kernel to Avoid Crash 章节），即可使整个利用正常工作。64位中添加的修补代码如下：
mov qword ptr[rbx+108h],0
mov rax,qword ptr[rsp]
add rax,440h
mov qword ptr[rsp],rax
mov r11,qword ptr gs:[188h]
add word ptr [r11+1C4h],1总结
本篇文章主要是分享我们在分析CVE-2019-0708漏洞利用的过程中整合现有的一些方法和技术去解决具体实际问题的思路。但这种方法也会有一些限制，例如既然使用了smb协议中的一些内核对布局方式，则前提是需要目标开启了smb端口。另外，不同虚拟化平台下的目标内核基址需要预测来达到使exp通用的问题仍没有解决，但由于这个漏洞是2019年的，从到目前为止众多已经修补过的rdp信息泄露漏洞中泄露一个任意内核对象地址，应该不会是太难的一件事。
综上，我们建议用户尽量使用最新的操作系统来保证系统安全性，如果的确出于某些原因要考虑较早版本且不受微软安全更新保护的系统，也尽量将补丁打全，至少可以降低攻击者攻击成功的方法和机会。
