Like almost any application that works on the web, SharePoint, in all of its’ versions, has a list of vulnerabilities that can be exploited from different avenues (internal vs external). That being said, even security hardening recommendations aren’t capable of covering all of the possible angles, the majority of those vulnerabilities are more about abusing the way the specific SharePoint features are designed.
Groups of SharePoint vulnerabilities
The general assumption is that there’s four groups of SharePoint security flaws:
- Permission mismanagement;
- Default pages;
- Vulnerabilities in the SharePoint system itself or in SharePoint Apps;
- Various content issues.
Permission mismanagement. The overwhelming majority of content management systems are facing the same similar issue. The issue itself is that there’s a number of users that can control who sees what content and there’s also users that can upload content to the server, and in most cases permissions for a particular task are set too wide and with them open a lot of possibilities for anyone that gains access to this account. System-wide restrictions are possible, but often not configured correctly. The process of finding out the improper permissions is very hard to automate and should ideally be done in tandem with content evaluation/content discovery.
Default pages. These pages are quite helpful for anyone who’s relatively unfamiliar with SharePoint as a system, since there’s a number of default pages that are pre-installed from the beginning. The problem with these pages is that they are relatively similar and can streamline the hacker attack, making the entire process of breaking into your system way faster and far more destructive in nature than it would otherwise be. The general recommendation is to only use the pages that you’ve created yourself, and disable the default pages as soon as you can. There’s one more problem with that, since attackers can still re-enable those pages, if they’ve managed to gain access to the system through other means.
Web app vulnerabilities (SharePoint and SharePoint Apps). Like a lot of web apps, there’s a variety of unified vulnerabilities that can be used to get access to the system, including SQL injections, XSS, and many more. These vulnerabilities are capable of providing access to either the entire system or to the specific user accounts via client-side attacks.
Content issues. This group represents all of the issues that arise from the way SharePoint interacts with different content types. Problems with content can be downright terrifying from a scale and destructive potential to your system. There’s three main sub-groups for content issues:
- Malware. All kinds of malicious code can be added to the system via content that’s uploaded to the system, and the uploaded content itself is barely tested by SharePoint’s own means.
- Server scripts. A variety of projects can be used to upload various server scripts to allow access to shell and web pages.
- Client attacks. SharePoint is a trusted tool, which makes it easier to abuse it for attackers, via XSS, social engineering, or just plain impersonation.
This brings us to the subject of SharePoint security testing. Security testing in the context of SharePoint means using one of the specific tools to check if you can gain access to your SharePoint server via various means. There are some of them that are exceedingly complicated and many web tools may not work properly or list unreliable results.
In this article we’ll be going over some of the penetration testing techniques available, namely:
- Google Dorks;
- Fuzzing;
- Kali Linux.
Google Dorks for SharePoint security testing
Google Dorks is another name for Google hacking – a hacker technique that utilizes the ability of Google Search (and some other Google-related applications) to find parts of the websites’ code and security holes for the system. On its own, “Google hacking” is about using a specific way of targeting Google’s advanced search engine to find specific text strings in your search results.
There’s a number of different search queries that can be used to locate specific bits of code in the site. We can use the keyword site to specify the search location, inurl to find any mentions of a specific word, a * symbol means that there can be any text in this place, and so on.
For this exact test we’re using a number of specific search queries (called “dorks”, hence Google Dorks) to look for various content types within your SharePoint system (don’t forget to specify your site using the site:yoursite.com command, it needs to be input before the dorks to narrow your search results). Here are those dorks:
- inurl:”/viewlsts.aspx?BaseType=”
- inurl:”/_layouts”
- inurl:”/_catalogs”
- “All site content” ext:aspx
These search queries should be able to let you access a lot of various classified documents.
Fuzzing testing of SharePoint security
In addition to the results from the previous method we can also try and expose some important information like:
- The version of SharePoint installed;
- SharePoint web services that are configured on the app;
- View default SharePoint layouts, configs, forms, etc.;
- Enumerate users, and so on.
Fuzzing is a software testing technique that is automated and used to provide various invalid and unexpected inputs to the program. The program that is overloaded with such commands might show various exceptions, including crashes and memory leaks.
There’s a number of different fuzz testing programs (fuzzers), but the next step should work with pretty much all of them. As a process, fuzzing involves a lot of intricacies, but we won’t go over them to keep the matters relatively simple. An example of a fuzzer is presented here, and “running” it after specifying your server address should get you a number of different results in the command line with different codes at the end of each file found: 200, 403, etc.
Going directly to the pages that had shown “200” at the end of the specific lines should allow you to uncover bits and pieces of information about this specific SharePoint server, like SharePoint version, frontpage server extensions, default layouts, web services, and so on.
Kali Linux
If we’re talking about more complex SharePoint security testing, it usually involves four main parts: recon, exploit, attack and report. This entire part would be executed via Kali Linux – one of the most renowned penetration testing Linux distributions.
The first step is recon, and it’s usually about trying to find out some information about the target, including:
- OS version;
- Installed components;
- SharePoint version;
- Web service version;
- SharePoint web service endpoint;
- Available ports;
- SharePoint frontpage results.
The first tool that we’ll be using is zenmap, and it can be found under the Kali Linux > Information Gathering > OS Fingerprinting > zenmap.
The way it works is that you enter either the IP address of the server, the SharePoint URL, or the server itself. Choosing the “Intense Scan” option allows you to perform two different scan types: Stealth SYN and Nmap.
The results of a Stealth SYN scan allow us to see the specifics of open ports and the IP address of the server in question, giving us the attack surface that might not be obvious from the get-go. After the stealth attack is done, the Nmap scan tries to perform the so-called Fingerprinting – identification process, that goes first for the open ports that have been found, and then for the server’s details.
After the scan is done defining the API versions or OS versions of all the ports, it moves to the device itself and performs a different scan type called Guess scan. It’s basically the same identification process as before, but it attempts to discover much more information than just the OS version, including:
- MAC address;
- Uptime guess;
- Device type;
- Service info;
- Network distance by hops, and so on.
The results of the scan should give you the estimate of the information that has been found, and if the information is not clear (hence the “guess” in the name), the scan can also give you the probability of this device having a specific OS like this:
Aggressive OS guesses: Microsoft Windows 7 Professional (95%), Microsoft Windows Vista SP0 or SP1, Windows Server 2008 SP1, or Windows 7 (93%)… … No exact OS matches for host (test conditions non-ideal).
To remedy that uncertainty, the next step of this long scanning process is to perform another scan to identify the exact OS version that is used, from the list with probabilities that has been shown to you before.
The knowledge of the specific OS of the system already allows us to look for specific vulnerabilities to exploit, or we can look further to try and find out about the SharePoint applications or SQL on the server.
Specifically performing a SQL scan requires the usage of another tool called metasploit framework, located in Kali Linux under Exploitation Tools > Metasploit > metasploit framework.
This time it’ll load as an application with the terminal interface with the ability to input commands. The first thing we’re doing is scanning the server and other servers that are in the same network segment for the signs of SQL activity, one of the pre-built scanners allows us to do exactly that, with this command:
use auxiliary/scanner/mssql/mssql_ping
Now the console prompt changes to show you that it’s using the tool in question, called mssql_ping. Typing in the following commands allows you to begin the scan (note that you have to specify your target’s IP address instead of the one shown below):
set RHOSTS 192.168.0.1/88 exploit
The results are shown in a form of a list with the parameters like server name, instance name, version and TCP port.
To try and make changes to the SQL configuration that we’ve found requires us to brute force the password to this SQL to be able to see anything in the first place. The tool that we’re looking for is mssql_login.
use auxiliary/scanner/mssql/mssql_login
As soon as the tool is loaded, we’ll have to input the following commands that are used to specify the username and user password in question. Instead of a specific password we’re inputting the path to one of the password files that are all over the internet (file name and path are only examples).
set USERNAME _admin set USER_AS_PASS false set USERPASS_FILE /tmp/Dictionary/B5.DIC
After all that the console is ready to try and brute force the password, all you need to do is specify the target IP, as we’ve shown before (set RHOSTS 192.168.0.1), and the process should begin.
The successful end of the process should look like this:
– MSSQL – successful login ‘ag’ : ‘P@ssw0rd5’ Scanned 1 of 1 hosts (100% complete)
The last lines of the successful brute force attempt are showing us that the successful pair of username and password in this exemplary case is the username “AG” with the password “P@ssw0rd5”
With this the majority of the process is complete, now we just have to load one last tool called mssql_enum to get access to a lot of information about the SQL server.
use auxiliary/admin/mssql/mssql_enum info
The command info allows us to see the base information that we already know of, but now we can specify the username and password that we’ve found and start the process with the specific command about our target IP.
set USERNAME ag set PASSWORD P@ssw0rd5 set RHOST 192.168.0.1
Now we can just run this tool and it should render a lot of information about the SQL server, including:
- More specific OS version info;
- Database names and locations;
- SQL accounts;
- Account groups;
- Accounts with empty passwords that are accessible via public execution permission;
- SQL instance name and the name of the service account that runs it.
After all of that we’re ready to exploit the server in any way we want, since we have credentials and other important information already. Other ways of influencing the system also include loading a specific payload with the remote set of commands, loading up SQL management studio, etc.
Conclusion
Of course, these aren’t the only ways of performing security testing for your SharePoint server, but these should help you understand the overall complexity of the matter in general. It is recommended to turn this work to a trusted professional in the field. As always, fixing found security flaws through patching, turning off default pages, and so on is strongly recommended.
