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.
Fuente: http://pentestlab.wordpress.com/2013/03/18/penetration-testing-sql-servers/
No hay comentarios:
Publicar un comentario