AuditPro v4.0.0

Description:
This check finds all fixed user database links that are stored with a cleartext password. A database link is a pointer within an Oracle database to a remote database. For fixed user database links, the information on how to connect to the database is stored in the system table SYS.LINK$. Within this table are four sensitive columns:
-USERID
-PASSWORD
-AUTHUSR
-AUTHPWD
These columns contain the usernames and passwords used to connect to the remote database. In order to connect to the remote database, the username and passwords in this table must be stored in plain text.

Because of the security concerns with storing passwords in clear text, it is recommended that you use a connected user and current user database links. These types of links do not include credentials in the definition of the link. Using these forms of database links are preferred.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	Database Link Passwords in Cleartext	No violations found

Description:
Check for default passwords that have not been changed. 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,
NAMES/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.

CVE Reference No.: CVE-NO-MATCH

Severity	USERNAME	DEFAULT	PASSWORD
	SYSTEM	DEFAULT	D4DF7931AB130E37
	DBSNMP	DEFAULT	E066D214D5421CCC
	SCOTT	DEFAULT	F894844C34402B67
	OUTLN	DEFAULT	4A3BA55E08595C81
	ORDSYS	DEFAULT	7EFA02EC7EA6B86F
	OLAPSVR	DEFAULT	AF52CFD036E8F425
	OLAPSYS	DEFAULT	3FB8EF9DB538647C
	ORDPLUGINS	DEFAULT	88A2B2C183431F00
	MDSYS	DEFAULT	72979A94BAD2AF80
	OLAPDBA	DEFAULT	1AF71599EDACFB00
	RMAN	DEFAULT	E7B5D92911C831E1

Solution:
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.

Description:
Verify that default role passwords have been changed. Many roles contain powerful privileges for which you may want to provide additional security. For this reason, Oracle allows roles to be assigned to passwords, requiring users to submit the password before the role can be enabled. Oracle is installed with a set of well-known roles and passwords. If the default password for these roles have not been changed, an attacker can gain elevated privileges.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	Default role password	No violations found

Description:
If SAP is being used on Oracle, it has the default password of SAPR3 after installation. This can be used by an attacker to authenticate himself to the Oracle database. The SAP account is likely to have much higher privileges than the other accounts, and is therefore more critical.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	Default SAP account	No violations found

Description:
Check for evidence of password attacks. A password attack is a method of attempting to compromise a system by connecting using words from a dictionary for the password. People typically pick passwords that are easy to remember, such as names, birthdays, or words found in a dictionary. To prevent and detect this type of attack, set the Password Lockout feature for Oracle 8 and periodically review the audit logs for evidence of attacks. This check requires that auditing of failed connections be enabled and that auditing data be written to the SYS.AUD$ table. Oracle 7 does not have a Failed Login Limit function. Check the audit log for evidence of successful attack.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	Excessive Failed Logins	No violations found

Description:
Check that password ages do not exceed a reasonable password lifetime. 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.

CVE Reference No.: CVE-NO-MATCH

Severity	USERNAME	ACCOUNT_STATUS
	OUTLN	EXPIRED & LOCKED
	WKSYS	EXPIRED & LOCKED
	QS_CBADM	EXPIRED & LOCKED
	QS_OS	EXPIRED & LOCKED
	QS_ES	EXPIRED & LOCKED
	SH	EXPIRED & LOCKED
	PM	EXPIRED & LOCKED
	OE	EXPIRED & LOCKED
	HR	EXPIRED & LOCKED
	QS_WS	EXPIRED & LOCKED
	QS	EXPIRED & LOCKED
	QS_ADM	EXPIRED & LOCKED
	QS_CS	EXPIRED & LOCKED
	QS_CB	EXPIRED & LOCKED
	RMAN	EXPIRED & LOCKED
	OLAPDBA	EXPIRED & LOCKED
	CTXSYS	EXPIRED & LOCKED
	OLAPSVR	EXPIRED & LOCKED
	OLAPSYS	EXPIRED & LOCKED
	MDSYS	EXPIRED & LOCKED
	ORDPLUGINS	EXPIRED & LOCKED
	ORDSYS	EXPIRED & LOCKED

