Oracle Security and Auditing

8/13/2019 Oracle Security and Auditing

1/31

Oracle Security and Auditing

Oracle Securityand

Auditing

By K. K. Mookhey [email protected]

Network Intelligence India Pvt. Ltd.

www.nii.co.in

Copyright 2003 by Network Intelligence India Pvt. Ltd. All rights reserved. No

part of this publication may be reproduced or distributed in any form or any means

whatsoever, without the prior written permission of Network Intelligence India Pvt.

Ltd.

If you find this document useful and wish to recommend it to someone, please do

not make copies of it, but ask them to download it fromhttp://www.nii.co.in/research/handbook.html


http://www.nii.co.in/research/handbook.html
mailto:[email protected]://www.nii.co.in/http://www.nii.co.in/research/handbook.htmlhttp://www.nii.co.in/research/handbook.htmlhttp://www.nii.co.in/mailto:[email protected]


2/31


Introduction

This document is about the practical techniques for auditing Oracle databases. It gives the queries andthe configurations that the auditor must check for when carrying out an Oracle audit. Most of thematerial in this document applies to both Oracle 8i and 9i. Wherever it differs we have clarified the

distinction. Towards the end we also give the tools and products that an auditor might use in order toease the task of data gathering and reporting. Finally, not much previous Oracle experience is assumed,but some general knowledge about SQL and relational databases would aid the reader.

For auditing the security of an Oracle database, we will execute SQL queries using the SQL*Plus utilitythat gets installed whenever Oracle client is installed. The output of these queries can be voluminousand therefore we must store it in an output file. You may also use the DBA Studio to view the schemas,tables, views, users, etc., and the SQL Worksheet to execute SQL queries. You could also use thecommand-line sqlplusutility. When auditing Oracle Security, we must also audit the underlyingOperating System. But we do not go much into detail on that aspect. We will however explain how toaudit that part of the OS Security that deals with the database.

Contents:Introduction to Oracle Security

Secure Installation and OS SecurityGathering General InformationDatabase ParametersUsers and ProfilesRoles and Privileges

Oracle Built-in AuditingMiscellaneous Security AspectsReferences




3/31


Introduction to Oracle Security

Some time back Oracle had started a marketing campaign, which proclaimed its product to beUnbreakable. During this campaign, a UK based researcher discovered a dozen critical security flawsin Oracle that proved once and for all that no system could claim to be 100% secure. Since then Oracle

has put into place a number of security measures, but recently a series of critical flaws were once againdiscovered in the latest version Oracle 9i. What all this really means is that it is we security auditors,administrators, and DBAs who must really take the onus of securing our databases.

Oracle provides extensive measures to implement security, while at the same time maintainfunctionality and efficiency. With Oracle 8i, Oracle has also started providing for a new kind of securitycalled Fine-Grained Security which allows us to ensure auditing the tables on a per-user or per-fieldbasis and Oracle Label Security, which enables access control on each row of any table in thedatabase.

Secure Installation and OS Security

This section briefly touches upon the method of installing Oracle securely and the measures that must betaken to secure the Operating System as it relates to the Oracle database. We cover Unix and Windowsseparately and it is assumed that the reader is familiar with common administration tasks dealing withuser permissions and filesystem structures.

Unix and Oracle SecurityUsually, Oracle installs under the username oracle and the group oinstall. During installation itcreates the DBA group dba, which maps to the database roles OSDBA, and OSOPER. All these aredefault names and create insecurity. It is advisable for the administrator to choose unique names duringthe installation process itself to make it more difficult for an attacker to guess the Oracle owner andgroup names.

It is also advisable that each administrator or operator of the database should have their own accountsand these should be added to the respective groups instead of having one generic all-powerful DBAaccount. This can be viewed by seeing group membership information in the/etc/groupfile.In Unix, each user has his own umaskvalue. The umask determine the permissions with which newfiles get created by the user. For a detailed description on Unix permissions and how to read them, seehttp://www.acm.uiuc.edu/webmonkeys/html_workshop/unix.htmlOracle recommends that the user who is designated as the owner of the Oracle software should have anumask value of 022. This means that any new files created by him will have permissions 755. A usersumask value is specified in one of his startup scripts, such as the .profilefile in his home directory, orthe default is picked up from/etc/profileor/etc/default/profile. An easy way to check the oracle ownersumask value is to login to his account and issue the command umask at the Unix prompt.

The most important part with the Oracle installation is the file permissions on the Oracle files andfolders (these are present in ORACLE_HOME and you can go to this folder directly by executing cd$ORACLE_HOME at the Unix command prompt). The model suggested by Oracle is (assumingoracle is the account used during Oracles installation):



This account, oracle, should own all the files and directories and must have full permissions onall files
http://www.acm.uiuc.edu/webmonkeys/html_workshop/unix.htmlhttp://www.acm.uiuc.edu/webmonkeys/html_workshop/unix.html


4/31


The Oracle installation group oinstall by default should have read, write, and executepermissions on the oraInventory directory, but should not have write permissions on any otherfiles.No other user should have write access to any files under the ORACLE_HOME directory.

This is actually the minimum level of security that should exist on the files and folders underORACLE_HOME. Usually, you would want to implement tighter controls. As an auditor, you couldrecommend the following setup:

1. The oracle software installation account oracle should be given no access once installationis over. In fact, you may recommend that this account be locked out by setting an invalidpassword hash in the/etc/shadowfile. This would prevent anyone from logging into the Unixsystem with the username oracle

2. Create a single group called oradba, which is mapped to the OSDBA role during installation.3. Any accounts that need to carry out database administration should be added to this group.4. The permissions on the entire ORACLE_HOME directory should be to give the owner and the

group full permissions and no access at all to any body else (770).

5. Furthermore, you may remove write permissions even to the members of the oradba group oncritical directories such as $ORACLE_HOME/rdbms/logand $ORACLE_HOME/rdbms/auditand the directories containing the data files, to ensure that even a DBA cannot modify the audittrails or the database files directly.

