On a recent external web app pen test, I found a possible SQL injection vulnerability using the Burp Scanner. One of the tests triggered an A record lookup for the Burp Collaborator server. In the screenshot below, we can see the test that triggered the finding.
We can see that a local variable, @q, is declared and is set to a UNC path of a random subdomain for the Collaborator server and a random directory. @q is then passed as an argument to the xp_dirtree stored procedure. Xp_dirtree is an undocumented stored procedure that will list all directories, subdirectories, and files in the specified directory.
Based on some previous work on this engagement, I suspected that the perimeter firewall had a very relaxed egress filtering policy. I wanted to test this, so I modified the query to point to the IP address of one of my servers. Sure enough, outbound SMB was permitted, so I was able to receive an SMB connection triggered by the SQLi.
Whenever a Windows system tries to connect to a UNC path, the host will try to authenticate to the remote server by passing the user’s password hash. In other words, I could force the SQL server to authenticate to me and give up the password hash of the user account running the SQL server process!
With this in mind, I fired up the Metasploit auxiliary/server/capture/smb server module. I triggered the SQLi and waited a few seconds for the SQL server to connect and voilà! we have a hash!
Abusing SQL server via xp_dirtree and SQLi isn’t a new concept. You can read more about it in Bernardo Damele Assumpção Guimarães’ 2009 Black Hat Briefings Europe slides. Holly Graceful also has a great blog on out-of-band data retrieval via SQLi using xp_dirtree. If you run into a blind SQLi where you can execute xp_dirtree but don’t have SMB egress, you can still exfiltrate data using Holly’s method.
If you happen to encounter SQLi on an MS SQL server in the future, you now have a few more tools in your toolkit. Good luck and happy hunting!