Solution:
Remind users to change their passwords on a regular basis. Change a password by executing the command ALTER USER IDENTIFIED BY .

Description:
The FAILED_LOGIN_ATTEMPTS parameter defines the number of successive failed login attempts that can be performed before an account's status is changed to locked. This protects against attackers attempting to guess a password for an account. If this parameter is set low enough, the effectiveness of password attacks on the database can be eliminated.
The password management features of Oracle are enabled through the use of profiles. A profile is a set of limits on database resources and of parameters for the password management features. You can create multiple profiles in a database with different parameter settings. You then must assign the profiles to the users that the profile is most appropriate for. For each failed login attempt, the unsuccessful login attempt count is incremented until it reach the value configured for the parameter. After a user successfully logs into an account, that user's unsuccessful login attempt count is reset to 0.

By setting this value to a reasonable number, such as 10, you can limit the ability of an attacker to launch a password attack against the account. Even if a user chooses a weak password that is found in a dictionary, it is unlikely that an attacker will be able to guess the password in the first 10 attempts.

Setting this parameter to UNLIMITED is the worst possible setting. By setting the parameter to UNLIMITED, an attacker can attempt an unlimited amount of guesses of the password for all accounts granted the specified profile. Setting the parameter to a value such as 10 is appropriate. Setting the value too low may result in valid users locking their accounts when mistyping the password.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	FAILED_LOGIN_ATTEMPTS	UNLIMITED

Solution:
The permissible number of failed login attempts can be specified when creating the profile using the CREATE PROFILE statement or later by executing the ALTER PROFILE statement. Below is the syntax for changing the value.

ALTER PROFILE [profile name] LIMIT
FAILED_LOGIN_ATTEMPTS 10

Once a profile is configured, the profile must be assigned to users. Below is the syntax for this command:
ALTER USER [username] PROFILE [profile name]

Once an account has been locked, it can be unlocked by an account with the ALTER ANY USER system privilege using the command below:
ALTER USER [username] ACCOUNT UNLOCK

Description:
Check for accounts that have been locked. Oracle provides a facility to lock accounts when multiple failed logins occur against that account. This facility prevents passwords from being brute-forced by an attacker. If an account is found to be locked, it may indicate that the account has been attacked.

CVE Reference No.: CVE-NO-MATCH

Severity	USERNAME	ACCOUNT_STATUS
	OUTLN	EXPIRED & LOCKED
	WKSYS	EXPIRED & LOCKED
	QS_CBADM	EXPIRED & LOCKED
	QS_OS	EXPIRED & LOCKED
	QS_ES	EXPIRED & LOCKED
	SH	EXPIRED & LOCKED
	PM	EXPIRED & LOCKED
	OE	EXPIRED & LOCKED
	HR	EXPIRED & LOCKED
	QS_WS	EXPIRED & LOCKED
	QS	EXPIRED & LOCKED
	QS_ADM	EXPIRED & LOCKED
	QS_CS	EXPIRED & LOCKED
	QS_CB	EXPIRED & LOCKED
	RMAN	EXPIRED & LOCKED
	OLAPDBA	EXPIRED & LOCKED
	CTXSYS	EXPIRED & LOCKED
	OLAPSVR	EXPIRED & LOCKED
	OLAPSYS	EXPIRED & LOCKED
	MDSYS	EXPIRED & LOCKED
	ORDPLUGINS	EXPIRED & LOCKED
	ORDSYS	EXPIRED & LOCKED

Solution:
You can unlock a password using the following command:

ALTER USER [username] ACCOUNT UNLOCK;

If you discover a password is being locked and cannot determine the cause, you should configure auditing on the account and review the audit logs to determine the source of the locking.

Description:
Check that the OS_AUTHENT_PREFIX setting is in compliance with the policy. Oracle can be configured to allow operating system accounts to be authenticated to Oracle without having to specify a password. When set up this way, OS accounts are mapped to Oracle accounts of the same name prefixed with the string specified by the OS_AUTHENT_PREFIX configuration parameter. By default, this value is OPS$. This means that the OS user account jdoe will be authenticated to Oracle as the Oracle account OPS$jdoe, if that account exists.

