The term “Privilege Escalation” describes a type of application security vulnerability in which a user has the ability to access information, features, or functionality that they are not entitled to in their role. It is only a concern in applications in which different classes of users (i.e. roles) are granted different permissions within the application, and represents the application’s failure to enforce those permissions properly.
While usually not the main aim of an attacker, privilege escalation is frequently used in preparation for a more specific attack, allowing intruders to deploy a malicious payload or execute malicious code in the targeted system. This means that whenever you detect or suspect privilege escalation, you also need to look for signs of other malicious activity. However, even without evidence of further attacks, any privilege escalation incident is an information security issue in itself, because someone could have gained unauthorized access to personal, confidential or otherwise sensitive data. In many cases, this will have to be reported internally or to the relevant authorities to ensure compliance.
To make matters worse, it can be hard to distinguish between routine and malicious activity to detect privilege escalation incidents. This is especially true for rogue users, who might legitimately perform malicious actions that compromise security. However, if you can quickly detect successful or attempted privilege escalation, you have a good chance of stopping an attack before the intruders can establish a foothold to launch their main attack.
Privilege escalation can be caused by a number of design or coding missteps:
Privilege Escalation is a category of security vulnerability that includes certain types of Insecure Direct Object References, and Open Forwards, specifically those that result in elevated access or permission.
For insights into detecting Privilege Escalation vulnerabilities, please review the article entitled “How To Test For Privilege Escalation“.
To learn about avoiding and/or fixing Privilege Escalation vulnerabilities, please see the article entitled “How To Prevent Privilege Escalation“.
Since Privilege Escalation vulnerabilities are the result of the failure to verify that the user has the authority to perform a requested action, prevention boils down to verifying permissions.
The application must know what role (or roles) the current user is associated with as well as what commands, actions, or requests they can submit. Note that this is a positive (whitelist) model that represents a “deny by default” design approach. Simply put, if a permission is not listed, then it is not available.
Application permissions can be thought of as a “role/permissions matrix”:
| Perm 1 | Perm 2 | … | Perm N | |
| Role 1 | X | |||
| Role 2 | X | |||
| : | ||||
| Role N | X |
Where each role represents a “class” of user enjoying a common set of permissions, and each permission represents a potential command, request, or action that a user might potentially initiate. The presence of an ‘X’ would indicate the role enjoys the permission whereas the absence of an ‘X’ would indicate the absence of that permission.
The above “role/permissions matrix” would be accompanied by a mapping of user accounts to roles (i.e. a users/roles matrix):
| Role 1 | Role 2 | … | Role N | |
| User 1 | X | |||
| User 2 | X | |||
| : | ||||
| User N | X |
Where each user is identified as being associated with one or more roles.
Now when a user submits a command, request, or action to the application, the application need only check whether the permission is granted for one of the roles associated with that user.
Even with properly implemented permissions checking, it is still possible to “drop the ball” in other ways. Clearly, the role/permissions matrix and user/roles matrix should be configurable outside the application and stored in a secure manner with role-based access control. The insecure storage of the role. permission, or user information used by the application can render permissions checking a moot point. Also, any misconfiguration of that same information can lead to Privilege Escalation, even if the application itself is properly checking permissions.
Source: Wikipedia, Sciencedirect, NIST
Are you looking to break into the exciting field of cybersecurity? Join our 5-day CompTIA Security+ Bootcamp Training and build your cybersecurity knowledge and skills.
Or
Become a certified ethical hacker! Our 5-day CEH Bootcamp is unlike other strictly theoretical training, you will be immersed in interactive sessions with hands-on labs after each topic. You can explore your newly gained knowledge right away in your classroom by pentesting, hacking and securing your own systems.