CVE-2021-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability
June 02, 2021 | The ZDI Research TeamIn May of 2021, Microsoft released a patch to correct CVE-2021-31181 – a remote code execution bug in the supported versions of Microsoft SharePoint Server. This bug was reported to the ZDI program by an anonymous researcher and is also known as ZDI-21-573. This blog takes a deeper look at the root cause of this vulnerability.
Before this patch being made available, this vulnerability could be used by an authenticated user to execute arbitrary code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker must have SPBasePermissions.ManageLists permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permission.
The Vulnerability
This attack is possible due to insufficient validation of user input in the EditingPageParser.VerifyControlOnSafeList() method. This method verifies user input against a list of unsafe controls and should raise an exception if any control is not marked as safe by the SafeControl elements as specified in web.config.
A good example of an unsafe control that is forbidden by SharePoint is System.Web.UI.WebControls.XmlDataSource. This control is dangerous because it would allow an attacker to get information from an arbitrary XML file on the server. As we will see, this could be used not only for information disclosure but even for code execution.
We can see that it is marked as unsafe via a SafeControl element in web.config:
Because of this, an attacker should not be able to instantiate this control. However, we will see how we can bypass verification in EditingPageParser.VerifyControlOnSafeList().
EditingPageParser.ParseStringInternal() parses user input (dscXml) and populates hashtable with information from Register directives and hashtable2 with values from tags that represent server controls. In the next step, it tries to create a Type object for each element from hashtable2 and checks it against an allowed list of SafeControls. However, it will ignore the tag of the server control if the Type cannot be resolved. Normally, this would not create a hazard. If a Type cannot be resolved at the verification stage, then it should similarly fail to resolve later during the actual processing of markup. However, an inconsistency between the code in EditingPageParser and TemplateParser breaks this assumption.
Let’s look closer at how the values in hashtable are populated, and let’s pay attention to the namespace attribute of the Register directive:
The value of the namespace attribute will be stored in triplet.First. Let’s suppose that we have Namespace="System.Web.UI.WebControls " (note the trailing space) in our Register directive, and a tag named XmlDataSource. As you can see, there are no Trim() calls for the namespace attribute. Due to the trailing space, VerifyControlOnSafeList will not be able to resolve the Type System.Web.UI.WebControls .XmlDataSource and consequently it will not be blocked. Later, though, during actual processing of the Register directive, the following code executes:
At this stage, the Namespace will be trimmed and a Type for System.Web.UI.WebControls.XmlDataSource will be successfully resolved. This means the unsafe control will be processed by the server.
For our attack, we will use the WebPartPagesWebService.RenderWebPartForEdit webapi method. It is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It takes ASPX markup as an input, verifies it using EditingPageParser.VerifyControlOnSafeList, and, if there are no unsafe elements, processes the markup in Design mode. The resulting HTML will be returned to the web client.
We will use the WebPart Microsoft.SharePoint.WebPartPage.XsltListFormWebPart with our unsafe XmlDataSource, specifying a simple XSL transformation to copy the result verbatim to our output. In this way we can obtain the contents of an arbitrary XML file from the server. We choose to disclose the contents of web.config. This will provide us with the validation key needed to forge a VIEWSTATE parameter, providing a path to remote code execution.
To proceed, we will also need to provide the Title of any existing SPList from the current site, as well as the site’s webID. These can be obtained easily. We will see how to do this in the PoC section.
Here is an example of a RenderWebPartForEdit request:
We can use the machinekey section from web.config to create a valid VIEWSTATE parameter that causes an arbitrary OS command to be executed when the ViewState is deserialized on the server.
Proof of Concept
For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter.
The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to January 2021 Patch (Version 16.0.10370.20001) and a couple of users have been added, including “user2” as a regular, unprivileged user.
On the attacker side, we need any supported Web Browser, our PoC application for sending SOAP requests to the server, and the ysoserial.net tool. For this demonstration, we are using Firefox as our browser.
Getting Remote Code Execution
Let’s begin by visiting our SharePoint Server and authenticating as “user2”.
Let’s create a site so that we will be the owner and have all permissions.
Click on “SharePoint” on the top panel:
Now click the “+ Create Site” link:
Choose Team Site.
Choose a name for the new site. In this example, it is ts01.
Click “Finish” and the new site will be created:
Now let’s get the webId for the site. This can be done with a request to /_api/web/id :
In this example, it is 6e7040c8-0338-4448-914d-a7061e0fc347.
We also need the title of any existing SPlist in the current site. The “Documents” SPlist is available on most sites, but we can use any item from the /_layouts/15/viewlsts.aspx page:
Now we use our PoC to send a request to the server. We need to provide the base URL for our site, valid user credentials, the title of an SPList, and the webId. In our case:
>PoC.exe http://sp2019/sites/ts01/ user2 P@ssw0rd contoso "Documents" "{6e7040c8-0338-4448-914d-a7061e0fc347}"
If this step successful, we will get the machineKey section of web.config:
For our RCE attack, we need the value of validationKey. In this example it is:
validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”
We can also see the algorithm: validation="HMACSHA256"
Using this information, we can proceed to get remote code execution. Before the actual attack, let’s go to the target SharePoint Server and open C:\windows\temp folder:
Note that there is no PoC_SPRCE01.txt file yet.
Now let’s go back to the attacker machine. We need to collect one more piece of information, which is the value of __VIEWSTATEGENERATOR. We can get this by browsing to the success.aspx page on our site. In this example, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:
Viewing the source code, we can find the value of __VIEWSTATEGENERATOR:
In this example it is AF878507.
In summary, the values needed to forge a VIEWSTATE are as follows:
__VIEWSTATEGENERATOR=AF878507
validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79
validationAlg=HMACSHA256
We provide these values on the command line of ysoserial, as follows:
>ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo RCE > c:/windows/temp/PoC_SPRCE01.txt" --generator="AF878507" --validationkey="FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79" --validationalg="HMACSHA256" --islegacy --minify
The result is a valid VIEWSTATE.
We need to URL-encode this ViewState and send it as a __VIEWSTATE parameter to our server. For example, this can be done by composing a URL with a __VIEWSTATE query string parameter, as follows:
Browsing to this URL, an error page is returned.
However, when we check the C:\Windows\temp folder on the SharePoint server:
Our target file was successfully created, demonstrating that we achieved code execution. In the same way, an attacker can execute any OS command in the context of the SharePoint web application.
Conclusion
Microsoft patched this in May and assigned identifier CVE-2021-31181, with a CVSS score of 8.8. SharePoint continues to be an attractive target for researchers and attackers alike, and several SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.
Until then, follow the team for the latest in exploit techniques and security patches.