Privilege Escalation as a subcategory of Broken Access Controls

[fennellkyle]

Can we add Privilege Escalation as a subcategory of Broken Access Controls?
At our organization, priv esc more commonly manifests from access control vulns than authentication or session vulns.

For example: AuthZ and AuthN are handled centrally by 2 different services. An API doesn't properly implement AuthZ which allows a lower-priv user access to higher-priv data/operations. Clear case of Privilege Escalation by Broken Access Controls, that would more likely and inappropriately be triaged as Broken Authentication and Session Management > Privilege Escalation.

[TimmyBugcrowd]

Hi fennellkyle,

I agree with you partly, that PE and BAC are related however they are not the same and cannot be considered as a subcategory of one another because:

Broken access controls are security vulnerabilities that occur when an application fails to properly implement access control mechanisms. This could allow unauthorized users to access sensitive data, execute unauthorized actions, or modify system resources without appropriate permission.

Privilege escalation refers to a situation where an attacker is able to exploit a vulnerability in a system or an application to gain elevated access or permissions, typically beyond what they were initially granted. Meaning the attacker is not limited to one or two actions as in BAC.

Basically, PE deals with an attacker gaining elevated privileges or access beyond their initial permissions. While it can result from broken access controls, it is not limited to this cause.

Also, the root cause is not the same. PE occurs due to software bugs, misconfigurations, etc, while BAC occurs due to incorrect permissions settings, etc.

[TimmyBugcrowd]

P.S

AuthZ which allows a lower-priv user access to higher-priv data/operations

based on my comment you can see that what you've mentioned is a BAC issue.

[fennellkyle]

Hi Timmy,

Thanks for the comment.

On the VRT, Privilege Escalation is nested under Authentication and Session Management which is implying that Privilege Escalation is a consequence of bad AuthN.

I think we should add it as a subcategory of BAC as well, for when it is a consequence of bad AuthZ.

While sure, my first described scenario can be labeled with the BAC vrt when triaged, none of the subcategories are appropriate. This leads to many Researchers, Bugcrowd Triagers and Customers instead using the inappropriate Broken Authentication and Session Management > Privilege Escalation as the obvious choice.

PE occurs due to software bugs, misconfigurations, etc, while BAC occurs due to incorrect permissions settings, etc.

Not quite. BAC can commonly come from developers not properly coding in AuthZ on endpoints or an API holistically . I also think PE is appropriate as a label for any instance of being able to escalate your privileges, even if it's one or two operations. Maybe we can find a standard definition as I think that is a sticking point between our opinions.

Happy to discuss further, it's an important topic to clarify.

[p3t3rr4bb1t]

What do you define as a PE is key here. Is it using functions you are not entitled to ( to me that's an RBAC issue, so a Broken Access Control) or is it escalating your ENTIRE session privileges to a higher role (to me that's now a session management issue)? Reality is, what I have seen, PE are usually tied to a RBAC issue somewhere (e.g., adding yourself to a group, listing objects you are not supposed to, etc.) with the end state being a privilege escalation. I mean, you could also use a XSS to escalate your privileges, but the root cause is still an XSS. Perhaps this VRT should not even exist....

[TimmyBugcrowd]

Based on @p3t3rr4bb1t's comment, if you add PE as a sub-category of BAC, then XSS could also be considered as a sub-category of BAC, right?

The way I understand this is that this VRT entry:

Varies | Broken Authentication and Session Management | Privilege Escalation

can be chosen when you're able to completely change your privileges(Regular user -> Admin). If there is a situation where you can use SOME e.g Admin privileges but not ALL, then that's considered BAC which is this category:

Broken Access Control (BAC)

I do agree that the sub-categories are not appropriate and I think we can solve this problem by adding a new entry but without a subcategory at all because adding a subcategory called PE could confuse researchers with:

Varies | Broken Authentication and Session Management | Privilege Escalation

What are your thoughts? @fennellkyle @p3t3rr4bb1t

[p3t3rr4bb1t]

Well I'm going to stick with the fact that "Privilege Escalation" is an end state caused by some other technical root cause(s) (single bug or bug chains). I'd remove that subcategory completely, but this topic goes larger than the current discussion.. I'd be careful outlining end states in the VRT and would rather focus on the vulnerability technical root cause instead... there are so many ways to perform PE other than abusing roles misconfigurations, although RBAC misconfiguration is the most common cause I have seen. If we follow the end state logic, SQL injections can also lead to privilege escalations, and XSS, and RCE...

I mean if say a USER A with a role of "guest" or "low priv", can perform actions on some APIs that should be used by admins, that's an RBAC issue on the admin APIs no properly enforcing role permissions.

Frankly, if I was to refactor that category, I'd remove PE from broken session management, and add some additional variants to the BAC category to cover Role issues.

[fennellkyle]

Adding a new subcategory under BAC that describes the scenarios where privileged actions can be performed would be favorable. It doesn't have to be 'PE', if you want that to strictly represent complete role escalation vulnerabilities.

I'd be careful outlining end states in the VRT and would rather focus on the vulnerability technical root cause instead...

This I agree with. This helps the customer, at least, identify trends and areas to focus attention. Identifying how many 'PE' vulns we have is useless if it's not attributed to some cause.