Attaquer Kubernetes – Partie 3 – Blog IT-Sécurité Tec-Bite

À propos de cette offre

Microsoft a présenté au printemps 2020 une liste de différents scénarios d'attaque pour les environnements Kubernetes. La liste présente 9 tactiques différentes (horizontalement) avec les techniques pertinentes (verticalement). Dans la première partie de cette série de blogs, nous avons examiné les trois tactiques Initial Access, Execution et Persistence (voir la partie 1 ici : www.tec-bite.ch/attacking-kubernetes-container-umgebungen-teil-1/). La deuxième partie de la série de blogs a été consacrée aux cinq tactiques suivantes de la liste : Privilege Escalation, Defense Evasion, Credential Access, Discovery et Lateral Movement (partie 2 : www.tec-bite.ch/attacking-kubernetes-container-umgebungen-teil-2/). Aujourd'hui, dans la troisième partie de la série, nous abordons la tactique Impact et montrons ce qu'il faut également prendre en compte. Source : https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/, consulté le 29.07.20 La liste est conçue comme la matrice ATT&CK(1) de MITRE (lien : attack.mitre.org) et répertorie 9 tactiques différentes (horizontalement) avec les techniques pertinentes (verticalement)(2). (1) ATT&CK signifie Adversarial Tactics, Techniques, and Common Knowledge, c’est-à-dire tactiques d’attaque, techniques et connaissances générales. (2) MITRE propose également une matrice ATT&CK plus générale pour le cloud (lien : attack.mitre.org/matrices/enterprise/cloud/) Tactiques 1-8 Les tactiques 1-3 sont décrites dans la première partie de la série de blogs : Attacking Kubernetes (Container-Umgebungen) – Partie 1 Et les tactiques 4-8 sont abordées dans la deuxième partie de la série de blogs : Attacking Kubernetes (Container-Umgebungen) – Partie 2 Enfin, la dernière série de techniques restantes des deux premières entrées : 9. Impact La dite "tactique Impact" consiste en des techniques utilisées par les attaquants pour perturber, abuser ou même détruire le comportement normal de l’environnement. 9.1 Destruction de données Les attaquants peuvent tenter de détruire les données et ressources dans le cluster. Cela inclut la suppression de déploiements, configurations, ressources de stockage et de calcul. 9.2 Détournement de ressources Les attaquants peuvent abuser d’une ressource compromise pour exécuter leurs propres tâches. Un abus fréquent consiste à utiliser des ressources compromises pour le minage de cryptomonnaies. Les attaquants ayant accès à un conteneur dans le cluster ou l’autorisation de créer de nouveaux conteneurs peuvent les utiliser pour ces activités. 9.3 Déni de service Les attaquants peuvent également tenter de mener une attaque par déni de service (DoS), rendant le service indisponible pour les utilisateurs légitimes. Dans les clusters de conteneurs, cela inclut les tentatives d’affecter la disponibilité des conteneurs, des nœuds du cluster ou du serveur API. Microsoft propose plus d’informations sur la sécurité des conteneurs ici : docs.microsoft.com/en-us/azure/security-center/container-security De même chez AWS (pour ECS) : docs.aws.amazon.com/AmazonECS/latest/developerguide/security.html Et chez Google (GCP) : cloud.google.com/container-registry/docs/container-analysis Qu’avons-nous oublié ? Beaucoup. L’outil Mitre Att&ck adapté par Microsoft pour Kubernetes est un document précieux et intéressant. On peut en apprendre beaucoup et il montre clairement que de nombreuses techniques sont similaires dans les environnements conteneurisés, comme dans les environnements cloud ou sur site classiques. Cela devient intéressant lorsqu’on considère ce qui fonctionne différemment dans un cluster Kubernetes par rapport aux environnements sur site. Ces points précis pourraient alors représenter des vulnérabilités supplémentaires. D’une part, il faut toujours se demander si la plateforme elle-même présente ou pourrait présenter des vulnérabilités. Au sein d’une plateforme K8s, de nombreux services différents fonctionnent (du monitoring aux contrôleurs en passant par le service mesh, etc.) qui peuvent avoir leurs propres vulnérabilités et être exploités. De telles attaques dites de la chaîne d’approvisionnement ne sont pas rares et le récent piratage Solarwinds a clairement montré à quel point elles peuvent être dangereuses. Toute la pipeline CI/CD est également un vecteur d’attaque idéal, des outils CI/CD eux-mêmes aux outils d’automatisation et bien sûr aux dépôts. Le scan d’images de conteneurs dans le dépôt devrait en fait être mis en œuvre dans chaque environnement conteneurisé. Il ne faut pas non plus oublier la composante humaine. Les environnements Kubernetes sont assez complexes et lorsqu’on ajoute la pipeline CI/CD, il y a beaucoup de possibilités de mauvaise configuration (surtout, mais pas uniquement, /etcd et kubelet). C’est pourquoi il existe de plus en plus de solutions CSPM (Cloud Security Posture Management) qui peuvent vérifier la configuration des environnements conteneurisés (et spécifiquement Kubernetes) et la comparer aux standards. Il n’est pas surprenant que les API des environnements conteneurisés soient souvent considérées comme une cible d’attaque évidente. Dans un cluster Kubernetes, il n’y a presque pas de meilleur vecteur d’attaque, car une fois qu’une vulnérabilité API est trouvée, il est souvent trivial de l’exploiter et de réaliser une escalade de privilèges. Il y a beaucoup d’autres points auxquels il faut faire attention, la liste est assez longue. Beaucoup dépend encore de l’environnement conteneurisé lui-même. Nous recommandons de créer une visibilité claire du cluster, de la pipeline CI/CD et de tous les fournisseurs dès le départ, de la maintenir continuellement à jour et de la remettre régulièrement en question. Conclusion Est-il donc suffisant de prendre ces 9 tactiques comme base pour sécuriser un environnement Kubernetes ? Cela dépend, comme toujours en matière de sécurité, fortement d’autres circonstances. Où se trouve votre environnement conteneurisé (sur site ou dans le cloud) ? Comment exploitez-vous les conteneurs (Openshift, Kubernetes, via un environnement managé comme ECS, GKE ou AKS) ? Avez-vous construit un environnement isolé ou vos clusters font-ils partie d’une chaîne de développement (avec vos propres dépôts et CI/CD) ? etc. Il n’est pas nécessaire d’exploiter son cluster Kubernetes complètement isolé dans un datacenter comme une boîte noire, mais il ne faut pas non plus simplement lancer ECS/GKE ou AKS en pensant que les fournisseurs cloud s’occuperont de toute la sécurité (conseil : ne le faites pas). Et enfin, un peu d’auto-promotion, nous sommes heureux de vous aider à construire votre environnement conteneurisé en toute sécurité et avons dans notre portefeuille des solutions spécialement conçues pour Kubernetes et les conteneurs. Liens Matrice ATT&CK(1) de MITRE : attack.mitre.org Blog Microsoft – Matrice de menaces pour Kubernetes : www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ Sécurité Cloud par AVANTEC : www.avantec.ch/themen/cloud-security/ L’article Attacking Kubernetes (Container-Umgebungen) – Partie 3 est initialement paru sur Tec-Bite.