How To Exploit Least Privilege Vulnerabilities

Introduction

In the previous article, we discussed the importance of access controls and understood that the principle of least privilege is an essential component of information assurance and security activities. Access control issues are often dangerous as they can lead to attacks such as privilege escalation. 

This article discusses how such vulnerabilities caused due to insecure coding can be exploited by malicious actors.

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

What is the principle of least privilege?

According to OWASP documentation, “In security, the Principle of Least Privilege encourages system designers and implementers to allow running code only the permissions needed to complete the required tasks and no more. When designing web applications, the capabilities attached to running code should be limited in this manner. This spans the configuration of the web and application servers through the business capabilities of business logic components.”

In the context of web application’s business logic, authenticated users’ access to resources must be limited based on their identity and roles. Let us understand with an example, how this can be exploited when applications are not built by keeping this in mind.

Exploiting improper access controls

The following web application consists of two roles as follows. A standard user role with limited features and an admin role, which can control other user accounts.

Logging in with the standard user account shows the following. 

As we can observe, the user can only view his/her profile by clicking on View My Profile button. However, logging in as an admin user shows the following page.

Clearly, this role has an additional feature to delete users. Also, notice the difference in URLs. When a standard user is logged in, he/she is redirected to the following URL.

http://192.168.1.90/site/home.php

 

Logging in as admin redirects the user to the following URL.

http://192.168.1.90/site/admin.php

 

If the logged in admin user clicks the Delete Users button, the following page will appear, where users can be deleted.

Additionally, following is the URL associated with the delete users page, which is supposed to be accessible only when the user is logged in as an administrator.

http://192.168.1.90/site/deleteusers.php

 

Accessing privileged functions as low privileged user

The goal of this attack is to be able to access the features that are otherwise accessible only to a user with administrative privileges. So, let us see if we can access the delete users page as a normal user.

Login as a low privileged user and access the deleteusers.php page with this session. 

We are able to access this page with a normal user account. As we can see in the figure below, we can also delete all the user accounts on behalf of admin.

This is clearly a serious issue as a low privileged user is able to perform administrative tasks. Following is the piece of code causing this issue

if(!isset($_SESSION['user_loggedin'])) {

header('Location: index.php'); }

else

{

//do something

}

 

This is the only check being performed in the application when the deleteusers.php page is accessed by any user. Anyone with a valid session, can access admin pages and they can do all the actions on behalf of an admin. The point to note here is, there is no role- based access control implemented in the application to prevent unauthorized access to admin pages. Users with any role can access admin pages if they have a valid session on the application. It is common in applications that they serve privileged resources to unprivileged users. The problem is quite simple to understand. When a sensitive page is loaded to the user, there should be an authorization check to see if the user requesting this page has sufficient privileges to access this page or not. In the example we have seen, we requested a page and the page is served without any additional check apart from a valid session.

In addition to the example shown, it is possible that privilege escalation vulnerabilities are introduced in several other ways. 

Horizontal Privilege Escalation

Assume that a user has performed a transaction online, and he was given a transaction ID to verify his transaction details at a later point in time. The URL looks as shown below.

https://bank.com/transactions/tr_id/2344544443

 

Now, the user can change this ID to something else, and he can view the transaction details associated with that ID if the application is vulnerable.

https://bank.com/transactions/tr_id/2344544444

 

This is a typical example of Horizontal Privilege Escalation. 

vertical Privilege Escalation

Let us assume that a user is redirected to the following page, when logged in.

https://site.com/login/home.jsp?admin=false

 

If the same user is redirected to the administrator's home page just by tampering the GET parameter as shown below, it is called vertical privilege escalation.

https://site.com/login/home.jsp?admin=true

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Conclusion

As described in this article, lack of access controls can lead to various forms of privilege escalation vulnerabilities in web applications depending on the type of functionality. A low privileged user may be able to access other users’ resources or high privileged user’s resources depending on the access controls implemented in the application. In the next article, we will discuss how such privilege escalation vulnerabilities can be prevented by enforcing appropriate access controls.

 

Sources

1. https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html
2. https://portswigger.net/web-security/access-control
3. https://owasp-aasvs.readthedocs.io/en/latest/requirement-4.1.html