Now a days hacking has shifted from attacking systems to know how they work or for the trill of getting into a system for the sake of the hunt but many hackers are doing it for profit, in fact many companies around the world and states are employing hacker for information both for political and financial gain. One of the places where most of this information resides is in databases and one of the most popular databases in enterprises and governments now a days is Microsoft SQL Server and on this blog post I will cover some of the attacks you can do against this system with Metasploit 3.3.
The Microsoft SQL Server Product is in fact a suite of products compromise of several services like reporting, integration and others, in addition there is large number of types depending on the version like for instance in MSSQL 2000 there is a MSDE edition for Desktops that is small and lite, there is an Express, Web, Standard and Enterprise to mention the most popular with MSSQl 2005 and 2008 so in this blog post I will focus mainly on the Database component of it. MSSQL listens on 2 ports, port TCP 1433 and UDP port 1434, server instances get a random TCP port and this port can be obtain thru the UDP port 1434. It has 2 methods of authentication that can be configured SQL Authentication and Windows Authentication. This 2 methods differ in terms where the Account Credentials are stored and what policy is applied to such account. In MSSQL 2000 the SQL Authentication is one of the most abused methods of gaining access to the database since it does not log authentication attempts by default, it is clear text and one of the most abused methods is that by default there is no account lockout of password policy on this version on MSSQL, now on the most recent version SQL 2005 and SQL 2008 this differ in terms that the account policy being applied to the Windows host where the database engine is running, I have seen in production environments DBAs (Database Administrators) disable the policy checks for SQL accounts in the latest versions. Another one of the drawbacks of using SQL Authentication is the presence of the SA account, this account runs as sysadmin on the Database Engine and thru the store procedures on MSSQL it can execute command against the host OS under the privileges under whish the Database Engine is running under. As you can see using Windows Authentication is the way to go when performing hardening of a MS SQL system and making sure developers use Windows Accounts. One important note is that when the server is set for SQL Authentication it will also Authenticate Windows Users this is known as Mixed mode. In MSQL 2000 and 2005 the local Administrators group is given the sysadmin role by default and on MSSQL 2008 only the local Administrator account is given permission, on MSSQL Clusters the service account for the Database Engine has to be a domain account and in many installations I have seen this account be part of the Domain Administrators Group. This information can be of great use when doing post exploitation on a MSSQL host. Another important part of MSSQL systems is that they come with a large number of Stored Procedures that permit Command Execution on the host, modification of the hosts registry, File manipulation, sending emails and many other functions as âFeaturesâ making the post exploitation aspect of MSSQL attack a very interesting one.
So lets start by finding all host running MSSQL Database Instances on a network for this Metasploit has an auxiliary module called mssql_ping, below you will see how to use this module and see the options it offers from a msfconsole window
The 2 options we need are the RHOSTS and the THREADS options. Lets set and run the module against the network in my lab.
As it can be seen 2 servers where found, know I like to corroborate always my findings with other tools so I can be sure Iâm targeting the correct targets and the correct versions, for this we will use the nmap por sacnner with one of their nse scripts
As it can be seen by the nmap scan there is a second instance on each of the host files, one special note is that when you run the nmap scan with the ms-sql-info nse script that the scan be a UDP scan and nmap must be ran as root. Another way is to use Nessus in command line mode with the plug-in id 10674
As it can be seen each tools gives a different level of information, but I have found that one of the fastest ways is to use Microsoft own tools, the Microsoft SQL Server Management Studio that comes as part of MS SQL 2005 and MS SQL 2008 is on the fastest at finding MSSQL Machines on the same subnet and also helps in identifying any other MS SQL Services that might be available something that the other tools do not detect or look for.
we start by bringing up Microsoft SQL Server Management Studio and in the login box selecting to Browse for More servers than the ones local
On the Next screen we select the Network Servers tab and there we will see what it discovered.
Now for our next attack we will do a brute force attack but first we have to find out if the servers are configured for SQL Authentication and here management studio comes in to play again, we can select a sever give it bogus credentials and the error message we get back will tell us if it is.
When we get a message that says the user is not associated with a trusted SQL Server Connection it means that there is a miss match of protocol giving us the information that it does not support SQL Authentication. If SQL Authentication is enabled the message would be login failed message
Now that we know whish server to attack with the brute force we can choose the SA account but since this server is a MS SQL 2008 we know that since it is disabled by default we might have to try another one if SA fails, in our case we will assume we got the user meta from an IIS 500 error. in Metasploit we load the brute force login module for MS SQL
We have to give it our target host in the RHOST variable, the username to test in MSSQL_USER and the dictionary file in MSSQL_PASS_FILE. The THREADS will depend on the network connection and load of the target for this example I will leave it as it is but I tend to start with 50 and the reduce in increments of 5 if I get any error
Now that we have a username and password lets enumerate the MSSQL server with the enumeration module
We will provide the username and password we found in addition to the target and run it
Now we know what stored procedures are enabled or not, accounts, if policy is applied and a wealth of other information to continue our attack. One critical piece of information is that the instance is running as LocalSystem so we can get a shell on the system since if it was Network Service we would not be able to to start our shell, since nothing beats having a nice Meterpreter shell lets move from SQL access to shell on the host with the MSSQL Payload Exploit module
We set our values including our payload and we let the exploit module run
I hope you find this post useful and of help, this is only the basics of what can be done to and thru a MS SQL server.