In this article, part one of the series, I describe the MultiValuedProperty exploitation primitive, which became fundamental for my further exploitation of Exchange PowerShell. I also present a bypass for Microsoft’s first patch for this vulnerability, accomplished by chaining MultiValuedProperty with the Command class.

Introduction

You might already be familiar with the Exchange ProxyNotShell chain, CVE-2022-41040 and CVE-2022-41082. It allowed any authenticated Exchange user to achieve remote code execution. ProxyNotShell was exploited in the wild before Microsoft released a patch.

I described the ProxyNotShell chain, especially its RCE vector, in this blog post. Before proceeding with this post, please make sure that you are familiar with the original issue, as this article will focus on bypassing the patches.

In this blog post, I would like to start with 2 RCE vulnerabilities:

• ZDI-23-163/ CVE-2023-21529 – abuse of the allowed MultiValuedProperty class.
• ZDI-23-881/ CVE-2023-32031 – bypass for CVE-2023-21529, abuse of not blocked Command class.

Accessing PowerShell Without ProxyShell Path Confusion

The original path confusion vulnerability, CVE-2021-34473, was discovered by Orange Tsai. He used it together with CVE-2021-34523 and CVE-2021-31207 to achieve pre-auth remote code execution, forming the chain known as ProxyShell.

Microsoft’s original patch for the path confusion did not eliminate the root of the problem, but instead placed it behind authentication. After the patch, it was exploited in the wild for post-auth remote code execution using the ProxyNotShell chain mentioned above.

Exploitation of the path confusion allowed a threat actor to reach the Exchange PowerShell backend by sending HTTP requests to the autodiscover endpoint.

After the patch for ProxyNotShell, it appears that this attack vector is completely blocked, though I must admit that I have never fully verified that patch. Nonetheless, a low-privileged attacker still has direct access to Exchange PowerShell Remoting, subject to Kerberos authentication. This is because every Exchange user can trigger some Exchange PowerShell cmdlets, such as Get-Mailbox. Instructions that describe direct interaction with the Exchange PowerShell can be found here.

As Kerberos authentication is required, this attack surface is probably restricted to internal attackers, which is to say, attackers who are already present in the organization’s network. There remains plenty of reason for concern, though. It would not be good if any domain account (and organization member) could escalate to SYSTEM on the Exchange server.

Patch for the ProxyNotShell CVE-2022-41082 RCE

CVE-2022-41082, the RCE part of the ProxyNotShell chain, was fixed with the introduction of the Microsoft.Exchange.Diagnostics.UnitySerializationHolderSurrogateSelector class. It extends SurrogateSelector and its main goal is to validate the types that are retrieved during the deserialization of UnitySerializationHolder. It does this by checking the types against an allow list.

Microsoft’s approach here seems appropriate. An allow list is probably the best way to fight deserialization issues and similar type-based vulnerabilities. However, when the allow list is extensive, it may be possible to find some types there that can be used in exploitation. I decided to take this path and look for potentially dangerous allowed classes.

ZDI-23-162/ CVE-2023-21529 – Allowed MultiValuedProperty Leads to RCE

The Exchange allow lists can be divided into two main parts:
• List of allowed regular types.
• List of allowed generic types.

Generic types seem especially interesting because they allow the inclusion of arbitrary, internal types. Moreover, generic types can be also retrieved through a deserialization of UnitySerializationHolder. Let’s review the list of allowed generics that are defined in the Microsoft.Exchange.Data.SerializationTypeConverter.allowedGenerics member.

The first part of the list is especially interesting because it contains custom Exchange types. It turns out that deserialization involving retrieval of the Microsoft.Exchange.Data.MultiValuedProperty<T> or Microsoft.Exchange.Data.DagNetMultiValuedProperty<T> generic classes can lead to remote code execution.

One may remember that PowerShell Remoting deserialization allows one to call a single-argument constructor of any allowed type (as long as the argument can be also deserialized). This leads us to a consider a single-argument constructor of MultiValuedProperty<T>.

As you can see, it accepts an argument of type object. Thus, the attacker can provide an instance of any allowed PowerShell Remoting deserializable class. This constructor invokes a different constructor that accepts a larger number of arguments.

A great deal of processing occurs after the constructor call. Of primary interest is that we ultimately reach the ValueConvertor.ConvertValue method. Here, the attacker-controlled type is provided as the second argument, while the attacker-controlled object is provided as the first argument. This is the object provided to the MultiValuedProperty constructor.

At [1], it invokes ValueConvertor.TryParseConversion. This call looks particularly interesting because the method name suggests that the Parse method is involved.

At [2], it calls TryConstructorConversion.

Let’s focus on the parse-based conversion now.

At this stage, it is worth to note the values of specific arguments:

• originalValue - value provided by the attacker to the MultiValuedProperty constructor.
• originalType - type of the originalValue.
• resultType - the type parameter (“T”) of the attacker-specified generic MultiValuedProperty<T> type.

At [1], the method checks if originalType is the type string

At [2], it calls ConvertValueFromString. This method is also called during the deserialization process. This method hardcodes several possible conversions and throws NotImplementedException if the conversion from originalType to resultType is not implemented.

At [3], it catches the exception.

At [4], it retrieves the public static Parse method from the attacker-controlled resultType.

At [5], it invokes the Parse method with the attacker-specified value.

