Privilege Escalation from Improper Access Control [Medium] — $700
Disclaimer: This writeup is heavily redacted due to the company’s policy on disclosing reports. Don’t forget to read my previous Bug Bounty Writeup — Stored XSS on Product Description [HIGH] — $400. Thank you for your time!
Within a web application, user roles are often established in order to correctly restrict resources accordingly. This translates to real-life company hierarchy where for example, a manager might be allowed to decide/perform monetary actions, but an entry-level staff couldn’t. In some web applications, different user roles are granted what is called Privilege. This helps companies to not only organize job responsibilities but to prevent unauthorized employees from accessing restricted resources. In this article, I will be discussing how I was able to leverage an Improper Access Control Vulnerability to a Privilege Escalation Vulnerability on one of the most popular ride-hailing companies in Asia, Company X (REDACTED).
What is Improper Access Control?
In order to fully understand the vulnerability, it is essential to understand what is Improper Access Control. According to cwe.mitre.org, an Improper Access Control is a vulnerability where a web application does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In the context of user roles, this simply means that different roles should have a set of permissions tailored or exclusive to the role itself, and in no way should other roles be able to access it.
The Journey to $$$
More complex, more mistakes. More mistakes, more vulnerabilities. Choosing a bug bounty with a complex web application has become one of my top priorities. Especially having multiple user roles defined, misconfiguration happens much more frequently on a complex web application rather than a simple one. This will provide pentesters with additional attack surfaces to test. Since this article is about improper access control and privilege escalation vulnerability, I will skip most of my early rituals after selecting a bug bounty program.
When testing for privileges, identifying different user roles and its definition is the first thing we should do. In Company X, user roles are explicitly stated as the following:
- Company Admin
- Allowed to modify and access company’s settings
- Allowed to create, edit and delete groups
- Allowed to invite new members to any group
2. Group Admin
- Allowed to access and modify group resources
- Allowed to invite new members to their group as user or group admin
3. User
- Basic access to allocated resources
I highly recommend all of you to write this down in your note since we will be referring to the above during our pentest session.
After identifying the user roles along with its definition, we should start testing right away. The most efficient way for me is to start bottom-up. Create two accounts with User Privilege and Group Admin Privilege, then for every Group Admin exclusive actions, whether its accessing, modifying, creating, or deleting, we should use User Account’s credentials to test for Improper Access Control Vulnerability. Manually, we could just copy all of the credentials (Authorization Headers, Cookies, CSRF Token and etc.) and replace them on Group Admin’s request, but a tool recommended by Tomnomnom is Autorize by Barak Tawily. This tool is an extension on Burpsuite where it completely automates replacing user-defined values and report for possible vulnerabilities to us, good for testing IDOR too.
After carefully testing for User-to-GroupAdmin Privilege issues, everything seems to be configured well. I proceeded with the next level of privileges which is GroupAdmin-to-CompanyAdmin. According to my notes, Group Admins are only allowed to invite new members to their own group, therefore we should test for the inverse. What if we change the Group ID to other Group IDs which we are not an admin of. Surprisingly, the server replied with an HTTP Status Code 200, which means that our request was received and processed by the server. This means that I was able to invite new users as Group Admin on other groups without the permission of the Company Admin or the admin of the group.
After confirming the vulnerability through the newly invited user, I did not directly report it to Company X. Keep in mind that every vulnerability that you have discovered should be leveraged if possible. In this case, a leveraged scenario will be where I could invite other members as not only Group Admins but as Company Admins. At this point, I was out of luck, the server did not process my request, but it was worth the try. Since I was able to invite new users to other groups as Group Admins, this is considered a Privilege Escalation Vulnerability. I submitted the report to Company X through HackerOne and was rewarded with $700.
Tips
Testing for broken privileges has always been my favorite. Since the implementation and logic are pretty complex, developers tend to make more mistakes here. Here are a couple of things that I keep in mind when testing for broken privileges:
1. Identify different user roles along with its definition before start testing.
2. Test privileges systematically, bottom-to-top.
3. After discovering vulnerabilities, don’t forget to find leveraged scenarios before submitting.
4. To speed up the process of discovering vulnerabilities, use tools for automation.
Thank you once again for spending your time reading this write-up. Don’t forget to read my other write-up, Stored XSS on Product Description [HIGH] — $400, drop a clap and comment.