6. Critical files: Certain files should be secured even further:a. Listener.ora in $ORACLE_HOME/network/adminb. Remote password files in $ORACLE_HOME/dbs/orapwc. Snmp*.ora files in $ORACLE_HOME/network/admindirectory

Users must be given no permissions at all on these files.

Also, check all SUID files in the ORACLE_HOME directory. In Unix, SUID files are those that executewith the privileges of the owner of the file. As far as Oracle is concerned, SUID files can either executewith privileges of the oracle account or of root. Both are of equal concern to us, and it is extremelyvital that apart from the Oracle owner, and the DBA group, no one else has any permission on these files(770). To find all SUID files:unix#>find $ORACLE_HOME -perms 4000

Finally, you must check for any SQL*Plus commands being executed on this system. SQL*Plus is theutility to connect to the Oracle database to directly execute SQL queries. It is possible to use SQL*Plusby supplying the username and the password in the command itself. For instance, sqlplussystem/manager. This is usually done when sqlplus is to be executed with batch jobs. To check for this:unix#>ps ef | grep sqlplusAnd see if any username/password combinations pop up.

You must also ensure that all other Unix security measures have been followed.




5/31


6/31


General Information Gathering

Initially, we must make an inventory of the database version, its components and their versions. This ismainly to ensure that all components are upgraded to the latest secure versions as recommended byOracle.

Queries can be executed under two privilege levels:1. As the user sys with SYSDBA privileges2. As a lower-privileged account who must have the necessary SELECT permissions on all system

tables and views in the SYS and SYSTEM tablespaces. You may ask the local DBA to createsuch an account for you and allot the required privileges. This is the preferred method whendoing an audit. Mainly, you will need to have CREATE SESSION system privileges, andSELECT object privileges on all tables and views in the SYS and the SYSTEM tablespaces, andyour default tablespace as SYS.

For the remainder of this document, we shall assume that we are connected with the AUDITOR accountwith appropriate privileges.

When connecting using SQL*Plus, you will be asked for the Username, Password and the Host String.Now on a given Oracle installation, it is possible to have multiple database instances running. Each suchinstance is an independent database with its own tables, users, roles, privileges etc. In the Host Stringyou must provide the name of this instance, also known as SID (System Identifier). On your targetOracle server, there might be multiple SIDs. The more the number of SIDs, the more the resourcesbeing used up, and the greater the chance of an insecure configuration on one or more of them. Youmust ascertain that only the absolutely necessary instances are configured on a production database. Youcan determine the current SID by studying the environment variables on the target system. If it is a Unixsystem then issue the command envat a command prompt and determine the value of the variableORACLE_SID. Enter this value into the Host String to connect to the database. On Windows, you may

right-click on My Computer, and go to Environment to check for the value of the ORACLE_SIDvariable.

If there are multiple instances running on the same database, then their configuration files will be storedin files of the name init.ora as mentioned earlier. But, it is preferable that there be only oneinit.ora file which contains the common parameters, and the other init.ora file must contain a lineof the type IFILE=Path of the main init.ora file, along with the minimum necessary instance-specificparameters. This ensures that a change in any configuration parameters has to be made only once in themain init.ora file, and it will get reflected for all the instances once they are restarted.

Once connected to a given instance, you will see the version number of the SQL*Plus utility, and will

be landed onto a prompt. Before issuing the commands you may start spooling to an output file by goingto File | Spool | Spool File. This not only saves the queries and their outputs, but it also helps to maintainaccountability of your actions. You may also prefer to gather the entire list of queries given in thisdocument into a single file and give this as the input to SQL*Plus by going to File | Open and navigatingto the .sql file. You can then analyze the output of these commands offline.




7/31


To gather a list of components and their versions, issue the following command at the SQL prompt:

SQL>select * from product_component_version

Here the output will give us the component version in a form such as 8.1.7.0.0. Each of the numbers

gives us vital clues as to the patches applied to Oracle.

8.1.7.0.0

Version Number Platform specific patch set number

New features release number Generic patch set number

Maintenance release number

Version number

This number represents the major Oracle release, indicating significant new additions and features

New Features Release Number

Represents new features in the same release

Maintenance Release Number

Represents a new maintenance release. May also include some new features

Generic Patch set Number

Identifies a generic patch set which is applicable across all operating systems and hardware platforms.

Platform Specific Patch Set Number

Represents a patch set that is applicable only to specific operating systems or hardware platforms.

You must ensure that the latest generic and platform patch set number has been applied to the systembeing audited. Information on the latest vulnerabilities and patches is available at Oracles websitehttp://otn.oracle.com/deploy/security/alerts.htm. To be able to download patches you need to be amember of Oracle Metalink http://metalink.oracle.com

Next you must gather information about the instances configured on this database, and their status i.e.whether they are configured to run, and if so in what mode. This information is maintained in a SystemView called v$database:

SQL>select NAME, CREATED, LOG_MODE, OPEN_MODE from v$database


http://otn.oracle.com/deploy/security/alerts.htmhttp://metalink.oracle.com/http://metalink.oracle.com/http://otn.oracle.com/deploy/security/alerts.htm


8/31


The first two parameters are self-explanatory. The third parameter tells us whether Oracles built-inauditing has been turned on for this instance or not. And the OPEN_MODE parameter tells us whetherthis database is in READ WRITE or only READ. Most databases would need to be in READWRITE mode.

SGA System Global AreaThe System Global Area is the memory Oracle takes when the database is started. Information about theSGA parameters can be gathered with:

SQL>select * from V$SGA

The parameters are:Fixed Size, Variable Size, Database Buffers, and Redo Buffers. These parameters must be set accordingto the available memory, size of the database, and the number of expected concurrent transactions.Details on this and the recommended settings for different database sizes are given in the defaultinit.ora, supplied by Oracle.




9/31


Database Configuration Parameters

The configuration parameters for each instance of the database are in files of the name init.orapresent in the $ORACLE_HOME/admin//pfile directory. You must study this file to ensure thatcritical security parameters are set properly. Alternatively, you may execute the following SQL query to

gather only the specific configuration parameters that we need to audit from a security perspective:

