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.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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).
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: email@example.com
No software to download or install.
Contact us or call us 0113 887 8380