Hello folks,
This blog focuses on the identification and exploitation of Broken Access Control vulnerability. We will be providing a detailed walkthrough of PortSwigger’s labs which you can access on the PortSwigger. We will be providing a detailed writeup covering this vulnerability in three categories. So in this blog, we will be covering the first one which is ‘Vertical Privilege Escalation’. Let’s understand Access Control and its vulnerabilities.

Access Control is a set of techniques, rules, and guidelines that define restrictions on what request or which user is authorized to access or perform specific actions on available resources. It’s all about making sure only the right people can access specific resources, like files or features on a computer, data center, or network. Broken Access Control is a vulnerability that allows an intruder to access or perform unauthorized actions on resources. If Access Control isn’t working properly, it means someone who shouldn’t be allowed to access something gets in anyway. This is a big problem because it can lead to unauthorized access or actions, like someone seeing private information they shouldn’t.

There are two types of access control mechanisms:
1. Vertical Access Control– This mechanism restricts the access of unauthorized users to sensitive functionalities within various resources based on the permission provided to each user. It is based on security policies like separation of duties and least privilege. For example, a regular user shouldn’t be able to do things only an admin should do.
2. Horizontal Access Control– This mechanism restricts a user’s access to sensitive resources/functionalities of other users at the same level. For example, you should only be able to look at your account details, not someone else’s.

To exploit these access control mechanisms, we can use the following techniques of broken access control vulnerability:
1. Vertical Privilege Escalation– If a regular user can access functionalities that they are not supposed to, it’s called vertical privilege escalation. For instance, if a non-admin user can get into a page meant only for admins and can change account settings for users, that’s vertical privilege escalation.
2. Horizontal Privilege Escalation– Horizontal privilege escalation happens when a user gains access to resources that belong to another user, rather than being limited to their resources of that type. For instance, if a user can view the shopping cart of other users in addition to their own, then it is possible due to horizontal privilege escalation.
As a penetration tester, it is very important to identify and remediate this vulnerability. So without any delay, let’s start our penetration testing process.

Lab-1 Unprotected admin functionality

In this lab, we will identify Vertical privilege escalation vulnerability on an application that fails to provide security measures for critical functionalities. We can read the lab description and then click on ‘Access the lab’. This lab can be performed without Burp Suite as well.
To access the admin page, we need to know the URL of it. This URL can be available on the robots.txt file. Let’s try to check the robots.txt file.

We will find an entry for /administrator-panel. This is the URL using which we can access the admin page. Let’s change the URL to the same and access the page. We will find that we successfully accessed the admin panel where we have the privilege to delete the user from the website. To solve the lab, we have to delete the user carlos.

Once the user is deleted, the lab will be solved.

Lab-2 Unprotected admin functionality with unpredictable URL

In certain instances, sensitive functionality may be hidden by assigning it a less predictable URL. Nevertheless, concealing sensitive functionality in this manner does not effectively enforce access control, as users may still uncover the unpredictable URL through various means. We can read the lab description and then click on ‘Access the lab’. This lab can be performed without Burp Suite as well.
To access the admin page, we require its URL. Although the URL might typically be found in the robots.txt file, which is absent on this website, alternative methods exist. One approach involves searching for the URL within the website’s source code or examining provided JavaScript files. Let’s proceed by accessing the webpage’s source code through the shortcut Ctrl + u.
Within the source code, we will find the URL for the admin panel.

Let’s try the URL and access the admin panel to delete the carlos user. Once the user is deleted, the lab will be solved.

Lab-3 User role controlled by request parameter

Some applications identify the user’s access rights or role upon logging in, subsequently storing this information in a location that the user can control, such as a cookie or within GET/POST request parameters. In this lab, we will identify a cookie parameter that might help us perform vertical privilege escalation. We can read the lab description and then click on ‘Access the lab’. This lab can be performed without Burp Suite as well.
If we try to access the /admin page, we will find that only the administrator has access to the admin panel. So in this situation, we have to find a parameter like a cookie that might help us become administrator user. We are provided with our account credentials so let’s log in as wiener user.
To access the cookie parameters, we need to press Ctrl + Shift + I to access the Inspect element. Now open the cookies section (Google Chrome/Brave browsers- Application tab and Firefox browsers- Storage tab). We will find a cookie with the name ‘Admin’ whose value must be set to false. We have to change the value to true. Once we refresh the page, we will find the admin panel where we can delete users. Here the permission to access the admin panel was dependent on the cookie parameter.

