How I leveraged XSS to make Privilege Escalation to be Super Admin!
Hi, I’m Asem Eleraky -aka Melotover- and today I will show you how I could leverage an XSS vulnerability using XHR request to make the attacker be a Super Admin on the victim account!
First of all, This was a private program, so I will refer to it with example.com.
Let me tell you how I found the Reflected XSS vulnerability first.
Finding The XSS:
When I do my recon I usually check the out of scope domains and see if it has any relation to the in-scope stuff, so when I start to navigate a subdomain called community.example.com, I found a login button that will redirect the user to login in the main domain first which is in-scope, and then redirect him back to this subdomain, checked the link in my browser!
So now we have a parameter called referer that have a value of a URL,
So as usual I tried to do two things:
- Tried to exploit SSRF, but it was redirecting me to my localhost, tried with some SSRF payloads, and no result!
- Tried to find Open Redirect, and if it worked fine, I usually check if I can leverage it to Reflected XSS, and this way worked with me!
Good, Now we have P3 severity vulnerability, but when I found XSS affects the main domain of any application, I usually search for further exploitation so I can raise the severity, get more points, money, knowledge, and searching to learn something new!
Check Possible Functions:
And here is what I found:
- Change the user email function without asking the user for the current password which is great right?!
Yes, but it needs the user to visit the confirmation link that will be sent to the email! ,,, I think it could be exploitable but the PoC will be more complex so let it be our last choice!
- A function that can send an invitation to any user to add him to the same account as a restricted privileged user and an option for a Super admin privileged user! ,,, Nooooice one! let’s do it!
Checking the Request:
By checking the request for adding a Super admin privileged user, I found that I should be aware of three important things that should be in the request:
The request should have:
- The GET parameter PID of the current user!
- There is a X-Example-CSRF header with a CSRF value!
- The request body is a JSON format that contains the email we want to send the invitation to with the right role.
So our exploit should be like make a form that sends the post request to add our email and this request contains the Pid number of the victim user that we don’t have and the CSRF value and again we don’t have it!
And the main problem here that the request is a JSON format and the HTML form can not do it for us! even adding headers!
I looked deeply at the request again and found that the cookie parameters have very useful information like our Pid number in the USER_ID parameter and the CSRF value in example-csrf cookie parameter!
Now the exploit will be just to send this link to the victim!
And that’s it!
09 Feb: Submitted.
11 Feb: Triaged as P2 Severity.
12 Feb: Bounty Rewarded.
Thanks for reading my first write-up in my bug bounty hunting journey!
I hope you enjoyed reading!
I will be very happy if you have any feedback!