Êtes-vous prêt à accroître la notoriété de votre marque ? Envisagez de devenir sponsor du AI Impact Tour. En savoir plus sur les opportunités ici.
Une vague de nouvelles attaques a ciblé Kubernetes en 2023 : les crypto-mineurs Dero et Monero, Scarleteel et RBAC-Buster. Trouver un premier pied avec une application Web vulnérabilité, puis se déplacer latéralement est la marque d’une attaque Kubernetes. Comprendre la réalité de ces attaques peut aider à protéger votre organisation contre les attaques actuelles et futures ciblant Kubernetes.
Voici un aperçu de la manière dont les attaques se déroulent et de ce que vous pouvez faire pour vous en protéger – ou au moins minimiser les dégâts une fois attaqués.
Plan d’attaque de Scarleteel
Une application Web de notebook Jupyter hébergée dans Kubernetes était le point d’entrée de Scarleteel, dans le but d’accéder à des données sensibles cryptées hébergées dans le stockage cloud et le crypto mining. Pour trouver un accès libre à l’environnement cloud AWS, le attaquants a également utilisé un outil de test d’intrusion Kubernetes open source appelé Peirates, ainsi qu’un outil similaire appelé Pacu.
Scarleteel a démontré avec quelle fluidité un attaquant peut se déplacer dans un environnement cloud. L’attaquant est passé d’une application Web hébergée dans Kubernetes directement au cloud, à Kubernetes, puis inversement. Défenseurs n’ont pas une vision similaire de leur environnement, mais examinent séparément la sécurité du cloud, la sécurité des applications Web et la sécurité de Kubernetes, puis ont du mal à rassembler l’ensemble des mouvements et des objectifs de l’attaquant.
Que pouvez-vous faire pour vous protéger de Scarleteel
Si vous n’utilisez pas de notebooks Jupyter, vous n’y serez peut-être pas sensible. attaque. Mais il existe de nombreuses autres vulnérabilités des applications Web. Vous pouvez être sûr de vous protéger contre la mauvaise configuration très spécifique du cloud dont les attaquants ont profité. Si vous exécutez EKS, recherchez les endroits où IMDSv1 ou IMDSv2 sont installés et demandez à une équipe bleue d’exécuter Peirates et Paco sur votre environnement avant qu’un attaquant ne le fasse.
Les capacités d’exécution détecteraient potentiellement le malware Pandora, mais ne le relieraient pas à l’attaque et à l’activité plus larges se produisant dans les environnements cloud et Kubernetes, de sorte qu’elles ne pourraient pas arrêter l’intégralité de l’attaque.
Mineurs de crypto-monnaie Dero et Monero
Dans l’attaque Dero, l’acteur malveillant a d’abord recherché les API Kubernetes où l’authentification est définie pour permettre à toute personne d’accéder de manière anonyme. Pour que cela fonctionne, le cluster avait également besoin d’une configuration RBAC permettant la création de pods dans ce cluster. Une fois ces conditions remplies, l’attaquant a déployé un Daemonset, créant ses propres pods à partir d’images malveillantes à travers le cluster.
La première partie de l’attaque Monero est la même que celle de Dero. Ensuite, avec l’accès à l’API Kubernetes, les attaquants ont supprimé les pods Dero et déployé leur propre pod privilégié via Daemonset. Le pod privilégié a ensuite tenté de monter le répertoire hôte pour échapper au conteneur et a téléchargé un rootkit qui pourrait cacher le mineur. Ensuite, l’attaquant a installé un service d’exploration de données personnalisé sur l’hôte.
Contrairement à Dero, l’attaque Monero implique des techniques d’élévation de privilèges et d’évasion de conteneurs. Autoriser les conteneurs privilégiés est l’un des problèmes de sécurité Kubernetes les plus critiques à éviter. Kubernetes interdit les pods privilégiés dans sa politique de base pour Normes de sécurité des podsce qui rend moins probable que cela se produise par défaut.
Toutefois, si vous exécutez EKS et Kubernetes v1.13 et versions ultérieures, la stratégie de sécurité des pods par défaut est privilégiée. Dans EKS, vous devez supprimer cette stratégie pour activer vos stratégies client — une étape supplémentaire qui augmente potentiellement les chances que vous autorisiez la création de pods privilégiés.
Dans Monero, de nombreuses activités d’exécution se produisent après que les pirates ont profité de la mauvaise configuration initiale de Kubernetes. Le verrouillage de cette fonctionnalité empêcherait un comportement d’exécution malveillant de se propager à d’autres pods et clusters. L’arrêt des chemins montés sur l’hôte non autorisés et des mauvaises configurations des pods privilégiés est le plus important. mesure préventive. Si vous effectuez KSPM sur des intervalles d’interrogation, vous manquez toute activité d’attaquant qui se produit entre les deux.
Comment se protéger des attaques Dero/Monero
En cas d’exposition, votre principale préoccupation est de réduire le rayon d’explosion, car l’attaque se produit en temps réel dans Kubernetes, et non pendant l’exécution. Si votre capacité d’exécution inclut une règle autour du minage de crypto Monero, vous pouvez arrêter la dernière étape mais pas les phases initiales de la compromission.
Même si vous ne configureriez probablement pas votre API pour autoriser l’accès anonyme, il existe d’autres façons d’obtenir ce même point d’entrée. exploité. Un initié malveillant peut installer des portes dérobées ou des mineurs de cryptomonnaie similaires à ceux de ces attaques. Un développeur peut sans le savoir archiver un jeton de compte de service ou un fichier kubeconfig dans un référentiel git public, ce qui pourrait rendre un cluster vulnérable.
La mesure de protection la plus importante consiste à empêcher la création de charges de travail malveillantes à partir de Daemonsets. Il existe également des arguments en faveur d’outils d’observabilité, car de nombreuses opérations de crypto-jacking sont découvertes grâce à des pics de trafic inattendus.
Étant donné que cette attaque a utilisé une image pour créer les pods malveillants, la mise en place d’une politique de contrôle d’admission empêchant la création de charges de travail provenant de sources d’images non fiables fonctionnerait. Cependant, vous devrez soit appliquer la politique de manière générale, soit utiliser une solution de détection KSPM en temps réel pour comprendre exactement où vous rencontrez des problèmes, puis utiliser le contrôleur d’admission de manière chirurgicale pendant que vous corrigez les configurations dans le code.
Plan d’attaque RBAC-Buster
L’attaquant tente de prendre pied dans un environnement Kubernetes en recherchant un serveur API mal configuré qui autoriserait les requêtes non authentifiées des utilisateurs disposant de privilèges. Les attaquants ont utilisé un accès privilégié pour répertorier les secrets et découvrir l’espace de noms du système Kube.
Ils ont créé un nouveau ClusterRole avec des privilèges d’administrateur et un nouveau compte de service dans l’espace de noms, liant les deux ensemble pour donner les privilèges d’administrateur du ClusterRole au compte de service. L’attaquant a recherché des clés AWS pour accéder au fournisseur de services cloud. Ils ont ensuite utilisé un Daemonset pour déployer des pods malveillants pour le crypto mining sur le cluster, à l’aide d’une image de conteneur.
La première étape de cette attaque suppose que non seulement votre serveur API Kubernetes est ouvert, mais qu’il accepte également les demandes des utilisateurs privilégiés. Le reste de l’attaque s’opère avec cet accès privilégié.
Que pouvez-vous faire pour vous protéger contre RBAC-Buster
Pour se propager latéralement, les attaquants ont utilisé la même technique Daemonset que dans la campagne Dero : un rappel pour empêcher la création de charges de travail malveillantes à partir de Daemonsets. Vérifiez les configurations de votre serveur API et auditez vos autorisations RBAC pour vous protéger contre cette attaque.
Prévenir de futures attaques
L’équipe qui a découvert RBAC-Buster a déclaré que 60 % des clusters exposés trouvés présentaient un campagne active en cours. Cela ne signifie pas que 60 % de tous les clusters sont exposés. Mais les attaquants recherchent des erreurs, des erreurs de configuration et un accès à votre environnement Kubernetes.
La plupart des clusters n’étaient accessibles que pendant quelques heures, ce qui met en évidence la nature éphémère des clusters Kubernetes et comment ce qui laisse présager aujourd’hui une exploitation et une exposition pourrait demain être fermé aux attaquants. Cela signifie un cauchemar en matière de remédiation si vous travaillez avec des intervalles d’interrogation qui ne peuvent pas afficher ces changements au fil du temps.
S’appuyer uniquement sur le contrôle d’admission ou sur la détection par ingénierie inverse des événements d’exécution lorsque la prochaine attaque survient ne la détectera pas du tout ou la détectera trop tard. Vous avez besoin d’une vue combinée en temps réel des risques Kubernetes. La défense en profondeur est la meilleure pratique. Mais si la défense en profondeur ne fournit aucune vision de la manière dont les différents composants fonctionnent ensemble, vous êtes toujours en retard sur l’attaquant.
Jimmy Mesta est CTO et co-fondateur de KSOC.
DataDecisionMakers
Bienvenue dans la communauté VentureBeat !
DataDecisionMakers est l’endroit où les experts, y compris les techniciens travaillant sur les données, peuvent partager des informations et des innovations liées aux données.
Si vous souhaitez en savoir plus sur des idées de pointe et des informations à jour, sur les meilleures pratiques et sur l’avenir des données et de la technologie des données, rejoignez-nous sur DataDecisionMakers.
Vous pourriez même envisager contribuer à un article ton propre!