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 unauthorized
access 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 in
the 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 special
characters. 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 new
password 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 ALTER
USER <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 Permissions
Detailed 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 or
viewed. 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