SQL>select name, value, description from v$parameter where NAME in(O7_DICTIONARY_ACCESSIBILITY, audit_trail, db_name,dblink_encrypt_login, instance_name, log_archive_start,os_authent_prefix, os_roles, processes ,remote_login_passwordfile, remote_os_authent, remote_os_roles,resource_limit, sessions , sql92_security,utl_file_dir)

The following table gives the explanation of each of these parameters, and their suggested values:



NAME DESCRIPTIONSUGGESTED VALUES AND

REASONING

O7_DICTIONARY_ACCESSIBILITY

Version 7 DictionaryAccessibility Support

Users with the ANY privilege (see section onPrivileges) would be allowed to access theobjects (tables, views, triggers, etc.) in theSYS schema. These are very critical objectswith very sensitive information, and you canprevent a user from accessing thisinformation, even if he has the ANYprivileges, by setting the value of thisparameter to FALSE. Under no circumstancesis it recommended to set this value to TRUE.

audit_trail Enable system auditing

To turn auditing on and control whetherOracle generates audit records based on theaudit options currently set, set the parameterAUDIT_TRAIL to "DB" in the database'sparameter file. This will start Oracles built-inauditing and direct all auditing data to thedatabase's auditing trail.

db_name

database name specified

in CREATEDATABASE

This is for information purposes only thename of the database.

dblink_encrypt_loginenforce password for

distributed login alwaysbe encrypted

The Oracle configuration parameterDBLINK_ENCRYPT_LOGIN specifieswhether attempts to connect to remote Oracledatabases through database links should useencrypted passwords. Prior to Oracle 7.2,


10/31




passwords were not encrypted before beingsent over the network. In order to connect toolder servers, Oracle included this parameterto retry failed connections using theunencrypted format. If the

DBLINK_ENCRYPT_LOGIN parameter isTRUE, and the connection fails, Oracle doesnot reattempt the connection. If this parameteris FALSE, Oracle reattempts the connectionusing an unencrypted version of the password.Servers with DBLINK_ENCRYPT_LOGINset to FALSE can be coerced into sendingunencrypted passwords by computers betweenlinked servers. This parameter must be set toTRUE in the init.ora configuration file.(See the section on Database Links for more

details)

instance_nameinstance name supported

by the instance

This is just for information purposes and itsvalue is the same as that which you used in thehost-string.

log_archive_startstart archival process on

SGA initialization

To enable automatic archiving of filled groupseach time an instance is started, include theinitialization parameterLOG_ARCHIVE_START in the databasesinitialization parameter file and set it toTRUE. The new value takes effect the next

time you start the database.

os_authent_prefix

If the database has been configured to use theOperating System authentication, rather thanits own, then the users who are identified onthe OS rather than on the database, have theiruser names on the database prefixed by thevalue shown here in order to distinguish themas OS users. By default this value is OPS$,meaning that a user who is identified on theOperating System as user1 will have acorresponding database login as OPS$user1

os_rolesretrieve roles from the

operating system

To operate a database so that it uses theoperating system to identify each usersdatabase roles when a session is created, setthe initialization parameter OS_ROLES toTRUE (and restart the instance, if it iscurrently running). When a user attempts tocreate a session with the database Oracle


11/31




initializes the users security domain using thedatabase roles identified by the operatingsystem. This may be set to TRUE if thedatabase is configured to use externalOperating System authentication.

processes user processes

This parameter determines the maximumnumber of operating system processes that canbe connected to Oracle concurrently. Thevalue of this parameter must include 5 for thebackground processes and 1 for each userprocess. For example, if you plan to have 50concurrent users, set this parameter to at least55.This parameter is set to an acceptablevalue.

remote_login_passwordfilepassword file usage

parameter

This parameter tell Oracle whether to check

authentication information from a file createdusing the orapwd utility instead of theSYS.USER$ table. This is mainly for remoteadministration of a database from a client PCand should in most cases be strictly avoided.The preferred value of this parameter isNONE. It can also be set to EXCLUSIVE,which means that only one instance can usethis file, but it can contain hashed passwordsfor users other than SYS and INTERNAL. Itcan also be set to SHARED, which means

multiple instances can use the password file,but only hashed passwords for SYS andINTERNAL are allowed. See the section onUsers and Roles for more information on theINTERNAL account.

remote_os_authentallow non-secure remoteclients to use auto-logon

accounts

It is strongly recommended that the value ofthis parameter be set to FALSE. Setting it toTRUE allows a user to connect to the databasewithout supplying a password, as long as he islogged on to his operating system with anallowed user name. An attacker can

impersonate the user on his own OS and getconnected to Oracle, if the user is set up forremote authentication.

remote_os_rolesallow non-secure remote

clients to use os roles

The same logic applies here as well. Thisvalue must be set to FALSE to disallow amalicious user from connecting to thedatabase and assumin a role that is identified


12/31


by his own Operating System, instead of bythe database.

resource_limitmaster switch for

resource limit

If a database can be temporarily shut down,resource limitation can be enabled or disabledby the RESOURCE_LIMIT initialization

parameter in the databases initializationparameter file. Valid values for the parameterare TRUE (enables enforcement) and FALSE;by default, this parameters value is set toFALSE. Once the parameter file has beenedited, the database instance must be restartedto take effect. Every time an instance isstarted, the new parameter value enables ordisables the enforcement of resourcelimitation.

sessionsuser and system

sessions

This is the maximum number of sessions thatcan connect to the database. Usually, youbegin with the default value and increase it ifyou find that the peak usage is more thanexpected.

sql92_securityrequire select privilege

for searchedupdate/delete

The SQL92 standards specify that securityadministrators should be able to require thatusers have SELECT privilege on a table whenexecuting an UPDATE or DELETE statementthat references table column values in aWHERE or SET clause. SQL92_SECURITY

lets you specify whether users must have beengranted the SELECT object privilege in orderto execute such UPDATE or DELETEstatements.

utl_file_dirDirectories that the

UTL_FILE package canaccess

The UTL_FILE package allows Oracle to readand write files on the host Operating System.The value of this parameter determines whichdirectories on the OS can be accessed byPL/SQL statements. Setting this option to *in effect turns of any access control on thedirectories. It must also not be set to the

