SQL brute force POC (Alternate Ending)

11 Sep

I hope you read my post on ethical computer hacking…

Last time, the main character left off using a feature that is built into SQL Server ‘xp_cmdshell’. This was done using SSMS so it wasn’t really an “exploit” per-se. So for round two, my goal was to make sure to wow the audience and [SPOILER ALERT!] kill off all the main characters. Here is how it happens…

The brute force attack did get us connected to SQL Server with a sysadmin account. I’ll need this for the next step in our alternate ending. Instead of using ssms to run xp_cmdshell I’m going to attempt to use real exploits within the metasploit framework. This framework comes pre-loaded in backtrack. Launch it using the ‘msfconsole’ command.

The specific module is mssql_payload That site comes in quite handy when searching for a plausable exploit. There are so many pre-loaded payloads and exploits in msf that sometimes its harder to choose one than it is to use one.

Meterpreter is a quite popular method of dll injection. It will get your target machine doing things that you want it to do rather than the actions that it’s used to. By operating entirely in memory and over normal ports on a TLS connection, it avoids any classic virus scan, firewalls, network traffic scans and even post carnage forensics.

If you have ever seen scary movie, this is the point the attacker is in the house and the victim has run up the stairs to get away (doh). The flimsy door latch seems to be holding on for now so the attacker goes rifling around the rest of the house. I was actually quite shocked I was able to pop the meterpreter prompt on my windows 2012 vm. That got me wondering if we could use this account to dump any hashes (the encrypted password strings stored in Windows). Turns out I can’t, at least not today with my current skills and the rather outdated msfconsole I have. I am also unable to do several other nasty things. The one thing I can do is clear the windows event log with that ./sql account.

We’ve all been in a position where we might have to choose one of these options, security or productivity. The developer calls up complaining about some loading procedure that isn’t working and just wants sysadmin for a second to fix it (lol). So you mistakenly think you have done a great job by fixing the problem a different way, granting the sql service the ability to run as system. It is very realistic to find SQL Servers setup to run as different accounts other than those suggested by best practices. On the install, any amateur administrator might think it’s fine to run as one of the pre-populated NT Athority accounts. NT ATHORITY\SYSTEM perhaps might be a good choice. If it were my first install of SQL, I might fall into the same trap of not trying to be secure but trying to get something to work.

Right now you might be wondering, why is this hacker continuing to press on? Maybe at this point they create a administrator user account or drop a backdoor payload and call it a night. But this hacker wants to teach the owner of this box a lesson.

This is another terrible idea to have IIS installed on the same host as SQL Server. That makes it easy on attackers to compromise one service and easily gain access to the other. That said meterpreter does have some interesting features I will have to explore on linking exploited computers together via “pivoting” and the ADD ROUTE parameter.

Enough fun, time for the finishing move…

If you look closely at the commands that were run, you will see that the first attempt to dump the hash fails even when running as NT AUTHORITY\SYSTEM. But, fortunately SQL out of the box has this handy service that nobody uses set to NT AUTHORITY\SYSTEM. Even better, it has even more access because it uses VSS. One process migration later we grab the password hash and run. Back in the safe zone we take less than 1 second to crack the lazy administrators extremely weak password.

What you have seen in this post is not really a lesson on how to be a great hacker, but more of a lesson on how NOT to be a bonehead administrator.


Posted by on September 11, 2012 in Security, SQL Admin


2 responses to “SQL brute force POC (Alternate Ending)

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: