Now that we have covered PeopleSoft Architecture, it is time to continue with PeopleSoft security and describe some attack vectors against PeopleSoft system discovered by ERPScan researchers. The first one is an attack on back-end systems.
First, we should clarify some essential terms:
- User ID – a PeopleSoft user account.
- Connect ID – a special account with minimal DBMS privileges.
- Access ID – a special account with a high level of DBMS privileges.
To begin with, let’s find out how the authentication of a PeopleSoft user into the application server works. Authentication consists of the following steps:
- A user sends his/her user ID and password to the application server.
- Application server retrieves these data and connects to the DBMS using Connect ID with the corresponding password. This DBMS account has limited access (can read the PSDBOWNER, PSSTATUS, PSOPRDEFN, PSACCESSPRFL tables). It requests User ID and password and compares them with those that were entered.
- If the credentials match, the application server retrieves the Symbolic ID associated with the User ID. Symbolic ID is just a link to a more important account: Access ID.
- The application server uses the retrieved Symbolic ID to find the necessary account (Access ID + password) in PSACCESSPRFL. This is a privileged account which has more rights in PeopleSoft database than Connect ID. Access ID and the password are encrypted.
- The application server uses Access ID to reconnect to the database.
So, Access ID is a high-privileged DBMS account. If an attacker can get it, they can pwn the whole PeopleSoft application.
Let’s take a closer look at the access available to Connect ID. It’s much easier to steal this account than Access ID because Connect ID is stored in plain text in some configuration files of the PeopleSoftapplication.
Connect ID allows us to read data from three tables, but only two of them store valuable information.
The first table – PSOPRDEFN – contains PS usernames and their passwords. But the passwords are hashed, and each password even gets its own random salt. Of course, they can be bruteforced, but the result depends on password complexity.
The second table – PSACCESSPRFL – contains the encrypted Access ID and its password. Oracle documentation states that Access ID is encrypted and, therefore, secure. But is it true?
A small research of ours has only revealed an XOR operation with a hardcoded key. What’s more, the key is the same for all PeopleSoft applications. Thus, anyone can decrypt Access ID and its password. Here is a simple Python script that decrypts Access ID.
import base64, sysdef xor_strings(xs, ys):
return "".join(chr(ord(x) ^ ord(y)) for x, y in zip(xs, ys))
if len(sys.argv) < 2:
sys.exit('Usage: %s b64_encoded_value_of_AccessID_or_AccessPSWD' % sys.argv[0])
key = "\xE3\x45\x98\x30\xCD\x02\xAD\xA8"
result = base64.b64decode(sys.argv[1])
if len(result) != 8:
print "Wrong encrypted value legth"
result = xor_strings(result, key)
print "Decrypted value is:\t"+result
The length restriction determines the feasibility of performing a bruteforce attack. An Access ID password cannot be longer than 10 symbols, which facilitates bruteforce attacks.
To sum up, once an attacker gets a Connect ID account and manages to connect to the DBMS, they can easily decrypt Access ID and take total control over PS.
In addition, I should mention that the same so-called “encryption” is used in PeopleTools applications for Windows: credentials are stored in the Windows registry (HKCU\Software\PeopleSoft\PeopleTools\Release8.40\).
This vulnerability was patched in Oracle CPU for October 2014 and the new method of encryption is now investigated by ERPScan Research Team.
The article is written by Alexey Tyurin, Head of Oracle Security at ERPScan
Comments