Using Kubernetes Raises Security Stakes: Three Attack Paths

There’s really no question when it comes to which container orchestration platform leads the market – yeah you guessed it, It’s Kubernetes. In recent years, use of Kubernetes by development teams has grown massively and this trajectory is only set to continue. The reason? The ease and flexibility it provides for managing and deploying applications across various environments is unparalleled. 

Yet as critical as Kubernetes is for the management of applications, it also opens many new security issues that are increasingly exploited by attackers. Since their security needs span the entire application lifecycle – from development through deployment and maintenance – containers present particular security challenges. 

Kubernetes security concerns are so prevalent that in a recent study, 93% of respondents asserted that they had experienced at least one K8s-related security incident in the 12 months preceding the recent survey. Many suffered revenue or customer loss, and over half had to delay an application rollout. Yet while exposures and Kubernetes vulnerabilities are very common, misconfigurations are an even greater challenge. Since Kubernetes is highly customizable, tweaks to various configuration options can affect application security unintentionally. Respondents to the above survey were three times more concerned about exposures owing to misconfigurations than they were about attacks. 

Seeing is Believing – Three Kubernetes Attack Paths 

It’s not hard to see why security needs to become more top of mind when using K8s. And one of the best ways to understand the threats to Kubernetes deployments is to examine the threats to Kubernetes clusters, up close and personal. In this blog, we’lll show you 3 attack paths our team came across at enterprise customers which clearly demonstrate how dangerous it can be when exposures like CVEs/vulnerabilities, identity issues, misconfigurations and other security gaps chain together.

Taken on an individual basis, most exposures can’t be significantly leveraged by an attacker. But attackers don’t look at individual exposures. Instead they use these combinations to reach sensitive assets. This allows them to cause significant and ongoing damage while hiding inside networks. 

So now, let’s have a look at the 3 paths we came across that clearly illustrate how understanding attack paths helps us see how attackers compromise critical assets. By understanding how attacks could have occurred, we can understand how to prevent similar attacks in the future. 

Kubernetes Attack Path #1 – Active Directory to Kubernetes

The Path:

This is a hybrid attack path that gives attackers the ability to move from the enterprise world into the  kubernetes. Active Directory is an attractive starting point for attackers as it’s open to the world and users can get emails, download malicious things, etc. 

• The attacker starts with an Active Directory user. Then from the user, they can reset the password of another user. 
• This AD user is a member of a security group which has permissions to add members to another group. From there, the attacker gets to another security group, by adding a user. The compromised group has permissions to perform resource based constrained delegation which allows the attacker to compromise a computer account.
• Once there, the attackers can get to all the resources on the computer, and then you can start looking for credentials, in this case the attacker found the Kubernetes certificate.
• From the certificate, the attacker can enter the Kubernetes cluster as a user, such as a developer who has high permissions on the cluster.
• Once the attacker has a strong user, everything is open and the impact could be a complete compromise of the Kubernetes cluster.

By the way, this is how crypto mining is done, and in fact is what happened in the recent Tesla breach, when attackers broke into a Kubernetes cluster and increased the scale to use it for crypto mining.

Kubernetes Attack Path #2 – AWS to Kubernetes

The Path:

XM Cyber is always checking which identities from the given cloud provider (in this case, AWS) can enter into the cluster and the level of permissions they have been granted. Permissions can always be limited and this is critical in order to reduce the attack surface from identities. This following example illustrates an attack path that’s not necessarily a “game over” path but it shows what might happen with over permissive identities within the kubernetes cluster.

• An attacker was able to compromise an AWS user. After performing reconnaissance within the AWS account, the attacker understands that the user has permissions to execute code on EC2 instances by abusing the SSM agent.
• After compromising EC2 instances, the attacker was able to understand that one of the instances has a role attached to it, which allows the attacker to gain access into the role.
• Abusing the role permissions allows the attacker to compromise another AWS.
• The user has a cluster role binding within one of the critical Kuberenetes clusters. 
• Abusing the cluster role allows the attacker to compromise all the secrets within the cluster, some of them are highly sensitive.

Kubernetes Attack Path #3 – Kubernetes Native

The following attack path happens inside the Kubernetes cluster. What’s interesting here is that one of the best practices in Kubernetes is to use Namespaces for segregation of assets inside the cluster. But if you don’t have a tool to help you visualize all the configurations and permissions, how can you be sure that the attacker will be able to move from one namespace to another?

The Path:

• The attacker started from a pod in a specific Namespace, where they found a secret. 
• The secret represents a service account attached to the pod.
• From the Service Account, they compromised a cluster role.
• Abusing the cluster role permissions allows the attacker to generate a service account token which allows the attacker to compromise another service account.
• The service account has cluster role permissions which allows him to read all configmaps.
• Even though it’s not a best practice, one of the config maps contained highly sensitive domain credentials.

The Bottom Line

Kubernetes is an unparalleled force for managing and deploying applications across diverse environments. However, its increasing adoption has unveiled a dark side – heightened security challenges and Kubernetes has become a prime target for attackers, leading to a surge in security incidents. 

Mapping attack paths is a key asset in the battle for K8s security – enabling a holistic view of risks within Kubernetes clusters and helping prioritize and mitigate vulnerabilities strategically. Gaining context of the actual risk towards critical assets in Kubernetes clusters helps you accurately prioritize issues and focus on remediating exposures where attack paths converge at choke points, first. 

Delving into Kubernetes attack paths isn’t just an exercise in understanding the past – it’s a proactive step toward fortifying defenses in the future.

Want to learn more about Kubernetes attack paths and how XM Cyber is helping organizations secure their clusters? Grab your spot for a demo today.