Climbing The Ladder | Kubernetes Privilege Escalation (Part 1)

Kubernetes (K8s) has become an integral part of cloud-native environments, offering powerful container orchestration capabilities that enable organizations to deploy, manage, and scale applications efficiently. However, as Kubernetes adoption grows, so does its attractiveness as a target for attackers.

This is the first Attack post within our new Cloud & Container – Attack & Defend blog series. In this post, we discuss the threat of Kubernetes privilege escalation, specifically, Account Manipulation (T1098) and Valid Accounts (T1078) as well as the abuse potential of system pods within an attack chain.

Kubernetes (K8s) Privilege Escalation

After Initial Access (TA0001), threat actors targeting Kubernetes often first look to expand the scope of attack, through either Credential Access (TA0006), Privilege Escalation (TA0004), or a combination of the two. Privilege escalation in Kubernetes occurs when an attacker gains unauthorized access to higher levels of privileges within a cluster.

This can be achieved through various means, including exploiting misconfigurations, leveraging vulnerabilities, or abusing over-permissive Role-Based Access Control (RBAC) policies. Once an attacker escalates their privileges, they may gain control over the entire Kubernetes cluster, access sensitive data, disrupt critical services, or deploy malicious workloads.

MITRE ATT&CK’s Container Matrix details six main privilege escalation techniques that have been observed in the wild:

• Account Manipulation – Where threat actors increase permissions or add additional roles of a user or service they control. For Kubernetes specifically, threat actors have been observed creating RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account. Additionally, if Kubernetes attribute-based access control (ABAC) authorization is in use, then additional permissions can be granted via manipulating the policy directly. It’s worth noting that for Kubernetes deployed in public cloud environments, account manipulation extends to cloud-specific access services such as AWS IAM, GCP IAM, and Azure role-based access control.
• Valid Accounts – Where threat actors use or abuse default or local accounts to further their compromise campaign. For Kubernetes, this would include threat actors leveraging the default service account.
• Create or Modify System Process – Where threat actors create or modify cluster management tools like Docker and Podman, or environment specific components like kubelet. For Kubernetes, a threat actor can modify DaemonSets to Deploy Container across all nodes, including ones added later.
• Escape to Host – Where threat actors gain access to related containerized resources or the underlying host. Within Kubernetes environments, an example would be leveraging a privileged container to run commands on the host, or using a writable hostPath mount to create new containers with similar capabilities to run commands or drop payloads.
• Exploitation for Privilege Escalation – Where threat actors exploit a software vulnerability to run their own code for the purpose of elevating privileges. As a Kubernetes specific example, similar to popular Bring Your Own Vulnerable Driver (BYOVD) attacks which allow attackers to exploit a vulnerability and execute code in kernel mode, vulnerabilities in eBPF have been found to enable attackers as unprivileged users to out-of-bounds (OOB) access to the Linux kernel, which constitutes both container escape and privilege escalation to the host.
• Scheduled Task/Job – Where threat actors abuse scheduling functionality to run malicious code. For Kubernetes, threat actors have been observed leveraging CronJob to malicious code at the scheduled deployment of a Job.

Privilege Escalation via Account Manipulation

Before diving deeper into Kubernetes privilege escalation, it is crucial to establish a solid understanding of Kubernetes Role-Based Access Control (RBAC). Kubernetes basics can be found here.

Kubernetes RBAC is a critical security mechanism that controls access to resources within the cluster. However, when RBAC roles are misconfigured or over permissive, they become a prime target for attackers looking to escalate privileges. RBAC works by allowing fine-grained control over who can perform specific actions on Kubernetes resources, structured through Roles and ClusterRoles.

• Roles and ClusterRoles:
  • Roles – Defined within a specific namespace, Roles consist of rules that specify permitted actions (verbs) on certain resources. For example, a Role might allow reading (get) or modifying (update) ConfigMaps within a namespace.
  • ClusterRoles – These are similar to Roles but operate at the cluster level, applying either across all namespaces or to cluster-scoped resources like nodes or persistent volumes. ClusterRoles can grant broad or fine-grained permissions across the entire cluster.
