If a hacker sets sights on your SQL Server, there are four primary methods he can use to take control and carry out unauthorized, malicious activity. I will look at each method in the following tip.
TABLE OF CONTENTS
[IMAGE] Password compromise
[IMAGE] Account compromise
[IMAGE] SQL injection
[IMAGE] Buffer overflows
[IMAGE][IMAGE] Password compromise[IMAGE] Return to Table of Contents
When someone guesses or learns the password for your sa account or another account in the system administrator's or dbo_owner's role, your password has clearly been compromised -- usually because they are too weak. A weak password is usually less than seven characters long, entirely comprised of alphanumeric characters (i.e. no non-alphanumeric characters like ~!@#$%^&*()_`{}[]\| forming part of your password).
Other reasons why passwords are compromised:
- High-privileged accounts have the same password as the account name (in many applications the account name is easily exposed);
- Passwords and account names are posted in conspicuous places for easy memorization or availability;
- Passwords and accounts are hard coded in your code or web.config file;
- A single administrator creates all passwords and accounts (which leads to predictable account names and passwords).
Consider a janitor walking up to the console of your SQL Server machine and hitting Control/Alt/Delete. The account name displays in the logon prompt. Now all he has to guess is the password. Statistics show that, often, passwords are the same as the account name.
If the same admin creat...
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
ed the NT accounts and SQL accounts, statistics show it is likely he will reuse account names. Your SQL Server account name and password may be the same pair that's used for SQL authentication on the same machine or on another machine.
That said, most NT hacks are performed using the Administrator account, which is not disabled after a predetermined number of failed logon attempts in SQL Server 2000. (In SQL 2005, non-administrator NT accounts will be locked out after a predetermined amount of consecutive failed login attempts within a predetermined time period.) There is also the problem of a hacker's social engineering skills -- for bullying, cajoling or sweet talking the account name and password from unsuspecting employees.
Some of these vulnerabilities can be mitigated only by using Windows Authentication Mode for SQL Server. Windows Authentication will send a hash made using your password across the network as opposed to SQL authentication, which sends the actual password.
You should enable auditing to detect failed login attempts -- and successful accesses. To enable this feature in SQL Server 2000, right click on your SQL Server in Enterprise Manager, select Properties, click on the Security tab, and select "All in the Audit Level" group. Failed logon attempts will show up in the SQL Server logs.
[IMAGE][IMAGE] Account compromise[IMAGE] Return to Table of Contents
Hackers may piggyback on a SQL Server account to carry out unauthorized activity. The most common method for compromising an account is through SQL injection attacks, which I'll discuss later. They also use ODBC DSNs (data source names) to gain access to your SQL Server databases. For example, a hacker could walk up to an open console and browse your ODBC connections and then write custom code to connect to your ODBC source and issue login commands. Then, easily enough, the hacker controls your machine. To avoid compromises through DSN, you must ensure that your application account users are given only the rights they need to do their work and nothing more.
You must never allow an application to access SQL Server using sa accounts or accounts in the database owner or system administrator roles. Imagine the damage a hacker could cause by sending a query with an add logon, drop database or truncate table command! To avoid such risks, create a special application account that only has rights in the application databases, and use the GRANT command to assign this account the minimal rights to access tables and views and execute stored procedures and functions.
Privileged accounts aren't all you have to worry about. Another factor is employee malfeasance. Consider a global DBA group with sa rights to the human resources (HR) database. A member of this group could log on to the HR server, connect to the payroll database and give himself a pay increase.
You should limit rights to sensitive SQL Servers to trusted employees who can be audited. Some companies will lock down HR servers (or other sensitive servers), store half of each password with the support desk and the other half with the DBA manager. When you require access to these sensitive servers, the password halves are brought together, access is granted, the work is done, the password is changed and the two halves of the password are issued again to the respective parties.
[IMAGE][IMAGE] SQL injection[IMAGE] Return to Table of Contents
SQL injection allows a hacker to create entry to a Web page text box (for example) to perform an action. This action can be as minor as mere database access or as major as dropping tables or objects or creating logins. You can prevent SQL injection attacks by using an application account that only has the privileges it requires (called the principle of least privilege) and by using parameterized queries or stored procedures.
For a more in depth discussion of SQL injection attacks, please refer to the white paper, Advanced SQL injection in SQL Server applications.
[IMAGE][IMAGE] Buffer overflows[IMAGE] Return to Table of Contents
Buffer overflows are robot-like attacks that use your SQL Server as a host to launch other attacks (i.e., Slammer worm of Jan. 2003). They typically don't result in a hacker taking control of your SQL Server -- but that's not to say a new worm won't be launched tomorrow that does precisely that.
When a program writes data beyond the allocated end of a buffer in memory and injects machine code program instructions into the processor, you have a buffer overflow. The Slammer worm was caused by a buffer-overflow exploit. Microsoft has gone to great lengths to protect its binaries against buffer overflows; however, there are many ways to write a buffer overflow. Nowadays, hackers scour Microsoft's new patch releases to see which vulnerabilities Microsoft is patching so they can quickly release a worm or virus to target the unpatched server. The recent Zotob worm is a good example of a that.
Summary
There are many ways hackers can gain control of your SQL Servers. Offense is the best defense. Microsoft has released a baseline security analyzer (MBSA for SQL Server, which will help you detect servers that are vulnerable on your network. Several SQL Server best practice guides can help you lock down your SQL Servers. Microsoft has also done considerable work on SQL Server 2005 to make it highly secure out of the box.
About the author: Hilary Cotter has been involved in IT for more than 20 years as a Web and database consultant. Microsoft first awarded Cotter the Microsoft SQL Server MVP award in 2001. Cotter received his bachelor of applied science degree in mechanical engineering from the University of Toronto and subsequently studied both economics at the University of Calgary and computer science at UC Berkeley. He is the author of a book on SQL Server transactional replication and is currently working on books on merge replication and Microsoft search technologies.
More information from SearchSQLServer.com
Learning Guide: SQL Server Security
School: SQL Server Security School
Topics: Get best practices for locking down SQL Server
For help with all of your Windows security issues, visit our sister site, a href=http://searchwindowssecurity.techtarget.com>SearchWindowsSecurity.com.
