Quelques jours après la découverte d'implémentations réseau Kubernetes vulnérables à des attaques, Microsoft a alerté ce mercredi sur un autre vecteur de compromission affectant cet orchestrateur de containers. Bien qu'il ne s'agisse pas directement d'une faille de sécurité de Kubernetes en tant que tel, cette dernière a déjà mis à mal plusieurs dizaines de clusters Kubernetes d'après l'équipe Azure Security Center (ASC) de Microsoft. L'origine de la faille se situe dans Kubeflow, un framework open source dédié au machine learning dans Kubernetes.
« En avril, nous avons observé le déploiement d'une image suspecte à partir d'un référentiel public sur de nombreux clusters différents. L'image est ddsfdfsaadfs / dfsdf: 99 », a alerté Microsoft. « En inspectant les couches de l'image, nous pouvons voir que cette image exécute un mineur XMRIG ». Dans le cadre de ses investigations, l'équipe de chercheurs en sécurité a pu établir que le framework Kubeflowx peut être utilisé en tant que vecteur d'attaque. « Kubeflow crée plusieurs CRD dans le cluster qui exposent certaines fonctionnalités sur le serveur API », poursuit l'équipe de chercheurs. Mais ce n'est pas tout car Kubeflow expose également sa fonctionnalité d'interface utilisateur via un tableau de bord qui est déployé dans le cluster.
Une backdoor déployable dans un container pour compromettre un cluster
« Le tableau de bord est exposé par la passerelle d'entrée Istio, qui est par défaut accessible uniquement en interne. Par conséquent, les utilisateurs doivent utiliser la redirection de port pour accéder au tableau de bord qui tunnelise le trafic via le serveur API Kubernetes », poursuit Microsoft. « Dans certains cas, les utilisateurs modifient le paramètre du service Istio sur Load-Balancer qui expose le service (istio-ingressgateway dans l'istio-system de l'espace de noms) à Internet. Nous pensons que certains utilisateurs ont choisi de le faire pour des raisons de commodité: sans cette action, l'accès au tableau de bord nécessite un tunnelage via le serveur API Kubernetes et n'est pas direct. En exposant le Service à Internet, les utilisateurs peuvent accéder directement au tableau de bord. Cependant, cette opération permet un accès non sécurisé au tableau de bord Kubeflow, qui permet à quiconque d'effectuer des opérations dans Kubeflow, y compris le déploiement de nouveaux conteneurs dans le cluster ».
Une fois le tableau de bord Kubeflow, les pirates sont dès lors en mesure de déployer une porte dérobée dans un des containers contenus dans un nouveau cluster spécialement créé à des fins malveillantes. Pour le déployer, les pirates peuvent par exemple choisir de créer une image personnalisé de serveur notebook Jupyter, voire de se servir d'un véritable notebook Jupyter pour faire tourner leur code Python. « Le code s'exécute à partir du serveur de bloc-notes, qui est un conteneur en soi avec un compte de service monté. Ce compte de service (par défaut) dispose des autorisations pour déployer des conteneurs dans son espace de noms. Par conséquent, les attaquants peuvent l'utiliser pour déployer leur conteneur de porte dérobée dans le cluster », explique Microsoft.
Vigilance sur le load-balancing partagé avec une adresse IP publique
Pour se prémunir, plusieurs vérifications s'imposent comme s'assurer qu'aucun container malveillant n'est déployé dans le cluster via la commande kubectl get pods –