深入分析CVE-2021-4034及漏洞复现

Posted 2023-04-18

参考技术A winrm

HTTP.sys

winrm默认监听端口：

项目地址：

使用方法：

本程序利用HTTP.sys官方接口，向该驱动注册url前缀，与IIS共享端口，从而实现后门功能。

项目地址：

项目地址：

本地的1080端口即可访问

如果目标严格禁止仅仅开放80端口，我们就需要把80的ssh流量转发到22的ssh

别的师傅说因为所有的流量都转发到了22，所以正常访问80端口会访问不了，但是经过我的实际测试，我用的python开启的http服务，连接80端口的ssh的时候，也是可以正常访问的。

不限制访问ip

如果想要多开几个ssh连接，我们只需要把端口再转发几个就行了

开启：

关闭：

如果网络中禁止ping，或者没有ping，则无法利用

ubuntu中：

kali中：

开启连接：

关闭连接：

待续

成功正向连接

web日志：

假定需要通过192.168.198.133的3389端口转80端口，则需要在192.168.198.133主机的命令行输入如下语句：

冰蝎有自带的正向流量代理工具

箭头所指处填写

需要用到蚁剑的插件：AS-exploit

CVE-2019-0708 漏洞分析及相关测试

在CVE-2019-0708公布后几天就已经尝试过复现该漏洞，但借助当时exp并没能成功复现反弹shell的过程遂放弃，故借助这次漏洞复现报告再来尝试复现该漏洞，因为还在大三学习中，有很多知识还没有掌握，出现的错误希望得到指正，也想借此给19年的学习画上句号，希望这次可以成功吧。

漏洞背景

CVE-2019-0708 | 远程桌面服务远程执行代码漏洞

安全漏洞发布时间: 2019-05-14

MITRE CVE-2019-0708

当未经身份验证的攻击者使用 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

Getting the Bluekeep Exploit-Twitter

Getting the Bluekeep Exploit

决定尝试使用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自启服务是在登录阶段进行启动的，而这一阶段是后于内核加载阶段，假设此处我对于该漏洞浅显的理解没有错误，且该漏洞的攻击也假设可以在启动系统启动项前作用于该系统，那是否可以通过漏洞的二次攻击，先将靶机系统蓝屏重启，在重启的过程中利用内核加载阶段过渡到登录阶段的这一间隙再次运行攻击程序来完成攻击。

 

而对于这一假设目前最明显的问题就是网络的连通性，网络服务也属于系统的自启项之一，所以当在未联网的系统开机过程中如何实施攻击就是问题，当然这还有很多的问题包含在里面，而这也仅仅是我的一个假设，但能通过这次复现的过程学习到这么多东西也是一次宝贵的过程，也发现了漏洞复现对于学习也有很大的帮助，可以更深入的了解和探知漏洞背后的规律和原理，即便不能完全理解吃透，这也是一次实践的经历。