Table of contents

• Introduction
• What is unSharePoint and how it works
• Preparation phase
• Analysis phase
• Presentation phase
• Next steps
• References

Introduction

The use of Microsoft tools for the development of web applications has been an established and consolidated practice over the years. In particular, there are several technologies that make it possible to greatly simplify the development and distribution cycles of web services, assisting the managers of these applications through a wide set of features. One of the main tools used in this context is undoubtedly Sharepoint, a Content Management System (CMS) software platform. Sharepoint allows the creation and distribution of particular websites, mainly designed for corporate use (Intranet), which can however be distributed on the Internet as to be accessed outside the organization itself. By managing a system of permissions for its elements (Site Collection, Site, List / Repository, Page or Folder / Item), it is possible to associate a set of permissions to each element of the system, thus implementing a Discretionary Access policy Control (DACL). This allows you to create websites in which, depending on the level of authorization a specific user has, he is allowed to access or not to different elements, specifying the type of access (for example, if in read-only or in contribution).

However, the process of managing a set of privileges can introduce a series of vulnerabilities, due to the improper assignment of authorization to groups and users of the platform. The permission chains for each group and their users are not always correctly monitored: this problem could ultimately lead to the direct compromise of the Sharepoint infrastructure. Furthermore, the large amount of publicly identified vulnerabilities (CVE) for Sharepoint exposes companies that use this system for the management of internal and external websites to an enormous risk: in the event that an attacker manages to identify the presence of a vulnerable version to a known criticality, it is highly probable that this will be exploited with potentially catastrophic results. The identification of each of the previous elements translates into a series of long and repetitive activities for each administrator of a Sharepoint platform: these characteristics could therefore lead to the approval and use of unsafe configurations not only for the Sharepoint platform, but also for any related systems, such as servers and entire Windows domains. Starting from these considerations, I decided to simplify the carrying out of the previous tasks by developing a simple automation tool: in a nutshell, I embarked on the path that led to the development of unSharepoint¹.

What is unSharePoint and how it works

In short, unSharepoint represents a tool that allows you to quickly scan a Sharepoint environment for known vulnerabilities and misconfigurations. Developed in python, it can provide a rough indication of which critical issues could be exploited by an attacker to compromise Sharepoint. The tool has a mainly modular structure, in order to simplify the testing and development phases. In particular, during the normal cycle of use of the application it is possible to identify the following macro-phases:

• Preparation phase: here all control activities are carried out to ensure that the target is accessible and is hosting Sharepoint;
• Analysis phase: to prepare a series of tests meant to check for any security vulnerabilities (each class has an appropriate module);
• Presentation phase: finally, the collected vulnerabilities are analyzed and presented according to their impact and possible exploiting scenarios.

unSharepoint mainly supports three types of scans, in order to allow different results depending on the user’s needs. Specifically, it is possible to carry out the following types of activities:

• Informative scan: simple information checks are carried out, such as version detection and identification of any exposed files;
• API scan: in addition to information tests, a series of tests are prepared to determine the type of APIs exposed; can be specified as detailed (parsing single SOAP endpoints) or not.
• Total scan: in addition to the previous scans, further tests are carried out to verify username / password according to a bruteforce probing and REST APIs for user enumeration. Scans are inclusive (Total > = API> = Informative)

Preparation phase

The Preparation phase determines the start of the scan activities performed by the tool, assessing the required parameters and preferences to understand if they are correct, finally setting them. In detail, during this first phase the following activities are carried out:

• checking if the parameters included are consistent with what is expected;
• building a local DB;
• checking availability of the service (healthcheck probe);
• checking Sharepoint availability.

As for the construction of a local DB, a local folder is generated, inside which we will find two .csv files:

• Versions.csv: Sharepoint versions up to the current date are stored (version string, patch ID, date)
• Cves.csv: Public vulnerabilities are stored for each version of Sharepoint

The need for a local DB came out after several testing activities of the tool itself. In particular, while trying out the different scan types, it was clear that the tool could not be used inside local LANs or VPN environments, given that Sharepoint versions and available CVEs are recovered from outside the local network. To understand a little bit more on how such files are structured, additional context will be provided in the next paragraphs.

Analysis phase

Once parameters are verified, the specified domain is labelled as reachable, the local DB is updated and that Sharepoint is available (or we reasonably think it is present on the target), the analysis phase begins. In particular, the following activities are carried out:

• version / patch analysis;
• CVE analysis;
• parsing exposed configuration files;
• API analysis;
• username / password bruteforce.

