Protect Your Windows Network: From Perimeter to Data

As we saw earlier, the database server is not directly accessible from the Internet, and our front-end Web server is fully patched and not vulnerable to anything. Our objective at this point is to elevate our privileges so that we become an internal user , preferably a highly privileged one, on one of the systems in the target network. To do that, we will use the SQL injection to send commands to the database server and ask it to do things for us.

It is important to note here that we cannot connect directly to the database server, so instead we will ask it to make a connection to us. We will start by setting up a listener on our attacker machine. Then we will make the database server connect out to us.

Before we can control the database server we need to get some tools onto it. This is important because, generally speaking, attack tools are not installed on the operating system by default. There are several techniques for getting our tools (often called "warez") onto the database server. A simple option is to use a file transfer protocol such as the Trivial File Transfer Protocol (TFTP). TFTP is a connectionless file transfer protocol used primarily for booting diskless workstations. However, the client application for TFTP is installed on all Windows systems by default. Because we have an SQL injection vulnerability, we can use it to tell the database server to use TFTP to get our tools. The first tool we will upload (download?) is Netcat. Netcat is a network tool somewhat like Telnet, except that it is much more versatile and is unauthenticated. It is freely available on the Internet and even comes standard on many UNIX and Linux distributions. It is pretty much universally used by attackers , however, and should never be left on a system where it is not absolutely needed.

At this point, we do not know what privileges we have on the database server. Our commands on the database server will execute as whatever user the Web application uses to connect to the database server. This could be anything, but far too often that connection happens with too high privileges. Many Web programmers use the sa account for this because (1) everything works that way because sa can do anything, and (2) there is less to type because sa usually has a blank password.

In this case, the connection does happen as sa, which means we have access to the xp_cmdshell extended stored procedure (xproc), which is only available to system administrators by default. Xp_cmdshell is used by SQL Server to execute operating system commands, which means that if we pass it the right parameters, SQL Server will actually execute any operating system command we want. Xp_cmdshell is installed by default on SQL Server 2000. Using the SQL injection attack, we call xp_cmdshell and ask it to call TFTP and have it, in turn , connect to our attacker machine and get Netcat from there.

TIP: Xp_cmdshell is rarely needed in many deployments, and can be disabled as a defense- in-depth measure to protect against exactly this kind of attack. For more details on how to do so, see Chapter 14, "Protecting Services and Server Applications." In SQL 2005, xp_cmdshell will no longer be installed by default.

Use of xp_cmdshell is logged in both the SQL error log and the Windows application log. However, an attacker that can run xp_cmdshell can almost certainly delete arbitrary events from the SQL error log and possibly also from the application log.

Once we have uploaded Netcat we run xp_cmdshell again and execute it. We tell Netcat to create a socket, and then pass that socket as stdin (input), stdout (output), and stderr (error output) in a call to cmd.exe. This sounds complicated, but it works reliably. The net result is an outbound connection where we pipe a command shell over a socket. We now have our remote command line on the attacker host:

c:\>nc -l -p 12345 Microsoft Windows 2000 [Version 5.00.2195] Copyright 1985-2000 Microsoft Corp. C:\WINNT\system32>hostname hostname PYN-SQL

At this point, we have established our first foothold and are well on the way to taking over the network. We have escalated privileges from a remote anonymous user to an inside user. To find out what kind of user, we need to first get the rest of our tools onto the system. Those tools will be used to escalate local privileges if needed as well as to hack the rest of the systems on the network. We can transfer those too using tftp.exe. After we have done that, we can verify our credentials on the host:

C:\Warez>whoami whoami NT AUTHORITY\SYSTEM

Bingo! We are already LocalSystem. That must mean the SQL Server is running in the LocalSystem context. When we told it to execute xp_cmdshell, it executed the commands we passed in as LocalSystem as well. That means we have already completely compromised the back-end database server. We can now proceed to hacking other machines on the network. At this point, our first host has been compromised, as shown in Figure 2-1a.

Before we continue, it is worthwhile at this point to stop and reflect on why we have been successful so far:

• The first entry was made using a poorly written Web application (Chapter 16, "Evaluating Application Security").

• The flawed Web application allowed us to pass commands to an unhardened database server (Chapter 14, "Protecting Services and Server Applications").

• The database server is allowed to make outbound connections through the firewall. To learn more about how to use egress filtering with firewalls, see Chapter 7, "Protecting Your Perimeter."

• If your firewall does not support egress filtering, you need to filter such traffic on the host. Chapter 10, "Preventing Rogue Access Inside the Network," shows how to set up those filters, and Chapter 9, "Network Threat Modeling," discusses a technique to analyze which ports you need to allow through.

• Finally, we used a tool installed by default to upload the necessary tools we needed to complete the attack. Without those tools, this attack would be considerably more difficult. The tool we used was tftp.exe, but there are other tools that can be used for the same purpose. Use of these tools needs to be restricted to only those users who absolutely need them. Chapter 12, "Server and Client Hardening," talks about hardening individual hosts against these types of attack.