Modal Title
Kubernetes / Security

Kubernetes: An Examination of Major Attacks

Kubernetes is not immune to attacks. Organizations must bolster observability, regularly audit their environment and apply security patches.
Jun 15th, 2021 8:00am by
Featued image for: Kubernetes: An Examination of Major Attacks
Featured image via Pixabay.

Manoj Ahuje
Manoj is a senior threat intelligence research engineer at Tigera, where he closely monitors trends in the cloud security industry, with a specific focus on threats targeting Kubernetes environments. Manoj has extensive experience in vulnerability analysis, exploit development and malware reverse engineering.

In a never-ending game of cat and mouse, threat actors are exploiting, controlling and maintaining persistent access in compromised cloud infrastructure. While cloud practitioners are armed with best-in-class knowledge, support and security practices, it is statistically impossible to have a common security posture for all cloud instances worldwide. Attackers know this and use it to their advantage. By applying evolved tactics, techniques and procedures (TTPs), attackers are exploiting edge cases. As a result, organizations like Capital One, Jenkins, Docker and many others have experienced high-profile breaches.

TTPs are defined as “patterns of activities or methods associated with a specific threat actor or group of threat actors.” TTPs describe how threat actors (the bad guys) orchestrate, execute and manage their operations attacks. Analysis of TTPs can benefit security operations by providing a description of how threat actors performed their attacks. Kubernetes is not immune to TTPs. Let’s examine some recent cases within the Kubernetes ecosystem.

Case #1: Misconfigured Docker

If you’re an attacker looking for misconfigured Docker instances to exploit, it’s as easy as probing open ports 2375, 2376, 2377, 4243 and 4244 on the internet. Vulnerable instances can also be located using search engines like Shodan. Organized threat actors like TeamTNT have been observed using legitimate Kubernetes monitoring tools like Weave Scope to backdoor these Docker instances.

In addition, Docker configuration flaws are being exploited by crypto-jacking malware like Cetus and Graboid and orchestrated campaigns exploiting CI/CD tools are a threat. Vulnerable Docker instances have also been targeted by DDoS malware like XORDDoS and Kaiji, which use those resources to increase their DDoS capacity.

For organizations that are using Docker, deploying cloud provider firewalls like AWS security groups as a defense is essential. Consider investing in observability tools to monitor running containers, CPU utilization and network activity. Security teams can also benefit from embedding threat intelligence into the cloud and monitoring risk thresholds.

Case #2: Malicious Docker Images

Public image repositories have become an easy tool for distributing malicious images disguised as custom configurations. An example that illustrates the reach of this attack vector is an incident with Docker Hub, where a malicious image was pulled 5 million times before being removed. This underscores the need to check your base image sources, regardless of whether you are creating your own or using images from a public repository. Forensic analysis tools like dive, as well as Docker itself, can help you check image history.

Case #3: Unintentional Cluster Misconfiguration

A considerable amount of trust is placed in cloud providers to configure, patch and manage Kubernetes security on our behalf. Sometimes, however, things can fall through the cracks. Even the most highly trusted cloud services can be susceptible to configurations that unwittingly enable privilege escalation and facilitate the takeover of the cluster.

A blog post by Christophe Tafani-Dereeper demonstrates the disastrous consequences that compromising a pod in the cluster can have on resources in an AWS account if access to the Instance Metadata Service (IMDS) is not explicitly blocked. The unlucky author reached the metadata service from a compromised pod to retrieve an Identity and Access Management (IAM) role credential. Unfortunately, by default, the IAM role had too many permissions, resulting in privilege escalation. In hindsight, this could have been preventable through continuous auditing of managed environments and early detection of security gaps.

Kubernetes vs. Kubernetes

Occasionally, Kubernetes can be its own worst enemy. Components like kubelet, controller-manager and etcd can be exploited with the goal of obtaining a higher level of privilege and persistence in the cluster. Remote code execution inside a container can be accomplished using kubelet’s unauthenticated, undocumented API. Kubernetes threat actor TeamTNT is seen exploiting this flaw in the wild. Rhino Security Labs showed how an attacker can join as a fake worker node.

Here are some other ways that Kubernetes can be used against itself:

  • A second kubelet can be run on a node so that the same node will be part of two different clusters, one of which will be attacker-controlled.
  • Privileged pods can escape containers and provide root access to the host by abusing Linux functionality like CGROUPs.
  • If a hostnetwork-enabled pod is present, it can attack an underlay network on Kubernetes.
  • A malicious webhook can intercept and modify requests made to the Kubernetes API. This is evasive and hard to detect in production clusters.
  • The pod network can be used to exploit VXLAN and IPIP networks in the Kubernetes cluster.
  • Using insecure root mounts, the host filesystem can be accessed inside a pod.
  • Kubernetes CronJobs/jobs can be used to backdoor the cluster.
  • Pod default tokens can be used to get access to privileged resources if misconfigured.
  • Kubernetes ExternalIPs can be used in man-in-the-middle attacks.

Summary

Constant vigilance is required to ensure that cloud infrastructure is locked down and that DevSecOps teams have the right tools for the job. Cloud adds a new dimension and increases an organization’s attack surface, creating potential opportunities for attackers. Even a classic vulnerability can become a greater threat when the cloud is factored into the equation. To effectively respond to this new security paradigm, it’s critical for cloud security teams to understand the impact of each of the common vulnerabilities and exposures (CVEs) and be prepared to apply mitigation when they are detected.

Threat actors are using evolved TTPs to exploit, control and maintain persistent access in compromised cloud infrastructure. Early detection of anomalous behavior is paramount and can go a long way in speeding detection, investigation and mitigation of threats. Using the most recent advances in data science and machine learning techniques, organizations must bolster their cloud observability capabilities, regularly audit their environment and apply the latest security patches as they become available.

Want to learn more about cyber threat protection strategies and tactics for Kubernetes? Read about the latest eBPF vulnerability, its impact on Kubernetes, and how to mitigate it, and check out the replay of this hands-on workshop for Kubernetes security.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma, Docker, Tigera.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.