If the Oracle account being accessed has a valid password, then users may also login into Oracle using a username/password combination. If you set the prefix to anything other than OPS$, users can log into Oracle without specifying a password or by entering a valid username/password, but not both. Using the default prefix OPS$ allows remote users to attempt to guess passwords of accounts that have the OPS$ prefix but are not created using IDENTIFIED EXTERNALLY. By using a different prefix, accounts configured with the prefix must be IDENTIFIED EXTERNALLY if they are to use operating system authentication. Using any prefix other than OPS$ significantly reduces any chance of remote password guessing and makes guessing account names with the prefix harder.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	OS Authentication Prefix	No violations found

Description:
Check that users have changed their passwords within the designated policy setting. Passwords need to be changed frequently, as there are so many ways to have your password stolen, sniffed or viewed. It is therefore important for database administrators to be mindful of how frequently passwords are being changed, and which users have not been changing passwords regularly.

CVE Reference No.: CVE-NO-MATCH

Severity	NAME	ROUND(SYSDATE-PTIME)
	SYS	2285
	SYSTEM	2285
	DBSNMP	2285
	AURORA$JIS$UTILITY$	2285
	OSE$HTTP$ADMIN	2285
	AURORA$ORB$UNAUTHENTICATED	2285
	SCOTT	2285

Solution:
Inform each user that the password needs to be updated. This can be changed by running the command:

ALTER USER [username] IDENTIFIED BY [password]

Then verify that passwords have been changed by running the check again.

Description:
Check that all profiles have a Password Grace Time within the limits of the policy. The PASSWORD_GRACE_TIME value serves as a limit to the number of days during which a password must be changed following the first successful login after password expiration. Setting this value ensures users are changing their passwords. PASSWORD_GRACE_TIME can be set to a number of days; UNLIMITED, meaning never require an account to change the password; or to DEFAULT, which then uses the value indicated in the DEFAULT profile. Leaving this value as UNLIMITED allows users to ignore the Change Password prompt indefinitely. This feature is set for profiles. These profiles then must be associated with an account. This check verifies that all profiles have a minimum level of security.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	PASSWORD_GRACE_TIME	UNLIMITED

Solution:
Modify the PASSWORD_GRACE_TIME profile parameter by executing the following command:
ALTER PROFILE [profile name] LIMIT PASSWORD_GRACE_TIME xx

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

Description:
Check that Oracle 8 profiles have not exceeded the allowed limit for Password Life Time. 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 number of days; UNLIMITED, meaning never require an account to change the password; or to DEFAULT, which then 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. This check verifies that all profiles have a minimum level of security set.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	PASSWORD_LIFE_TIME	UNLIMITED

Solution:
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]

Description:
Check that Oracle 8 profiles have not exceeded the allowed limit for PASSWORD_LOCK_TIME. The PASSWORD_LOCK_TIME value specifies the number of days to lock an account after the designated number of failed login attempts is reached. PASSWORD_LOCK_TIME can be set to a number of days; UNLIMITED; or to DEFAULT which then uses the value indicated in the DEFAULT profile. Setting this value on UNLIMITED requires that the database administrator unlock the account. This feature is set for profiles. These profiles then must be associated with an account. This check verifies that all profiles have a minimum level of security set.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	PASSWORD_LOCK_TIME	UNLIMITED

Solution:
Modify the PASSWORD_LOCK_TIME profile parameter by executing the following command:
ALTER PROFILE [profile name] LIMIT PASSWORD_LOCK_TIME xx

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

Description:
Check that Oracle 8 profiles have not exceeded the allowed limit for PASSWORD_REUSE_MAX. The PASSWORD_REUSE_MAX value specifies the number of password changes before a password can be reused. PASSWORD_REUSE_MAX can be set to a number of reuses; UNLIMITED; or to DEFAULT, which then 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_MAX is mutually exclusive with PASSWORD_REUSE_TIME. If PASSWORD_REUSE_MAX is set to a value for a given profile, PASSWORD_REUSE_TIME must be set to UNLIMITED for the same profile. This check verifies that all profiles have a minimum level of security set.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	PASSWORD_REUSE_MAX	UNLIMITED

