CVE-2019-0708脆弱性を再現してみました数日を発表し、ないのexpで正常に再生リバウンドシェルプロセスは、その後、あきらめることができたされた後、それが再び脆弱性レポートを再現する脆弱性を再現しようとすることを意味しますジュニアはまだ学んでいるので、多くの知識を習得していないが、研究の19年にフルストップを利用したいと思い、私はそれが成功する可能性があり、この時間を願って、誤りを訂正取得し表示する、があります。
脆弱性の背景
CVE-2019-0708 |リモートデスクトップサービス、リモートでコードが実行される脆弱性
セキュリティの脆弱性公開日：2019年5月14日
認証されていない攻撃者は、ターゲットシステムに接続し、要求（以前は「ターミナルサービス」として知られている）特別に設計され、リモートデスクトップサービス、リモートコードが実行される脆弱性を送信するようにRDPを使用する場合。この脆弱性は、ユーザーとの対話なしに、事前認証です。攻撃者はこの脆弱性を悪用、ターゲットシステム上で任意のコードを実行する可能性があります。表示、変更、または削除データを;その後、攻撃者はプログラムのインストール、または完全なユーザー権限を持つ新たなアカウントを作成します。
この脆弱性を悪用するには、攻撃者がRDPを介してターゲットシステムの設計リモートデスクトップサービスへの特別なリクエストを送信する必要があります。
私たちは、攻撃が彼の最大変えるのその後の使用のいずれかで所望の効果を達成するために行われたときに、リモートデスクトップRDPポート3389を使用するには、RDPプロトコルは、原因害は、計り知れない場所な見ることができます。
準備
ドローン配置
POCは、以下による脆弱性の範囲に発表された詳細情報を取得することができます
Windows2003の、windows2008、windows2008 R2、WindowsはXP、win7の：システムに影響を与えます
win7のシステムのこの選択は、無人偵察機を配置し、使用するシステムのバージョン究極のSP1
win7のをインストールした後、従来のVMware仮想マシンの脆弱性に応じて開いているポート3389の使用を必要とし、最終的な配置の結果は次の通りであります
攻撃機のレイアウト
cve_2019_0708_bluekeep_rceのMetasploitのフレームワークを使用した攻撃が使用して提供されているので、カリのLinux-2019.03以降のプロセスでのMSFが事前にロードされたが、実際には多くの予期せぬ事態に遭遇して、後述します。
EXPとカーリーに設けられた支持のGitHubページスキャナの準備ができました
最終テスト環境
攻撃：カーリーIP：192.168.26.135
ドローン：win7のIP：192.168.26.134（オープン3389）
ツール：MSFフレームワーク
エクスプロイト
以下は、再生処理中に抜け穴外仕上げの問題、予期せぬ出会いの品種ですと確かに私は私が問題に遭遇した関連ソリューションを見つけ、解決することができます。
問題フレームモジュールをロードするときに遭遇しました
モジュールのロードに失敗しました
複雑初めての現在の考え方によると、ロードされている対応するディレクトリ操作フレームワークにMSFや他のファイルをexpにあるが、今回はそれが問題のフレームワークは、対応するモジュールをロードすることはできませんでした、
ビューには、以下の情報を得る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対応モジュールの問題があるだろう、無駄にBaiduの後、最終的にAで404下の検索エンジンは、手がかりを得るのに役立ち、かつ、次の資料と問題に言及した後
BlueKeep Metasploitのモジュールと遊びます
私のMSFの枠組みを再インストールするためのgit-バンドル方法を使用しようとすることを決定し、この方法の利点は、あなたがフレームワークのバージョンに直接アクセスすることができるということですが、未知の交絡因子を避けるために、代わりに手動で追加をダウンロードするので、GitHubの上CVE-2019から0708まで含まれてい
新規インストールをお試しください
次のように配置されたローカルのgitのクローンへの最初のすべての新しいインストールプロジェクト、
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しかし...例次のシリーズが期待されることはありません
インストール時に発生する問題と
、バンドルインストールによって、あなたが対応する構成要素の多くをインストールする必要があり、そして私は、このようなインストールでは初めての試みだったので、依存関係の多くがインストールされていないため、
ZLIB、zliblg-devを、libpqの-devの、のlibpcap-devを含めて、コマンドでinstallコマンドを再実行してインストールした後
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自启服务是在登录阶段进行启动的，而这一阶段是后于内核加载阶段，假设此处我对于该漏洞浅显的理解没有错误，且该漏洞的攻击也假设可以在启动系统启动项前作用于该系统，那是否可以通过漏洞的二次攻击，先将靶机系统蓝屏重启，在重启的过程中利用内核加载阶段过渡到登录阶段的这一间隙再次运行攻击程序来完成攻击。
而对于这一假设目前最明显的问题就是网络的连通性，网络服务也属于系统的自启项之一，所以当在未联网的系统开机过程中如何实施攻击就是问题，当然这还有很多的问题包含在里面，而这也仅仅是我的一个假设，但能通过这次复现的过程学习到这么多东西也是一次宝贵的过程，也发现了漏洞复现对于学习也有很大的帮助，可以更深入的了解和探知漏洞背后的规律和原理，即便不能完全理解吃透，这也是一次实践的经历。