Microsoft Exchange Server Remote Code Execution

Introduction

This is possible because all Exchange servers use the same static key to encrypt/decrypt ViewState. Attackers can specify arbitrary values for the ViewState and leverage an insecure deserialization vulnerability to execute commands.

Why is this really bad?

The only thing you need to exploit the vulnerability is a valid username and password for an account with a mailbox on the on-prem Exchange. If you only have on-prem Exchange (no Office 365), then all your user accounts can be used; the attacker only needs one. This can be obtained with password spraying, or phishing.

Even in hybrid environments, there are often old shared mailboxes still laying around on the on-prem Exchange, with simple passwords.

There are open source tools that, given a target organization name, scrape LinkedIn and other social media sites to build a list of valid users, then start hammering the Exchange server with logon attempts.

It’s also extremely easy to buy stolen/phished credentials on the dark web, and the amount of self-spreading phishing campaigns is extremely high these days (we get multiple incident response calls every day related to compromised mailboxes…).

All of this, combined with the fact that Exchange servers are usually Internet-facing, is devastating.

Imagine the threat actor takes over the Exchange server. What’s next? Dumping credentials, of course. You run Mimikatz on the Exchange server and you end up with the credentials of all authenticated users syncing their mailbox. Most likely some of these users are admins to at least some servers. And from Exchange, you can probably reach some of those internal servers. Well… I don’t think I need to continue explaining at this point. They will be domain admin pretty soon.

Additionally, there are often direct ways to escalate from the Exchange computer account to domain admin.

How does the exploit work?

To exploit the vulnerability, the attacker needs to:

• Logon with a valid account
• Grab the value of the session ID (ASP.NET_SessionId)
• Grab the value of the ViewState generator (__VIEWSTATEGENERATOR)
• Use the collected values, together with the known static encryption key, to create a payload exploiting the insecure deserialization in ViewState. For example, use YSoSerial.Net.
• Send the malicious ViewState to the server

The video below demonstrates the exploit.

The patch

The patch from February 11, 2020, fixes the problem by configuring the application to use auto-generated keys.

This is the configuration before the patch:

Figure 1 – Machine key configuration before patch

And this is how it looks like after the patch is installed:

Figure 2 – Machine key configuration after patch

Running the same exploit after the patch is installed will fail.

However, there is a small twist. By doing a thorough analysis of the different keys before and after the patch was installed, we noticed that not all keys are refreshed.

This is a dump of the keys under the ECP application before the patch:

Figure 3 – Keys before patch

And this is after the patch:

Figure 4 – Keys after patch

Although unique per installation, the keys used for ASP.NET 4.0 and below are not regenerated with the patch. Testing on a Windows Server 2019 with Exchange Server 2019 CU4, these are the keys used by the application after the patch is applied.

Figure 5 – Application pools

If an attacker has dumped these keys, the deserialization vulnerability can be re-exploited even after the patch has been installed. This would be a sneaky way to maintain access after the patch.

The re-exploitation of a fully patched system using the previously extracted keys is demonstrated in our video below.

Demo

This video demonstrates exploiting the vulnerability using a valid low-privileged user to obtain a reverse shell running with SYSTEM privileges and extract all application keys. We then proceed to install the patch. After patching, we re-exploit the vulnerability using one of the previously extracted keys.

This video demonstrates exploiting the vulnerability using a valid low-privileged user to obtain a reverse shell running with SYSTEM privileges and extract all application keys.

What do to next

1. Patch ASAP!
2. Check if you were breached
   1. IIS logs
   2. Exchange application logs
   3. Windows Event Logs
   4. Process creation logs
3. Conduct a thorough investigation, and keep in mind that old keys can be reused after patching!
4. If unsure, reinstall.
5. If you revert to a backup of the application, keep in mind that web.config.backup holds the old static key!
6. If you made any changes to the default configuration, make sure that the old static key is not used anywhere after the patch.

Want to learn more?

Fabio is speaking at Truesecs' upcoming two-day event Cyber Security Summit 2020. A great time to ask him more questions about this or other findings!