• RoleBindings and ClusterRoleBindings:
  • RoleBindings – Link a Role to a set of users, groups, or service accounts within a particular namespace. This binding authorizes the specified subjects to execute the actions defined in the Role within that namespace.
  • ClusterRoleBindings – Extend this concept by associating ClusterRoles with users, groups, or service accounts, granting them permissions across all namespaces or at the cluster level. This allows for the centralized assignment of permissions that apply universally across the cluster.

Consider the following ClusterRoleBinding that grants the pod-reader ClusterRole to the reader-sa service account:

The reader-sa service account can now be authorized to perform the operations listed in the pod-reader ClusterRole.

In Kubernetes, permissions are defined by rules within Roles and ClusterRoles, specifying verbs (actions) that can be performed on resources within specified API groups. Common verbs include get, list, create, update, patch, and delete. Roles and ClusterRoles can be associated with a pod through a service account, and binding a service account to a pod grants it the ability to perform actions across the cluster. For instance, binding the reader-sa service account to a pod grants it the ability to get pods across the entire cluster.

Attack Technique | Transitioning from Theory to Practice

With a solid understanding of RBAC, we can now delve into how these fundamental components can be manipulated to compromise a Kubernetes environment. Attackers often exploit these elements to move laterally within the cluster or escalate their privileges.

Attackers typically exploit permissive RBAC roles, targeting those that are overly permissive or too broadly applied. For example, a role intended for limited, namespace-specific access might mistakenly have cluster-wide permissions. Similarly, a service account might be granted more privileges than necessary. As such, attackers often focus on gaining access to a pod or user with the elevated permissions to enable further escalation of access, and/or gain cluster-wide administrative control.

Neighboring Pods

A particularly stealthy method involves exploiting neighboring pods, allowing attackers to ‘leapfrog’ from one pod to another, thereby gaining unauthorized access and control over the cluster. When an attacker gains unauthorized access to a Kubernetes environment, their exact landing spot within the cluster is often unpredictable. However, the inherent nature of DaemonSets – designed to ensure specific pods run on every node – makes them inevitable targets. These key services are high-value targets for attackers, who are likely to encounter them no matter where they enter the cluster.

However, the risk doesn’t stop at DaemonSets. Pods that are co-located on the same node, often referred to as ‘neighboring pods’, can also be exploited in conjunction, enabling attackers to escalate privileges or move laterally within the cluster. Even if the DaemonSet itself isn’t vulnerable, the configuration or vulnerabilities of neighboring pods might provide an exploitable route to a pod with elevated privileges.

Elevated Privileges

To analyze the privileges most commonly used and abused in attacks, it is worthwhile documenting the range from those that are allowed to escalate to cluster admin access to those that can be exploited in specific scenarios. To standardize discussions around these permissions, we categorize them into four primary attack types based on the nature of the threats they enable (see Table 1).

To prevent over-complication, similar actions and resources have been aggregated. For instance, update and patch verbs are combined into a single ‘modify’ verb, and permissions for various pod controllers like: DaemonSets, Deployments are collectively represented as ‘govern pod management services’. This approach simplifies the framework while accurately reflecting the potential impact of these permissions.

Breakdown of Attack Type

Trigger Remote Code Execution

This category encompasses permissions that enable the execution of arbitrary code within pods or nodes. While not all instances of RCE lead to privilege escalation, these permissions substantially increase the attack surface by allowing the attacker to control additional compute resources or services.

Example of Attack Scenario: An attacker possessing create pods/exec permission can execute arbitrary commands within other pods, leveraging tools like kubectl exec to escalate their influence and potentially compromise critical services across the cluster.

Harvest Access Tokens

This category includes permissions that allow attackers to retrieve or issue service account tokens, which can lead to unauthorized access within a Kubernetes environment. The impact of these permissions is heavily influenced by their scope – particularly if they apply to high-privilege namespaces like kube-system. Elevated risks arise if these tokens are obtained from namespaces with high-privilege service accounts.

