Penetration Testing SQL Servers

It is quite common to discover a Microsoft SQL server in a penetration testing engagement as many companies are having Windows environments. SQL servers are generally running on port 1433 but it can be found and in other ports as well.Since it’s a very popular database we have to know all the step and methods in order to conduct the database assessment efficiently.In this article we will examine step by step how we can perform penetration tests against SQL Servers.

Recon

As we have already mentioned SQL servers are running by default on port 1433.However in some cases they can be found on a different port.So how can we identify the existence of an SQL server on a system?The answer is through the SQL server browser service which runs on UDP port 1434.This service can provide us with the instance name,the version number and the exact port that the database is running.A UDP Nmap scan must be performed in order to discover these information as it can be seen from the next image:

 

Another tool that can help us to discover SQL servers on remote hosts is the metasploit module mssql_ping.The information that we can obtain from this module is actually the same as the Nmap UDP scan that we executed before but it will also returns and the pipe name.

 

From the version we can understand also that the database is SQL 2000.If it was the 9th version then the database would be 2005 etc.

Credentials

This is the most important part as if we manage to obtain somehow valid credentials we can connect directly through the database and we can start to extract data.Some common locations that we can discover database credentials are the following:

• XML files (looking for connection strings)
• SQL Injection (requires an application vulnerable to SQL injection that is running with high privileges)
• Windows Shares
• Developer Workstations (in case that we compromise them)

If we don’t have already discovered an account on some of the above locations then we can try a brute force attack.Metasploit Framework contains a module specifically for this task that can assist us.

auxiliary/scanner/mssql/mssql_login

 

As we have seen from the results above we have discovered that the SQL Server doesn’t contain a password for the sa account.It is also very common for database administrators to use as a password the username or any other simple passwords like company’s name etc.

Post Exploitation

Now that we have the credentials we can use a variety of other metasploit modules that will allow us to discover more information about the database.The first module is the mssql_enum which it will perform multiple security checks against the SQL Server.These checks can assist us to conduct further post exploitation activities against the database.The next three images are showing what kind of information we can harvest from this module:

 

 

 

From the above output we can spot the following:

• xp_cmdshell is enabled
• sa account doesn’t contain a password
• System and Windows Logins
• Privilege that the database server is running
• Databases that exist

The fact that the xp_cmdshell is enabled means that we can execute commands on the remote system through the SQL Server.Of course the first thing that comes to our minds is to add another account and to put it on the local administrator group in order to have permanent access to the box.Metasploit framework has an appropriate module for this work.Below is a sample of the usage of this module.

 

In case that we want to connect to the database directly and to execute SQL commands we can use either a client like osql or another metasploit module the mssql_sql.

 

With this module we can extract more information about the database tables and records.

Conclusion

The purpose of this article is to provide an overview to the penetration tester about common tools and methods when he has to assess Microsoft SQL servers.It is also very important to know the structure of an SQL server and what we have to look for as a penetration tester so it is recommended to create our own SQL database in our lab in order to understand better how it works and what these modules are doing exactly when interacting with the database.