Phishing for SYSTEM on Microsoft Exchange (CVE-2020-0688)
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.
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. There are nearly 800 Exchange 2010 servers that have never been updated.
In addition to the high numbers 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. Had this vulnerability affected Exchange 2007, 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 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. You can find the list of updates in the Microsoft advisory for CVE-2020-0688.
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.
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.
| Exchange Release | Build Number |
|---|---|
| Microsoft Exchange Server 2019 Cumulative Update 4 + hotfix | 15.2.529.xxx |
| Microsoft Exchange Server 2019 Cumulative Update 3 + hotfix | 15.2.464.xxx |
| Microsoft Exchange Server 2016 Cumulative Update 16 + hotfix | 15.1.1979.xxx |
| Microsoft Exchange Server 2016 Cumulative Update 15 + hotfix | 15.1.1913.xxx |
| Microsoft Exchange Server 2016 Cumulative Update 14 + hotfix | 15.1.1847.xxx |
| Microsoft Exchange Server 2013 Cumulative Update 23 + hotfix | 15.0.1497.xxx |
| Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 30 | 14.3.496.xxx |
Any version matching those listed below or that are older than those listed below are definately vulnerable.
| Exchange Release | Build Number |
|---|---|
| Microsoft Exchange Server 2019 Cumulative Update 2 | 15.2.397.3 |
| Microsoft Exchange Server 2016 Cumulative Update 14 | 15.1.1779.2 |
| Microsoft Exchange Server 2013 Cumulative Update 22 | 15.0.1473.3 |
| Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 29 | 14.3.487.0 |
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.