Example of Attack Scenario: An attacker with create serviceaccounts/token permissions in a privileged namespace can generate tokens tied to powerful service accounts. These tokens enable the attacker to impersonate these accounts, gaining unauthorized access to critical resources, escalating their privileges within the cluster, and potentially compromising the entire environment.

Compromise Access Management

These permissions allow direct manipulation of the cluster’s authentication and authorization mechanisms, making them highly targeted for attackers aiming to escalate privileges. They can enable actions such as assigning roles or impersonating other identities, effectively granting the attacker broad control over the cluster.

Example of Attack Scenario: If an attacker can bind clusterrolebindings, they could assign the cluster-admin role to a compromised identity, thereby gaining full administrative access across the cluster. In this context, these permissions serve as critical chokepoints that, if compromised, can lead to significant security breaches.

Divert Pod Controls

These permissions allow attackers to manipulate pod scheduling, effectively enabling them to relocate critical pods to compromised nodes. This technique is highly sophisticated and requires the attacker to first gain control over a node in the cluster.

Example of Attack Scenario: This technique relies on manipulating the Kubernetes tainting mechanism to control where pods are scheduled.

• Node Compromise – The attacker gains control over a node within the cluster.
• Taint Manipulation – By adding a NoExecute taint to the compromised node and a NoSchedule taint to other nodes, the attacker can force Kubernetes to evict and reschedule the targeted pods.
• Pod Rescheduling – The pods are then rescheduled onto the attacker-controlled node, giving the attacker potential access to sensitive resources, such as service account tokens and other secrets associated with the stolen pods.

The Silent Threat of System Pods

System pods are the backbone of a Kubernetes cluster, essential for functions like networking, resource management, and storage. Unlike user-deployed pods, these system pods are pre-installed and managed by cloud providers, often operating with elevated privileges. This inherent power and pre-configured nature make them a double-edged sword.

Users typically inherit these pods without direct control over their configurations or permissions, which creates a silent threat. Attackers increasingly target these privileged pods as entry points for privilege escalation due to their inherent power, using them as a stepping stone to potentially compromise the entire cluster.

The Achilles’ Heel | Misconfigurations

Misconfigurations in system pods present a nuanced and often underestimated security risk within Kubernetes environments. The complexity stems from the fact that what constitutes a misconfiguration is highly context-dependent. For example, a permission or setting that is necessary for the operation in one cluster might be excessive or dangerous in another, since both inherit the same system pods.

The risk becomes even bigger when multiple misconfigurations exist across different system pods, creating a chain that an attacker can exploit. Many times the ‘links’ in those chains are unnoticed or left unpatched. While each ‘issue’ might seem benign in isolation, together they can create a scenario where an attacker, once inside the cluster, can escalate privileges, gain unauthorized access to sensitive resources, or even take over the entire cluster.

To demonstrate why system pods are prime targets for attackers and to understand the risks associated with their misconfigurations, we have summarized the primary system pod families in Table 2 below. Each family is evaluated based on the privileges it holds, how misconfigurations can increase the attack surface, and why they are attractive targets for attackers.

Summary

Attacks like these underscore the need for both proactive and reactive security controls for Kubernetes environments. SentinelOne’s Cloud Security helps organizations secure their containerized applications by providing the full range of security controls needed, including Container and Kubernetes Security as well as Container Runtime Security.

In this blog, we’ve explored privilege escalation techniques in Kubernetes from an attacker’s perspective, examining how adversaries leverage Kubernetes features to gain unauthorized control. We began with an overview of the MITRE ATT&CK techniques, and followed with a dive into how RBAC is leveraged by attackers to further compromise and escalate privileges. We then shifted focus to system pods – crucial components with elevated privileges essential for cluster operations that are often involved within attack chains.

Next Up

Look out for the next post within the series where we showcase the learnings from this blog in real-life scenarios, exploring how a chain of misconfigurations in Google’s GKE System Pods constitutes a vulnerability (GCP-2023-047) and enables privilege escalation. By examining specific use cases, we can see how attackers chain together a couple of misconfigurations to escalate privileges, compromise critical resources, become cluster admin, and take control of an entire Kubernetes cluster.