Privilege escalation happens when a malicious user exploits 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. The attacker can use the newly obtained privileges to steal confidential data, run administrative commands or deploy malware – and potentially do serious damage to your operating system, server applications, organization, and reputation. This post examines typical privilege escalation scenarios and shows how to protect user accounts in your systems and web applications to maintain a solid cybersecurity posture.
In general, attackers exploit privilege escalation vulnerabilities in the initial attack phase to override the limitations of their initial user account in a system or application. There are two main types of privilege escalation: horizontal privilege escalation to access the functionality and data of a different user and vertical privilege escalation to obtain elevated privileges, typically of a system administrator or other power user.
With horizontal privilege escalation, malicious actors remain on the same general privilege level but can access data or functionality of other accounts or processes that should be unavailable to them. For example, this may mean using a compromised office workstation to gain access to other office users’ data. For web applications, one example of horizontal escalation might be using session hijacking to bypass authentication and get access to another user’s account on a social site, e-commerce platform, or e-banking site.
More dangerous is vertical privilege escalation (also called privilege elevation), where the attacker gains the rights of a more privileged account – typically the administrator or system user on Microsoft Windows or root on Unix and Linux systems. With this elevated level of access, the attacker can wreak all sorts of havoc in your computer systems and applications: steal access credentials and sensitive data, download and execute ransomware, erase data, or execute arbitrary code. Advanced attackers will use elevated privileges to cover their tracks by deleting access logs and other evidence of their activity, leaving the victim unaware that an attack took place at all. That way, cybercriminals can covertly steal information and plant backdoors or other malware in company systems.
Privilege escalation is often one part of a multi-stage 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. But 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.
Worse still, 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 have legitimate access yet perform malicious actions that compromise system or application security. However, if you can quickly detect successful or attempted privilege escalation, you have a good chance of stopping the intruders before they can establish a foothold to launch their main attack.
Many cyberattacks start by compromising a web server, which is often accessible from the Internet. Attackers can then exploit vulnerabilities or misconfigurations to obtain root privileges on the host system. This may allow them to gain access to the file system and any other server processes running in the same system or even gain a foothold in the local network to launch attacks against other systems. Crucially, web servers are used not just for hosting websites and web applications – many printers, routers, and Internet of Things (IoT) devices routinely run a web server for their administrative interface. Once compromised, such a device can be used to launch further attacks within the local network.
The majority of web servers in use today, including many embedded systems, are hosted on some flavor of Linux. Older versions of the Linux kernel (prior to 4.8.3, 4.7.9, or 4.4.26) were vulnerable to a local privilege escalation attack dubbed Dirty COW (from Dirty Copy-On-Write), which allowed attackers to make read-only memory mappings writable. While this is a local attack, it is still extremely dangerous because the only guaranteed protection is to upgrade the Linux kernel – and that’s not always easy or possible, especially with embedded systems. But how exactly does it work?
To start with, the attacker needs to gain access to a regular, unprivileged user account, usually by exploiting a bug or misconfiguration. Once a user shell is available, it’s now a matter of downloading and executing one of many existing exploit scripts for Dirty COW – see this GitHub page for a list. The vulnerability can be exploited for privilege escalation in different ways, depending on the desired effect. One way is to modify the system password file /etc/passwd by replacing the root user with a newly created user who will then have root privileges.
While Dirty COW is likely the most serious privilege escalation vulnerability ever discovered for Linux, it only affects older and unpatched systems. It also requires access to a local user shell and some way of downloading the exploit script, so you can mitigate its impact by following good security practices listed later in this article.
Microsoft Windows determines the ownership of a running process using access tokens. The access token mechanism can be targeted by attackers to tamper with access tokens, bypass user account control (UAC), and assume the process rights of another user, but in Windows 10 and Windows Server 2016 you can set an audit event to detect any such changes. When you enable the Audit Token Right Adjusted event, the system will generate 4703 events for audit token modifications that may signal privilege escalation attempts.
To enable this audit event, open the Group Policy Management Editor and under Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking set the Audit Token Right Adjusted event to Success and Failure. Now you will receive a 4703 event every time a token right is modified, resulting in a flood of legitimate events from system processes. Use your event monitoring software to narrow this down by searching only for 4703 events related to potentially suspicious changes. One common target for attackers is SeDebugPrivilege – a system privilege that grants a user full debugging access to a process. If this gets set when nobody is doing any debugging, you can be pretty certain something is up.
For details of this audit event, see Audit Authorization Policy Change in the Microsoft docs. See also Security Monitoring Recommendations for tips on filtering the 4703 events generated when you use this method.
Attackers can use many privilege escalation techniques to achieve their goals. But to attempt privilege escalation in the first place, they usually need to gain access to a less privileged user account. This means that regular user accounts are your first line of defense. Follow these best-practice tips to ensure strong access controls:
Applications can provide an entry point for any attack, so it’s vital to keep them secure:
Not all privilege escalation attacks directly target user accounts – administrator privileges can also be obtained by exploiting application and operating system bugs and configuration flaws. With careful systems management, you can minimize your attack surface:
Websites and web applications expose a global attack surface and are often the first port of call for attackers. Use a high-quality vulnerability scanner to check your sites, applications, web services, and web APIs for vulnerabilities. Modern DAST solutions such as Netsparker are accurate and versatile and are under constant development to stay one step ahead of the attackers. Even if your application was secure last month or even last week, new vulnerability reports and exploits are published every day – and your systems and information might well be in danger even as you read these words.