La protection contre les menaces d’Azure Security Center vous permet de détecter et d’empêcher les menaces dirigées contre un vaste éventail de services, de la couche Infrastructure as a service (IaaS) aux ressources de plateforme en tant que service (PaaS, platform-as-a-service) dans Azure, telles qu’IoT, Azure App Service et les machines virtuelles locales.

À la conférence Ignite 2019, nous avons annoncé de nouvelles fonctionnalités de protection contre les menaces pour contrer les menaces sophistiquées sur les plateformes cloud, notamment la version préliminaire de la prise en charge de la Protection contre les menaces pour le support du service AKS (Azure Kubernetes Service) dans Security Center et la version préliminaire pour l’évaluation de vulnérabilité pour les images ACR (Azure Container Registry).

Azure Security Center et clusters Kubernetes 

Dans ce blog, nous allons décrire une récente attaque d’exploration de données de crypto-monnaies à grande échelle sur les clusters Kubernetes récemment découverts par Azure Security Center. Il s’agit de l’un des nombreux exemples dont Azure Security Center peut vous aider à protéger vos clusters Kubernetes contre les menaces.

Les attaques d’exploration de données de chiffrement dans les environnements en conteneur ne sont pas nouvelles. Dans Azure Security Center, nous détectons régulièrement un large éventail d’activités d’exploration de données qui s’exécutent dans des conteneurs. En règle générale, ces activités s’exécutent dans des conteneurs vulnérables, tels que des applications web, avec des vulnérabilités connues qui sont exploitées.

Récemment, Azure Security Center a détecté une nouvelle campagne d’exploration de données de chiffrement qui cible spécifiquement des environnements Kubernetes. Ce qui différencie cette attaque d’autres attaques d’exploration de données de chiffrement est son échelle : en seulement deux heures, un conteneur malveillant a été déployé sur des dizaines de clusters Kubernetes.

Les conteneurs ont exécuté une image à partir d’un référentiel public : kannix/monero-miner. Cette image exécute XMRig, un mineur Monero Open source très populaire.

Le télémétrie a montré que le conteneur a été déployé par un déploiement Kubernetes nommé kube-control.

Comme vous pouvez le voir dans la configuration de déploiement ci-dessous, le déploiement, dans ce cas, garantit que 10 réplicas du pod s’exécuteraient sur chaque cluster :

En outre, le même intervenant qui a déployé les conteneurs d’exploration de données de chiffrement a également énuméré les ressources de cluster, y compris les secrets Kubernetes. Cela peut entraîner l’exposition des chaînes de connexion, des mots de passe et d’autres secrets, autorisant ainsi un mouvement latéral.

La partie intéressante est que l’identité de cette activité est system:serviceaccount:kube-system:kubernetes-dashboard qui est le compte de service du tableau de bord.
Ce fait indique que le conteneur malveillant a été déployé par le tableau de bord Kubernetes. L’énumération des ressources a également été lancée par le compte de service du tableau de bord.

Il existe trois façons pour un attaquant de tirer parti du tableau de bord Kubernetes :

1. Tableau de bord exposé : Le propriétaire du cluster a exposé le tableau de bord sur Internet, et l’attaquant l’a trouvé en effectuant une analyse.
2. L’attaquant a obtenu l’accès à un conteneur unique dans le cluster et a utilisé la mise en réseau interne du cluster pour accéder au tableau de bord (ce qui est possible avec le comportement par défaut de Kubernetes).
3. Navigation légitime vers le tableau de bord à l’aide des informations d’identification du cloud ou du cluster.

La question est la suivante : laquelle des trois options ci-dessus a été impliquée dans cette attaque ? Pour répondre à cette question, nous pouvons utiliser un conseil fourni par Azure Security Center, des alertes de sécurité sur l’exposition du tableau de bord Kubernetes. Azure Security Center envoie des alertes lorsque le tableau de bord Kubernetes est exposé sur Internet. Le fait que cette alerte de sécurité ait été déclenchée sur certains clusters attaqués implique que le vecteur d’accès ici est un tableau de bord exposé sur Internet.

Une représentation de cette attaque sur la matrice d’attaque Kubernetes se présente comme suit :

Éviter les attaques d’exploration de données de crypto-monnaies

Comment éviter cela ?

1. N’exposez pas le tableau de bord Kubernetes sur Internet : L’exposition du tableau de bord sur Internet implique l’exposition d’une interface de gestion.
2. Appliquez RBAC dans le cluster : Lorsque RBAC est activé, le compte de service du tableau de bord a des autorisations très limitées par défaut qui n’autorisent aucune fonctionnalité, y compris le déploiement de nouveaux conteneurs.
3. Accordez uniquement les autorisations nécessaires pour les comptes de service : Si le tableau de bord est utilisé, veillez à appliquer uniquement les autorisations nécessaires au compte de service du tableau de bord. Par exemple, si le tableau de bord est utilisé à des fins d’analyse uniquement, accordez uniquement des autorisations « get » au compte de service.
4. Autorisez uniquement les images approuvées : Appliquez le déploiement de conteneurs approuvés uniquement, à partir de registres approuvés.

En savoir plus

Kubernetes est en train de devenir la nouvelle norme en matière de déploiement et de gestion de logiciels dans le cloud. Peu de gens disposent d'une grande expérience de Kubernetes, et beaucoup se concentrent uniquement sur l'ingénierie générale et sur l'administration au détriment de la sécurité. L'environnement Kubernetes doit être configuré avec soin pour être sécurisé, en veillant à ce qu'aucune porte offrant une surface d'attaque centrée sur les conteneurs ne soit laissée ouverte et à la merci des attaquants. Azure Security Center fournit :

1. Découverte et visibilité : Découverte continue des instances AKS managées dans le cadre des abonnements de Security Center.
2. Recommandations relatives aux degrés de sécurisation : Mesures à prendre pour aider les clients à se conformer aux meilleures pratiques de sécurité dans AKS en fonction de leur Degré de sécurisation, par exemple « Le contrôle d’accès en fonction du rôle doit être utilisé pour limiter l’accès à un cluster de services Kubernetes ».
3. Détection de menaces : Analyses basées sur l’hôte et sur le cluster, par exemple « Un conteneur privilégié détecté ».

Pour en savoir plus sur la prise en charge d’AKS dans Azure Security Center, consultez la documentation ici.