Securing Your Remote Database Server
When it comes to DB security, things get really ugly in a hurry. You can see this for yourself by using the following Microsoft SQL Server Metasploit module:
We know you’re busy and may not have time to test every single exploit against every single version of SQL Server that Metasploit offers, so we wanted to give you a leg up on getting started with the basics. We also want to show you how easy it is to gain access to password hashes when they are stored locally in clear-text inside Exchange databases (see Figure 1). This article will cover techniques, attackers use to gain access to SQL Servers and how you can stop them.
Is your organization using insecure remote desktop (RDP) connections that allow end-users full access to their databases?
Do you have scripts that run at login and/or during the day with elevated rights?
Are you looking for quick ways to get an administrator shell on a SQL Server instance?
If any of these sounds is familiar, then your database is at risk of being compromised. You must harden this critical server or else risk losing your data, having it exfiltrated by attackers, and even dealing with ransomware encrypting all of your production databases! If you’re responsible for protecting a SQL Server environment, then you need to read this article. Don’t worry, you don’t need to be a security pro – just follow our advice and you’ll be able to sleep soundly at night knowing your databases are secure.
It’s About Time The one-two punch of ransomware and information exfiltration has the SQL Server community on high alert, but there is no silver bullet that can solve all SQL Server security issues. Instead, organizations need to harden their servers with the right combination of tools for their specific environment. They must also understand how attackers work so they can stop them before they successfully attack their servers. This article will help point out some common mistakes administrators make when securing their SQL Servers and offer defensive recommendations to protect those systems. We will give an overview of how attackers compromise these servers and some common attack vectors we see in the wild.
Attackers use a variety of techniques to gain access to SQL Servers; however, their end goal is usually the same: get SA (system administrator) rights on the server so they can execute OS commands or install/upload an application like Meterpreter. What you really need to understand is how attackers gain access to remote databases because not every environment installs SQL Server with local OS accounts with SA privileges. The first step for attackers is usually trying different OS user names and passwords to connect to SQL Server using a client application like sqlcmd.exe or bcp.exe. If the OS account doesn’t have access, then it’s time for them to move on and find another way in because if they can’t get in through one avenue, there will be other vulnerabilities in the environment that they can exploit.
1: Password hashes stored inside Exchange databases
This is why it’s crucial for administrators to map out their entire infrastructure and understand how each system connects with all others. The more you know about your environment, the better prepared you’ll be when trying to secure it from attackers. In this article, we’ll explore some of the techniques attackers use when compromising these systems along with some defensive steps you can take to harden your SQL Servers.
SQL Server OS and Application Accounts Attacks against SQL Servers often start with attackers trying to guess or crack passwords on local OS and application accounts used by the database engine. If attackers can gain access to these built-in accounts, they have a good chance of elevating their rights from whatever low-privileged account they started with all the way to SA! We’ve found that many administrators don’t pay much attention to securing these components, which makes it pretty easy for attackers.
A script running as SYSTEM using a remote RDP session
For example, we were recently contacted by a company whose customer had been infected with ransomware, which encrypted five of their databases hosted on the DAG cluster. We worked with them to analyze the compromised servers and found that one of the DAG member servers had been running a script on startup using a local administrator account. The script was designed to manipulate Exchange mailboxes, but it also started an RDP session by using that same admin account on another server. That opened up their environment to attackers who were able to get on that machine and use remote desktop protocol (RDP) to log in as Administrator and gain access to all of the SQL Servers.
Accordingly, we find many cases where administrators don’t disable unnecessary OS accounts including SA, which makes it easy for attackers with valid user credentials or password hashes to connect via sqlcmd.exe or bcp.exe from any other system in the network. In these cases, once attackers have access to OS credentials inside a database, they can often map out the entire SQL Server environment by using the sys.dm_exec_sessions DMV and system stored procedures that return information about all running sessions. Some of those stored procedures include: S accounts.
Conclusion:
Make sure you disable all OS accounts that are no longer needed like say, which can be disabled by running this SQL script.
