An Update on the Microsoft Windows RDP "Bluekeep" Vulnerability (CVE-2019-0708) [now with pcaps]
Last Updated: 2019-05-22 20:22:40 UTC
by Johannes Ullrich (Version: 1)
[Please comment if you have any feedback / suggested additions/corrections. You can also use our comment form ]
The most notable vulnerabilities patched by Microsoft last week addressed an input validation flaw in the Remote Desktop Service. To exploit the vulnerability, an attacker would send a specially crafted Remote Desktop Protocol (RDP) request to the Remote Desktop Service. The vulnerability is notable for several reasons:
- The exploitation of the vulnerability does not require authentication.
- An exploit may lead to arbitrary code execution.
- (too) many organizations are exposing RDP to the Internet.
- Windows 7 / 2008 and older are affected, going back to Windows XP.
Current Exploit Development Status
Several security vendors stated publicly that they developed exploits internally that will at least trigger a denial of service condition (blue screen). Currently, there are at least two public partial exploits . One triggers the "vulnerable path" without triggering a blue screen or causing any other damage. It can be adjusted to play with the "channel" parameter to create normal and exploit traffic. The second one also triggers the vulnerability without any intended ill effect. The second exploit has been made available in the form of a stand-alone vulnerability scanner.
It does appear non-trivial to develop a reliable remote code execution exploit for this vulnerability, which will hopefully get us a few more days until one is publicly available. However, exploit development is active, and I don't think you have more than a week.
Currently, we do not see a big increase in port 3389/TCP scanning. But this port is scanned rather heavily even without a new vulnerability drawing attention to it.
The NCC Group publicly released a Suricata signature to detect attacks taking advantage of the exploit . It is difficult to estimate how good the signature is. Cisco released rules for snort as well. Note that RDP usually uses TLS, and all current partial exploits use TLS, making the value of these rules questionable.
What you need to do NOW
Remember, we are coming up on a long weekend in the US. I hope you are well into mitigating this vulnerability as you read this, but here are a few things to consider:
- Do you have any systems running affected versions of Windows? Where are they located (e.g., are they confined to particular subnets)? Can you block port 3389 (RDP) inbound and possibly outbound?
- Deploy IDS/IPS rules to detect the exploit (just in case, but note the TLS issue above).
- Scan your network for open RDP. Do not just use the vulnerability scanner, but find out who is using RDP and why. RDP should not be exposed if possible.
- Follow up the scan with the vulnerability scanner.
- Patch! You want to patch this by Friday. For some organizations, the long weekend may provide a better patch window which is hopefully still ok.
Network Level Authentication
Another mitigating factor that should be mentioned is "Network Level Authentication". Network Level Authentication requires a valid username and password before the connection negotiation starts. The attacker will have to authenticate to launch the attack. In Windows XP, Network Level Authentication needs to be enabled via Registry settings. In Windows 7 and later, it is a simple setting as you enable the remote desktop. However, keep in mind that not all clients are compatible with Network Level Authentication. You may also run into issues if you need to change credentials on your first log in. So test careful, but this is something you may want to enable. This may also help against future problems with RDP as it defers the complex initial session negotiation until the user is authenticated.
Longer Term Fixes
Being vulnerable exposes two fundamental weaknesses in your network: You are still running Windows 7 (or XP??), and you are exposing RDP. Neither is good, and both issues need to be addressed. With this focus on RDP, there is a good chance that additional vulnerabilities will be found in the next few months. If this is true, then fire drills will continue until you can get these two issues resolved.
Upgrading from Windows 7 to 10, and upgrading from Windows Server 2008, should already be underway, so you may just accelerate what you are already doing. If you still run Windows XP: There better be a very good reason for it, and I hope that you have those systems adequately protected.
Eliminating RDP may be difficult for some organizations. But you can at least isolate it by requiring a VPN to connect to it, or by taking advantage of an RDP gateway supporting SSL. Take a look at some of the guidance offered by Microsoft 
Before authentication, RDP negotiates various parameters and capabilities. After initiating the connection with an X.224 connection request and having it confirmed by the server, the client will send a "Generic Conference Control (GCC) Conference Create Request." Usually, this request defines three different channels. To trigger the exploit, an MS_T120 channel is added as a fourth channel. This channel should only bind to "channel 31", but the exploit will bind it to another channel. The current signatures look for this particular artifact. McAfee's blog offers an excellent summary of some of the details. 
I collected some packet captures from various normal and exploit tools. You can download the pcap files here: https://isc.sans.edu/diaryimages/BlueKeepPCAPs.tgz
[ note that some of the links below may trigger overly sensitive anti-malware scanners ]
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
May 22nd 2019
4 years ago
I do wonder when things like this happen: Something changed around Windows 8 that removed this vulnerability. Whatever it was, it didn't clue the authors in to the problem in the old versions. Is it just a coincidence that the vulnerability was foreclosed?
May 23rd 2019
4 years ago
May 27th 2019
4 years ago
22.214.171.124 - - [2019-05-27T05:38:37Z] "^C^@^@/*à^@^@^@^@^@Cookie: mstshash=Administr" 400 -
May 28th 2019
4 years ago