As a follow-up to our June 3rd post PS_TOKEN vulnerability and prevention, I wanted to share recent activity about which you might be interested.

• On June 29, 2015, Security Week wrote the following article that not only discussed the issue, but also analyzed which organizations were at risk.
  • 249 commercial enterprises
  • 246 Universities
  • 64 government and military organizations
• On July 1, 2015, The Department of Homeland Security included this in its July 1 Daily Open Source Infrastructure Report

As you might imagine, some of the more public PeopleSoft customers have started to become concerned especially since an attack could occur offline without being detected by the customer.

Production Down!

At GreyHeller, things escalated when one of our Higher Education customers discovered that they were one of the universities Security Week had found. Due to these concerns, and because this customer had processes dependent on the PS_TOKEN cookie, this customer made the decision to shut down access to its production system until satisfied that this risk was addressed.

Following the shutdown, this organization looked at its options, which included the following:

• Contacting their cloud vendor to update their PS_TOKEN encryption key. This would take a minimum of 2 weeks of effort.
• Looking at upgrading to a newer version of PeopleTools that had a stronger encryption algorithm (256-bit versus 128-bit).
• Contacting GreyHeller to see if we could provide a solution for them that worked better than removing the PS_TOKEN cookie or their other options

The first two options would require an extensive outage that would affect employees as well as students.

Wait… Production Back Up!

Fortunately through collaboration with GreyHeller, this customer was able to meet its needs with only a brief outage. The ultimate solution will allow this organization to continue to operate PeopleSoft with the strongest protection possible with respect to this issue:

• They were able to move to the 256-bit encryption algorithm immediately
• They will be able to configure the solution to leverage alternate (and future) encryption algorithms with no down time
• They are able to deploy live rotation of encryption keys… without downtime. This means that this organization will be automatically changing the encryption keys more rapidly than the bad guys would be able break it.

Additionally, GreyHeller was able to address the customers risk without installing or updating software or accessing the PeopleSoft servers directly, which was extremely beneficial to them as their PeopleSoft systems are managed by a hosting provider.

Learn More

Contact us to schedule a review of your current environment and learn how you, too, could leverage the GreyHeller ERP Firewall to protect your PeopleSoft system.

If you weren’t in Amsterdam last week,  you missed out on a session at the Hack in the Box conference that is sure to be of interest to PeopleSoft customers. Presenters from ERPScan presented their latest findings in ERP vulnerability research and how PeopleSoft is affected.

Most critical to their findings is being able to brute force the PeopleSoft specific PS_TOKEN cookie to be able to recover the internal password used to sign the cookies.  This means that an attacker could be able to generate their own PS_TOKEN cookies at will for whatever user name that they choose.

Fear not though; there are ways to make sure that your PeopleSoft system is secure.

What is a PS_TOKEN cookie?

For those that aren’t familiar, the PS_TOKEN is what PeopleSoft uses to verify that someone has been authenticated by a PeopleSoft system.  It is not the same as the regular session cookie that identifies a given login session,  but is one of the mechanisms for establishing a new session.  For example,  someone might login to a PeopleSoft system for Financial data,  receive a PS_TOKEN cookie, and then when accessing a PeopleSoft system for Human Resource data, the PS_TOKEN cookie allows them access without needing to login again for the HR system.

This works by defining in the PeopleSoft configuration which nodes are considered to trust each other.  In the example above,  where someone logged in to the Financials system and was then given a PS_TOKEN cookie,  when they went to the HR system,  it would only allow that person to continue without authentication if 1) the node that created the cookie (the Financials system) is in the list of the nodes that the HR system trusts. 2) the PS_TOKEN cookie has not expired (the default expiration is 8 hours, but this is configurable) and 3) the user account that the PS_TOKEN cookie was issued for exists in the HR system.

How can you mitigate the risk?

Unfortunately,  generating a PS_TOKEN cookie when someone logs in is hard-coded into PeopleSoft.  Even if you don’t have multiple PeopleSoft systems.  In theory, you can remove all nodes from the trusted node table so that the generated PS_TOKEN can’t be used for establishing new sessions,  but this has an impact on some system level functionality as well (e.g. reporting functionality stops working),  which makes that impractical.

It turns out though that you don’t even need a PS_TOKEN cookie to work in PeopleSoft.  Who knew?!?  You can test this yourself by logging in to a PeopleSoft environment with a browser that allows deleting individual cookies,  such as Google Chrome,  and remove the PS_TOKEN cookie after you have logged in.  Everything will continue working properly.

Deleting the cookie manually is not viable either though.  This is something that you can do with the Appsian Security Platform for PeopleSoft.  You can remove the PS_TOKEN for just the public browsing sessions or for all users if you don’t rely on the PS_TOKEN cookie to transfer users between different PeopleSoft systems.

You can also create rules in the Security Platform that allow you to allow usage of the PS_TOKEN on your internal network,  but block it from external users.

How about external authentication such as Kerberos/Shibboleth/OAuth2?

If you already have PeopleSoft configured for external authentication, then you definitely don’t need the PS_TOKEN cookie to pass users between different PeopleSoft systems.  Once the person crosses from one system to the other,  your external authentication kicks in and automatically log them in to the other environment.

Doesn’t Two Factor Authentication fix this?

If you require two factor authentication each time someone logs in to PeopleSoft,  then this greatly reduces the exposure from an attacker being able to generate their own PS_TOKEN cookies.  They would be able to start a session,  but then would be immediately challenged for the second factor of authentication.

The Appsian Security Platform for PeopleSoft supports requiring a two factor challenge at authentication time,  but one issue is that usability suffers dramatically when constantly requiring a second factor at login time.   In fact, what we typically see with Appsian customers implementing the Security Platform is that it is preferred to wait until someone accesses sensitive data/actions before requiring the additional factor of authentication.  This hits a balance between locking things down and the user experience.

What about using a stronger hashing algorithm?

A stronger hashing function will help,  but less than you think.  If you look at tools like oclHashcat,  they show that breaking an SHA-256 hash runs at about 40% of the speed of breaking an SHA-1 hash. Breaking an SHA-512 hash runs at about 14% of the speed of breaking an SHA-1 hash.

So if it would have taken someone 8 hours before to break an SHA-1 hash,  now they have to wait overnight in order to break an SHA-256 hash.  Or they have to wait a few days to break an SHA-512 hash.  Not a big deal if full access to a PeopleSoft environment as any user is the prize.

The other thing to keep in mind is that you can now rent GPU instances from Amazon with over 1500 cores in them and breaking hashes is something that is, as they say, embarrassingly parallel.

For additional information on the Security Platform or Appsian visit www.appsian.com.