Windows RDP Remote Code Execution Vulnerability (BlueKeep) – How to Detect and Patch
Last updated on: December 20, 2022
This month’s Microsoft Patch Tuesday included a very high-risk vulnerability (CVE-2019-0708, aka BlueKeep) in Remote Desktop that impacts Windows XP, Windows 7, Server 2003, Server 2008, and Server 2008 R2. This vulnerability allows an unauthenticated attacker (or malware) to execute code on the vulnerable system. It is very likely that PoC code will be published soon, and this may result in a WannaCry-style attack.
Microsoft has not only released patches for Windows 7, Server 2008 & R2, but also has taken the extra step to issue patches for Windows XP and Server 2003. Patch now!
UPDATE: Network Level Authentication (NLA) partially mitigates this vulnerability. QID 90788 (Microsoft Windows Network Level Authentication Disabled) can be used to find hosts that have NLA disabled. This forces the attacker to have valid credentials in order to perform RCE.
UPDATE: A new remote (unauthenticated) check was released under QID 91541. See below for details.
Detecting CVE-2019-0708
Qualys has issued a special QID (91534) for Qualys Vulnerability Management that covers only CVE-2019-0708 across all impacted Operating Systems, including Windows XP and Server 2003. This QID is included in signature version VULNSIGS-2.4.606-3, and requires authenticated scanning or the Qualys Cloud Agent. Cloud Agents will automatically receive this new QID as part of manifest version 2.4.606.3-2.
BlueKeep Unauthenticated check Update:
Qualys has also released a new unauthenticated check to address BlueKeep vulnerability:
QID 91541 : Microsoft Windows Remote Desktop Services Remote Code Execution Vulnerability (BlueKeep) (unauthenticated check)
This QID is included in vulnerability signature version VULNSIGS-2.4.620-x. A Scanner version update (11.2.35) is required to support this new QID. In certain edge cases involving CredSSP, for Windows 7 and above operating systems, this QID may not post as vulnerable, if service is not identified as RDP over port 3389. However, the authenticated check (QID 91534) will post the vulnerability for all affected Operating Systems.
You can search for all vulnerable systems in AssetView or within the VM Dashboard (Beta) by using the following QQL query:
vulnerabilities.vulnerability.cveIds:CVE-2019-0708
Tracking Impact and Remediation
Qualys is providing a downloadable AssetView Dashboard for tracking this vuln across your environment. Visit the Qualys Community to download it now for importing into your subscription.
Remediating with Qualys Patch Management
Customers using Qualys Patch Management with Cloud Agent can search for cve:`CVE-2019-0708` in the Patch Catalog, and click “Missing” in the side panel to locate and deploy patches to all affected Operating Systems, including Windows XP and Server 2003.
For emergency patching, you can create an On-demand Job and target it at the “Cloud Agent” tag to cover all hosts. For continuous patching, a Daily Job can be created with a 24-hour “Patch Window” to ensure all hosts will continue to receive the required patches. This patch does require a reboot.
Targeting specific operating systems is not necessary. The Qualys Cloud Agent already knows which patch is needed for each host.
Get Started Now
To start detecting and remediating this vulnerability now, get a Qualys Suite trial.
Can someone advice for a new fix (Patches) for the below vulnerability :
Microsoft Graphics Component Remote Code Execution Vulnerability (MS15-080)
McAfee Anti-Malware Scan Engine Multiple Vulnerabilities (SB10190)
Microsoft .NET Framework Denial of Service And Information Disclosure Vulnerabilities (MS16-019)
Microsoft .NET Framework Elevation of Privilege and Denial of Service Vulnerability (MS15-101)
Microsoft Windows Remote Desktop Protocol Remote Code Execution Vulnerability (MS15-082)
Microsoft Windows Common Controls Remote Code Execution Vulnerability (MS15-060)
Microsoft Font Drivers Remote Code Execution Vulnerabilities (MS15-044)
Microsoft .NET Framework Elevation of Privilege and Denial Of Service Vulnerability (MS15-048)
Microsoft .Net Framework Remote Code Execution Vulnerability (MS14-057)
Microsoft .NET Framework Elevation of Privileges and Denial of Service Vulnerabilities (MS14-009)
Microsoft .NET Framework and Silverlight Multiple Code Execution Vulnerabilities (MS13-052)
Microsoft .Net Framework Elevation of Privilege Vulnerability (MS13-015)
Some of our systems have RDP explicitly disabled but would still show as vulnerable based on the version check.
Can this QID be updated to check for both the version AND status of the RDP service – TermService
A suggestion is to run ‘sc qc TermService’ from the command line and check for ‘START_TYPE 4 DISABLED’
We post the vuln even if the service is stopped, to be thorough, but you can add “and services:(name:TermService and status:running)” to the AssetView queries to filter those out.
Is there a detection which does not require authentication in the works?
Yes, it’s in the works. Please see this comment on the related Qualys Community thread: https://community.qualys.com/thread/19653-cve-2019-0708#comment-46722
I see you mentioned QID 90788 but that check requires authentication and does not check for the NLA GPO setting just the GUI setting. There is also unauthenticated QID 105501 but it either is for something else or is definitely not working right. Both Tenable and Nmap have unauthenticated NLA checks.
QID 90788 also works without authentication.
For Qualys there is a “Services Detected” section in the report where you can confirm if RDP is running or not.
When will we have an unauthenticated scan for this issue ?
As per Davids comments your competitors can do an unauthenticated NLA check which is better than nothing at this stage. Where is Qualys on this ?
Suricata (and at least one other vendor we deal with) already has a network based signature for the vulnerability being exploited so i think we are overdue in getting an unauthenticated QID for the specific vulnerability.
https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt
We have this. QID 90788 – Microsoft Windows Network Level Authentication Disabled
This is an unauthenticated check that can be used for remote scanning.
Network-based attack detection in an IDS is very different from an active exploit-based vulnerability detection that doesn’t BSOD hosts. We are working on it, and will release it as soon as we can.
Thanks.
Is there any technical reason why the NLA check isn’t an unauthenticated ?
The following free perl script can do it. It would be really nice if the product we pay quite a bit of money for could do the same so we can have all our vulnerability data in the one location.
https://github.com/portcullislabs/rdp-sec-check
QID 90788 works without authentication.
My naïve understanding is this vulnerability – if exploited, can eliminate role based privileges and as a result can be used to access areas which typically require priv access/admin access. Would this still be the case if you are utilizing credentialing (check in/check out) tooling around sensitive zones/sensitive information?
Do privilege access tools (check in check out credentials) help with mitigating the exploit around sensitive data stores?
I added this dashboard but there are some discrepancies between widgets.
First one “by operating system” shows Windows 7 OS twice. But widgets located at the bottom show 0 for all systems.
Our appliances are showing 11.2.34-1 as last version. (Updated today) How can we get the version 11.2.35 in order to run the scans for QID 91541?
From the article: “In certain edge cases involving CredSSP, for Windows 7 and above operating systems, this QID (QID 91541) may not post as vulnerable, if service is not identified as RDP over port 3389. However, the authenticated check (QID 91534) will post the vulnerability for all affected Operating Systems.”
Why does it say Win7 and above if Bluekeep applies to Win7 and below?