Keeping Privileged Users Under Control In Oracle DatabaseTeam Shatter Exclusive

Posted September 30, 2011 by TeamSHATTER Admin in Best Practices, Database Security, Oracle, Team Shatter Exclusive, Tips and Tricks, User Rights with 0 comments

As I have mentioned in my previous post Harnessing Privileged Database Users, Relational Database Management System (RDBMS) software is not designed to provide sufficient protection against database users that hold certain privileges such as like system privileges. These privileges are usually granted to database and application administrators — and also it is not rare to find them granted to normal and application user accounts even on production databases.

In this article I will discuss some practical actions that can be taken to keep privileged users under control in Oracle databases including those databases protected by Oracle Database Vault. First, I’m going to enumerate the ways in which a privileged user can compromise a database and then some guidelines on how we can minimize these threats. I’m not going to dig too much into why we need to protect from privileged users as it is clear if we take note of the increasing data breaches where insiders are the ones responsible for the attacks. Furthermore, almost all security regulations today require rigorous separation-of-duty and control over privileged users.

Now let’s see some of the most common ways in which a privileged user can compromise an Oracle Database and what required privileges are necessary to carry out  the attack. I will not show the steps and code required to perform these kinds of attacks, you can find plenty of code on the Internet, in this post I will focus more on the protective measures that we can take.

Getting OS Access From The Database

Oracle Database provides many ways in which a database user (with certain privileges granted) can access the Operating System and execute commands. If these commands are executed with the OS user that is running the Oracle server process then the whole database can be compromised and any native auditing mechanism provided by the database can be bypassed.

 The table below contains some of the ways in which a database user can get OS access and what are the privileges required.

Escalating To SYSDBA

SYSDBA is the highest privilege in an Oracle Database. It has unlimited access to all data and can make any configuration change. In a database with Database Vault installed, it is possible to restrict SYSDBA users from accessing certain data but the protection is not complete. There are ways to bypass the defenses and compromise the data protected by Database Vault.

It is important to note that with SYSDBA privilege it is possible to compromise Oracle Database native auditing system. Therefore not only will the user gaining SYSDBA privilege  be able to leverage any malicious actions on the database, they will also be able to do it without leaving any trace in the native database auditing system.

  

Compromising Oracle Database Vault

Oracle provides an optional add-on that can be installed over an existing Oracle Database to further protect it, especially from privileged users. This product, called Oracle Database Vault, can be used to limit the power of the DBAs so that they can continue performing their jobs but without access to sensitive data.

This product is not perfect and there are some ways in which a privileged user can compromise the protections and disable it.

Enumerating Users Which Have These Privileges

The first protection measure that we can take is to remove the dangerous privileges mentioned above from the users that don’t need them. This is associated to the principle of least privilege. The first step is to make a list of the users holding these privileges.

Enumerating all the users that have these dangerous privileges granted can be a challenging task. The effective privileges that a user has are determined by complex rules that frequently vary from vendor to vendor. We are not going to discuss this in detail, for those interested in further reading about effective privileges I recommend the post by Gene Trog: What Are My Users’ Effective Database Privileges?

There are some simple queries that can be used to get an idea of which users and roles have been assigned these potentially dangerous system privileges.  The query below lists all users and roles with direct grants on dangerous system privileges:

Things get more complicated when we try to enumerate all users with EXECUTE permissions on packages or procedures that are potentially dangerous. As shown in the tables above, EXECUTE rights on packages or procedures can be abused to escalate to SYSDBA privilege, for the case of SYS-owned packages, or to get access to the underlying Operating System on the Database Server for procedures that call native functions.

By default, Oracle Database comes with EXECUTE privileges granted to PUBLIC on a large number of packages (meaning that all database users will have this permissions granted). As a result there is a substantial attack surface for SQL Injection and Buffer overflow vulnerabilities that could lead to SYSDBA privilege escalation or Operating System access as the Oracle Database owner.

Additional Protection Measures

To limit the dangerous system privileges that can be used to escalate to SYSDBA or access the Operating System, there are some other actions that we can take to minimize the impact of the abuse of these privileges.

