在CVE-2019-0708公布后幾天就已經嘗試過復現該漏洞，但借助當時exp並沒能成功復現反彈shell的過程遂放棄，故借助這次漏洞復現報告再來嘗試復現該漏洞，因為還在大三學習中，有很多知識還沒有掌握，出現的錯誤希望得到指正，也想借此給19年的學習畫上句號，希望這次可以成功吧。
漏洞背景
CVE-2019-0708 | 遠程桌面服務遠程執行代碼漏洞
安全漏洞發布時間: 2019-05-14
當未經身份驗證的攻擊者使用 RDP 連接到目標系統並發送經特殊設計的請求時，遠程桌面服務（以前稱為“終端服務”）中存在遠程執行代碼漏洞。此漏洞是預身份驗證，無需用戶交互。成功利用此漏洞的攻擊者可以在目標系統上執行任意代碼。攻擊者可隨后安裝程序；查看、更改或刪除數據；或者創建擁有完全用戶權限的新帳戶。
若要利用此漏洞，攻擊者需要通過 RDP 向目標系統遠程桌面服務發送經特殊設計的請求。
可以看到其中利用的RDP即遠程桌面端口3389，RDP協議，所帶來的危害是不可估量的，當達到預想中的任意執行的攻擊效果，后續利用便多種多樣起來了。
准備工作
靶機布置
根據公布的poc詳情中可以得之該漏洞影響范圍如下
影響系統：windows2003、windows2008、windows2008 R2、windows xp 、win7
這里選用win7系統來布置靶機，使用的系統版本為旗艦版sp1
在VMware中常規安裝好win7虛擬機后根據漏洞利用要求開啟3389端口，最終布置結果如下
攻擊機布置
因為這次攻擊使用的是metasploit-framework中提供的cve_2019_0708_bluekeep_rce所以使用已經預裝有msf的Kali Linux-2019.03但其實后續過程中還是遇到了很多預料之外的情況，在后文中會講到。
在Kali中准備好GitHub頁中提供的exp與配套掃描器
最終測試環境
攻擊機：Kali IP：192.168.26.135
靶機：Win7 IP：192.168.26.134（開放3389端口）
工具：MSF框架
漏洞攻擊
以下是在進行漏洞復現過程的整理以及遇到的各種各樣預料之外的問題及我所能找到的並確實解決了我遇到問題的相關解決方案。
框架載入模塊時遇到的問題
模塊加載失敗
按照第一次復現時的思路，就是將exp等文件放入MSF對應目錄中使框架加載，但是這次卻出現了框架無法加載對應模組的問題，
查看framework.log得到如下信息
......
[12/28/2019 02:47:10] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[12/28/2019 02:47:10] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[12/28/2019 02:47:11] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[12/28/2019 02:47:11] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[12/28/2019 02:47:12] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/onprem_enum.go Errno::ENOENT No such file or directory - go /opt/metasploit-framework/embedded/lib/ruby/2.6.0/open3.rb:213:in `spawn'
......尋找解決方案
對於出現該問題的原因還未知，這里我嘗試重新從MSF重新獲取安裝，但問題似乎仍未解決，仍然會出現0708的對應模組未能成功加載的問題，在百度無果之后，終於在某404搜索引擎幫助下得到了線索，在參考了以下文章及issue后
Playing with the BlueKeep MetaSploit module
Can not load another module #12321
決定嘗試使用git-bundle的方式來重新安裝我的MSF框架，這樣子的好處就是可以直接獲取Github上已經含有cve-2019-0708的框架版本，而不用手動下載添加，避免了未知的干擾因素
嘗試新安裝方式
新的安裝方式首先要將項目git-clone至本地，布置過程如下
root@kali:~/Desktop# git clone --single-branch --branch bluekeep https://github.com/busterb/metasploit-framework
Cloning into 'metasploit-framework'因為克隆過程極為緩慢，即使設置代理之后也提不上速度，所以消耗了不少的時間，當克隆完成后進入該目錄，用對應命令進行安裝
root@kali:~/Desktop/metasploit-framework# bundle install但是…接下來的一連串情況是萬萬沒想到
安裝過程中又遇到的問題
因為通過bundle安裝中，需要安裝許多的對應組件，而我是第一次嘗試這樣的安裝，所以很多相關依賴沒有安裝，
其中就包括zlib、zliblg-dev、libpq-dev、libpcap-dev，通過以下命令安裝后重新執行安裝命令
sudo apt-get install zlib1g
sudo apt-get install zlib1g.dev
sudo apt-get install libpq-dev
sudo apt-get install libpcap0.8-dev最終出現該樣式便是安裝成功
如果出現的是其他的綠色字體似乎也是安裝成功的標志，只要不是鮮紅色的報錯
攻擊過程
重新安裝好框架后啟動程序
這里有一個要注意的點，因為重新用git-bundle安裝了框架，所以啟動的時候要對應的使用./msfconsole而不是平時一樣使用msfconsole，這樣進入的才是重新安裝的MSF框架，進入后用search命令搜索，可以看到已經有cve-2019-0708的exp，用對應命令使用該exp
use exploit/windows/rdp/cve_2019_0708_bluekeep_rce
利用分析
終於順利的來到了漏洞利用的第一步了，首先來看看該exp需要的參數
可以看到主要設置的參數有RHOSTS / RPORT / target
RHOSTS 靶機IP
RPORT RDP端口
target ID（可選0~7）設置靶機機器架構
從這里可以看到MSF框架更新了target列表的信息，對比舊版的靶機架構列表
明顯看出對於靶機的架構相對於exp公布初期，進行了更詳細的划分，通過相關分析可推測該漏洞利用點就是系統因二次釋放造成堆內存被破壞，exp則利用該特點在泄露的內核堆中尋找對應位置劫持控制流，具體可參照52pojie的相關文章-[漏洞分析] CVE-2019-0708 微軟遠程桌面服務遠程代碼執行漏洞之漏洞分析與漏洞利用簡介
所以對於不同架構的機器，很有可能會出現exp所能利用的漏洞點位置不同從而出現我在第一次嘗試復現該漏洞時所出現的攻擊只能造成藍屏而並不能成功反彈shell的結果，所以現在對於細化后的target列表，感覺成功的幾率大了一點，同時也參考相關復現成功的案例，將靶機配置調整為2g內存、2核cpu。
攻擊中所遇問題
首先，按照說明設置對應的參數值
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set rhosts 192.168.26.134
rhosts => 192.168.26.134
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set target 4
target => 4
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
這里設置了靶機IP，對應的target架構，然后執行exp，
雖然顯示目標存在可利用點，且攻擊也已經完成，但是最終並沒有按照預定計划創建會話返回shell，這樣的攻擊仍然是將靶機打藍屏，並沒有成功實現getshell執行任意代碼的目的，與第一次復現的結果相同，但因為距離初次披露poc與exp已經有了一段時間，就嘗試尋找是否有新的文章提出了對應的解決方法。
嘗試解決藍屏
尋找了很多文章並進行一一的嘗試之后，總結了以下不同問題的對應解決方法：
對於我這種攻擊成功但仍然出現藍屏的情況，在我反復測試攻擊過程后發現，每次的藍屏現象基本都是出現在exp進行至該位置時出現
而我在閱讀文章中發現有一個問題的解決方案是和這個進度極為相似的
於是嘗試將該解決方法應用在我出現的問題中，
終於！成功獲得了靶機的控制權
信息一致，終於成功復現了cve-2019-0708
后續測試
因為基於第一次失敗的復現，所以靶機上沒有開啟任何防御措施，包括系統自帶防火牆，在成功復現漏洞后我想試試這樣子通過內核劫持控制流的攻擊方式，會被哪種程度的防御抵擋。
第一次測試
首先開啟系統自帶防火牆，依舊保持3389端口開啟，再次運行exp。
可以看到在開啟防火牆的狀態下，仍然能夠進行攻擊且執行任意代碼
第二次測試
基於第一次的嘗試，開啟系統防火牆的同時，安裝安全防護軟件，在這里我選擇火絨作為測試對象，再次執行exp
可以通過顯示信息看到，攻擊是已經順利執行了的，並且會話也已經成功建立，但是在惡意進程入駐內核的同時，該會話也被強行終止，退出了控制，這一行為可以在火絨的安全日志中看到
在這里exp的確成功執行並與之前一樣成功的進行了進程的入駐，但這一入駐過程被火絨所攔截了下來，並識別為Backdoor進行及時阻止與防護，由此可見，該exp的攻擊流程是由底層的內核入侵逐步上升至進程與內存管理器，而當攻擊上升到用戶應用程序所能監控到的層面時便會被識別且清除，但這里也存在着疑問，當我在攻擊行為被火絨攔截之后再次運行命令，我設想的結果是會再次成功執行且被火絨查殺，但結果卻是再次將靶機打藍屏
造成這個問題的原因還未找到有相關的解答，只能留意以后的相關文章了
第三次測試
經過上一次的嘗試得知，安全防護軟件的確可以在一定程度上對該攻擊手段進行一定程度的防范，但第二次的嘗試是先開啟了安全防護軟件，再進行exp攻擊，這樣的異常進程入駐的確很容易引起查殺，所以我想嘗試在已經成功入駐了進程后再開啟安全防護，能否通過進程的掃描來發現正在執行代碼的會話進程並對其進行查殺清除。
首先將攻擊開啟，成功執行且getshell。
此時在靶機上並無異常，開啟安全防護軟件，並進行掃描
可以看到在靶機上即便掃描項包含了磁盤與系統進程，但並沒有發現正在連接中的exp會話。
在以上三次實驗中仍然試過相同條件下靶機藍屏的情況，所以有可能測試的結論有失偏頗，還望指正
總結與假設
以上就是此次復現cve-2019-0708的過程整理，而過程中所出現的問題與解決方法並不一定具備普遍性，而后續測試因為在過程中也試過相同條件下仍然會出現藍屏現象，故以上內容僅代表我個人觀點，而且對於計算機及內核相關內容我的了解也並不是非常全面，僅限於在一邊復現一邊學習的過程中所學習與理解的內容，帶有一定的個人推理，所以可能存在諸多理論上的漏洞或是本質上的錯誤，故本篇主要用作個人歸檔與總結報告用途，如果遇到相關問題善用搜索引擎是最大的幫助。
在本次的復現里總算解決了第一次復現時的失敗，也從中更深入的了解了該漏洞所影響面之廣與帶來危害之深，即便該漏洞有着較為嚴苛的利用條件，但相信在披露的時候仍然會對很多企業與個人帶來威脅，而通過后續的測試也發現了安全防護是能夠在一定程度上對攻擊進行防范的，所以用戶在使用過程中適當的根據自己使用習慣來選擇防護措施防患於未然也是很重要的一點。
但在這里我也有相關的疑惑，因為在了解過程中通過windows的結構框架了解到系統的啟動具有層面上的先后順序，而該漏洞的利用是對於底層內核在釋放內存時Double free的利用，達到欺騙系統修改內存的目的，且該漏洞也具有將靶機打至藍屏的特性，而系統在藍屏后大多數都會釋放內存重新啟動，而系統重啟時，windows自啟服務是在登錄階段進行啟動的，而這一階段是后於內核加載階段，假設此處我對於該漏洞淺顯的理解沒有錯誤，且該漏洞的攻擊也假設可以在啟動系統啟動項前作用於該系統，那是否可以通過漏洞的二次攻擊，先將靶機系統藍屏重啟，在重啟的過程中利用內核加載階段過渡到登錄階段的這一間隙再次運行攻擊程序來完成攻擊。
而對於這一假設目前最明顯的問題就是網絡的連通性，網絡服務也屬於系統的自啟項之一，所以當在未聯網的系統開機過程中如何實施攻擊就是問題，當然這還有很多的問題包含在里面，而這也僅僅是我的一個假設，但能通過這次復現的過程學習到這么多東西也是一次寶貴的過程，也發現了漏洞復現對於學習也有很大的幫助，可以更深入的了解和探知漏洞背后的規律和原理，即便不能完全理解吃透，這也是一次實踐的經歷。