Database Crime Scene Prevention

A good detective understands the criminal mind, techniques, and tools of the trade. To protect your database and prevent it from becoming a crime scene, it is crucial to understand the common methods of attack, data theft, and cover up techniques. The suspect line-up can come from outside hackers and from within the ranks of trusted employees, contractors, and partners. Some threats are easily prevented or contained; while others more elusive. Fortunately, many of the security mechanisms and tools required to protect databases are readily available.

This article examines known attacks, methods, and tools used by criminals, as well as emerging exploit categories used to break into a database, establish control, compromise the system, steal the data, and cover up the tracks. We will also cover best practices for protecting databases against these attacks methods.

The database server as a target

Given the wealth of information stored in databases and its value on the open market, it is no surprise that databases are a primary target of criminals. The personal, identity, trade, and military data contained in many repositories can fetch top dollar. Meanwhile, employment instability, mergers, acquisitions, etc., can also contribute to insider data theft. In addition, data can leak out accidentally and though these acts are not criminal, they can result in severe data breaches.

It can be said that the database server provides an attacker with the perfect criminal opportunity, combining motive (the resale value of the information), means (easily available tools), and opportunity (direct access to the server through thick client-applications, lax internal network controls and ill written applications).

The Five-Step Program

Before attempting to implement effective database security, it is crucial to understand the processes that lead to a breach. These processes can be broken down into five basic steps:

• 1. Tools of the Trade

• 2. Initial Access

• 3. Privilege Abuse

• 4. Privilege Elevation

• 5. Covering the Tracks

Page Break

1. Tools of the Trade

A perpetrator's first step toward attacking a database server is to obtain the right tools. These are surprisingly easy to obtain, even for internal users. Security officers often underestimate internal threats by making the following assumptions:

• Internal users are not "hackers" with hacking tools and they are not equipped to produce "hacking tools" themselves.

• Security policies on internal workstations will deny software installation by end-users.

While both assumptions are probably valid, they have nothing to do with the ability of end-users to get their hands on tools for database attacks. As is turns out, most types of attacks (SQL related) can be executed through standard database client software such as the one provided by default from the database vendor (e.g. Query Analyzer, SQL Plus, etc.). This software is usually part of the basic installation for any workstation in the enterprise.

Moreover, almost all the capabilities required for database attacks can be found in the tools of typical office software such as Microsoft Excel. Other types of attacks (such as network protocol related attacks) can be constructed using a simple text editor such as Notepad, WordPad or a Telnet client. Finally, in many organizations users have remote access to the internal network through their home computers where no software installation restrictions exist.

2. Initial Access

There are two elements required for making initial contact with the database server. The attacker needs network access to the database server machine and a set of valid access credentials (i.e. username and password). Network access to the database server is usually an easy task considering the lax internal network security found in most enterprises. Even when some internal access restrictions exist within the network, many workstations are allowed to communicate with the database server due to thick-client applications that are provided to users. These applications contain all the application logic on the client side and communicate directly with the database server rather than through an intermediary application server.

Some types of infrastructure attacks prey on database vendor-specific vulnerabilities that require no more than this initial access in order to take down a server or execute arbitrary code. However, for most attacks an attacker must provide a valid set of access credentials. These credentials can be obtained through various methods, assuming that the perpetrator was not given them rightfully. The following are some of the methods perpetrator's use to obtain access credentials.

Page Break

Brute Force and Exhaustive Search

This method involves guessing a large number of possible user/password combinations until one combination is successful. While in theory this method is futile and infeasible due to the large size of the search space, in practice there are techniques that can be employed to reduce the number of guesses required to find a valid combination.

There are many techniques (usually related to minor vulnerabilities in the database server) that allow an attacker to find valid account names and then search for the corresponding passwords. Finding user accounts can be easy, especially when they are assigned in a systematic way within the organization, e.g. john.smith or JohnDoe.

There are numerous optimizations that can be applied to the "guessing" of passwords. These optimizations rely on what are known as "password rules," which are a compilation of social observations related to the way that people choose passwords. For instance, the account "John" might have passwords JohnJohn, nohj, John1234 and so on. In a large user base, password rules greatly reduce the number of guesses necessary for an account/password match.

