pscipher, psvault and Web Server Passwords
Encrypting passwords is a common activity for PeopleSoft administrators. For many of us, we take for granted that passwords are encrypted by the system. In this post, I want to look at password encryption for web server configuration files and how that works.
Encrypting with pscipher
pscipher is a PeopleTools utility that encrypts passwords using 3DES encryption. The utility is a wrapper for a Java class that handles the encryption and decryption of passwords. If you look at the passwords stored in the configuration.properties file, or produced by pscipher, they look something like this: {V1.1}IsZtCVg15Ls=
To encrypt a password with pscipher:
- Navigate to your web server’s
[PS_CFG_HOME]\webserver\[domain]\piabinfolder. - Run
.\pscipher.bat [password]
pscipher will return the encrypted output:
.\PSCipher.bat password
Your environment has been set.
Encrypted text: {V1.1}7m4OtVwXFNyLc1j6pZG69Q==You can copy/paste the encrypted text into your web server config files. For example, below is the pskey configuration in the integrationGateway.properties file using an encrypted password:
secureFileKeystorePath=e:/psft/cfg/LM014-8.55.09/webserv/peoplesoft1/piaconfig/keystore/pskey
secureFileKeystorePasswd={V1.1}7m4OtVwXFNyLc1j6pZG69Q==You can also encrypt passwords with pscipher through the PIA too. Navigate to PeopleTools > IB > Configuration > Gateways. Select your a gateway and click “Gateway Setup Properties”. After you log into the gateway, select the link “Advanced Properties Page”. This page lets you modify the integrationGateway.properties file directly, but it also has a Password Encryption section. This Password Encryption tool calls pscipher on your application server to encrypt passwords.
Building New Keys
The {V1.1} at the beginning of the password denotes which key pscipher uses. 1.1 means your passwords are using the default key. To create a new key, run the command pscipher -buildkey. A new key will be appended to the file psvault. The pscipher command will now generate {V1.2} passwords. Appended is important here. This means that you can still use {V1.1} encrypted passwords in your configuration files and the newer {V1.2} encrypted passwords.
psvault Locations
The psvault file is stored under [PS_CFG_HOME]\webserv\[domain]\piaconfig\properties\psvault. When you run -buildkey, that is the file pscipher updates. After you update the key to {V1.2}, you need to copy the updated psvault file to any other web and app servers that you want to decrypt the new passwords.
- For web servers, copy the updated
psvaultfile to[PS_CFG_HOME\webserv\[domain]\piaconfig\properties\psvault. - For app servers, copy file to
[PS_HOME]\secvault\psvault.
You should copy the updated psvault file to your app servers. When you update your integrationGateway.properties file online (PeopleTools > IB > Configuration > Gateways), any passwords you encrypt using the online pages are encrypted with the app server’s copy of psvault.
So far, I haven’t been able to get the Tuxedo domains to recognize the psvault file under PS_CFG_HOME, and a Oracle confirmed with me that PS_CFG_HOME is not supported with psvault and the app server. If you are using decoupled homes, this breaks some of the benefits of having a separate and shared PS_HOME codeline. I created an Idea on the Oracle Community site to add support for PS_CFG_HOME and psvault.
PeopleSoft passwords
We can divide these passwords mainly into 2 groups:
1) passwords generated by the PSCipher utility
2) passwords that we can discover in psappsrv.cfg file
Passwords produced by the PSCipher utility
According to Oracle, “The PSCipher feature encrypts and decrypts text used in your PeopleSoft system. System administrators interact with PSCipher through a Java, command line utility located on the web server, which enables you to encrypt text, such as user IDs and passwords, stored in configuration files.”
We can use this utility for encryption, but if we run it, we won’t find any arguments for password decryption.
Java application is a utility by itself, so we can try decompiling it and find out how we can use it for password decryption.
For decompilation, I applied Procyon utility. After, we can see that the PSCipher utility is a simple program that has several methods and one of them is provided below.
Nevertheless, we don’t have access to this method from the program start point, a main function. Therefore, we can a little bit change the main function to use this method.
If we append this code and recompile the PSCipher utility, we will be able to decrypt PSCipher’s passwords.
The PSCipher utility uses triple DES algorithm to encrypt/decrypt user passwords. The secret key is stored in special storage that is called psvalut. You can also mention a prefix that is used in a password encrypted by the PSCipher. In our case, it is {V1.1}. These prefixes indicate that the version of psvault format is “V1”, the second part after the dot is the number of internal triple DES key for passwords decryption/encryption. For example, if we run the PSCipher with an option -BuildKey we will get a message:
If we run the utility again with the same option, we get {V1.3}, etc.
User data is encrypted on a new secret key, it is added to psvault, and older keys are not lost, and you can decrypt the old data with prefixes 1.1, 1.2.
It’s important for PeopleSoft administrators to understand that if they don’t add a new secret key to psvalut storage (- BuldKey option) after system installation, PeopleSoft system will use default 3DES secret key for all data that needs to be encrypted. A default key in psvault isn’t generated randomly after installation, and the prefix {1.1} indicates that the PeopleSoft system uses this default base64 encoded triple DES key.
We can easily check that our psvault storage contains this key using STRINGS, SED, and CUT commands on Unix-like operation systems.
In the output that is shown above, the first line is a default key for {V1.1} prefix, and the remaining keys generated randomly are used for prefixes {V1.2} and {V1.3} accordingly.
The predefined key for the prefix {V1.1} was used on the whole PeopleSoft installation with a PeopleTools version at least from 8.50 and further. It means if an attacker somehow exposed critical data from PeopleSoft inner configs, he or she can easily decrypt and obtain the original password. This decrypted password can be used to leverage an attacker’s access to critical parts of PeopleSoft system or even can compromise the system, in case an attacker got access to integrationGateway.properties config.
Another way of collecting passwords that have been encrypted with the default key is to use Google. As a rule, PeopleSoft administrators expose passwords by themselves. For example, we can find that these passwords are publicly accessible:
Passwords from psappsrv.cfg
This file contains critical credentials such as password from PS user, PeopleSoft Application Administrator.
If we try to find any information on how these passwords can be encrypted we will get stuck, at least the same happened to me.
I am only aware that PSADMIN utility can change passwords in psappsrv.cfg but how exactly, I don’t know.
PSADMIN utility is well known in PeopleSoft administrators, it is used to manage PeopleSoft systems.
We can change passwords manually in the menu that was shown above. Now we should understand how passwords are stored. We should answer 2 questions for that:
- Are they encrypted or hashed?
- Can we decrypt them if they are encrypted?
Finally, PSADMIN utility changes data in psappsrv.cfg configuration file, so if we look at passwords in this file we will see the following:
At first glance, the passwords are hashed. Nevertheless, we can get all answers from the PSADMIN utility. For that, we will try collecting base information about the internal functionality of the utility. For that, we try to get names of all symbols used in the PSADMIN utility. We can do this with an assist of nm utility.
The nm utility was used because Oracle doesn’t delete symbols from the PSADMIN tool.
We can try to find curious function names that work with passwords. We can do this in the following way:
It seems interesting because according to the function name, RetrieveDomainConnectionPwd, we can in theory retrieve passwords from psappsrv.cfg.
RetrieveDomainConnectionPwd
Now it is time for static analysis. We can try to grasp how this function works by using IDA Pro disassembler or another free analog, for example, radare2. After the function has been decompiled and slightly reverse-engineered, we can see these remarkable parts of it:
1 2 3 4 5 6 7 8 | std::string::string(&command, "", &v39); std::string::string(&ubbgenFullPath, "", &v40); std::string::string(&appDomName, "", &v41); v8 = strlen(g_szPSHome); v9 = std::string::assign(&ubbgenFullPath, g_szPSHome, v8); std::string::append(v9, "/bin/ubbgen", 0xBuLL); //XXX ??? sprintf(&s, "%d", 30LL, v29); v10 = std::string::assign(&appDomName, "-decr ", 6uLL); |
and
It means that some utility is called with an option “-decr”, and it seems that its name is UBBGEN. Fast check in dynamic analyses has shown that it’s true. If we stop execution in _popen function and look at content of command variable, we will see the following:
The UBBGEN utility can read parameters from a file, there is a file content
Therefore, finally, this is how we can run command to decrypt DomainConnectionPwd:
Moreover, if we remove ’30’ program, it will work correctly.
The UBBGEN utility can decrypt more than one parameter from psappsrv.cfg (DomainConectionPwd), and even all of them.
In my test system, they look as follows:
Another compelling thing about UBBGEN that it has “-encr” option and we can encrypt what we need.
The UBBGEN utility
According to it, “Regardless of how you specify domain values, ultimately you must run PSADMIN to generate some necessary files that include your specific values. In the following example, PSADMIN invokes another PeopleSoft executable, UBBGEN, which reads the values and format in the psappsrv.cfg, psappsrv.val, and psappsrv.ubx files, and generates the psappsrv.ubb and psappsrv.env files.
Where you see Do you want to change any config values? (y/n), regardless of what you enter, PSADMIN calls UBBGEN.
If you have already entered values manually in the psappsrv.cfg file and enter n, UBBGEN reads those values and writes to the necessary files.
If you enter y, you see the PSADMIN prompt interface, which is actually a wrapper to UBBGEN. UBBGEN reads the previous values in the psappsrv.cfg, presents those values, and allows you to change them. It presents the values in the format that is derived from reading the PSAPPSRV.UBX file, and it validates selected values based on criteria in the PSAPPSRV.VAL file.”
It implies that PSADMIN is only a wrapper for UBBGEN that does all main work behind the scene. If we run UBBGEN without any arguments, we will get its usage prompt.
It’s ironic that UBBGEN’s usage prompt doesn’t show “-decr” and “-encr” options, it seems they are hidden.
Since PeopleSoft delivers the base64 encryption algorithm with the PSPETSSL encryption library, we can move right into defining the Algorithm Chain. To define the chain, navigate to PeopleTools > Security > Encryption > Algorithm Chain. Add the new value BASE64_ENCODE and add the following Algorithms in order:
- PSUnicodeToAscii
- base64_encode
- PSAsciiToUnicode
Be sure to set the sequence number for each row (1-3). Save and navigate to PeopleTools > Security > Encryption > Encryption Profile. Add the new value BASE64_ENCODE. Specify the algorithm chain BASE64_ENCODE and save. We can now test this pluggable encryption profile with a little PeopleCode:
Local object &crypto = CreateObject("Crypt");
&crypto.Open("BASE64_ENCODE");
&crypto.UpdateData("Hello World");
MessageBox(0, "", 0, 0, "Encrypted: " | &crypto.Result);
And, the result should be: SGVsbG8gV29ybGQ=. I am sure you will all agree that this solution is much simpler than the ugly Java Reflection I previously demonstrated. Furthermore, this method is well documented in PeopleBooks and supported by PeopleSoft.
No comments:
Post a Comment