In part 2, I describe the ApprovedApplicationCollection gadget, which was available for abuse because it did not appear on the deny list and could therefore be accessed via MultiValuedProperty. I am also presenting a path traversal in the Windows utility extrac32.exe, which allowed me to complete the chain for a full RCE in Exchange. For the moment, at least, Microsoft has made a decision not to fix this path traversal bug.
You can watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 18:10 to 21:10.
Introduction
In the previous post, I described two RCE vulnerabilities, CVE-2023-21529 and CVE-2023-32031. In this post, I present the next RCE that found in Microsoft Exchange. It consists of a chain of two vulnerabilities:
• CVE-2023-36756 – a vulnerability in Exchange Server.• ZDI-CAN-21499 – an unpatched path traversal vulnerability in the Windows utility extrac32.exe.
Microsoft decided that ZDI-CAN-21499 would not be fixed as “Windows customers are not exposed to this vulnerability.” They also note that, in their view, “It is the caller’s (the application using extrac32) responsibility to make sure extrac32 is not called on untrusted CAB files.” As we will see in this article, though, the extrac32 issue can be used to an attacker’s advantage.
The Patch for CVE-2023-32031
While Microsoft was dealing with the ProxyNotShell chain back in 2022, I took some time to look for different classes that could be abused to exploit PowerShell Remoting for some security impact, such as RCE, file disclosure, denial of service, or NTLM relaying. I found around 30 unique classes and reported them to Microsoft.
Those submissions were marked as duplicates and were ignored, which in my opinion was a mistake. The initial patch for the ProxyNotShell included an allow list, so it seems that the deficiencies in the separate deny list did not attract the attention it should. The problem became evident later when I discovered the vulnerable MultiValuedProperty class (CVE-2023-21529). This class was present on the allow list, and it allowed me to access a separate, internal deserialization mechanism not subject to the allow list sanitation. Even after the internal MultiValuedProperty deserialization mechanism was hardened by means of the deny list, I was able to easily abuse the classes that I had reported many months before, as they had not been added to the deny list. For example, I was able to use the Command class, as I described in the previous post. I had originally reported this class to Microsoft in September 2022, but I was able to reuse this class for CVE-2023-32031 almost seven months later because it did not appear on the deny list introduced in the patch for MultiValuedProperty.
To patch CVE-2023-32031, Microsoft expanded the deny list to include all the classes that I had previously in 2022. The patch went no further than that. Critically, it still did not introduce an allow list, so it was game on. All I had to do was find another class with security impact not included in the deny list, and then I could use MultiValuedProperty to deserialize it. This became my next challenge
CVE-2023-36756 – ApprovedApplicationCollection
I was looking for classes where something potentially malicious could be reached either through a single-argument constructor or a static Parse(String) method. This approach led me to the Microsoft.Exchange.Data.Directory.SystemConfiguration.ApprovedApplicationCollection class.