Privilege escalation is an attack where the adversary changes their provisioned set of permissions. Otherwise known as PrivEsc, as penetration testers like to call it, this is probably every hacker’s goal. If they are lucky, they can go from unauthenticated web user to server admin and gain root server access in one attack. More often than not, it might require the attacker several steps to reach that goal, such as from unauthenticated to authenticated user, then to a privileged user. This could go on to a footprint on the server, from which they escalate their attack to admin/root on the server.

Privilege Escalation is the symptom for the lack of strong and inclusive access controls. In most cases, PrivEsc exists because of weak or missing security controls. 

Access control is the combination of:

• Authentication: Proper identification of the user’s identity, basically ensuring the user is who they say they are.
• Session management: The process of tokenizing this identity into the user’s session so the application does not have to check the identity on every request.
• Authorization enforcement: The process of ensuring that the user has access to the resources as claimed.t

With that in mind, the process of privilege escalation is where the attacker is trying to circum one or more of these access controls (i.e. authentication, session management and/or authorization) to achieve a privilege escalation vulnerability. 

How is Privilege Escalation in Web Applications Different?

The main difference between privilege escalation within web/api applications and a network is the attack surface. The attack surface is much bigger and much more complicated in web/api applications. Every single server URL, file, API endpoint, and accepted HTTP Verb (e.g. GET, POST, DELETE, etc) is a potential target for a privilege escalation attack. 

Types of Privilege Escalation

There are two main types of privilege escalation:

Horizontal Privilege Escalation:

In this type of privilege escalation, the attacker is trying to move laterally to gain access to unauthorized data or privileges. For example, in a banking application, an attacker might try to gain access to someone else’s account. Here, they are not trying to get admin access (i.e. move up) but lateral access (move sideways). Another example, in a multi-tenant environment, is where the attacker is trying to gain access to the resources and data belonging to another tenant.

Vertical Privilege Escalation: 

In this type of privilege escalation, the attacker is trying to move vertically and expand his set of permissions. For example, an attacker with no access at all (i.e. unauthenticated), and is trying to get authenticated-user privileges. Another example is an authenticated user who is trying to elevate their privileges and gain access to the set of permissions an administrator would have.

Detecting Privilege Escalation

The ultimate form of privilege escalation is when the attacker is able to gain admin access (i.e. root) on the server. Whether horizontal or vertical privilege escalation, this could be achieved using one or more of the following hacking techniques:

1- Parameter Manipulation

Parameter manipulation, is an attack where through the manipulation of an HTTP Request parameters, the attacker is able to exploit the server side protection, or the lack of, in gain unauthorized access to a resource or a database record by simply modifying a parameter in the HTTP QueryString or body. Take for example the following: 

GET /retrieveaccount?accountID=12345 HTTP/1.1

Host: vulnsaas.com

Accept: */*

Content-Length: 0

Changing the account ID to, say, 12456 might lead to retrieving someone else’s account information.

2- Lack of Server-Side Security Controls

There is a lot of variety in this particular vulnerability. For example, let’s assume the following web application, where an admin have access to a menu with five functionalities (Tasks, Documents, Files, Discussions, and Settings):

Clicking on each menu item would lead to a request from the prospective API endpoint, so for example “Tasks” would issue a request to “/api/v2/tasks,” and so on. Now, let’s assume a regular user does not have access to the last two menu items. They have access only to “Tasks”, “Documents” and “Files.”

In this case, the user does not have access to “Discussions” or “Settings” from the menu. But the lack of server-side security controls does not prevent them from sending the request directly to those API endpoints. 

There are several other lack of server side security controls scenarios, for example, let’s assume that a regular user in the previous example has access to their own documents, but an Admin has access to everyone’s documents. 

The request might look something like:

GET /api/v2/documents/user HTTP/1.1

Host: vulnsaas.com

Accept: */*

Content-Length: 0

This would change the URL to something like the following:

POST /api/v2/documents/all HTTP/1.1

Host: vulnsaas.com

