Vertical PrivEsc

If suppose a normal user can gain access to an admin page, where they can delete user accounts, then this is vertical privilege escalation.

Unprotected Functionality

https://example.com/admin

Do check the /robots.txt for some Disallowed endpoints

But nowadays, they've made the admin panel less predictable for an attacker to guess, but still he can bruteforce directories but that is time taking process, instead have a look in the page's source or any JS files, so that any juicy endpoints can be revealed.

var isAdmin = false;
if (isAdmin) {
var topLinksTag = document.getElementsByClassName("top-links")[0];
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', '/admin-9z0n38');
adminPanelTag.innerText = 'Admin panel';
topLinksTag.append(adminPanelTag);
var pTag = document.createElement('p');
pTag.innerText = '|';
topLinksTag.appendChild(pTag);
}

Parameter-based access control methods

Some backend what they do is => At the time of login, depending on what role the user logs in. The application stores the information in a user-controllable location. The vuln arises when we try to tamper it.

https://example.com/login/home.jsp?admin=true

https://example.com/login/home.jsp?role=1

Once when we intercept our login request over the application though burpsuite, make sure we get back the response from the server and we'll have to intercept it [Enable response interception].

PortSwigger Exercises

User roleid can be modified using burpsuite by explicitly adding the "roleid=2" parameter in the JSON Context separating it by adding a ,

PortSwigger Exercises

Broken Access Control from Misconfigs

Some backends implements access controls on the application layer by restricting access to specific URL's and HTTP methods based on user's role.

DENY: POST, /admin/deleteUser, managers

The above rule restricts an entry of POST request for the URL /admin/deleteUser and users in the managers group.

Some backend frameworks supports various non-standard HTTP headers that can be used to override the URL in the original request.

X-Original-URL and X-Rewrite-URL

URL-based access control can be circumvented

PortSwigger Exercises

When we try to access the /admin panel it restricts us by saying Access Denied in a plane text manner which eventually means it's given out by the front-end.

Inspecting that particular GET request by sending it to the repeater, We see the same message Access Denied. Now trying only / gives a 200 status, Adding the non-standard HTTP header X-Original-URL in the request body as /invalid, which gives us 302 saying not found. Which confirms we can override the URL in the request.

Now changing the /invalid to /admin gives us 200, and now our goal is to delete the carlos user so further changing it to /admin/delete gives us 200.

But still our goal isn't achieved, we still dint delete the user. All we did is, we just broke the access control and we could access the admin page.

If suppose we had admin access and we delete the carlos user account, our URL will simply look like

https://example.com/admin/delete?username=carlos

We could access the /admin/delete explicitly in the message body by using non-standard HTTP method X-Original-URL.

But now to delete the carlos user we have to enter his username in the URL ?username=carlos

Method-Based access control can be circumvented

This is an alternative attack where when we try to the change the HTTP method used in the request, the front-end controls above restrict access based on the URL and HTTP method.

The attacker can use the GET or any other request to perform actions on a restricted URL.

PortSwigger Exercises

Logging in using the admin credentials, we can upgrade any user to ADMIN privileges.

Upgrade any user, intercept that request and send it to the repeater, open a new session with a normal user's credentials. Intercept that and send it to the repeater.

Now we got two tabs opened in the repeater section - one is from the admin and other is a normal user.

Copy paste the session id from the GET request [ normal user] in the POST request of the admin-roles, when we try to forward it - we get an Unauthorized message.

Tampering the Request Method as POSTX - still gives us an error missing parameter.

When we try changing the Request Method to GET - we can see the admin user's name, when we try tampering it to our normal user's name and forward the request, gives us 200 .