Oracle EBS密码安全的攻与防

<<攻>>

Oracle EBS密码安全机制做的并不完善，还有漏洞，已经看到很多的帖子在讲如何破解密码.

最牛的是“Oracle 11i / 12 APPS Password Cracker”这一篇文章（需FQ）,破解密码都不用费力的....

http://symplik.blogspot.com/2010/07/oracle-11i-12-apps-password-cracker.html

“How to find out Oracle Apps password??”

http://www.appsdbatraining.com/2011/05/05/how-to-find-out-oracle-apps-password/

“Oracle E-Business Suite Vulnerability: Users Passwords Decrypted”

http://awads.net/wp/2006/12/12/oracle-e-business-suite-vulnerability-users-passwords-decrypted/

“Integrigy Oracle Apps Password Issue”

http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf

还有我之前转载的一篇

http://blog.csdn.net/pan_tian/article/details/7528932

<<防>>

现在获取密码的原理都是基于你已经知道某一个用户的密码再来推导apps账户或者其他账户密码，所以对DBA来说，一旦安装完EBS之后，需要立即更改所有预先安装的fnd_user中所有user的password，尤其是别漏掉guest账户的密码。几个默认账户列表见：http://blog.csdn.net/pan_tian/article/details/7432623

Integrigy_Oracle_Apps_Password_Issue 中讲到的保护系统密码安全的几点注意事项：

PROTECTING ORACLE APPLICATIONS PASSWORDS

The Oracle Applications encrypted passwords must be protected in order to prevent decryption. The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with the DBA_USERS view.

 

1. VERIFY APPLSYSPUB DOES NOT HAVE ACCESS TO FND_USER_VIEW [CRITICAL]

Verify APPLSYSPUB and PUBLIC do not have SELECT privileges on the view APPS.FND_USER_VIEW. This is especially an issue with instances that were upgraded from 11.5.6 and prior. FND_USER_VIEW shows all application accounts and the ENCRYPTED_FOUNDATION_PASSWORD. Prior to 11.5.7, APPLSYSPUB may have been granted SELECT privileges on this view to support ADI. This view is not required by APPLSYSPUB, except for old, desupported versions of ADI.

2. CHANGE GUEST ACCOUNT PASSWORD

The password for the GUEST account should be changed from the default of ORACLE or GUEST. 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".

3. CHANGE PASSWORDS FOR ALL SEEDED ORACLE APPLICATIONS ACCOUNTS

Change the passwords for all Oracle Applications 11i seeded accounts (SYSADMIN, WIZARD, APPSMGR, etc.) even though these accounts may be already be 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. 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.

4. CHANGE PASSWORDS FOR ALL DATABASE ACCOUNTS [CRITICAL]

Change the passwords for every database account including all 250+ Oracle Applications schemas. Even though a module is not being used, the database account password must be changed. Use the FNDCPASS utility to change all the database passwords on a periodic basis. In 11.5.10 RUP3, FNDCPASS includes a new option (ALLORACLE) to change all the schema passwords in a single FNDCPASS call (see Metalink Note ID 398942.1).

 

 

5. CREATE ALL NEW APPLICATION ACCOUNTS WITH STRONG PASSWORDS

Create all new user accounts with unique and strong passwords. In 11.5.10, User Management (UMX) can be used to securely create new users with strong passwords.

6. SET SERVER SECURITY TO SECURE

Oracle Applications Server Security when set to SECURE requires servers connecting to the Oracle Applications database to provide a secure server ID. This is only used when actually logging into Oracle Applications through a SQL*Net and is not related to database authentication. By setting Server Security to SECURE may prevent an attacker from obtaining the encrypted foundation password under certain circumstances. See the section "AdminAppServer Utility" of the Oracle Applications 11.5.10 System Administrator's Guide – Configuration manual for detailed instructions on setting up Server Security.

7. IMPLEMENT MANAGED SQL*NET ACCESS

11.5.10 introduced a new feature called Managed SQL*Net Access. Managed SQL*Net Access limits the hosts that can connect to the database server using SQL*Net by implementing Oracle TNS Listener valid node checking. Valid node checking is a list of IP addresses that are permitted to connect to the database server. Unfortunately, it is very difficult to implement this feature since a large number of hosts often require access to the database server. See Metalink Note ID 291897.1 for more information on configuring this feature.

 

8. LIMIT ACCESS TO FND_USER AND FND_ORACLE_USERID

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 ad-hoc query use. These accounts tend to be created with SELECT ANY TABLE system privilege, which allows access to FND_USER. Instead, all non-DBA accounts should be created with a limited set of database privileges for only those tables absolutely required for the business function.

Unfortunately, the FND_USER table is fundamentally required by many reporting and ad-hoc queries, thus it is difficult to directly exclude this table from such database accounts. Also, over 500 standard Oracle Applications views are dependent on FND_USER. A careful review of ad-hoc query privileges should be performed to determine the exact business requirements and privileges required.

Query accounts should not normally require access to FND_ORACLE_USERID, therefore, this table should be easy to exclude from such database accounts. 

All user and database passwords should be immediately changed in all cloned databases to prevent decryption of the production passwords.

                   

                   9. CHANGE ALL APPLICATION ACCOUNT PASSWORDS DURING CLONING [CRITICAL]

As part of the cloning process, change all application account passwords to a random string using a PL/SQL script that calls FND_USER_PKG.CHANGEPASSWORD. An operational issue then exists in that users of the cloned instance will need to obtain the new password. One solution is to use the "Reset Password Functionality" in 11.5.10 and UMX.H. Users needing access will then have to reset their password after each clone of a development or test database. See Metalink Note ID 399766.1 for more information on the UMX Reset Password Functionality.

 

10.CHANGE THE GUEST ACCOUNT PASSWORD DURING CLONING

The GUEST password requires additional steps in order to change including updating the password in the AutoConfig XML file. As part of the cloning process, follow the steps in Metalink Note ID 396537.1 to change the GUEST password.

11.CHANGE ALL DATABASE ACCOUNT PASSWORDS DURING CLONING [CRITICAL]

All database account password should be changed as part of the cloning process (with the exception of APPLSYSPUB). Even though a module is not being used, the database account password must be changed. In 11.5.10 RUP3, FNDCPASS includes a new option (ALLORACLE) to change all the schema passwords in a single FNDCPASS call (see Metalink Note ID 398942.1). Also, all standard database account passwords (CTXSYS, DBSNMP, etc.) should also be changed as part of each clone. 

 

 

转载请注明出处：http://blog.csdn.net/pan_tian/article/details/7692088

======EOF======

只要保管好apps  system 和guest 的口令而且无法远程登录db服务器,就应该无法破解.