Kubernetes end-to-end chain exploit
Situation
Software deployment, scalability, and management may all be automated using Kubernetes, an open-source container orchestration system. As a result of the potential new difficulties that developers may encounter when working in multi-cluster environments, they seek to implement GitOps tools that expand Kubernetes’ capabilities to automate infrastructure updates, configurations, and policy management within the clusters and to deploy their applications in a secure and well-organized manner. The most widely used GitOps tools are listed below:
- ArgoCD https://github.com/argoproj/argo-cd
- Helm https://helm.sh/
- GitLab https://about.gitlab.com/
- GitHub https://github.com/
And the list goes on…
The cloud technology trend is grabbing the attention of developers in numerous fields. DevOps engineers are now considering migrating the Kubernetes system to the cloud because of its great efficiency, simplicity of use, high reliability, and numerous other benefits. With the assistance of top businesses in this sector, like AWS, GCP, Azure, etc., this change is now doable.
With great power comes great responsibilities
Despite this paradigm shift’s many advantages, it puts Kubernetes and GitOps tools in front of new risks. Furthermore, the usage of these tools over the cloud requires more attention to the cloud-related security threats to reduce the risks that may reach to put the infrastructure at risk.
This article and the articles it links to detail the security flaws we discovered in Kubernetes and the used GitOps tools as a result of improper configurations. Show how an attacker can use these cloud-hosted tools to perform post-exploitation attacks, increasing their privileges and the size of the attack surface.
Impact
Important key findings from the security review we performed for one of our clients are as follows:
- Kubernetes — Pod Escape [1]
- ArgoCD — Retrieve AWS EC2 security credentials [2]
- GoCD — Agent Remote Command Execution (RCE) through Command Argument Injection [3]
The results demonstrate how an attacker with limited privileges can expand the attacked domain. Unauthorized users may be able to access administration interfaces that are available to the public if developers don’t adhere to security best practices during implementation and deployment.
There will always be people out to steal sensitive user information. Therefore, the first step is typically an attack on the infrastructure, followed by an attempt to gain unauthorized access so that the attacker can inject malicious code into the system and then target the users.
Path
This section will explain the final steps we took to gain unauthorized access to Infrastructure and various GitOps applications and ultimately take full or partial control of the infrastructure.
Initial Footstep
We were granted with limited rights credentials on Kubernetes with Namespace Editor (a.k.a. Edit role). These credentials have granted us access to the Kubernetes dashboard. Then, we were able to execute our privileged pod[1] to escape the namespace and obtain access to data from other namespaces and pods.
ArgoCD attack over the cloud
After executing our privileged pod, we were able to acquire the password for the ArgoCD administrator, allowing us to begin lateral movement throughout the infrastructure. With a deeper understanding of the application’s capabilities, we were able to get AWS tokens[2] that granted us access to the AWS infrastructure with an excessively permissions to manage all EC2 instances.
Attacking GoCD
Due to a lack of fundamental security awareness, we were able to reuse the same password for ArgoCD on GoCD, and it worked! However, after logging in with pipeline operator credentials, we detected a command-line argument injection that led to a GitHub account access token leak[3]. In addition, we discovered that these credentials had read and write access to many unpublished sensitive repositories.
Solution
When Kubernetes, GitOps, and the Cloud are utilized safely by developers adhering to security best practices, these technologies are remarkable. We have outlined recommended steps for mitigating the vulnerabilities identified in each article [1][2][3].
As each component plays a significant role in the infrastructure, guaranteeing security and the secure movement of resources and information between them is crucial for the secure deployment of applications and, by extension, the security of users. We strongly suggest implementing additional security controls, not only generic controls but also more specific and technology-related controls that prevent the misuse of each component, to prevent hackers from carrying out attacks outside the vulnerable components and gaining unauthorized access to the rest of the components, thereby putting infrastructure and application end-users at risk.
