Access control vulnerability (part 2)

Tram Ho

III. Analyze and exploit vulnerabilities in vertical access controls

If a normal user has the ability to access functions that they are not supposed to have access to, we will call it a vulnerability in the form of vertical access controls. We can interpret the term “vertical” here to mean that along the access rights, the lower role has the ability to access the functionality of the higher role.

1. By changing the parameter values, normal users can access the admin page

Web applications often include different functions for accounts with different roles. Normally, the administrator account is the account with the highest permissions and can access all the features in the system. For normal users will not be allowed to access some advanced features such as viewing the database, performing other user account deletion, …

For example, a web application with an admin page function for an administrator account is accessed via a URL like this:

https://insecure-website.com/admin

Ordinary users can also know this link (accidentally guessed, or using some tools like Dirsearch, Gobusster, …). If the programmer does not set up reasonable access rights, leading to all users being able to access this path will have unpredictable consequences, because then everyone is an administrator!

Lab Analysis Unprotected admin functionality

This lab has a solidly unprotected admin admin page, we need to access and delete the carlos account.

One of the first things to do when pentesting a website is to find useful information related to the target. And one of the files that are often read first is robots.txt (This file is also included when scanning links). The robots.txt file is primarily used to manage crawler traffic to a website and is often used to hide a file from Google. Sometimes it also contains some useful information.

Read the site’s robots.txt file by adding /robots.txt after the URL:

The site restricts bots from crawling to the sensitive link /administrator-panel – which is the link to the admin admin page.

Go to /administrator-panel :

We see that the system does not do a good job of setting permissions for each user role, resulting in anyone having access to this path and performing an administrative role!

Just delete carlos account:

Some sites protect the path to the admin by not revealing it in the robots.txt file and naming the path in an unpredictable way, for example:

https://insecure-website.com/administrator-panel-somerandomcharacters_ah27ds7d

This way the attacker will not be able to use the path scanning tools to find this page. However, if the path is used in some code that will be visible to the user in the source code (e.g. Javascript), important information may still be disclosed to the user. Consider the following code:

How the above code works: Check if the user role is admin or not through the isAdmin variable value, if true, it will be created and displayed from the Admin panel on the interface – the path to the admin page. And accidentally also revealed this link to the user.

Lab Analysis Unprotected admin functionality with unpredictable URL

This lab has a solidly unprotected admin admin page. Although the path is named so that it cannot be scanned, it is exposed somewhere around the website, we need to access and delete the carlos account.

View the website source code by pressing Ctrl+U or right-clicking and clicking View page source :

Detects JavaScript code that works, revealing the path to the admin page is /admin-pwyhr4 .

Go to the admin page:

We see that the system does not do a good job of setting permissions for each user role, resulting in anyone having access to this path and performing an administrative role!

Just delete carlos account:

Some websites do check the user’s administrative role through parameters passed to the system. For example:

However, attackers can modify these parameters through tools, such as with Burp Suite.

Lab analysis User role controlled by request parameter

The title description shows the admin page at /admin and the system defines the admin role via a parameter in the cookie. We need to elevate the user wiener:peter to admin and delete the carlos account.

Log in with the account wiener:peter , observe the request via Burp Suite we have:

The system determines the user’s administrative role through the Admin parameter in the Cookie. We can modify this value to Admin=true :

Access to /admin :

Delete carlos account:

You can view it directly on the web interface by right-clicking, selecting Show response in browser :

In addition, we consider a similar case where an attacker can change the parameters passed to the system that determine the administrative role of a user account.

Analysis lab User role can be modified in user profile

The post description says the admin page is at /admin and it only allows access for users with roleid value equal to 2. We need to elevate the user wiener:peter to admin and delete the carlos account.

Log in with the account wiener:peter , observe the request via Burp Suite we have:

Unlike the previous lab, the request does not contain specific parameters that define the administrator role.

Also unable to access the admin page:

Since the topic says that the system uses the roleid parameter to define the user role, we need to find a way to “attach” this value to the system with the wiener account. Naturally, we will choose when to send at login time.

Go back to the login request, send it to the Repeater (Ctrl+R), add the roleid=2 parameter after the username and password parameters:

Select Follow redirection :

And… we still can’t become admins. That is, the roleid value needs to be passed elsewhere. Go on to try some transmissions:

  • Cast directly in the URL (GET method):

  • Pass in Cookie:

