微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

0x00 概述

20190514,微软发布补丁,修复了一个严重的RDP远程代码执行漏洞。该漏洞无需身份认证和用户交互,可能形成蠕虫爆发,影响堪比wannycry。

0x01影响范围

Windows 7

Windows Server 2008 R2

Windows Server 2008

Windows Server 2003

Windows XP

0x02 漏洞重现

poc已出,重现几个网上主流的poc:

1)360的0708detector.exe(无损扫描工具)

//感觉不是很稳定,对同个ip有时成功有时不成功……

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

一些根据此工具写的批量

https://github.com/biggerwing/CVE-2019-0708-poc

https://github.com/autoing/CVE-2019-0708-POC

2)https://github.com/zerosum0x0/CVE-2019-0708

包含了msf的rb

git clone https://github.com/zerosum0x0/CVE-2019-0708.gitcd CVE-2019-0708/rdesktop-fork-bd6aa6acddf0ba640a49834807872f4cc0d0a773/./bootstrap./configure –disable-credssp –disable-smartcardmake./rdesktop 192.168.1.7:3389

可能要apt-get install libssl1.0.0 libssl-dev

用scan_with_docker.py可以批量

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

//较稳定

3)https://github.com/Ekultek/BlueKeep.git

可以批量

先安装impacket

https://github.com/SecureAuthCorp/impacket

pip install -r requestments.txtpip install .vim bluekeep_poc.py

删除重复的一个impacket

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

4)https://github.com/robertdavidgraham/rdpscan

可批量

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

//较不稳定

5)https://github.com/Leoid/CVE-2019-0708

pip3 install impacket

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

6)https://github.com/n1xbyte/CVE-2019-0708

//20190531新增蓝屏poc,用03standx86测试出现

OpenSSL.SSL.SysCallError: (104, ‘ECONNRESET’)

应该是这个03系统问题

直接找几个僵尸主机测一测

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

//效果不错!

7)https://github.com/closethe/CVE-2019-0708-POC

试了几个都是timed out,可能是poc未完善……

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

其他一些poc(未测试):

https://github.com/skyshell20082008/CVE-2019-0708-PoC-Hitting-Path

https://github.com/blacksunwen/CVE-2019-0708(和5基本一样)

https://github.com/Jaky5155/cve-2019-0708-exp

https://github.com/fourtwizzy/CVE-2019-0708-Check-Device-Patch-Status

https://github.com/trickster0/CVE-2019-0708

https://github.com/algo7/bluekeep_CVE-2019-0708_poc_to_exploit(powershell)

截至发文(20190605),尚未发现公开可用exp,拭目以待!

360的某大神已搞出exp,能在win7 x64弹框了,未公开。

20190606,发现msf可获取meterpreter的exp,未公开。

https://twitter.com/zerosum0x0/status/1135866953996820480

还有一堆假exp,利用ms12-020、os.system()、alert、假GUI、骗star等等。

www.cve-2019-0708.com(20190529无法访问了)据说是假的!

0x03 漏洞分析

rdp基础

RDP 协议基于 T.128(T.120 协议族)提供多通道通信,并进行了拓展。

远程桌面协议(RDP)支持客户端建立点到点的连接,并定义了通信双方在虚拟通道间的数据通信方式,。这种虚拟通道为双向数据通道,可以扩展RDP的功能。Windows Server 2000在RDP v5.1中定义了32种静态虚拟通道(SVC),但是因为将来要定义的动态虚拟通道数量的限制,因此专用的通道svc数量受到一定限制。SVC是在会话开始时创建的,并在会话终止前保持不变,但DVC不同,因为它是根据用户需求来创建和删除的。

服务端在初始化阶段,会创建MS_T120, Index 为 31 的通道。在收到MCS Connect Initial数据封包后进行通道创建和绑定操作。

在IcaBindVirtualChannels函数中进行绑定时,IcaFindChannelByName函数只根据通道名进行通道查找。当通道名为MS_T120(不区分大小写)时,会找到系统内部通道 MS_T120的通道并与之绑定,绑定后,通道索引会即被更改为新的通道索引。

参考mcafee,seebug

本人用win7sp1 x64进行测试

查看termdd.sys,有修改

对比补丁前后

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

13628这个子模块变化比较大,先看看

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

