Novel Technique Exploits Kubernetes RBAC to Create Backdoors – Source: www.databreachtoday.com

Cloud Security
,
Containerization & Sandboxing
,
Endpoint Security

Attackers Deployed DaemonSets to Steal Resources From Victims

Prajeet Nair (@prajeetspeaks) •
April 22, 2023    

Threat actors are exploiting Kubernetes Role-Based Access Control in the wild to create backdoors and to run cryptocurrency miners.

See Also: Live Webinar | Education Cybersecurity Best Practices: Devices, Ransomware, Budgets and Resources

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.

Kubernetes Role-based access control or 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 were 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 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,” researchers say.

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’.

Researchers say they assume by deleting these deployments, 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 bounds the ClusterRole to the ServiceAccount to “create a strong and inconspicuous persistence,” researchers found.

With the attacker creating persistence that enabled further exploitation of the cluster and avoiding any kind of detection during the binding of ‘cluster-admin’ role to a new or suspicious user. In doing so, an alarm would trigger. In order to avoid being detected, the attackers used a clever way by blending the role with the API audit logs.

It was accomplished by “setting this legitimate-looking ClusterRoleBinding ‘system:controller:kube-controller,’ the attacker could persist under the radar without setting off any alarms.”

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. Where, the container was 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 the 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 and at this rate of mining, they could gain another 5 per year – around $200 from a single worker.

“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,” researchers say.

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,” researchers say.