PeopleSoft Token: Difference between revisions

From Leo's Notes
This page was last edited on 27 September 2015, at 09:15.
No edit summary
No edit summary
Line 46: Line 46:
Data Value: 2015-09-25-18.43.15.553453
Data Value: 2015-09-25-18.43.15.553453
}}
}}
== A Simple Parser ==
Here's a parser which I wrote in PHP. It will correctly detect the endianness of the values and read the binary properly. It also checks the hash against some default passwords.
<phorkie>https://phorkie.leo.home.steamr.com/11/embed</phorkie>


== Signature Generation ==
== Signature Generation ==
Line 54: Line 59:


=== Cracking The Node Password ===
=== Cracking The Node Password ===
Since I can't figure out how to get John to crack a SHA1 hash with a prefixed string... I wrote a PHP script that pipes stdin to a {{code|sha1}} call. This is undoubtedly slower, but I have full control over the string.
Since I can't figure out how to get John to crack a SHA1 hash with a prefixed string, I modified the parser script I wrote in PHP to read passwords through stdin to test.


What is confusing is why the strings contained in the token contains null bytes before each character. It could be something to do with the string being UTF8 perhaps.
What I'm unsure at this point is how PeopleSoft hashes the values to generate the signature. The string values I read from the PS_TOKEN cookie appears to have null values inserted between each ASCII character which almost seems to hint that the string is encoded in UTF-8.


At the moment, I hash the guess three times: Once with the null bytes before each ASCII character, one after each ASCII character, and one without any null bytes.


== See Also ==
== See Also ==

Revision as of 09:15, 27 September 2015

I came upon an article concerning the PS_TOKEN vulnerability where an attacker can brute force the SHA1 signature value in order to obtain the node password for PeopleSoft systems using SSO.

Since my university uses PeopleSoft, I took a deeper look into how PS_TOKEN is generated and parsed.

Cookie Format

The value itself is encoded using base64 and looks something similar to:

AAAAqQECAwQAAQAAAAACvAAAAAAAAAAsAARTaGRyAgBOdwgAOAAuADEAMBSEI9HyVMA76K0KLjX552P1scTSuwAAAGkABVNkYXRhXXicHYtBDkBADEWfIZaWbkEGM8JasBMJNjaO4XIO58+06Wublw+8iUkzElTmCyy5Y19MDLT0WNHlzGysBTsHCyeP/OGkLA2eSnsU23g3itY4OjHYWuP1ucgf6kMMnw==

The actual format of the binary blob that I've found is:

0 : Int32 - length of the entire token
4 : Int32 - Some magic number
???
20 : Int32 Header Length
24 : 00 padding?
String - Header string (Shdr)
String - Unknown (N)
00 padding? - 1 byte
String - Version (8.10)
String - SHA1 Signature, 20 bytes as hex
Int32 - Data Section Length
00 padding? - 1 byte
String - Data Header (Sdata)
String - Data Value (zlib data. String values starting at 20 bytes in)

A String in the data section above is a byte value containing the string length followed by the string.

Parsing the cookie above produces the following values:

Full Length: 169
Magic Number: 16909060
Header Full Length: 44
Header String: Shdr
Unknown field N
Version: 8.10
Hash length is 20
Signature: 8423d1f254c03be8ada2e35f9e763f5b1c4d2bb
Data Length: 105
Data Header: Sdata
Data Value: ZZZUC826024
Data Value: ENG
Data Value: PSFT_CS
Data Value: 2015-09-25-18.43.15.553453

A Simple Parser

Here's a parser which I wrote in PHP. It will correctly detect the endianness of the values and read the binary properly. It also checks the hash against some default passwords.

<phorkie>https://phorkie.leo.home.steamr.com/11/embed</phorkie>

Signature Generation

According to Oracle's documentation, the SHA1 signature is generated using:

SHA1_Hash ( UserID + Lang + Date Time issued + Issuing System + Local Node Pswd )

Basically, the first 4 values which are given as part of the PS_TOKEN value (acting as the salt) is hashed with the node password in order to create a signature. This is then used on subsequent requests to the server to verify the person's identity. Since the salt and the hash is known, an offline brute force attack can be done in order to find the node password.

Cracking The Node Password

Since I can't figure out how to get John to crack a SHA1 hash with a prefixed string, I modified the parser script I wrote in PHP to read passwords through stdin to test.

What I'm unsure at this point is how PeopleSoft hashes the values to generate the signature. The string values I read from the PS_TOKEN cookie appears to have null values inserted between each ASCII character which almost seems to hint that the string is encoded in UTF-8.

At the moment, I hash the guess three times: Once with the null bytes before each ASCII character, one after each ASCII character, and one without any null bytes.

See Also