🏷infosec

Access control vulnerabilities and privilege escalation @WebSecAcademy Lab Notes

September 12, 2020

This is just a draft, and it will be refined over time.

What is access control?

access control = authorization

In the context of web applications:

Authentication, its like when you log in to the Steam using your user credentials.
Session management, basically it is there to make sure that your interactions with the Steam server are safe and sound.
Access control, its like which games your user account has access to (obviously the ones you paid for).

Categories of access control

Vertical access controls - good for separation of duties and least privilege (admin vs user)
Horizontal access controls - its like you can view the transaction details for the games that were bought for your user account but not for any other user account.
Context-dependent access controls which prevent a user performing actions in the wrong order. For example, a retail website might prevent users from modifying the contents of their shopping cart after they have made payment.

Examples of broken access controls

Broken access control vulnerabilities exist when the above is violated.

Vertical privilege escalation

The simplest example would be a non-admin user accessing /admin page.

Unprotected functionality

In some cases, the administrative URL might be disclosed in other locations, such as the robots.txt file.

An attacker may be able to use a wordlist to brute-force the location of the sensitive functionality.

In some cases, sensitive functionality is not robustly protected but is concealed by giving it a less predictable URL: so called security by obscurity.

Parameter-based access control approach (such as storing the information in a user-controllable location, such as a hidden field, cookie, or preset query string parameter) is fundamentally insecure, because the values for the parameters can easily be altered by the user.

I actually had issue with Burp Suite in my Kali VM, while doing the lab "URL-based access control can be circumvented". Each time I was trying to add a special HTTP header X-Original-URL to my request the Repeater would not display any result back from the server. So I used Postman as a workaround to construct my HTTP requests.

what I learned about X-Original-URL

Some applications enforce access controls at the platform layer by restricting access to specific URLs and HTTP methods based on the user's role.

Some application frameworks support various non-standard HTTP headers that can be used to override the URL in the original request, such as X-Original-URL and X-Rewrite-URL. If a web site uses rigorous front-end controls to restrict access based on URL, but the application's backend allows the URL to be overridden via specially-crafted request header, then it might be possible to bypass the access controls, for example using a request like the following:

GET / HTTP/1.1

X-Original-URL: /admin

...

You can also experiment by alternating between the HTTP methods like GET and POST and see how the application responds.

A vulnerable application can restrict the request POST /admin-roles?username=wiener&action=upgrade and server responds 401 UNAUTHORIZED, however if you change POST to GET it might slip in your favour.

Horizontal privilege escalation

If your colleague can see your payroll records instead of his own only - that's an example of Horizontal privilege escalation.

Horizontal privilege escalation attacks may use similar types of exploit methods to vertical privilege escalation.

So far most of the labs for this section are about figuring out how to alter the request urls and HTTP request headers in order to avoid access control restrictions, as well as where to look for potential disclosures of sensitive information which you might use for successful attack.

For example, https://insecure-website.com/myaccount?id=456 and you might guess the id and thus get access to someone else's account. And in case if the user ids aren't easily guessable, such as GUIDs, you might want to look for GUIDs belonging to other users might be disclosed elsewhere in the application where users are referenced, such as user messages or reviews.

Or lets say the application redirects you to the login page after detecting that you've been trying to access the resource you aren't supposed to, some sensitive data could even be disclosed within the response containing the redirect.

Horizontal to vertical privilege escalation

Its basically when an attacker gets access to administrative account.

The LAB: Logged in with given credentials wiener:peter Clicked on nav button "My Account" and observed the url https://..web-security-academy.net/my-account?id=wiener Altered the url to id=admin, got access to admin's "My Account" page. To reveal the masked pre-filled password changed the html input field's property type from "password" to "text" Use the password to login as admin and delete carlos :D

Location-based access control can be bypassed using web proxy, VPN or by manipulating client-side geolocation mechanisms.

Referer-based access control, as you guessed depends on checking referer when accessing certain functionality like subpages - vulnerable approach, as referer header can be altered by an attacker.

Access control vulnerabilities in multi-step processes

Many web sites implement important functions over a series of steps. This is often done when a variety of inputs or options need to be captured, or when the user needs to review and confirm details before the action is performed. For example, administrative function to update user details might involve the following steps:

Load form containing details for a specific user.
Submit changes.
Review the changes and confirm.

Sometimes, a web site will implement rigorous access controls over some of these steps, but ignore others. For example, suppose access controls are correctly applied to the first and second steps, but not to the third step. Effectively, the web site assumes that a user will only reach step 3 if they have already completed the first steps, which are properly controlled. Here, an attacker can gain unauthorized access to the function by skipping the first two steps and directly submitting the request for the third step with the required parameters.

How to prevent access control vulnerabilities

Access control vulnerabilities can generally be prevented by taking a defense-in-depth approach and applying the following principles:

Never rely on obfuscation alone for access control.

Unless a resource is intended to be publicly accessible, deny access by default.

Wherever possible, use a single application-wide mechanism for enforcing access controls.

At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.

Thoroughly audit and test access controls to ensure they are working as designed.