È stata scoperta una vasta campagna di attacco in cui è stata sfruttata la gestione degli accessi basata sui ruoli (Role-Based Access Control o RBAC) di Kubernetes (K8s) per creare backdoor ed eseguire miner di criptovalute.
Kubernetes ed RBAC cosa sono di preciso?
Prima di proseguire, spieghiamo cosa sono RBAC e Kubernetes.
Kubernetes è un sistema open-source per l’automazione della gestione dei container che semplifica l’implementazione, la scalabilità e la gestione delle applicazioni in container su più host. Kubernetes si basa sul concetto di orchestrazione dei container, dove un’istanza di Kubernetes coordina la distribuzione e la gestione dei container su diversi nodi all’interno di un cluster.
L’Access Control di base in Kubernetes è gestito tramite il controllo degli accessi di base (ABAC), ma ci sono anche altre modalità di controllo degli accessi più avanzate, tra cui il controllo degli accessi basato sui ruoli (RBAC). Il controllo degli accessi basato sui ruoli è una funzionalità di sicurezza avanzata che consente di definire ruoli specifici all’interno del sistema e di assegnare autorizzazioni specifiche ai ruoli stessi. Ciò consente ai team IT di gestire l’accesso ai componenti di Kubernetes in modo granulare e specifico per il ruolo di ogni utente o gruppo di utenti.
In pratica, il controllo degli accessi basato sui ruoli in Kubernetes consente di garantire che solo le persone autorizzate possano accedere alle risorse del sistema, come i nodi del cluster e i contenitori in esecuzione. Ciò aiuta a proteggere il sistema contro attacchi esterni e interni, tra cui quelli che mirano a creare backdoor o a eseguire attività dannose, come il mining di criptovalute giusto per dirne una.
Ecco i problemi di Kubernets con RBAC
“Gli hacker hanno anche implementato DaemonSets per prendere il controllo e dirottare le risorse dei cluster K8s che attaccano“, ha detto la società di sicurezza cloud Aqua in un rapporto; l’azienda israeliana, che ha denominato l’attacco RBAC Buster, ha scoperto 60 cluster K8s esposti che sono stati sfruttati dall’attore minaccia dietro questa campagna.
La serie di attacchi hacker è iniziata con l’attaccante che ha ottenuto l’accesso iniziale tramite un server API mal configurato, seguito dalla verifica di eventuali prove di malware miner concorrenti sul server compromesso e poi utilizzando RBAC per configurare la persistenza.
“L’aggressore ha creato un nuovo ClusterRole con privilegi quasi di amministratore“, ha detto l’azienda. “Successivamente, l’attaccante ha creato un ‘ServiceAccount’, ‘kube-controller’ nel namespace ‘kube-system’. Infine, l’attaccante ha creato un ‘ClusterRoleBinding’, legando il ClusterRole con il ServiceAccount per creare una persistenza forte e insospettabile“.
Nell’intrusione osservata contro i suoi honeypot K8s, l’attaccante ha cercato di utilizzare le chiavi di accesso AWS esposte per ottenere una presa salda nell’ambiente, rubare dati e uscire dai confini del cluster.
L’ultimo passaggio dell’attacco ha comportato la creazione di un DaemonSet da parte dell’attore minaccia per distribuire un’immagine di contenitore ospitata su Docker (“kubernetesio/kube-controller:1.0.1”) su tutti i nodi. Il contenitore, che è stato scaricato 14.399 volte dal suo caricamento cinque mesi fa, contiene un miner di criptovalute.
“L’immagine del contenitore chiamata ‘kubernetesio/kube-controller’ è un caso di typosquatting che si spaccia per l’account legittimo ‘kubernetesio’“, ha detto Aqua. “L’immagine imita anche l’immagine del contenitore popolare ‘kube-controller-manager’, che è un componente critico del piano di controllo, in esecuzione all’interno di un Pod su ogni nodo master, responsabile della rilevazione e della risposta ai guasti dei nodi.”
È interessante notare che alcune delle tattiche descritte nella campagna presentano somiglianze con un’altra operazione illecita di mining di criptovalute che ha sfruttato anche i DaemonSets per generare Dero e Monero. Al momento non è chiaro se i due insiemi di attacchi siano correlati.
