Quarter 1, 2004 Vol. 9, Issue 1

Securing Your Database

By Michael Dougherty

Don't let your Web applications threaten your data's security.

Information security is a critical element of business operations. Yet, surprisingly few organizations have integrated security policies, measures, and technologies to protect their information assets against internal and external threats. Billions of dollars' worth of productivity and information assets are lost each year to security breaches and other intrusions. In light of many recent high-profile security breaches and the endless stream of disastrous virus infections, businesses are finally recognizing security as mission critical.

Security has evolved from protecting the network perimeter to protecting data at the source. Perimeter security is no longer effective in an age when data access models (once designed for employees only) now extend to partners, vendors, and customers.

Today, organizations must strike a balance between ensuring safety and providing access. It's a fine line to walk: openness is essential, but must be scrutinized to reduce weak links.

The current trend in corporate IT is toward centralized security administration. IT managers are increasingly focused on knowing which elements in their networks are protected and which are exposed. Recognizing the points of weakness is half the battle; the other half, of course, is deciding how to mitigate weaknesses. Proactive steps to reduce security risks and vulnerabilities are an important facet of today's top IT organizations.

IT organizations face a multitude of challenges in keeping intellectual property, trade secrets, business practices, financial records, contractual negotiations, customer records, and other assets safe from theft, destruction, or misuse. Because the information in databases is usually a company's most prized possession, protecting databases is crucial.

In this column, I'll review general database security concerns and recommendations, DB2-specific security points (for Linux, Unix, and Windows environments), and security product trends.

SQL Injection

Most databases are set up in a way that makes breaking in relatively easy. But securing the database has become simpler. A few straightforward steps can vastly improve security, usually by locking out all users except applications and DBAs.

But even that restriction doesn't completely protect your data. One of the primary security breaches organizations experience today takes place via applications that connect to databases. Applications don't use native database security. Instead, they access the database as a "super user" and, therefore, could represent a risk to data security. One of the most common examples of exploiting this risk is known as SQL injection.

SQL injection isn't a direct attack on the database. Instead, it takes advantage of the way many Web applications that access databases are developed. SQL Injection attempts to modify the parameters passed to a Web application via a Web form to change the resulting SQL statements that are passed to the database and compromise its security. If successful, an attacker can hijack the database server and be granted the same permissions to add, drop, and change users that the application has. From that point, the database is fully exposed.

Unfortunately, the practice of SQL injection is easy to learn. Fortunately, with a little forethought, you can prevent it. The simplest way to find out if you're vulnerable to an SQL-injection attack is to enter a single quote into each field on each form in your applications and verify the results. Some applications will return a message claiming a syntax error. Some applications will catch the error and not report anything. In both of these cases, your site has some protection from SQL injection, but don't assume it's secure. You can only validate your level of protection by going to the application's source code. I'll explain what well-protected source code should contain later in this column.

A hacker will use SQL injection to modify a query in order to send (via the application) commands to the database that the developer never intended. Take the following example:

SELECT * FROM my_table
WHERE column_a =
'1' UNION select userid, password from
DBA_USERS WHERE 'a'='a'

Typing this command into a form at the right place in a vulnerable application will give the hacker access to user accounts and passwords. Even if the passwords are encrypted, obtaining a list of all users can severely compromise database security.

Applications can be the poison of databases given their "super-user" privileges, especially when the applications aren't created with as much concern for security as is typical for databases.

Here's an example of how an application can breach database security: A typical custom-built Active Server Pages (ASP) application will handle authentication as in Listing 1.

Listing 1: Authentication in a typical ASP application.

Allowing users to view Web pages' source code makes the weaknesses more evident for intruders using SQL injection, because they will be able to determine if and where the code has been built carelessly. Preventing users from seeing source code makes SQL injection more difficult, but it doesn't prevent it; the intruder simply has to play a guessing game.

If I set my username to Mike and password to IloveSQL, the SQL statement resolves to:

SELECT * FROM users WHERE
username='Mike' AND password
= 'IloveSQL'

