Oracle E-Business Suite Denial of Service Attacks and Locking the APPS Password

My wake-up call one day last week came from an acquaintance. Somebody at his company typed the APPS password in wrong too many times and locked the APPS database account. This caused the Oracle E-Business Suite to lock-out ALL users from accessing the application and concurrent processing to stop. Since it was production, excitement ensued. By the time he had called me, the APPS password had been reset and the Oracle E-Business Suite was back up. The question was what do to prevent it from occurring in the future?

In order to provide a more secure default configuration, Oracle began setting the default profile FAILED_LOGIN_ATTEMPTS in 11g to 10 (failed logins). This profile is assigned to all database accounts by default, including the APPS account in Oracle E-Business Suite environments. Thus, most are vulnerable to a very simple to execute denial of service attack. The risk of allowing the APPS password to be easily locked is essentially risking an intentional or unintentional denial-of-service attack.

As part of Integrigy’s standard security assessment checks for the Oracle E-Business Suite, we recommend that a custom database password profile be created for key service accounts such as APPS. In this custom profile for service accounts, FAILED_LOGIN_ATTEMPTS should be set high value or UNLIMITED for key application service accounts. To mitigate any risk of brute force attempts against these accounts, failed login attempts should be monitored and a PASSWORD_VERIFY_FUNCTION set to require password complexity and a minimum password length.

The default password profile should not be used. Integrigy recommends a set of custom profiles be developed and segment accounts into interactive service accounts, other service accounts, and named users.

What might be a few other denial-of-service attacks for the E-Business Suite? This not inclusive, but a few of them are:

If the profile option ‘Upload File Size Limit’ is not set, a user could potentially upload an inordinately large document or a number of large attached documents sufficient to consume storage to the point that the database would become inoperable. The file size limit should be set and be set appropriately small for your business processes.
If you are Internet facing, such as running iRecruitment, there is another profile option, ‘IRC: Document Upload Count Limit’ which limits the total number of documents that can be uploaded per user.
As well, if you are Internet facing, such as running iRecruitment or any other module that allows self-registration and creation of accounts, you should consider implementing CAPTCHA – these are the hard-to-read random words you need to retype that are used by web sites to prove you are a human. Someone with nefarious intent could create numerous bogus E-Business Suite user accounts (most likely through automation) sufficient to interfere with the normal operation of the Suite. See the reference below for the Oracle Support note for how to implement CAPTCHA.
Not directly related to the E-Business Suite, but those accounts used in OBIEE data source connections (defined in the RPD) should certainly be treated the same as what is suggested above for the APPS account. Locking the accounts used for data connections will render OBIEE unusable for users.

If you have questions, please contact us at info@integrigy.com

References

Preventing a Hacker from Creating Bogus Users and Uploading the Maximum Files in iRecruitment (Doc ID 402662.1) https://support.oracle.com/rs?type=doc&id=402662.1
What is CAPTCHA http://en.wikipedia.org/wiki/CAPTCHA