Cloud Security , Containerization & Sandboxing , Endpoint Security
Novel Technique Exploits Kubernetes RBAC to Create Backdoors
Attackers Deployed DaemonSets to Steal Resources From VictimsThreat actors are exploiting Kubernetes Role-Based Access Control in the wild to create backdoors and to run cryptocurrency miners.
See Also: Protect Your Amazon S3 Data: Why Versioning, Replication, and AWS Backup are Not Enough
Researchers observed a recent campaign that targeted at least 60 Kubernetes clusters by deploying DaemonSets to hijack and steal resources from the victims' clusters.
Researchers at cybersecurity firm Aqua Security said they recorded and analyzed an attack on its Kubernetes honeypots that used the RBAC system to gain persistence.
RBAC is a method of restricting network access based on the roles of individual users within an organization.
In their honeypots, the researchers exposed AWS access keys in various locations on the cluster and received a beacon indicating that the access keys had been used by the attacker to try and gain further access to the cloud service provider account and leverage the attack to steal more resources and data.
"The findings are significant as they shed light on the risks of misconfigurations and how even large organizations can overlook the importance of securing their clusters, leaving them vulnerable to potential disasters with just one mistake," according to the researchers.
The large-scale campaign, dubbed RBAC Buster, allowed attackers to gain initial access by exploiting a misconfigured API server that allowed unauthenticated requests from anonymous users with privileges.
"The attacker sent a few HTTP requests to list secrets and then made two API requests to gain information about the cluster by listing the entities in the 'kube-system' namespace," the researchers said.
To confirm if the attack has been deployed, the attackers looked for a specific deployment named kube-controller
.
The actors also tried deleting existing deployments in various namespaces, including kube-secure-fhgxtsjh
kube-secure-fhgxt, api-proxy
, and worker-deployment
.
The researchers said that by deleting these deployments, they believe the attackers were trying to disable legacy campaigns or competitors' campaigns "to increase available CPU and reduce the chances of being discovered if the server was exhausted."
The attackers then created a ClusterRole with admin-level privileges and also created a "ServiceAccount" kube-controller
in the kube-system
namespace.
In the last stage, the adversary built a ClusterRoleBinding that binds the ClusterRole to the ServiceAccount to "create a strong and inconspicuous persistence," the researchers found.
The attacker created persistence that enabled further exploitation of the cluster and avoided any kind of detection during the binding of the cluster-admin role to a new or suspicious user. In order to avoid being detected, the attackers blended the role with the API audit logs.
By "setting this legitimate-looking ClusterRoleBinding 'system:controller:kube-controller,' the attacker could persist under the radar without setting off any alarms," the researchers said.
The attackers then created a DaemonSet to deploy containers on all nodes with a single API request. The container image on kuberntesio/kube-controller:1.0.1
, hosted on the public registry Docker Hub, has been pulled 14,399 times since it was uploaded five months ago.
Further analysis revealed that each container image had the binary kube-controller and was detected in VirusTotal as a cryptominer. Researchers were able to uncover configuration files for each of the container images.
The wallet address further revealed that attackers mined 5 XMR. At this rate of mining, they could gain another 5 per year - around $200 from a single worker, the researchers said.
"The container image named 'kuberntesio/kube-controller' is a case of typosquatting that impersonates the legitimate 'kubernetesio' account. It has amassed millions of pulls, despite having only a few dozen container images. The image also mimics the popular 'kube-controller-manager' container image, which is a critical component of the control plane, running within a pod on every master node, responsible for detecting and responding to node failures," the researchers said.
The image is a widely used component that could deceive practitioners into thinking it is a legitimate deployment rather than a cryptominer. "Since it is designed to run continuously, no one would question its presence," they said.