As an attacker, I could make my password Aa' OR 'A'='A. Now the SQL statement becomes:

SELECT * FROM users WHERE
username='Mike' AND password='Aa'
OR 'A'='A'

Here's where the attacker hits pay dirt. The query returns all the rows in the database because the result of 'A'='A' is always true. Even worse, the first entry in the list is often the administrator. In that case, the attacker will be authenticated with full administrative rights to the application.

The UNION SQL command can be used in a similar manner, although doing so is a little more difficult because the number of columns and column types must match. However, if the server responds to the UNION with error messages, then the task becomes far less difficult; the error messages provide clues to the data structure. This process is called database foot printing. Here's another ASP example code set:

Dim sql
Sql = "SELECT * FROM PRODUCT WHERE
Productname = '" & productname & "'"
Set rs = Conn.penRecordset (sql)

The attacker would attempt to gain access to encrypted passwords from your database. With these hashes, the attacker can start breaking the passwords. For instance, the hacker could set the product name directly in a form to:

Check' UNION SELECT username,
password FROM sysadmin WHERE 'a' = 'a

Processed via the ASP, this step produces the following direct result on the page:

SELECT * FROM PRODUCT WHERE
ProductName='Check' UNION SELECT
username, password FROM sysadmin where
'a'='a'

This statement would evaluate to TRUE and cause all rows to be returned from the sysadmin table.

Protection from SQL Injection

There are two primary methods to protect your database from SQL injection. First, make sure that applications validate user input by blocking invalid characters. In many cases, only alphanumeric characters should be accepted. At minimum, single quotes should be blocked. Second, use protected queries that bind variables rather than combining SQL statements together as strings such as stored procedures.

These suggestions may also help:

• Use original names for tables and columns to make the names harder to guess.
• Use aliases to provide more layers of separation between the data and the intruder. (For example, an intruder might find the alias "b" after some digging. But "b" is an alias for "book," and the actual term is necessary to perform the correct query.)
• Set length limits on form fields and validate data for content length and format.
• Keep up-to-date on patches.
• Make your schema unique.
• Use stored procedures, which use parameters, at all times.
• Avoid using query strings for Web page building.
• Use Push and Get for HTML commands.
• Audit your code to expose vulnerabilities.
• Lock down your server. Make sure the application is running with the minimal rights necessary to complete its task. Remove any unnecessary accounts and any unnecessary information, such as example databases and unused features. Also remove or disable unnecessary stored procedures.

Of course, if you work with developers who are less seasoned or unaware of programming security risks, train them. Going through all exposed ASP, PHP, Cold Fusion, Visual Basic, Perl, CGI, and other scripts and pages may be time consuming, but it's necessary for database protection. A programming guidebook on protecting against SQL injection would help prevent future exposures.

Another option is to use a Web application assessment tool such as Wpoison, which searches for known security flaws on remote Web documents. Wpoison helps identify and flag weaknesses in applications. You'll find a development copy of Wpoison at sourceforge.net/projects/wpoison. Keep in mind, though, that this tool is also very useful for attackers.

Database Worms

Since the Slammer worm hit SQL Server in 2003, the awareness of database worms has grown. Although no one can predict the future, the general belief in the database community is that database worms aren't a major security concern. You might be better off spending time on security against targeted attacks on your salable data (such as SQL injection) as opposed to destructive attacks (such as database worms).

Denial of Service and Other Dangers

Denial-of-service attacks involve crashing a Web server or database or locking it into an endless process that consumes all system resources. The result is the inability to provide a response to Web site browser requests or even to core database requests. Locking down your database via firewalls (more than one is recommended for additional layers) is one way to protect your server; however, this step should be only the beginning, depending on your available budget.

The most common form of database security compromise has been buffer overflow. This "catch all" security malady essentially states that some database resource, such as the number of available connections or a memory buffer to hold user input, has hit its limit and overflowed, affecting any further access for that resource. This overflow is typically caused by a looping activity that takes resources but has no end condition (or a compromised one).

