Si vous pensiez qu'être victime d'un ransomware ou qu'un pirate informatique s'emparait de votre poste de travail était un cauchemar, imaginez la catastrophe potentielle que représenterait le piratage de votre cluster Kubernetes (k8s). Il pourrait s'agir d'un désastre amplifié un million de fois.Kubernetes a gagné une immense popularité auprès des entreprises ces dernières années en raison de ses prouesses indéniables en matière d'orchestration et de gestion des applications conteneurisées. Il consolide votre code source, vos comptes cloud et vos secrets en un seul centre. Cependant, entre de mauvaises mains, l'accès au cluster k8s d'une entreprise pourrait être non seulement nuisible, mais aussi potentiellement catastrophique.
Lors de leur enquête, Assaf Morag et Michael Katchinskiy d'Aqua Security ont découvert des clusters Kubernetes appartenant à plus de 350 organisations, projets open-source et particuliers, ouvertement accessibles et en grande partie non protégés. Au moins 60 % d'entre eux ont été violés et ont fait l'objet d'une campagne active de déploiement de logiciels malveillants et de portes dérobées.
La plupart de ces groupes étaient liés à des organisations de petite ou moyenne taille, avec un sous-ensemble notable lié à de vastes conglomérats, certains d'entre eux faisant même partie du classement Fortune 500. Les organisations identifiées sont issues de divers secteurs, tels que la finance, l'aérospatiale, l'automobile, l'industrie, la sécurité, etc.
Parmi les éléments qu'ils ont découverts, ils ont relevé deux principales erreurs de configuration. La plus courante, qui a été largement couverte par le passé, mais qui reste un problème préoccupant, consiste à autoriser l'accès anonyme avec des privilèges. Le second problème qui est sorti du lot est l'exécution du proxy `kubectl` avec certains arguments qui conduisent à exposer sans le savoir le cluster à l'internet. Pour une compréhension plus complète de ces mauvaises configurations, voici un extrait de leur recherche et de leur découverte.
Trouver les clusters k8s exposés
Les attaquants utilisent souvent des moteurs de recherche tels que Shodan, Censys et Zoomeye pour trouver des hôtes mal configurés ou vulnérables. Ils recherchent également sur Internet des hôtes exposés à l'aide de botnets ou d'outils tels que masscan et Zgrab pour scanner rapidement de larges plages d'adresses IP et identifier les services sur les ports exposés.
Bien que ce nombre initial (environ 3 millions) soit énorme, il ne reflète pas le nombre de clusters à risque, c'est pourquoi les requêtes de recherche ont été modifier pour rechercher spécifiquement les serveurs API qui peuvent être exploités par les attaquants.
Sur une période de trois mois, ils effectué plusieurs recherches distinctes à l'aide de Shodan. Lors de leur première recherche, ils ont identifié 120 adresses IP. Chaque recherche ultérieure (hebdomadaire) a révélé environ 20 nouvelles adresses IP. Au total, pendant toute la durée de cette recherche, ils ont identifié un peu plus de 350 adresses IP distinctes.
Conclusions générales
En analysant les plus de 350 hôtes nouvellement découverts, ils ont constaté que la majorité d'entre eux (72 %) avaient les ports 443 et 6443 exposés. Il s'agit des ports HTTPS par défaut. Ils ont constaté que 19 % des hôtes utilisaient des ports HTTP tels que 8001 et 8080, tandis que les autres utilisaient des ports moins courants (par exemple 9999).
La répartition des hôtes a révélé que si la plupart (85 %) avaient entre 1 et 3 nœuds, certains hébergeaient entre 20 et 30 nœuds au sein de leurs clusters Kubernetes. Le nombre de nœuds plus élevé pourrait indiquer des organisations plus grandes ou des clusters plus importants.
En ce qui concerne la répartition géographique, la majorité des serveurs étaient géolocalisés en Amérique du Nord, avec une empreinte importante d'AWS (environ 80 %). En revanche, divers fournisseurs de cloud chinois représentaient environ 17 % des serveurs.
Le serveur API est utilisé pour accéder aux secrets de Kubernetes, de sorte qu'un accès ouvert permet à un attaquant de prendre le contrôle total du cluster. Toutefois, les clusters Kubernetes ne se contentent généralement pas de stocker leurs propres secrets. Dans de nombreux cas, le cluster Kubernetes fait partie du cycle de vie du développement logiciel (SDLC) de l'organisation, et doit donc avoir accès à la gestion du code source (SCM), à l'intégration continue/au déploiement continu (CI/CD), aux registres et au fournisseur de services Cloud (Cloud Service Provider).
Dans les secrets Kubernetes, il y avait un large éventail de secrets supplémentaires associés à divers environnements. Il s'agit notamment d'environnements SCM tels que GitHub, de plateformes CI telles que Jenkins, de divers registres tels que Docker Hub, de services de base de données externes tels que Redis ou PostgreSQL, et bien d'autres encore.
En analysant l'identité des propriétaires de clusters, ils ont découvert qu'ils allaient des entreprises Fortune 500 aux petites, moyennes et grandes entreprises. Il est intéressant de noter que dans leurs recherches, ils ont également rencontré des projets open-source qui, s'ils sont compromis, pourraient déclencher un vecteur d'infection de la chaîne d'approvisionnement avec des implications pour des millions d'utilisateurs.
Et vous ?
Pensez-vous que cette étude est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
Le rapport de Red Hat sur la sécurité de Kubernetes révèle que l'homme est le problème,L'entreprise estime que la complexité de Kubernetes déconcerte le cerveau humain
Les entreprises se tournent vers Kubernetes pour gérer le Big DataKubernetes devenant la norme pour les charges de travail de données dans le cloud et sur site, selon une nouvelle étude de Pepperada
51 % des développeurs cloud utilisent Kubernetes et les conteneurs dans leurs opérations quotidiennes57 % ont constaté une augmentation du nombre de clusters Kubernetes au sein de leur organisation