We have updated our free Oracle Database Listener Security Check tool that analyzes security of the Oracle Database TNS Listener to identify potential security issues.

Two new features have been added from upcoming changes to our AppSentry security auditing tool -

• Checks all the entries in a tnsnames.ora file for four security configuration issues in the database listener
  

• Generate TNS entries and JDBC connect strings (6 different ways) for enumerated SIDs

The AppSentry Listener Security Check Tool is available for download at -

http://www.integrigy.com/security-resources/whitepapers/lsnrcheck-tool/view

Two weeks after the initial release of the October 2006 Critical Patch Update (CPU) Advisory, Oracle added information about the Oracle Database 9.2.0.8 being vulnerable and about a patch being available in the future.  The 9.2.0.8 patch release date keeps getting pushed back and is now scheduled for December 22 on Unix/Linux and December 15 for Windows (5 days ago).

The Oracle E-Business Suite Note for the CPU (Metalink Note ID 391564.1) has not been updated to show the required 9.2.0.8 patch.  If you have upgraded to 9.2.0.8, then you need to apply the CPU security patch when it becomes available as it corrects a number of high-risk vulnerabilities.

We have updated our free Oracle Database Listener Security Check tool that analyzes security of the Oracle Database TNS Listener to identify potential security issues.  The tool performs four basic checks for the Database Listener in a simple and user friendly way - (1) is a listener password set, (2) is ADMIN_RESTRICTIONS set, (3) is logging enabled, and (4) is LOCAL_OS_AUTHENTICATION enabled for Oracle 10g.  It is a single executable that can be run from any Windows XP/2000 PC, requires no Oracle client install, and can be run from a USB key.

The following enhancements are in the new version -

• Fully compatible with Oracle 10g (10.1 and 10.2)
• New Oracle Applications 11i check for database and FNDFS listeners
• New enumeration of all instances for a listener
• Saves history of servers and ports for easy access

The AppSentry Listener Security Check Tool is available for download at -

http://www.integrigy.com/security-resources/whitepapers/lsnrcheck-tool/view

The inherent weakness of the Oracle Applications 11i user password algorithm is a topic that every so often gets some attention.  It bubbles up and then is largely forgotten by most.  However, the issue doesn't go away and is very much alive today even in 11.5.10.2.  See the references at the end of this post for a little history of the topic.  This password weakness (along with the APPLSYSPUB database account) is really a hold-over from client/server and is an inherent design flaw in the current architecture of Oracle Applications.

Many people are missing two critical issues with the Oracle Applications 11i user password encryption -

• The encryption is basically two way - (1) if you know any username/password you get the APPS password or (2) if you know the APPS password, you get any user's password.  I can see about potential fraud if you know another user's password, but the APPS password is the key to the kingdom.  Most likely someone shouldn't have the necessary privileges in production to obtain this information, but often the user's passwords are in cloned instances like development.
  
• Since the decryption routine is a Java class, it is actually easy to create a Java application that calls the decrypt method.  Simply put in a username, password, and encrypted password, out comes the APPS password.  Put in a username, APPS password, and encrypted password, out comes the user's password.  No need to even have access to a database to run the decrypt.
  

Improving the Oracle Applications 11i password algorithm is a complex change and I don't expect Oracle to fix it in the foreseeable future.  Hopefully in Release 12, a strong hash algorithm will be implemented and the APPLSYSPUB database account will no longer exist.

In the meantime, here are a few recommendations to at least improve the security of the user passwords.  The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with DBA_USERS.

• Verify APPLSYSPUB does not have SELECT privileges on APPS.FND_USER_VIEW.  This is especially an issue with instances that were upgraded from 11.5.6 and prior.  This view is not required by APPLSYSPUB, except for old versions of ADI.
  