current directory .. In face, access to theUTL_FILE package itself must be severelyrestricted.




13/31


Users and Profiles

Before we move onto describing users and profiles on an Oracle database, let us determine our mainsources of information for Oracle. Most of the information that we will be gathering in the next fewsections is from views that exist in the SYS schema (you can see this using DBA Studio). These views

are of three main types:1. DBA_: views that are for the DBA and list all information2. ALL_: views that list all information except any sensitive data3. USER_: views that list information pertaining to the currently logged on user, who

is executing the query.

When carrying out an Oracle audit after logging in with a specially created account, you must ensurethat you have been granted SELECT privileges on all views that begin with DBA_, ALL_, and USER_.

To see all the users created on the system:SQL>Select * from DBA_USERS

In order to get only the fields we want to study:SQL>Select Username, Password, Account_Status, Default_Tablespace,Profile from DBA_USERS

Let us study each of these columns one by one. The first two column lists all the users created in thisdatabase, and their hashed passwords. We must ensure that all default accounts have been removedunless they are absolutely required. The problems with default accounts are well known: they arecommon knowledge, their passwords are also known (see table of default users and passwords below),and they have the privileges that have been granted to the role PUBLIC (more on this in the section onRoles and Privileges). As a result, most hackers will try to log in to your Oracle database using any

number of default username/password pairs. The following is a table of these accounts, and what theirpurpose is:



Username Default Password FunctionSYS CHANGE_ON_INSTALL The most powerful account

on the database that ownsall the internal objects thatmake up the database itself.

SYSTEM MANAGER The initial very powerfulaccount from which most ofthe object creation is done.

Its default password is sowell-known, that it must bechanged immediately.

SCOTT TIGER This account is mainly forlearning SQL and fortesting databaseconnectivity over thenetwork. You may choose


14/31


15/31


BLAKE PAPER ``

JONES STEEL ``

CLARK CLOTH ``

AURORA$ORB$UNAUTHENTICATED

Randomly generated Used for supporting theOracle 8i Aurora JVM

facilities of the RDBMSserver to concurrentlyschedule Java execution.

ORDSYS ORDSYS Used to support Oracle 8iTime Series Option toenable working withcalendars and time seriesdata.

MTSYS MTSYS This account supports theMicrosoft TransactionServer and the Microsoft

Application Demo software.APPS APPS

SAP SAPR3 The defaultusername/passwordcombination if SAP isrunning.

During an audit, what we really need to check for is whether the default username/passwordcombinations exist or not. Now the passwords in an Oracle database are stored using a modified DESalgorithm. Therefore, we need to know the list of password hashes for these users as well. I recommendhttp://www.pentest-limited.com/default-user.htmfor not only a list of default username/passwords, but

also for a sample SQL script that you can run towards the end of the audit, to ensure that even if thedefault accounts exist, their passwords must be changed.

You can check for these accounts with a query like this (assuming you are already connected withSELECT privileges on SYS.USER$):SQL>Select DBSNMP has default password DBSNMP whereusername=DBSNMP and password=E066D214D5421CCC

Connect as INTERNALIn Oracle 8i and earlier, a user can connect to the database with the alias INTERNAL and the defaultpassword ORACLE. This would give him highest possible privileges on the database, including the

ability to start or shutdown a database. This feature was deprecated in Oracle 8i and has beencompletely removed in Oracle 9i. This is probably one of the highest security risks in Oracle. You cantest whether this account still exists with the default password, or an easy to guess password by:

SQL>connect internal/oracleOrSQL>connect internal/


http://www.pentest-limited.com/default-user.htmhttp://www.pentest-limited.com/default-user.htm


16/31


Going back to the output of our query on the DBA_USERS view, we want to audit for users whoseACCOUNT_STATUS is not LOCKED/EXPIRED i.e. it is OPEN. We will see later in PasswordParameters, how the account gets locked out or expired.

Next, we want to ensure that for no users does the DEFAULT_TABLESPACE value equal SYS or

SYSTEM. These are very highly privileges system tablespaces containing the tables that are required forthe oracle database to function and contain highly critical information. When the user logs in to Oracle,he is automatically assigned a tablespace according to the value set for this parameter. To enlist userswith the default tablespace as SYS or SYSTEM, execute the following SQL query:

SQL>Select Username from DBA_USERS where DEFAULT_TABLESPACE in(SYS,SYSTEM)

ProfilesThe final and most important user parameter is the Profile. In Oracle, user account restrictions in termsof password parameters and resource usage can be set with the use of Profiles. In a default installation,

Oracle creates one profile called the DEFAULT profile, which gives no password or resourcerestrictions. We must modify this profile to set its parameters appropriately.

You may execute the following query to get the values for the parameters in each profile defined in thedatabase:

SQL>Select * from DBA_PROFILES

Next, we describe each parameter, and its suggested value. Do keep in mind, though, that these are onlygeneral recommendations and need to be carefully evaluated for each specific instance. But theimportant thing is that the parameters must be changed from their default settings. This can also be done

by using a script called utlpwdmg.sql found in $ORACLE_HOME/rdbms/admin.

The parameters of each Profile are of two types: Kernel and Password. Let us see the Passwordparameters first:

FAILED_LOGIN_ATTEMPTS

The FAILED_LOGIN_ATTEMPTS parameter serves as a limit to the number of allowed failed loginattempts before the account is locked out. Setting this parameter to an acceptable value ensures that nomalicious user can try to guess passwords by repeatedly trying to login. Setting this value limits theability of unauthorized users to guess passwords and alerts the DBA as to when password guessingoccurs (accounts display as locked). Once an account is locked, it cannot be logged on to for a specified

number of days or until the DBA unlocks the account. (See the Password Lock Time and PasswordReuse Time below).Default value: UNLIMITED, meaning never lock an account.Suggested value: A user must be locked out after at least 3 failed login attempts. Ensure that this valueis set to 3, or a maximum of 6 but never more than that.




17/31


PASSWORD_LOCK_TIME