We can delete the user carlos to solve the lab.

Lab-4 User role can be modified in user profile

In this lab, we will perform vertical privilege escalation by identifying a request parameter that might help us change the current role of our logged-in user. We can read the lab description and then click on ‘Access the lab’. This lab requires the Burp Suite community edition.
If we try to access the /admin page, we will find that only the administrator has access to the admin panel. So in this situation, we have to find a parameter that might help us here. We are provided with our account credentials so let’s log in as wiener user.
On our account page, we will find an email change functionality that might help us here. Let’s change our email address to contact@cyberiumx.com and submit the request. We need to proxy the traffic through Burp Suite which will provide us with a POST request where the parameters are mentioned in JSON format. If we check the response of this POST request, we will find that there is a parameter name roleid which is set to 1.
Let’s take this request to the repeater. Now we have to see whether we can update our roleid with an email address. For this, we have to add another parameter in the body of the POST request and set the roleid value to 2 as follows:

{
“email”:”contactus@cyberiumx.com”,
“roleid”:2
}

After making the above changes, click on the Send button to confirm that our roleid is also getting updated.

We have successfully modified our role using which we can now access the admin panel at /admin. Using Burp Suite also, we can send a GET request to /admin page. In the response, we will find the complete URL to delete the carlos user. Finally, we can send a GET request to /admin/delete?username=carlos endpoint to delete carlos user.

Once the user is deleted, the lab will be solved.

Lab-5 URL-based access control can be circumvented

Some web applications use platform-level measures to control user’s access by restricting access to specific web addresses (URLs) and types of interactions (HTTP methods) based on the user’s assigned role. For this, an attacker can use some headers which are allowed by certain application frameworks. These HTTP headers are X-Original-URL and X-Rewrite-URL, which allow for modifying the original requested URL.
We can read the lab description and then click on ‘Access the lab’. This lab requires the Burp Suite community edition. If we try to visit /admin URL, we will find that we do not have access to the page. Let’s proxy the traffic through Burp Suite and send the GET request for /admin endpoint to repeater. On the repeater, add a new header as follows:

X-Original-URL: /admin

Also, we need to remove the /admin from the resource header. Now, try to send the request. This time we will find that we can access the admin panel by clicking on Render.

Now to delete the carlos user, we have to find the URL for it. In the response body, we will find the URL to delete the user. But if we supply the whole URL to the X-Original-URL header and send the request, we will find that the username parameter is not allowed as a GET request. We need to change the request method to POST and then add the following header:

X-Original-URL: /admin/delete

In the body of the POST request, mention the username parameter as follows:

username=carlos

Now send the request.

We will find a 302 response which confirms the carlos user has been deleted successfully.

Lab-6 Method-based access control can be circumvented

The access restrictions outlined earlier in this document are implemented on the front-end and are dependent on both the URL and the HTTP method used. Certain websites may allow various HTTP request methods for specific actions. If an attacker manages to utilize a method like GET (or any other) to execute actions on a restricted URL, they can circumvent the access controls set up at the platform level.
We can read the lab description and then click on ‘Access the lab’. This lab requires the Burp Suite community edition. First, we log in using the administrator credentials. Then, we navigate to the admin panel where we can promote a user named carlos.

After promoting carlos, we send the HTTP request to Burp Repeater. Next, we open a new private or incognito browser window and log in using non-administrator credentials. We attempt to re-promote carlos using the non-administrator account by copying the session cookie from that user into the existing Burp Repeater request. We notice that the response indicates “Unauthorized“.

Following that, we modify the method from POST to POSTX and observe that the response changes to “missing parameter“. We then convert the request to utilize the GET method by right-clicking and selecting “Change request method“. Finally, we changed the username parameter to our username and resend the request to observe the outcome.

We will find that wiener has been successfully promoted to the admin role. Hence, the lab is solved.

In this blog, we learned how to identify and exploit Vertical Privilege Escalation which is a type of Broken Access Control vulnerability. In the upcoming blog, we will explore Horizontal Privilege Escalation.
You can check out our other web application penetration testing blogs on our website.

Happy Pentesting!
Team CyberiumX