What to Do with Your New SQL Kingdom
In the last posts, we explored ways to gain access to MS SQL and to extract the data it contains. The fun thing with MS SQL, though, is that is just the start. Every application has a certain amount of access to other resources. Databases generally have a lot of low-level access to system since their whole purpose in life is to optimize access to data. That means augmenting some basic IO and process management approaches – tasks which require the ability to touch OS functions with high privilege. Microsoft is no exception here, and one might even say that the close relationship the MS SQL platform enjoys to its host OS grants it even more power to be a vehicle to exploiting the layers below. So we will now look at some ways that owning the database can help you own the system it is on, and maybe even more beyond that.
To do these bad things, we will focus on using the access we already gained and working within the MS SQL system itself – so get ready for some SQL statements and commands. I will stick to using the basic command line (sqlcmd.exe), but everything I’m going to do would work in any IDE or other UI that allows SQL and commands to be entered. It is also worth noting (as we have in previous posts) that you can look to a comprehensive system like Metasploit or PowerUpSQL to do much of the heavy lifting here. We will look at the individual commands so we are doing the homework to understand what is happening under the hood a bit. But if all you want it to skip to the end, maybe one of those frameworks is a better choice. Infosec Institute has a pretty good walkthrough on using Metasploit (in the Linux Kali incarnation of the tool) to do much of what we will cover here.
Stealing All Hashes
Possibly the simplest attack you can mount outside the owning and data exfiltration is grabbing password hashes. If you followed our former advice, then you would be keeping the number of SQL native account you have to a minimum and making sure the password complexity is very high. However, most seem to feel that isn’t needed since they still subscribe to the “hard outer shell” approach to security. So you can find some good hashes to crack in the database. You may also find passwords here that are repeated in other places that are more vulnerable here.
Taking the passwords couldn’t be simpler. You already have system level access from your previous progress, and now you just run this SQL:
One of the nice things about databases is they tend to label everything for you. Of course there is a column named “password_hash” to make things easy. You’ll get results like this:
Hashes in hand, you now go to your favorite hash ripping tool to find the passwords, or maybe use the hashes themselves in compatible PtH style attacks.
Getting OS Right from SQL
One of main reasons bad guys targeted MS SQL early on was how easy it was to get to the OS from inside of SQL. The OS was typically a bit more well protected than the SQL layer. So you took the easy route and targeted SQL. This is still true, but security has improved on every layer so there are some new steps needed. The biggest change is that xp_cmdshell, the easy path from SQL to the OS, is no longer on by default. You must activate it in order for it to work. Of course, once you have system access, this is only a SQL command away. Here’s how to enable it:
Once you have this enabled, you can now run commands on the OS level and they will run as if you are the SQL Instance itself. Running them is quite simple:
By the way, if you are seeing a lot more line breaks and empty lines in your output when you follow along that is expected. I’m removing a bunch of that to make the post more readable.
As you can see, the xp_cmdshell is powerful. With a little creative thinking, you can see how you might enable this, do a few bad things, and then disable it before any one notices the setting change. Many organizations will filter out the activity of the SQL Instance on the server where it runs since there is so much of it and most is noise. That means you also have a decent chance of evading monitoring and log scraping using this method.
Persistence with Control Server Rights
The classic persistence trick is to install a backdoor. This often comes in the form of a user with elevated rights, or a user that has the correct rights to perform some exploit to elevate rights as needed. MS SQL gives you a way to do this without need for any exploits. Remember, you are logged on now with SysAdmin rights. So you can do whatever you want. But you know you can’t stay that way forever without being noticed. What you do is either create an account or grant to an existing account the ‘Control Server’ permission. The notion behind this permission is sound enough – it’s an attempt to allow you to achieve least privilege operations. You can give an account this permission and then it can do many operations without being a full SysAdmin.
The trouble with ‘Control Server’ is twofold. First, the number of things this permission implies is quite large. So even though is it not a full SysAdmin, we will see it can effective be just as powerful. Second, it is not something to which people are generally paying attention. The logins that have this permission aren’t often audited nearly as well as those who are full SysAdmin level. That means they can fly under the radar. Maybe that’s OK because the thing you’re predicting I’ll do with this right is mint myself a full SysAdmin and that will be caught. That’s where the clever combo of ‘Control Server’ and another right can be used to circumvent things. First, let’s give ourselves a login with this right to use:
Once we have that right, we can log on as that user and do something else tricky. This one is a little long, but we’ll break it down immediately below:
What happen here is this:
At this point, we have a login, agentx, that can act as sa at will to do anything. Since it’s not a persistent holder of that role, it will not show up in typical audits. That is a powerful bit of persistence.
How to Prevent All This
Clearly, there is a lot more we can do with the tools we’ve built up in this post. We can do anything the SQL Instance can do, and we can hide from typical detection methods while doing it. We only scratched the surface here. There are ways to use ownership chaining, another SQL feature, to extend the reach of these methods across many systems. We can leverage the right of the Instance to write files into system directories to drop in other malware and tools. The list is very long. All of that starts with these basics and you can choke off much of it by preventing these first steps. Things you should consider to prevent these attacks are:
Learn about how STEALTHbits addresses SQL auditing and monitoring with StealthAUDIT for SQL here.
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.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.