Take into consideration that prior to implementing these recommendations in a production database it is important to test them to detect possible incompatibilities or other issues.

 Recommendations:

  • For Local External Jobs: use a low privilege Operating System user account other than “oracle” or LocalSystem. To do this:

In Unix/Linux: Specify  the user in $ORACLE_HOME/rdbms/admin/externaljob.ora (for Oracle 10.2.0.3 and later), or change the owner of $ORACLE_HOME/bin/extjob (for Oracle 10.2.0.2 and earlier).

In Windows: Change the authentication user defined in the external job service (OracleJobScheduler{SID_NAME}). After configuring a different user, enable and start the service.

Note that for an external job created in SYS schema the user under which it is executed is always the Oracle Database owner regardless of the configuration in externaljob.ora file or OracleJobSchedure Service. The only users allowed to create jobs in SYS schema are SYSDBA users.

  •  For External Stored Procedures (ExtProc):

The ExtProc functionality has changed in Oracle 11g. Since this version, the Listener is no longer in charge of spawning the extproc agent to run the external library in a default configuration. In Oracle 11g the Oracle process is the one that spawns the extproc agent.

If your application does not use external stored procedures:

  • Remove the extproc functionality. You can do this by deleting the external procedure agent: extproc (Unix) extproc.exe (Windows) file from $ORACLE_HOME/bin directory.
  • Remove ExtProc entries from listener.ora file

If your application needs external stored procedures you can secure it by doing the following:

  • Configure a separate listener for external stored procedures and make it run under a different Operating System account other than the Oracle software owner or LocalSystem.
  • Restrict what external libraries can be loaded using EXTPROC_DLLS environment variable in listener.ora file (if extproc agent is configured there) or extproc.ora file located in the $ORACLE_HOME/hs/admin directory.

This is to avoid that the use of external procedures to execute Operating System by calling an external library function.

Since Oracle Database Release 9.2 the external libraries that can be used with external procedures call in a database must reside on $ORACLE_HOME/lib (Linux) or %ORACLE_HOME%\bin (Windows). This is not enough because on those directories there are libraries that contain functions which allow Operating System access.

We should use the EXTPROC_DLLS environment variable setting to restrict the external libraries that can be loaded and authorize only those libraries that we know are safe and required for our applications to work.

See Configuring Oracle Net Services for External Procedures for more information.

For more information see Oracle Documentation: Enabling Advanced Features of Oracle Net Services

  •  Use Third-Party Software –like database activity monitoring software- to audit all access to the database, including access from privileged accounts such as SYSDBA. This should be done whether native database auditing is in use or not.

 There are protection measures that are specific for databases with Database Vault installed:

  • Protect MACSYS Schema With A Realm.

Can be done with the following PL/SQL program:

  • Restrict Access To The Database Server Operating System. From there it is possible to disable Database Vault protections. Pay attention to the ways in which a database user can get OS access as the oracle software owner from the database and implement the measures stated earlier to prevent them.
  • Grant Oracle Database Vault Account Manager (DV_ACCTMGR role) only to trusted personnel. We have discovered security issues that allow users granted DV_ACCTMGR role to compromise Database Vault protections.
  • Do Not Trust Factors Such As Module Name, Terminal And Similar That Can Be Manipulated By The Client Software. They are not a reliable way to determine if an action is authorized or not.

Conclusion

Protecting from privileged users is not an easy task and certainly not one that can be taken carelessly as it is a crucial piece of current security regulations. The intention of this article was to enumerate some of the threats organizations encounter when trying to keep privileged users in Oracle Databases under control and to provide guidelines on how to mitigate the risks.

Beyond all the mitigation measures to protect from the threats posed by privileged users it is important to note that auditing and accountability is of special importance for privileged users and is sometimes overlooked. An example of this is when the auditing task is left solely to the native database auditing capabilities. This can be easily manipulated by a privileged user determined to erase the trails if a fraudulent action.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Please note: JavaScript is required to post comments.

Powered by