Database Security Issues

The database should meet the criteria indicated in the security policy are highlighted below. Following listed violations are against the security policy. Violations are listed in order of severity; those exposing the highest risk.

Default Accounts and Passwords

Detailed Description: Oracle databases have several well-known default username/password combinations. These combinations include the following: SCOTT/TIGER, DBSNMP/DBSNMP, SYSTEM/MANAGER, SYS/CHANGE_ON_INSTALL, TRACESVR/TRACE, CTXSYS/CTXSYS, MDSYS/MDSYS, DEMO/DEMO, CTXDEMO/CTXDEMO, APPLSYS/FND, PO8/PO8, AMES/NAMES, SYSADM/SYSADM, ORDPLUGINS/ORDPLUGINS, OUTLN/OUTLN, ADAMS/WOOD, BLAKE/PAPER, JONES/STEEL, CLARK/CLOTH, AURORA$ORB$UNAUTHENTICATED/INVALID, and APPS/APPS. These default combinations may provide unauthorizedaccess to the server.

Fix: Change the default password to a value that is difficult to guess. Change the password for an account by executing the following command: ALTER USER <username> IDENTIFIED BY <new password>

Note: If you use Oracle Intelligent Agent and change the password for the DBSNMP account, you must also place the new password in the snmp_rw.ora file.

Weak Account Passwords

Detailed Description: Oracle versions prior to 8.0 do not provide a mechanism to enforce password strength. In Oracle 8.0 and higher, a password verification script can be used to include some validation of password strength. Accounts configured with easily-guessed passwords are targets for password guessing. This check ensures that account passwords are not found inthe specified dictionary or are not one of the following common passwords: - password same as the account name - password same as the account name reversed - password same as the server name - password is the account name appended with a number between 1 and 100

Fix: Require accounts to use passwords with a minimum of 6 characters and a combination of letters, numbers, and specialcharacters. If you are using Oracle 8 or higher, verify that you have a strong password verification script in place.

Change passwords by executing the command: ALTER USER <account> IDENTIFIED BY <password>

Note: If you use Oracle Intelligent Agent and change the password for the DBSNMP account, you must also place the newpassword in the snmp_rw.ora file.

Failed Login Attempts

Detailed Description: Profiles have been found that exceed the specified resource usage on the Failed Login Attempts parameter. The FAILED_LOGIN_ATTEMPTS value serves as

a limit to the number of failed login attempts allowed before an account is locked. Setting this value limits the ability of unauthorized users to guess passwords and alerts the DBA when password guessing has occurred (accounts display as locked). Once an account is locked it can not be logged on to for a specified number of days or until the DBA unlocks the account. FAILED_LOGIN_ATTEMPTS can be set to a specific number of attempts; to UNLIMITED, meaning never lock an account; or to DEFAULT, which uses the value indicated in the DEFAULT profile. This feature is set for profiles. These profiles then must be associated with an account.

Fix: Modify the FAILED_LOGIN_ATTEMPTS profile parameter by executing the following command: ALTER PROFILE <profile name> LIMIT FAILED_LOGIN_ATTEMPTS xxx

Modify the users associated with a profile by executing the following command: ALTER USER <username> PROFILE <new profile>

Unlock a user account by executing the following command: ALTER USER <username> ACCOUNT UNLOCK

Database Link Password Encryption

Detailed Description: The Oracle configuration parameter DBLINK_ENCRYPT_LOGIN specifies whether attempts to connect to remote Oracle databases through database links should use encrypted passwords. Prior to Oracle 7.2, passwords were not encrypted before being sent over the network. In order to connect to older servers, Oracle included this parameter to retry failed connections using the unencrypted format. If the DBLINK_ENCRYPT_LOGIN parameter is TRUE, and the connection fails, Oracle does not reattempt the connection. If this parameter is FALSE, Oracle reattempts the connection using an unencrypted version of the password. Servers with DBLINK_ENCRYPT_LOGIN set to FALSE can be coerced into sending unencrypted passwords by computers between linked servers.

Fix: Change the parameter to ensure that the line DBLINK_ENCRYPT_LOGIN = TRUE appears in the init.ora configuration file. Restart the server for the setting to take effect. NOTE: Oracle Version 7.1 or earlier will not run if you make this change.

Expired Passwords Found in Oracle 8

Detailed Description: Oracle 8 introduced the ability to limit password lifetime through the use of profiles. This check uses the built-in password aging functionality of Oracle for version 8 servers and higher. The password lifetime will be taken from the profile associated with the accounts. Requiring password changes on a regular basis counters undetected password compromises. By determining and setting an appropriate password lifetime, the security risk associated with password authentication can be reduced. The longer a password is in use, the more likely the password will become exposed, whether through brute force, eavesdropping, or other avenues.