Accept: */*

Content-Length: 0

This would give the user access to all the documents due to the lack of server-side controls.

3- Command Injection

Command Injection is a vulnerability that would allow an attacker to execute command directly on the server side. In this case, the attacker is looking to elevate their privileges from a web user, whether authenticated or not, to obtain a shell on the server and perhaps elevate their privileges to root in some cases.

Take for example this piece of code:

String comm = "cmd.exe /c dir "+ request.getParameter(“file”);

Process process = Runtime.getRuntime().exec(comm);

BufferedReader stdInput = new BufferedReader(new InputStreamReader(process.getInputStream()));

Passing the URL http://vulnsaas.com?file=.;ipconfig -a would execute the following commands, respectively:

cmd.exe /c dir .

Ipconfig -a  

4- SQL Injection

SQL Injection is a vulnerability that would allow the attacker to manipulate a SQL query, which is part of the application. This would allow the attacker to, in addition to other things, run their own queries to retrieve data they are not authorized to access. But SQL injection could also be used to escalate privileges. As most database management systems have a functionality to run system commands as part of a query. In this case, the attacker is trying to elevate their privileges from a web user to a console/server user, and ultimately server root/admin. For example, SQL Server has xp_cmdshell:

EXEC xp_cmdshell 'dir *.exe';  

GO  

Here is another long way to doing the same thing in Postgres:

CREATE TABLE trigger_test

             (

                          tt_id SERIAL PRIMARY KEY,

                          command_output TEXT

             );CREATE

OR

replace FUNCTION trigger_test_execute_command()

returns TRIGGER language plpgsql AS $body$

BEGIN

  copy trigger_test (command_output) FROM program 'echo 123';RETURN NULL;END;$BODY$;CREATE TABLE trigger_test_source

             (

                          s_id INTEGER PRIMARY KEY

             );CREATE TRIGGER tr_trigger_test_execute_command after

INSERT

ON trigger_test_source FOR each statement

EXECUTE PROCEDURE

  trigger_test_execute_command();

insert INTO trigger_test_source VALUES

            (

                        2

            );



table trigger_test;

tt_id │ command_output ───────┼──────────────── 1 │ 123

Thankfully, most database management systems come with this functionality disabled. However, there is always a way to enable it.

5- Insecure File Upload 

This is one of the most underestimated vulnerabilities out there. Although it is seen less in the wild right now, nonetheless, the existence of this vulnerability could lead to a complete server takeover. Take this StackOverFlow answer, for instance, which was marked as the right answer for the question, “Upload a file using PHP:”

<?php

$target_dir = "upload/";

$target_file = $target_dir . basename($_FILES["fileToUpload"]["name"]);

$uploadOk = 1;

$imageFileType = pathinfo($target_file, PATHINFO_EXTENSION);




// Check if image file is a actual image or fake image

if (isset($_POST["submit"])) {




   if ($target_file == "upload/") {

       $msg = "cannot be empty";

       $uploadOk = 0;

   } // Check if file already exists

   else if (file_exists($target_file)) {

       $msg = "Sorry, file already exists.";

       $uploadOk = 0;

   } // Check file size

   else if ($_FILES["fileToUpload"]["size"] > 5000000) {

       $msg = "Sorry, your file is too large.";

       $uploadOk = 0;

   } // Check if $uploadOk is set to 0 by an error

   else if ($uploadOk == 0) {

       $msg = "Sorry, your file was not uploaded.";




       // if everything is ok, try to upload file

   } else {

       if (move_uploaded_file($_FILES["fileToUpload"]["tmp_name"], $target_file)) {

           $msg = "The file " . basename($_FILES["fileToUpload"]["name"]) . " has been uploaded.";

       }

   }

}




?>

The code is validating whether there is an actual file being uploaded, but there is a lot more than that to be sure the upload is secure. The code is not validating the content or even the extension of the file. The most dangerous part is that the file is being uploaded using its original name somewhere on the server. If that location is web accessible, that’s all the attacker needs. In this case, the attacker will upload a PHP file and, assuming it is web accessible, they can simply execute whatever malicious code is in there.

How to Prevent Privilege Escalation Attacks

Privilege escalation is every attacker's goal, so naturally they are looking for it aggressively. Privilege escalation is the kind of vulnerability that can definitely end up getting your company in the news or putting you in an embarrassing situation with a client. 

1- Strong authentication controls

It goes without saying that strong authentication controls are super important to ensure the identity of every request. Every endpoint, serve file, API, and HTTP Method should all be protected.

2- Strong access control

Similar to authentication, strong access controls should protect every endpoint. Access control is much harder to get right than authentication, especially for applications that have multiple roles and those that have configurable permissions. 

3- Avoid calling system commands from source code

Unless absolutely necessary, system commands shouldn’t be called from source code at all. If absolutely necessary, then a very strong “Allow List” should be implemented. 

4- Use ORMs or parameterized statements

These are very important, not just to stop privilege escalation but to stop SQL injection as well.

5- Hardening your whole stack

Laxed or insecure configuration could also lead to privilege escalation.

6- Penetration testing

Implementing all the above is not a guarantee that your application is PrivEsc-less. Keep in mind that you need to close all the gaps, while the attacker is only looking for one to exploit. Penetration testing is the best way to ensure that all the mitigations mentioned above are strong enough and implemented across the board. 

References:

[1] StackExchange

[2] StackHawk