Access control vulnerability (part 4)

Tram Ho

V. Some other access control vulnerabilities

1. Multi-Step Access Control Vulnerability

Consider the steps in a system that processes a user’s request to change account information:

  • Step 1. Receive the modification information submitted by the user.
  • Step 2. Perform an interaction with the database to modify the information.
  • Step 3. Check and confirm again.

In each step, if the control of access from users is not tight, an attacker can take advantage of this feature to skip some steps to perform malicious purposes. For example, skip step 1, 2 directly access the system in step 3.

Lab analysis Multi-step process with no access control on one step

The lab description assumes that we already have an account with administrator privileges of administrator:admin . The admin page contains a multi-step process of making user role changes. We can collect how the admin page works with the administrator account. We are also provided with a valid wiener:peter account, the task is to exploit an access control vulnerability to climb the wiener account to admin rights.

Log in with the account administrator:admin , at the Admin panel page contains the function to upgrade the user role. Perform an upgrade of the carlos user role and observe the history of requests and responses in the HTTP History in Burp Suite.

Upgrade user carlos :

Confirm upgrade:

User is successfully upgraded to admin role:

Observing the history in HTTP History :

First, send to the path /admin-roles two parameters username=carlos&action=upgrade via the POST method including the username and the upgrade operation:

Next, confirm the upgrade operation, adding the confirmed=true parameter:

Open a new incognito browser, log in with the account wiener:peter . With the information in place, we can use the wiener account to send the username=wiener&action=upgrade parameter to the /admin-roles path using the POST method, try the upgrade function for normal users?

However, getting “Unauthorized” message. We know that the user role change function works in two steps. Therefore, try to skip the first step (the system is able to perform user authentication at this step), directly sending the parameters action=upgrade&confirmed=true&username=wiener using the POST method to /admin-roles :

Status code returns 302 Found . That means we have successfully upgraded the wiener user to administrator role!

2. Access Control Vulnerability Exploited Through the Referer header header

An HTTP referer (from the accidentally misspelled word “referrer”) is an HTTP header field that identifies the address of the web page (i.e. URI or IRI) associated with the requested resource. By checking the referrer page, the new site can see where the request originated. For example, when a user clicks on a link in a web browser, the browser sends a request to the server hosting the destination web page. That request includes a referer field, which indicates the last page the user used (the page on which they clicked the link). Attribution of transitions is used to allow websites and web servers to determine where people are accessing them from, for advertising or statistical purposes.

Let’s recall situations where the request was to delete the carlos user account. First we will need to access the path to /admin which is the admin page, and then we will continue to access the path that has the function to delete the user account is /admin/delete and send the required username parameter Delete the account. Referer header access control vulnerability can occur when a user accesses /admin/delete , the system checks the Referer header value to see if the user is coming from the source path of /admin or not. if true, will authenticate the trust and pass the request. Since an attacker can change the Referer header value, this mechanism of action is really dangerous!

Referer-based access control lab analysis

The lab description says the site checks the Referer header information to authenticate the user. We are provided with an administrator role account administrator:admin to collect links as well as information related to the user role upgrade function. We are also provided with a normal valid account wiener:peter , the task to exploit the above vulnerability is to climb the wiener account to administrator privileges.

Log in with the administrator account administrator:admin , access the Admin panel option, which contains the user account upgrade function.

Perform an upgrade of the carlos account to admin rights and observe the request:

The request sends to the path /admin-roles the parameters username=carlos&action=upgrade using the GET method. Also notice the Referer header.

Change the source URL in the Referer header to any path and observe the response:

Received “Unauthorized” message. This proves that the system exists a mechanism to authenticate the user’s identity through the Referer header, in which the user must send an account upgrade request from the /admin path.

Login with the account wiener:peter , send to /admin-roles the parameters username=wiener&action=upgrade using the GET method, add the Referer header with the value https://0aed00f6031ed0b7c0c86a80009c008c.web-security-academy.net/admin :

Status code returns 302 Found . That proves we have successfully upgraded the wiener role to admin!

References

Share the news now

Source : Viblo