Digital Immunity Prevents BLUEKEEP in Manufacturing OT

May 23, 2019 | Tristan Lawson, Senior Solutions Architect

It’s going to be a long Memorial Day weekend for many security engineers in the Manufacturing Industry as they scurry around their plants patching Microsoft Windows workstations and servers that are vulnerable to the latest BlueKeep vulnerability.  Designated as “critically severe,” this “wormable” vulnerability can propagate across vulnerable systems in WannaCry fashion.  Companies are being advised to quickly patch affected systems.

Digital Immunity Threat Researchers have reviewed the BlueKeep Vulnerability, released May 14th 2019 by Microsoft, with the assigned CVE of 2019-0708, and have assessed how foreign code would be inserted into memory by a BlueKeep exploit. Digital Immunity DI PROTECT™ will detect and prevent, in memory, at run-time, the insertion of the foreign code by a BlueKeep Exploit, without the need for emergency patching.

The article below explains the details of the BlueKeep exploit and what you can do to protect your critical OT devices.

BlueKeep Remote Desktop Exploit

The announcement of the potent remote desktop exploit (RDP) vulnerability by Microsoft through its security advisory has recently created substantial buzz. Microsoft states the CVE-2019-0708 vulnerability is a Remote Code Execution vulnerability and ranks it a high criticality and  a Common Vulnerability Scoring System (CVSS) score of 9.8 out of 10.  This high score is because the exposure is within Remote Desktop Services, which are used all over the world by Industrial Control environments to enable Operational Technology (OT) staff to access Industrial Control Systems (ICS) and infrastructure.

Who and What Is at Risk?

The CVE-2019-0708 vulnerability, referred to as BlueKeep, affects anyone running the following operating systems:

  • Windows XP
  • Windows Server 2003
  • Windows Server 2008
  • Windows 7
  • Windows Server 2008 R2

OT environments are at an increased risk because many systems are considered legacy systems and are past End-of-Life for vendor support which means patches may not be available for some time, if ever. Additionally, these environments tend to remain static, with little change, and as a result, often go unpatched. Patching OT systems for critical vulnerabilities such as this one means emergency downtime, loss of revenue and staff overtime. Systems such as Human Machine Interfaces (HMI’s), Data Historians and Engineering workstations all run Windows operating systems and are potentially affected by this new vulnerability.

A likely vector of attack uses jump servers which are often used and accessible from IT networks to get to the inner protected networks represented in a typical Purdue Model architecture. This vulnerability can be used to breach the segmentation between the protected networks. In this scenario, attackers can perform malicious operations, such as:

  1. updating live production parameters,
  2. deleting and altering critical files and folders,
  3. making changes to data,
  4. creating administrative accounts, and
  5. potentially launching a subsequent malware attack such as ransomware (LockerGoga is a potent example).

Technical Brief

When reviewing a brief history of Windows Terminal Services, you find that Microsoft kept most of the functionality of the Terminal Services running within the Kernel drivers for versions of Windows Server 2000 through Windows 7, and Windows Server 2008 R2.

This vulnerability abuses the lack of checks for the use of the channel name MS_T120 on any channel other than Channel 31, which can cause a heap corruption within the Termdd.sys driver. Virtual channels provide data channels for functions such as mouse, keyboard, clipboard, etc.

CVE-2019-0708, also known as BlueKeep is considered a User-After-Free vulnerability because, by binding the channel name MS_T120 in such a manner through the initialization of a channel other than the hard-coded channel index 31, the memory allocation becomes freed. This causes a dangling pointer of the virtual channel structure, where the result can then be used to leverage control of process execution. Gaining control of the process execution occurs through reallocating the freed virtual channel structure and the overwriting of address pointers in memory which the virtual channel structure contains. An absolute call primitive is then possible, which in the case of an attacker would be used to point to shellcode.

How Does It Work?

Remote Desktop Protocol, just like any other protocol, follows a series of steps which is executed each time a Remote Desktop connection is initiated, illustrated in the diagram below.     It is the initiation of the Generic Conference Control (GCC) Conference Creation Request step where the attack begins to take advantage of the CVE-2019-0708 vulnerability.

