Disabling PS_TOKEN with PSEatCookies Filter
As many of you have probably heard, there has been much discussion over the past few weeks regarding vulnerabilities in PeopleSoft's PS_TOKEN. The talk all started after a presentation from ERPScan, which basically said that a PeopleSoft node's password can be gained by brute force against a PS_TOKEN. This would allow someone to generate their own PS_TOKEN for any userid.
Now, word is the Oracle plans to bump up it's SHA-1 salted encryption with PeopleTools 8.55. However, it is probably a long ways out before most of us get to 8.55. And when we do get there, who's to say how long this new encryption will be considered secure? One option is to simply disable the PS_TOKEN, and therefore prevent this vulnerability altogether! The problem is, PeopleSoft does not give us the option to disable it.
I decided to come up with a proof of concept for a custom solution to this issue. I wrote a Java servlet filter, called PSEatCookies, that will prevent a PS_TOKEN, or any other Cookie you specify, from being added to the ServletHttpResponse. The basic structure and setup is very similar to the filter delivered in the Kerberos Desktop Single Signon solution. I have added the java source, classes and an example web.xml entry to a GitHub repository. You can download it and follow the instructions for setup in the readme file here: https://github.com/kbens/ps-eat-cookies.
I can see this filter being handy when you have a web server located in your DMZ for a single PeopleSoft application. This way you can turn on this filter without impact to your internal users, who most likely would need their PS_TOKEN to jump between multiple applications. Otherwise, you would have to really build this out with special rules and logic, or purchase a third-party product that allows for more configuration.
Update 07/15/2015: If you find any problems, have ideas for enhancements or just have a question, feel free to open an issue on GitHub!
Now, word is the Oracle plans to bump up it's SHA-1 salted encryption with PeopleTools 8.55. However, it is probably a long ways out before most of us get to 8.55. And when we do get there, who's to say how long this new encryption will be considered secure? One option is to simply disable the PS_TOKEN, and therefore prevent this vulnerability altogether! The problem is, PeopleSoft does not give us the option to disable it.
I decided to come up with a proof of concept for a custom solution to this issue. I wrote a Java servlet filter, called PSEatCookies, that will prevent a PS_TOKEN, or any other Cookie you specify, from being added to the ServletHttpResponse. The basic structure and setup is very similar to the filter delivered in the Kerberos Desktop Single Signon solution. I have added the java source, classes and an example web.xml entry to a GitHub repository. You can download it and follow the instructions for setup in the readme file here: https://github.com/kbens/ps-eat-cookies.
I can see this filter being handy when you have a web server located in your DMZ for a single PeopleSoft application. This way you can turn on this filter without impact to your internal users, who most likely would need their PS_TOKEN to jump between multiple applications. Otherwise, you would have to really build this out with special rules and logic, or purchase a third-party product that allows for more configuration.
Update 07/15/2015: If you find any problems, have ideas for enhancements or just have a question, feel free to open an issue on GitHub!
Comments
Post a Comment