Vertical privilege escalation

A web application including authentication usually allows the user access to various types of information. By the same token, several web applications provide advanced features that are assigned through different access levels.

This type vulnerability occurs when a user obtains access to more resources or features that they should’ve been granted to obtain based on the authorization scheme of the web application.

The consequential impact is that the user has more privileges than what was intended by the designer of the web application. The degree of escalation will depend on what privileges the attacker is authorized to possess and what privileges can be obtained after a successful attack.

We have two main scenarios:

• When it is possible to access to resources/features related to more privileged accounts the attack is called vertical privilege escalation.
• When it is possible to access resources with accounts having similar privileges then it is called horizontal privilege escalation.

This article is focused on vertical privilege escalation vulnerabilities.

For instance, imagine an investment web application where a user can invest his money buying company stocks, funds, bonds and/or indexes of a wide range different stock markets.

This type of application usually has at least three roles and hence, three levels of access:

• Standard user: with access to the current value of the assets and the ability to acquire/sell specific financial products. These users may choose the option that one financial expert could manage their assets on their behalf.
• Account manager: these managers should be able to buy or sell financial products with the goal of increasing the benefits of their customers. The managers will  only be allowed to access users within their group.
• Administrator: this role will have access to all the information within the web application. They will be in charge of assigning standard users into the various account managers group.

The potential impact from the business perspective may be critical. Worst case scenario can be a standard user would be able to have access to features limited to the administrators, such as assign their user to the administrators or account managers group. If this happens, the confidentiality and integrity will be compromised.

The following features will typically require administrative privileges:

• Creating user accounts
• Site design
• Configuration changes
• Data manipulation
• Assign users to manager´s groups

For example we can see different features reachable through these URL’s:

• https://example.es/manage_users.php
• https://example.es/admin/edit_layout.php
• https://example.es/manage

What features could be affected by this vulnerability?

In every part within the web application where a user can store information within the database, the user can also retrieve information or can delete information. These interactions with the database could be prone to this vulnerability, so it will be necessary to verify all these available functionalities.

In order to efficiently and properly accomplish this, the consultants must record the candidate features in a first phase. Next, they will attempt to access these features employing different accounts with different levels of access. This verification may require the modification of parameters and/or cookies as well.

This vulnerability commonly appears when a user may have access to the users administration function or within a feature that is able to generate reports containing information from several users. Sometimes it is possible to find this flaw in strange situations, such as detecting that all standard users are firstly assigned to the administrators group while a background task is re-assigning them into the standard users group.

Let’s see one example of the vulnerability.

Below can be observed a POST request that uses the Role parameter:

POST /example HTTP/1.1

Host: ***.net

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0)

Gecko/20100101 Firefox/16.0

Accept: */*

Accept-Language: en-gb,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest

Referer: https://***.net/901/Dossier/Subdossier?subdossierIndex=3

Content-Length: 392

Cookie: ... (omitted)

Pragma: no-cache

Cache-Control: no-cache

Role=Client&Bsn=&Geslacht=Man&Titel=&Voornaam=&Voorletters=IT&Tuss

envoegsel=&Achternaam=Test&*************=01-11-

1984&Straatnaam=&Huisnummer=&Toevoeging=&Postcode=&Woonplaats=&Lan

dID=1&************=&Polisnummer=&Emailadres=test%40mtest.nl&TelefoonnummerVast=&*************=&HerinneringenOntvan

genPerEmail=true&HerinneringenOntvangenPerEmail=false&Donorcodicil

By modifying the ‘Role’ parameter, the users could elevate their privileges to a different role. Enabling these users to access all the resources and functions that are accessible by that selected role, resulting in a vertical privilege escalation.

How to deal with these vulnerabilities?

First and foremost, it is vital to insist that the application should not trust in information sent from the client side (provided via input fields or through user’s browser). The authorization decisions should be made only on the server-side.

Furthermore, the application should implement an authorization scheme that categorizes and maintains full control about what information a user role is authorized to see. This system should be checked on the server side before granting access to the specific features.

Thank you for tuning in!