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 unSharepoint1.
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:
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:
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:
As for the construction of a local DB, a local folder is generated, inside which we will find two .csv files:
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.
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:
As introduced in this link (sharepoint-farm-build-numbers2), Sharepoint manages the versioning problem according to the following format:
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 buildnumbers3 portal.
To determine the presence of known vulnerabilities, an official Windows endpoint (windows-cve-api4) 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-sharepoint5 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.
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:
The last two bullets, as shown in the next session, are still under development and will likely be integrated in the next releases.
For any doubt or suggestion on developing new modules, you can write an email to davide.meacci_at_cys4.com: collaboration is always welcome!