Attacking Microsoft SQL Server Databases

In the business of selling security solutions, not too long ago the phrase “defense in depth” dominated the messages. It was meant to evoke an image of defending each layer of the IT infrastructure with uniquely suited solutions. Now everyone recognizes that the notions about perimeter defenses are flawed. Real security is built into everything, not wrapped around it. However, there are many corners of the IT stack that seem to still behave as if security is going to be taken care of for them by other layers. Nowhere is this more evident in our experience than at the database layer. That isn’t to say that databases don’t have security built it. They do. Most simply don’t seem to be using that security supplied and largely seem unaware that it is there. In this edition of the ongoing STEALTHbits attack series, we will look at how Microsoft SQL Server can be discovered, attacked, and used as a vehicle for attacking systems and data. By the end, we hope you will have the information you need to become one of the exceptions to the rule and run MS SQL in a safe and secure way.

How Do You End Up With Insecure MS SQL?

If a vendor were to ask you to set up a completely new NAS device just to try out their software (assuming they were selling something other than a NAS device), you would likely laugh in their face. If a developer were to tell you they were going to run an instance of some accounting software with a copy of the production data on a server under their desk, you would hopefully have a whole list of complaints and requirements to make that near impossible without the right security and operational considerations. But for some reason when things like this happen with databases, most organizations don’t have a lot to say about it. Databases pop up all over the place. Many, of course, are set up in the “beg forgiveness instead of asking permission” model. A surprising number of organizations don’t seem to have either standards for the security of databases outside production or a means to discover where databases may have been improperly set up.

Some of this comes from the mistaken notion – related to that “defense in depth” idea – that security will come from somewhere else. The image is of the database living in some highly secure, central part of an IT infrastructure protected on all sides by other controls that keep it safe even when the rest may be under attack. This is clearly false in today’s reality. This also comes from old habits where the database was often seen as a mere extension of the application that used it. The application layer took care of security, so the story goes, and the database is protected that way. In this view, it’s often considered a bad idea to configure too much database security out of fear that it may interfere with the application’s operations! Now that we live in the “everything under attack always” mode, all of this must be swept aside.

Another guilty party that can’t go without mention is the large number of software vendors that encourage bad practices in database security. Some of that is the same as above, but some are the vendor and the eager internal champion trying to rush to get the software installed. That often means setting up a soft database for expediency. While it’s just a pilot, that may not be seen as too risky (hint: it still is). However, quite often those pilot systems simply get slid over into production as is. In a virtualized world, it’s easy enough to double or triple the capacity of the systems to allow them to handle production loads. But how often do the security settings of the new solution’s components get reviewed? If there is a review, how often does it include the database?

What We Cover In This Blog Series

As with many other editions in these attack blogs, we will go step by step through the steps of the attacks and our suggested mitigations. The steps for this series will be:

• Step 0: Get some credentials.

If you’ve been reading the attack blog series until now, you’ve seen we have focused 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. Of course, AD is the hub for so much access to data in any organization that it may feel like those attacks actually compromise everything else. We won’t go into those again, but encourage you to check all of that out to see where your attacker will likely begin.

• Step 1: Find some databases and compromise them.

MS SQL will often advertise itself on the network. This is very good for applications looking to source data and even better for attackers looking to steal that data. We’ll use some of the tradecraft available for free to find where there are databases and see if we can knock on the front door to get in easily. Here you will see us use nmap, medusa, and discuss metasploit.

• Step 2: Use a toolkit to own the databases.

Like nearly every other aspect of IT, there are kits for MS SQL that will help you to compromise poorly protected systems. We’re going to explore PowerUpSQL. PowerUpSQL really is the swiss army knife of MS SQL cracking. It can do everything from discovery through persistence. We will only scratch the surface, but even then we can do some real damage.

• Step 3: Use compromised MS SQL to attack other things.

The interesting thing about MS SQL, in particular, is its complicated relationship to the operating systems on servers where it runs. That relationship can be easily exploited to take a compromised SQL system and reach out to compromise a whole lot more of the network. We’re going to look at that and see how dangerous it can be.

Along the way, we will make suggestions to help ensure that all of this stays theoretical in your world. And we hope that you’re not going to need any of that advice.

Learn about how STEALTHbits addresses SQL auditing and monitoring with StealthAUDIT for SQL here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*