Solution:
Modify the PASSWORD_REUSE_MAX profile parameter by executing the following command:
ALTER PROFILE [profile name] LIMIT PASSWORD_REUSE_MAX xx

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

Description:
Check that Oracle 8 profiles are not within the allowed limit for PASSWORD_REUSE_TIME. Oracle 8 introduces a new profile value, PASSWORD_REUSE_TIME. This value specifies the number of days before a password can be reused. PASSWORD_REUSE_TIME can be set to a number of days; UNLIMITED; or to DEFAULT, which then 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.

CVE Reference No.: CVE-NO-MATCH

Severity	PROFILE	RESOURCE_NAME	LIMIT
	DEFAULT	PASSWORD_REUSE_TIME	UNLIMITED

Solution:
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]

Description:
Check that the Password Verify Function is specified properly. The PASSWORD_VERIFY_FUNCTION value specifies a PL/SQL function to be used for password verification when users who are assigned this profile log in to a database. This function can be used to validate password strength by requiring passwords to pass a strength test written in PL/SQL. The function must be locally available for execution on the database to which this profile applies. Oracle provides a default script (utlpwdmg.sql), but you can also create your own function. The password verification function must be owned by SYS. The default setting for this profile parameter is NULL, meaning no password verification is performed.

CVE Reference No.: CVE-NO-MATCH

Severity	RESOURCE_NAME	LIMIT
	PASSWORD_VERIFY_FUNCTION	NULL

Solution:
Modify the PASSWORD_VERIFY_FUNCTION profile parameter by executing the following command:
ALTER PROFILE [profile name] LIMIT PASSWORD_VERIFY_FUNCTION [password function]

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

Description:
Check that the Oracle parameter REMOTE_LOGIN_PASSWORDFILE is in compliance with the policy. REMOTE_LOGIN_PASSWORDFILE specifies whether Oracle checks for a password file and how many databases can use the password file. Setting the parameter to NONE signifies that Oracle should ignore any password file (and only operating systems accounts in the dba group can connect INTERNAL). Setting the parameter to EXCLUSIVE signifies that the password file can be used by only one database and the password file can contain names other than SYS and INTERNAL (operating system users can still connect INTERNAL). Setting the parameter to SHARED allows more than one database to use a password file. However, the only users recognized by the password file are SYS and INTERNAL (operating system users can still connect INTERNAL). Setting the parameter to NONE, the recommended setting, prevents remote users from connecting as INTERNAL.

CVE Reference No.: CVE-NO-MATCH

Severity	NAME	VALUE	DESCRIPTION
	remote_login_passwordfile	EXCLUSIVE	password file usage parameter

Solution:
Set the REMOTE_LOGIN_PASSWORDFILE value in the init.ora configuration file.

Description:
Check for roles without passwords. Oracle roles can be configured to require password authentication to use the role. In secure environments, sensitive roles should have passwords assigned to them. Oracle roles defined without password verification allow easy access.

CVE Reference No.: CVE-NO-MATCH

Severity	ROLE	PASSWORD_REQUIRED
	CONNECT	NO
	RESOURCE	NO
	DBA	NO
	SELECT_CATALOG_ROLE	NO
	EXECUTE_CATALOG_ROLE	NO
	DELETE_CATALOG_ROLE	NO
	EXP_FULL_DATABASE	NO
	WM_ADMIN_ROLE	NO
	IMP_FULL_DATABASE	NO
	RECOVERY_CATALOG_OWNER	NO
	AQ_ADMINISTRATOR_ROLE	NO
	AQ_USER_ROLE	NO
	OEM_MONITOR	NO
	HS_ADMIN_ROLE	NO
	JAVAUSERPRIV	NO
	JAVAIDPRIV	NO
	JAVASYSPRIV	NO
	JAVADEBUGPRIV	NO
	JAVA_ADMIN	NO
	JAVA_DEPLOY	NO
	CTXAPP	NO
	WKADMIN	NO
	WKUSER	NO
	OLAP_DBA	NO

Solution:
To set passwords for a role, execute the following statement: ALTER ROLE [Role Name] IDENTIFIED BY [password].

