From Information Disclosure to interesting Privilege Escalation

4 min readJun 24, 2021

The bug bounty program on which this vulnerability was discovered has not allowed for public disclosure. Therefore I will name the program REDACTED.com.

Summary:

In this web application (subdomain.REDACTED.com), users can create a money program for their own company.

I was able to find a cool information disclosure which leads me to be an admin of the application eventually.

Description:

After I logged into the application as a simple user, there were not many features that I could play with.

However, the one that got my attention was the “Edit Account” feature.

I Turned on my Burp Suite and caught the request after editing some fields in my profile, I saw the request was sent to the following endpoint: /ProgramManagerREDACTED/REDACTED/updateuser

The request method was “PUT” with many parameters, but what caught my eyes was “role_id” and “user_info_id”:

So the first thing I have done was to change the “role_id” parameter value from 1 to 2. However, the server response was “401 Unauthorized” :(

(Lets did not forget we still have the second parameter to play with, but let’s keep that one for later)

After a while of playing with the endpoint (“/ProgramManagerREDACTED/REDACTED/updateuser”), I removed the body request and the two last directories and changed the “PUT” request into “GET”. The response from the server was “200 OK”, and the response body was massive information about hidden endpoints:

The response body was pretty huge, so I decided to search for several keywords, such as admin, passwords, user, and more.

The “user” keyword led to an interesting endpoint: “/ProgramManagerREDACTED/userInfoDetailsEntities”.

Hitting that endpoint with a “GET” request got me amazed. The server response body contained huge leaks about every user on the web application (here I also understand that there are four role ids):

With this information leakage, I thought about submitting the vulnerability to BugCrowd, but something inside of me told me that there is more, so… I KEPT DIGGING AND TRIED HARDER :)

So I sent another request to that endpoint, but now I was using my “user_info_id” value for searching only for my user information (“/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}”).

I was able to see my user information in the server response — including “role_id” and “mail” (another thing that is important to say, mail was not introduced as cleartext, mail was some hash):

I decided to take the first request (“Edit Account”) with the same original request body, but changing the endpoint to the one I just found (“/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}”), so I sent a “PUT” request, with changing the “role_id” parameter value to “4” and the “mail” parameter value to hash mail.

My “Burp Suite” was not responding, so I thought to myself, there is nothing more that I can do. BUT, 5 seconds later, I got the response from the server with the status code of “200 OK”, and I realized that the role_id had been changed successfully; I WAS SHOCKED!