Critical Vulnerabilities within SharePoint Server

In the past week or so, there has been a lot of noise made around an exploit in the wild creating vulnerabilities within SharePoint Server. This exploit reference is CVE-2019-0604, and further details are available from Microsoft and also the National Institute of Standards and Technology (NIST).

Microsoft Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0604

NIST Advisory: https://nvd.nist.gov/vuln/detail/CVE-2019-0604#vulnCurrentDescriptionTitle

What is interesting is how this exploit works. Microsoft outlines a basic explanation of what the exploit does:

“A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the SharePoint application pool and the SharePoint server farm account.”

This explanation makes it sound like every single SharePoint Server is easily hackable, so time to turn them all off I suppose. In reality, exploits like this are complicated to create and use, and they require particular conditions. Did you know that SharePoint Server 2016 has 18 known vulnerabilities/exploits to date? Over half of these have a score of 9.3, which means they are pretty potent and dangerous.

https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-11116/version_id-199889/Microsoft-Sharepoint-Server-2016.html

SharePoint Server as a whole, including all versions, currently has 149 known vulnerabilities and exploits.

https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-11116/Microsoft-Sharepoint-Server.html

This particular issue affects all versions, including SharePoint Server 2010, SharePoint Server 2013, SharePoint Server 2016, and yes, SharePoint Server 2019.

How does the exploit work?

The affected component within SharePoint is the people picker control we all use to add users and groups into SharePoint. The control itself uses the “Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder” class:

https://docs.microsoft.com/en-us/dotnet/api/microsoft.sharepoint.businessdata.infrastructure.entityinstanceidencoder?view=sharepoint-server

This class and specific methods expect information to pass to the function in the form of an XML/JSON object allowing for the execution of the code within SharePoint. What effectivity happens is that a hidden div/span container (“ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData“), within the page, has its values injected into the pipeline for the picking control to work. These values are then serialized using the standard “XmlSerializer,” and the code executes.

So, what is the big deal?

Well, let’s imagine a malicious hacker, disgruntled developer or administrator has access to execute commands against the SharePoint Server. What could happen is that a crafted link or modified system page could execute commands and allow remote execution of commands directly within SharePoint. In reality, the code execution would need the following steps:

1. Instantiate a SharePoint Server connection
2. Load the “Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder” class
3. Call the required method
4. Create custom XML object Payload
5. Override the default values with custom XML Object
6. Load the XML Object into the standard method
7. The malicious code would execute

From a code perspective if we were creating a console application then our code could look something like this:

The payload itself is a link to an XML file that contains the commands I wish to run. In this instance it could be anything, for this example though, I am launching PowerShell, then loading a local PowerShell script, but it could easily be one located on the internet somewhere such as GitHub or other code sharing platform.

The outcome of executing the code is “CMD” is loaded, a “PowerShell” window launches, which loads the “ps1” file which runs “whoami” to display the account I am logged in as. Of course, this could be much more malicious.

How do I protect from this exploit?

Patch, Patch, and Patch. That is the only way of resolving this issue. With any SharePoint Server Farm, patching is a pain but a necessity. For me, I always stay two cumulative updates behind, just in case of those pesky regressions. However, for Security patches and updates, these should be applied more frequently after careful consideration and reading of what it updates and resolves. The patch for this issue was released back in February with subsequent updates added later. The Microsoft CVE page displays the links for the updates for each version of SharePoint.

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0604

Outside of patching, always check for any changes to system pages, for example scanning with IIS files and folders, and of course the “hive” file structure for any anomalies.

As always, knowing what you have within your SharePoint Farm, current Patch Levels as well as who can make changes such as these is essential. If you do not have this process, or have not patched for a long time, or have no monitoring solution, then now is the time to do so.

If you are running Office 365, or planning to move to the cloud, and would like to brush up on your security protocols, check out this free checklist on strengthening the security posture of your Microsoft 365.