Not able to run CVE-2019-0708

[hexagon-sigma]

[] Started reverse TCP handler on 172.31.23.143:4444 [] IP:3389 - Detected RDP on IP:3389 (Windows version: 6.1.7600) (Requires NLA: No) [+] IP:3389 - The target is vulnerable. [-] IP:3389 - Exploit failed: Msf::Exploit::Remote::RDP::RdpCommunicationError Msf::Exploit::Remote::RDP::RdpCommunicationError [*] Exploit completed, but no session was created.

Why it is showing RdpCommunicationError

[Synzack]

I am having the same issue. Steps I have already tried: -Installing latest files -Setting the GroomBase according to NPP address -Trying different GroomSizes -Lowering encryption level on the host -Toggled SSL/TLS settings in Metasploit module

[bwatters-r7]

The RdpCommunicationError means "something went wrong while speaking RDP to the target" Since you have a fingerprint of the OS using the RDP SMB magic, that means there's something there to talk to, so no issues reaching RDP, but what the target sending back during the exploit is not what the module expects. That makes me curious what it is saying. The best way to figure that out is with wireshark or other packet capture application. What does the target say before the connection is closed?

Specifically, I see that RdpCommunicationError is raised in three locations

Location 1 and 2: In this case, it gets raised if the packet is empty or the length/size don't match

  def rdp_recv(length = -1, timeout = 5)
    res = self.rdp_sock.get_once(length, timeout)
    raise RdpCommunicationError unless res # nil due to a timeout

    res
  rescue EOFError
    raise RdpCommunicationError
  end

