This time of the year is pretty good in companies. Many people are enjoying the holidays, there's not that many problems in day-to-day job and everything is quiet. Perfect time of the year to perform some default configuration check that might be used by an attacker to compromise windows servers, data and any other information asset within the domain.

There's a pretty old extended stored procedure available in Microsoft SQL Server called xp_cmdshell. This procedure allows to execute commands in the operating system with the same rights as the Microsoft SQL Server service account. The procedure is pretty insecure and as of today is disable by default. It is used by many developers as a shortcut to easily develop distributed applications by invoking external applications and passing arguments as plain-text files.

So, what's the vulnerability? If you instruct your developers to always place a password to the SA user on their machines and tell them not to use xp_cmdshell, you are fine. Otherwise, people could connect to the Microsoft SQL Server instance using utilities like sqlcmd and execute commands like user creation and user group modification to add it to the administrators group.

How can you tell if there are Microsoft SQL Instances with a blank password for the SA user? You can take advantage of the ms-sql-empty-password nmap script. This script allows to perform a quick check in your network for that vulnerability. For example, if you want to check the empty password for the 192.168.0.0/24 network, you only need to execute the following command: nmap -p 1433 --script ms-sql-empty-password --script-args mssql.instance-all 192.168.0.0/24.

If you get any outputs like the following:

Nmap scan report for 192.168.0.144
Host is up (0.00s latency).
PORT     STATE  SERVICE
1433/tcp open ms-sql-s

Host script results:
| ms-sql-empty-password:
|   [192.168.0.144\MSSQLSERVER]
|_    sa:<empty> => Login Success
 

That means the computer has the vulnerability. If you can execute the following command successfully without any errors, you might be prone to other nasty vulnerabilities like windows local user creation, adding users to the windows Administrators group, changing windows user passwords, among many others:

sqlcmd -q "exec xp_cmdshell 'dir c:\'"

So, what do we need to enforce to prevent this problems? First, ensure that the SA user has a password by placing it. Second, disable the xp_cmdshell if you don't need it.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org