To summarize, the MultiValuedProperty<T> generic class implements another way to call the Parse method. This can result in invocation of the XamlReader.Parse(String) method with an attacker-controlled string. In addition, TryConstructorConversion allows one to call a single-argument constructor of a given class.

At this point, one can see that MultiValuedProperty<T> class implements the two most powerful conversions of PowerShell Remoting. Since it is an internal deserialization mechanism, it is included on the allow list. It can be abused by the attacker, for example to call a single-argument constructor of any accessible class. This became a fundamental building block for my subsequent vulnerability research.

As an example of how MultiValuedProperty<T> can be abused, consider the following code:

This line simulates what we achieve via Exchange PowerShell Remoting during exploitation:

• The attacker provides a serialized UnitySerializationHolder object that specifies the allowed MultiValuedProperty<T> type. The type parameter, T, is set to System.Windows.Markup.XamlReader.
• An allow list check is performed on our type: MultiValuedProperty<XamlReader>. The check is successful, because: (1) MultiValuedProperty<T> is present on the allow list, and (2) the type specified in the type parameter, XamlReader, is not subjected to validation at all.
• The MultiValuedProperty constructor instantiates a XamlReader object by calling the static XamlReader.Parse(String) method.
• As the attacker controls the input string, they can provide any XAML deserialization gadget to achieve remote code execution.

The simplified attack scheme is presented in the following diagram.

As we have shown, allow lists are not always secure, and they need to be carefully reviewed. It may turn out that even in a product as mature as Microsoft Exchange, allowed classes may contain functionality that can be abused. This may be especially true for generic classes included in the allow list. The generic (internal) type should always be verified by your type control mechanism. Otherwise, your allowed class may turn out to be abusable. Moreover, class inheritance should also be verified. For example, suppose that Microsoft removed MultiValuedProperty<T> from the allow list. We would still be able to reach it via the allowed type DagNetMultiValuedProperty<T>:

DagNetMultiValuedProperty<T> inherits from MultiValuedProperty<T>. Its single-argument constructor calls the constructor of the base class. Thus, it is another way to trigger the dangerous routine, and it could be abused even if MultiValuedProperty<T> were removed from the allow list.

ZDI-23-881/ CVE-2023-32031 – Bypassing the Internal Deny List with the Command Class

In CVE-2023-21529, I abused the internal deserialization-like mechanism that can be reached through the allow-listed MultiValuedProperty<T> class. When considering potential patches, two approaches present themselves:

1. Remove MultiValuedProperty<T> from the allow list.
2. Implement additional type control in the internal deserialization mechanism within MultiValuedProperty.

MultiValuedProperty is frequently used by the Exchange, thus removing it from an allow list is not an option. Implementing type control in the internal deserialization mechanism defined in ValueConvertor.ConvertValue looks like a good option though. This is what the patch looks like:

You can see that the ChainedSerializationBinder.ValidateResultType method was introduced, to limit the types that the attacker can specify.

Consequently, if the attacker provides the type MultiValuedProperty<XamlReader>, an exception is being thrown, because type XamlReader fails the new validation. Looking deeper into the validation mechanism, though, I found that type validation here is based on a deny list. Instead of implementing a allow list of types that can be used with the MultiValuedProperty, a deny list was used. If you have seen my Hexacon talk about .NET deserialization, you probably know that I love messing with deny lists.

The Exchange deny list is actually pretty good, and it contains dozens of classes. However, it contains almost no internal Exchange classes. My idea was to look for a class, that:

• Is not on the deny list.
• Implements a public and static Parse(String) method that leads to something exploitable, or
• Implements a public constructor that accepts a single argument and leads to something exploitable.

Such a class could be abused when chained with MultiValuedProperty internal deserialization.

The constructor-based deserialization is handled by the previously mentioned TryConstructorConversion method, and it is pretty much the same as the one implemented in PowerShell Remoting.

It didn’t take me long to find the Microsoft.Diagnostics.Runtime.Utilities.Command class:

At [1], the Command(String) constructor calls the Command(String, CommandOptions) constructor.

At [2], a new ProcessStartInfo is instantiated, and both the process name and arguments are retrieved from the attacker's controlled input.

At [3], Process.StartInfo is set to the ProcessStartInfo object from line [2].

At [4], a new process is started.

This class was not included in the deny list, so the following code:

Leads to the execution of cmd.exe /c calc.exe. That’s it. To sum this up, I did the following:

• I used the allow-listed MultiValuedProperty class to reach the internal deserialization mechanism. This mechanism is protected with the deny list of abusable types.
• I delivered the Command class, which is not on the deny list. This allows execution of an arbitrary command.

Demo

I presented the demo for CVE-2023-32031 during my Hexacon 2023 talk about .NET deserialization. It shows the entire exploitation process with the debugger attached.

Summary

In this blog post, I have described both CVE-2023-21529 and CVE-2023-32031. In those vulnerabilities, I abused both the allow-listed and deny-listed classes to achieve RCE on Exchange. That wasn’t the end of my Exchange vulnerability research, though. I still had two additional full-RCE chains that I was able to deliver after the CVE-2023-32031 patch.

In the next blog post, I will provide you with full details on the ZDI-23-1419/CVE-2023-36756 RCE vulnerability. Once again, you can watch my entire OffensiveCon 2024 talk here.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.