{"id":19888,"date":"2022-10-07T18:51:38","date_gmt":"2022-10-07T13:21:38","guid":{"rendered":"https:\/\/www.varutra.com\/?p=19888"},"modified":"2022-12-01T16:53:57","modified_gmt":"2022-12-01T11:23:57","slug":"access-control-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.varutra.com\/varutravrt3\/access-control-vulnerabilities\/","title":{"rendered":"Access Control Vulnerabilities"},"content":{"rendered":"

<\/p>\n

This blog aims to understand and demonstrate different access control vulnerabilities. The flow here will start with the theoretical explanation of what access control is and how different types of access controls are implemented. Then we will gradually move on to a practical demonstration of the exploitation of such vulnerabilities.<\/p>\n

So, first things first, what is access control? The term is self-explanatory; access control or limits the access of the requested resources for the user trying to access the same. So, access control determines whether the person trying to access a particular resource is allowed to access it or not.<\/p>\n

When coming to applications, Access control is implemented based on authentication and session management. Authentication is responsible for identifying whether the user is a legitimate one or not. And session management will analyze whether the same user makes consecutive requests.<\/p>\n

Vulnerabilities related to access control often have a critical impact depending on the nature. For example, such vulnerabilities are broken access control, privilege escalation, etc. In addition, designing and managing access controls is often a complex task.<\/p>\n

On the basis of the level of criticality of the functions being accessed and the user’s point of view, access controls can be classified into different types, as stated below.<\/p>\n

    \n
  1. Vertical Access Controls<\/li>\n
  2. Horizontal Access Controls<\/li>\n
  3. Context-Dependent Access Controls<\/li>\n<\/ol>\n

    Vertical Access Controls<\/strong><\/h2>\n

    They are responsible for restricting access to sensitive functionalities which are not available to other types of users. These types of controls are generally used for limiting access to admin functionalities from the non-administrative set of users.<\/p>\n

    Horizontal Access Controls<\/strong><\/h2>\n

    They are used when there is a requirement to restrict resource access to only specified users allowed to access those particular resources. For example, in any banking application, it should only allow the user to view his transactions but not for any other users.<\/p>\n

    Context-Dependent Access Controls<\/strong><\/h2>\n

    They are responsible for limiting access to resources and functionalities based on the application’s context and user activity.<\/p>\n

    When an attacker breaks these access controls, then this will lead to vulnerabilities related to authorization issues. There are different ways to break the access control implied upon the resources, and these ways are specific to the nature and context of the application and the functionalities being accessed.<\/p>\n

    Different types of broken access controls are in detail are we go further with this blog.<\/p>\n

      \n
    1. Vertical Privilege Escalation<\/li>\n
    2. Horizontal Privilege Escalation<\/li>\n
    3. IDOR (Insecure Direct Object Reference)<\/li>\n
    4. Access Control Vulnerabilities in a Multi-Step Process<\/li>\n
    5. Referrer-Based Access Control<\/li>\n
    6. Location-Based Access Control<\/li>\n<\/ol>\n

      Vertical Privilege Escalation<\/strong><\/h3>\n

      It is when a user can access functionality that they are not authorized to access in the first place. There is a number of ways that can lead to vertical privilege escalation. Some of these methods or possibilities will be explained here, along with a demo using some of the labs available online.<\/p>\n

      Unprotected Functionality<\/strong>:<\/h4>\n

      Basically, privilege escalations arise when an application does not impose any protection over any sensitive or critical functionality.<\/p>\n

      A simple example for this scenario will be any non-administrative or average user accessing a sensitive admin functionality like “delete user.”<\/p>\n

      There are different ways an average user can try to do the same. A user might try to access (force browse) the admin URL by directly browsing to that particular URL.<\/p>\n

      A question might arise here, how a normal will get that sensitive admin URL? Sometimes the URL can be predictable, or even in some cases, there is a change of disclosing such sensitive URL in the Robots.txt file. Even if the URL is unpredictable, someone can try to brute-force the URL using different wordlists available these days.<\/p>\n

      Parameter-Based Access Control Methods<\/strong>:<\/p>\n

      Sometimes applications use parameters for storing users’ access rights. Parameters such as hidden fields, cookies or preset query string, etc., are submitted so that, based on the value of parameters, access control decisions can be made by the applications. As access control decisions are made based on the submitted values of these parameters, this method can be very insecure because the value of these parameters can be easily manipulated.<\/p>\n

      Now we will see a demo of this type of access control and how to bypass the same. In this scenario, we will use the id parameter to get access to the admin functionality (delete User functionality) from a non-admin user, and we will use it to delete a user.<\/p>\n

      Step 1- Login using low-privileged user credentials. \"Fig<\/p>\n

      Fig 1.1: Login using low-privileged user credentials<\/strong><\/p>\n

      Step 2- There is an \u201cupdate email\u201d functionality. Enter an email and capture the update email request.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.2: Click on update email<\/strong><\/p>\n

      Step 3 – Send the captured request to Repeater.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.3: Send the request to the repeater<\/strong><\/p>\n

      Step 4 – Check the response. We can see that the current user role id is 1.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.4: Observe the response for the current user<\/strong><\/p>\n

      Step 5 – Now, in the request, manually add role id = 2 after the email parameter.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.5: Add the \u201crole id=2\u201d to the request<\/strong><\/p>\n

      Step 6 – As the role is changed, the request is redirected to the my-account page. Check the response in the browser.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.6: Observe the response<\/strong><\/p>\n

      Step 7 – Now, if we see that the Admin panel is also accessible, thus the lower privilege user is now able to access the admin functionalities leading to vertical privilege escalation.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.7: Low privileged user got the Admin access<\/strong><\/p>\n

      Step 8 – Now, the normal user is also able to delete another user, which is actually an admin functionality.<\/p>\n

      \"Fig<\/p>\n

      Fig 1.8: Click on the Delete module<\/strong><\/p>\n

      Step 9 – User is successfully deleted. \"Fig<\/p>\n

      Fig 1.9: User got deleted successfully<\/strong><\/p>\n

      Broken access control resulting from platform misconfiguration:<\/strong><\/h4>\n

      Access control can also be enforced at the platform layer. It can be done by restricting access to specific URLs and HTTP methods based on user roles.<\/p>\n

      For example: DENY: POST, \/admin\/deleteUser, managers<\/p>\n

      The above-shown syntax will restrict the access of POST methods and the \/admin\/deleteUser URL to the users in the manager group.<\/p>\n

      But this restriction can also be bypassed using some of the headers that are not proper in the configuration. If the application allows an alternative method for the same request, we can bypass the access control implemented on the platform layer. It is called method-based access control circumvention.<\/p>\n

      Horizontal Privilege Escalation<\/strong><\/h3>\n

      Here, in Horizontal privilege escalation, the user would be able to get access to the other same privileged user\u2019s data. For example, in any application, a user can see their own PII data, but in the case of horizontal privilege escalation, the user will be able to access other users\u2019 PII data as well.<\/p>\n

      In the same way as user access other same-level users\u2019 data, if they try and access the data of higher-level privileged user data, then it will be escalated from horizontal privilege escalation to vertical privilege escalation.<\/p>\n

      For example, if there is any \u201cid\u201d parameter in the request where data related to the user\u2019s account is being disclosed, then an attacker will try to modify that parameter and gain access to other users\u2019 data. Sometimes, this id parameter is made unpredictable so that the attacker will not be able to guess the same, but here even if it is unexpected, the attacker might get the id from elsewhere in the application where the ids are being disclosed. And also, sometimes, there is a chance that sensitive data like IDs and usernames are being disclosed in response to redirect pages.<\/p>\n

      Moving on to the demo of Horizontal Privilege escalation, we will try to get the API key of the same-level user.<\/p>\n

      Step 1 – Login using the normal user credentials. There is an API key on the \u201cMy account\u201d page.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.1: API key for the normal user<\/strong><\/p>\n

      Step 2 – There are many posts on the home page. Find the post written by the user \u201ccarlos\u201d and view that post.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.2: Click on view post<\/strong><\/p>\n

      Step 3 – Capture the request on burp and check the user id is being disclosed in the response.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.3: Capture the request and observe the response<\/strong><\/p>\n

      Step 4 – Now, navigate to the \u201cMy account\u201d page and capture the request.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.4: Click on My account<\/strong><\/p>\n

      Step 5 – Check that there is an \u201cid\u201d parameter in the request. \"Fig<\/p>\n

      Fig 2.5: Capture the request and observe the id<\/strong><\/p>\n

      Step 6 – Now change the existing value of the id parameter with the id of carlos, which we captured earlier in the response of the My account page.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.6: Change the id of carlos<\/strong><\/p>\n

      Step 7 – Here, we are able to see the API key of carlos, who is the same level privileged user. Thus, leading to horizontal privilege escalation.<\/p>\n

      \"Fig<\/p>\n

      Fig 2.7: API key of the carlos user<\/strong><\/p>\n

      Horizontal to Vertical Privilege Escalation<\/strong>:<\/h3>\n

      As stated earlier, horizontal privilege escalation can be converted into vertical privilege escalation by accessing the data of more privileged users. Let\u2019s take the above example whereby changing the id parameter was able to get access to other users\u2019 data. If the same way, by changing the id if he is able to access the administrator data, then this be a serious issue, and hence this will convert the horizontal privilege escalation into vertical privilege escalation. In the same way, if an attacker accesses the data, he might be able to access the functionalities of other users or even the admin as well.<\/p>\n

      To demonstrate this type of privilege escalation, we try to get the password of the administrator and will login into the admin account to delete a user named carlos.<\/p>\n

      Step 1 – Login using the low privileged user credentials.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.1: Login as low privileged user<\/strong><\/p>\n

      Step 2 – On the My Account page, we can see that there is an update email and update password functionalities. The Password field is prefilled and masked.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.2: Click on update password<\/strong><\/p>\n

      Step 3 – Capture the above request and send it to Repeater.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.3: Capture the request and send it to the repeater<\/strong><\/p>\n

      Step 4 – Observe the response. The password of the current user is disclosed in the response.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.4: Password of the current user is disclosed<\/strong><\/p>\n

      Step 5 – In horizontal privilege escalation, we were replacing the id value with the same level user. Now, to escalate the same, we will change the id value to higher privilege user, i.e., administrator. We can see the administrator password in the response.<\/p>\n

      \"\"<\/p>\n

      Fig 3.5: Change the id to administrator<\/strong><\/p>\n

      Step 6 – Logout of the existing user login.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.6: Click on logout<\/strong><\/p>\n

      Step 7 – Login using the administrator credentials that we captured earlier.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.7: Login using admin credentials<\/strong><\/p>\n

      Step 8 – We have successfully logged into the administrator account. Now, navigate to the admin panel.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.8: Successfully logged into the admin console<\/strong><\/p>\n

      Step 9 – Delete the user named carlos.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.9: Click on delete<\/strong><\/p>\n

      Step 10 – User is successfully deleted.<\/p>\n

      \"Fig<\/p>\n

      Fig 3.10: User got deleted successfully<\/strong>\u00a0<\/strong><\/p>\n

      IDOR (Insecure Direct Object Reference)<\/strong><\/h3>\n

      IDOR is another sub-group of access control vulnerability; this vulnerability emerges when user-supplied input is used by the application to directly access the objects. An attacker might take advantage of the same and will modify the inputs to get direct unauthorized access. Although IDOR is an implement error from a pool of other implementation errors, it is more popular than the rest because of its listing in OWASP<\/a> Top Ten in the year 2007.<\/p>\n

      Direct reference in IDOR can be to anything like; it can be directly referenced to database objects or even to the static file, which is directly stored on the server-side filesystem.<\/p>\n

      Access Control Vulnerabilities In a Multi-Step Process<\/strong>:<\/h3>\n

      There are various functionalities in the application where the process is submitted in multiple steps. For example, there are many applications that use incremental forms to commit changes to users\u2019 data or even to access existing data. In the case of these incremental forms, sometimes the access controls are implemented in the initial step only. So, an attacker might try and alter the content in the final submission, which will ultimately save the final data altered that the attacker has provided.<\/p>\n

      Referrer-Based Access Control<\/strong>:<\/h3>\n

      Some of the applications use access controls that are based on the Referrer header of the HTTP request. The referrer header is basically used to indicate where the page is coming from, i.e., the Referrer header is always the previous URL of the page. In a few of the applications, the restriction to some critical or sensitive functionalities is based on the referrer header. For example, if a user wants to access a URL \u201c\/admin\/dashboard,\u201d then the application will first check the referrer header of the request and will validate whether the value of the referrer is \u201c\/admin\u201d or not. This way, the access is granted after validating the referrer of the request. In such a type of access control, the attacker will alter the referrer header and gain unauthorized access to such sensitive pages and functionalities.<\/p>\n

      Location-Based Access Control<\/strong>:<\/h3>\n

      These days websites are also enforcing access controls based on the geolocation of the user. In cases, whether banking applications or entertainment applications, where depending upon the state legislation, only the approved content and functionalities will be available to the user. These controls can be bypassed using web proxies, VPNs, or manipulation of the client-side geolocation mechanisms.<\/p>\n

      Mitigation for Access Control Vulnerabilities<\/strong>:<\/h2>\n
        \n
      1. Until and unless public access is required for any resource, by default, deny access to resources.<\/li>\n
      2. Mandatory define the access for each resource at the code level.<\/li>\n
      3. Test all the access controls properly to check whether they are working properly or if there are any loopholes in the implementation.<\/li>\n
      4. Use single application-wise access control wherever possible.<\/li>\n
      5. Don\u2019t rely only on obfuscation; implement a proper access control mechanism.<\/li>\n<\/ol>\n

         <\/p>\n

        Reference Links:<\/strong><\/h2>\n

        PortSwigger<\/p>\n

        InfoSec Write-ups<\/p>\n

         <\/p>\n

        Author:<\/p>\n

        Pralekya H.<\/strong><\/p>\n

        Attack & Pentest Dept.<\/p>","protected":false},"excerpt":{"rendered":"

        This blog aims to understand and demonstrate different access control vulnerabilities. The flow here will start with the theoretical explanation of what access control is…<\/p>\n","protected":false},"author":4,"featured_media":19921,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"inline_featured_image":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[270,277,261,1,278,263,272],"tags":[694,693,340],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t