Vulnérabilité critique d’exécution de code arbitraire découverte dans Kubernetes

Le 3 décembre 2018, une vulnérabilité grave a été divulguée à la communauté Kubernetes. Il s’agit de la première CVE critique découverte dans le projet Kubernetes (selon le score CVSS v3).

Des versions corrigées ont été publiées et mises à la disposition des utilisateurs finaux et des fournisseurs cloud. Veillez à effectuer la mise à niveau vers une version corrigée si ce n’est pas déjà fait. Nous recommandons les versions corrigées suivantes : v1.10.11, v1.11.5, v1.12.3 et v1.13.0-rc.1. Si une mise à niveau est impossible, d’autres solutions de contournement et mesures d’atténuation ont été proposées dans le ticket GitHub mentionné précédemment par Jordan Liggitt, du projet Kubernetes.

La vulnérabilité critique, identifiée sous le numéro CVE-2018-1002105, a été découverte par Darren Shepherd, de Rancher. Elle permet à un attaquant d’accéder à distance aux services back-end présents dans le cluster Kubernetes et d’y exécuter des commandes arbitraires, ce qui peut entraîner une élévation de ses privilèges.

Cette attaque est rendue possible par une vulnérabilité du service d’API kubelet, l’un des nombreux composants du projet Kubernetes.

Le service d’API kubelet est une passerelle intermédiaire fournie par Kubernetes, qui permet aux services back-end, également appelés serveurs d’API agrégés, de s’y enregistrer. Par conséquent, toutes les requêtes adressées à ces serveurs, comme les appels d’API à /apis/<apiGroup>/<apiVersion>, transitent par le service d’API kubelet avant d’être acheminées vers la destination de l’API agrégée au sein du cluster Kubernetes.

Un exemple d’utilisation d’un serveur d’API agrégé est un service de vérification de l’état de santé pour les équilibreurs de charge, qui interrogent les serveurs back-end internes afin de connaître leur état. Le service de métriques intégré à Kubernetes en est un autre exemple.

La vulnérabilité

Pour exploiter cette vulnérabilité, un utilisateur doit avoir accès au service d’API kubelet, identifié comme kube-apiserver. Cela ouvre la voie à une élévation de privilèges et à l’obtention de droits d’accès supplémentaires.

La vulnérabilité tient à la façon dont kube-apiserver relaie les requêtes vers les serveurs back-end internes du cluster. Cela crée un tunnel direct entre ces serveurs et l’utilisateur. Plus précisément, cela se produit lors du traitement des requêtes de mise à niveau de connexion, utilisées pour les communications WebSocket. La connexion TCP ouverte entre le client et le serveur back-end peut alors servir à envoyer des requêtes arbitraires directement à ce serveur.

En principe, l’accès au service d’API kubelet est bloqué pour toute personne extérieure au cluster. Toutefois, par défaut, l’accès à cette API est activé pour les utilisateurs anonymes afin de permettre la découverte des services et les vérifications de leur état de santé.

Il existe un autre vecteur d’attaque : un service accessible aux utilisateurs peut interagir avec le service d’API kubelet de manière à permettre à un attaquant distant de prendre le contrôle de cette interaction. Cela ouvre alors la voie à la manipulation de la connexion à kubelet et à son exploitation de façon similaire.

Fait intéressant, ce n’est pas le premier incident lié à kube-apiserver. Une analyse publiée en mars a révélé qu’un kube-apiserver exposé publiquement avait entraîné l’installation d’un logiciel malveillant de minage de cryptomonnaie dans un cluster Kubernetes. L’infrastructure cloud de Tesla a également été victime d’une attaque similaire, due à une console d’administration Kubernetes non sécurisée. Cela dit, cette vulnérabilité récente est la plus grave jamais signalée à ce jour à la Product Security Team de Kubernetes.

Chez Snyk, notre équipe de sécurité a ajouté cette vulnérabilité à notre base de données le 5 décembre 2018.

Points clés à retenir :

• Paramètres par défaut non sécurisés : les utilisateurs authentifiés comme non authentifiés peuvent interroger l’API Kubernetes.

• Journalisation insuffisante : des activités malveillantes ou suspectes ont été menées via une connexion API existante. Kubernetes n’a donc pas consigné l’activité réelle dans ses journaux, à l’exception de l’appel initial à l’API.

Comment vous protéger

En juin, nous avons annoncé notre solution d’analyse d’images Docker, conçue pour les développeurs. Elle permet de détecter si vos images contiennent l’une des vulnérabilités mentionnées dans cet article, et bien d’autres. De plus, Snyk vous recommande des mesures correctives, notamment des images de base vers lesquelles effectuer une mise à niveau pour réduire le nombre de vulnérabilités et atténuer cette vulnérabilité en particulier.

Si vous ne l’avez pas encore essayée, vous pouvez tester vos projets contenant des Dockerfiles. Nous commencerons alors à les analyser et à surveiller les paquets vulnérables installés sur l’image de base du système d’exploitation.