Une vulnérabilité critique découverte sur Kubernetes

L'équipe de développement de Kubernetes a corrigé une vulnérabilité critique sur son logiciel. L'exploitation de cette vulnérabilité est possible lorsque que celui-ci est configuré par défaut. Elle permettrait à un attaquant de gagner des privilèges administrateur sur n'importe quelle machine à l'intérieur d'un cluster de serveurs ciblé. Une attaque de ce type est simple à mettre en œuvre, ne nécessite ni privilège ni interaction avec un utilisateur et peut être réalisée à distance. Son impact estimé sur la confidentialité, l'intégrité et la disponibilité des données est élevé. 

Kubernetes est une plateforme en code source ouvert qui automatise l'exploitation des conteneurs Linux, facilitant notamment leur déploiement et la mise à l'échelle des applications en conteneur. Elle fonctionne sur le principe d'une architecture maître-esclave, avec une unité de contrôle qui pilote plusieurs "node". Chaque node est une machine pouvant héberger plusieurs conteneurs, pouvant eux-mêmes être regroupés en "pod". L'unité de contrôle, pour maintenir l'architecture désirée au sein du groupe de nodes, met à disposition un serveur API permettant aux utilisateurs de communiquer avec elle, pour lui fournir par exemple les éléments de configuration.

Cette vulnérabilité peut être exploitée dans deux cas de figure : 

  • Dans le cas d'un utilisateur authentifié, s'il possède certains privilèges présents dans la configuration par défaut, pourrait devenir administrateur du cluster et ainsi lire ou modifier les données présentes sur les conteneurs du pod ;
  • Dans le cas d'un utilisateur non authentifié, Il pourrait élever ses privilèges et effectuer n'importe quelle requête via l'API. 

Ces vulnérabilités affectent également Open Shift développé par RedHat, qui est une surcouche de Kubernetes facilitant l'intégration de ce dernier dans d'autres infrastructures. Cette vulnérabilité n'aurait a priori pas été exploitée lors d'attaques mais cela reste à nuancer en raison de la complexité à détecter ce type d'attaque. En effet, un ingénieur travaillant dans l'équipe sécurité du logiciel a constaté qu'elle ne laissait pas de trace dans les journaux de connexion (logs) du serveur API.

Dans les cas où les mises à jour automatiques ne seraient pas activées, les utilisateurs sont fortement invités à les appliquer le plus rapidement possible.

Détails Techniques :

Lorsque l'utilisateur n'est pas authentifié, le vecteur d'attaque repose sur la présence d'un serveur API agrégé, permettant d'étendre les services de l'API standard. Il fonctionne ainsi comme un serveur proxy en faisant suivre toutes les requêtes via le serveur API. Un attaquant non authentifié ayant accès à un environnement kubernetes pourrait réaliser une requête sur ce serveur agrégé et élever ses privilèges afin de réaliser n'importe quelle requête API.

Par défaut, tous les utilisateurs ont les permissions nécessaires pour réaliser les requêtes sur le serveur API agrégé. Ces requêtes sont alors signées par le serveur API et apparaissent comme légitimes. Il n'est alors possible de les détecter qu'avec les logs du serveur API agrégé.  

L'attaque nécessite l'envoi d'une requête spécialement conçue dont les paramètres n'ont bien sûr pas été communiqués.

Informations
+

Risques

  • Elévation de privilèges

Criticité

  • Score CVSS : 9.80

Existence d’un code d’exploitation de la vulnérabilité

  • Aucun code d'exploitation n'est publiquement disponible.

Composants & versions vulnérables

  • Kubernetes v1.0.x-1.9.x

  • Kubernetes v1.10.0-1.10.10

  • Kubernetes v1.11.0-1.11.4

  • Kubernetes v1.12.0-1.12.2

CVE

  • CVE-2018-1002105

 


    Recommandations
    +

    Mise en place de correctif de sécurité

    Un correctif a été publié le 3 décembre :

    • Pour la branche 1.10, la mise à jour 1.10.11 a été publiée.
    • Pour la branche 1.11, la mise à jour 1.11.5 a été publiée.
    • Pour la branche 1.12, la mise à jour 1.12.3 a été publiée.

    Solution de contournement

    • Plusieurs solutions de contournement sont proposées, néanmoins elles doivent être considérées au cas par cas en raison de leurs effets indésirables. Il est ainsi possible de désactiver le serveur API agrégé et les requêtes anonymes ou encore modifier les permissions par défaut.