When a particular user exceeds a designated number of failed login attempts, the server automaticallylocks that users account. You must specify the permissible number of failed login attempts using theFAILED_LOGIN ATTEMPTS parameter above. Here you can specify the amount of time accountsremain locked.

Default value: UNLIMITEDSuggested value: .0006

PASSWORD_LIFE_TIME

This parameter determines the maximum validity period for a password. The user must change thepassword within the value of this parameter. This is one of the most critical parameters and its valuemust be set strictly as recommended. Setting this value ensures users are changing their passwords.Default value: UNLIMITED.Suggested value: As per the security policy, this may be set to a value between 30-60 days.

PASSWORD_GRACE_TIME

Users enter the grace period upon the first attempt to log in to a database account after their passwordhas expired. During the grace period, a warning message appears each time users try to log in to theiraccounts, and continues to appear until the grace period expires. Users must change the password withinthe grace period. If the password is not changed within the grace period, the account expires and nofurther logins to that account are allowed until the password is changed.Default value: UNLIMITED, meaning never require an account to change the password;Suggested value: 10

PASSWORD_REUSE_TIME

The PASSWORD_REUSE_TIME value specifies the number of days before a password can be reused.PASSWORD_REUSE_TIME can be set to a specific number of days; to UNLIMITED; or toDEFAULT, which uses the value indicated in the DEFAULT profile. Default value: UNLIMITED,which allows passwords to be reused immediately.PASSWORD_REUSE_TIME is mutually exclusive with PASSWORD_REUSE_MAX. IfPASSWORD_REUSE_TIME is set to a value for a given profile, PASSWORD_REUSE_MAX must beset to UNLIMITED for the same profile. And vice-versa.Default value: UNLIMITEDSuggested value: 1800

PASSWORD_REUSE_MAX

This parameter determines the number of password changes a user must make before he can re-use hiscurrent password. (Compare this with the PASSWORD_RESUE_TIME, wherein he can reuse hispassword if it is older than x number of days). This along with the other parameters for the profilefurther increases the impregnability of the user accounts. If PASSWORD_REUSE_MAX is set to avalue for a given profile, PASSWORD_REUSE_TIME must be set to UNLIMITED.Default value: UNLIMITEDSuggested value: UNLIMITED (assuming PASSWORD_REUSE_TIME has been set appropriately).

PASSWORD_VERIFY_FUNCTION



The PASSWORD_VERIFY_FUNCTION value specifies a PL/SQL function to be used for passwordverification when users who are assigned this profile log into a database. This function can be used to


18/31


19/31


IDLE_TIME

This setting limits the maximum idle time allowed in a session. Idle time is a continuous period ofinactive time during a session. Long-running queries and other operations are not subject to this limit.The limit is expressed in minutes. Setting an Idle Time Resource Usage limit helps prevent users fromleaving applications open when they are away from their desks.

Its recommended value is 15

CONNECT_TIME

Connect Time Resource Usage limits restrict the maximum elapsed time allowed for a session. The limitis expressed in minutes. Setting a Connect Time Resource Usage limit helps prevent users frommonopolizing a system and can ensure that resources are released when a user leaves his workstationwithout logging off the system.Its recommended value is 90



The default value for all of these parameters is UNLIMITED, and must be changed according to thevalues suggested above or those found appropriate depending upon available resources and expected

peak usage.


20/31


Roles and Privileges

In Oracle, privileges are assigned to roles and roles are assigned to users. You can think of roles inOracle, as groups in Unix or Windows. This facilitates easier management of users and privileges.Instead of assigning privileges to 100 users in the accounts department, you can create one ACCOUNTS

role, assign it the required privileges, and then assign this role to all the 100 users. If in the future, youdecide to remove a privilege you had granted earlier, all you need to do is remove it from the role, andautomatically all the users assigned to that role will lose the privilege.

To see all the roles that exist in the database:

SQL>Select * from DBA_ROLES

To first see what roles have been granted to a given user, RAKESH:

SQL> Select GRANTEE, GRANTED_ROLE, ADMIN_OPTION, DEFAULT_ROLE from

DBA_ROLE_PRIVS where GRANTEE=RAKESH

Remember that roles can be assigned to users as well as to roles. An entire hierarchy of roles can becreated. For instance, you may create roles ACCOUNTS and PERSONNEL for the respectivedepartments, and a role MANAGEMENT for senior managers. If the requirement is to provideMANAGEMENT privileges that have been granted to both ACCOUNTS and PERSONNEL, then theseroles can be assigned to MANAGEMENT. As a result, to really know all the roles assigned to a user,you must repeatedly execute the above query for the roles that appear in its result. We will see anexample of how to do this below.

Also, there is one critical role that you must ensure has not been assigned to any application users: the

RESOURCE role. This role includes privileges that are not required by most application users, and amore restricted role must be granted:

SQL>Select * from DBA_ROLE_PRIVS where GRANTED_ROLE=RESOURCE

Another role that you must also check for, is the CONNECT role. This role grants critical privilegessuch as CREATE TABLE, CREATE DATABASE LINK, and several others, which are not required bythe majority of database users. Instead of using the CONNECT role to grant users access to Oracle, aspecial role must be created with only the CREATE SESSION privilege, and then this role must begranted to all users. This can be checked as follows:

SQL>Select * from DBA_ROLE_PRIVS where GRANTED_ROLE=CONNECT




21/31


Privileges are granted to users/roles using the GRANT statement and are removed using the REVOKEstatement. The possible privileges in an Oracle database are:

Privilege AuthorizationSelect Read the information from a table or view

Update Modify the contents of the table or view

Insert Add new rows of data into a table or view

Delete Delete one or more rows from a table or view

Execute Execute or access a function or procedure

Alter Modify an objects parameters

Read Read files in a directory

Reference Create a constraint that refers to a table

Index Create an index on a table

These are called object privileges, and are granted to users or roles on database objects such as tables,views, procedures, functions, triggers, synonyms, indices, etc.

The second type of privilege is system privileges. These allow you to connect to the database, affect

