Several years ago, ERPScan published a
series of articles describing PeopleSoft security attack vectors. While reading the series, keep in mind it was written nearly a decade ago, and PeopleSoft has made changes to security to mitigate the issues raised by ERPScan. For example, their article about the Access Token ends with the note, "this vulnerability was patched in Oracle CPU for October 2014." Note to self: Apply CPUs! But the topic that keeps coming up is
TokenChpoken.
What is TokenChpoken?
When you authenticate (log in) to PeopleSoft, PeopleSoft sends a cookie to your browser. Thereafter, PeopleSoft identifies you by that cookie. For every request, PeopleSoft asks, "who are you?" and that cookie supplies the answer. This cookie is critical to cross-product SSO for unified navigation, Interaction Hub, etc. TokenChpoken describes how to decrypt that cookie, change the OPRID, and assume the identity of someone else. Pretty scary! But is it legitimate? As described by the TokenChpoken write-up, someone leveraging this approach must know your user ID, the SSO node name, and the node password must be discoverable through a modern brute-force attack. If you renamed your nodes and use strong passwords, you are a long way from a TokenChpoken "vulnerability." But that doesn't eliminate the potential. It is now a risk calculation.
Is TokenChpoken still relevant for today's PeopleSoft? In PeopleTools 8.56, PeopleSoft implemented a "knock knock/callback" pattern with a check token. Dan Iverson has a great write-up on this 8.56 feature. Likewise, as of 8.56, if I restart my web server while browsing PeopleSoft, PeopleSoft renders the message "unauthorized token detected." It seems like PeopleSoft now keeps a list of issued tokens in memory, and a restart clears that list. These are fantastic safeguards against a potential TokenChpoken Switch User. My thought is,
"If PeopleSoft won't accept its own token after a restart, why would it accept a modified token?"
But is this enough?
A few years ago, Colton Fischer came up with a simple way to test functionality as a different user. You log into PeopleSoft as yourself, press a bookmark in your web browser, supply the node name, node password, and the target user ID, and instantly become someone else. You may find his project here. As a developer and tester, this sounds fantastic! Through a "master password," I can assume the identity of anyone for testing purposes, of course. How does it work? It is essentially TokenChpoken in the web browser. What does that mean? TokenChpoken is alive and well.
Mitigation
As documented by Dan Iverson, setting the Check Token and node password on your nodes, as well as changing node names from something other than the default PSFT_xx, is a great start. And that start may be enough. But you might want to try Colton's bookmarklet to see if you can become someone else. If so, here is another idea: Eliminate the PS_TOKEN cookie. Eliminating the PS_TOKEN is a bit controversial as this is the "key" to PeopleSoft SSO, and it may not be the right solution for you. But here is how it works: As a request leaves a load balancer or web server, the web server/load balancer replaces PS_TOKEN with a different, randomized cookie. On re-entry, the web server/load balancer maps that random cookie to the original PS_TOKEN. PeopleSoft is unaware and functions as usual. If all of your PeopleSoft instances are behind the same load balancer and use the same domain, then SSO may work as usual, and token replacement may be a great option. If you want an off-the-shelf solution, check out Pathlock's ERP Firewall, which has built-in TokenChpoken mitigation.
Since most PeopleTools classes involve nodes and security, we talk about TokenChpoken regularly. To learn more about this topic and other PeopleTools tips, check out our website to see what we are offering next!
