How missing access control can make your application hacker-friendly?

POSTED ON MARCH 3, 2018

Welcome back my hacker friends. If you have already gone through the OWASP TOP 10 for 2017, you will find that Broken Access Control is in the 5th position on the list. In the recent penetration tests, our team at ENCIPHERS found a whole lot of vulnerabilities regarding broken access control. So in this post, I will be discussing the different fields where we look and how we proceed accordingly to get these type of bugs in the web application.

So first thing, what actually is Access Control?

Access control defines the type of permissions which are allowed for different types of users of an application. These users can be a normal user of an application, a person having high privileges like having the Right permissions of an application or the Administrator of the application who can do anything with the application. Now say, for example, you have the access to only a normal user but somehow you get access to any other’s user account or the access to an administrator’s account, this is what is called missing or broken access control. All the privilege escalation kind of vulnerabilities come under this kind of attack. If the user can get access to any other user’s account, then it is called a Horizontal privilege escalation while if he/she gets the access to a user with higher privileges like an admin’s account it is called a vertical privilege escalation.

Practical Examples:

So now, let’s see some of the findings we got in the previous pentests so you can have a better picture of this kind of vulnerability.

Example 1. A user with only view rights could delete workspaces, libraries, and channels which should only be available to the admin.The target here was an Ad selling company for TV and media. The first thing which is required to get this kind of vulnerabilities is to have two accounts. It will be better to have two user accounts to test for horizontal privilege escalation and one admin account to test for vertical privilege escalation. We were provided with all of these already.These were the steps I followed:
Invited a user with the Admin’s account.
Signed up and logged in the account and this user was automatically added to the team.
With the Admin account, we only gave the user account the VIEW rights, i.e. this user can’t delete or change anything which has been added by the admin and provided to only the team members but can, of course, make his own workspaces, libraries and channels like any other normal user account.
So the user can see the libraries, workspaces and channels and all the listings but can’t delete them because he doesn’t have any sufficient rights.
So what the user does is create his own library or workspace, delete it and capture the request in BurpSuite. This is how the request looks

DELETE /mediamanage/group HTTP/1.1
Host: http://www.xyz.com
‍User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0)
Gecko/20100101 Firefox/57.0Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Authorization: Bearer

eyJhbGciOiJIUzI1NiIsIn..[redacted]

Content-Length: 120
Cookie:session_guid=s%3A5glHGEGceeF8yiD..[redacted]
DNT: 1
Connection: close

{“team_guid”:”d41344be-f986-4d09-9077-1a2af33b692c”,”service_guid”:”1002″,”guid”:”f6181612-3582-4262-b8b0-03b8ba01a801″}

Now, if you see the request carefully, you will notice that in the post body parameters there is a team_uid which will be same for everyone in the team. The service_guid represents which service we are performing in the application like Deleting a library in this case and the main thing is the “guid” which is the id for the library or workspace.
The user needs to get the “guid” value of this library or workspace of which he is a part of. So what the user can do now is to select the library or workspace created by the admin and see the request in BurpSuite where you may get the “guid” value of that media.
Now, just replace the guid value and the library or workspace or channel got deleted from both the user’s and the admin’s account.
This was a critical issue of vertical privilege escalation which was marked as P1.
Example 2: Sensitive Information Leakage( A user with only View rights can see the details of the whole Team management system of the company which will reveal every detail that only the Admin should know)This was a pretty similar application like the previous one. Here the user with only view rights could see the whole team management system of the company along with their positions and email addresses.So to test for this:
We logged in with a normal user account in one browser and with an admin’s account in another browser.
This user was only provided VIEW rights. A user with VIEW rights can’t see the Admin Panel and yes it should be obvious.
So, we just pasted this link https://www.xyz.com/#/workspace/playbox/admin/teammanagement/ in the user’s account and BANZAI!! We were able to see the whole team management only available to Admin.
Now the thing to notice here is when we just tried for https://www.xyz.com/#workspace/playbox or https://www.xyz.com/#workspace/playbox/admin, the application did nothing but as soon as I pasted that link we could see the same panel as an Admin.
So, as a tester, you need to check each and every feature for broken access related vulnerabilities because most of the times, it’s not been tested completely.
Example 3: User with only VIEW Rights can send an invite to a new user who will then be automatically added to the Team with “EDIT” Rights.This was an extra step taken after the bug found in Example 2.Steps:
After doing all the steps as in Example 2, a user with only VIEW Rights can see the Admin panel of team management. Now there was also an option to Invite a User though it which should have been only available to the Admin.
Interestingly enough, when the invited user signed up for the account, he was automatically added to the team of which the user is a part of along with the “EDIT” rights which is a critical access flaw because not only the user added another user to the team created by Admin but that person was also given the EDIT rights.

So in this way you can find several access related flaws in an application. In bug bounties most probably you will be provided with a normal user account, so most of the times you will be testing if you can somehow get the account access of a different user. It’s always advisable to create two accounts and then cross-test them.
While capturing requests, you will come across many situations where there will something like an identifier or id. It can be in the post body parameters or in the URL itself. Changing of these identifier values can lead you to get account information which you should not have been given access in any case.

This is all for this post. We tried to give the most important practical findings in this post, s you could understand how this works in the real world instead of just testing on Webgoat or Mutillidae. Hope our findings will be somewhat useful to you in future penetration tests.Meanwhile, for further deep understanding, check out the OWASP guide on it and check out our video on Youtube here. If you will like to ask us anything or want us to add something more to this post, please comment below and help us make this post better. Until then, keep learning and Happy hacking.:)

How missing access control can make your application hacker-friendly?