How I encrypted your EBS application password

Nowadays, Oracle is widely known as one of the leaders in the production of enterprise software. Among its products, there is Oracle EBS (E-Business Suite), which is a huge ERP system used in various industries, such as Automobile, Aerospace and Defense, Engineering and Construction, Health Sciences, Hospitality, Professional Services, etc.

It was reported that Oracle EBS has multiple vulnerabilities but they are not the only issue its security since there are architecture problems. All of them can come in handy for hackers.

In this article, we will run through Oracle EBS security mechanisms implemented for the storage of EBS application users’ passwords and understand how hackers can take advantage of its drawbacks.

Oracle EBS application user passwords

Oracle EBS application users’ passwords can be stored in Non-Reversible Hashed Mode and in Encrypted Mode.

Non-Reversible Hashed Mode means that passwords are transformed with the use of some hash functions into special hash values which are difficult to be reconstructed into origin values. Nonetheless, it is easy to check passwords integrity.

Oracle EBS handles such hash algorithms as SHA-1, SHA-256, SHA-368, SHA-512. In case an attacker gains an access to the Oracle EBS database and exfiltrates passwords data, there is the only way to get initial passwords value by using brute force attack. Such attack consumes more time and computer resources depending on which hash algorithm had been used.

Oracle EBS password encryption

It is worth noting that hash mode is not enabled by default. There are dozens of articles describing how to migrate to a Password Hashing mode. If you want to learn more on this topic, you can find the information in Oracle EBS Security Guide “Switch to Hashed Passwords, page 10-11”.

In our security audit practice, we meet Encrypted mode implemented on customers’ EBS systems with particular frequency. And this mode is insecure, and we will show you why.

In this mode, EBS stores application user passwords in FND_USER table.


ENCRYPTED_FOUNDATION_PASSWORD column stores APPS user password encrypted with the use of User name and User password) combination.

ENCRYPTED_USER_PASSWORD column stores user password encrypted with APPS user password.

So, if anyone has found APPS user password, he can decrypt all EBS application users’ passwords, but how can it be performed?

One way is to create a special procedure in the database.

                                   value IN VARCHAR2) 
  RETURN VARCHAR2 AS LANGUAGE JAVA name ',java.lang.String) return java.lang.String';

This procedure allows to decrypt any EBS application user’s password in the EBS system using its internal functionality of EBS Java classes (we will talk about it in detail further). It takes two arguments: the first is Key value, and the second is cipher text. The only thing you need is to get the Key value. It turned out that at this step it can be performed with the use of EBS default functionality.

We can get GUEST user password with the following sql query:

SELECT fnd_web_sec.get_guest_username_pwd FROM   dual;

So, with the GUEST user password value and ENCRYPTED_FOUNDATION_PASSWORD for GUEST (as you remember this column stores encrypted APPS user password) using ‘decrypt’ procedure, we will decrypt APPS user password with the following sql statement:

SELECT (SELECT Decrypt((SELECT fnd_web_sec.get_guest_username_pwd 
                        FROM   dual), fu.encrypted_foundation_password) 
        FROM   dual) AS apps_password 
FROM   fnd_user fu 
WHERE  fu.user_name LIKE (SELECT 
Substr(fnd_web_sec.get_guest_username_pwd, 1, Instr( 
        fnd_web_sec.get_guest_username_pwd, '/') - 1) 
FROM   dual);

Now, providing possession of APPS user password, we can decrypt all EBS application users’ passwords.

So, as you can see, this mechanism has severe security flaw. This information is enough for hackers to perform a cyberattack. However, we were interested in more details on encryption algorithm. Still, how users’ passwords encryption is implemented? The answer is provided by EBS ‘’ java class. This class implements ‘AolSecurityPrivate.decrypt’ function, which parses entering cipher text for the first two characters. If they equal to ‘ZH’ or ‘ZG’, then
‘newDecrypt’ function is executed, or another ‘oldDecrypt’ function is produced. Let’s dive deeper into Java code and see how exactly EBS encryption works.

New decryption of Oracle EBS passwords

For better understanding, we will operate with an example Key and cipher text values. Below, you can see an example of cipher text value for ‘newDecrypt’ function.

The Key value will be the default APPS user password value the same in all examples – which is APPS (suddenly!)

The ‘newDecrypt’ function cuts ‘ZH’ or ‘ZG’ from the encrypted value and transforms the remainder into bytes.

Now we have an array of bytes.
40 BA C4 09 88 B2 47 F1 7B 1C 64 00 74 17 B5 AD 0F E6 1E 67 1B 03 44 76 57 49 CA C2 73 3D 4A 91 2F B9 9D C4 3C 6B ED BC 46 0E 2D DA 98 63 6E 19 74

