In this blog post, we will walk through each of these vulnerabilities, starting with a Server-Side Request Forgery (SSRF) vulnerability. We will also review the validateClient method that Oracle introduced to allow PeopleSoft system administrators to restrict access to certain functionality. Spoiler alert: the SSRF allows attackers to make requests that satisfy this validation and access endpoints vulnerable to remote code execution (RCE).

Overview

There are two main components involved here, both served as individual Oracle WebLogic applications.

The first, the PeopleSoft Environment Management Hub (PSEMHUB), is part of Oracle’s Environment Management Framework. This component implements the validateClient method, ensuring only trusted clients can reach PSEMHUB functionality. Because this is an internal management interface, it makes sense that Oracle would restrict access to its web endpoints. However, this also means it’s a prime target for attackers looking to pivot from their existing, low-privileged access.

The second, the PeopleSoft Integration Gateway (PSIGW), contains functionality for exchanging messages between the PeopleSoft server and remote systems. This is accomplished using a set of Listening and Target Connectors.

One such connector is the HttpListeningConnector, which translates data from inbound HTTP requests into the format supported by the specified Target Connector before routing the request to the desired URL. In this chain, attackers specify the HttpTargetConnector.

The diagram below shows how an attacker like ShinyHunters can combine these vulnerabilities to compromise PeopleSoft systems. Notice that the attacker cannot simply hit the PSEMHUB functionality directly:

Bug 1: PSIGW Server-Side Request Forgery (ZDI-CAN-31816)

Now let’s take a look at how the PSIGW SSRF provides attackers with a foothold in the PeopleSoft application. An example malicious request to PSIGW shows just how powerful this is for an attacker. We control the URL to hit AND the full payload to send!

At [1], the attacker sends a POST request to /PSIGW/HttpListeningConnector

At [2], the HttpTargetConnector handler class is specified

At [3], the target is PeopleSoft on the loopback interface at http://127.0.0.1:8000, satisfying the validateClient logic

At [4], the full POST request payload is specified in the Data field, to be forwarded to the target URL at [3]

The HttpTargetConnector handler appears below. Note there is no validation to ensure this traffic is legitimate and bound for a valid target. I've done my best to pull out the important parts of this 800+-line function. If you want a fun side quest, go decompile this for yourself and check it out. I hope you like spaghetti!

At [1], retrieve the target URL from the attacker's request

At [2], create an httpObj using the URL from [1]

At [3], retrieve the HTTP method (POST) and apply it to the httpObj from [2]

At [4], send the content data seen in the Data tag of the network request. This content is sent as-is using the HTTP parameters configured in the httpObj

To fully understand why this SSRF is valuable, here is the validateClient method I mentioned earlier:

At [1] and [2], the validateClient method pulls the hostname and IP of the requesting client

At [3], a file path is built to the /envmetadata/config/allowedhosts.properties file, which contains the list of hosts allowed to access functionality protected by validateClient

At [4], the server checks if the allowedList set contains any entries. The first time this path is hit, the set is empty, so execution continues into the client list refresh block

At [5], that allowedhosts.properties file is read and iterated over

At [6] and [7], each allowed host is added to the allowedList set, including the default localhost entry alongside the server's resolved hostname and IP address

At [8] and [9], if the requesting host is found in the allowedList set, validateClient returns true

We can see the localhost entry in the default allowedhosts.properties that ships with PeopleSoft:

While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB. Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access.

Bug 2: PSEMHUB External Control of File Path (ZDI-CAN-31818)

Now that the attacker can make requests to the PSEMHUB endpoints using the PSIGW SSRF, let's see how they can turn that into RCE.

The first path to code execution uses an External Control of File Path vulnerability in the ExecuteProcessActivityCommand handler, which is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem.

However, callers of the command control both the file contents AND the absolute file path on disk to which that content is written. Here’s an example of the request made to PSEMHUB. Note that, in practice, each parameter value is a form-encoded serialized Java object. For clarity, I’ve decoded and formatted it here:

At [1], we see the request is being made to PSEMHUB’s central routing hub

At [2], note that the request is made to the loopback address 127.0.0.1. Since this request originates from localhost, the validateClient check is satisfied

At [3], the web shell contents are specified in the m_line parameter

At [4], the absolute path where the contents will be written is specified in the m_targetFile parameter

Looking at the handler for this request, we can see that no validation is performed to ensure that m_targetFile points to a legitimate log directory:

By writing this shell to the PSEMHUB WAR path, the attacker achieves immediate remote code execution in the context of the PeopleSoft service account.

Here's how those bugs look when chained together:

Bug 3: PSEMHUB Deserialization of Untrusted Data (ZDI-CAN-31817)

Using any file write primitive (like the ExecuteProcessActivityCommand seen above), an attacker can write a malicious XML file inside the [docroot]/envmetadata/data/environment/ directory. When the PSEMHUB HubServlet class initializes next (after a system or service restart, for example), it triggers a code flow that ultimately deserializes this XML file. Because this vector does not require writing a JSP web shell, it is less likely to be noticed by standard detection methods.

Specifically, on initialization, the PSEMHUB HubServlet class calls startServerPeer in the com.peoplesoft.pt.environmentmanagement.hub.Server class:

At [1], HubMBeanPersistance.getInstance() is called, which triggers the private constructor for that class

At [2], env_dir_path is set to <context_root>/envmetadata/data/environment/, which contains the malicious XML file placed by the attacker

At [3], all files from this folder are loaded into a list variable fl

At [4] and [5], the absolute path for each file in that directory is built

At [6], XMLDecoder is instantiated for each file

At [7], the content of the malicious XML placed by the attacker is deserialized

Java's XMLDecoder instantiates and configures the objects described in the XML during parsing, so the attacker's payload executes before the cast to Environment throws an exception.

Conclusion

The combination of the powerful PSIGW Server-Side Request Forgery primitive alongside the decision to allow access to PSEMHUB via the loopback address by default renders the validateClient protection ineffective. Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft.

The impact of SSRFs can sometimes be overlooked, especially if they have no standalone information disclosure impact. Under the right circumstances, however, the humble SSRF can open the door for complete compromise.