This is part 2 of a series of posts aiming to analyze the real world security challenge of the Oracle database. Part 1 discussed the potential risks to the database, and this part will discuss the methods likely to be employed by each individual to compromise the data. So
How will the breach occur?

While this post discussed the breaching of many different types of systems on the way to the Oracle database, one needs to keep in mind that the end point of any computer security breach is data. All the roads lead in one way or another to the database. While putting on barriers in every junction is important, one much not neglect to protect the database itself.

The next post will discuss how everything converges back to the Oracle database and the security measures required to protect it.

DBAs and Privileged users
DBAs and privileged users have all the access they need to modify, steal, or manipulate the Oracle database. They also have all the tools and skills required to do so efficiently and without detection.

Internal users with database access
Internal users with database access have a user and password to connect to the database. For the most part, those credentials will give them access to sensitive information. However, the tools they usually use to access the database will not naturally lend themselves to abuse. Such an individual will therefore need to

• Obtain a tool that will allow them to achieve what they are trying to do. Toad will be a simple tool, but SQL*Plus is likely already installed on their system
• Figure out how to write some SQL statements to accomplish the job. The internet is filled with examples on how to do these things.

If the credentials they have do not give them access to the sensitive data, they will also need to do one of the following:

• Borrow (with or without permission) a co-workers credentials
• Find a website with hacks and try those recipes one by one until they find the one that works. See Local Breaching below.

Internal users with system access
Any individual that can log into the operating system that runs the Oracle database, is a potential threat. The same applies to users with access to the storage and network that the Oracle databases use. Backup tapes are a little different in that anyone with physical access to those is considered a risk.

If these individuals do not have direct access to the Oracle resources (e.g. a Unix Administrator), they will need to obtain such access. As discussed above, borrowing credentials or using hacking recipes are the most obvious routes to take. See Local Breaching below.

Additionally, these individuals will need to learn how to convert the access they have to steal or modify sensitive information. For example:

• If you gain access to the Oracle Unix account, you need to login to Oracle (“sqlplus / as sysdba” will work in some environment). You than need to locate the tables with sensitive data (sometimes by joining multiple tables), and change / steal the data.
• If you have access to the storage system that contains the Oracle database, you could create a snapshot of the database, mount it on another system, start the database, locate the sensitive information, and extract it.
• If obtained the backup tapes of the Oracle database, you will need to restore those on a different system, start the database, locate the sensitive information and extract it.
• If you have access to a network that handles Oracle database traffic, you could hijack a SQL*Plus connection made by one of the DBAs and use it change / steal data.

For obvious reasons, I did not go into too much details on how to convert system access into a security breach. However, people with the right technical skills can do this, and their main challenge will probably be the lack of Oracle database expertise to accomplish the Oracle part of the breach.

Users with application access
Users with application access can either abuse their access to steal / modify information they have access to or they can steal / modify information they do not have access to.

Abuse of access by application users can be, for example, a customer call center representative stealing the information of every customer they talk to, or an HR administrator modifying the salary of her boyfriend who works in another department.

A more disturbing problem is when an application user finds a way to steal / modify records they are not supposed to. SQL injection is the most common way such breaches occur. SQL injection is a type of bug in the application that allows the user of the application to do things they were not supposed to be able to do. While searching for such flaws can be done maliciously, they are sometimes discovered on accident by a knowledgeable user.

For example, our customer call center representative talks to Mr. O’Connor, and searches for the customer information by last name. He notices that he gets an unexpected SQL error from the application when entering O’Connor. This can clue the user to the fact that the application converts the field into a SQL without using bind variables and without validating the field content. Basically, the application code looks something like:

"select ... from customer_info where last_name = '" + field + "'"

and entering O’Connor creates an invalid SQL:

select ... from customer_info where last_name = 'O'Connor'

Knowing this, a simple SQL injection can be performed by search for customer last name of

' or 'a'='a

Which will generate this SQL:

select ... from customer_info where last_name = '' or 'a'='a'

The condition of this SQL is always true and will therefore retrieve information about all the customers in the database.

A lot can be done with such vulnerabilities in the application, and a large application is almost guaranteed to have such mistake introduced by a careless programmer. SQL injection is one of the most troubling security vulnerabilities and is especially problematic with applications that are open to the internet. Part 3 will discuss measures to help with this problem.

