La nouvelle d’une grave faille de sécurité détectée dans les conteneurs Windows a récemment éclaté. Cette faille de sécurité a été exposée à l’état sauvage par un malware nouvellement découvert nommé ‘Siloscape’. La vulnérabilité permet à un conteneur Windows compromis d’être utilisé pour obtenir des privilèges sur son nœud hôte et donc potentiellement un accès complet à un cluster Kubernetes. Cela peut permettre la création de conteneurs malveillants, le contrôle administratif des conteneurs existants ou l’accès aux données dans l’environnement conteneurisé existant. Ou en d’autres termes, un scénario de cauchemar pour une infrastructure Kubernetes de production.
Le nom « Siloscape » indique comment cette vulnérabilité permet à un utilisateur « d’échapper » à ce que la plupart des administrateurs savent être un « silo » sous la forme d’un conteneur. Considéré comme le premier malware connu ciblant les conteneurs Windows, cela a des ramifications pour toute entreprise utilisant des conteneurs Windows pour Kubernetes et devrait rappeler à toutes les équipes NetOps et DevOps l’importance de mettre en œuvre des contrôles de sécurité appropriés dans l’ensemble du cluster Kubernetes. Un point clé est que cela est crucial dans tous les déploiements – en production ET hors production. Il réaffirme également à quel point il est crucial que l’infrastructure Kubernetes soit construite avec Zero Trust et une protection pare-feu d’application Web dès le départ.
Alors comment exploiter les conteneurs Windows ?
Ce malware nécessite initialement d’exploiter une vulnérabilité connue d’exécution de code à distance dans l’application conteneurisée. Cette étape de l’exploit dépendrait de l’application et utiliserait généralement une vulnérabilité connue d’un jour.
La prochaine étape est la plus préoccupante. Le malware tire parti des liens symboliques (une fonctionnalité de Windows peu utilisée) pour monter le système de fichiers hôte en usurpant l’identité d’un processus appelé CExecSvc. Cela permet au malware de s’échapper jusqu’au nœud hôte. Il tente ensuite d’utiliser les privilèges de nœud pour créer un nouveau déploiement dans Kubernetes qui établit une connexion avec un serveur réseau Tor non autorisé où des commandes à distance peuvent être émises ultérieurement. Ceux-ci peuvent aller de l’accès aux données dans Kubernetes au contrôle des conteneurs Kubernetes de production.
En règle générale, les conteneurs fonctionnent en partageant le noyau avec un nœud hôte et en exécutant des instructions directement sur l’hôte. Cependant, alors que certaines ressources sont partagées, cela est strictement géré pour maintenir une « limite ». Dans le cas des conteneurs Windows, cependant, la découverte récente montre que la frontière peut être « échappée » en utilisant ces techniques.
Il est important de mentionner que les conteneurs Windows peuvent prendre deux formes :
- Conteneurs d’isolement de processus (conteneurs de silo) Celles-ci sont similaires au fonctionnement des conteneurs Linux où tous les conteneurs partagent le noyau du système d’exploitation hôte.
- Conteneurs d’isolation Hyper-V : Ceux-ci utilisent l’hyperviseur Hyper-V de Microsoft pour configurer des machines virtuelles légères, ce qui signifie que chaque conteneur a son propre noyau. Cela a un coût en termes de performances et de ressources.
Ce problème n’affecte que Conteneurs d’isolement de processus.
Impact d’être vulnérable
En conséquence, les administrateurs doivent supposer que tout processus s’exécutant dans un conteneur Windows Server dispose des mêmes privilèges que l’administrateur sur l’hôte, qui dans ce cas est le nœud Kubernetes. Si vous exécutez des applications dans des conteneurs Windows Server qui doivent être sécurisées et isolées, il est fortement recommandé d’utiliser des conteneurs d’isolation Hyper-V.
Atténuations
Ce problème souligne l’importance de sécuriser TOUT le trafic entrant dans les conteneurs comme mécanisme de prévention des exploits. L’utilisation du contrôleur Kemp Ingress avec Web Application Firewall et Zero Trust est un moyen simple de mettre en œuvre une protection Day-0 pour les applications Kubernetes. Vous pouvez en savoir plus sur l’histoire de l’intégration Kubernetes de Kemp ici.