database objects, and to create user objects such as tables, views, indexes and stored procedures.

The syntax for granting privileges is:

SQL>grant to

To see what privileges a user is granted you must also see what privileges are granted to the roles that heis assigned. Object and system privileges are stored in the DBA_TAB_PRIVS and theDBA_SYS_PRIVS views. For RAKESH, check the object privileges that have been granted:

SQL>Select GRANTEE, OWNER, TABLE_NAME, GRANTOR, PRIVILEGE, GRANTABLE

from DBA_TAB_PRIVS where GRANTEE=RAKESH

You must also ensure that RAKESH has been granted only the appropriate privileges, according to hisfunctionality requirements.



Here, the GRANTOR and the OWNER can be two different users. This is possible because of theGRANTABLE field. This field is also known as the WITH GRANT OPTION. This option allows the


22/31


grantee to further grant these privileges to users that he wants to. This is a dangerous option and must beused sparingly.

To check all object privileges that have been assigned with the WITH GRANT OPTION:

SQL>Select * from DBA_TAB_PRIVS where GRANTABLE=YES

Finally, system privileges are stored in the view DBA_SYS_PRIVS. Some system privileges areCREATE SESSION (to allow the user to connect to the oracle database), CREATE TABLE, CREATEVIEW, etc. To check what actions RAKESH can do as far as creating and manipulating the databaseobjects is concerned:

SQL>Select GRANTEE, PRIVILEGE, ADMIN_OPTION from DBA_SYS_PRIVS whereGRANTEE=RAKESH

Once again, you must ensure that RAKESH has the most restrictive set of system privileges. The otherthing to note is the field ADMIN_OPTION. This is somewhat similar to the field GRANTABLE in theobject privileges view DBA_TAB_PRIVS. This field, also known as, WITH ADMIN OPTION,allows the GRANTEE to grant these system privileges to other users or roles. This is similar to theWITH GRANT OPTION for object privileges and is very critical. To check for all privileges that havebeen assigned using the WITH ADMIN OPTION:

SQL>Select * from DBA_SYS_PRIVS where ADMIN_OPTION=YES

To summarize, what we need to do is this:1. Pick the user (or we can do this for all users), say RAKESH2. Find out all the roles assigned to him:

SELECT * FROM DBA_ROLE_PRIVS where GRANTEE=RAKESH3. Find out the object privileges granted to RAKESH and also to the roles that have been assigned

to RAKESH:SELECT * from DBA_TAB_PRIVS where GRANTEE=RAKESH

4. Find out all system privileges granted to RAKESH and his roles:SELECT * from DBA_SYS_PRIVS where GRANTEE=RAKESH

One role that this must specially be done for is PUBLIC. The PUBLIC role is like the Everyone groupin Windows. It cannot be removed, and every database user is automatically assigned the PUBLIC role.On a default database, the PUBLIC role has a really extensive list of permissions. It is highlyrecommended to complete REVOKE all privileges and roles that have been granted to PUBLIC. Anyprivilege that stays with PUBLIC is to be viewed as a critical security risk. In a default setup the output

of this command can be quite voluminous:

SQL>Select * from DBA_TAB_PRIVS where GRANTEE=PUBLICAndSQL>Select * from DBA_SYS_PRIVS where GRANTEE=PUBLICAndSQL>Select * from DBA_ROLES_PRIVS where GRANTEE=PUBLIC




23/31


Alternatively, you can query privileges based on the object name. For instance, the SYS.LINK$ tablecontains plain-text passwords for database links (see section later), and the SYS.AUD$ table containsthe auditing trail, in case auditing has been turned on and the audit destination is DB. Both these tablesmust be protected from lower-privileges accounts. You can view the privileges on these tables with thequery:

SQL>Select * from DBA_TAB_PRIVS where TABLE_NAME in (SYS.LINK$,SYS.AUD$)

It is preferable that privileges be granted to roles rather than to users. The advantages of this have beenmentioned at the start of this section. To check for those privileges that have been granted directly tousers:

SQL>Select * from DBA_TAB_PRIVS where GRANTEE in (Select * fromDBA_USERS)AndSQL>Select * from DBA_SYS_PRIVS where GRANTEE in (Select * fromDBA_USERS)

Additionally, you also want to ascertain all object privileges that have been granted with the WITHGRANT OPTION:

SQL>Select * from DBA_TAB_PRIVS where GRANTABLE=YES

And all system privileges that have been granted with the WITH ADMIN OPTION:

SQL>Select * from DBA_SYS_PRIVS where ADMIN_OPTION=YES

There is a certain subset of system privileges, which are granted using the keyword ANY. For instance,a user can be granted the CREATE TABLE privilege, which allows him to create tables within his ownschema, but he can also be granted the CREATE ANY TABLE privilege, which allows him to createtables in other users schemas as well. This is once again a dangerous set of privileges and must begranted with extreme caution. To check who has these privileges:

SQL>Select * from DBA_SYS_PRIVS where PRIVILEGE LIKE %ANY%

You also want to be very sure of why any users have been granted the DBA role:

SQL>Select * from DBA_ROLE_PRIVS where GRANTED_ROLE=DBA

The absolute minimum number of people must be granted this maximum privileges role. Anyextraneous additions to this role imply serious security flaws in the setup.

Next you must check for those users that are connected to the database at this point of time, with DBAprivileges:




24/31


SQL> Select username, SID, Status, Schema#, Server fromSYS.V_$SESSION where username in (Select username from DBA_ROLE_PRIVSwhere GRANTED_ROLE in ('SYS','DBA'))

The V_$SESSION view contains information about the current sessions, and we query it for those users

who are assigned to the SYS or the DBA roles. This again, must be a minimum number and you mustcheck that there are no multiple logins by two or more users using the same DBA-level account. Thisresults in a complete loss of accountability. All users must have their own accounts with appropriaterestricted privileges.

You must also keep a check on all tables that are present in the SYS or SYSTEM tablespaces. Asmentioned earlier, these are privileges tablespaces and no user must be allowed to create his own tableshere. The best method is to run the following query on a default installation and store it as a baseline forfuture comparisons, any new tables popping up in the output must be investigated:

