Privilege escalation occurs when an attacker can exploit a weakness in software to gain access to resources (such as systems or data) that is not intended by the system owner to be accessible to them. The attacker may use the maliciously obtained access privileges to steal sensitive data or run malicious commands on a compromised system or host. This blog post looks in more detail at how privilege escalation can occur, as well as highlighting some common variants and also how to best prevent or avoid them from happening.

What do we mean by “privileges” anyway?

Most computer systems are not fully “open”, in that they place restrictions on what individuals accessing the system are able to do, or on what data they are able to access (whether to read it, amend it or delete it). The overarching term for these systems of restrictions is known as access control and whilst there are a number of ways of implementing such a system, they all ultimately rely on some form of identification (requiring a user to provide some kind of unique identifier such as their name or system ID), authentication (requiring the user to prove that they “own” the identity claimed, often via the provision of some form of credential or shared secret), and authentication (a check that the user that has been identified is permitted to access the given resource, i.e. a check of their privileges).

In a system that may have thousands or millions of discrete resources (known as “objects”), and thousands or even millions of possible users (known as “subjects”), it is combinatorially impractical to explicitly define on an individual basis the access of each user to each and every resource. Instead, a system of rules is put in place to manage access control within a given system or domain, known as an access control system. There are several different ways of managing and mapping these privileges to identities, including:

• Discretionary Access Control (DAC) – in which subjects determine and map which subjects can access their objects;
• Role Based Access Control (RBAC) – in which system owners assign rights based upon roles, and then map subjects to one or more roles
• Mandatory Access Control (MAC) – in which access to every resource is managed by the system owner using security labels classifying the security level, and users are assigned security clearances that permit them to access objects up to their given classification.
• Rule-Based Access Control – as seen in typical firewall configurations, where one or more rules are evaluated one after the other in a list fashion until one is matched that defines the privileges permitted

What is privileged access?

Strictly speaking, in a managed access control system that applies an access control model, any user with defined access has defined privileges, and “privileged access” may simply refer to having any access to a given system whatsoever (as opposed to an anonymous, unidentified user). However, privileged access more typically is used to refer to some “higher” grade of access to objects within a given system. The form it takes will depend on the access control model that is implemented, but it may refer especially to accounts that have administrative privileges, and in particular to those accounts that are “meta-accounts” in that they provide access to the management of privileges within the system.

What is privilege escalation and what is it meant for?

Within a given system, it is sometimes possible to escalate a privilege set (the set of authorised object accesses) for a given account in an authorised and managed way and either without transitioning identity, or by transitioning identity in an authorised and intended manner. An example might be the “sudo” (“superuser do”) command on Unix and Linux operating systems, designed to allow users to temporarily assume higher privileges for the execution of certain commands, or the su (“switch user”) command on the same operating systems, which allows you to switch identity to that of another user, provided you have permissions to do so.

The idea behind privilege escalation when used in this designed and intentional way is that by establishing a method for privileged accounts to be accessed only on an as-needed basis, that the rest of the time a user can operate in a lower-privilege environment, reducing the possibility of accidental damage to the system from accidental or mistyped commands that would be denied at their lower privilege level.

How does unauthorised privilege escalation occur?

Privilege escalation can sometimes happen in an unauthorised way that was not intended by the system designer or owner. This can often occur when a malicious user is able to exploit a bug, design flaw, or configuration error in an application or operating system to gain elevated access to resources that should normally be unavailable to them.

What types are there?

A primary distinction is normally made between two types of privilege escalation within a system:

Horizontal privilege escalation is the term used to describe the ability for a given user to access the functionality and data of a different user that is on the same privilege “sphere” or level as them – either having the same or similar role set within a RBAC-based system, or having the same access clearance as them within a MAC-based system.

Vertical privilege escalation on the other hand may be the form that is most suggested by the term “privilege escalation” in that it describes the ability of a user to escalate or increase their privileges, typically to those of a system administrator or other power user:

There is a third type of privilege escalation that doesn’t fall neatly within either of the above two categories in that it doesn’t directly involve a user gaining the identity or full access privileges of another user, but is able to access some or all resources that are accessible by another user but not normally to themselves: this is known as the “confused deputy” variant. In this variant, a user is able to trick or manipulate a legitimate, more privileged computer program into misusing its authority on the system to perform an action on behalf of the unprivileged user. This can occur in systems in which there is a separation of authority from the purpose of an access – that is, a privileged program is requested to access a resource (to which it has access) but fails to check or determine the requesting subject. It can often occur in services in which a user is authenticated and authorised to access the service, but the service fails to check the explicit authorisation for each requested action, known as incomplete mediation.

What are some examples within web applications?

