That escalated quickly: how to prevent privilege escalation

Late last year, a major vulnerability was uncovered in the Kubernetes container orchestration system. It was a severe threat, not just because of the large number of organisations using Kubernetes, but also because of how brutally effective the exploit could be – potentially letting attackers take over entire nodes of target systems. Fully updated users are now secure, but this flaw came as a very unpleasant surprise, even if it was based on a common type of vulnerability known as privilege escalation.

What is privilege escalation?

Support for multiple users is a fundamental part of modern software and online platforms. While most users only need basic functionality, a select few are given access to advanced admin controls. Privilege escalation works by exploiting flaws in a system to give an attacker a higher level of rights or abilities, i.e. privileges, than they would normally have. The attacker can then view files they shouldn’t be able to access, steal data that should be safe, or even run their own malware.

The first step of a privilege escalation attack is finding a vulnerability – usually an overlooked flaw or programming error in the target system. Often the attacker will create a normal user account to analyse the system for flaws. Once a potential vulnerability is identified, the attacker can create an exploit and try it out. If successful, they have their privileges fraudulently raised, and may be given the opportunity to gain even higher levels of access.

In practice, privilege escalation attacks generally fall into two categories: vertical and horizontal. Vertical privilege escalation, AKA privilege elevation, is when the attacker starts off with standard user privileges and raises them via an exploit. Horizontal privilege escalation differs slightly in that the attacker accesses content or functionality meant for a different user with the same privileges. An example of horizontal privilege escalation would be a bug in an online banking platform that allowed one customer to view the details of another.

The actual exploits used in privilege escalation come in a variety of forms including custom requests, cross-site scripting, and exploitation of cookies or session IDs. But the ultimate objective is always the same: access to resources or abilities that would ordinarily be off-limits.

How did the Kubernetes vulnerability work?

The recent flaw was due to a vulnerability in the Kubernetes API server – software that allows instructions to be sent to Kubernetes pods via an HTTP API. If an unauthenticated user sent a carefully crafted request to a pod, the API server would return an error – but crucially, the line of communication to the backend server would remain open. Subsequent requests would be authenticated by the API server’s Transport Layer Security credentials, enabling a normal user to gain exec-level privileges – meaning access to all containers on the same node and the power to interfere with services, steal data or execute malicious code.

Officially labelled CVE-2018-1002105, the flaw was the worst Kubernetes vulnerability so far, earning a Common Vulnerability Scoring System (CVSS) rating of 9.8 (critical). This severity was partly due to how relatively straightforward the exploit was to execute, with attackers able to act remotely and no user interaction or starting privileges required. Because requests went via an established connection and didn’t appear on the API server audit logs, it was also difficult to assess whether an attack had even occurred.

Needless to say, a patch came hot on the heels of these revelations. While systems with automated updates are no longer at risk, any Kubernetes users not on the latest version should implement the patch as soon as possible. And of course, at Fasthosts our internal systems are fully patched, up to date and secure.

What is the principle of least privilege?

The principle of least privilege is a longstanding element of programming best practice, and it’s key to combating privilege escalation. The basic idea is this: in the design of any kind of software or platform, every separate module should have the level of privileges required for its particular role – nothing more, nothing less. In a sense, least privilege is the “need-to-know basis” of the IT security world.

According to the least privilege model then, each component – whether it’s an individual user, a process or an application – should only get the bare minimum level of access to resources within the system as a whole. Examples are easy to see on workplace PCs, such as how standard users can access a range of applications but can’t install new ones. The division of business IT systems between departments is another basic implementation of least privilege: a support agent can log in to the customer database; a member of the HR team can use the payroll system – but neither employee has access to both.

Why isn’t the principle of least privilege always applied?

It might sound like a no-brainer, but failure to adhere to the principle of least privilege is surprisingly common. In small teams and start-ups, for example, ad-hoc arrangements and mutual trust can lead to privileges being unnecessarily distributed; combined with the misconception that smaller businesses aren’t worth attacking, this can be a recipe for disaster. In larger organisations, the need to manage large numbers of users across multiple systems can lead to “privilege creep” – that is, when users retain previously required privileges that aren’t relevant to their current roles. On complex platforms, it’s also possible for technical oversights to result in users having more privileges than they should, as happened with Kubernetes.

A high-profile example of least privilege failure can be seen in the case of Edward Snowden. Employed by the US government as a contractor, Snowden’s job concerned the creation of database backups – yet he was given high-level admin rights that allowed him to access critically sensitive files. Regardless of his motivations, Snowden was only able to leak highly classified information because the principle of least privilege was not followed.

With all this in mind, the security benefits of least privilege are obvious: even if an attacker gains unauthorised access to parts of the system, there’s only so much harm they can do with minimal privileges. Least privilege provides vital damage limitation and can prevent critical resources from being compromised, especially in cases where the attack or data breach originates from users with pre-existing credentials.

In the case of the Kubernetes flaw, the ability of any user to gain full admin rights was obviously a huge lapse of the least privilege principle. While never intended by the developers, this vulnerability provides a valuable glimpse of how dangerous privilege escalation can be, and a reminder of the value of least privilege when it comes to building maximum security into any online platform.