发现加了stricmp比较,和ms_t120这个通道比较,为0就用写死的v19即31(rdp通道编号)作为第三个参数传入13ec8这个子模块,所以这里可以看出漏洞点应该是ms_t120这个通道,是就触发漏洞。

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

//bindiff没解析出_IcaBindChannel和_IcaBindVirtualChannels。

在安全机制启用前,系统初始化了RDP连接序列,并完成通道的建立,这导致了该漏洞可形成蠕虫。

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

在rdp的gcc协商初始化序列中,ms_t120这个svc会被绑定作为引用通道31。

这个通道编号31在microsoft内部使用,在客户端请求连接中不会出现ms_t120这个svc。

但是在GCC协商初始化的过程中,客户端提供的通道名称并不在服务器端的白名单中,这意味着攻击者将能够设置另一个名为“MS_T120”的不在编号31的SVC通道,这导致目标系统发生堆内存崩溃并实现远程代码执行。

MS_T120引用通道会在rdpwsx.dll中创建,堆内存也会在rdpwp.sys中分配内存池。当MS_T120引用通道在通道编号非31的场景下建立时,便会发生堆内存崩溃。

微软在termdd.sys的_IcaBindVirtualChannels和_IcaRebindVirtualChannels两个函数中为客户端的连接请求部分添加了针对通道名称“MS_T120”的检查代码,来保证ms_t120是和通道31进行绑定。

利用wireshark获取rdp数据包(winn2003stand without 0708 patch)

正常rdp连接:

tcp三次握手后发送rdp数据,利用decode as tpkt解出rdp数据包

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

//第二遍tcp握手后(neg req=fff)才开始发clientdata

没有ms_t120通道信息

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

利用360无损检查工具发送的数据包(neg req=fff)

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

此处本人推测ms_t120通道编号是1,channelCount就是channelDefArray元素数,验证漏洞存在!

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

利用./rdesktop(第二个poc)对某僵尸主机发送的数据包:

此时推测ms_t120通道编号为2,验证漏洞存在!

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

利用蓝屏crashpoc.py对某僵尸主机发送的数据包:

微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的

本人才疏学浅,对rdp不甚了解,只能从浅层大概分析,高手可参考相关分析资料。

相关分析资料:

英文:

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/(推荐)    
https://medium.com/@straightblast426/a-debugging-primer-with-cve-2019-0708-ccfa266682f6

https://wazehell.io/2019/05/22/cve-2019-0708-technical-analysis-rdp-rce/

https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html

https://medium.com/@ab_65156/proactive-detection-content-cve-2019-0708-vs-mitre-att-ck-sigma-elastic-and-arcsight-22f9ebae7d82

https://zerosum0x0.blogspot.com/2019/05/avoiding-dos-how-bluekeep-scanners-work.html

https://www.zerodayinitiative.com/blog/2019/5/27/cve-2019-0708-a-comprehensive-analysis-of-a-remote-desktop-services-vulnerability

中文:

https://xz.aliyun.com/t/5295(翻译zerodayinitiative)

https://www.anquanke.com/post/id/178964(翻译mcafee)

https://www.anquanke.com/post/id/178966

https://www.giantbranch.cn/2019/05/14/CVE-2019-0708%20%E5%BE%AE%E8%BD%AF%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2%E6%9C%8D%E5%8A%A1%E8%BF%9C%E7%A8%8B%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%E4%B9%8B%E8%A1%A5%E4%B8%81%E5%88%86%E6%9E%90/

https://paper.seebug.org/937/

https://mp.weixin.qq.com/s/_MaxpGtDj2D8oENCZ68hKA

https://mp.weixin.qq.com/s/OeJ7W3GxsQedpezTsa6z_Q

0x04 修复方案

1.补丁    
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708

2. 开启NLA网络级身份验证减轻危害(利用漏洞就需要身份验证)

0x05 结语

此漏洞危害巨大,一旦exp公开,必会掀起腥风血雨,估计各种勒索挖矿病毒已经蓄势待发,所以大家抓紧打补丁吧!

关于微软RDP远程代码执行漏洞CVE-2019-0708的分析是怎样的问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注亿速云行业资讯频道了解更多相关知识。

原创文章,作者:bd101bd101,如若转载,请注明出处:https://blog.ytso.com/221516.html

(0)
上一篇 2022年1月3日
下一篇 2022年1月3日

相关推荐

发表回复

登录后才能评论