3: Raised when the RSA magic number is not where it should be in the packet (likely not the case here as you don't show the print_error message that precedes this invocation).

        if rsa_magic != "RSA1"
          print_error("Server cert isn't RSA, this scenario isn't supported (yet).")
          raise RdpCommunicationError
        end

So likely, you're experiencing the first or second error; either the packet you are getting back has a size and length mismatch or it is nil. If it is nil, it could be due to a timeout or a reset (?). We've also seen some interesting instances of RDP that have some nuance in responses that we were not expecting, and we're trying to get those changes into the code so those responses are handled correctly. The only way to be sure is to see the network traffic and figure out what the response is that's confusing the module. Regardless, there is little we can do without knowing what that response was.

It would help greatly if you could let us know what the contents of the packet were that cause the exception. If it was in a lab and you are comfortable sharing, please send us a pcap to msfdev[at]metasploit.com We really appreciate your help!

[bwatters-r7]

@Zachilles21 I assume it was you that emailed the info; thank you for that! I was able to recreate your error in my lab quickly. The catch is that the target has "Low" security settings involved, so the SSL negotiation stops, and that appears to break the exploit. Awesome find! I am going to bring this up in the PR in hopes someone can address it.

For anyone coming afterward, to re-create this scenario on a Windows 7 x64 SP1 VM, go to the group policy editor and change the value under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Set Client Encryption Level. Select Enable and set the Encryption level to Low.

[Synzack]

@bwatters-r7 Yes that was me, thanks for the quick reply! The low security setting was actually the result of another error. When the setting was not set to low, I received the following:

msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run
[*] Started reverse TCP handler on 10.223.20.93:4444
[*] 10.220.22.151:3389    - Verifying RDP protocol...
[*] 10.220.22.151:3389    - Attempting to connect using TLS security
[-] 10.220.22.151:3389    - Connection reset
[*] 10.220.22.151:3389    - Cannot reliably check exploitability.
[-] 10.220.22.151:3389 - Exploit aborted due to failure: not-vulnerable: Set ForceExploit to override
[*] Exploit completed, but no session was created.

I believe it has something to do with the TLS/SSL communications. I have a tried enabling certificates as well as toggling the security layer (SSL/TLS1.0) settings in the group policy. It could be a host issue? Not sure. When I attempted the exploit using the the rdp_bluekeep.py file, it did not appear to have the same issue connecting to SSL.

[bwatters-r7]

Any chance your target is using a Windows host that is asking for activation?

[Synzack]

Ah, yes, it is not an activated windows host. Would that be the issue?

[bwatters-r7]

It may be. It is something that is getting checked out right now. It was what I thought your original problem might have been at first.

[Synzack]

Thank you!

[bwatters-r7]

@Zachilles21: @bcook-r7 pushed a set of updates last night to https://github.com/rapid7/metasploit-framework/pull/12283 Could you update and rerun with set verbose true and post/email the console output? We don't have a fix, yet, but if the problem is the licensing stuff, it will show it when verbose is turned on, now.

[Synzack]

Hey @bwatters-r7, here is my output. This host didn't have the TLS enabled so it still shows the RDPCommunicationError, but I do see the license packet error. Thanks for the team's help on this.

`msf5 exploit(windows/rdp/cve_2019_0708_bluekeep_rce) > run

[] Started reverse TCP handler on 10.0.2.9:4444 [] 10.0.2.10:3389 - Verifying RDP protocol... [] 10.0.2.10:3389 - Attempting to connect using TLS security [] 10.0.2.10:3389 - Attempt to connect with TLS failed with error: SSL_NOT_ALLOWED_BY_SERVER [] 10.0.2.10:3389 - Attempting to connect using Standard RDP security [] 10.0.2.10:3389 - Verifying RDP protocol... [] 10.0.2.10:3389 - Attempting to connect using TLS security [] 10.0.2.10:3389 - Attempt to connect with TLS failed with error: SSL_NOT_ALLOWED_BY_SERVER [] 10.0.2.10:3389 - Attempting to connect using Standard RDP security [] 10.0.2.10:3389 - Detected RDP on 10.0.2.10:3389 (Windows version: N/A) (Requires NLA: No) [] 10.0.2.10:3389 - Sending erect domain request [] 10.0.2.10:3389 - Sending security exchange PDU [] 10.0.2.10:3389 - Sending client info PDU [] 10.0.2.10:3389 - Received License packet (34 bytes) [*] 10.0.2.10:3389 - Got license packet type 0xff (LICENSE_ERROR_ALERT)* [] 10.0.2.10:3389 - Waiting for Server Demand packet [] 10.0.2.10:3389 - Received Server Demand packet [] 10.0.2.10:3389 - Sending client confirm active PDU [] 10.0.2.10:3389 - Sending client synchronize PDU [] 10.0.2.10:3389 - Sending client control cooperate PDU [] 10.0.2.10:3389 - Sending client control request control PDU [] 10.0.2.10:3389 - Sending client input sychronize PDU [] 10.0.2.10:3389 - Sending client font list PDU [] 10.0.2.10:3389 - Sending patch check payloads [+] 10.0.2.10:3389 - The target is vulnerable. [] 10.0.2.10:3389 - Verifying RDP protocol... [] 10.0.2.10:3389 - Attempting to connect using TLS security [] 10.0.2.10:3389 - Attempt to connect with TLS failed with error: SSL_NOT_ALLOWED_BY_SERVER [] 10.0.2.10:3389 - Attempting to connect using Standard RDP security [] 10.0.2.10:3389 - Sending erect domain request [] 10.0.2.10:3389 - Sending security exchange PDU [] 10.0.2.10:3389 - Sending client info PDU [] 10.0.2.10:3389 - Received License packet (34 bytes) [*] 10.0.2.10:3389 - Got license packet type 0xff (LICENSE_ERROR_ALERT)* [] 10.0.2.10:3389 - Waiting for Server Demand packet [] 10.0.2.10:3389 - Received Server Demand packet [] 10.0.2.10:3389 - Sending client confirm active PDU [] 10.0.2.10:3389 - Sending client synchronize PDU [] 10.0.2.10:3389 - Sending client control cooperate PDU [] 10.0.2.10:3389 - Sending client control request control PDU [] 10.0.2.10:3389 - Sending client input sychronize PDU [] 10.0.2.10:3389 - Sending client font list PDU [-] 10.0.2.10:3389 - Exploit failed: Msf::Exploit::Remote::RDP::RdpCommunicationError Msf::Exploit::Remote::RDP::RdpCommunicationError [] Exploit completed, but no session was created.`

[busterb]

This could be related to an issue I saw targeting a device with Wifi that had a very small receive buffer, where we would send messages too fast and the TCP window would overflow, retry too many times, then reset the connection. Does Wireshark show something like "TCP Window Full" if you capture network traffic?

[its0x08]

LoL not licensed users are safer ?! Whatt ?!!

[peterpt]

i got here first : [*] Exploit completed, but no session was created. without s meterpreter session

so i run the exploit for the 2nd time and i got . Exploit aborted due to failure: unreachable: Unable to connect to RDP service

after this point when i try to connect to the test computer using rdesktop i got

Autoselected keyboard map en-us ERROR: 192.168.1.46: unable to connect

The error here was that Windows was 32bit and payload was 64bit .

[DongGyu1996]

I'm curious about this problem, too. Have you solved it?

[jisjose98]

exploit(windows/local/bypassuac_windows_store_reg) > exploit

[] Started reverse TCP handler on 192.168.43.46:4444 [] UAC is Enabled, checking level... [+] Part of Administrators group! Continuing... [+] UAC is set to Default [+] BypassUAC can bypass this setting, continuing... [!] This exploit requires manual cleanup of 'C:\Users\IEUser\AppData\Local\Temp\BfHDKsm.exe! [*] Exploit completed, but no session was created.

[bwatters-r7]

@jisjose98 this is an issue thread about cve_2019_0708_bluekeep_rce. You opened an issue about the windows store privileged escalation here: https://github.com/rapid7/metasploit-framework/issues/13210 that has a question waiting.