Description:
Check that the REMOTE_OS_AUTHENT parameter is not set to TRUE. Setting this value to TRUE allows operating system authentication over a non-secure connection. Trusting remote operating systems can allow a user to impersonate another operating system user and connect to the database without having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only information a remote user needs to connect to the database is the name of any user whose account is setup to be authenticated by the operating system.

CVE Reference No.: CVE-NO-MATCH

Severity	NAME	VALUE	DESCRIPTION
	remote_os_authent	FALSE	allow non-secure remote clients to use auto-logon accounts

Solution:
Set the REMOTE_OS_AUTHENT value to FALSE in the init.ora configuration file.

Description:
Check that Oracle is not configured to enable roles based on remote operating system user group membership. Setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles. The default value of FALSE causes roles to be identified and managed by the database. If REMOTE_OS_ROLE is set to TRUE, a remote user could impersonate another operating system user over a network connection. It is a security risk to use operating system role authentication for network clients.

CVE Reference No.: CVE-NO-MATCH

Severity	NAME	VALUE	DESCRIPTION
	remote_os_roles	FALSE	allow non-secure remote clients to use os roles

Solution:
Set the REMOTE_OS_ROLES value to FALSE in the init.ora configuration file.

Description:
The DBA role on an Oracle database is the most powerful role with far-reaching privileges. All users or roles granted this privilege must be carefully monitored. You must watch out for any unauthorized additions to the DBA role, or the addition of Oracle default accounts to the DBA role. By default the SYS and SYSTEM accounts are granted the DBA role. This check determines if any users other than SYS and SYSTEM have been given the DBA role.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	GRANTED_ROLE	ADMIN_OPTION	DEFAULT_ROLE
	CTXSYS	DBA	NO	YES
	WKSYS	DBA	NO	YES

Solution:
The findings given below do not necessarily represent a vulnerability if the accounts are authorized accounts for the DBA role. But if this is not the case, such accounts must be investigated immediately and removed from the DBA role. This is done by the following command:
REVOKE DBA FROM [account]

Description:
Privileges to create, alter, or execute ANY source code objects are very powerful privileges. Because of the ease in which these privileges can be elevated to full DBA, granting these privilege should be done only to DBA accounts.
Oracle supports a wide variety of privileges which allow a user to perform actions of types of objects. Some of these privileges can be granted using the "ANY" keyword. This keyword allows the GRANTEE to perform the action on any schema. This is powerful and can be used to escalate privileges.

The following privileges can be used to create or execute code in the SYS schema.
CREATE ANY PROCEDURE
ALTER ANY PROCEDURE
EXECUTE ANY PROCEDURE
ALTER ANY TRIGGER
CREATE ANY TRIGGER

Once code is create or execute in the SYS schema, it will run under the privileges of the SYS user, effectively allowing the GRANTEE to execute any commands as the SYS user.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	ALTER ANY PROCEDURE
	IMP_FULL_DATABASE	ALTER ANY PROCEDURE
	MDSYS	ALTER ANY PROCEDURE
	WKSYS	ALTER ANY PROCEDURE
	CTXSYS	ALTER ANY TRIGGER
	IMP_FULL_DATABASE	ALTER ANY TRIGGER
	MDSYS	ALTER ANY TRIGGER
	WKSYS	ALTER ANY TRIGGER
	CTXSYS	CREATE ANY PROCEDURE
	IMP_FULL_DATABASE	CREATE ANY PROCEDURE
	MDSYS	CREATE ANY PROCEDURE
	WKSYS	CREATE ANY PROCEDURE
	CTXSYS	CREATE ANY TRIGGER
	IMP_FULL_DATABASE	CREATE ANY TRIGGER
	MDSYS	CREATE ANY TRIGGER
	WKSYS	CREATE ANY TRIGGER
	CTXSYS	EXECUTE ANY PROCEDURE
	EXP_FULL_DATABASE	EXECUTE ANY PROCEDURE
	IMP_FULL_DATABASE	EXECUTE ANY PROCEDURE
	MDSYS	EXECUTE ANY PROCEDURE
	OUTLN	EXECUTE ANY PROCEDURE
	WKSYS	EXECUTE ANY PROCEDURE

