Windows Remote Code Execution Vulnerability Requires More Than Just Patching
But nobody said it was going to be easy...
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt80ad5f6b59198497/64f17b2d3023e87c07f5cd03/9144.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
The remote code execution (RCE) vulnerability in Remote Desktop Protocol (RDP) of Windows (CVE-2019-0708) was patched by Microsoft in May. They have made patches available for all their systems, even including Windows 7, which is in end-of-life status. They have strongly advised everyone -- and they mean everyone -- to apply the patch, fearing the exploit could become widespread.
There are ways to protect against the RCE at a network level, Cisco Talos has found. One can use SNORT rules to block any RDP connection that attempts to use the "MS_T120" virtual channel, for example. That is the channel that enables the entire RCE process. Nick Biasini of Talos posted a summary of their work that shows how involved a full network solution would have to be. And it's not an easy one, by any means.
The blog focuses on how to deal with an attacker that tries to bypass any network efforts against the "BlueKeep" RCE exploit by encrypting the RDS service using TLS. Such encryption would stop the scanning of the RDP stream unless it is acknowledged as encrypted during the beginning of the RDS connection.
Cisco outlines in their posting the steps that are necessary to get RDP over SSL decryption.
The self-signed certificate for the RDP server is the first area that needs attention. Working with the "Remote Desktop Session Host Configuration" can obtain the private key to it.
Some command line work in OpenSSL is the next step after exporting the certificate. This gets the RDP certificate separated by itself, and able to be imported into your network scanner.
Once imported, the certificate is used to create an Intrusion Prevention Policy in the network scan. It has to be enabled, of course.
In general, even if services like RDP and SMB are not exposed to the raw Internet unless explicitly required, it will not eliminate the need for continual patching.
As Talos put it, "Vulnerabilities this severe appear periodically, and organizations need to be prepared to respond in a variety of different ways. Patching takes time and making sure that you have detection and prevention in place can require varying levels of difficulty. In this particular example, in order to get a higher level of visibility, SSL decryption is required for more thorough protections."
Although additional detection steps may be useful in this kind of situation, they can't be counted on to stop all problems that may arise. Patching remains the best overall solution.
Be aware that the network-layer solution that Talos is proposing has never been implemented at scale and across so many versions of Windows (all of which have quirks). This means other controls would need to be in place (like everyone in the world patching) for true mitigation.
— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.
Read more about:
Security NowAbout the Author
You May Also Like
Catch the Threat Before it Catches you: Proactive Ransomware Defense
September 5, 2024How to Evaluate Hybrid-Cloud Network Policies and Enhance Security
September 18, 2024DORA and PCI DSS 4.0: Scale Your Mainframe Security Strategy Among Evolving Regulations
September 26, 2024Harnessing the Power of Automation to Boost Enterprise Cybersecurity
October 3, 2024
[Virtual Event] The Essential Guide to Cloud Management
October 17, 2024Black Hat Europe - December 9-12 - Learn More
December 10, 2024SecTor - Canada's IT Security Conference Oct 22-24 - Learn More
October 22, 2024