All failed! And only the Update email function we have not used yet. Make an update to a new email and observe the request:

Ohhhh, do you see what I see! Emails are POSTed to the system in JSON format (in simple terms, the data is formatted in key:value pairs, learn more at https://en.wikipedia.org/wiki/JSON ). And the returned data is also in JSON format and contains the roleid:1 value pair. Our wish is to change the other roleid value to 2 . Simply “plug” it into the email value and send it to the system!

Successful! Follow redirection we have:

Go to the admin page:

Delete carlos account:

You can view it directly on the web interface by right-clicking, selecting Show response in browser :

2. Some other ways to allow users to access the admin page

Some websites use frameworks that allow dangerous HTTP headers to act like X-Original-URL, X-Rewrite-URL . These headers allow the access URL to be overwritten, thereby bypassing the protection from ordinary users accessing higher system functions.

For example:

When the system receives this request, by accepting the X-Original-URL header, it will overwrite and cause the user to gain unauthorized access to /administrater/some_sensitive_path .

Some web frameworks affected by this vulnerability include: Symfony 2.7.0 to 2.7.48, 2.8.0 to 2.8.43, 3.3.0 to 3.3.17, 3.4.0 to 3.4.13, 4.0.0 to 4.0.13 and 4.1.0 to 4.1.2 , zend-diactoros 1.8.4 and earlier, zend-http 2.8.1 and earlier, zend-feed 2.10.3 and earlier.

Lab analysis URL-based access control can be circumvented

Describe a scenario that allows a site to have an administrator page with the path /admin. The front-end system has implemented to prevent unauthorized access to this path, however, the back-end server uses a framework that allows the X-Original-URL header to work. Our task is to exploit this vulnerability, access the system administration page and delete the account of user carlos .

After accessing the website, we notice that the home interface has the words Admin Panel leading to the admin page at /admin .

When accessing we receive an Access denied error message.

In terms of the interface returned when we access /admin , try to compare it with some of the labs we have analyzed, for example lab User role controlled by request parameter

Obviously, the return interface is completely different, we will analyze it more closely through the response interface in Burp Suite, with the User role controlled by request parameter lab, the Response returns as follows:

For the current lab URL-based access control can be circumvented , the Response returned via Burp Suite (when accessing /admin ):

With two different status codes:

  • 401 Unauthorized : Unauthenticated user.
  • 403 Forbidden : User is not authorized.

From these indications we can predict that the Access denied response in this lab may be coming from the front-end system.

Check if some headers are allowed or not. X-Original-URL Header:

With the return status code 404 Not Found , this proves that the back-end system is processing the content search request to our /some_path , which means that the system allows the X-Original-URL header to work. .

Do overwrite the URL content with the X-Original-URL header:

The status code returns 200 OK , indicating that we have successfully accessed the admin page.

Perform deletion of the carlos user account:

Besides, when the system does not check some HTTP Request methods from the user, it can also bring some risks. A method is considered safe – safe when it does not change the “sate” state of the server. In other words, safe is read-only without changing anything.

Lab analysis Method-based access control can be circumvented

We are provided with an account with an administrator role of administrator:admin that helps collect useful information related to upgrading an account to administrator rights. We need to exploit a vulnerability in the HTTP reuqest method to upgrade the wiener:peter account to admin rights.

Log in with the account administrator:admin and look at the Admin panel:

The feature allows us to upgrade or downgrade the role of any user. Try upgrading the role of user carlos and observe the request in Burp Suite:

The system calls the path /admin-roles and passes two parameters username=carlos&action=upgrade using the POST method. Note the value at the header Cookie session=gyIyALKqa3VgPiAYZobuGlCHj3SUt1yN used to authenticate the user.

Open an incognito browser, log in with the account wiener:peter to get the current view of wiener :

Replace the session value of the wiener with the session in the request upgrade role:

We get the “Unauthorized” message. Since the system does not check for HTTP request methods from users, we can bypass this protection by using the HTTP request method POSTX :

We see that the system returns the message “Missing parameter ‘username'”, which proves that we have passed the session authentication mechanism. Add the username parameter sent to the system using the HTTP request method GET and replace the username=wiener value:

wiener account has been upgraded successfully!

References

Share the news now

Source : Viblo