As well as the traditional basis of privilege escalation concerns in terms of user accounts on a system, web applications have their own privilege escalation concerns. The below is just a few examples:

• Unprotected Functionality – In many cases broken access controls, sensitive functionality and resources can be accessed by anyone with the knowledge of the correct URL to request. In this case the developer or operator of the given application is dependant on the sensitive functionality being obscured or hidden from it’s users, with the application only enforcing access controls to the extent of a logged in user. An example of this would be access to the administrative functionality being protected by the assumption that an attacker will not know or discover the correct URL.
• Authorization Bypass Through Identifier Based Functions – where system’s authorization functionality does not prevent one user from gaining access to protected functionality by modifying the key value identifying the data, e.g., a user might ordinarily access their own account page using a URL like the following: https://insecure-website.com/myaccount?id=123 – Now, if an attacker modifies the id parameter value to that of another user, then the attacker might gain access to another user’s account page, with associated data and functions.
• Authorization Bypass Through Direct Access to Methods – arise when functionality within an application exposes URL’s or parameters that are remote invocations of back-end functionality. In principle, this is similar to the previously mentioned authorization bypasses, in that knowledge of the correct parameter is required in order to successfully access sensitive functionality. The key difference here is the client interacts directly with back-end system or functionality which bypasses any application-level access controls that are in place.
• Authorization Bypass Through Multistage Functions – Many functions within web application are implemented across multiple stages, which may include multiple requests being made that each require checks against access controls. Sensitive functionality from unauthorised access is implemented but the access controls employed are broken because of flawed assumptions about how the functionality will be used. An example of this could be found in an online banking application which uses multiple stages to a user journey to carry out a monetary transaction between customer bank accounts. Whilst sufficient controls may be in place that allows the user to access the transaction page but there may be insufficient controls to govern which bank account the money is to be transferred from.
• Platform Misconfigurations – occur in some applications that rely on controls set by the underlying web server. Access to sensitive functionality is based on data and attributes passed through from the original request. Rules such as these allow or deny access based on HTTP request methods, URL paths or a user’s role. In principle this is an entirely legitimate means of enforcing control, but it requires precise configuration, with any misconfiguration in the platform resulting in possible unauthorised access for an attacking party. A typical example is an access control which is based on HTTP verbs. A HTTP GET request to the “/admin” part of an application, could be trivially bypassed by instead requesting a different HTTP verb such as POST.
• Static Content – Often access control issues arise from the lack of controls around dynamic content. However, in some cases requests for protected resources can be made to static resources that reside in the web root of the hosting web server. As the protected resources are hosted within the context of the web server, no application-level code or access controls are applied to an incoming request. An example of this would be a malicious party requesting PDF reports that have been saved by the legitimate users of the website to the “/reports” directory.

What is the impact of unauthorised privilege escalation?

When an attacker is able to assume the identity of another use, they gain all the privileges that that assumed identity has been granted by the system owner under its access control model. They can use the newly obtained privileges to compromise the confidentiality of any data that the privileged account has access to by stealing (exfiltrating) it, often known as a “data breach”; they can impact the integrity of the data or system, by installing malware, modifying data records, installing “backdoors” that permit ongoing further access, run administrative commands or otherwise disturb the intended state of the system and its data; or they can disrupt the availability of the system, either by shutting it down, wiping its disk or storage or – more recently – by performing a ransomware attack for financial gain, in which the system’s data is encrypted using a key known only to the attacker, so that the organisation must pay the attacker a ransom fee (often in untraceable cryptocurrency) in order to regain access to their own data.

How can we prevent it?

When combatting specific cybersecurity risks, security teams talk in terms of controls that can be applied to help mitigate the risk – these are often classified as being preventative (reduce the likelihood of the exploit occurring, or the impact should it occur), detective (spotting when an exploit has occurred, so that an attack can be stopped in its tracks, and/or remedial action can be taken swiftly) or corrective (restoring security posture and normal system operation, and fixing the underlying cause of the weakness to prevent reoccurrence) in nature.

Preventative controls

The Principle of Least Privilege is a key concept and security principle that applies across a range of technologies. Rather than being a specific technical control, tool or program that you can deploy, it is a principle that can be followed when designing and implementing every component of your infrastructure from the facility and tin up to the application layer. In summary, it involves ensuring that you restrict the authorised set of access to a given site, system, service or resource for a given user to only that which is required for them to perform their function or duty, and no more.

Privilege Separation is an extension of the least privilege principle in which a program or system is divided into parts which are each limited to the specific privileges they require in order to perform a specific task, in order to mitigate the potential damage of a computer security vulnerability. A common method to implement privilege separation is to have a computer program (such as a webserver) fork into two processes for example: the main program drops privileges, and the smaller program keeps privileges in order to perform a certain task. The two halves then communicate via a socket pair such that any successful exploit against the larger program will gain minimal access, even though the pair of programs will be capable of performing privileged operations.

