Detecting and Responding to Kubernetes Ransomware Attacks: A Guide for IT Professionals

As Kubernetes continues to be adopted for container orchestration in cloud-native environments, the risk of ransomware attacks targeting Kubernetes clusters grows. Ransomware attacks can cripple operations, compromise sensitive data, and incur significant financial losses. This guide aims to equip IT professionals with strategies to detect and respond effectively to Kubernetes ransomware attacks, thereby minimizing their impact and mitigating risks.

Kubernetes continues to grow in popularity for the automation of at-scale software delivery, deployment and management in containerized environments. But many organizations see the threat of ransomware attacks as a showstopper to adopting it. A Red Hat survey of more than 500 DevOps, engineering and security professionals found that 55% of them had delayed deploying Kubernetes applications into production because of security concerns.

While security worries can postpone a Kubernetes rollout, the rising threat of ransomware doesn’t seem to have dampened Kubernetes adoption. In Red Hat’s survey, 88% of respondents said their organization uses Kubernetes for container orchestration and 74% have adopted Kubernetes in production environments.

As Kubernetes deployments continue to increase, the number of attack vectors, in theory, is expanding as well, helping to explain in part the surge in ransomware attacks and resulting damages for these environments. Kubernetes clusters, as well as containers in general, are vulnerable as entry points for intruders seeking to orchestrate ransomware attacks, due largely to their highly distributed nature. As they scale, the number of microservices deployed results in many interdependencies that can be exploited.

Ransomware attacks have understandably garnered attention by the U.S. government, culminating in an official memo from the White House, issued back in June 2021, urging corporate executives and business leaders to take specific steps to protect their assets. In July, the National Security Agency (NSA) issued a report specific to Kubernetes security. Each offers a trove of information, with plenty of overlapping guidance, on how to protect Kubernetes clusters from ransomware attacks.

The White House report makes it clear that ransomware attacks are usually preventable. Once Kubernetes ransomware risks are understood, there are specific and reasonable steps an organization can take for protection.

The Weakest Links

Vulnerabilities in Kubernetes environments that ransomware attackers exploit are much like those hit by other kinds of attacks. They often result in data theft and destruction, the theft of expensive computing resources via a cloud provider account, illicit mining for cryptocurrency, denial-of-service attacks (DoS) and other security-related incidents. Ransomware, specifically, involves an attacker blocking access to data and applications — typically through encryption — and extorting an organization to pay a ransom to resume access.

The underlying framework of a Kubernetes cluster lends itself to numerous attack entry points among Kubernetes components:

The Kubernetes API server.

The etcd server client for key-value storage.

Kubelet for node management.

A kube-scheduler used to assign pods to nodes.

A kube-controller-manager.

And for those relying on cloud providers, a separate kube-controller manager for cloud environments.

While less complex to implement and manage, virtual machines (VMs) do not offer the immense advantages that Kubernetes does for developing and managing applications, but they are easier to lock down, as VMs running Linux, Windows or another operating system are largely self-isolated. They don’t share the underpinning operating system, whereas in a Kubernetes deployment, all the containers running in each node do.

If a Kubernetes node is compromised, all pods on the node are affected, which can put the entire cluster to which the node belongs at risk. Consequently, all containers within that cluster can be exploited because unlike VMs, they share the same kernel of the same host.

In the world of Kubernetes, every node, cluster and container can share a number of resources — and vulnerabilities — in addition to a common operating system. All it takes is for a single microservice to introduce vulnerabilities among multiple containers. The potential attack vectors lurking within a container supply chain are as numerous as the microservices connecting the containerized environment.

Inherent within the Kubernetes cluster is another source of trouble: secrets management. Used to provide tokens for APIs, passwords and other sensitive data, secrets have their own vulnerabilities. Ingress controllers and other components, for example, are configured to access secrets within the entire cluster. Moreover, secrets are largely unencrypted. While some encryption schemes do exist — including an option Kubernetes offers for encrypting secrets — those alternatives are still being beta tested or are not 100% secure. DevOps teams are rightly wary of using them in production environments.

The Lurking Predators

A ransomware attacker seeking to exploit a vulnerability in a Kubernetes environment will likely use automated tools to scan for vulnerabilities. Many scanning tools can be bought online from the dark net, even sometimes via public forums such as Reddit, for just a few hundred dollars. The attacker finds a way to penetrate a cluster and then waits while their automated scanning tool uncovers an angle of attack.

More direct routes to data exist for ransomware attackers. For more than eight years until the vulnerability was recently widely disclosed, a simple scanning tool could seek and find standard ports for MongoDB databases that were exposed by default for several years. During that time, any MongoDB customer admin — or intruder posing as one — had read-write access to these MongoDB databases through the unsecured ports, which were also unencrypted. This meant that an organization that deployed a MongoDB database in a Kubernetes or containerized environment on, for example, Amazon Web Services (AWS) could expose the database to the world through commands that required no credentials for access.

Read Informative Blogs