Les pirates utilisent une nouvelle méthode impliquant RBAC (Role-Based Access Control) pour créer des comptes de porte dérobée persistants sur les clusters Kubernetes et détourner leurs ressources pour le crypto-mining Monero.
RBAC est un système de contrôle d’accès à l’API Kubernetes permettant aux administrateurs de définir quels utilisateurs ou comptes de service peuvent accéder aux ressources et aux opérations de l’API.
En abusant de RBAC pour appliquer des politiques de contrôle d’accès malveillantes, les acteurs de la menace peuvent persister sur des clusters compromis même si la mauvaise configuration qui a fourni l’accès initial est corrigée à l’avenir.
Ce nouveau type d’attaque a été découvert par l’équipe de recherche d’Aqua Security, « Nautilus », qui a baptisé la campagne « RBAC Buster ».
Les analystes rapportent que la campagne d’attaque a été activement utilisée pour compromettre 60 clusters Kubernetes mal configurés.
RBAC Buster
Aqua Security a pu enregistrer et analyser l’attaque après que les acteurs de la menace aient violé l’un de ses pots de miel Kubernetes qui ont été délibérément mal configurés pour exposer les API et les clés d’accès.
L’accès initial au cluster Kubernetes cible est obtenu par le biais de requêtes non authentifiées d’utilisateurs anonymes disposant de privilèges. Le serveur d’API doit donc être mal configuré.
Ensuite, l’attaquant envoie des requêtes HTTP pour répertorier les secrets et effectue des requêtes API pour recueillir des informations sur le cluster en répertoriant les entités dans l’espace de noms « kube-system ».
À ce stade, l’attaquant vérifie si le serveur a déjà été compromis par sa campagne, déployé en tant que « kube-controller », ou si d’autres cybercriminels concurrents ont déjà compromis le cluster. S’il trouve les déploiements d’autres attaquants, il les supprimera pour prendre le contrôle des ressources de l’appareil pour son propre usage malveillant.
L’étape suivante est lorsque l’attaquant gagne en persistance sur le cluster en créant un nouveau « ClusterRole » avec des privilèges proches du niveau administrateur et un ServiceAccount « kube-controller » dans l’espace de noms « kube-system ».
Enfin, l’attaquant crée un ClusterRoleBinding nommé « system:controller:kube-controller », liant le ClusterRole au ServiceAccount pour persister dans le cluster même dans le cas où « l’accès utilisateur anonyme » est désactivé.
Un ClusterRoleBinding nommé « kube-controller » a été utilisé pour échapper à la détection et se fondre dans les journaux, car ce nom est similaire à un démon légitime utilisé par Kubernetes.
Le pot de miel d’AquaSec a délibérément exposé les clés d’accès AWS, et la société de sécurité a remarqué que les attaquants les exploitaient pour essayer de recueillir des informations supplémentaires à partir de l’instance cloud à laquelle ils pouvaient accéder.
La dernière étape de l’attaque consiste à créer un DaemonSet pour déployer une image de conteneur hébergée par Docker Hub (« kuberntesio/kube-controller ») sur tous les nœuds avec une seule requête API et commencer à exploiter la crypto-monnaie difficile à tracer Monero sur le serveur compromis.
Déployé par typosquattage
Aqua Security a découvert que le conteneur malveillant « kube-controller » était déployé à partir du registre public Docker sous le nom de « kuberntesio/kube-controller:1.0.1 ». Ce nom imite le compte légitime « kubernetesio » et l’image populaire « kube-controller-manager ».
Ce dernier est un composant critique fonctionnant en continu du plan de contrôle Kubernetes chargé de détecter et de répondre aux défaillances de nœuds, il est donc facile pour les administrateurs de l’ignorer.
AquaSec rapporte que l’image de conteneur particulière a été extraite plus de 14 000 fois de Docker Hub au cours des cinq mois depuis sa première mise en ligne dans le référentiel, ce qui indique que la campagne est généralisée.
La récupération de l’adresse du portefeuille à partir du fichier de configuration a révélé que l’attaquant avait déjà miné 5 XMR et a le potentiel de gagner l’équivalent de 200 $ par travailleur et par an.
Les répercussions des attaques RBAC Buster sur les clusters Kubernetes peuvent être importantes et inclure l’accès non autorisé aux données, l’exposition de secrets, le détournement de ressources et potentiellement même des atteintes à la réputation.
Pour atténuer la menace, sécurisez le serveur d’API en interdisant les demandes non authentifiées des utilisateurs anonymes et créez et appliquez des politiques d’accès aux API strictes en utilisant efficacement RBAC.
Les administrateurs sont également invités à surveiller les journaux d’audit et à chiffrer tous les secrets et informations d’identification de compte hébergés dans le cluster.