The Constant Challenge of SQL Server Security, Part I

In the first entry in this SQL Server security series, we will demonstrate a brute force attack against SQL Server and discuss various techniques to protect against one. Brute force attacks are nothing new. They have been around for a long time and are very simplistic by design. The recent coverage of Apple vs FBI has brought up the topic again, as many news sources claim that the FBI is requesting a tool to “brute force” the pin of a locked phone.
Brute force attacks are named as such due to their design. This type of attack has no real “brains”, like you see with social engineering techniques. A password file is fed into a login tool and away it goes. Hammering and hammering until it is out of potential passwords or is successful.
In June of 2015, I added two tools to the Microsoft Technet Gallery which can be used to help achieve better SQL Server security. The first tool is a T-SQL script designed to reveal any SQL Server authenticated logins have either a blank password or a password matching the login name. The second is a console application designed to demonstrate a brute force attack.

SQL Server Security Fix:  The Brute tool

Start by downloading the tool here: https://gallery.technet.microsoft.com/SQL-Server-authenticated-79c063c6. The download includes the full C# source code.
Once the source is downloaded, you can either choose to open the file in Visual Studio (2013 or later) or navigate to the debug directory, where you’ll find the executable. The two files needed to run the demo are Brute.exe and Library.txt.

• Brute.exe – Simulates an attack on the server.
• Library.txt – Contains a list of sample passwords to feed the brute application.

Running the demo

The Brute application has a few switches. To view which are available, run the application with the -? switch.
Switches

• Help -?
• Server name -crack:[server name]
• User name -U:[user name]
• Show Library -List

Example
BRUTE -crack:SQL01 -U:Joe

Brute force in action

For the purposes of this blog I have created a user named Steve. To run the demo, we drop to a command prompt and execute the following:
Brute –crack:. –U:Steve

Now that we’ve been attacked, where do we look?

The easiest place to find this type of attack is in the SQL Server error logs. The error most commonly seen is 18456. Though this can appear for many reasons, you’ll want to examine the error reason and look for “Password did not match”. It’s worth noting that this can occur from normal activity, where a user simply mistypes the password; however, in the case of a brute force attack you’ll see hundreds or thousands of these errors.

Now that we know what to look for, how can we protect ourselves?

One simple method is to ensure our SQL authenticated accounts do not have weak passwords and will lock out when too many attempts are made.
You can do this by checking the Enforce Password Policy box when the instance is on a domain.
Too many failed attempts at logging in will result in the following:

While a locked account may cause interruptions in the environment, it’s better than the data being compromised.
In the next part, we discuss implementing SQL Server security best practices using Policy Based Management. Stay tuned!