SQL Injection: Deconstructing an Attack

As we wrap up our month of posts about SQL Server security and information about our SQL Server security checks, let’s talk about SQL Injection. We’ll deconstruct a pattern of attack we’ve seen before, and talk about prevention and awareness.

SQL Injection: Deconstructing an attack pattern

SQL Injection has existed as long as web apps have been accepting data and querying databases with user input. In short, SQL Injection is the practice of “injecting” a SQL command into an input box that allows it. If a site and SQL code are not built to be safe from this risk, an attacker can insert a command terminator like a semicolon and then add additional commands. Ultimately, the risk here is that the web application can be used to take over an entire network and introduce ransomware, take your domain down, and steal your data.

How?

We’ve seen this a time or two with clients who have called us after an attack or experienced an attack while a client. The approaches can vary, but in order to get from a risk of SQL injection to something bad happening, a few things have to occur:

1. The SQL has to “allow” for it. If the input isn’t validated and protected, it’s not safe.
2. The site has to “allow” it. If the web form allows free text—like a login screen that allows someone to pass single quotes and semicolons—an attacker has a blank slate to experiment.
3. The user and login in SQL for the application have to have permissions to allow for the attack to do damage.
4. The SQL Server service account has to be set up in a way that gives too much privilege to the service account.
5. The environment has to be unmonitored, with nothing outside checking input and output and looking for exploits.

There are many ingredients, even more than the simple list above. The point, however, remains—if a vendor isn’t following the best practices in their coding and the DBA and security teams aren’t doing their best to protect from issues, you’re creating an environment that is ready for attack.

A recent attack example

This pattern follows one we’ve seen a couple of times. It’s been around for a long time and it is still out there today.

An attacker hits a public website that accepts input parameters. Often, this can be a login page or a search page with dynamic searching receiving an unvalidated input box. They will attempt to see what inputs the site accepts. They try various escape characters and command terminators and see if the site accepts characters other than letters. If this works, they see if they can get the site to report back on what is found. If that works, they can figure out what level of permissions the service account running the application has inside SQL Server. Based on that, they can then attempt to turn xp_cmdshell on, turn ole automation on, and shell out to the OS to see what level of permissions the SQL Server service account has. Based on their success and permissions, they can install trojans and examine all of the services installed on the Windows server, looking for exploits. Based on the exploits and permissions, they can make your SQL Server become the entry for an attack into your network, spreading ransomware, stealing data, or taking advantage of exploits in various ways. Once an exploit is found, it can take seconds to minutes for a script to do all this work and completely compromise your network, data, and ruin your business.

Only You Can Prevent SQL Injection Attacks

I hope Smokey the Bear forgives the blatant theft of his slogan here. We’re getting close to wrapping up a month of security here, and we’re focused on the SQL Server angle. But there will be no risk if everyone involved in securing the environment, administering the environment, and developing apps for you has that same attitude.

SQL Injection attacks, like many attacks and disasters, are often a series of poor choices and ingredients adding up to equal an attack. In so many cases, if just one of the risks were mitigated, it’s likely that the attack wouldn’t happen.

We’re speaking to DBAs primarily here, but we’ll talk about a few of the safeguards your company should be implementing, whether it is the DBAs responsibility or not. At Straight Path, one of our values is “Ownership Mentality” – “it’s not my job” shouldn’t be in our vocabulary. At least not as an excuse to not care about doing the right thing. I think DBAs should have that same attitude. The firewalls and edge protection aren’t your “job” – but protecting the data is – and if you know about something existing, even it’s not in your role, you can still ask around and make sure your organization is doing something about it. So read the list, talk to your team, and make sure you are safe:

Develop/Purchase Safe Applications

Ask your vendors questions. Question the permissions they want for their apps. If they want their application service logins to have excessive permissions on the SQL Server – be a thorn in their side. Ask them why. Protest. Tell them they have to code around it. Don’t just “isolate” the app on its own server – those permissions when ingredients are right can still bring the entire environment down. They should have no server roles associated, and have minimum permissions in the database.

Also, application vendors should code their sites and database access in ways that are safe from SQL injection. Inputs should be typed appropriately, interrogated and validated, and only used to supply a query—users should not be able to escape in any way.

Layers of Network Security

Your applications should all be sitting behind Web Application Firewalls. This can be in the form of devices with software controls or firewalls as a service on-site or in the cloud. All of these tools (Imperva, Cloudflare, etc.) have some level of SQL Injection protection. Let’s assume that the developers made a mistake and allow something. The firewalls can add a layer of security which step in and identify SQL injection attempts and prevent them, even shut down access to the app when the patterns require it. These tools will also often see the internal and external traffic looking for patterns such as locations, known bad IPs, and even look for unusual amounts of data being sent out of the network.

Security Best Practices In Place in SQL Server

This one is yours 100%, and with all of the posts this month and our sp_checkSecurity, there’s really no reason to have applications running with permissions from SA, Control Server, Security Admin, etc. There’s no excuse for your SQL Server service account to be a local admin (or worse, a domain admin!). There’s no excuse to having features enabled like xp_cmdshell when you can avoid it. A locked down SQL Server with misses on the firewall and application development side can make a difference. An attack could still happen with misses, but the surface area of that attack can be reduced to damage within an application and not take down an entire network and domain.

In conclusion, it’s on you to have a safe and secure SQL Server. While you aren’t ultimately purchasing or developing the applications, you can work with your team and take a leadership role on security measures. You can take a leadership role by securing and locking your SQL Servers down and preventing the next attack.