Hi y'all guys, I haven’t been writing for a long time as I focused more on bounties. Wanted to share with you one of the many bugs I found on one public program in H1. However, they don’t have public disclosure so I’ll redact the target.

Also, this gives an important takeaway, which we’ll see later.

So, approaching the target. Every time I logged in to the app, a call was made to a backup endpoint. Returning a user’s backup data. No cookies were used, only a token in the POST data. It looked like this: 1234-randomletters. Didn’t come to my mind any interesting attack surface here, I tried with another token, same length, etc. And skipped the endpoint and jumped right in using the app. It’s important to note that I had just decided to start hunting on that program, and in my process, I don’t go directly into exploitation, so I didn’t spend time trying to hijack the token, or using any other technique to bypass it. After using the app for a while and watching the flow via Burp’s Target window, I noticed the token was used to perform any action, it was the only authentication required. But again, that means nothing. So I decided to create another account, and see what changed. The first thing I saw is that the token looked like this: 2323-randomletters . While one of the other users I used before was like this one: 2323-otherrandomletters . Notice something? that 2323 was the same and it looked interesting. Why would It be the same? What I did was sending the request to the repeater, then In the token, I only put the 2323 and to my surprise, I was able to get the backup data for both users without the token. Only a random number. However, It was not a 4-digit, it was a 6-digit number. Meaning that a brute-force was an option, but not a practical one. So, to have a higher impact I needed to understand what was that and how to get it. Luckily, I have burp pro :) which enables me to search a specific word in the HTTP traffic history, so I searched for 2323 it and found out that it appeared in the response to a get request demanding the machineID for a given account. It returned the number I used to leak the backup data of any user. Then I thought I could use this as an app-wide authentication bypass as all the endpoints used that token. That would be a P1. Unfortunately for me, the only endpoint that was vulnerable to it was just this one. So I submitted it as a P3, and the report got triaged+awarded+resolved within 16hrs. I’d really like to disclose the program name as it’d be nice to mention the ones who are efficient and really mind about their security.

Timeline

reported on Nov 8th

triaged and rewarded on Nov 9th

resolved on Nov 9th

If you see a parameter on many different endpoints, and test one of them and see that the parameter isn’t vulnerable, test also the other endpoints, you never know if an endpoint was coded by another dev, or there is a minimal syntax issue, etc. Always test them all!

Thanks for reading, if you found this helpful share it with other Hunters. I recently opened a Twitter account: https://twitter.com/_hensis_, let’s connect!