Hello everyone,
It’s been a while since I have written a blog post but since it’s end of year and this has been amazing year and I learned a lot from the cyber security community. I am grateful for the cyber security community out there, because of there awesome writeups/articles about the bugs they found I have learned a lot from them. So, I will try contributing a bit to it.
This writeup is about a user improper authentication issue which I found in one of my favorite private program
Technical Details
Let’s get right into it, so the main domain of the program target.com uses another subdomain api.target.com for the API requests. And this another subdomain api.target.com points to some other subdomain abc.api.target.com of the target.
Now based on what I understood they were checking if the user is authenticated or not on their api.target.com subdomain, if the user was authenticated then this subdomain api.target.com would have returned the authenticated user’s UUID and authenticated user’s email address then would have forwarded these data in the request headers to abc.api.target.com subdomain.
Just to clarify the main API subdomain abc.api.target.com which retrieves the data from database or performs any functions on the user’s account is getting only request headers containing the user’s UUID, user;s email ID which tells that subdomain to access this account and perform any function on this account. Basically, the attacker only needed a victim’s UUID and victim’s email to access or perform any action in that victim’s account.
How I found this issue
While hunting on the program, I wasn’t catching anything interesting. So I randomly started checking up on the open ports of API subdomain of target.com, and I found that this subdomain api.target.com was pointing to another subdomain abc.api.target.com
Then I thought of trying API calls directly on this abc.api.target.com instead of api.target.com with the session cookie. I was getting a missing header error, so I ran param miner on that endpoint and param miner found these X-User-Id and X-User-Email request headers. Then on trying up the user ID and user email in these headers, it returned the details of that user in the response.
But the bad thing was the attacker would require a victim’s UUID in order to exploit this issue. And I couldn’t find any such API endpoint which was leaking the UUIDs of the victims else this would have been Critical severity issue. But still this was rated as High severity and was resolved resulted in $1000 bounty.
Well this one of the interesting issue which I found in 2023.
I hope it was a good read for you.
Thank you all for reading!
Happy New Year!