• Change the passwords for all Oracle Applications 11i seeded accounts (SYSADMIN, GUEST, WIZARD, APPSMGR, etc.) even though these accounts may be already disabled.  At the same time, make sure all accounts except for SYSADMIN and GUEST are disabled (note a few accounts may be required by a specific module).  See Metalink Note ID 189367.1 for the most up to date list of seeded user accounts.  Be sure to change the GUEST password and follow the solution in Metalink Note ID 396537.1 for details on changing the password and check that the password was also changed in the System Profile Option "Guest User Password".  For years clients have questioned why we recommend always changing the seeded account passwords even though the accounts may be disabled -- this is the reason why.
• Create all new user accounts with strong and unique passwords.
• Limit access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts including any query-only accounts.  Often an APPSREAD or similar database account is created for support purposes or end-user query use.  These accounts tend to be created with SELECT ANY TABLE system privilege, which allows them access to FND_USER.

Cloning presents a security issue with Oracle Applications since sensitive information like passwords are in the cloned instance.  This applies to both FND_USER as well as DBA_USERS since weak database passwords can be easily cracked (see the tool orabf).  The challenge with cloning is that there may be multiple cloned instances with different uses and varying levels of access.  Often the development instance is wide-open to all developers and the APPS password is distributed.  Support instances may be frequently cloned, contain sensitive information, and be accessed by end-users.  Broadly changing passwords all passwords in DBA_USERS and FND_USER usually is difficult to accomplish, but with the security weaknesses of both the application and database passwords changing all the passwords is strongly recommended for every cloned instance.

References about the Oracle Applications 11i Password Weakness

May 2002 - Martin Schlafer and Michael Ackerman of Answerthink were the first ones to really document this issue in their OAUG paper "Oracle Unbreakable? Part I: Ten Hot Security Spots in Oracle Applications 11i" presented at the Spring 2002 OAUG Conference in Toronto.  The paper is available for download from the OAUG Conference Paper Archive (OAUG membership required).  They highlighted both the password weakness, as well as, the fact that anyone could download all Java JAR files from any Oracle Applications implementation through the web server.  The ability to download the JAR file isn't really much of an issue since it is fairly easy to obtain and every Oracle Applications 11i implementation in the world uses the same algorithm.  Although, Oracle has limited the downloading from the web server of the core JAR files to just those used by JInitiator.

November 2005 - http://www.erp100.com/viewthread.php?action=printable&tid=1592 (Simplified Chinese -> English Translation)  (Sidenote: I would like to know what in Chinese ends up as translating to this - "We know tuberculosis Oracle database provides a common account")  This post has sample PL/SQL procedures to crack a password.

May 2006 - http://521102yz.itpub.net/post/5095/84876 (Simplified Chinese -> English Translation) - Report of the above information

December 2006 - http://johanlouwers.blogspot.com/2006/12/oracle-applications-passwords.html

With the advent of legislative mandates like Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act (HIPAA), the security and auditing of Oracle Databases has become much more of a priority for most organizations. A common solution has been to implement an Oracle-aware Intrusion Detection System (IDS) or auditing product to address these legislative mandates and increased auditor scrutiny. Integrigy has released a new whitepaper paper that looks at a number of techniques that may be used to evade such Oracle intrusion detection and auditing solutions, especially signature-based solutions.  It is actually very easy to evade a signature-based Oracle IDS solution.

Organizations that have implemented network-based IDS and auditing solutions for their Oracle databases should carefully review the actual effectiveness of these solutions.

Whitepaper: Evading Network-Based Oracle Database Intrusion Detection Systems

In a follow-up to my previous post regarding mystery patches for 9.2.0.8 in the October 2006 Critical Patch Update, the CPU advisory was updated to include information about 9.2.0.8.  However, the patches for 9.2.0.8 are still not available and have an anticipated release date of December 15, 2006 (note: the initial release date was November 15, 2006).

The initial release of the October 2006 CPU did not include any references to 9.2.0.8 as being vulnerable or requiring patches.  Oracle did not update the advisory until October 31st.  So if you evaluated your internal risk and identified databases requiring patches prior to October 31st, you will need to reevaluate all your 9.2.0.8 databases.

The following vulnerabilities were updated to include 9.2.0.8 - DB09, DB13, DB14, DB15, and DB17.  DB09 is the View bug, which is serious.  DB13 and DB17 are SQL injection bugs in standard Oracle Spatial packages or triggers.  DB14 and DB15 are SQL injection bugs in XDB packages.  All of these SQL injection bugs allow a database account with limited privileges the ability to execute SQL fragments as a privileged database account like MDSYS.