- Mitigation options
- Best practices
- Lessons learned
- Incident Response
- Defense-in-depth for PeopleSoft
After the PS_TOKEN threat vector was announced at Hack in the Box Amsterdam in May 2015, security organizations started adding specific tests for PS_TOKEN into their penetration test portfolio.
If your organization does regular penetration tests (which you should if your PeopleSoft system is publicly available on the internet), your organization may fail and would therefore have to remediate this risk immediately.
What does this mean to you?
More time and effort will be required to deal with test results moving forward. Prepare for this situation today.
GreyHeller is the leading expert in performing PS_TOKEN assessments for customers and non-customers alike. Ensure your organization is in the most secure position by scheduling your assessment with GreyHeller today.
Appsian has been offering security assessments to both customers and non-customers around the potential of a PS_TOKEN configuration vulnerability. Over the past month, we have posted to our blog that PeopleSoft is arguably the most secure ERP platform on the market. The blog contains links to the PeopleSoft red paper and additional information about proper configuration of PeopleSoft to mitigate potential vulnerabilities of PS_TOKEN configuration.
In this session, Greg Wendt, Executive Director, Security Solutions, talks about numerous takeaways learned from our PS_TOKEN assessments. Topics include:
- Mitigation options
- Best practices
- Lessons learned
- Incident Response
- Defense-in-depth for PeopleSoft
In recent blog posts, we’ve mentioned that PeopleSoft provides a number of security protections out of the box. In this entry, we wanted to go into more detail on this, specifically focusing on what you should know about PeopleSoft and common web application vulnerabilities.
- Data sniffing
- SQL Injection
- Cross-Site Scripting
- Content Spoofing and Injection
- Directory Indexing
- Information Leakage
If you hire an organization to perform penetration testing (as any organization deploying PeopleSoft on the public internet should), these are the items that they will primarily focus on.
PeopleTools as a Security Platform
One of the most important aspects of security within PeopleSoft, is that the platform ensures that security protections are built in globally. As such, PeopleTools differs from other development platforms in the following ways:
- Secure by Default: Developers do not have to write specific security code in the application, because protections are applied automatically — PeopleTools takes care of it for them — thus ensuring that security is enforced consistently.
- Rapid evolution: Keeping up with potential vulnerabilities is an arms race where new attack vectors are constantly being created by the bad guys. Because the security logic is applied externally to the application logic, vulnerabilities can be addressed at the platform level, delivered by Oracle, and applied platform-wide immediately.
- Centralized Security Expertise: PeopleTools has a team of security developers who’s job it is to stay current on best practices and potential vulnerabilities, allowing the rest of the organization to focus on business functionality. This ensures that customers staying current on their PeopleSoft updates will be have the latest protections available.
So, let’s look at each of the common web vulnerabilities and what PeopleSoft does to remediate them.
Although this should be second nature to anybody deploying a web application, SSL termination is a critical component of ensuring secure data transportation between the end-user and the PeopleSoft system. PeopleSoft has configuration settings specifically for SSL termination and virtual addressing so that all traffic can be sent securely. It also gives organizations the ability to utilize other tiers for SSL termination, such as the load balancer.
Because many web applications access and store data through a relational database, a common attack vector is to inject SQL into edit boxes, URLs, or other user enterable fields to bypass application logic and talk directly to the database. This could allow an unauthorized user to:
- Gather sensitive data
- Make unauthorized updates to application data
- Escalate privileges and/or bypass system controls
- Cause service interruptions
The following comic — “Bobby Tables” — pokes fun at this technique:
PeopleTools mitigates this vector through its definitional development infrastructure. When a page is developed in PeopleTools, the developer is rarely writing SQL, but placing the fields on the page. PeopleTools will generate the SQL with the appropriate size, type, and encoding.
However, PeopleTools does not restrict developers from writing their own SQL, frequently using the infamous SQL-Exec PeopleCode function. Therefore, it’s important that organizations incorporate strong change management techniques to review in detail any places where customizations are made with SQLExec functions.
PeopleTools protects against cross-site scripting by embedding a random token in each PeopleSoft page that is validated by servlets on the PeopleSoft web server. If the form doesn’t have the token or the token is rejected, the traffic is also rejected.
This vulnerability existed in very early PeopleTools versions (circa 2000), but was remediated quickly platform-wide with a PeopleTools update once the threat vector was discovered and hasn’t been a risk for at least 10 years.
Content Spoofing and Injection
Content spoofing and injection is a whole category of techniques for making unexpected modifications to HTTP traffic between the browser and the application. Examples include:
- Modifying the URL in unexpected ways
- Altering or removing HTTP Headers
- Altering or removing cookies
- Altering the HTML or XML content
A common technique followed by the bad guys is to install a proxy between the browser and the application, capture traffic, modify the different aspects of the traffic, and play back the results.
PeopleTools protects against spoofing and injection by acting as a single controller that issues and processes the HTTP traffic. Whenever an unexpected event occurs (such as an unexpected URL), it will either issue a security error (such as You are not authorized to access this component) or will terminate your session.
That said, there are techniques that some implementation decisions that customers can make that would allow an organization to circumvent these protections. These would include the following:
- Adding an HTTP header to the HTML to maintain the identity of the user for single signon. If the header is accessible to the end-user and Signon PeopleCode does not have anti-spoofing functionality, modifying the header could allow access without logging in.
- Utilizing the %GetRequest parameter with a SQL-Exec function. Because this function allows parameters to be embedded in the URL as a query string, improper use of it could open up a vulnerability
- Improper implementation of location-based security rules. Many organizations will implement location-based security by hiding URLs based on location (versus blocking them). Because any PeopleSoft page can be accessed directly from a URL, merely hiding navigation does not block access to the content.
Directory indexing is a threat vector where a person gets a web server to disclose the list of files and folders on it. In some cases, this can be used to determine how the application works behind the scenes, even to point of looking at the code that is running on the server.
PeopleSoft provides a few protections against this:
- The first is that all of the security, business and database logic runs on a server separate from the PeopleSoft web server. This means that gaining access to the web server does not provide access to the directories controlling how the application processes
- The second is that PeopleSoft has a number of ways in which it can be deployed in conjunction with a DMZ. One common option is to have a proxy server running in the DMZ where the web server itself is behind the corporate firewall.
The last threat vector we will discuss. From the context of this discussion, we will be covering information leakage as it relates to an external attacker trying to learn about how the system operates. Information Leakage can also be discussed from the perspective of an authorized user’s use of sensitive application data, which will be discussed in a future post.
Anybody familiar with PeopleSoft’s Control-J function is familiar with type of data that can be leaked. This page provides information about the version of PeopleTools, the PeopleSoft application, and the ports that are being used on the app servers. At the weblogic level, the weblogic console provides information about the java version being run, etc. Although it is great for troubleshooting issues in a development or test environment, an external person can utilize this to research known vulnerabilities for the versions being utilized to plan an attack.
Fortunately, PeopleSoft provides a configuration option in the web profile to turn off disclosure of this information, and the default PROD web profile has this setting made appropriately.
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.
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.
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.