As introduced in this link (sharepoint-farm-build-numbers²), Sharepoint manages the versioning problem according to the following format:

• Major: the major version of the product
• Minor: the minor version of the product (can be ignored in 99% of cases)
• Build: used to indicate the version number, it is modified during the application of a new service pack / update.
• Revision: indicates the type of most recent update applied.

At this very moment, it has not been possible to find an official and updated library for each version published over the years of Sharepoint: for the development of this tool an external portal is used for the determination of these elements, available at the buildnumbers³ portal.

To determine the presence of known vulnerabilities, an official Windows endpoint (windows-cve-api⁴) exist for the determination of all public vulnerabilities associated with a given product ID; however, the product ID does NOT represent the installed patch, but simply the “major” component of the previously parsed version string. In order to determine whether the analyzed portal is actually vulnerable to a given vulnerability, we must therefore carry out a further check to verify the patching and public disclosure date of the vulnerability concerned. This information is cataloged within the versions.csv and cves.csv files in the first stage of preparation, as previously analyzed.

While developing the tool, I recognized that some vulnerabilities may be more interesting than others, even not taking CVSS Score or Impact into consideration. Specifically, all vulnerabilities that have an associated PoC are definitely interesting, since it will become much easier to test and replicate them in the target environment. To signal this, the tool implements a simple logic to test for available PoC with as less false positives as possible (feel free to check the code!)

About the remaining checks, SharePoint includes REST / SOAP API services applicable to object models that already existed in the framework. This functionality has been included to allow developers to perform create, read, update and delete (CRUD) operations via add-ons, using REST web technologies and the standard Open Data Protocol (OData) rest-sharepoint⁵ syntax Since the introduction of Sharepoint Online, Microsoft Graph is used to manage calls on REST endpoints. Furthermore, through the Excel Services component, it is possible to make SOAP calls; in any case, we can use a series of known endpoints to verify the possibility of access and exploitation, in order to retrieve sensitive information or outline new attack chains. At this very moment, only SOAP API are listed: however, REST API will be soon included in this analysis steps.

Presentation phase

At the end of the Analysis phase, the information collected is finally classified and presented in the as clearly as possible. In particular, the following activities are carried out:

• Classification of information, according to the type of result achieved or potential exploitation scenarios
• Determination of possible attack chains, presenting the final result of the same (creation of new pages / users, modification of contents, RCE, etc.)
• Final report writing, supporting different formats available

The last two bullets, as shown in the next session, are still under development and will likely be integrated in the next releases.

Next steps

• Tuning version check: unfortunately, since it is not possible to find an official and updated library for each version published over the years of Sharepoint, the analysis of the patching level and therefore of the currently exposed vulnerabilities results in a complicated and time-consuming process. For this reason, further analyzes are underway to determine certain versions of Sharepoint specifications which, at the moment, it has not been possible to identify precisely. Furthermore, in-depth studies are underway to implement further strategies for the efficient determination of the patch number of the analyzed platform.
  
  
• RPC Interaction Analysis: For some versions of Sharepoint (2010) RPC Sharepoint 2010⁶, it is possible to exploit a series of endpoints to make RPC calls to Sharepoint. In particular, through the use of an XML-like language called CAML to query Sharepoint through RPC. The RPC protocol uses the HTTP POST request to submit methods to SharePoint Foundation and FrontPage Server Extensions. These requests allow the client to request documents, update task lists, add new authors etc. At the moment, unSharepoint does not support the enumeration of such endpoints: in the next phases a module will be implemented to support this functionality.
  
  
• Determination of attack vectors: Sharepoint allows the creation and distribution of particular websites, mainly designed for corporate use (Intranet), which can however be distributed on the Internet and accessed outside the organization itself. By managing a system of permissions for its elements (Site Collection, Site, List / Repository, Page or Folder / Item), it is possible to associate a set of permissions to each element of the system, thus implementing a Discretionary Access policy Control (DACL). This allows you to create websites in which, depending on the level of authorization a specific user has, he is allowed to access different elements or not, specifying the type of access (whether read-only or contributing)
  
  
• Update reporting phase: the results of the analyzes carried out are currently presented on the console where the tool is run. With a view to future updates, the creation of a final report is planned according to different formats available to make the interpretation of the results easier and more accessible.

For any doubt or suggestion on developing new modules, you can write an email to davide.meacci_at_cys4.com: collaboration is always welcome!

References