DB2 Security

When analyzing your DB2 database, there are several areas in the database layer where you should validate security. I'll explain each area in detail and provide suggestions for ensuring DB2 security. Remember, though, it only takes one hole to compromise the entire security model. The areas I'll cover are just a portion of the constant and never-ending process of securing the database server and the entire enterprise.

Authentication types. In DB2, the authentication type is used to identify users. It defines where and how authentication occurs. Several authentication types are available; which one to use should be carefully determined by the environment, operating system, and purpose of the DB2 server.

The authentication type is configured on both the client and server. However, authentication type is defined only on the server in the database manager configuration file. That configuration file is associated with an instance and applies to all databases with that instance as well as all users within the database.

DB2 currently supports the following authentication types:

• SERVER
• SERVER_ENCRYPT
• CLIENT
• DCE (replaced by KERBEROS with LDAP in v.8)
• DCS (holds the same meaning as SERVER in DB2 v8, with the exception of federated servers)
• DCS_ENCRYPT (holds the same meaning as SERVER_ENCRYPT in DB2 v.8, with the exception of federated servers)
• KERBEROS (for Windows 2000/XP/2003, planned for Unix/Linux expansion)
• KRB_SERVER_ENCRYPT (for Windows 2000/XP/2003, planned for Unix/Linux expansion).

