In 2015, Alexey Tyurin from ERPScan presented at the Hack-In-The-Box Amsterdam conference  multiple attack vectors to defeat the widely used Oracle PeopleSoft (or PS) system. Many companies in various market verticals are relying on this massive and complex software to host confidential information about their employees, their students or even about the financial results of the company. Furthermore, many corporations are exposing this platform on the Internet, especially when relying on PS for career portals or student portals. A year later, I am still amazed to see publicly accessible systems or internal PeopleSoft deployments during our intrusion testing practice that are vulnerable to these common attack vectors. These deployments fail to deliver a useful result, putting the entire company workforce identity at risk. The following post will explain how to attack the PS_TOKEN, as well as describe our contributions to John the Ripper and oclHashcat in order to speed up the cracking process.
During the presentation, Tyurin explained and demonstrated a way to attack the SSO functionalities of the PeopleSoft deployments. In a nutshell, the idea behind this technique is to break the SHA1 signature contained in the PS_TOKEN, and gather the PeopleSoft node password. The node password is used as a trust entity, just like a pre-shared key system. An attacker gaining access to this information will give them the ability to generate a valid PS_TOKEN for any users of the platform, allowing them to completely bypass the need of authentication. In other words, it means a potential access to the default PS user or a DBA access level. Ouch! The worst part is there is a working tool available, and almost all phases of this attack can be conducted offline, so no obvious traces will be logged in the remote system. A nightmare for incident handlers to detect the breach in a timely manner.
Adding Brute-Force Capabilities
While the ERPScan tools are working perfectly to perform dictionary attacks on the node password, sometimes heavier attacks like brute force are required to break the signature. In a recent mandate, no word lists were effective, so our team had to roll up our sleeves and code a dynamic format for the popular John the Ripper software.
Based on the ERPScan’s tool source code, the algorithm used by PeopleSoft to hash the signature is fairly simple: SHA1(salt+utf16le(password)). In other words, the SHA1 signature is the hash of a salt (which is derived from the token variables) concatenated with the node password encoded in UTF-16. If you use John the Ripper with the jumbo patch you will notice that the code was recently fixed to support salts containing null bytes. Now, you can add this function in your “dynamic.conf” file :
Expression=sha1($s.utf16le($p)) [Oracle PeopleSoft PS_TOKEN]
Please also note, the SaltLen variable may need to be adjusted according to your setup. In our example, we tell John the salt has a maximum length of 150 bytes.
While this dynamic format can leverage CPUs to crack the password, the time required to break a long and complex password could take years. Obviously, that could not work for our assessments or intrusion tests, so we had to change our approach. The solution was to contribute a new mode in oclHashCat.
GPU Cracking With oclHashcat
The requirements to create a new mode for oclHashcat are quite simple: you need to build the parser for the proper hash/salt format, handle the core storage of the data, build the OpenCL kernels for the cracking algorithm, and code the unit tests. Martin Lemay and I were able to contribute PeopleSoft's PS_TOKEN hash cracking to the oclhashcat project and make it work, of course, with the great guidance and the help of Jens Steube for the OpenCL kernels. It has been integrated in the project's master branch. As a result, we can now achieve much higher cracking speed: 4.3 billion hash per second on a single cracking node.
Now, with this new mode, you will be in a better position to brute force any PS_TOKEN SHA1!
There are no reasons to keep your enterprise at risk of such attack, especially when the workarounds are so easy to implement. Three options are available:
- Disable SSO completely on PeopleSoft. That way, you would no longer have any token. Unfortunately, sometimes SSO is required, this is a feature after all.
- Use a strong password for the node. No reason to keep the default or use a dictionary based word. The system allows a maximum of 24 characters, you should take this opportunity and create a strong and complex password.
- Use certificates. Using certificates as trust entities would add robustness to your setup.
What We Observed In The Wild
Unfortunately, many corporations do not implement any of the recommendations outlined above. You can find a lot of Oracle PeopleSoft deployments simply by using Google. Also, you will notice that a quick and naïve testing of the PS_TOKEN will reveal the use of very weak node passwords, even the default is still in use at times. Of course, I did not try the last piece of the attack which is to generate a valid token because of the legal impacts, and I do not recommend the readers to do it either. That being said, these companies or entities are exposing themselves to huge risks even if the mitigation measures are very simple to implement. A successful breach could leak hundreds or thousands of employees’ personal identities. The impact would be devastating for them, and also for the company's reputation. So, if you are using PeopleSoft in your company, now you know how to mitigate your risks, and what could happen if you don’t!
About the author
François Gaudreault manages the team of Ethical Hacking at GoSecure. He specializes mainly on methodology and improving practices. He also ensures management and test execution, as well as delivery of projects for customer satisfaction. You can follow him on LinkedIn.