Keeping Score on BlueKeep

September 18, 2019 Jonathan Cran

Vulnerability management – the act of patching and mitigating avenues for security breaches in IT systems – overwhelms most organizations. Most security teams end each day with more vulnerabilities than they started with. Organizations need to pick and choose their battles, deciding which vulnerabilities to patch and which can be left untouched. This is a challenge of information, and there’s a lot of noise around various threats, making these decisions difficult.

So, when BlueKeep, one of the most significant and well-known vulnerabilities of 2019 affected the commonly used Microsoft Remote Desktop Protocol (RDP), many in the industry were happy to receive ample warning of the danger before it was exploited in the wild. 

This is how it’s supposed to work.

Not every vulnerability garners the attention of a BlueKeep, but it is a prime example of how a vulnerability and its risk score evolve over time. While we may not have the benefit of an NSA public service announcement for every vulnerability, it is possible to stay informed at a similarly high level, no matter the vulnerability.  

Officially known as CVE-2019-0708, BlueKeep was announced May 15. We shared concerns with the broader community that it would be quickly weaponized. There were a few reports that this vulnerability was already being used underground. This was accentuated shortly after the announcement by a tweet from the CEO of Zerodium, the leading gray market exploit broker.

The potential impact of a BlueKeep-level flaw was obvious, in part because RDP has long been considered a relatively safe protocol to expose to the outside world and thus it was particularly widespread. The last major fire drill around RDP occurred in 2017, when the ShadowBrokers leak gave us the EsteemAudit exploit – targeting CVE-2017-9073. This vulnerability targeted older systems, and thus many still exposed RDP directly to the Internet.

Researchers quickly analyzed the vulnerability and released tools to detect it, resulting in increased attention. Initial numbers suggested nearly one million exposed systems on the internet (with an untold number exposed internally). There were a number of posts indicating that it affected major organizations. It was, indeed, something to pay attention to. 

So how does all of this attention affect our scoring? Let’s dive into it.

Upon initial ingestion into Kenna’s Reference Data Service on May 15, the vulnerability’s score – like many other vulnerabilities with limited context and intelligence – stayed low, at 36.06. Most vulnerabilities will come in around a 25 at this stage. The higher score was based on several objective variables, including CVSS and the fact that RDP is widely prevalent. Even though multiple three-letter government agencies had issued warnings, there was no proof of malicious use at this point and so the score remained low in the beginning. 

On the next run, Kenna’s prediction algorithm weighed in. Low information situations can be tough, but it’s an area of strength for machine learning when historical data tied to an outcome is available. This is what Kenna’s algorithm does. By analyzing the corpus of vulnerability information from the last three years, and by including the prevalence of the vulnerability, the dominant model suggested that this vulnerability would have a public exploit released at some point, causing the score to rise from 36 to 54 on May 17, two days after the initial announcement. 

Over the next few weeks, more information about the vulnerability was ingested, and the risk score for this CVE rapidly increased, reaching a 93 on May 26, 11 days after the initial announcement. It’s rare to see a vulnerability increase this quickly, especially one without a weaponized exploit or with exploitation in the wild. There was not yet a weaponized exploit available, but the high risk score could be attributed to the following factors:

  • High Severity (as described in CVSS)
  • Vulnerability Prevalence
  • Early Crash-case PoC Exploits
  • Prediction of exploitation in the wild  

On July 31 as reports of active (albeit, only triggering Denial of Service) exploitation in the wild started to flow in, the vulnerability was given the highest risk score possible. For reference, only 0.2% of CVEs have a score of 100 in the Kenna Security Platform.

On September 6, the prediction of public RCE exploit was realized when researchers published an exploit module in Metasploit. An exploit arriving in Metasploit is one of the greatest indicators that a vulnerability will be utilized in the wild. However these are not the same thing. We track the difference between exploit existence and detected exploit usage in the wild. Typically, usage in the wild is the variable that sends a vulnerability to the top score.

Looking at the current remediation data for BlueKeep over the last four months, it appears that security teams patched many of systems and/or took steps to mitigate the risk before the release of the Metasploit module. The data paints a positive picture of remediation activity — almost 84% remediated. Most of this activity occurred in the first two months, with the remediation rate leveling since July.

Although most systems have been patched, there are still many organizations, some at the Fortune 500 level, that remain vulnerable on their external perimeter. Even more unattributed cloud systems remain in a vulnerable and exposed state. That said, the numbers are moving in the right direction with Shodan reporting just over 65,000 in the US this week, down from 70,000 last week. Visibility and patching remain an ongoing challenge but exposure management appears to be getting better. And while getting to 100% internally shouldn’t be the goal for an organization’s entire network, it should be for assets that sit on the perimeter.

So four months in, overall, I think we’re doing pretty well, and honestly, better than I expected back in May. I’m hopeful that BlueKeep can become a textbook case for how vulnerability management should work. Not every instance of a vulnerability can be remediated, and the typical organization can patch just one in ten vulnerabilities. With numbers like those, it puts incredible pressure on companies to predict which vulnerabilities are most risky and need to be addressed immediately. While BlueKeep was – and remains – an obvious patch decision, many vulnerabilities are not. Advanced information and predictive intelligence can help security professionals fill the gap and inform decisions about what to prioritize to stay one step ahead of today’s threats.

Reference Timeline: 

The post Keeping Score on BlueKeep appeared first on Kenna Security.

Previous Article
Poised for Growth: Kenna Security Announces Series D Funding
Poised for Growth: Kenna Security Announces Series D Funding

Right now is an exciting time for Kenna Security. We are in an unprecedented time of growth, change, and ac...

Next Article
Kenna Security and VMware Collaborate to Empower IT to Mitigate Vulnerability Risk
Kenna Security and VMware Collaborate to Empower IT to Mitigate Vulnerability Risk

Keeping the company secure has historically been the security organization’s job, but the reality of the th...