Sandboxes is the name given to a situation in which a system or service is “firewalled” from other components such that the service is provided with a minimal and tightly controlled set of resources for guest programs to run in, such as storage and memory scratch space, and from which broader network access, the ability to inspect the host system, or read from input devices are either disallowed entirely or heavily restricted. More broadly, more sophisticated containment systems extend this principle into MAC-based access control capabilities, such as SELinux or Apparmour.

System hardening refers to the pre-emptive and precautionary reduction of the “attack surface” of a given system or service, by deliberately reducing the set of interaction points (whether these are services, ports, paths or methods) into only those that are essential for the service’s operation. Many Linux distributions are delivered out of the box with a flexible configuration designed to cover multiple system usages, but this may involve operating many more services than is actually required, each of which represents a potential point of attack or attack vector if compromised.

Firewalling of systems both individually and into appropriate network segments is effectively an extension of the system hardening and least privilege principles combined. It can act to reduce both inbound but also outbound access, to prevent inappropriate access as well as preventing partial system compromises or remote code execution from being used to establish further “backdoors” or pivoting their attacks to other systems and escalate an attacker’s compromise of the network.

Patching is perhaps the most common preventative measure recognised in vulnerability management, and a routine activity for many “blue” teams within technology departments. Patching firmware, operating systems and application and utility software can prevent serious vulnerabilities such as Remote Code Execution (RCE) and SQL Injection (SQLi) from being exploited, both of which can lead to privilege escalation.

Password policies are key for any system in ensuring that authentication is robust and that a user’s identity is only assigned to requesting subjects that can adequately establish account ownership. Where possible, multi-factor authentication (MFA) should also be considered, especially for publicly exposed systems, for administrative access, and as a secondary authentication barrier for high-risk activities such as password reset requests.

Automated provisioning and PAM is a less common technique more recently established in the enterprise space, which aims to reduce the possibility of identity management errors and other weaknesses via an ecosystem of tools including a secure key/password vault, secure password auto-generation, auto-rotation of passwords, and approval workflows for key actions.

Detective controls

Logging monitoring and auditing, is essential for any system and involves ensuring that key actions are recorded in a forensic audit trail, to establish timeline of events and allow spotting of malicious activity. Wherever possible logs should be transmitted off-host in near real time and logged to a SIEM or other platform that is suitably secured and ensures that logs are immutable in that they cannot be modified, to cover an attacker’s trail for example.

Event alerting for key activities such as privilege escalation requests is important to be built on top of a monitoring system, so that any issues can be spotted quickly and investigated.

Behavior Analytics is a more sophisticated technique that can be used to spot patterns in system usage where each individual action may be benign, but as a whole the pattern represents an anomaly that should be investigated. Once a baseline of “normal” usage has been established then anomalies can be used to trigger alerts – for example if a system that normally sees minimal usage during the night sees a sudden spike in activity at 3am, then this could trigger an alert.

Vulnerability Scanners are tools that allow an organisation to perform a scan that checks whether networks, machines, and applications are susceptible to attacks, vulnerabilities and exploits. Vulnerability scanning is a common practice used in the vulnerability management of web applications and web servers that helps to identify web server security vulnerabilities that can lead to privilege escalation, such as:

• Command injection (RCE)
• Insecure server configuration
• Cross-Site Scripting (XXS)
• SQL injection

Corrective Control

An Incident response plan can be established, that outlines basic “playbooks” of what action should be taken if an exploit does occur, ensuring that there are defined communication channels and clear understanding of responsibilities, as well as clear understanding from technical teams on how to respond to an incident in terms of triage, damage limitation, and forensic preservation.

How can AppCheck Help?

AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including authentication failures, misconfigurations and violations – from first principle to detect vulnerabilities in in-house application code.

While crawling an application AppCheck analyses the application for vulnerabilities including weak session tokens, session fixation weaknesses, weak passwords, and other weakly implemented authentication. It can also detect suspected IDOR weaknesses as well as exposed administrative endpoints.

AppCheck specific checks for known default or hard-coded vendor passwords on equipment and services, the use of session IDs in the URL, plaintext passwords emailed to users during registration, vulnerabilities in forgot-password processes, and authentication bypass. AppCheck also includes configurable password guessing modules to identify weak account credentials with systems such as:

• HTML Form Authentication
• Outlook Web Access (OWA)
• Content Management Systems (eg. WordPress)
• NTLM/Basic Authentication
• Management Systems and SSL VPN Gateways

The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.

About AppCheck

AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).

Additional Information

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost