First Defensive Layer: Eliminating First-Layer Attacks

Executing many of the stored procedure attacks we have explained requires that you already have sysadmin-level access within SQL Server application. It is obvious that you can gain this level of authority by directly defeating SQL Server's security, but it can also come from attacking and defeating Windows itself. The key to eliminating first-layer attacks, therefore, is actually just following good security practices in regards to both Windows and SQL.

alt1 Note

Prior to SQL Server 2008, administrator-level access within SQL Server was automatically provided to the local administrators group of the Server (if it was set for either mixed mode or Windows authentication). This means that if you gain local administrator membership on a machine running SQL Server 2005 or earlier, the database is automatically yours. Of course, this does not mean that you won't be able to easily find a way to gain sysadmin-level access in SQL Server 2008 if an attacker “Owns” the machine, especially because the built-in administrator account is still provided this authority, but it is no longer automatic.

The subject of securing either your Windows operating system or your SQL Server implementation is covered in many other books that are much larger than this one, so we obviously cannot go into all of the details surrounding how to do this. We can, however, hit some of the high points related to blunting general attacks.

Implement the Strongest Authentication Possible

We feel that this is so important that “password attacks” is the subject we chose as the most dangerous attack against Windows itself as covered in Chapter 1, “Windows Operating System – Password Attacks.” Weak passwords on default accounts are often one of the things both attackers and penetration testers go after, and it is scary how many times this works, even in environments that are supposedly “high security.” The need for strong authentication is important regardless of the account type or authorization level, but it is doubly important when you are looking at privileged accounts that have administrative rights within an application.

Attackers have many tools at their disposal today that allow the automation of dictionary and brute force password attacks against Microsoft SQL servers. The tools are used by attackers and penetration testers and are usually easy to configure. Some currently available applications are listed in Table 3.1; however, these are just an example as there are many other similar tools.

Table 3.1. SQL Server password attack tools

Hydra	SQLBrute
SQLPing	Cain and Abel
Metasploit framework

SQL Server has built-in integration with Windows security and you should use this whenever you can. This is especially true when the Windows server is part of a domain and account credentials and passwords are stored in active directory (AD) rather than the local machine. Regardless of where the credentials are stored (whether it is AD, the local SAM database or within the SQL Server database itself), implementing strong password policies such as minimum lengths, complexity, and lockout periods is critical to limiting the effectiveness of password based attacks. As long as your SQL Server is running on Windows Server 2003 or later, you should also always select the Enforce password policy option within SQL Server. This option automatically enforces all of the same password policies of the computer against the SQL logins, which includes the sa account.

Even better than having strong passwords is requiring two-factor authentication mechanisms for all privileged accounts. Windows natively supports mechanisms such as biometric scanners, smart cards, and tokens. Since Windows supports these, you can easily use them for all of your integrated accounts. In addition, SQL Server 2008 running on a Windows 2008 platform fully supports two-factor for biometric and smartcard certificates. Although two-factor systems can have their own problems and vulnerabilities, generally they are more secure than even a 100-character password with upper- and lowercase letters, numbers, and symbols.

Implementing End-Point Security Mechanisms

Although some end-point security solutions (such as an antivirus solution) are given in today's world, many security administrators think of end-point security solutions only in terms of their workstations rather than their servers. In our opinion, this is a mistake. Relying on network systems such as firewalls and intrusion detection system/intrusion protection system (IDS/IPS) to protect the server infrastructure provides an attacker with only one system to defeat. In addition to network systems only providing perimeter security, most of the administrators of these systems have concerns regarding performance that will preclude you from being able to define detailed access control lists (ACLs) and policies for every server.

By adding desktop firewalls and host-based IDS/IPS to the server running SQL Server, you are able to prevent certain actions, or alert someone to these actions, based on different kinds of activities that occur on the server during normal operating conditions. Using and tuning these solutions properly can even make it so that certain actions can only be performed from a management subnet or the internal network. This may not stop every attacker, but it would definitely slow one down (at least one who isn't using an internal zombie that they already own).

In addition to traditional IDS and IPS implementations, administrators may choose to deploy IDS/IPS systems that detect and alert administrators of attacks against SQL server instances. This will provide advanced knowledge of pending attacks and other suspicious activities to network administrators and security personnel.

Employ an Efficient and Well-Defined Patching Process

Some things seem obvious to an attacker, if Code Red will still work against an SQL Server (and it is scary that even today we still see this in the wild) then the “administrator” is more likely to be Bob from accounting than an IT security professional. The unfortunate reality is that no developer can anticipate every possible attack and no software company can afford to make their application 100% bulletproof before they release it; therefore, it is vitally important to ensure that vendor patches for the operating system and applications running on a system are applied as quickly as possible. This may seem pretty straightforward; just have Windows and all of the applications automatically download and install patches from the vendor as soon as they are released. Sadly, things don't get to work this easily in the real world.

In a working environment, SQL Server is generally a part of the backbone of some business processes and therefore concerns about issues such as performance and downtime are valid. With this in mind, most updates and/or patching must actually occur during regularly scheduled support windows rather than when the update or patch is first released. The design of the patching process must understand this and balance the criticality of the patch with the risk of downtime for this server. This balancing act can mean that the most critical servers are actually the servers that get patched the least, and this should not be acceptable from a security perspective.

One way to combat this situation is to define a solid business and technical process related to patching your SQL Servers. This core process should start with defining categories for the criticality and priority of each update or patch (the number of categories an organization defines is up to them). The process should then evaluate the criticality of each system and define timelines and procedures for each of the categories previously defined. Once these guidelines are in place, each update or patch should be evaluated when it is released from the vendor and immediately assigned to a category. Once the patching category is defined, the process and timeline for the implementation of the update or patch on each system should already be defined. You must actively monitor the criticality of an update or patch until it is fully implemented and you should reevaluate the category it is assigned to, if the situation changes. For example, if a vulnerability is found in Windows and a patch is released on a Tuesday, but there is no exploit code in the wild, then you may assign the patch into your “standard priority” category. Everything sounds good at this point, but let's say that on Wednesday someone releases an exploit for the vulnerability the patch addresses.

From a security perspective, the vulnerability has now gone from a theoretical to an active risk and you must be able to act accordingly. This change in circumstances doesn't automatically mean that you have to change the designation from “standard priority” to “critical priority,” nor would a change in category necessarily mean that you would apply the patch to your SQL Server any sooner. The crucial element here is that your process must allow you to actively reevaluate the criticality of the patch based on the change in circumstances and act according to the new evaluation.