In the previous blog post about PeopleSoft Security we looked at the TockenChpoken attack and PeopleSoft SSO. Today we will go through all steps of exploitation of the attack which can help you during a PeopleSoft pentest. It consists of 3 key steps.
Preparation: Get an “original” ps_token
1. The TockenChpoken attack, by its nature, is a kind of privilege escalation attack. Therefore, we (as a penetration testers) need a valid user credential to exploit it successfully.
There are several main ways how we can get it:
- Check for default credentials;
- Dictionary/bruteforce attack;
- Various attacks on PeopleSoft users (XSS, MiTM, etc.) to steal a user’s authentication cookie (PSJSESSIONID, PS_TOKEN);
- MitM attacks on PeopleSoft web services, because they can also use ps_token for authentication;
- Via “Autologin” feature. A PeopleSoft application can be configured to authenticate an anonymous user automatically;
- Stolen credentials or cookies from other Oracle applications. For example, JD Edwards can be configured to support PeopleSoft SSO technology, so we can attack it too.
When we have a valid user credential, we can login into a PeopleSoft application and get a ps_token.
There is an additional, but sometimes useful step – to check the obtained ps_token.
We should delete all browser cookies and set only the ps_token, and the PS application should authenticate us. If it fails, there is something wrong with a configuration of SSO, so the TockenChpoken attack will not work out.
Attack
2) Perform the TockenChpoken attack on an “original” ps_token
First, we need to download the TockenChpoken penetration testing toolkit. The toolkit consists of three Python scripts. Two of them we will use on this step and the last one – on the next step.
The first script (parse.py) parses a ps_token and gives us all valuable information from it.
Example:
python parse.py -c PS_TOKEN_COOKIE_HEREOutput example:
SHA-1 hash from the token: e36a2b956e0466aebb4bb506da78538f2ecd4f99
Information from the token:
Little endian
PTWEBSERVER - user name
ENG - lang code
PSFT_HR - node name
2015-07-01-08.06.46.109641 - creation time
salt.txt is saved
We just need to set the “original” ps_token as an argument of the script. Also, the script generates a file (salt.txt, by default) containing the first part of values for the signature in a special format.
I should mention that during the testing of the toolkit we have found out two types of ps_tokens. It looks like the type depends on an architecture of a PS application’s hardware. So, there are ps_tokens with UTF-16 Little Endian encoding and UTF-16 Big Endian encoding. This fact doesn’t change the core of the attack, but the parsing process and a final hash value (signature) will differ.
As I have access to a PeopleSoft application with LE ps_tokens, the toolkit was fully tested on them. But I had only one BE ps_token (with a known node password) and I was not able to test the toolkit properly (actually, brute.py, as parce.py works with BE well).
As we parsed the ps_token and got all important values (salt.txt), we can go on to a dictionary/bruteforce attack on it in order to find a Node Password.
There is the second script (brute.py) in the toolkit. It gives us the opportunity to perform a dictionary attack on the ps_token. But being a Python script, it doesn’t provide a really high speed.
Nevertheless, I’ve added a list of the most widespread/default node passwords to the toolkit, so the toolkit guesses a correct node password pretty often.
Example:
python brute.py -s e36a2b956e0466aebb4bb506da78538f2ecd4f99 -d dictionary.txt -f salt.txtMoreover, as we remember, the signature we want to bypass is just a result of the SHA-1 hash function
Signature = SHA1(salt+password)where the salt is a special structure exported from parse.py (salt.txt), and the password s a node password in UTF-16LE encoding.
So, actually, we can use any brute forcing tools (HashCat, John The Ripper). But, unfortunately, HashCat doesn’t support the required length of the salt. On the other hand, knowing wide abilities of HashCat, I think it’s possible to bypass this restriction.
Well, having successfully bruteforced the ps_token and known the correct node password, we can create a new ps_token.
3) Create a new ps_token
We can easily create a new ps_token consisting of almost any values within it with the help of the last script of the TockenChpoken toolkit – generate.py
Just feed almost all values from parse.py and the node password from brute.py.
python generate.py -e 0 -u PS -l ENG -p password -n PSFT_HR -d 2015-07-01-08.06.46.There we may face two obstacles:
A) As we know, the ps_token is valid for a limited lifetime. The time and date when the ps_token was created is stored within it (example: 2015-07-01-08.06.46.109641 - creation time). Therefore, we have to set an appropriate time for a new ps_token, otherwise, a PeopleSoft application will authenticate us with the new ps_token. It shouldn’t be “in the future” (I mean, run ahead the server time. Besides, it shouldn’t be “older” than a lifetime of ps_token.
In practice, there can be some problems with setting the correct time. But there are three sources that can help us:
- Time from the original ps_token; (from parse.py)
- Time from “PS_TOKENEXPIRE” cookie. A PeopleSoft application sets it after an authentication;
- Time from HTTP response header “Date”.
To check, you can get all values except time from parse.py, set a new time, create a new ps_token and try to log into a PeopleSoft application.
B) Also, we need to know a valid name of user we want to “become”. The common choice is to set “PS”, a default super administrator of a PS application. But again, in practice this option sometimes doesn’t work well (for example, because the PS account is blocked). Therefore, we need to find a valid username of an administrator.
As an attempt, we can try to use default or known usernames and then using this access get a list of all users. If prefer, we can log into each user and check its privileges.
Conclusion
In general, these are the main steps to perform the TockenChpoken attack and difficulties one may meet during PeopleSoft penetration tests.
I’d like to thank everyone who helps me with the testing of the toolkit and send me feedbacks reporting results and problems.
By the way, if you have access to a PeopleSoft application with Big endian ps_tokens and with a known node password, please, write me.
The post PeopleSoft Security part 4: PeopleSoft pentest using TokenChpoken Tool appeared first on ERPScan.