Implementation options: Knowing and controlling how database logins are used

The first step in addressing vulnerabilities associated with lax protection of database password information is knowing who is accessing your data.

You should start by creating a report showing which database usernames are being actively used, what IP addresses are connecting using these user-names, and what applications are being used to access the database. The applications sometimes map to executables and sometimes to drivers; in both cases I refer to them as source programs. I usually recommend also showing the number of database sessions each such entry produces over time—it helps identify which access points are the main application tun-nels. Figure 5.2 shows an example of such a report (the usernames have been somewhat blurred so as not to reveal any information that might be useful to a hacker).

This report can help you in several ways:

1. It shows you who is accessing your database. You can then use this information to find application owners and schedule reviews of how passwords are being stored in each one of these client machines. Without this information you can never know when you’ve covered all places that store your database passwords. You should pursue each such access point and review where and how the passwords are stored. While this may be difficult and take a long time because you will need to work with others who may not be part of your group, this is the only way you can be assured that there are no gaping holes.

2. Once you have cataloged all access points, use this report as a baseline. This means either periodically producing this report and compar-ing it with the original (the baseline) to look for new access points, or creating a real-time alert that notifies you when a new access point suddenly appears. Such a new access point can mean one of two things, both of which may require your attention:

The first is a new application or client that legitimately is using this database user. Examples of such cases can include upgrades to the database drivers, application servers, change in tools, or new modules/programs being installed. In all cases you should

5.1 Reviewing where and how database users and passwords are maintained 135

Chapter 5

review these new access points to make sure they did not rein-troduce clear text password vulnerabilities. In addition, if you notice that the same database username is being used from numerous different client IPs, you may want to segregate the usage of this username to only one client source.

The second case that can cause deviation from the baseline is actual hacker attacks. When hackers get the username and password from the application, they will usually connect to the database from another machine or using a different pro-gram. As an example, hackers may prefer to run a Perl script from their own laptops; this is much easier than fully compro-mising the application server to a point that they can issue arbitrary SQL using the application server. Moreover, hackers run the risk of being discovered if they remain logged into the application server host for a long time. It is easier and safer to Figure 5.2

Start by listing which username is being used to access the database and where such access comes from.

136 5.1 Reviewing where and how database users and passwords are maintained

take the username and password and continue the attack from their own machines. For you this means that by monitoring this access data, you may be able to identify an attack. Hence, if your environment is stable and there are little or no changes from the baseline under normal conditions, a real-time notifi-cation on any divergence is a very good idea.

Creating this type of report is not difficult. The simplest way is to use a third-party database security tool that supplies this information. Look for products that use the buzz term “who-what-when-where” related to data-base access or datadata-base audit. These products will usually have this report as a built-in feature or will allow you to easily build this report.

If you don’t want to introduce a new tool, you can get at this informa-tion yourself—albeit through quite a bit of work. In addiinforma-tion, doing it yourself will usually be limited to producing a snapshot, will not support real-time alerts, and will not support baseline generation without a large-scale development effort.

As an example, to get access information in Oracle, you can query the v$session table. A query of the form

select machine, terminal, program from v$session;

returns records of the form:

USERNAME MACHINE PROGRAM

--- --- ---SYSTEM WORKGROUP\RON-NY sqlplusw.exe

where RON-NY is the client machine from which access was initiated using sqlplus signing on as SYSTEM. The equivalent information in SQL Server is extracted using:

select loginame, hostname, program_name from sysprocesses

In both cases you will have to write a job that continuously looks at this information and collects it to form a baseline. Alternately, you can use the database’s auditing or tracing capabilities to create this baseline; this topic is discussed further in Chapter 12 and 13.

5.1 Reviewing where and how database users and passwords are maintained 137

Chapter 5

Once you have a baseline, you can choose to block database access that does not match the baseline. Let’s revisit the case in which hackers steal the database username and password from a clear text configuration file on the application server and then connect to the database from their own machines. In this case the attack will come from an IP that is not part of the baseline. You can block this type of attack by limiting access to your data-base to certain IP addresses. This can be done using datadata-base capabilities or firewalls. For example, in Section 3.7you learned how to configure Oracle to limit access to a limited set of IP addresses.

The more functional option is to use a firewall, as shown in Figure 5.3.

Here too you have two main options: (1) use a standard firewall, which will allow you to block access based on IP addresses and ports only, or (2) use a SQL firewall, which will allow you to build rules that are based not only on IP addresses but also on database usernames, source programs, and even database objects. It will allow you to define precisely which source programs running on which hosts can access the database using the login name. This takes the report shown in Figure 5.2 and converts it not only to a baseline, but to an enforced security policy.

If you choose to employ this type of protection, you may want to cou-ple it with a real-time notification on any policy violation. Hackers may try to connect to the database from their machines. When this fails because of a SQL firewall, they may guess that you’re employing some kind of IP-sensitive protective layer and go back to the application server host to launch the attack. Hackers can also spoof the IP address of the application server and still launch the attack from their own machines.

However, in both cases the first attempt was initiated naïvely from their machines, and the attack refinement process takes time; if you get an alert in time, you can stop the attack before hackers can figure out how to bypass your security measures.

Figure 5.3 Using a firewall between applications and the database.

138 5.1 Reviewing where and how database users and passwords are maintained

A SQL firewall is the only way to enforce this kind of access control, especially if it has to be database-agnostic to support a heterogeneous envi-ronment. Using a SQL firewall, you can carefully define what is allowed (and what is denied) at an application/tool level, an IP level, a command and object level, and so on. The database cannot usually provide this level of access control.

The closest such function implemented natively within a database is an Oracle function involving SQL*Plus that allows you to limit actions per-formed by SQL*Plus. For non-Oracle readers, SQL*Plus is Oracle’s equiva-lent to isql in Sybase, Query Analyzer in SQL Server, DB2’s Command Line Processor, and the MySQL command line. SQL*Plus implements access control beyond the login name and database permissions. It allows you to specify which commands a user can or cannot perform once signed on to the database using SQL*Plus.

This functionality is supported through the use of the PRODUCT_PROFILE table (and through the PRODUCT_PRIVS view that is used by users other than SYSTEM):

Name Null? Type

--- --- PRODUCT NOT NULL VARCHAR2(30) USERID VARCHAR2(30) ATTRIBUTE VARCHAR2(240) SCOPE VARCHAR2(240) NUMERIC_VALUE NUMBER(15,2) CHAR_VALUE VARCHAR2(240) DATE_VALUE DATE

LONG_VALUE LONG

When you log into Oracle using SQL*Plus, the tool issues the following query to the database:

SELECT

ATTRIBUTE,SCOPE,NUMERIC_VALUE,CHAR_VALUE,DATE_VALUE FROM

SYSTEM.PRODUCT_PRIVS WHERE

(UPPER('SQL*Plus') LIKE UPPER(PRODUCT)) AND (UPPER(USER) LIKE USERID)

If (as SYSTEM) I issue the following command:

insert into