Fix: Remind users to change their passwords on a regular basis. Change a password by executing the command ALTERUSER <username> IDENTIFIED BY <password>.

Database Link Password Unencrypted

Detailed Description: Database link passwords have been found stored in plaintext. A database link is a mechanism used to provide a method of transparently accessing one server from another. When creating a link, a user name and password of an account on the remote

server can be specified. If this is done, all queries using the link will have the privilege of the indicated account on the remote server. By omitting an account and password when creating a database link, the account and password of the user connecting through the link is used. Indicating the username and password of an account to use for all connections through a link can lead to passwords being exposed. Database link passwords are stored unencrypted in the database. Users with SELECT privilege to the SYS.LINK$ table can view the passwords in plaintext. Setting up links to authenticate as the current user prevents unencrypted passwords from being exposed, helps prevent linked servers from being compromised, and provides increased accountability.

Fix: Drop the database link and create a link without specifying an account and passwords. To drop a database link,execute the command DROP DATABASE LINK <link name>. To re-create a link without hard coding the password,execute the command CREATE DATABASE LINK <link name> USING <connection string>.

Password Life Time

Detailed Description: The PASSWORD_LIFE_TIME value serves as a limit to the number of days after which a password expires. Setting this value ensures users are changing their passwords. PASSWORD_LIFE_TIME can be set to a specific number of days; to UNLIMITED, meaning never require an account to change the password; or to DEFAULT, which uses the value indicated in the DEFAULT profile. Leaving this value on UNLIMITED allows users to use the same passwords indefinitely. This feature is set for profiles. These profiles then must be associated with an account.

Fix: Modify the PASSWORD_LIFE_TIME profile parameter by executing the following command: ALTER PROFILE <profile name> LIMIT PASSWORD_LIFE_TIME xx

Modify the users associated with a profile value by executing the following command: ALTER USER <username> PROFILE <new profile>

Use of RESOURCE Default Role

Detailed Description: Accounts have been found with the RESOURCE role. The built-in role RESOURCE is not recommended for application users. This role includes privileges that are not required by most accounts functioning within the bounds of an application and conveys no indication of the purpose of the privilege by its name.

Fix: Remove any accounts in the role and delete the role. Create a more appropriate role with only the required permissions.

PUBLIC Object Permissions

Detailed Description: Permissions on objects may be granted to users and roles and to the user group PUBLIC. Because every database user is a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the database access to that object. In a secure environment, granting object permissions to PUBLIC should be restricted to those objects that all users are allowed to access.

Fix: To revoke permissions from PUBLIC, execute the following statement: REVOKE <privilege> ON <object> FROM PUBLIC.

UTL_FILE Permissions

Detailed Description: The UTL_FILE package allows Oracle accounts to read and write files on the host operating system. Access to this package should be restricted.

Fix: Use the following command to revoke permissions from the UTL_FILE package: REVOKE <privilege> ON SYS.UTL_FILE FROM <account/role>.

Password Reuse Time

Detailed Description: 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 to DEFAULT, which uses the value indicated in the DEFAULT profile. Setting this value to UNLIMITED allows passwords to be reused immediately. This feature is set for profiles. These profiles then must be associated with an account. PASSWORD_REUSE_TIME is mutually exclusive with PASSWORD_REUSE_MAX. If PASSWORD_REUSE_TIME is set to a value for a given profile, PASSWORD_REUSE_MAX must be set to UNLIMITED for the same profile. This check verifies that all profiles have a minimum level of security set.

Fix: Modify the PASSWORD_REUSE_TIME profile parameter by executing the following command: ALTER PROFILE <profile name> LIMIT PASSWORD_REUSE_TIME xx

Modify the users associated with a profile value by executing the following command: ALTER USER <username> PROFILE <new profile>

Run-Time Listener Administration

Detailed Description: Oracle provides the ADMIN_RESTRICTIONS_LISTENER listener parameter, which when set to ON, prohibits run-time modifications to listener parameters via the set command. There is a vulnerability in the listener program that allows you to dynamically change the location of output files when logging or tracing is enabled. If the location is set to an existing file, that file is overwritten. If run-time administration of the listener is not prohibited, a user could set the location of the output files to overwrite any file in which the Oracle user has access. If ADMIN_RESTRICTIONS_LISTENER is set to ON, listener parameters can only be modified by shutting down the listener and modifying the parameter file. By default, ADMIN_RESTRICTIONS_LISTENER is set to OFF. In a secure environment this parameter should be set to ON and a strong listener password should be established.

Fix: For Oracle 8.1.7 and later: Add the line ADMIN_RESTRICTIONS_LISTENER=ON to the listener.ora file, then reload the listener parameter file by either restart the listener or run lsnrctl reload command. For 8.1.6 and lower version, make sure that proper patch is applied, then set the ADMIN_RESTRICTIONS_LISTENER parameter and reload the parameter file.

