EAS-SEC. Oracle PeopleSoft security configuration. Part 9: Insecure trusted connections

Various solutions may be used to create intersystem business processes. The trusted relationships or Single Sign-on (SSO) between PeopleSoft systems allow minimizing the authentication requirements. If the calling PeopleSoft system (Node) accepts the called system as trusted, the password won’t be required.

The biggest benefits of such interaction are that, firstly, passwords are not transmitted to the network, and secondly, a simple registration is available beyond the system boundaries. With this function in place, you may create a PeopleSoft portal consisting of various PeopleSoft applications (e.g. Campus Solutions, HCM, FSCM) where a user has an opportunity to navigate within a system of multiple applications after being once authenticated.

PeopleSoft-only Single Sign-on [EASSEC-PVAG-PS-28]

Description

Single sign-on is critical for PeopleSoft portal implementations because the portal integrates a content from various data sources and application servers and presents them in a unified interface.

After the first application server/node authenticates a user, the system delivers a web browser cookie containing an authentication token (PS_TOKEN). PeopleSoft uses web browser cookies to store a unique access token for each user after the initial authentication. When the user connects to another PeopleSoft application server/node, the second application server uses the token in the browser cookie (as long as the token is valid) to re-authenticate users automatically so they don’t have to sign in repeatedly.

The list of trusted nodes for the Financials system resides in the PSTRUSTNODES table. You configure the list using PeopleTools, Security Objects, Single Sign-on. There, trusted nodes are chosen and then added to Whitelist sites or allow Domain Compare in Web Profile to participate in single sign-on.

Furthermore, nodes have a two-authentication option of single sign-on:

  • Password (the value you enter is limited to 88 characters) indicates that each node in the single sign-on configuration authenticates other nodes by “knowing” the password for each node.
  • Certificate shows that a digital certificate authenticates each node in the single sign-on configuration.

Threat

  1. PeopleSoft single sign-on functionality is also applied at the web server level. For example, imagine you have two web servers, server X and server Y. Assume that web server X is an SSL/TLS site while web server Y is not. In this case, many organizations want server Y to trust the authentication token, PS_TOKEN issued by server X. It requires PS_TOKEN to be set in order to be secure.
    If PS_TOKEN is not marked as secure, the browser sends PS_TOKEN to server Y over the unencrypted non-SSL/TLS link when a user signs in through server Y. This is a typical behavior for browsers when dealing with non-secure cookies. Potentially, a hacker could identify this token from the clear network and use it to sign on to SSL/TLS-secure server X.
  2. If you use a password as an authentication option of single sign-on, especially in case of a short length password, an attacker can perform a TockenChpoken attack and gain full access to PeopleSoft.

Solution

To resolve this potential security issue, select the Secure Cookie with SSL check box on the Web Profile Configuration – Security page. You use this property to control the secure attribute of the single sign-on cookie. If you enable the property, and the scheme of the current request is HTTPS (SSL/TLS server), the system sets the secure attribute of the single sign-on cookie (PS_TOKEN) to true.

This prevents the single sign-on token from travelling over an insecure network. If you enable this property, you effectively disable single sign-on to any non-SSL/TLS servers. To prevent a TockenChpoken attack, it’s recommended to use digital certificate authentication when implementing single sign-on. It is configured in the Node Definitions page (PeopleTools >Portal > Node Definitions).

PeopleSoft integration with third-party systems via Integration Broker [EASSEC-PVAG-PS-29]

Description

PeopleSoft Integration Broker is a middleware technology that

  • performs asynchronous and synchronous messaging among internal systems and third-party systems;
  • exposes PeopleSoft business logic like web services to PeopleSoft and third-party systems;
  • consumes and invokes web services from third-party and PeopleSoft systems.

PeopleSoft Integration Broker enables you to perform these integrations among internal systems and third-party integration partners, while managing data structure, data format and transport disparities.

Third-party systems is configured like PeopleSoft systems in Node Definitions page (PeopleTools > Portal > Node Definitions) and in the Gateways page (IB_GATEWAY) to update configuration settings and register target connectors to be used with the gateway.

The PeopleSoft delivered some default target connectors with properties:

  • APNTargetConnector
  • AS2TargetConnector
  • ExampleTargetConnector
  • SimpleFileTargetConnector
  • FTPTargetConnector
  • GetFileTargetConnector
  • GetMailTargetConnector
  • HttpTargetConnector
  • JMSTargetConnector
  • ApplicationMessagingTargetConnector
  • PeopleSoftTargetConnector
  • RIDCTargetConnector
  • SFTPTargetConnector
  • SMTPTargetConnector

Threat

The web services and integrations in your PeopleSoft applications can expose sensitive information including financial data. For example, security requirements might differ when interfacing with credit card processing vendors, versus publishing salary information out of human resources, versus synchronizing business units between applications, and so on. If authentication data of a user with access to a third-party system is compromised, an attacker will get access to the PeopleSoft system and perform critical actions with sensitive information via Service Operations.

Solution

A security analyst must evaluate security requirements for each individual integration. Review the list of connections with third-party systems and active nodes and define which of them you actually need. If the connection stores user authorization values, it is recommended to analyze the user. Properties of connectors is configured in the Gateways page (IB_GATEWAY). Node definitions, WS Security, and Routing Definitions with Service Operations are configured in Node Definitions page (PeopleTools >Portal > Node Definitions).

Remote PeopleSoft connections with DB [EASSEC-PVAG-PS-30]

Description

Data sources represent the location of the source data that is extracted, transformed, and loaded to the target. Remote data source data is extracted from a separate (remote) database and migrated into the local database. You must define remote database connections to source data from a database other than your local PeopleSoft database instance.

The Remote Database Access Management page enables you to define connectivity information for relational databases to be used for sourcing data for PeopleSoft Data Transformer. The Remote Database Access Management page (REMOTEDB) is used to define remote database connections.

Threat

If authentication data of a user with access to system is compromised, an attacker will get access to the remote database, because the local database stores data of the remote database: DB name, server, port, user ID, and password.

Solution

If you don’t require extracting remote data from a separate database and migrating into the local database, it is not recommended to use this functionality. If you access data from a local database, you do not need to set up remote database connections.

Further steps

In addition to mechanisms of an application server, servers are often connected with a number of other mechanisms. For example, Oracle Access Manager can be used as the single sign-on solution. It is used when you have Oracle applications and PeopleSoft applications in your organization and users who have been authenticated by the Oracle system can access PeopleSoft applications without being re-authenticated.

Further, the scope of such mechanisms includes any other possible methods to penetrate neighbour system employed in penetration tests, i.e. an attempt to enter the neighbor system with the same or similar passwords both at OS, RDBMS and application levels, as well as all kinds of search for passwords in plain text in the file system; update, integration, backup scripts, etc. All this should be checked to eliminate any risk of penetration with one weak link to all systems.

Stay tuned, as soon we will come back with the final critical area – Security events logging.

Do you want more?

Subscribe me to your mailing list