Default Accounts and Passwords

Many database servers and applications deployed over them come bundled with default accounts configured with default passwords. Unless all of the defaults are changed by the administrator upon installation, these accounts provide an easy access point for uninvited guests. Also, poor installation and configuration may allow anonymous database access to users. Even if access privileges granted to anonymous users are minimal, this is a crack an attacker may use to gain access.

Thick-Client Applications

A thick-client application that is installed on a workstation communicates directly with the database server. In order for the application to communicate with the database server it must have a set of valid credentials. The credentials are either supplied by the end-user when running the software or more commonly embedded within the application code or in a local configuration file. In either case, an attacker with a text editor can easily get hold of this set of credentials.

Social Engineering

This term is used to describe a set of techniques, including eMail messages and phone calls, where a would-be attacker tricks an individual into disclosing a personal set of credentials. Perpetrators employing social engineering techniques have been known to trick administrators into providing them with a freshly assigned set of credentials.

Page Break

3. Privilege Abuse

A large number of database attacks are carried out using this step. When an attacker makes an initial connection to the database server, they are granted a set of access privileges. Depending on the nature of these credentials, they is may allow access to enough sensitive information or functionality. If the set of credentials was taken from a thick-client application, the perpetrator could bypass the access restrictions imposed by the application code and not be subject to database access control mechanisms.

In actuality, there are many control mechanisms that do not exist on the server. One example is the lack of restriction on the amount of records that can be retrieved using a single database query. Another is a lack of limits on the criteria that can be used for extracting records.

Typical attack scenarios involve the use of the tools within common Office software, e.g. Microsoft Excel. These tools can be used to retrieve large amounts of information from the database which can be stored locally on the workstation and then exported to a detachable medium.

Other crime scenes involve the use of native database client software to make unauthorized (or uncontrolled) changes to the information stored on the database.

Privilege abuse is hard to detect using traditional access control mechanisms because in these cases, perpetrators employ legitimate commands under illegitimate circumstances. For instance, perpetrators with legitimate privileges avoid detection by committing the crimes outside of normal working hours, by using a different client machine, or by using illegitimate channels, i.e., client applications.

4. Privilege Elevation

If a perpetrator cannot accomplish his crime by using the basic privileges granted upon initial contact, chances are he'll move toward obtaining administrative privileges. Privileges at this level in the database would allow the perpetrator to gain virtually unlimited access to any information stored within the database server, and worse, total control over the server itself.

There are a number of techniques that result in administrative privileges being granted to a non-privileged user. The most notorious (yet the toughest to exploit) is the use of the buffer overflow attack. Server software is not designed to handle long user input. When used naively, the buffer overflow vulnerability can be exploited to quickly bring down a server. However, if the attacker carefully plans this exploit, he/she will be allowed to execute arbitrary code with administrative privileges. Buffer overflow vulnerabilities are found in built-in stored procedures, SQL statements, and even built-in functions. While the first two can be mitigated using internal access control mechanisms, the third type requires access control semantics that do not exist in the database server.

Page Break

The second type of privilege elevation technique perpetrators employ is the SQL injection through stored procedures attack. Stored procedures are written in a manner that uses their parameters to construct SQL statements which are then executed with the privilege of the procedure owner. As a consequence, a perpetrator that is only allowed to execute a stored procedure can actually execute any SQL statement with administrative privileges (assuming that in most scenarios, the owner of the stored procedure is an administrative user, exposing some reduced functionality to less privileged users).

