We have updated our Oracle Applications 11i Security Quick Reference to include new information and for 11.5.10 CU2.  The Quick Reference is a simple two-pager meant to highlight some key security areas and settings.

Oracle Applications 11i Security Quick Reference

Usually, I am not in the position to defend Oracle on the number of vulnerabilities fixed, but the recent Symantec Internet Security Threat Report inflated the vulnerability count for Oracle by comparing apples and oranges.   This version of the Threat Report contains a comparison of the number of vulnerabilities found in five leading relational databases (Oracle, IBM DB2, Microsoft SQL Server, MySQL, and PostgreSQL).  Oracle looks really bad with 168 vulnerabilities published during the second half of 2006 as compared to 5 for IBM DB2 and 0 for Microsoft SQL Server during the same period.  I am not here to defend Oracle as the true number is way more than 5, however, it is far less than 168 when only comparing database vulnerabilities to database vulnerabilities.

Our internal count puts the Oracle Database-only published vulnerability count for the second half of 2006 at 49.  In the most limited installation of the Oracle RDBMS without any optional products, the number of vulnerabilities would be about 20.  The Symantec report does address the feature issue by saying -

"Oracle’s database implementations offer a greater feature set and a broader range of database products than many of the other database vendors. The more features an application has, the more code that is available in which to find vulnerabilities, and the more code that must be audited for vulnerabilities. This can equate to a higher proportion of vulnerabilities, depending on the nature and complexity of the features."

What I find interesting is that Symantec appears to have been able to filter IBM WebSphere and other IBM products from the IBM DB2 count, but did not do the same for Oracle (based on a quick search of NVD).

Cryptographic hash functions seem to be an ideal method for protecting and securely storing credit card numbers in ecommerce and payment applications. A hash function generates a secure, one-way digital fingerprint that is irreversible and meets frequent business requirements for searching and matching of card numbers. However, due to the predictability of credit card numbers and common business requirements in processing credit cards, ecommerce and payment applications may implement such hashing of card numbers in an unsafe manner that allows an attacker to obtain a large percentage of card numbers by brute forcing compromised hashes in a matter of hours.

To provide more information on this issue, Integrigy has released a whitepaper that is an analysis of actual application practices for storing of credit card number hashes and a review of brute force attack methods against such hashes.  The impetus for this paper was identification of this issue during multiple application security assessments.

The bottom-line is that storing of credit card numbers by simply hashing only the card number is unacceptable and can be easily compromised by brute force methods. An attacker who is able to compromise the application or database can obtain many card numbers in a trivial amount of time –

• If only the hashed card number is available, it is actually practical to obtain all 14 and 15 digital card number hashes in less than thirteen days.
• If only the hashed card number is stored, an attacker can potentially obtain 30-70% of all card numbers within a matter of hours by intelligently focusing on the most popular card brands and issuing banks.

• If the Prefix 6 + Last 4 digits are known, all card numbers can be obtained in less than 2 hours.

Application developers can not rely on simple hashing methods and must build-in protections against such brute force attacks on compromised card numbers.

Whitepaper: Hashing Credit Card Numbers: Unsafe Application Practices