The “?k” parameter looked a bit suspicious to me so I quickly copied it and pasted it on CyberChef to see if it's an encrypted string or not. To my surprise, it was an Encrypted+Compressed string

It was first Zlib-deflated and then the deflated string was Encrypted back using Hex. Thus the token

“789c0dc8610a80200c06d0bbec049bc9d26f870921834192a4ffa2bbd7fbf90a029e810c9adeea98a5753287a844e16555b1016150bfafc3cfbaf94eff2450e494a2e640f67ebc89137aade927d25a020ab2535ab4b5c9dc4fd1"

decrypts back to

“a:2:{s:9:”timestamp”;i:1614104013;s:10:”profile_id”;s:8:”40884692";}”

The decrypted string consists of two important variables “profile_id” and “timestamp”. I was very happy to see that, thinking I found the Gem. I immediately forged the token for my second account used it to changed the password.

Forged Token — 789c0dc8510a85201005d0bdcc0ac6f25da6eb62427806034992fe457bb7df93b9f0e9dc28c36be923d726c919107ec0aa40ea0c4a69f775f85976ffcb2746891a610693f44ebe171387

But I was totally wrong. The link was not valid.

Nothing comes this easy…right?

If you notice closely then you would notice that the original token and the forged token have a difference in length

The original token and the forged token had a difference of 32 characters. This was a huge problem as the server was not accepting any junk value in place of that 32 characters. Both the tokens were being decrypted to the same value i.e

“a:2:{s:9:”timestamp”;i:1614104013;s:10:”profile_id”;s:8:”40884692";}”.

This left me totally frustrated 😫 😫. I started searching more about Zlib Compression. I went to Reddit and posted my query and surprisingly my Inbox was flooded with numerous amazing blog posts and ideas on how to deal with the Zlib.

And after 2 hours of reading on the internet, I found out that Zlib includes an ADLER32 checksum if you use the Adler-32_Checksum() function after inflating you get BC89137A, notice that this checksum is present in the original token. In Zlib, everything after this checksum is not part of the compression stream and will therefore be ignored, this was the reason why both tokens give the same result even after a difference in length.

So now the challenge was to find the 32-bit string. As all the token-related work was happening on the client side I was pretty sure to find something in the JS files.

After few hours of looking in the JS file, I Found an endpoint “ /php / user ”. I decided to brute force the directory and finally found the endpoint “https://example.com/php/user/example/”, this endpoint had a string named “Transction_Token”, and indeed this was the last piece I was looking for.

Now it was time for putting everything together and exploiting it.

This attack needed to be precise as every time the page is refreshed the “Transaction _Token” changes. So I made a python script to automate the whole thing.

I generated the token for my second account and used it to change the password and IT WORKED!!!!

• If there is a token then there is a chance that it can be cracked.
• Manually read the JS file once as these contain very important information on working of the Web App
• Try asking on Reddit for technical details, it will surely surprise you, Also there people don't see your follower count before replying to you 😅 😉.

Trust your Gut Feeling And Always Go the Extra Mile 😇

Thanks a lot for reading. Share if you like it

You can find me on Twitter: mayank_pandey01