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 you
finally get soaked? Microsoft has done a lot of work towards protecting
its operating systems and applications out of the box. When
exploitation is discovered, 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 inadvertently 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 other
isolation techniques.
Weak System Administrator Account Passwords
One
of the easiest ways to give someone the keys to SQL Server is by
providing a weak password for the system administrator (SA) account. In
versions of SQL Server prior to SQL Server 2005, it was possible to
give a blank password for the SA account without much complaint from
SQL Server itself. As of SQL Server 2005, there is a lot more
functionality around password policies and enforcement. Configuring
a strong password length and account lockout in your domain will ensure
that all users of SQL Server are supplying passwords that are more
difficult to crack.
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. Starting with SQL Server 2005, this
enumeration functionality is in a separate service called the SQL
Server Browser service. The functionality no longer runs in the SQL
Server 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
is the process by which a malicious user enters SQL statements instead
of valid input. For example, suppose that a website is asking for a
user name. Instead of actually typing in a user name, a malicious user
could type ‘blah’; DROP TABLE Sales;.
The web server will happily take the user input and pass it along to
the application layer, where it is executed in code as follows:
SqlCommand cmd = new SqlCommand
("SELECT * FROM Sales WHERE Name='" + customerName + "'", conn)
To SQL Server, it looks like the following:
SELECT * FROM Sales WHERE Name='blah'; DROP TABLE Sales;
When
this statement executes, the sales table will be erased (which is not
quite what the application developer had in mind!). You can see how
easy it is for malicious users to cause problems and return potentially
sensitive information via simple inputs to webpages or applications
that blindly accept user input to build dynamic SQL. To eliminate this
potential, add the user input as a parameter to the SqlCommand rather than concatenating dynamic SQL strings, as shown here:
SqlCommand cmd = new SqlCommand("SELECT * FROM Sales WHERE Name=@CustomerName", conn));
cmd.Parameters.Add("@CustomerName", customerName);By using the Parameters collection of the SqlCommand object, whatever the user types will be treated just as the value of the name part of the WHERE clause.
With the advent of powerful search
engines such as Google and MSN Search, finding things on the World Wide
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 things like websites for pizza places, they also obtain
various kinds of error information returned from web servers. Error
information is very valuable to hackers. For example, if a hacker types invalid password access denied
into the search string in MSN, they’ll get a list of various topics
that are, in general, not that interesting. However, one item might
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. Hackers know that this site is using MySQL and PHP, and they also learn some of the directory structure of the website /home/vhosts/<<removed for legal reasons>>/docs.
Now they can try to query that individual directory path using an
ordinary browser to see whether they can uncover any additional
goodies—a script file, perhaps. If they find a script file in this
directory and the developer has hard-coded login credentials to the
database, they are only one connection away from compromising the
database.
The moral of the story is that search
engines are very good hacker tools. Never hard-code passwords in script
files, and always provide webpage redirects for errors within your web
application. In addition, always pay extra attention to any web
application that receives input. Make sure that these kinds of data are
protected against SQL injection attacks.
