The first known proof that attackers are using Kubernetes (K8s) Role-Based Access Control (RBAC) in the field to construct backdoors was found by specialists. DaemonSets were also deployed by the malicious actors in order to seize control of the K8s clusters they attacked and steal their resources. An incorrectly configured API server that permitted unauthenticated queries from anonymous users with privileges was the entry point that allowed first access to be acquired. The attacker issued a few HTTP queries to list secrets and then performed two API calls to get information about the cluster by listing the entities in the ‘kube-system’ namespace. These requests allowed the attacker to discover information about the cluster. After then, the adversary searched for a deployment with the name ‘kube-controller’ in order to determine whether or not an attack had previously been carried out on this particular cluster.
Additionally, the attacker tried to remove several already-existing deployments from namespaces like “api-proxy,” “worker-deployment,” “kube-secure-fhgxtsjh,” and “kube-secure-fhgxt.” In order to maximize the amount of CPU that was available and lower the likelihood of being found if the server was full, we presume that the attacker was stopping older campaigns or rival campaigns.
When the attacker employed RBAC to acquire persistence, that was the most fascinating component of this attack. An additional ClusterRole with almost administrative powers was established by the attacker. Because it was a cluster role, it was not restricted to any one namespace in particular. After that, the adversary established a ‘ServiceAccount’ with the name ‘kube-controller’ under the ‘kube-system’ namespace. In the last step of their attack, the malicious actor built a ‘ClusterRoleBinding,’ which bound the ClusterRole to the ServiceAccount in order to provide a persistent state that was both robust and covert.
At this stage, the attacker has generated persistence that enables for continued exploitation of the cluster. This is true even in the event that access for anonymous users is blocked. In addition, attaching the ‘cluster-admin’ role to a new or questionable user may trigger alerts; nevertheless, the adversary devised a cunning technique to blend in beautifully with the API audit logs. This was accomplished by creating a creative approach to blend in. In the end, the attacker would be able to stay under the radar without triggering any warnings by configuring the ClusterRoleBinding to access “system:controller:kube-controller.” This binding seems to be completely acceptable.
After that, the malicious actor constructed a DaemonSet in order to distribute containers across all nodes using a single API call. The container image known as ‘kuberntesio/kube-controller:1.0.1’ was included in the DaemonSet formation request object. This image was stored on the public registry known as Docker Hub.
The container image with the name ‘kuberntesio/kube-controller’ is an example of typosquatting that is attempting to spoof the real ‘kubernetesio’ account. In spite of the fact that it only has a few dozen container images, it has gathered millions of pulls. The image also imitates the well-known ‘kube-controller-manager’ container image, which is an essential part of the control plane. It is a container image that operates inside a Pod on each master node and is accountable for determining when a node has failed and taking appropriate action in response to that failure. It is a frequently used K8s component that should exist on the cluster and has the potential to fool people into believing it is a valid deployment rather than a cryptominer. This is because it should exist on the cluster. Because it is intended to function in an unceasing manner, nobody would question its existence.
This new K8s attack is known as RBAC Buster. Its purpose is to exploit K8s API servers in order to construct a ClusterRoleBinding and acquire complete access to the cluster with persistence after the misconfiguration is fixed.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
