Exploring CVE-2024-38227 vulnerability in Microsoft SharePoint
On September 10, Microsoft released another batch of updates addressing 79 vulnerabilities in its products. Among the patches that caught our attention were those for Microsoft SharePoint, an extensive content management system (CMS). Four out of the five SharePoint vulnerabilities covered by the September release allowed remote code execution (RCE) and one of them posed a DoS threat. We decided to analyze CVE‑2024‑38227, a privileged user RCE vulnerability. This research was an opportunity to explore Microsoft SharePoint as such and understand its state‑of‑the‑art operation theory.
Microsoft SharePoint is a CMS with a wide array of functionality. It allows users to create websites ranging from internal corporate services to document management portals. In addition, the Microsoft SharePoint architecture enables the interaction of several servers within a single farm. While all of this provides vast possibilities, it also greatly expands the attack surface. Microsoft SharePoint is written in C# while using IIS as the web server and MS SQL as the datastore.
As always, when analyzing closed‑source software, the goal was to understand the exact changes introduced by an update. For this purpose, we chose the classical comparison method and installed Microsoft SharePoint 2019 twice: the version before and after the patch.
Microsoft SharePoint contains about 700 executables, at least 400 of them are C# DLLs. Obviously, this requires some kind of automation. The first urge when working on such projects would commonly be to decompile all DLLs through dnSpy or similar C# decompilers and then compare the text. However, after testing this approach, we got a lot of false-positive results. Making a more correct comparison required a truly in‑depth analysis, at the IR level. So we switched to BinDiff with IDA, and here is how:
- We did a recursive run through the old and new projects and converted all executables found to IDB.
- We converted IDB to BinExport.
- We compared BinExport files via BinDiff and wrote the result to a common database.
Comparing the files showed that only two were in fact changed:
Among the list of changed files, Microsoft.SharePoint.dll caught our attention. The comparison clearly shows patches related to deserialization. We can see the IsAllowedIDictionaryType method added to the SPUtility class. The method checks that the type implementing the IDictionary interface is present in the allowed list of checked types.
This method is used in the SPAutoSerializingObject class, and, according to ZDI, the vulnerability that exists there only creates a DoS condition.
We were more interested in the following changes to the RemoterService and LobSystemParser classes, which presumably correspond to CVE-2024-38227 and CVE-2024-38228:
Changes to the ReadXml method of the LobSystemParser class
Changes to the ExecuteBdcMethod method of the RemoterService class
Judging by the content of the exceptions, we can assume that Microsoft has removed the ability to execute .NET Assembly. Kind of looks like RCE, doesn’t it?
For further analysis, we needed to investigate how the ExecuteBdcMethod method of the RemoterService class had been changed. The first step was to understand how to invoke it. The RemoterService class is an implementation of the IRemoteExecutionService interface. It is the ServiceContract attribute within which the ExecuteBdcMethod operation is defined.
The RemoterService class implements IRemoteExecutionService
The IRemoteExecutionService interface
At that point, we looked through the references in RemoterService and found the file BdcRemoteExecutionService.svc. The IIS configuration suggests that this SVC file can be accessed through the path /_vti_bin/BdcRemoteExecutionService.svc.
The method we are interested in can be invoked by accessing the service using the Windows Communication Foundation WCF.
We could not find readily available information on how WCF works at the network level. WCF itself uses SOAP, though it is not clear what to use as namespace and SOAPAction if not explicitly specified in the contract. So, in order to understand what to specify, we created a small test bench with a C# test service that uses WCF and analyzed the traffic.
As it turned out, if namespace is not specified explicitly, http[://]tempuri[.]org is used by default. In SOAPAction, it is required to specify namespace (in our case http[://]tempuri[.]org), the ServiceContract type, and the OperationContract type.
In our instance, we understood that http[://]tempuri[.]tempuri[.]org/IRemoteExecutionService/ExecuteBdcMethod must be specified as SOAPAction.
Based on this information, a similar query was made to invoke the BdcRemoteExecutionService.svc method.
The method was invoked successfully, but an exception was triggered
Now that we invoked the method we were looking for, we wanted to understand what this service was and what this method did. Judging by the name of the class, method, and its arguments, we could invoke the methods of a certain BDC.
Using the legitimate functionality available to the privileged user, we imported the BDC model with a .NET Assembly:
Then all that remained was to execute the query to invoke ExecuteBdcMethod, with the required parameter values prefilled for arbitrary code execution.
The win32calc.exe process on the host running SharePoint
When we decided to investigate CVE-2024-38227, we had no idea how complex and intricate Microsoft SharePoint would turn out to be.
Complex design and heavy architecture seriously hinder the analysis of such projects and create a real challenge when it comes to tracing data and code flows. However, in the course of such research, we accumulate a variety of tools and knowledge to apply to similar‑stack services in the future.
We do hope you found this research useful. Stay tuned for more.