SQL>Select * from DBA_TABS where TABLESPACE_NAME in (SYS, SYSTEM)

Default Roles and Roles with PasswordEach user can be assigned any number of roles. Of these, one or more roles are the users default roles.When a user connects to an Oracle database, he is automatically granted the privileges that have beenassigned to his default roles. In order to assume another role, the user must execute the SET ROLEquery. In such a case, if the Role is password-protected, then he will have to supply the password beforebeing allowed to assume that role. To check for what roles have been assigned as default roles to a givenuser:SQL>Select * from DBA_ROLE_PRIVS where GRANTEE=RAKESH andDEFAULT_ROLE=YES

To check those roles that are password protected, (and all roles that have been granted critical privilegesmust be so):SQL>Select * from DBA_ROLES where PASSWORD_REQUIRED=YES

Finally, let us recap the important views:DBA_SYS_PRIVS: List of system privileges assigned to users and rolesDBA_TAB_PRIVS: List of object privileges assigned to users and rolesDBA_ROLE_PRIVS: List of roles assigned to a user or a roleDBA_ROLES: List of roles in the database



This is by far, the most important section as far as Oracle security is concerned. All the remainingmeasures can crumble if users and roles are not assigned privileges appropriately. Another common

occurrence you will find during audits, is that the application, or the GUI, or the front-end is quiterestricted. But you must audit whether those same restrictions get reflected on the database as well. It isusually, preferred to have access control be defined at the database, rather than within the applicationcode. Because, sooner or later, even the most inexperienced user will discover tools such as SQL*PLUSand realize that he has more privileges if he connects directly to the Oracle database and executes SQLqueries than he does through the application installed on his PC. Keeping this in mind, you are urged toread through the section again.


25/31


Oracle Auditing

For Oracles built-in auditing functionality, you must not only determine the rationale behind the turningon of auditing, but also the level of auditing and its impact on system resources. Oracle auditing getsturned on as soon as you set the AUDIT_TRAIL parameter in the init.ora file. If this value is set

to DB, then all entries go to SYS.AUD$ table, if it is set to OS, then they go to the$ORACLE_HOME/rdbms/audit directory. This location will be altered if the AUDIT_FILE_DESTparameter is set to a different path.

In Oracle, we can audit the following:Statement Auditing: Audits on the type of SQL statement used, such as any SQL statement on a table.Privilege Auditing: Audits use of a particular system privilege, such as CREATE TABLEObject:Audits specific statements on specific objects such as ALTER PROFILE on the DEFAULTprofile.

You can set these auditing options and specify the following conditions:

WHENEVER SUCCESSFUL/WHENEVER NOT SUCCESSFULBY SESSION/BY ACCESS

The main problem with auditing is either too much information or too less information.

All audit entries go into the SYS.AUD$ table which must be secured with the tightest set ofpermissions. It must also be recycled by exporting it to another table, and truncating it, as it has apredefined size limit.

To view the current auditing options:Statement Auditing

SQL>Select * From DBA_STMT_AUDIT_OPTS

Privilege AuditingSQL>Select * from DBA_PRIV_AUDIT_OPTS

Object AuditingSQL>Select * from DBA_OBJ_AUDIT_PRIVS

Ensure that the audit parameters are according to the rationale and requirement of the organizationsaudit policy.

The SYS.AUD$ table is bulky and difficult to analyze; therefore you must rely on the numerous viewscreated on this table. These views are of the type: DBA_AUDIT_




26/31


Irrespective of the audit configuration, Oracle will always capture the following minimum fields:

User IDSession identifierTerminal identifierName of the schema object accessed

Operation performed or attemptedCompletion code of operationDate and timeSystem privileges used




27/31


Miscellaneous Security Aspects

SQL*Plus Security

You can restrict users from executing certain commands or even connecting to a database usingSQL*Plus by using a table called the PRODUCT_USER_PROFILE. This table is not created by default,

and must be done so by running a script called pupbld.sql. This is very essential for certain criticalPL/SQL commands like host. This command allows the user to spawn an operating system prompt andexecute OS commands. However, the command prompt is of the system on which he executed theSQL*Plus utility. If executing it remotely, he will get the command prompt of his local operatingsystem. This is a mitigating factor, but there are other critical PL/SQL commands that you would notwant all users to execute. This is done through the table PRODUCT_USER_PROFILE.

SQL>Select PRODUCT, USERID, ATTRIBUTE, CHAR_VALUE fromPRODUCT_USER_PROFILE.

Here PRODUCT is either SQL, PL/SQL, or SQL*Plus. USERID is the name of the user you want to

restrict access for. ATTRIBUTE is the command you want to restrict. And CHAR_VALUE isDISABLED in case we are making an entry for SQL, PL/SQL or SQL*Plus, or if its an entry for a role,then CHAR_VALUE is the role name.

Database Links

Database links are Oracle mechanisms for one database to connect to another database and for all this tobe transparent to the user. For instance, if one Oracle database, say ORA1, has a Link to a seconddatabase called ORA2, then a user can query tables of ORA2 just as if they were tables on ORA1.Information about the databases that our target database links to is stored in the table DBA_DB_LINK:

SQL>Select * from DBA_DB_LINK$

If a specific account is used to connect to the second database, the password for this account gets storedin the SYS.LINK$ table in clear text. Therefore, if database links are being used, the permission on thistable must be extremely restrictive. To view, who has what permission on SYS.LINK$:

SQL>Select * from DBA_TAB_PRIVS where TABLENAME=SYS.LINK$

Also, only select users must be granted the Select Any Table system privileges, because they will beable to see the clear text passwords in the SYS.LINK$ table.

To ensure that passwords are sent in encrypted format in all server to server communications, you mustset the dblink_encrypt_login parameter to TRUE in the init.ora file for all instances.

Recommend to the select query on DBA_DB_LINK$ at regular intervals to audit what database linksexist, who created them, and when they were created.




28/31


Oracle Network Security