Users with code access
An application developer or anyone with access to the code running against the database can breach sensitive information. The most famous example of this type of breach is known as Salami Slicing or Penny Shaving: when interest is calculated, there are always fractions of a penny that are rounded down. A malicious developer can accumulate those into his own account thereby embezzling funds without affecting the bank’s bottom line.

Another famous security problems involving code is that backdoor – a loophole left by developers that allows them to gain access without authenticating by regular means.

There are an endless number of examples of what developers can put in their code that will allow them to breach sensitive information.

Internal users with or without computer access
Users that work for the company have a higher opportunity of breach security than those outside of it. There are many opportunities that they can take advantage of, depending on the environment they work in:

• There are computer terminals around, and they might come across and unlocked terminal from time to time. They can also install key loggers and other security countermeasures.
• There are network ports around them all the time. Using those allows them to tap directly into the network bypassing any corporate firewalls.
• They might know other employees that will give them access (intentionally or unintentionally).
• They have access to the work environment of other employees in which they might be able to find written passwords.
• They have knowledge of the corporate structure, corporate mentality, key personnel and some procedures and policies. Such knowledge can help obtain access by manipulating individuals.

Once connected to the network, the next challenge is to obtain access to the data. To do so, one would need to breach the Oracle database, the application, the operating system, storage etc. The previous part of this post contains information about breaching these systems as well as the sections below on Local and Remote breaching.

External threats
External threats have several basic initial attack vectors:

• In many cases, companies have an internet facing application that allows customers or other individuals to access information over the internet. Vulnerabilities in these applications such as a SQL injection is the first thing an attacker would look for.
• The corporate network is protected by the corporate firewall. While beaching the firewall directly can be a problem, the firewall often times have holes allowing access to internal systems. Those can sometimes be compromised to gain access to the network
• Most companies have a wireless network (WiFi) nowadays. WiFi networks with little or no security can be easily breached. Even secured WiFi networks can be breached, most commonly by simply asking someone for the password.
• Physically accessing one of the facilities connected to the corporate network is another means of breaching security. Once inside the doors, there are many opportunities similar to those available to most regular employees.
• Calling the helpdesk or otherwise manipulating employees of the company to give access is probably the easiest means of breaching security. The human element is the most susceptible attack vector. For example, gaining access to VPN can sometimes be easily achieved by asking the helpdesk to “reset your password”.

Once connected to the network, the next challenge is to obtain access to the data. The rest of this posts has information about that.

Local Breaching
Local Breaching is the attempt to gain elevated privileges in a system that you can already log into. This can mean to obtain root privileges on a Unix system from a regular user, to obtain DBA privileges in an Oracle database from a non-DBA account etc.

Local breaching is accomplished by taking advantage of bugs in the system in question. While one might consider this to be the job for an expert hacker, most systems can be breached by following recipes.

There are many websites devoted to the collection of recipes for breaching various systems. Those recipes are contributed by various hackers that find vulnerabilities and means of exploiting those. The recipes are usually designed to be a simple matter of cut-n-paste or following a simple procedure.

You can search the site by the type of system you are faced with and find a list of these recipes exploiting various security flaws. Each recipe is usually designed for a particular version (or patch) of the system, but most users just try these exploits one by one until they find one that works.

In my experience in system security, I’ve often encountered transcripts of users that were clearly very novice, running what seemed like a complex exploit they pasted into their terminal (often having problems pasting it correctly).

As a good rule of thumb, one should assume that a user that is able to log into a system, can (with enough time and effort) obtain access to anything one that system.

Remote Breaching
While local breaching is usually a matter of searching for the right recipe, remote breaching is significantly more difficult. Most systems have little or no remote exploits and those that do tend to patch those quickly and efficiently. Searching hacking sites for remote exploits can be done, but few (if any) results are likely to be found, and none of which are likely to match the exact version of the system in question.

Remote breaching is therefore based initially on obtaining a login to the system. Trying default passwords, key loggers, network sniffing, connection hijacking, spoofing and a myriad of other tricks can be employed, including the manipulation of employees to reveal or reset passwords.