For CLIENT authentication, two other parameters are used: TRUST_ALLCLNTS and TRUST_CLNTAUTH. When determining a secure mechanism, don't depend on client authentication. You can't assume clients are secure. Even TRUST_CLNTAUTH is ineffective because the client can be spoofed (a term that refers to a hacker observing and modifying a target's Web pages).

You should use either SERVER_ENCRYPT or KBR_SERVER_ENCRYPT for fewer security weaknesses.

IBM DB2 usernames and passwords. For DB2 UDB installed on Windows, make sure you change all default usernames and passwords immediately. Hackers use these default names and passwords as an easy first attempt to break into your database once they've broken through the other layers of security.

DB2 database privileges. IBM DB2 databases don't have database-specific accounts as other databases do. Instead, authentication is performed under the operating system with operating specific accounts. As a result, DB2 doesn't have a table where all accounts are listed. Accounts are stored in the following tables instead:

• IBMSysDBAuth
• IBMSysTabAuth
• IBMSysINDEXAuth
• IBMSysCOLAuth
• IBMSysSCHEMAAuth
• IBMSysPASSTHRUAuth.

You should revoke privileges on the system catalogs I listed in order to help prevent easy access. For security lockdown, you should also remove all permissions granted to public and carefully examine all users within the SYSADMIN group.

New releases of FixPaks. Keeping up-to-date on the latest FixPaks from IBM minimizes your vulnerability to database weaknesses or flaws such as buffer overflows. However, there's an inherent danger in installing FixPaks, too. Always validate that the FixPak won't cause any side effect to your specific environment before updating your production database with it. FixPaks are quality tested prior to release, but unique environments can bring out undiscovered issues.

The latest FixPaks (which you can find online at www.ibm.com/cgi-bin/db2www/ data/db2/udb/winos2unix/support/download.d2w/report) include:

• V.8.1 FixPak 4 (the most current is DB2 UDB 8.1.4)
• V.7.2 FixPak 10a
• V.7.1 Upgrade to 7.1 with latest FixPaks.
• V.6.1 FixPak 11.

If you're using a DB2 older than v.6.1, it may be time to consider upgrading.

DB2 Control Center buffer overflow. The DB2 Control Center is a GUI for managing database objects and their relationships. Hackers can exploit a buffer overflow in this service by sending an invalid packet to port 6790. To prevent that situation, apply the latest FixPak from IBM.

A similar problem exists for the DB2ckpw utility, which verifies usernames and passwords for operating systems. Again, the remedy is to apply the latest FixPak from IBM.

The latest DB2 FixPaks also solve problems with the DB2 Query Compiler that can cause database denial of service. Not all issues for DB2 version 6.x or earlier have a FixPak. I recommend upgrading to DB2 v.7.x (at the minimum) for security's sake.

The Future of Security

A new security trend is to provide multiple layers of security within a computing environment. These layers can include multiple firewalls between the Internet and the organization and even firewalls within an organization to protect high-value assets.

Decisions regarding the level of security you need aren't easy. You'll need to consider the following items:

• The balance of how much budget to use versus the level of protection needed
• The level and ease-of-access needed for external employees, partners, and permitted parties (such as consulting agencies) and the lockdown for unwanted infiltrators
• Layers of security versus the simplicity and ease of administration.

No Better Time

Security considerations go far beyond the database. But the database should be one of the most protected elements of any business environment; after all, it usually holds the most valuable and mission-critical knowledge. With a few simple tasks, you can reduce your DB2 security risk to a reasonable level:

• Keep current with DB2 FixPaks.
• Be aware of database security holes such as built-in stored procedures, predefined tables, and so on. The built-in stored procedures that come with the standard database (as opposed to custom-built ones) can hold weaknesses known by infiltrators.
• Restrict access and authorization to "none" unless validated.
• Audit your applications (built or bought) for holes.
• Maximize the layers of protection to your database.
• Monitor your log files.
• Consider adopting risk-management and proactive vulnerability assessment tools.

Companies with more than 50 employees should also consider building a true security practice. A true security practice includes a security specialist certified through a reputable organization and at least a part-time security manager. Depending on the size of your organization, a full-time security manager and a Chief Security Officer may also be appropriate.

Considering the potential threats from everything from cyberterrorism to angered employees to hacks for hire, it's time to get serious about security. Taking the easy path is the surest way to become the latest statistic on the roster of companies injured by a security travesty.

SECURITY STANDARDS

Security is a complex and involved practice that shouldn't take a back seat to other administrative tasks. The database is one of the key protection points; however, as a database architect, DBA, or IT manager, recognizing the breadth and depth of security considerations will help you plan prevention methods.

Here are the 10 domains of security in the Common Body of Knowledge produced by the International Information Systems Security Certification Consortium, also known as (ISC)², one of the main guiding bodies of security-based standards.

1. Security management practices (security guidelines and SLAs for data centers)
1. Security policy, standards, and procedures
2. Roles and responsibilities
3. Risk management (data classification, risk assessment, and risk analysis).
2. Security architecture and models (confidentiality, integrity, and availability)
1. Trusted systems
2. Desktop and server operating system security model
3. WAN and LAN topologies.
3. Access control systems and methodology (access level for a centralized or decentralized system or application)
1. Preventative, detective, and corrective controls
2. Authentication (sso, kerberos, and so on)
3. Security domains
4. Intrusion detection.
4. Operations security (access privileges, audit, and monitoring, and how to handle violations, incidents, and breaches)
1. Control of hardware, media, and operator access
2. Change control management
3. Separation of duties.
5. Physical security (physical protection for people, facility, and instruments)
1. Facility planning
2. Personnel access controls.
6. Cryptography principles (disguising information to ensure integrity, confidentiality, and authenticity)
1. Use of encryption to secure information
2. Public key infrastructure
3. Digital signatures.
7. Telecommunications, network, and Internet security (voice and data communications, LAN, WAN, and remote access)
1. Email security
2. Network security management
3. Remote access (VPN, SSL)
4. Firewalls.
8. Business continuity planning and disaster recovery planning (focuses on protection from major system and network failures).
1. Strategy
2. System backup and recovery.
9. Law, investigations, and ethics
1. Intellectual property law
2. Privacy laws
3. Regulatory compliance
4. Governance requirements.
10. Application development security
1. Integrity, security, and availability
2. System life-cycle and security
3. Database and data warehousing threats and protections.

Michael S. Dougherty has been consulting for more than 12 years in systems-level programming, application development, and project management. He currently works for Burntsand Corp. (www.burntsand.com) and is part of a new business called MovieConnector Enterprises. You can reach him at mikjza@kingwoodcable.com.