With Grant Option

Detailed Description: A user having object privileges with the GRANT OPTION can grant privileges to other users as if he were the owner of the object. Use of the WITH GRANT OPTION may not be appropriate in certain database environments and use of this option should be limited to security administrators.

Fix: To remove the WITH GRANT OPTION, you must revoke the privilege and regrant it. The following statement recreates the permission without the WITH GRANT OPTION: REVOKE DELETE ON <object name> FROM <account> GRANT DELETE ON <object name> FROM <account>

Audit Table Tablespace

Detailed Description: The audit trail table (SYS.AUD$) should be placed in its own tablespace to avoid fragmentation of the system tablespace and to avoid running out of space in the system tablespace.

Fix: Recreate the SYS.AUD$ table in its own tablespace. In order to do this, you may wish to implement the following steps as the SYS user: 1. Create the new tablespace for the audit table. 2. Create a table in the new tablespace with a temporary name based on the AUD$ table. Use the following command: CREATE TABLE temp_audit <storage clause> as SELECT * FROM SYS.AUD$. 3. Drop the SYS.AUD$ table. 4. Rename the temporary table to AUD$ using the following command: RENAME temp_audit to AUD$ 5. Recreate the views based on SYS.AUD$ and DBA_AUDIT_TRAIL by running the appropriate sections from the cataudit.sql install script located in the $ORACLE_HOME/rdbms/admin directory.

Privileges Granted With Admin

Detailed Description: Revoking system privileges having the WITH ADMIN OPTION does not revoke those privileges from other accounts that have been given the privilege by the account being revoked. This makes revoking system privileges that were granted WITH ADMIN OPTION difficult as the privilege can be given to an account and then granted back after it is revoked.

Fix: To revoke the WITH ADMIN OPTION, you must revoke and re-grant the privilege without the WITH ADMIN OPTION.

View Missing With Check Option

Detailed Description: Views containing a WHERE clause without the WITH CHECK option allow users to insert or update rows that cannot be seen by the view because they do not meet the selection criteria. Depending on the sensitivity of your data, this may be undesirable behavior. Adding the WITH CHECK option to the WHERE clause will force the WHERE clause to be evaluated upon insert or update, and will not allow a user to insert or update rows that would be otherwise be hidden by the view.

Fix: Drop the view and recreate it using the WITH CHECK option at the end of the WHERE clause.

Account Permissions

Detailed Description: Granting object permissions to individual accounts is error prone and repetitive. Instead, consider assigning object permissions to roles and then granting the roles to accounts. Note that INDEX and REFERENCES privileges cannot be granted to roles.

Fix: Revoke permissions using the following command: REVOKE <privilege> ON <object> FROM <account>.

To revoke permissions using Oracle Security Manager: 1. Select the account that will have a privilege revoked. 2. Select Object Privileges Granted. 3. Right-click on the privilege you wish to remove. 4. Select Revoke.

Data Dictionary Accessibility

Detailed Description: Oracle 8 provides the parameter O7_DICTIONARY_ACCESSIBILITY to prevent accounts with the privilege SELECT ANY TABLE from selecting the data dictionary tables. Setting this parameter to FALSE helps restrict access to sensitive data in the data dictionary such as the encrypted passwords.

Fix: Set the O7_DICTIONARY_ACCESSIBILITY value in the init.ora configuration file to FALSE.

Use of CONNECT Default Role

Detailed Description: The CONNECT role includes the system privileges CREATE TABLE, CREATE DATABASE LINK, and several others, which give users more privileges than required to connect to a database. Use of this role is strongly discouraged. Instead of using the CONNECT role to grant access to Oracle, consider creating a user defined role containing only the CREATE SESSION privilege and then granting this role to accounts.

Fix: Remove any accounts in the role and delete the role. Create a more appropriate role with only the required permissions.

Default Tablespace

Detailed Description: Use of the SYS or SYSTEM tablespace as the default table space is highly discouraged. New objects created by the account will be placed on this tablespace. The SYS or SYSTEM table space contains the data dictionary and should not be used for other tables.

Fix: Change the default table space for an account by executing the following command: ALTER USER <username>DEFAULT TABLESPACE <new tablespace>.

Role PermissionsDetailed Description: Oracle does not provide a method of granting row-level

permissions for SELECT, DELETE, or UPDATE statements. It is good security practice to limit the granting of these permissions. You should instead provide access to these statements through functions, procedures, or views that provide validation that only the appropriate rows are being modified orviewed. To ensure maximum security, the only permissions allowed should be execute permissions on procedures and functions or select from views.

Fix: To revoke permissions from a role execute the following statement: REVOKE <privilege> ON <object> FROM <role>

Regards,

Umesh Pawar Global Interdict Polaris Software Lab Limited. +91-22-28290019 #1894