Oracle E-business suite passwords

I have already reported about a security flaw in the way Oracle is working with the passwords stored for Oracle E-business suite. The passwords are stored in an encrypted form and not as a hash value. This means that if an entered password can be compared with a encrypted password there is somehow a function that allows you to decrypt a password.

After some research I found the decryption technique to be in APPLSYS. FND_WEB_SEC as an internal function used to decrypt the encrypted passwords. TO make the function available outside the package a single line of code needs to be added to FND_WEB_SEC.

After understanding the complete way the package was working it came to my attention that you are able to decrypt all user passwords in this way. Due to the possible security risks for companies and the possible difficulties this can cause for SOX (Sarbanes-Oxley) compliant companies I informed CERT and the Dutch CERT. CERT.org responded in a quick and good way. I received a ticket number and have been updated about all communication between CERT and Oracle. The Dutch version of CERT however informed me that they would contact Oracle and requested me to remove the information from my weblog. This was the only communication I ever received from the Dutch CERT.

CERT.org have been keeping me up-to-date and finally responded that they would NOT send out a warning as there is a rather high level of access needed to the system to make the change to the FND_WEB_SEC package. I can agree on this as we are talking from a production system point of view, however the exploit becomes more scary when you think about a development environment cloned from a production environment.

In this case a lot of developers will have the access rights to do so and will be able to lookup passwords and use this in the production environment. This is to say if the passwords are not reset. As most companies are unaware of this exploit, resetting the passwords is not a step taken in the cloning process of a production environment to a development environment.

Even do, I understand the standpoint of CERT.org however I do not understand the standpoint of Oracle who identified this as a very minor glitch in there security module. Personally I think this is a lot more than a minor glitch. Personally I think the complete security model is setup wrongly from the beginning by storing an encrypted password instead of a password hash value.

If some people like to gain some more insight in the way the security problem is working I have posted some code on my website terminalcult.org.

I have a uploaded a query which enables you to decrypt a password. And I created a Oracle function which will do the same, the function has some more details in it to start understanding the way the system works.