Protiviti / SharePoint Blog

SharePoint Blog

June 17
Is SharePoint Vulnerable?

So this is a question that I get asked quite a lot when traveling around speaking. It is a bit of a vague question, as SharePoint can and is vulnerable to all kinds of things. In the context of security then the answer is yes and no. However this can only be truly answered once a Pentest process has been completed.




What is Web Application Penetration Testing?

A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.​

What is a vulnerability?

A vulnerability is a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. A threat is a potential attack that, by exploiting a vulnerability, may harm the assets owned by an application (resources of value, such as the data in a database or in the file system). A test is an action that tends to show a vulnerability in the application.

When tasked with validating security for SharePoint you need to follow a strict plan of tasks that make up the Pentest process. Using the standard OWASP guidance is a good place to start. A security test for any web application (“which SharePoint is”) would contain the following items:​

  • Configuration Management Testing
  • Business Logic Testing
  • Authentication Testing
  • Session Management Testing
  • Authorization testing
  • Data Validation Testing
  • Denial of Service Testing
  • Web Services Testing​
  •  Ajax Testing

Each of these tests can be broken down further so you have an exact list of items that you need to validate. As an example if we break down the “Configuration Management Testing”, we are looking at testing the following: (courtesy of www.owasp.org)​

SSL/TLS Testing

SSL and TLS are two protocols that provide, with the support of cryptography, secure channels for the protection, confidentiality, and authentication of the information being transmitted.

Considering the criticality of these security implementations, it is important to verify the usage of a strong cipher algorithm and its proper implementation.​

Database Listener Testing

During the configuration of a database server, many DB administrators do not adequately consider the security of the DB listener component. The listener could reveal sensitive data as well as configuration settings or running database instances if insecurely configured and probed with manual or automated techniques. Information revealed will often be useful to a tester serving as input to more impacting follow-on tests.​

Infrastructure Configuration Management Testing​

The intrinsic complexity of interconnected and heterogeneous web server infrastructure, which can count hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application. In fact it takes only a single vulnerability to undermine the security of the entire infrastructure, and even small and (almost) unimportant problems may evolve into severe risks for another application on the same server. In order to address these problems, it is of utmost importance to perform an in-depth review of configuration and known security issues.​

Application Configuration Management Testing​

Web applications hide some information that is usually not considered during the development or configuration of the application itself.

This data can be discovered in the source code, in the log files or in the default error codes of the web servers. A correct approach to this topic is fundamental during a security assessment.​

Testing for File Extensions Handling​

The file extensions present in a web server or a web application make it possible to identify the technologies which compose the target application, e.g. jsp, asp and aspx extensions. File extensions can also expose additional systems connected to the application.​

Old, Backup and Unreferenced Files​

Redundant, readable and downloadable files on a web server, such as old, backup and renamed files, are a big source of information leakage. It is necessary to verify the presence of these files because they may contain parts of source code, installation paths as well as passwords for applications and/or databases.​

Infrastructure and Application Admin Interfaces

Many applications use a common path for administrative interfaces which can be used to guess or brute force administrative passwords. This test tends to find admin interfaces and understand if it is possible to exploit it to access to admin functionality.​

Testing for HTTP Methods and XST​
In this test we check that the web server is not configured to allow potentially dangerous HTTP commands (methods) and that Cross Site Tracing (XST) is not possible.

In the next series of posts we will look at each of these and how we can test SharePoint just like any other web application.​

Too often we don’t think of SharePoint as a web application but really an application and we have this very naïve view that because it is, that we do not need to test it so much. We often have the attitude of “well Microsoft created it so it should be inherently secure”. This approach though may be founded, also does not cater for the misconfiguration, or downright not adhering to best practice approach for any security within an infrastructure.  In my experience 90% of security issues with SharePoint, even the one mentioned by the NSA recently regarding the “Snowden” trouble are because of misconfiguration from really laziness and lack of understanding.

http://www.neowin.net/news/did-edward-snowden-use-sharepoint-to-leak-nsa-files​

General Alexander, while not naming Snowden directly, answered the question by saying, "This leaker was a system administrator who was trusted with moving the information to actually make sure that the right information was on the SharePoint servers that NSA Hawaii needed."

As you can see as SharePoint becomes a platform of choice for all government, military agencies and general businesses it now becomes more important to “configure it correctly”.​

In the next few posts we will break down the Pentest process into small pieces so you can perform some of the basic tests yourself. However if it was me and I had a very large SharePoint platform that was going to be housing sensitive content then I would consider the following:​

1. Read the document for securing SharePoint on Microsoft TechNet
2. Potentially read the exciting Security Technical Implementation Guides (STIG) and NSA Documents
3. Perform some basic security tests
4. Contract a Pentest company to perform a full “end to end” test​

The real goal here is to get everyone everywhere to configure SharePoint correctly so that the majority of security issues go away and SharePoint does not get a bad reputation for being “in-secure”.​

Quick Launch


© Protiviti 2019. All rights reserved.   |   Privacy Policy