CVE-2020-1181: SharePoint Remote Code Execution Through Web Parts
June 17, 2020 | The ZDI Research TeamLast week, Microsoft released a patch to correct CVE-2020-1181 – 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 as is also known as ZDI-20-694. This blog takes a deeper look at the root cause of this vulnerability.
Before this patch being made available, SharePoint Server allowed an authenticated user to execute arbitrary .NET code on the server in the context and permissions of the service account of the SharePoint Web Application. For an attack to succeed, the attacker should have Add and Customize Pages permissions on the SharePoint site. However, the default configuration of SharePoint allows authenticated users to create sites. When they do, the user will be the owner of this site and will have all the necessary permissions.
High-Level Description of The Vulnerability
Microsoft SharePoint Server allows users to create web pages, but to prevent abuse, it places strict limits on what components can appear on those pages. The SharePoint server treats its “own” pages and user-defined pages in different ways. SharePoint’s “own” pages are stored on the file system and are excluded from all restrictions. User pages are stored in a database and are subject to restrictions. Some of these restrictions include the inability to use code blocks or include files from the file system. They typically can use only allowed web controls from a predefined list.
If a user creates a new page via upload, it will be restricted as usual. However, if the new page is instead created by going through the SharePoint web editor, it will be considered as “ghosted” and will be treated as a trusted source. This makes sense, because the SharePoint web editor places restrictions on what components can be added to a page, so the page can be run safely in unrestricted mode.
The vulnerability occurs because one type of Web Part permitted by the editor is a type called WikiContentWebpart, and this Web Part allows inclusion of arbitrary ASP.NET markup. This provides a route for an attacker to have arbitrary ASP.NET markup run in unrestricted mode, leading to remote code execution.
Examining the Vulnerable Code
SharePoint uses SPPageParserFilter to block all dangerous content. Let’s review how SPPageParserFilter is initialized:
If we created our page by using the SharePoint Web Editor, it will have IsGhosted = true and _isAppWeb will be set to false.
Note that there is an additional check to ensure there is no dependency file with a lower trust level:
However, we have not added any such file, so we should be good here and pass this check. As a result, GetEffectivePageParserSettings() will return PageParserSettings.GhostedPageDefaultSettings:
As a result, our page will have compilationmode=Always, allowServerSideScript=true and allowUnsafeControls=true.
Now let’s take a closer look at WikiContentWebpart:
This means content from its parameters (Directive and Content) will be parsed by ParseControl(text2, false). The second parameter (false) will force the use of PageParserFilter, but it will be used with PageParserSettings.GhostedPageDefaultSettings.
Because the ParseControl() method never causes compilation, we cannot specify .NET code directly. However, we can use dangerous controls from within SharePoint to invoke arbitrary methods and get code execution. Here’s an example of a configuration of WikiContentWebpart that will run an arbitrary OS command:
Proof-of-Concept
For our demonstration, we used a Microsoft SharePoint 2019 Server with all default options installed on a Windows Server 2019 Datacenter edition system. We assigned it the name sp2019.contoso.lab and made it a member of the contoso.lab domain. Our domain controller is on a separate virtual machine. Our target machine had all available patches installed as of February 2020, which puts it at version 16.0.10355.20000.
Our attacker system simply needs any supported web browser. In the screenshots below, we’re using Mozilla Firefox 69.0.3. We’ll also use a custom WikiContentWebpart similar to the example above. We have named ours
WikiContentRCE.xml
.
Let’s visit our SharePoint Server and authenticate as a regular user. In this example, it is user2 :
Let’s create a site so that we will be the owner and have full permissions.
Click on “SharePoint” on the top panel:
Click on the “+ Create site” link:
Choose Team Site. Now we need to pick a name for the new site. In this example, it is testsiteofuser2.
Click “Finish” and the new site will be created:
Now let’s click on the “Pages” link:
We need to switch to Classic View. To do this, just click on the “Return to classic SharePoint” link on the bottom left corner:
Click on “+ New” and choose any name for our new page. In this example, we called it newpage1:
Click on the Create button to confirm.
Now we need to choose Web Part on the INSERT tab:
In the dialog window, select the “Upload Web Part” link on the bottom left corner and upload the crafted WikiContentRCE.xml file:
Click Upload. You may receive a pop-up warning stating, “This page is asking you to confirm that you want to leave - data you have entered may not be saved.” Just confirm by clicking on the “Leave Page” button. We then return to the main editing view:
We need to choose the Web Part widget on the INSERT tab again. It will have our imported crafted Web Part:
Before we click on the Add button, let’s go to the target SharePoint server and open the C:\windows\temp folder:
Notice there is no RCE_PoC.txt file.
Now let’s go back to the attacker machine and add our imported Web Part to the page:
Let’s check the C:\windows\temp folder on our target server again:
In this way, our attacker can execute any OS command and compromise the server. They just need to replace echo pwned > c:/windows/temp/RCE_PoC.txt string in WikiContentRCE.xml file with their desired command.
Conclusion
In their patch documentation, Microsoft gave this vulnerability an Exploit Index (XI) rating of 2, which means they felt exploitation of this bug is unlikely. However, as demonstrated in our proof of concept section, the exploitation of this bug is quite straightforward for any authenticated user. Because of this, we recommend treating as an XI of 1, which indicates exploitation is likely. According to Microsoft, they addressed this bug by “correcting how Microsoft SharePoint Server handles processing of created content.” That does seem like a reasonable path to take in this instance. 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.