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.
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 malwares like Cetus and Graboid, and orchestrated campaigns exploiting CI/CD tools are a threat. Vulnerable Docker instances have also been targeted by DDoS malwares 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 absolutely 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.
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.
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.
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…
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. Even a classic CVE can become a greater threat when 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 these 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.
Get updates on blog posts, new releases and more!