Scenario 2 – making a mess with MSSQL

Many people enable Microsoft SQL Server (MSSQL) for personal projects from their work computers (I know that I run an MSSQL Server on my laptop 90 percent of the time). Unfortunately, some of those people leave the settings as default. As before, we're going to be using default credentials as the initial attack vector, but this time, we're going to follow up with some Metasploit action. This is a pretty standard scenario for beginners to run through.

Setup

We are going to create an MSSQL Server instance on your host, and then open it up to external access. We'll go through it step by step so that it's nice and easy. You will need MSSQL Server 2005 Express and MSSQL Management Suite to complete this. There are newer versions of MSSQL available, but the use of MSSQL Server 2005 is intentional, as it grants more options for attacks. Perform the following steps:

1. First of all, download MSSQL Server 2005 Express from http://www.microsoft.com/en-gb/download/details.aspx?id=21844. Follow the standard process until you hit the Authentication Mode screen, which is shown in the following screenshot:
   

   It's important to set this to Mixed Mode (Windows Authentication and SQL Server Authentication) and set the credentials to something guessable. For this example, I've used sa:sa. These are the most common default credentials for SQL Servers on the planet. If your flag captors don't guess this, send them packing. Complete the installation by phoning it in; everything else should be clicked through.

2. Second, download MSSQL Management Suite 2008. This is available from the Microsoft site at procedure and then set up a MSSQL database in the following manner:
   1. Run the .exe file, select Installation, and then select New SQL Server stand-alone installation or add features to an existing installation. In the following screenshot, this is the topmost option:
      
   2. Proceed with the installation; click through until you reach the choice of installation. Select the Management tools – Basic option—everything else is unnecessary. The following screenshot shows how it should look:
      
   3. Once all the options have been completed, boot up SQL Server Management Studio and log in with the credentials you set earlier (sa:sa if you used my choice). You should be presented with a screen showing the standard layout of a SQL Server. This proves that the server is running.
   4. Finally, before going away and giving the server a good kicking, open SQL Server Configuration Manager, browse to SQL Server Network Configuration (32bit), and then browse to TCP/IP. Double-click on TCP/IP, and make sure that the port you want to run MSSQL on is completed in every network adapter that you want in the TCP Port option, as shown in the following screenshot:
   
3. From a separate machine, run an Nmap scan against the host, and make sure that your port 1433 (in this case) is open.

   Tip

   Nmap is a network mapping tool that is installed by default on Kali Linux. What it does is that it attempts to connect to ports on a host and returns whether they are open or not. The exploit guides contain specific strings to use when attacking, but the following are useful for now:

   • The nmap –sS –vvv –p- <host> command will scan all TCP ports on a host and return verbose output
   • The nmap –sU –vvv –p- <host> command will scan all UDP ports on a host and return verbose output
   • The nmap –sS –vvv –p <port> <host> command will scan the specifically designated port on a host and return verbose output

   If you're experiencing trouble, check whether:

   • Windows Firewall is disabled or an exception is made for MSSQL.
   • Any antivirus is turned off. The Meterpreter payload we will be using is essentially a Trojan, so any antivirus that isn't just pretending to be secure will pick it up.
   • MSSQL is configured to listen on the port you selected previously. Run netstat –a to check.
   • As a last resort, put your desired port in the IP ALL option in the server configuration tool.

Variations

Once it's up and running, you have some choices. If you have the time, you can populate some data as red herrings (or as the objective of sub-challenges if you wish). As you'll find in real. These can also be scripted quite easily to generate fluff data. Alternatively, you can leave it as a test environment and leave the scenario as attacking a developer in progress.

When you're satisfied that you've made it lifelike enough, roll out your Kali box and smack that MSSQL installation around a bit. The guide to this is, again, at the end of this chapter.

Your brief is once again important. The suggestions here are:

• Collect X records from a MSSQL database using default credentials
• Exploit a vulnerable MSSQL database using Metasploit and a common web vulnerability
• Gain a foothold on the box running MSSQL