远程桌面漏洞poc_CVE20190708 bluekeep 漏洞研究分析详细完整版

本文为看雪论坛精华文章

看雪论坛作者ID：MSA_Li

一、概括   这个漏洞是微软在2019年被披露的漏洞中安全威胁最高的一个，在写本文之前，网上已经存在可以直接使用的poc，但质量参差不齐，而微软也及时修补了该漏洞。 这个漏洞主要涉及微软win7(x64/x86/server)和winXP(x64/x86)的远程桌面服务，漏洞分类为UAF。 远程桌面连接过程中包含几个协议，RDP，T.124，T.125，COTP，TPKT。 这些协议运行在TCP协议上，所用端口为3389。

二、环境配置   测试环境为三台虚拟机，一台系统为win7(x64)作为远程服务的服务端，一台系统为win7(x86)作为客户端，一台kali linux(x64)作为辅助分析系统，两个win7虚拟机均未打补丁，所以都存在所述漏洞。 三、开始实验   实验的思路是从逆推法开始，即观察微软推送补丁所修改了哪些二进制文件，继而从中找出漏洞存在的相关逻辑和具体位置。

>>>>

对比二进制补丁

使用BinDiff软件观察修补前后的区别发现只有一个内核模块有改动，名为TermDD.sys。 在进一步筛选发现除了_IcaBindVirtualChannels函数和_IcaRebindVirtualChannels函数以外，其他的改动都无关痛痒。 根据这两个函数名字来看，我决定首先分析IcaBindVirtualChannels函数，我认为程序一般是先绑定然后再重新绑定(bind绑定)。 此函数关键改动部分如下图(图1为补丁后，图2为补丁前) 图1： 图2： 看到其中更改了调用_IcaBindChannel的方式，如果比较的字符串等于“MS_T120” 则此调用的第三个参数设置为31。 由于只有v18为false时才会执行补丁后的逻辑，所以我认为要触发该漏洞，则v17+268应该为“MS_T120”字符串，于是向前查找v17+268的线索，在返回v16的IcaFindChannelByName函数内部找到了答案。 图3： 可以看到参数a3应为要寻找通道的名称字符串，在循环中遍历对比v9+268，而返回值v9可以认为是目标通道的结构，而v9偏移268是通道结构中的通道名称。 上图中判断如果v9+268等于v3则返回v9。 通过以上分析，得出结论“MS_T120”是通道的名称，下一步就要找到如何调用这个函数，和参数的名称如何设置为“MS_T120”。 之后我在调用IcaFindChannelByName函数的地方下了一个断点，然后用正常的RDP客户端进行连接，当每次触发断点的时候检查下调用堆栈和通道的名称。 图4： 图5： 图5是第一次命中断点时，通道名称参数为“MS_T120”。 后续的通道名称为CTXTW，rdpdr，rdpsnd，drdynvc，cliprdr。 然而根据图1的逻辑可知，仅当FindChannelByName函数调用成功，即通道已存在的情况下才会命中存在漏洞的代码段，命中后会创建“MS_T120“通道，所以要触发此漏洞，需要使用“MS_T120“作为通道名称再次调用IcaBindVirtualChannels。 回顾图4的调用堆栈可知最上层的调用是类似AcceptConnection的函数，根据名称猜测应该是在接受连接的时候创建通道，所以现在的目标就是寻找一个方法在连接后打开“MS_T120“通道。 下一步准备用wireshark抓取RDP连接包进行分析，看看能不能找到一些线索。

>>>>

RDP抓包分析

win7系统默认远程桌面连接是用tls协议加密的，所以有以下两种方法解决，经过测试皆可达到目的： 1. (麻烦)直接抓取加密后的报文，再解密 ，方法如下 整体思路是客户端运行wireshark抓取加密的报文，再用名为mimikatz的开源工具导出RDP服务端的RSA私钥.pxf文件，再用openssl转成wireshark可识别的.pem文件格式。 但由于windowsXP及以上的系统内tls协议默认为双方协商加密算法和密钥交换算法，默认的加密算法是RSA-AES，没有问题，但默认的密钥交换算法是ECDHE椭圆曲线。