RBAC Buster — First-ever recorded proof of attack on Kubernetes RBAC as backdoor for cryptomining
A newly-discovered attack on Kubernetes is making rounds recently. This would be the first-ever recorded proof of attack on Kubernetes RBAC. Aptly dubbed ‘RBAC Buster’, The discovery was made public by cybersecurity researchers at Aqua Security.
RBAC Buster assembles backdoors and creates a “zombie” out of exploited assets and used to mine cryptocurrency like Monero.
What is Kubernetes RBAC?
Kubernetes RBAC is a key security control to ensure that cluster users and workloads have only the access to resources required to execute their roles. Kubernetes RBAC aka Kubernetes API access control system enables administrators to specify which service accounts or users have access to API operations and resources. This system then provides precise access control and enhances security measures by limiting access to critical resources.
Attack in detail
A misconfiguration in the API Server was leveraged as the initial access which allowed unauthenticated requests from anonymous users with privileges. A series of HTTP requests from the attackers listing the secrets and making two API requests to get details about the cluster in the kube-system namespace. Then the attacker confirmed if a previous attack had been done on this specific cluster by checking for a deployment named kube-controller.
Initial Access:
Exposed Sensitive Interfaces
Execution:
Deploy Daemonset
Persistence:
Create ClusterRole Binding
Create ClusterRole
Defense Escalation
Masquerading
Stop Competeing Campaigns
Images from a Public Registry
Credential Access
List Kube’s Secrets
List Kube’s Configmaps
List Pods
Discovery
Access the Kube’s API Server
Impact
Resource Hijacking
Seemingly, steps to “cover tracks” or beat other “competing” hackers were done by the attacker/s as they also attempted to delete some existing deployments in various namespaces, including ‘kube-secure-fhgxtsjh’, ‘kube-secure-fhgxt’, ‘api-proxy’, and ‘worker-deployment’. If other competing hackers were to also successfully hack the same systems, CPU usage would be too high and very noticable.
The highlight of this attack was that the actor used RBAC for persistence. New ClusterRole with near admin-level privileges was created. A cluster role is not bound to a specific namespace. A ‘ServiceAccount’, ‘kube-controller’ in the ‘kube-system’ namespace were also created. To hide and solidify its persistence, A ‘ClusterRoleBinding’ was created to bind the ClusterRole with the ServiceAccount.
Possible Impacts
Resource Hijacking and Abuse
Data Privacy
Secret exposure
Data Exfil
Reputation damage
Mitigations
Security controls are in-place, tested and updated on the below activities
Prohibit unauthenticated requests from anonymous users.
Make sure to secure the API server.
Ensure to employ Role-Based Access Control (RBAC) effectively.
Enforce strict API access policies.
Regularly monitor audit logs.
Make sure to encrypt any secrets with proper encryption.
Always secure the account credentials hosted in the cluster.
Reference:
https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters
