Hacking Kubernetes: Cloud attacks

Disclaimer:  

The content presented in this lab is intended solely for educational purposes and informational use. The purpose of this lab is to provide a practical understanding of cloud attacks, specifically as related to Kubernetes, and their potential impact on web security. It is not intended to promote or encourage any malicious activities or harmful actions against real-world websites or individuals. 

Participants are advised to conduct lab exercises within a controlled environment and refrain from using the knowledge gained to engage in any unauthorized or illegal activities. Any attempt to perform attacks on live websites or systems without explicit authorization is strictly prohibited and may lead to severe legal consequences. 

The lab materials, including code snippets and demonstrations, are provided as educational resources only. The instructors and creators of this lab are not responsible for any misuse or unintended application of the knowledge acquired during the learning process. 

By accessing and utilizing the lab materials, participants agree to use the information responsibly and ethically, respecting the principles of cybersecurity and online safety. If you have any concerns or questions about the content or exercises, please seek guidance from authorized instructors or cybersecurity professionals. 

Remember, responsible learning and ethical conduct are essential for fostering a safe and secure digital ecosystem. Let's use this lab to enhance our knowledge, promote cybersecurity awareness, and contribute to a safer online environment for everyone. 

Introduction

Kubernetes has rapidly emerged as the industry standard for managing and orchestrating containerized applications, addressing the complexities of modern software deployment and scaling with remarkable effectiveness. As organizations increasingly embrace Kubernetes to support their cloud-native architectures, they take advantage of its powerful features that automate deployment, scaling, and operational management of application containers. This evolution enhances agility and resource efficiency, enabling teams to respond swiftly to market demands. However, alongside these benefits, significant security challenges arise that organizations must confront to protect their critical applications and data.

In this context, we are utilizing Kubernetes Goat, a deliberately vulnerable Kubernetes environment, to delve deeper into the security issues prevalent in such systems. This platform provides a safe environment for experimenting with real-world attack scenarios, allowing us to explore the ramifications of various vulnerabilities without risking production systems. Through our exploration, we have successfully identified a server hosting Kubernetes, exploiting a range of security gaps, including the unauthorized access of sensitive keys within the codebase, Docker in Docker exploitation, and container breakout attacks.

In the following sections, we will delve into the detailed findings of our work with Kubernetes Goat, exploring each of the vulnerabilities we encountered and discussing best practices for securing Kubernetes environments against potential threats. Through this examination, we aim to provide insights that will help organizations prioritize security and adapt to the ever-evolving landscape of cybersecurity threats.

Identification of Kubernetes on Target System 

Typically, an attacker would effectively assess the security posture of a Kubernetes cluster; an attacker needs to enumerate the target system systematically. This process helps identify potential vulnerabilities or misconfigurations that could be exploited. Initially, this phase's tools, such as Nmap and Kube Hunter, serve as critical assets. Nmap allows for comprehensive network mapping and port scanning, providing insight into the accessible services and potential entry points within the cluster. By revealing open ports and running services, Nmap helps outline the attack surface that may be exploited. Simultaneously, Kube Hunter, which is specifically designed for Kubernetes environments, can be employed to identify misconfigurations and vulnerabilities unique to container orchestration systems. This tool scans the API server and various components of the Kubernetes environment to detect common security issues, such as exposed dashboard interfaces, improper role-based access control (RBAC) settings, and other security weaknesses. However, since this cluster is being run locally, the tool Kube Hunter will not be displayed.  The only thing that will be displayed is the port of Kubernetes Goat and the main page of Kubernetes Goat. 

Figure 1 Kubernetes Goat

Figure 2 Main Page of Kubernetes Goat

Sensitive keys in code base

In today's cloud-native environments, managing sensitive keys and secrets is critical for developers and operations teams, particularly when working with Kubernetes. As applications are deployed and scaled in dynamic clusters, the risk of exposing sensitive information increases significantly, such as API keys, database passwords, and tokens. Hardcoding these keys directly into the codebase poses security vulnerabilities and complicates application maintenance and deployment processes. Moreover, unauthorized access to sensitive data can lead to data breaches or service disruptions, making it essential for teams to adopt robust strategies for secure handling. This necessitates focusing on best practices for managing sensitive keys in Kubernetes, ensuring that security is integrated into the development lifecycle while maintaining efficiency and scalability.  

Figure 3 Sensitive Key Main Page

The attacker thoroughly analyzed the specified environment, noting that the webpage referred to containers with various CI/CD pipelines, including platforms such as GitHub, Docker, AWS, and others. Following this initial assessment, the next stage involved executing a directory brute-force attack to uncover any sensitive directories associated with the code that might be present within the system. This systematic approach was designed to identify potential vulnerabilities and access points that could be exploited.

Figure 4 Directory Scan

The attacker identified the presence of a .git/Head folder and utilized the Git tool developed by Internetwache. The repository can be found at https://github.com/internetwache/GitTools. This tool is designed to perform various functions, including downloading as much content as possible from a .git repository, extracting commits and their contents, and scanning for websites that host their .git repositories. 

The attacker is in the process of dumping files, as illustrated in the screenshots below. Once the files have been downloaded, the next step involves executing critical commands through the containerd.sock Unix socket. This allows us to retrieve images from the system, as demonstrated in the accompanying screenshots.

Figure 5 Downloading .git Folder

The attacker examined the. git folder but found no valuable information. Subsequently, the attacker turned to the commit logs to verify if any noteworthy details might have been overlooked. This command lists all commit hashes in the repository in reverse chronological order, beginning with the most recent commits. The logs include pertinent details such as email addresses, timestamps, and messages added by contributors during each commit.

Figure 6 Examining git commit Logs

The entered command git show provides detailed information about various Git objects, including blobs, trees, tags, and commits. During testing, the reviewer examined the list of commit hashes and noticed that after the third commit hash, there was exposure of sensitive information, specifically an AWS access key and AWS secret. This underscores the importance of securely handling and managing sensitive data within version control systems. Now, lets go ahead and get into mitigation and then go on to the next scenario. 

Figure 7 Retrieving AWS long-term Programmatic Keys

Mitigation

To mitigate risks related to sensitive information in a Kubernetes codebase, consider utilizing Kubernetes Secrets to store data like API keys and passwords instead of hardcoding them. Implement Role-Based Access Control (RBAC) to restrict access and pass sensitive keys through environment variables. Additionally, enable encryption for data at rest and in transit, conduct regular audits, and enforce code reviews to avoid accidental exposure. Automating secret management with tools like HashiCorp Vault can further enhance security measures. Overall, these practices help protect sensitive information effectively. 

Container Breakout 

A container breakout occurs when an attacker gains unauthorized access to the host system or other containers, circumventing the isolation mechanisms to keep them secure. This can lead to significant data breaches, compromise of sensitive information, and even full system control. In a Kubernetes environment, where containers are frequently deployed, scaled, and interconnected, the potential impact of a breakout can be profound. Understanding the mechanisms behind container breakouts and implementing robust security practices is essential for safeguarding Kubernetes clusters and ensuring the integrity of applications running in this dynamic landscape.

When attempting to escape a container, it's crucial to stay observant and search for anything that could help you break free. Begin by assessing capabilities to understand what you can and cannot execute. Our first step involved downloading and running deep.sh to verify whether we were inside a container. Next, we need to explore what additional capabilities or permissions we possess. This knowledge can be essential in formulating our escape strategy.

Figure 8 Container Identification

Figure 9 Capabilities Identified

It has been confirmed that we are currently operating within a Docker container. Upon thoroughly examining our environment, we have identified numerous potentially hazardous capabilities that malicious actors could leverage. For instance, the container may possess broader access to critical system resources or sensitive data, which, if exploited, could result in significant security vulnerabilities. Furthermore, inadequate isolation could allow unintended interactions with other components of the host system, heightening the risk of unauthorized access. One particularly concerning aspect is the presence of the `dc_override` capability, which can grant the container enhanced privileges, including the ability to exercise `cap_sys_admin`. This capability is often referred to as one of the most powerful Linux capabilities, as it can provide access to a wide range of administrative functions and resources. If an attacker could gain control over a container with `cap_sys_admin`, they could potentially escalate their privileges to manipulate or compromise the integrity of the host system itself. 

Next, the attacker noticed something odd: the directory host-system seemed particularly interesting when displaying all the directories. The attacker then decided to view that directory to see what was inside, such as the host system in the file system. However, it could have been just another directory to lure attackers in and try to mess with files with a trip wire attached.

Figure 10 Directory Listing

When the attack looked at the directories, a directory of Mike was found. However, it brought nothing of substance. When analyzing the configuration of this pod, it is inadequate, as it grants the root user full access to critical capabilities, including cap_chown. This poses significant security risks, as allowing unrestricted root privileges can lead to potential vulnerabilities and exploitation. The attacker subsequently executed a chroot (change root) operation, which is highly perilous as it alters the root directory for a particular process and its descendant processes. The sky is the limit once the attacker has broken out of the container and has root privileges. By looking at the admin, they can look for the brain of Kubernetes, which is called the control plane.The conf file is located in the /etc/Kubernetes folder, or you can look at the Kubernetes system. In this case, minikube was used to set up Kubernetes since it was used on a local system. Now, let us go ahead and get into mitigation and then go on to the next scenario.

Figure 11 Getting all Data on Kubernetes Cluster

Mitigation 

Adopting a layered security approach to mitigate the risk of container breakout in Kubernetes. Use namespaces for workload isolation and implement pod security policies to restrict privileged access—Configure containers to run as non-root users and set filesystem permissions to read-only where possible. Define resource quotas to prevent excessive consumption by any single container. Network policies can control the traffic flow between pods, limiting lateral movement. Regularly scan container images for vulnerabilities and ensure only trusted images are used. Keep Kubernetes and container runtimes updated with the latest security patches and review audit logs to monitor suspicious activity. By integrating these measures, you can significantly enhance the security of your Kubernetes environment.

DIND (Docker in Docker attack) exploitation

Kubernetes has become the go-to solution for managing and scaling containerized applications in container orchestration. However, as with any technology, it is not without its vulnerabilities. One notable threat is the Docker in Docker (DinD) attack, which exploits the Docker daemon's privileges to gain unauthorized access to the host system or other containers. This attack capitalizes on the layering of container technologies, enabling malicious actors to run a Docker daemon within a container, potentially allowing them to break out of the container isolation. In a Kubernetes environment, containers are orchestrated and deployed dynamically, and the risks associated with DinD can escalate quickly. Understanding this attack vector is critical for securing Kubernetes clusters and implementing effective countermeasures to protect sensitive workloads and maintain the entire system's integrity.

When visiting the webpage, the attacker noticed that it functions as an application capable of pinging external systems, which raises some concerns. Typically, applications with this feature can be susceptible to command injection vulnerabilities. Command injection occurs when an attacker exploits a flaw in the application to execute arbitrary commands on the server operating system. This can lead to significant security risks, including unauthorized access, data manipulation, or service disruption.

Figure 12 Main Page

The attacker leveraged this vulnerability to run commands with root access. This means they can access sensitive files and manipulate the system's core functionalities. When the attacker executes a command that reveals their current permissions, they might see something like “You are now logged in as root.” In this case, the id command shows what identification the server is being run at, which appears to be root shown in the screenshot below.

Figure 13 Command Injection Identified

Since this appears to be the filesystem, we know it is on some machine. So, we must figure out what that is. The attacker attempted to cd into other folders. However, it would not let him. Next, we should see what type of system we are dealing with here, so we will use the ; mount command. We first checked to see if it was a docker.socket, it appears that it is not.  However, it seems to be leaking containered sockets, which are Unix sockets, shown in the screenshot below.

Figure 14 Containerd.socket Leak

The attacker must first identify the architecture type of the target container to proceed effectively. This determination is critical, as it directly influences the selection of the appropriate binary for exploitation. To achieve this, the `uname -a` command should be utilized, which provides comprehensive information about the system's kernel and architecture. A screenshot illustrating this command's execution is provided below for reference. Properly assessing this information is imperative to ensure that the binary downloaded is compatible with the container's architecture, thereby optimizing the chances of a successful attack.

Figure 15 Architecture of File System

Once the attacker has comprehended the system architecture, the subsequent step is to initiate the file download utilizing the wget command. Following the successful download, it is crucial to extract the file's contents into the designated /tmp directory, as illustrated in the accompanying screenshot.

Figure 16 Extracting of crictl file in the tmp Folder

With the complete successful download, we can proceed to the engaging aspect of our task: accessing the system via essential commands utilizing the crictl binary and passing the `containerd.sock` command to view Unix socket. This allows us to retrieve and manage images stored within the system effectively. The process will be illustrated through the accompanying screenshots, which clearly represent the steps undertaken. This method enhances our understanding of the underlying architecture and shows image retrieval.

Figure 17 Running of the crictl images Command

Figure 18 Images Displayed

Mitigation

Docker-in-Docker (DinD) poses security risks in Kubernetes due to potential misconfigurations that could expose the host. Implement strict pod security standards to limit container capabilities and prevent privilege escalation to mitigate these risks. It’s best to avoid DinD using alternatives like sidecar containers for CI/CD tasks. Control resource access through namespaces and Network Policies and enhance security with Docker features like user namespaces and seccomp profiles. Regularly audit permissions and monitor runtime behavior to detect vulnerabilities. These measures can significantly reduce the risks associated with Docker-in-Docker in Kubernetes environments.