So you have your shiny new SharePoint environment and you are happy as can be with it. You sit in a meeting and your boss then asks, “Is it secure?” Of course you say “Yes” but then it makes you think about and wonder if it really is. You have internal and external users and have configured as per the documentation you read online so it has to be right. Well, maybe think again!! It could be secure, it may not be. This comes down to your configuration, entry points and how you secured everything from user access to the actual content itself.

One thing you can do is security audit your environment and even penetration test it, so you can get a nice shiny report that can be handed to your boss saying all is good. So how do you do that?

Ideally you would get someone else to perform this task, then get them to sign to say it is “secure” if anyone will actually put their name to that nowadays. Obviously that test comes at a cost of time and money. So “Is there a way of you doing some of the testing yourself?”

The answer is a resounding “Yes“, in this post we will look at the first and basic step to checking your site. This is not intended as a replacement for a professional security penetration test, but a starting point to let you know tools to use and what kind of things to look for.

The key to performing a test is really understanding that you need to complete the following items:

  1. Recon
  2. Exploit
  3. Attack
  4. Report

The steps are really straight forward, we are going to perform some “recon” on our environment, simple things like what Operating System, this will give is a base to start for known exploits that can then be ran against it. Once we have exhausted the known exploits then we may run brute attacks against the platform to uncover as much as we can and even compromise the system. Of course all of this should be documented so you can perform remedial steps later on.

So let’s look at the “Recon” phase. For all of the posts I will be using a Linux distribution called Kali Linux, you can get it from here: http://www.kali.org/

Firstly let’s create a plan of what information we need to gather:

  1. Operating System Version
  2. Web Service Versions
  3. Installed Components
  4. Available Ports
  5. SharePoint Version
  6. SharePoint endpoints
  7. SharePoint Web Service Endpoint
  8. SharePoint FrontPage/RPC Query results

So let’s look and finding the operating system details. From Kali Linux launch the following tool.

Zenmap is a GUI implementation of “NMap” along with a few other pieces and can be used for quite a few things. So how do we use it?

We are going to use the DNS name of either the server, SharePoint URL or the IP Address of the Server as the target. We will then select “Intense Scan“.

Click the “Scan” button and it will perform a “Stealth SYN” scan against the server, and then move on to an “Nmap” scan after that. Now when I ran this against an internal server, I got all kinds of results as there was nothing to deflect the scan, a firewall could have helped at this point to control the scan traffic or even block it. My results for the “Stealth SYN” scan were as follows:

Notice that I have lots of ports open and it gave me the IP Address of the server in case I didn’t already know that. This is great as it gives me a whole attack surface that I may not have known about. This is ideal as I can then check places like http://www.cvedetails.com for the latest vulnerabilities that can affect port based traffic. Now after the stealth attack “Nmap” is called to perform “Fingerprinting” of the ports and the device details, obviously the device here is a server. A results sample is shown below:

Notice it perform attempts to connect to the ports such as port 80. In this instance port 80 is open for our SharePoint site but requires an authentication token to get in. Once it has performed “Fingerprinting” of the ports it moves to the device.

For this is performs what I call the “Guess Scan“. It has a go at identifying the device by checking the following:

  1. MAC Address
  2. Device Type
  3. OS Scan
  4. Aggressive OS Guess Scan
  5. Uptime Guess
  6. Network Distance by Hops
  7. TCP Sequence Prediction
  8. ID IP Sequence Generation
  9. Service Info

My results are as follows:

It gave it, its best attempt and realizes that is windows but could be any number of versions.

Notice that each Operating System is weighted with a percentage to help you determine what it could be. Now lucky for us the next step in our scan actually using another mechanism to actually determine the operating system.

This test that is performed using SMB, gives us the exact Operating System, Device Name, and as it is a server gives me the domain details. Notice I also get the security that is associated to the server, in this case is using standard “Challenge/response” windows. So now we know the operating system we can now check for existing vulnerabilities and perform attacks that way. However we have only got the server details, what about applications that might be installed on the server, like SharePoint or even SQL.

To perform a SQL scan we can use another set of tools that are contained within the Metasploit Framework.

This will load as a terminal application.

Now we can start scanning the chosen server and any other servers on the same network segment for installations of SQL. To do this we will load one of the pre-built scanners. To load the scanner use the following syntax:

This will change the console prompt to now be using the auxiliary tool, which in our case is the “mssql_ping“. We can now type the following commands, obviously using your IP address of the server you wish to scan against.

  1. set RHOSTS 192.168.92.129/24
  2. exploit

This will then scan the entire network range for SQL server installations. The results are returned showing the server name, instance name, if it is clustered, version and TCP Port it is running on.

Now that we have found the SQL Server we wish to use now we can launch another tool that will allow us to try and make changes to the SQL configuration, such as changing passwords and even creating new accounts that can be used later. Firstly however we need to use the “mssql_login” tool to brute force the password.

Now that this is loaded we will use the following parameters:

  1. USERNAME
  2. USER_AS_PASS
  3. USERPASS_FILE

Loading these with the account we wish to try and compromise and then pointing the password location to a file. You can find lots and lots of password files on the internet to use for this. We then set the RHOSTS file as before to the server IP we wish to target.

Now we can set the host like before “set RHOSTS 192.168.92.129“. We can then run this and it should try to brute force the SQL Server using the specific account and passwords from the selected password file. The results should look as follows:

When it completes hopefully it will complete like this:

The result above shows me that a password was tried combined with the username of “SA” and it was successful. Now we have successfully got that we can do a whole bunch of stuff, connect it remotely or we could continue to do things using Metasploit. We will keep using the same tool but this time we will load the following tool.

Once loaded we can simply type “info” and it should render out some base information we already have. We will then too populate the rest with the same details and the new password we have now.

When we now check the information it should render as below.

Now we can simply run this tool and we should start to see more information about the SQL Server.

Databases and their file locations.

Accounts on in SQL.

Accounts grouped by permission levels and whether they have windows logins.

Accounts with empty passwords and then stored procedures that can be accessed using public execution permission.

SQL Instance name and the service account running it.

Now we have enumerated the SQL Server we are ready to exploit the server. In this example it could be as simple just loading up SQL management studio somewhere else and accessing it using the credentials we have. There are other ways that you could continue such as loading a payload that launches a remote “command” windows for making changes.

Now obviously you would like to think that you cannot do this from the outside network and that this is only possible from inside the network. Sometimes this is true other times it may not, in all fairness if this can be achieved from outside your network then you have slightly more things to worry about.

This just shows what the plan of attack could be for a SharePoint Farm whether from the inside or outside. In the next post we will focus on the SharePoint Web Application itself.