Remote Desktop Protocol Flow Source

Before authentication is even initiated in the setup of an RDP connection, RDP negotiates various parameters. The parameter of interest is the setting of Virtual Channels through the GCC Conference Initialization. The Dynamic Virtual Channels (DVC’s) are setup and torn down dynamically while the RDP sessions are active. Static Virtual Channels (SVC’s) are setup at the time of initialization. There are 32 channels possible.

In a typical RDP session, only three Static Virtual Channels (SVC’s) are setup. The vulnerability discussed is assigning a name to a fourth SVC of MS_T120 to a channel index number other than 31. The channel MS_T120 is a Microsoft internally used name.  There is no documented legitimate reason for a typical client application connecting to an RDP server to ever need to establish an SVC with this channel name.

The channel name MS_T120 can be given to the RDP server on a channel index number other than 31. Using the MS_T120 channel name on a channel index other than 31 causes a heap memory corruption.

The below diagram illustrates the areas of the RDP Service and drivers involved when the vulnerability is exploited.

Steps for Exploitation

Pre-Authentication

  • Initiate X.224 connection
  • Generic Conference Control (GCC) Conference Create Request
    • Typical operation (three channels requested)
    • Channel Name MS_T120 added to Fourth Channel (IDS Signatures Look for this)
  • The channel name MS_T120 is created with rdpwsx.dll
  • The Heap Pool for the MS_T120 channel is allocated by rdpwp.sys
    • An MS_T120 channel name is statically allocated to Channel 31
  • Another channel other than 31 is being named MS_T120 causing Heap Corruption within termdd.sys
  • The Heap which was used by the SVC channel named MS_T120 is now freed
  • Overwrite addresses in freed memory space with shellcode in Kernel memory
  • Call shellcode which inserts shellcode into a process to establish connection back to the attacker.

Where Digital Immunity Intercepts

Digital Immunity DI PROTECT™ intercepts at the point where foreign shellcode is inserted into memory and attempts to execute. The foreign shellcode is caught and execution is prevented by Digital Immunity DI PROTECT™ with no disruption to the system or its good processes.

Current Detection Tools Available

A Scanner by zerosum0x0, a Metasploit contributor, is available at https://github.com/zerosum0x0/CVE-2019-0708.

This scanner can be used to determine if your systems are vulnerable, though current testing shows this tool is not 100% reliable.

There is also a Suricata signature, released by the NCC Group, which detects the GCC initialization of RDP attempting to use MS_T120 channel on any channel other than 31. The signature can be found at https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt.

This signature does alert when using the published scanner.

What You Should Do NOW

It is good hygiene to do patching and hardening. It is common knowledge however that patching is and always will be a losing battle, especially when zero-day exploits become available, which may have been the case with BlueKeep where there was an exploit available on the market months before the announcement of the vulnerability and patch.

Although patching maybe a losing battle, In the short-term, if you have any systems running the affected versions of Windows, you should look at doing the following action items which include patching:

  • Enable Network Level Authentication (NLA) Where possible
    • This limits the exposure, so the vulnerability is no longer a pre-authentication threat

While it is good security practice to patch when possible, it is a losing battle.  You will never get ahead and as we all know, patching will not prevent zero-day attacks

Long Term Goals

Digital Immunity DI PROTECT™ will detect and prevent, in memory, at run-time, the insertion of the foreign code by a BlueKeep Exploit. Digital Immunity’s prevention capability will not disrupt good processes, ensuring that operations continue uninterrupted.  DI PROTECT™ also capture’s deep forensics, in context, at the point of attack.

In the long-term you should assess how a technology such as DI PROTECT™ could prevent cyber-threats like BlueKeep and allow you to better control the need for emergency patching.  According to this source, https://habr.com/en/company/jetinfosystems/blog/451852/,  this  same exploit has allegedly been available for sale on the black market for almost a year. Having a technology such as DI PROTECT™ to prevent known and unknown threats in OT can provide priceless peace of mind. DI PROTECT™ also delivers the added benefits of reduced down time, reduced emergency patching and increased uptime and revenue.

 

Want to give Digital Immunity a try?
Click here for more information and to request a software demo.

Request a Demo