Oracle PeopleSoft: still a threat for enterprises

PeopleSoft_Ent_logoIn 2015, Alexey Tyurin from ERPScan presented at the Hack-In-The-Box Amsterdam conference [2][3] 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.

TockenChpoken Attack

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 :

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.

Screen Shot 2016-05-02 at 2.23.26 PM

Now, with this new mode, you will be in a better position to brute force any PS_TOKEN SHA1!

Mitigations

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:

  1. 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.
  2. 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.
  3. 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.

6 comments on “Oracle PeopleSoft: still a threat for enterprises

  1. -

    Great work! One question as I didn’t see any information on it, what’s the proper format for oclHashCat? Is it [SHA-1 hash from ERPScan]:[PS_TOKEN] ?

  2. -

    Proper format is SHA1:SALT

  3. -

    If you don’t know how to get the salt, use the ERPScan tool in verbose mode to obtain it.

  4. -

    I just want to offer some info – I’m a tech arch working with PS systems for most of my career. I’m not a security expert, and you’re probably not PS-experts, so I thought you might find this stuff interesting.

    “In other words, it means a potential access to the default PS user or a DBA access level.”
    Entry via PS_TOKEN means accessing the online PS system. The access that would be granted would be that of the PeopleSoft OPRID requested, which must exist and not be locked. If default administrator accounts (PS, VP1) are not used in production, then they could not be accessed. Also, PS abstracts the database account from the user account, so saying that DBA access level can be achieved is, I think, an exaggeration.

    Under mitigations: “Disabled SSO completely”
    Unfortunately, I don’t think this is really feasible. In the PeopleSoft context, SSO refers narrowly to the trusted authentication between two PS systems, and does not apply to external SSO solutions (e.g. TAM, OAM). While one use of PS SSO is to provide seemless navigation between, say, a PS Portal and PS HR, or PS HR and PS Financials, it is also used, for lack of a better phrase, providing SSO to itself. The most used version of this is providing a user links to the output of their batch processing jobs (referred to as “report posting.”). Because report posting is such an integral part of a basic PS system, I don’t think that disabling PeopleSoft SSO completely is a viable mitigation.

    • - Post author

      Charlie,

      Thanks for your comments. I’m glad to see some PS experts contributing to the discussion 😉

      It is true to say the attack on the PS_TOKEN will give you an access to any valid user of the platform, including the PS or VP1 accounts. The reality is, in many cases, these accounts are still in use or other superuser accounts can be guessed/retrieved (e.g. matches the AD SAMAccountName).

Comments are closed