Protecting Kubernetes Clusters with ZeroLock^®

In this white paper, we examine how ZeroLock protects Kubernetes clusters from attacks at runtime.

Why Runtime Security for Kubernetes

First, you might be asking yourself, “What is runtime protection and why do I need it?” It’s a good question, as many organizations rely on configuration management and container scanning to ensure their clusters remain free of exploitable vulnerabilities. While effective at detecting known issues, these methods are not infallible. Vulnerability scanning will miss most new or zero-day vulnerabilities. Every year since 2016, there has been an increasing number of new CVEs discovered. There were 25,227 found in 2022 alone. That’s a lot of new vulnerabilities to keep up with. Every time a new vulnerability is discovered, scanning solutions must create new signatures or methods to detect it. This process takes time, leaving a window of opportunity for attackers. Vulnerability scanners are also not guaranteed to be perfect and can miss known vulnerabilities depending on the environment in which the issue exists.

Second, vulnerabilities and configuration issues that are discovered by a tool must be fixed. It is no secret that ensuring systems remain patched and configured properly is an operational challenge. On average, organizations take 205 days to fix critical vulnerabilities. This operational delay further increases the window of vulnerability in which threat actors can launch exploits.

In contrast, runtime security goes beyond scanning and protects systems from attacks even if they have vulnerable configuration settings or run exploitable applications. ZeroLock contains detection and response capabilities for malware, exploitation attempts, and provides ways to implement virtual patching of vulnerable applications. These capabilities are designed with Kubernetes-specific threats in mind. For more reading on the importance of runtime security, check out the following article published in Forbes by Vali Cyber’s CTO, Austin Gadient.

Protecting Kubernetes with ZeroLock

In this section, we demonstrate a series of attacks against a simple Kubernetes cluster and show how ZeroLock protects against these attacks. Figure 1 displays the network architecture for the scenario. The attacker is trying to compromise the cluster by launching attacks against a pod running a vulnerable web app. The attacker launches their exploits and malware from the Kali Linux machine. When running in a Kubernetes cluster, ZeroLock deploys as a daemonset, meaning there is a single pod deployed per node in the cluster.

To deploy ZeroLock in the cluster, we simply apply the ZeroLock manifest. The manifest runs ZeroLock pods as a daemonset on each node in the cluster. Figure 2 displays the kubectl apply command and the ZeroLock pod that it creates.

There are two nodes in this simple cluster, the worker, and the master. The nodes check themselves into ZeroLock’s management portal after the ZeroLock manifest is applied.

Now, we turn our attention to the attacker. The attacker first attempts to exploit a Log4J vulnerability in the webapp under its protection. The attacker places an exploit string that establishes a reverse shell session to their netcat listener as displayed in Figure 4.

When the attacker attempts to launch the exploit, it is immediately caught and denied by ZeroLock. The attacker’s reverse netcat shell is killed before it can connect back to its command-and-control infrastructure. This attack highlights ZeroLock’s virtual patching and anti-exploit capabilities. ZeroLock prevents containers in your Kubernetes cluster from being exploited even if they have vulnerabilities or misconfigurations.

At this point, the attacker is no longer able to exploit the system. To further highlight additional Kubernetes specific detection and response features, we must disable ZeroLock’s Log4J exploit detection and allow the attacker to advance. So, we allow the exploit to succeed. Now, the attacker will try to compromise other hosts in the cluster. First, they will enumerate the secrets under the /run/secrets/Kubernetes.io/serviceaccount directory through their netcat session. As you can see in Figure 6, the attacker is able to access the ca.crt certificate file and the Kubernetes API token. The attacker will use these files to craft a command with kubectl and enumerate the pods running in the cluster.

Now, the attacker will attempt to download a kubectl binary they can use to interact with the cluster controller’s API. Fortunately, ZeroLock detects this attempt too. The attempt to download is immediately detected and blocked and all malicious processes in the process tree are killed. The details of the malicious wget command are displayed in Figure 7.

The attacker is unable to subvert the cluster. So, they will now resort to launching a ransomware attack against the container they were able to compromise. The attacker will attempt to encrypt the web server’s HTML assets. This attack is also detected and remediated by ZeroLock’s ransomware detection engine. The process tree for the alert is displayed in Figure 8. All encrypted files are restored and the malware that was downloaded onto the system is removed.

In summary, ZeroLock provides an advanced runtime protection solution for Kubernetes clusters. ZeroLock’s anti-exploitation capabilities prevent attackers from gaining access to vulnerable containers. If an attacker can access a container, behaviors associated with cluster compromises such as downloading cluster management tools are detected. Remediation capabilities are extensive, allowing defenders to manually intervene or enable ZeroLock’s automated capabilities. Finally, ZeroLock containers behavioral malware detection engines stop attacks that commonly target clusters such as ransomware and cryptomining, allowing you to better ensure zero-downtime of your containerized applications.

To learn more about ZeroLock self-protecting containers, or to schedule a demo, email [email protected].