Solution:
Revoke privileges from any users that are not DBAs. Grant them specific privileges on any functions or procedures they need to execute.

To revoke the privilege from an account, run the following command:
REVOKE [PRIVILEGE] FROM [user or role]

where privilege is one of the following:
CREATE ANY PROCEDURE
ALTER ANY PROCEDURE
EXECUTE ANY PROCEDURE
ALTER ANY TRIGGER
CREATE ANY TRIGGER

Description:
Check for accounts (other than DBA, SYS, and SYSTEM) that have been granted the privileges BECOME USER or ALTER USER.
Privileges to become another user can be used maliciously. The privileges to do so allows an attacker to access data or runs commands under the privileges of another user. This results in a loss of both auditability and accountability.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	ALTER USER
	MDSYS	ALTER USER
	WKSYS	ALTER USER
	CTXSYS	BECOME USER
	IMP_FULL_DATABASE	BECOME USER
	MDSYS	BECOME USER
	WKSYS	BECOME USER

Solution:
Revoke the privileges from any users that are not DBAs. To revoke the privilege from an account or role, run the following command:

REVOKE BECOME USER FROM [user or role]
REVOKE ALTER USER FROM [user or role]

Description:
Check for accounts (other than DBA, SYS, and SYSTEM) that have been granted the privilege CREATE PUBLIC SYNONYM.

Privileges to create public synonyms can be used maliciously. The privileges to do so allows an attacker to create synonyms which override the names of other objects. The synonyms may point to other objects not intended to be accessed. Privileges to create public synonyms should be granted to database administrators only.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	CREATE PUBLIC SYNONYM
	IMP_FULL_DATABASE	CREATE PUBLIC SYNONYM
	MDSYS	CREATE PUBLIC SYNONYM
	OLAPSYS	CREATE PUBLIC SYNONYM
	ORDPLUGINS	CREATE PUBLIC SYNONYM
	ORDSYS	CREATE PUBLIC SYNONYM
	WKSYS	CREATE PUBLIC SYNONYM

Solution:
Revoke the privileges from any users that are not DBAs. To revoke the privilege from an account or role, run the following command:
REVOKE CREATE PUBLIC SYNONYM FROM [user or role]

Description:
Check for accounts (other than DBA, SYS, and SYSTEM) that have been granted the privilege GRANT ANY ROLE.
Privileges to grant any role are very powerful. Because of the ease in which these privileges can be elevated to full DBA, granting these privilege should be done only to DBA accounts.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	GRANT ANY ROLE
	MDSYS	GRANT ANY ROLE
	WKSYS	GRANT ANY ROLE

Solution:
Revoke the privileges from any users that are not DBAs. To revoke the privilege from an account or role, run the following command:
REVOKE CREATE PUBLIC SYNONYM FROM [user or role]

Description:
Check for accounts (other than DBA, SYS, and SYSTEM) that have been granted the privileges DROP PUBLIC DATABASE LINK and CREATE PUBLIC DATABASE LINK.
Privileges to replace public links can be used maliciously. The privileges to do so allows an attacker to replace an existing link with a link to a malicious database. Then when a privileged user access the database links, the credentials of the privilege user can be hijacked. Privileges to create and drop database links should be granted to database administrators only.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	CREATE PUBLIC DATABASE LINK
	IMP_FULL_DATABASE	CREATE PUBLIC DATABASE LINK
	MDSYS	CREATE PUBLIC DATABASE LINK
	WKSYS	CREATE PUBLIC DATABASE LINK
	CTXSYS	DROP PUBLIC DATABASE LINK
	IMP_FULL_DATABASE	DROP PUBLIC DATABASE LINK
	MDSYS	DROP PUBLIC DATABASE LINK
	WKSYS	DROP PUBLIC DATABASE LINK

Solution:
Revoke the privileges from any users that are not DBAs. To revoke the privilege from an account or role, run the following command:

REVOKE CREATE PUBLIC DATABASE LINK FROM [user or role]
REVOKE DROP PUBLIC DATABASE LINK FROM [user or role]

