Pete Finnigan's Oracle Security Weblog

There was a post a few days ago on LinkedIn by Johannes Michler about easily passing passwords to adop via a shell script when patching E-Business Suite. This script sets the password for the E-Business Suite APPS user, SYSTEM and a weblogic password by creating three environment variables that are then used to log in using the passwords in these variables.

It is a short article and part 1 of a longer series but it prompted me to write some comments on it that you can see in LinkedIn. Having written those comments I think its worth while discussing the solution to the problem that Johannes was trying to solve as its a more generic problem than just his specific case.

Over 20 years of performing security audits of Oracle databases and often where the database supports Oracle E-Business Suite I see the remnants of the solutions. I always in every audit find passwords for databases and sometimes other systems and applications on the server hosting the database. Always!

I find passwords in SQL scripts, shell scripts, text files, . (dot) scripts and files, environment variables, output files, scripts to change passwords, passwords stored in database tables, sometimes encrypted with real encryption, sometimes with pseudo encryption and sometimes in clear text and many more places.

I have always found passwords for the database that are current and often passwords for other databases. I see often that if I am reviewing the main production database and its server that DBAs use the server as a sort of personal PC and we find scripts and evidence of connections to other main databases and their servers on the server I am reviewing.

I once found all the EBS database passwords in one script on a server. The interesting thing was that these passwords were strong (15 characters, good character set...) but they were all in a script in the root directory of the Unix server.

My case is more generic as there is a clear evidence that in Johannes example and case its more defined and maybe OK. In general you should never put passwords in scripts or environment variables; These scripts will hang around and can be found by anyone like me and could be used to access the systems if the person doing the finding does not have rights to access these systems.

In Johannes case its for a patch and the server is not in use during the patch so if adding passwords to a script is faster and easier than typing them in many many times during an installation then OK; BUT. the script must be removed afterwards and not backed up. Ideally all of the passwords must be changed after the install/upgrade so that if the script is left then the passwords do not work still.

Johannes also suggested the use of OCI vault to store the passwords. This is also OK BUT if you don't use OCI then its more complex to use it just for this. If you do use OCI already then its easier as you have the OCI already and its set up already.

You can also use Oracle wallets and secure password store for local database passwords. You could also use directory based accounts or even SSL authentication in the database so there is no password but not for other systems that do not support these.

Finding a password is easier than cracking a password. Clean up, never leave scripts lying around, make sure anything with a password in a script temporarily has its password changed straight afterwards. Using scripts and passwords where the system is temporarily restricted is fine BUT only if you clean up

#oracleace #sym_42 #oracle #database #oci #vault #passwords #securepasswords #wallet #cracking #scripts