In its May Patch Tuesday update, Microsoft took quite an unusual step by making available security patches for operating systems that have long been discontinued. This update fixed a critical vulnerability, commonly known as BlueKeep, and required many organizations to test their patch management posture.

What Is BlueKeep?

BlueKeep is the common name for a remote code execution vulnerability (CVE-2019-0708) that exists in Microsoft’s Remote Desktop Protocol (RDP). This vulnerability occurs pre-authentication and requires no user interaction. In other words, attackers can execute code remotely without being dependent on a user falling victim to their scam. These characteristics are what make this vulnerability wormable, meaning that once exploited, the malicious code can propagate from one vulnerable computer to another automatically.

The BlueKeep vulnerability affects Windows 7, Server 2008 R2 and Server 2008, but also the out-of-support systems Windows 2003 and XP. Windows 8 and 10 are not affected.

Remote Desktop Protocol and BlueKeep

RDP, formerly known as Terminal Services, is a protocol to manage a computer remotely over a network connection with a graphical user interface. It’s primarily used in Windows environments, but clients exist for Linux and macOS as well. An RDP connection comprises a number of individual communication channels between the client and the endpoint that allow for data transmission. Earlier versions of RDP had only a limited number of static virtual channels (SVC), but this was solved in more recent versions with the introduction of dynamic virtual channels (DVC).

One of the major drawbacks of static channels was that they were created at the beginning of the connection and then terminated at the end of the connection. This meant that if you added a device during an RDP session, you could not make use of this device via an extra channel, except by stopping and restarting the session. With dynamic channels, a client can now create and stop channels when needed.

This concept of channels is what lies at the heart of the BlueKeep vulnerability. Following up on an X.224 connection request by the client and the confirmation by the server, the client sends a Generic Conference Control (GCC) Conference Create Request. This request is sent before authentication takes place. In this request, the client specifies which channels to use during the communication. If the client then adds a channel named “MS_T120” and binds this to a channel number other than 31, then the vulnerability is triggered, leading to heap memory corruption and remote code execution. In practice, this client-supplied input causes the hardcoded MS_T120 channel to be bound a second time, after it was already bound internally to 31.

What’s the Risk for the Enterprise?

In its advisory, Microsoft made a comparison to earlier worms such as WannaCry and NotPetya. Looking back at the root cause of these worms, the SMBv1 vulnerability was then also already patched for quite some time. At a basic level, BlueKeep can lead to the execution of whatever code the attacker chooses — either code that facilitates an attack that remains undetected with the objective of getting a further foothold in an organization, or a more destructive approach such as installing ransomware on production servers.

Currently, there is no known malware exploiting this vulnerability, but most experts, including Microsoft, are confident that working exploit code exists. Additionally, the wormability factor is increased by the fact that the vulnerability is also located in the older Windows XP and Server 2003 systems and these systems require manual updating.

How to Protect Against BlueKeep

In general, your patch management process should already include how to deal with installing the monthly patches from Microsoft. This means that, in theory, dealing with BlueKeep should be no different from dealing with other vulnerabilities. Unfortunately, due to the high number of updates to apply monthly and despite options to deploy them automatically, a lot of organizations may still run behind. As a consequence, they might miss the update that protects them against BlueKeep. So how can these organizations improve this?

Stay Prepared for the Latest Threats

IT security teams can easily anticipate the timing as Patch Tuesday occurs on the second Tuesday of every month. This fixed timing makes it easier to foresee the necessary resources you’ll need. Do not assume that all patching will happen automatically; some patches will have to be applied manually or require a manual intervention.

The amount of patches can be overwhelming for operational teams in certain organizations, so it’s best to have your computer security incident response team (CSIRT) or security operations center (SOC) do an initial evaluation and issue an internal advisory. To be effective, this advisory should follow rapidly after Patch Tuesday and cover the following:

• A technical evaluation of the most important vulnerabilities. Differentiate between end user systems and servers so operational teams know what’s relevant to them.
• A preliminary impact assessment of how these vulnerabilities could affect the organization. For example, an update for a service that is not used within your organization is less urgent. Also describe if certain preconditions for a vulnerability to be exploitable exist within your organization and whether you have security controls in place that protect you against exploitation.
• A classification of how urgent patches need to be deployed; if they can be included in your normal patch schedule or if they warrant an out-of-band patching.
• The mitigations or workarounds that are known to be effective.
• Methods for how you can track attempts for exploiting this vulnerability.
• A summary of known issues. Do not stick to issues only communicated by Microsoft but other sources as well.
• Established methods for testing if patching was successful.

Test, Test, Test

Testing should not be limited to verifying whether a patch was successfully installed. Equally important is that after the installation of the patch, the essential business components still function as expected. To better manage this, your patch management plan should include a phased deployment, ideally starting with a test environment. This test environment should mimic the real-life environment of your organization as close as possible. If needed, you can deploy clones of production machines in an isolated test network and then deploy the patches on these copies.

Make sure to monitor end user systems closely after deploying patches, measuring system crashes or increased unexpected behavior. In certain cases, it can be useful to instruct the help desk how to handle user reports that are likely caused by malfunctioning patches.

Mitigation Measures for BlueKeep

There’s no replacement for patching for BlueKeep, but in the meantime, here are some additional measures you can put in place:

• Disable RDP from outside your network. Make sure that you filter traffic on your perimeters.
• Be aware that if a system is exploited, nothing prevents the malware from changing the network port for RDP.
• Limit the internal use of RDP to systems that really need it and the management network.
• Block client requests with “MS_T120” on any channel other than 31 during the GCC Conference Initialization sequence.
• Enable Network Level Authentication (NLA). Note that this does not protect you if the attacker has obtained credentials or the system uses weak credentials.
• For systems that are problematic to reboot, you can apply micropatches as provided by 0patch.

To Protect Your Assets, Get to Know Them

An up-to-date configuration management database (CMDB) helps you to identify which systems need patching first. Unfortunately, reality proves that in a lot of organizations, these CMDBs are often far from complete. This doesn’t mean that you are at a loss.

The first resource to find affected assets is your own internal network data. Netflow data of your switches or routers is a valuable source to identify RDP traffic — and from where it’s being used. Pay special attention to RDP flows to and from a demilitarized zone (DMZ) or internal server zone.

Next, a vulnerability scanner often includes port scanning and chances are high that RPD is included. You can also do a more in-depth vulnerability scan — the popular penetration testing tool Metasploit contains support for testing if your RDP servers are vulnerable. Additionally, you can make use of a PowerShell script to check your Azure subscriptions and query the network security groups to see if port 3389 is open.

Furthermore, if your security information and event management (SIEM) tool supports Sigma, it can make use of the rule sysmon_susp_rdp.yml to detect nonstandard tools connecting to RDP. As a last resort, you can use the data made available by Shodan to monitor for alerts when a new RDP service pops up in your network.

At the end of the day, a solid patch management process is the best defense against BlueKeep and similar vulnerabilities. To protect critical assets, security teams must stay up-to-date on and prepared for the latest vulnerabilities, and implement regular patch testing to ensure business continuity and end user functionality.