From Oracle 8i onwards network security is implemented using Oracle Advanced Security. This ensuresencryption of all network traffic between client and server. This is of vital importance where thedatabase has to be accessed by users outside the network. This could lead to spoofing (an attacker

impersonates a genuine connection, either from the client or the server end), sniffing (an attacker sniffsthe data off the network and gathers vital information), or integrity attacks (attacker modifies the data asit passes over the network, either converting it into something malicious or unintelligible).

You can see the parameters that have been set for OAS through the Net8 configuration assistant:Network Administration | Net8 Assistant on Windows, and $ORACLE_HOME/bin/netasst on Unix.

If OAS has been installed, then under the Local Node, click on Profile, and then on Oracle AdvancedSecurity from the drop-down list on the right. There will be five tabs:

Authentication check which one is chosen: Kerberos, RADIUS, NTS, SecurID, CyberSafe, or Identix.

Integrity MD5 or SHA1 and ensure Checksum value is set to Required or Requested (see below).

Encryption Again Encryption Type must be Required or Requested (see below).

SSL SSL if configured must have a valid CA certificate. Further discussion on SSL on Oracle isbeyond the scope of this document.

Other Params provides a way to define the file locations and other authentication method-specificinformation.

For Encryption and Integrity tabs we have the following options:Required: Either use the security option or do not connect at allRequested: Use the option only if the other end supports itAccepted: Use the option only if the other side requests itRejected: Do not use the security option at all.

Physical Security and Backups and Emergency Recovery

We have put these two sections together because they are generic and only a few points are specific toOracle. Most of the checks that are recommended in any audit standard will be applicable here.

For Physical Security check:

The room is secured using locks or keypads, and who has the key codes or the keys to enter theroom.It is temperature controlled and is there adequate protection from natural hazards such as fire,water, and Acts of God.What is the normal position of the door, when authorized staff are present inside, and when noneare present



If there is adequate protection from power surges and a good UPS in place


29/31


Are there clearly defined rules for who is allowed physical access to the room other than theauthorized staff, and if so under what circumstances and in what manner.Is there an inventory of all equipment and is a register maintained to record all hardware inflowsand outflows.

Backup and Emergency Recovery:

For any database, reliable and efficient backups can be a lifesaver. More so than for any otheraudit, it is for a database audit that you must really concentrate on the backup strategy of theorganization.First and foremost ensure that there exists a formalized backup strategy and that theresponsibility for backups is clearly marked out to a specific set of people.When the backups are made, is this information recorded in a backup register noting down thedate, time, personnel, and name of tape.Where are the backup tapes storedHow many copies of the backup tapes are maintained. For instance, one copy of the daily backuptape might be stored onsite, whereas a week old backup might be available offsite. Or some

other strategy might be implemented.Where are the offsite backup tapes stored. Ensure it is a fireproof and physically securedlocation.Most important is to test recovery from the backup tapes. There is nothing worse than animmaculate backup plan, which has never been tested, and fails to help at crunch time.Check also what is backed up. In most locations, data is backed up daily, where as configurationfiles are backed up on a fortnightly or a monthly basis. It is extremely important to backupconfiguration files for both the database and the operating system to ensure faster recovery.Is there a documented disaster recovery plan? Audit it thoroughly, and see how well it has beenimplemented.Depending upon the criticality of the system, you may recommend a hot backup site, which canbe brought up in very less time.At the least, there should be hardware spares for all critical components of the server.The Disaster Recovery Plan must be fully test-run and evaluated




30/31


References:

The one good source for all Oracle security information is the official website:http://otn.oracle.com/deploy/security/content.htmlHere you will find not only the latest security topicswith Oracle, but also extensive documentation on security measures available with each database

version.

There is a book by the Oracle Press, Oracle Security Handbook, by Theriault and Newman, which ismore from the DBAs point of view, but contains some excellent material even for auditors. You can findit on Amazon.

Another good site for Oracle security is the home page of Oracle security expert Pete Finniganhttp://www.petefinnigan.com. It contains excellent resources and links to whitepapers and tools onsecurity for Oracle.



Of course, all updates and changes made to this document will be sent to you immediately.
http://otn.oracle.com/deploy/security/content.htmlhttp://www.petefinnigan.com/http://www.petefinnigan.com/http://otn.oracle.com/deploy/security/content.html


31/31



NII is an IT Security Company involved in the development of indigenous host-based security auditing

tools under the AuditPro brand name. These tools are uniquely different from the usual VulnerabilityScanners. There are AuditPro tools for Windows, Unix, Oracle, MS SQL Server and Sybase. Thesetools check your systems for misconfigurations, weak passwords, privileges, access control, and othervulnerabilities. The reports produced by these tools are comprehensive, detailed and accurate, withoutany false positives. More information on AuditPro tools is available athttp://www.nii.co.in/products.html

NII is also a provider of IT Security Services such as Security Auditing, Software Testing, EthicalHacking, Security Training, and Security Implementation. More information is available athttp://www.nii.co.in/services.html

We are also, probably the only company in the country to be involved in Security Research. This isevidenced by the fact that we have the most advisories in India, detailing vulnerabilities we havediscovered in software from companies such as Microsoft, Oracle, Symantec, Gupta Worldwide,Cypherix, etc. These advisories are available at http://www.nii.co.in/research/advisories.htmlWe alsodevelop free tools for the security community such as EnforcePass and forceSQL for SQL Serverpassword security. These are available at http://www.nii.co.in/research/tools.htmlOther security research documents such as this one are available athttp://www.nii.co.in/research/handbook.html

You can contact us at [email protected] call us at 91-22-22001530/22006019
http://www.nii.co.in/products.htmlhttp://www.nii.co.in/services.htmlhttp://www.nii.co.in/research/advisories.htmlhttp://www.nii.co.in/research/tools.htmlhttp://www.nii.co.in/research/handbook.htmlmailto:[email protected]:[email protected]://www.nii.co.in/research/handbook.htmlhttp://www.nii.co.in/research/tools.htmlhttp://www.nii.co.in/research/advisories.htmlhttp://www.nii.co.in/services.htmlhttp://www.nii.co.in/products.html

Documents

Oracle Security and Auditing