Description:
Check for accounts granted the system privilege ALTER SYSTEM
The initialization parameter "fixed_date" can be used to manipulate time or date dependent applications. Because of this class of time-based attacks, you should review the accounts granted the system privilege ALTER SYSTEM.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	ALTER SYSTEM
	MDSYS	ALTER SYSTEM
	WKSYS	ALTER SYSTEM

Solution:
For any accounts that do not require the system privilege ALTER SYSTEM, revoke the privilege using the following command:

REVOKE ALTER SYSTEM FROM [role or user]

Description:
Check for accounts (other than DBA, SYS, and SYSTEM) that have been granted the role JAVA_ADMIN.
The role JAVA_ADMIN can be used maliciously to execute and access files on the operating system level. The JAVA_ADMIN role should be granted to database administrators only.

CVE Reference No.: CVE-NO-MATCH

Severity	Parameter	Value
	Account granted the JAVA_ADMIN role	No violations found

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

CVE Reference No.: CVE-NO-MATCH

Severity	USERNAME	DEFAULT	DEFAULT_TABLESPACE
	SYS	DEFAULT	SYSTEM
	SYSTEM	DEFAULT	SYSTEM
	DBSNMP	DEFAULT	SYSTEM
	AURORA$JIS$UTILITY$	DEFAULT	SYSTEM
	SCOTT	DEFAULT	SYSTEM
	AURORA$ORB$UNAUTHENTICATED	DEFAULT	SYSTEM
	OSE$HTTP$ADMIN	DEFAULT	SYSTEM
	OUTLN	DEFAULT	SYSTEM
	OLAPSVR	DEFAULT	SYSTEM
	ORDPLUGINS	DEFAULT	SYSTEM
	OLAPDBA	DEFAULT	SYSTEM
	MDSYS	DEFAULT	SYSTEM
	ORDSYS	DEFAULT	SYSTEM

Solution:
Change the default table space for an account by executing the following command: ALTER USER [username] DEFAULT TABLESPACE [new tablespace].

Description:
Check permissions on the audit table. Permissions to this table should be restricted to only those accounts requiring access. Granting excessive permissions could lead to tampering of the audit trail data. Check that only the appropriate accounts have permissions to perform select, insert, delete, or update operations on the table where the audit data is stored (SYS.AUD$).

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	TABLE_NAME	GRANTOR	PRIVILEGE	GRANTABLE
	DELETE_CATALOG_ROLE	AUD$	SYS	DELETE	NO

Solution:
Revoke permissions from the SYS.AUD$ table for accounts that do not require access.

Description:
CREATE LIBRARY and CREATE ANY LIBRARY are powerful privileges and access to them should be tightly controlled. These privileges can be used to access the operating system. CREATE LIBRARY allows a user to load an operating system binary file and call into the functions of the binary. CREATE LIBRARY can be used by a database user to attack the operating system, so this feature should be tightly guarded.

CVE Reference No.: CVE-NO-MATCH

Severity	GRANTEE	PRIVILEGE
	CTXSYS	CREATE ANY LIBRARY
	DBA	CREATE ANY LIBRARY
	IMP_FULL_DATABASE	CREATE ANY LIBRARY
	MDSYS	CREATE ANY LIBRARY
	WKSYS	CREATE ANY LIBRARY
	CTXSYS	CREATE LIBRARY
	DBA	CREATE LIBRARY
	MDSYS	CREATE LIBRARY
	ORDPLUGINS	CREATE LIBRARY
	ORDSYS	CREATE LIBRARY
	WKSYS	CREATE LIBRARY

Solution:
Revoke permissions to create libraries from any users that do not need the privilege.

To revoke the CREATE LIBRARY system privilege, run the following command:

REVOKE CREATE LIBRARY FROM [user or role]

To revoke the CREATE ANY LIBRARY system privilege, run the following command:

REVOKE CREATE ANY LIBRARY FROM [user or role]

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

CVE Reference No.: CVE-NO-MATCH

Severity	NAME	VALUE	DESCRIPTION
	O7_DICTIONARY_ACCESSIBILITY	FALSE	Version 7 Dictionary Accessibility Support

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