Why the Response to DejaBlue Must Be Better than the Response to BlueKeep

By Paul Gagliardi

Posted on Aug 22, 2019

Last week, just three months after Microsoft publicly acknowledged and released a patch to address its BlueKeep vulnerability, the company released more patches to address seven other similar vulnerabilities that affect all versions of Windows.

Those new patches came with a message from the company: install these updates immediately

The danger is that IT teams, suffering from patch fatigue, or “DejaBlue,” won’t install the patch quickly enough or at all. 

Despite Microsoft’s patches, SecurityScorecard sees roughly 8 million instances of exposed Remote Desktop Protocol (RDP) on the public internet every day.

BlueKeep and its fellow CVEs: A quick overview

BlueKeep is the public nickname of CVE-2019-0708, an exploitable vulnerability in Microsoft’s RDP. This vulnerability — which affects Windows 2000 through Windows Server 2008, including Windows XP, Windows Vista and Windows 7 — allows for remote code execution (RCE) without any human interaction. 

Microsoft’s concern was that malware might use BlueKeep to create a worm, propagating from “vulnerable computer to vulnerable computer in a similar way as the WannaCry malware spread across the globe in 2017.”

The newest patches confirm that BlueKeep wasn’t a standalone problem — it has siblings. Two of the vulnerabilities, CVE-2019-1181 and 1182, pose the exact same risk as BlueKeep, in fact. These, however, affect every version of Windows and may be easier to exploit, so even users of the most recent version of Windows will have to act fast to limit risk. 

The other five CVEs: CVE-2019-1222, 1223, 1224, 1225, and 1226 aren’t “wormable," according to Microsoft, but they are all related to Remote Desktop Services and Remote Desktop Protocol, which means they expose Windows users to the risk of information disclosure, denial of service, and remote code execution. 

The attention around BlueKeep is likely the reason we know about the new CVEs — Microsoft’s  security teams probably did an internal audit of their RDP and RDS (Remote Desktop Services) code bases. 

Hopefully that audit was exhaustive, because for offensive-oriented reverse engineers, and vulnerability analysts, the RDP/RDS piece of the Windows system now has a bullseye on it. Cybercriminals may also be looking for similar programming or design flaws.

It’s DejaBlue all over again

Unfortunately, many IT teams probably won’t patch as quickly as they should. SecurityScorecard studied the original response to BlueKeep. We found the response from affected organizations and industries to be lacking. 

Our researchers began by identifying all machines across the public internet that were exposing RDP. We then scanned nearly 8 million machines a day to identify the machines that were vulnerable to BlueKeep. We found that only 1% of vulnerable machines were patched each day, and the number diminished as time went on. Many industries, like financial services, patched several machines the first day, with numbers falling off over time. 

This time, there’s an added hurdle: some system administrators or IT staff may be suffering from "alert" or "patch fatigue" after the alarms of BlueKeep earlier this year, and may be even slower to patch. 

This is a problem. It has been reported that the newest exploit code may be easier to implement than the original BlueKeep; this usually has to do with the technical logistics of the exploit, the state of system of memory, and what parts of a system crash during a non successful exploit. 

A bad actor may be able to exploit these new vulnerabilities, eventually making them public, and that’s where the real damage can occur. 

What can you do?

So what can IT teams do? The most important thing is to pay attention to Microsoft’s warnings and install the patches as quickly as possible. We expect this will look like May all over again; we’ll see another race of patching before exploits and attacks are publicly available and widely used.

Our recommendations:

  • Remain calm!
  • Disable RDS/RDP entirely on any public internet facing Windows machines
  • Consider the risk of enabling those services on private networks
  • Enable NLA (Network Level Authentication) if accepting that above risk
  • Ensure that machine is using the latest version of Windows and is regularly patched
  • Consider additional security and data protection on machines where RDS/RDP must be enabled

We recommend that Windows machines with RDP and RDS enabled not be exposed on the public internet in the first place, but kept behind a firewall or a VPN. Even in private networks, machines with RDP/RDS should also have Network Level Authentication enabled. 

SecurityScorecard can also help with awareness. Our platform notifies users about their specific Windows risks; we alert our users to patching cadence findings specific to Windows, and to publicly exposed RDP and SMB services, which users can find under Network Security.

The good news is that the fix is fairly simple: IT teams simply need to be aware of the vulnerabilities, install Microsoft’s patches, and follow good security practices.

Security Research in your Inbox

Thanks for siging up for the newsletter!

No waiting, 100% Free

Get your personalized scorecard today

Get your free scorecard and learn how you stack up across 10 risk categories. Answer a few simple questions and we'll instantly send your score to your business email.

Get Your Free Score

Get In Touch

Thank you for contacting us!