Share with Your Network
Last month, we analyzed progress versus the widely publicized ECC encryption vulnerability CVE-2020-0661 that was released in the January Microsoft Patch Tuesday announcement. This month, we look at the patching behavior of another vulnerability, CVE-2020-0688 from the February batch. From the analysis of last month, it was clear that security teams were making remediation of the vulnerability a priority, with approximately 60% remediated within a month, well ahead of the norm.
The CVE-2020-0688 vulnerability, a static cryptographic key in Microsoft Exchange Server’s on-by-default ECP control panel, is now being exploited in the wild by threat actors. Similar to the ECC vulnerability, both US-CERT and the NSA issued guidance urging teams to patch this vulnerability quickly. Just today, the MS-ISAC issued an advisory urging action in light of active exploitation in the wild. We currently have the vulnerability scored to the highest Kenna score: 100.
Some Background About the CVE-2020-0688 Vulnerability
On February 11, Microsoft announced a severe vulnerability in Microsoft Exchange Server as part of its monthly Patch Tuesday release. Initially, Microsoft labeled this a memory corruption vulnerability in Microsoft Exchange. But they later clarified that this is a static cryptographic key in an application running by default and exposed via :443 on Exchange servers.
This is not the first example of this kind of vulnerability, though it’s certainly one of the most high profile. IoT devices are commonly (and accidentally) shipped with a key, but it’s rare for software of this profile to have this kind of vulnerability. This post will not discuss the vulnerability specifics in depth, it’s been covered by others. The Trend Micro Zero Day initiative’s (ZDI) detailed description of the vulnerability on Feb 24th that summarizes it nicely:
The nature of the bug is quite simple. Instead of having randomly-generated keys on a per-installation basis, all installations of Microsoft Exchange Server have the same validationKey and decryptionKey values in web.config. These keys are used to provide security for ViewState. ViewState is server-side data that ASP.NET web applications store in serialized format on the client. The client provides this data back to the server via the __VIEWSTATE request parameter.
Exploitation is quite simple as well, given that the vulnerable component, Exchange Control Panel (ECP) is on by default. A single valid credential – including those with no significant privileges – is required to exploit the vulnerability
An exploit is available in Metasploit. The vulnerability is actively being exploited in the wild, as reported by Volexity on March 6. If your organization has not yet patched, you’re going to want to patch or disable ECP as quickly as possible. Check the server for IoCs, and, if you suspect it’s compromised, reset all passwords for your users. A compromise of your Exchange server is effectively a compromise of your Active Directory.
How Remediation Teams Are Progressing With Patching CVE-2020-0688
In order to understand how remediation teams were doing against this critical vulnerability, we pulled a representative sample of remediation data, giving us the rate of open vs closed instances of the vulnerability. This was not encouraging. The vulnerability is currently less than 15% remediated.
Given that we’re about a month out from the original announcement, we should be closer to 50%, according to the norm for Microsoft-sourced vulnerabilities as reported in the Prioritization to Prediction v3 report. Unfortunately, that’s simply not the case here.
Perhaps these servers aren’t directly exposed to the internet. Or, maybe users have worked around and disabled ECP. Or, perhaps they operate on an email domain that doesn’t have as much exposure to phishing or other credential leaks.
So, given the risk of this vulnerability, we decided to take a deeper look. Working with the team at BinaryEdge – who were kind enough to assist with an export of all internet facing Outlook Web Access (OWA) servers in their Internet-wide scan data – we collected 220,000 publicly exposed OWA servers – presumably everything on the Internet.
Since we wanted the underlying Exchange server, and knowing that OWA exposes the build number, we fired up Intrigue Ident, an open source fingerprinting library that accurately infers Microsoft Exchange versions from OWA. Approximately eight hours later, we received the following result:
As evidenced by this data, and as might be expected due to the unique nature of Exchange servers as a crucial hard-to-patch and hard-to-upgrade system, the installed versions are all over the place. Breaking it down by base version, you can see the bulk of the installs are 2016 versions.
How many of these are vulnerable? Using the inferred information – we can’t be 100% accurate since there’s no clear indicator that the patch was applied. But, based on the underlying version, we can label as either “vulnerable” or “potentially vulnerable. ”After doing this labeling, we got the result: 74% vulnerable and 26% potentially vulnerable. This falls in line with the first analysis and is not particularly encouraging.
The bottom line on CVE-2020-0688
In most Microsoft-centric organizations, Exchange is a critical organization service, and thus, may be off-limits for normal monthly patching schedules. This fact, combined with the fact that the vulnerability exposes SYSTEM access on the server, and the fact that exchange stores credentials in memory in plain text, make this an incredibly attractive target.
Yes, this vulnerability requires a first credential, but if you do some quick searching in one of the breach databases like Dehashed or Spycloud, you’ll quickly see this isn’t a barrier at all. It’s reasonable to assume that there’s at least one working credential for any given enterprise available with minimal effort at any given time.
Attackers are effectively one weak or leaked user password away from complete access to your organization. When combined with the external facing nature of OWA and the ECP – on by default in Exchange, this is likely to be one of the most devastating vulnerabilities of 2020.
So what can you do?
Drop everything and patch CVE-2020-0688 immediately. At present, this vulnerability presents more risk than most other vulnerabilities in the enterprise environment. If patching simply isn’t possible, block access to ECP. Ultimately, vulnerabilities like these make a strong case for upgrading to Office 365.
Looking for a better way to remediate? Risk-based vulnerability management is your answer. Get a demo today.
