1. Protecting SQL Server 2005
It appears that hackers are always finding
new ways to attempt to break into systems and applications. With the
wealth of information available inside databases, these types of
applications have become prime targets for mischievous users. In this
section, we will cover how SQL Server addresses some of the issues
around security as well as some of the things hackers do to try and
exploit your system.
Reducing the Surface Area for Attack
The more doors you have in your house, the more
opportunities an intruder has to break in. Even if those doors are made
of solid steel, each with a nice shiny lock, they are still considered a
surface area that is vulnerable for attack. One way to eliminate this
vulnerability is to not have a door where you don’t need one. The
computer application equivalent is that if you are not using a
particular feature, turn it off if possible.
Out of the box, SQL Server 2005 provides a
reduced surface area for attack by automatically turning off features
that are optional. These features include the SQL Server Agent service,
SQL Server Browser service, and various server functions including xp_cmdshell,
using the common language runtime within SQL Server, and others. The
management tool that allows administrators to turn on and off these
features is the SQL Server Surface Area Configuration tool. This tool is
installed as part of a database engine installation, so you should have
it regardless of which edition or components you install.
When the tool is launched, you get two options:
Surface Area Configuration for Services and Connections, and Surface
Area Configuration for Features.
The Services And Connections dialog box (Figure 1) shows a treeview list of sql components that are installed on the server.
Under
Database Engine are two panels. The first panel, Services, allows the
user to start, stop, and change the automatic startup settings of the
service. The other panel, Remote Connections, is perhaps one of the more
important switches to remember. By default in Express, Evaluation, and
Developer editions of SQL Server, remote connections are disabled. Thus,
if you install Express Edition and try to connect to it from another
client machine, the connection will fail. To enable remote connections,
you must choose which kind of remote connections to allow.
Note
If you allow remote
connections and have trouble connecting, check your firewall settings.
You might have to add an exception for the Sqlsvr.exe process or open a
specific port for SQL Server. |
The other important feature of this tool is the
ability to configure which features should be on or off. Clicking on
Surface Area Configuration For Features launches the dialog box shown in
Figure 2.
In the figure, you can see that the tool allows you to enable and disable the use of the xp_cmdshell
extended stored procedure. Other features that can be turned on and off
include the common language runtime, ad hoc remote queries, and Service
Broker.
Each of these options can also be programmatically turned on and off via the sp_configure stored procedure. To view these options, set the show advanced options property on sp_configure first. There is also a new system view called sys.configurations that effectively shows the same information as sp_configure with show advanced options set.
2. How Hackers Attack SQL Server
To
begin this section, we must start with a disclaimer. This section does
not cover every possible way that hackers can attempt to compromise SQL
Server. It is meant to introduce the various methods of exploitation and
get you thinking about security when you design database applications
and configure your system. Let’s start the discussion with topics
related to how SQL Server is configured.
Direct Connection to the Internet
Exposing any operating system or application
directly to the Internet without the use of a firewall is a bad thing—no
matter whether you are using Linux, UNIX, Windows, or any other
operating system. It’s rather like the carnival game where someone sits
on a platform above a pool of water waiting for someone else to throw a
ball and hit the bull’s eye. When it happens, the person sitting on the
platform is plunged into the water. Why expose your system, allowing
anyone to take shots until they finally get you soaked? Microsoft has
done a lot of work around protecting its operating systems and
applications out of the box. When an exploit happens, they quickly
address these problems and provide fixes.
This is only half of the battle, though. With
all the switches and states of security for various products, it is not
that difficult for an administrator or user to accidentally misconfigure
something and expose the systems to exploits. To mitigate these issues,
it is very important that users isolate their systems from the Internet
via firewalls and use other isolation techniques.
Weak SA Passwords
One of the easiest ways to give someone the keys
to SQL Server is by providing a weak password for the system
administrator account. In previous versions of SQL Server, it was
possible to give a blank password for the SA account without much
complaint from SQL Server itself. SQL Server 2005 has a lot more
functionality around password policies and enforcement.
SQL Server Browser Service
SQL Server uses UDP port 1434 to return SQL
Server instance names and port numbers to the requesting client. A few
years back, this enumeration was the key to the “SQL Slammer” DoS virus.
By consistently hitting the server with requests for enumeration, the
virus left the server too busy to process other requests. In SQL Server
2005, this enumeration functionality is in a separate service called the
SQL Server Browser service. The functionality no longer runs in SQL
Server’s process space, and it can be turned on and off without
affecting SQL Server. If you do not
want to use the SQL Server Browser service, you can still connect to
other instances on your server, but the connection string must contain
additional information (such as a specific port number in the case of
TCP connections). If you want to use the Browser service in your
organization, you can mitigate additional attacks by blocking UDP port
1434 on your firewall.
SQL Injection
SQL injection is the process by which a
malicious user enters SQL statements instead of valid input. For
example, suppose a Web site is asking for a user name. Instead of
actually typing in a user name, a malicious user might type ‘blah’; DROP TABLE sales;. The Web server will happily take the user input and pass it to its middle layer, where it is executed in code as follows:
SqlCommand cmd = new SqlCommand("SELECT * FROM sales WHERE name='" + s_Customername + "'
",myConnection)
To SQL Server, it looks like the following:
SELECT * FROM sales WHERE name='blah'; DROP TABLE sales;
When it is executed, the sales table will be
erased. You can see how easy it can be for malicious users to cause
problems and return potentially sensitive information via simple inputs
to Web pages or applications that directly use user input. To mitigate
this particular issue, you can add the user input as a parameter to the SqlCommand, as shown below:
Using (SqlCommand cmd = new SqlCommand("SELECT * FROM sales WHERE name= @s_CustomerName"
, myConnection));
{
cmd.Parameters.Add("@s_CustomerName",s_CustomerName);
...
To SQL Server, whatever the user types will be considered just the value of the name part of the where clause.
Intelligent Observation
With the advent of powerful search engines such
as Google and MSN Search, finding things on the Web is relatively easy.
Web crawlers from these search engines go off and fetch key words and
place them into their own internal database. These key words are used
within their own search algorithms so that when you type something to
search on, the search engine can easily return a list of possible
choices. These crawlers not only search for and store such things as Web
sites for pizza places, but they also obtain various kinds of error
information returned from Web servers. This information is very valuable
to a hacker. For example, if a hacker types invalid password access denied into the search string in MSN, he’ll get a list of various topics that are, in general, not that interesting. However, one item will show this string: Warning:
mysql_pconnect(): Access denied for user ‘root’@‘localhost’ (using
password: YES) in /home/vhosts/<<removed for legal
reasons>>/docs/citeheader.inc.php on line 2. A hacker knows that this site is using MySQL and PHP and now knows some of the directory structure of the Web site /home/vhosts/<<removed for legal reasons>>/docs.
Now the hacker can try to query that individual directory path using
his Internet browser to see if he can uncover any additional goodies—a
script file, perhaps. If he finds a script file in this directory and
the developer has hardcoded login credentials to the database, he is one
connection away from compromising the database.
The moral of the story is that search
engines are very good hacker tools. Never hardcode passwords in script
files, and always provide Web page redirects for errors within your Web
application. In addition, always pay extra attention to any Web
application that receives input. Make sure these kinds of data are
protected against SQL injection attacks.