Further, a number of salt bytes is counted and extracted from the encrypted value end. Let’s call a new encrypted value – freshBytes. The number of salt bytes depends on the encrypted value length and is counted internally. In our example, as of the encrypted value length equals to 100, salt bytes number is equal to 1. So, freshBytes value representation is:
40 BA C4 09 88 B2 47 F1 7B 1C 64 00 74 17 B5 AD 0F E6 1E 67 1B 03 44 76 57 49 CA C2 73 3D 4A 91 2F B9 9D C4 3C 6B ED BC 46 0E 2D DA 98 63 6E 19 74

Then Key value is taken in hexadecimal form
‘APPS’ -> 41 50 50 53

and added to salt bytes. The new Key value representation is:

74 41 50 50 53

After that, the Key value is driven through SHA-1 function, but it is done in an unusual way. The final Key hash value is a concatenation of SHA-1 {Key+’1’} 20 bytes and SHA-1 {Key+’2’} first 12 bytes.

Then, freshBytes are transformed with 3DES CBC algorithm with the use of the Key hash.
In the end ‘newDecrypt’ function grabs a decrypted value from the transformed freshBytes, and it is maintained from a third byte, till ’00’ byte. In an example below, you can see the decrypted freshBytes value and
13 EC 45 52 50 53 63 61 6E 54 65 61 6D 00 1E DD 49 C1 7B 2D 9D 5F 67 D0 A6 10 13 86 3D 5 FB E1 15 AF 97 9E

decrypted value is 45 52 50 53 63 61 6E 54 65 61 6D which is ERPScanTeam in ASCII representation.

Old Decryption of Oracle EBS passwords

In terms of ‘oldDecrypt’ function, it turns out to be unusual and diverse from ‘newDecrypt’ function. Let’s look inside its implementation.

First, ‘oldDecrypt’ takes the Key value and transforms it through SHA-1-like algorithm. This algorithm is called SHA-1-like as it is based on SHA-1 default implementation, but with some different implementation steps.


The first diverse step can be seen in the data chunk creation. SHA-1 algorithm takes the Key byte value, sequently appends ‘\x80’ and K ‘\x00’-s, finally it adds the length of the message and puts everything to the pre-processing function. The main difference between SHA-1 and SHA-1-like here is K value. SHA-1 counts it this way:

And SHA-1-like is:

What does it mean? For example, if Key length is equal to 55, then SHA-1-like algorithm creates a 128 length data chunk instead of an usual 64 length data chunk from SHA-1 algorithm. You can see the scheme on the picture below.

The second diverse step is in the data chunk pre-procession. SHA-1 algorithm transforms every data chunk into sixteen 4-byte big-endian words. SHA-1-like algorithm transforms every data chunk into sixteen 4-byte little-endian words except the final one, which is transformed into fourteen 4-byte little-endian words plus two 4-byte big-endian words.

The next important diverse step lies in data permutation inside hash rounds, which are absolutely different for both algorithms. There how it looks in SHA-1 algorithm:

In case of SHA-1-like algorithm, it looks like that:

Finally, the last diverse step for SHA-1-like algorithm is the result values initialization. SHA-1 algorithm sums new hash values with the previous ones and returns the result. SHA-1-like algorithm just permutes new hash values and returns them.

Let’s look at the example Key and cipher text values. This is an example of cipher text value for ‘oldDecrypt’ function.
C4 E9 B5 91 09 8E A0

SHA-1-like algorithm transforms the Key (which is still ’APPS’) into the following array of Key hash values.
0xcfee3a71, 0x7f7a2c54, 0x95e23be4, 0x25788ef9, 0x9a78bf48

Later on, ‘oldDecrypt’ takes the final Key hash values produced by SHA-1-like algorithm, separates each value by 1 byte and xor-s extracted bytes. Thus, it creates reduced Key hash values.

In our example, reduced Key hash values are:
0x6a, 0x7d, 0xa8, 0x2a, 0x15

And reduced Key hash value is always 5 byte length, that is not enough for brute-force attacks.

In the end, ‘oldDecrypt’ decrypts cipher data using reduced Key hash values like a key within a RC4 algorithm.

And cipher text is transformed into ‘APPSKEY’ which is our decrypted value.

Oracle EBS password decryption scheme

You can see the full scheme of EBS Application users’ passwords decryption below.

So, Oracle decided to implement its own version of hash function as it probably worked like ‘security through obscurity’. Due to the fact that SHA-1 algorithm was used as a base for its own SHA-1-like algorithm, Oracle own hash function inherited all limitations and security breaches.


So why we did this deep analysis of decryption function implementation? Sometimes it is vital to have a chance to decrypt Oracle EBS Application users’ passwords with the minimal Database interaction (for example, testing something in production systems or disability of proper database interaction). For these cases, we implemented Oracle EBS decryption algorithms in python. Meanwhile, it was an interesting theme for research. You can find a python implementation of Oracle EBS decryption algorithms in our GitHub repository.

The post How I encrypted your EBS application password appeared first on ERPScan.