A third type of privilege elevation attacks take advantage of SQL parsing vulnerabilities such as the one reported by Oracle in 2007 (see http://www.red-database-security.com/advisory/oracle_view_vulnerability.html). This vulnerability allows an attacker to create a special database view that provides unauthorized INSERT, UPDATE or DELETE capabilities on database tables. All these privilege elevation techniques can be employed using basic database client tools such as the tools provided with the Microsoft Office suite or with the default database client installation.

A newer and lesser known, yet incredibly clever attack technique exploits the vulnerabilities inherent in the implementation of database network communication protocols. These proprietary protocols are used for client-server communication and include a host of security vulnerabilities an attacker could exploit to gain control over the server. To do this, a perpetrator can use a simple text editor, though some require a standard Telnet client, and others require more sophisticated network control tools. There are no internal mechanisms within a database server to proactively protect against this type of attack.

5. Covering the Tracks

The smart thief knows how to strike and leave undetected. This also applies to database criminals, who have several ways to cover their tracks. In many instances, the perpetrator doesn't even have to worry, since internal audit mechanisms are rarely activated due to performance and disk space concerns. In many of the attack methods discussed, the thief's actions would not trigger an alert. Servers with audit trail functionality activated are typically set to track unusual conditions that are the result of unsuccessful executions. However, most of the techniques previously discussed do not invoke these conditions but rather yield successful execution of the SQL statements.

Let's assume though that we do have a properly configured audit mechanism on our database server. The first step a perpetrator would take upon completion of a successful privilege elevation attack would be to turn off logging. In most deployments, a criminal with administrative privileges can also tamper with the existing audit trail, erasing any trace of the attack steps that preceded the privilege elevation.

Page Break

Some types of attacks leave no trace in the internal database audit trail. For example, most of the database communication protocol attacks display this behavior. Other types of attacks can be launched after abusing vulnerabilities in the internal auditing mechanism. In this example (http://www.imperva.com/resources/adc/adc_advisories_ms_sql.html) an attacker was able to connect to a MS SQL Server database without his account name being registered by the audit mechanism.

In summary, as long as the audit trail is based on internal database mechanisms it is rather straightforward for an attacker to remove any trace of his covert activities and identity.

How to Stop an Attack One Step at a Time

Now that we understand the steps a perpetrator would take to make your database the scene of a crime, let's take a look at the steps that can be taken toward crime prevention. For each of the five steps, there are mitigation techniques that would interfere with a would-be perpetrator's attacks. While no single mitigation technique is in itself fool-proof, it is important to employ a range of mitigation techniques in what is known as a "layered security" approach. By following these recommendations, your database environment will become much more secure.

Because it is neither practical nor cost effective to limit the accessibility of tools, we will skip Step 1 -- Tools of the Trade.

2. Stop Initial Access

The following steps can be taken to protect your database and prevent a perpetrator's initial contact.

• Apply internal network access controls to the database server. Make sure that workstations cannot access non-database services on the database server machine.

• Do not allow anonymous access control to your database server.

• Remove or block default accounts.

• Change the default password for those default accounts that cannot be removed or blocked.

• Apply proper password policy to database accounts. Enforce "strong" password policies.

• Put in place mechanisms that will detect in real time exhaustive searches of credentials. These attacks are easily identified by a large number of failed authentication attempts in a relatively short time frame. Put in place mechanisms to block network access of machines trying to perform exhaustive credentials search.

3. Halt Privilege Abuse

Take steps to control access and usage to ensure that legitimate commands are not used in unauthorized circumstances, etc.

• Apply context based access controls. These mechanisms allow you to define access privileges based on the following criteria:

  - Network address of the workstation

  - Client software

  - Time of day

  - OS user

• Apply query level access controls. These mechanisms allow you to define the criteria allowed in database queries and structure of queries, thus avoiding bypass of some client-side application logic.

4. Prevent Privilege Elevation

Take steps to prevent the perpetrator from becoming a DB Admin or Root -- with all the attendant privileges associated with these privileged accounts.

• Deploy a database IDS/IPS solution with the following capabilities:

  - Reactive protection: detect and block known vulnerabilities based on a frequently updated set of signatures

  - Proactive protection: detect and block abnormal protocol messages possibly representing database network communication protocol attacks.

• Apply query level access controls.

5. Don't Let Them Cover Their Tracks

Finally, if all of your other mechanisms fail to prevent the crime, you and the authorities will want an audit trail that fingers the perpetrator. Deploy an independent database audit mechanism. This approach ensures that logging does not affect database performance and that an attacker cannot tamper with the auditing mechanism once connected to the database server.