After CVE-2019-0708 has been announced a few days tried to reproduce the vulnerability, but with no exp was able to successfully reproduce rebound shell process then give up, it means to reproduce the vulnerability report again try to reproduce the vulnerability because the junior is still learning, there are a lot of knowledge has not mastered, want to appear to get errors corrected, would like to take full stop to 19 years of study, I hope this time it may succeed.
Vulnerability background
CVE-2019-0708 | Remote Desktop Services Remote Code Execution Vulnerability
Security vulnerabilities Published: 2019-05-14
When an unauthenticated attacker to use RDP to connect to the target system and sends a request specially designed, Remote Desktop Services (formerly known as "Terminal Services") A remote code execution vulnerability. This vulnerability is a pre-authentication, without user interaction. An attacker who successfully exploited this vulnerability could execute arbitrary code on the target system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
To exploit this vulnerability, an attacker would need to send a special request to the target system design Remote Desktop Services through RDP.
We can see that is where the use of Remote Desktop RDP port 3389, RDP protocol, the harm caused is immeasurable, when the attack carried out to achieve the desired effect in any of the subsequent use of his varied up.
Ready to work
Drone arrangement
poc can get the details published in the scope of the vulnerability according to the following
Affect the system: windows2003, windows2008, windows2008 R2, windows xp, win7
This selection of win7 system arranged drones, used system version Ultimate sp1
In the conventional VMware virtual machine after installing the win7 requires the use of open port 3389 according to vulnerability, the final placement results are as follows
Attack aircraft layout
Since the attack using cve_2019_0708_bluekeep_rce metasploit-framework has been provided so the use of pre-loaded with msf of Kali Linux-2019.03 or later in the process but in fact encountered many unexpected situations, will be mentioned later.
Ready for exp and supporting GitHub page scanner provided in the Kali
The final test environment
Attack: Kali IP: 192.168.26.135
Drone: Win7 IP: 192.168.26.134 (open 3389)
Tools: MSF framework
Exploits
The following is a question of finishing outside the loophole during the reproduction process, and a variety of unexpected encounters and indeed I could find and solve the related solutions I encountered problems.
Problems encountered when loading frame module
Module failed to load
According to current thinking for the first time the complex, is to exp MSF and other files into the corresponding directory manipulation framework is loaded, but this time it was an issue framework can not load the corresponding module,
View framework.log get the following information
......
[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'
......Find solutions
The reason for the emergence of the problem is unknown, here I try to re-install reacquire from MSF, but the problem seems not solved, there will still be problems 0708 corresponding module failed to load, after Baidu to no avail, and finally in a under 404 search engines help to get a clue, and after reference to the following article and issue
Playing with the BlueKeep MetaSploit module
Can not load another module #12321
Decided to try to use git-bundle way to reinstall my MSF framework, the benefits of this way is that you can have direct access to the framework version contains cve-2019-0708 on Github, instead of manually downloading add, to avoid the unknown confounders
Try new installation
The new installation project first of all to git-clone to local, arranged as follows
root@kali:~/Desktop# git clone --single-branch --branch bluekeep https://github.com/busterb/metasploit-framework
Cloning into 'metasploit-framework'Since cloning process is extremely slow, even after the agent may also mention the set speed, consuming a lot of time, when the cloning is complete access to the directory, with the corresponding command to install
root@kali:~/Desktop/metasploit-framework# bundle installBut ... The next series of case is never expected
Problems encountered during installation and
Because by bundle installation, you need to install many of the corresponding components, and I was the first attempt at such an installation, so a lot of dependencies is not installed,
Including the zlib, zliblg-dev, libpq-dev, libpcap-dev, re-run the install command by the command after the installation
sudo apt-get install zlib1g
sudo apt-get install zlib1g.dev
sudo apt-get install libpq-dev
sudo apt-get install libpcap0.8-devThis style is eventually successful installation
If there are other green font seems to install a sign of success, if not bright red error
Attack process
After reinstalling a good framework to start program
这里有一个要注意的点，因为重新用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自启服务是在登录阶段进行启动的，而这一阶段是后于内核加载阶段，假设此处我对于该漏洞浅显的理解没有错误，且该漏洞的攻击也假设可以在启动系统启动项前作用于该系统，那是否可以通过漏洞的二次攻击，先将靶机系统蓝屏重启，在重启的过程中利用内核加载阶段过渡到登录阶段的这一间隙再次运行攻击程序来完成攻击。
而对于这一假设目前最明显的问题就是网络的连通性，网络服务也属于系统的自启项之一，所以当在未联网的系统开机过程中如何实施攻击就是问题，当然这还有很多的问题包含在里面，而这也仅仅是我的一个假设，但能通过这次复现的过程学习到这么多东西也是一次宝贵的过程，也发现了漏洞复现对于学习也有很大的帮助，可以更深入的了解和探知漏洞背后的规律和原理，即便不能完全理解吃透，这也是一次实践的经历。