Phishing for SYSTEM on Microsoft Exchange (CVE-2020-0688)

Last updated at Tue, 25 Apr 2023 22:30:54 GMT

Update: Sept. 29, 2020

It’s been just under eight months since Microsoft released the patches to address CVE-2020-0688, so we thought it would be a good time to revisit patch deployment to see whether organizations have addressed this particular risk. Unfortunately, as of our study on Sept. 21, 2020, it appears that 61% of the target population (Exchange 2010, 2013, 2016, and 2019) is still vulnerable to exploitation. We strongly urge organizations to update their environments and review the actions described in the Taking action section of this article.

Original post

On Feb. 11, 2020, Microsoft released security updates to address a vulnerability in Microsoft Exchange that would allow an attacker to turn any stolen Exchange user account into a complete system compromise. In many implementations, this could be used to completely compromise the entire Exchange environment (including all email) and potentially all of Active Directory.

We’ve used Project Sonar to perform a global survey of internet-facing Exchange servers, and what we’ve found is very concerning. As of March 24, there were over 350,000 Exchange servers exposing a version of the software that has this vulnerability.

If your organization is using Exchange and you aren’t sure whether it has been updated, we strongly urge you to skip to the Taking Action section immediately.

The global view

On March 24, we used Project Sonar to survey the internet for publicly facing Exchange Outlook Web App (OWA) services. What we found was that at least 357,629 (82.5%) of the 433,464 Exchange servers we observed were known to be vulnerable. We believe that some of the servers we’ve marked as Safe in the graphic below are unpatched. Our remote, unauthenticated check doesn’t provide the version precision we’d need in order to be sure, and our testing found that the related Microsoft update wasn’t always updating the build number, which leads to a degree of uncertainty.

Update 2020.04.07: It has come to our attention that the CVE-2020-0688 update (Rollup 30) for Exchange 2010 does not update the any visible build information to match the version documented in the software update, which is 14.3.496.0. The Exchange Management Shell (EMS) and Exchange Management Console (EMC) still show version 14.3.123.4, which is Service Pack 3 with no rollups. To add to the confusion, the build information from OWA shows 14.3.487.0, which is none of the above.

In light of this, the roughly 35,000 entries for 14.3.487.0 in the graphics below should be considered as likely safe but requiring manual validation. Thanks to "Remy S" for drawing our attention to this in the comments.

The image above is concerning not just because of the number of servers missing the update for CVE-2020-0688, but also because of how many other updates are also missing. There are over 31,000 Exchange 2010 servers that have not been updated since 2012 and nearly 800 Exchange 2010 servers that have never been updated.

In addition to the high number of servers that are missing multiple updates, there is a concerning number of Exchange 2007 and 2010 servers. Exchange 2007 transitioned to End of Support (EoS) status nearly three years ago on April 11, 2017. No security updates, bug fixes, timezone updates, etc., are provided after that date. Exchange 2007 does not have the vulnerability described by CVE-2020-0688, but if it did, it would not have been fixed.

Exchange 2010 will reach EoS on Oct. 13, 2020. It was originally planned to go EoS on Jan. 14, 2020. Had that been the case, there is a very real possibility that Microsoft would not have created an update for it. There are over 166,000 of these servers connected to the internet. That’s a staggering number of enterprise-class mail systems that will be unsupported in a few months.

Taking action

There are two important efforts that Exchange Administrators and infosec teams need to undertake: verifying deployment of the update and checking for signs of compromise.

Update Exchange

The most important step is to determine whether Exchange has been updated. The update for CVE-2020-0688 needs to be installed on any server with the Exchange Control Panel (ECP) enabled. This will typically be servers with the Client Access Server (CAS) role, which is where your users would access the Outlook Web App (OWA).

The most reliable method to determine whether the update is installed is by checking patch management software, vulnerability management tools, or the hosts themselves to determine whether the appropriate update has been installed. Note that these tools will likely not indicate that the update is missing if the Exchange Server isn't running a current version of the Exchange Cumulative Update or Rollup. These servers are still vulnerable. You can find the list of updates in the Microsoft advisory for CVE-2020-0688 here.

There are alternative methods for determining which version of software is installed, but you need to keep in mind that they either don’t provide the full build number or, as in the case of the PowerShell command and Exchange Admin Center, do not update the build number to reflect the correct build, as shown on the update download page.

Update 2020.04.07: For Exchange 2010, the build numbers shown in the Exchange Management Shell (EMS) and Exchange Management Console (EMC) cannot be trusted to show any updated build versions after Service Pack 3.

For those with sufficient access, you can get a listing of Exchange servers, their version, and whether they are CAS by running the following command in the Exchange Management Shell:

Get-ExchangeServer | select name,admindisplayversion,isClientAccessServer | ft

For those users without access rights, you can check the version of Exchange by accessing Outlook Web App and viewing the page source prior to logging in. The build number will be included in the links to many resources.

The following Exchange versions may be safe. Microsoft isn’t consistently updating the build number as part of the update installation process. Anything newer is probably patched.

Any version matching those listed below or that are older than those listed below are definitely vulnerable.

Check for compromise

You should also determine whether anyone has attempted to exploit this vulnerability in your environment. Since exploitation requires a valid Exchange user account, any account tied to these attempts should be treated as compromised.

The exploit code that we tested with left log artifacts in the Windows Event Log and the IIS logs on both patched and unpatched servers. The exploit attempts show up in the Windows Application event log with source MSExchange Control Panel, level Error, and event ID 4. This log entry will include the compromised user account, as well as a very long error message that includes the text Invalid viewstate. What you are seeing is portions of the encoded payload.

You can also review your IIS logs for requests to a path under /ecp (usually /ecp/default.aspx), which contain the string __VIEWSTATE and __VIEWSTATEGENERATOR. The long string in the middle of this request, as in the case of the Windows event log above, is a portion of the exploit payload. You will see the username of the compromised account name at the end of the log entry. A quick review of the log entries just prior to the exploit attempt should show successful requests (HTTP code 200) to web pages under /owa and then under /ecp.

Any user accounts seen in these exploitation attempts should be considered compromised.

Rapid7 coverage

InsightVM supports detection of the missing update when performing a credentialed scan. You can search your scan results for CVE-2020-0688 or the check name of msft-cve-2020-0688.

Metasploit Framework and Metasploit Pro support exploitation and vulnerability validation via the exchange_ecp_viewstate module.