Kubernetes, un outil qui alimente la plupart des infrastructures cloud, modernes et natives, vient de subir son premier gros bug de sécurité, et il est gigantesque. La faille aurait pu avoir fourni à un cybercriminel un accès totalement libre aux applications logicielles qui dépendent de l’outil pour fonctionner.
Kubernetes est un outil logiciel qui gère un grand nombre de conteneurs. Ceux-ci sont similaires à des machines virtuelles qui exécutent plusieurs systèmes d’exploitation sur le même ordinateur physique, mais ils ont tout de même une différence essentielle. Au lieu de contenir un système d’exploitation complet, les conteneurs ne contiennent que ce qui est nécessaire au fonctionnement d’une application particulière (dépendances logicielles, bibliothèques système, etc.), tout en partageant un système d’exploitation hôte avec d’autres conteneurs.
Les conteneurs sont de petits environnements d’exploitation très réactifs, conçus pour fonctionner de la même manière dans plusieurs environnements informatiques, en supprimant les fameux problèmes du type : “mais cela fonctionnait lorsque nous l’avions testé !”. Les entreprises peuvent gérer des dizaines, voire des centaines de milliers de conteneurs, ce qui peut poser de sérieux problèmes de déploiement, de mise à jour et de gestion. C’est là que Kubernetes entre en jeu. Il gère les conteneurs dans des groupes appelés pods.
Le programme, qui au départ était un projet open-source source de Google, est maintenant géré par la CNCF (Cloud Native Computing Foundation) de la Linux Foundation, et a connu sa première fuite de données sérieuse avec cette faille, donnant ainsi à un attaquant un accès en profondeur à une installation Kubernetes. Elle a permis à une requête spécialement conçue de se connecter aux serveurs Kubernetes et de créer leurs propres requêtes.
L’équipe Kubernetes a annoncé que la faille s’appelait CVE-2018-1002105. La vulnérabilité repose sur le serveur API Kubernetes, un outil logiciel permettant aux utilisateurs de Kubernetes d’envoyer des instructions aux pods Kubernetes via une API HTTP (Application Programming Interface), et à la manière dont le serveur API communique avec un pod Kubernetes.
Le serveur API autorise les demandes des utilisateurs via une authentification basée sur un certificat. Mais si l’utilisateur envoie une requête mal-formée, destinée à renvoyer une erreur, le serveur laisse la ligne de communication ouverte avec le pod et laisse alors simplement passer les requêtes suivantes sans vérifier si l’utilisateur est autorisé. Le résultat est une élévation plutôt efficace des privilèges de l’utilisateur.
Ce problème permet à un utilisateur normal d’obtenir un accès exec (privilège très élevé) au niveau de n’importe quel conteneur du nœud, y compris ceux disposant d’un accès en lecture/écriture au niveau du système de fichiers hôte. Ils ont accès à tous les workoads en cours d’exécution, y compris l’intégralité des données échangées entre eux.
Les pirates auraient pu utiliser cette vulnérabilité pour voler des données, interrompre le traitement des applications ou exécuter leurs propres commandes malveillantes.
L’exploit comporte deux variantes, l’une qui utilise les serveurs d’API agrégés de Kubernetes et qui est accessible à tous les utilisateurs. L’autre utilise un appel à une API appelée exec/attach/portforward, qui n’est généralement disponible que pour les utilisateurs dotés de rôles d’administration/modification.
Red Hat a fourni plus de détails sur la manière dont la faille affecte la version 3.0 d’OpenShift, sa propre plateforme de conteneur utilisant Kubernetes comme composant principal.
Kubernetes a déjà corrigé la faille et les utilisateurs des systèmes prenant en charge les correctifs automatisés devraient déjà être protégés. Ceux qui n’ont pas besoin de patcher leurs installations Kubernetes aussi !
Billet inspiré de Kubernetes cloud computing bug could rain data for attackers, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.