Des chercheurs en cybersécurité ont révélé une faille de sécurité affectant les services Microsoft Azure Kubernetes qui, si elle était exploitée avec succès, pourrait permettre à un attaquant d’élever ses privilèges et d’accéder aux informations d’identification des services utilisés par le cluster.
« Un attaquant avec exécution de commande dans un pod exécuté dans un cluster Azure Kubernetes Services affecté pourrait télécharger la configuration utilisée pour provisionner le nœud du cluster, extraire les jetons d’amorçage de sécurité de la couche de transport (TLS) et effectuer une attaque d’amorçage TLS pour lire tous les secrets au sein du cluster », a déclaré Mandiant, propriété de Google. dit.
Les clusters utilisant « Azure CNI » pour la « Configuration réseau » et « Azure » pour la « Stratégie réseau » ont été identifiés comme étant affectés par le bogue d’escalade des privilèges. Microsoft a depuis résolu le problème suite à une divulgation responsable.
La technique d’attaque conçue par la société de renseignement sur les menaces repose sur l’accès à un composant peu connu appelé Azure WireServer pour demander une clé utilisée pour crypter les valeurs des paramètres protégés (« wireserver.key ») et l’utiliser pour décoder un script de provisionnement qui comprend plusieurs secrets tels que les suivants –
- KUBELET_CLIENT_CONTENT (Clé TLS du nœud générique)
- KUBELET_CLIENT_CERT_CONTENT (Certificat TLS de nœud générique)
- KUBELET_CA_CRT (certificat d’autorité de certification Kubernetes)
- TLS_BOOTSTRAP_TOKEN (Jeton d’authentification TLS Bootstrap)
« KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT et KUBELET_CA_CRT peuvent être décodés en Base64 et écrits sur le disque pour être utilisés avec l’outil de ligne de commande Kubernetes kubectl pour s’authentifier auprès du cluster », ont déclaré les chercheurs Nick McClendon, Daniel McNamara et Jacob Paullus.
« Ce compte dispose d’autorisations Kubernetes minimales dans les clusters Azure Kubernetes Service (AKS) récemment déployés, mais il peut notamment répertorier les nœuds du cluster. »
TLS_BOOTSTRAP_TOKEN, d’autre part, pourrait être utilisé pour activer un Attaque d’amorçage TLS et finalement accéder à tous les secrets utilisés par les charges de travail en cours d’exécution. L’attaque ne nécessite pas que le pod soit exécuté en tant que root.
« L’adoption d’un processus de création de politiques réseau restrictives autorisant l’accès uniquement aux services requis permet d’éviter toute cette classe d’attaques », a déclaré Mandiant. « L’escalade des privilèges via un service non documenté est empêchée lorsque le service n’est pas accessible du tout. »
Cette révélation intervient alors que la plateforme de sécurité Kubernetes ARMO a mis en évidence une nouvelle faille Kubernetes de haute gravité (CVE-2024-7646Score CVSS : 8,8) qui affecte le contrôleur ingress-nginx et pourrait permettre à un acteur malveillant d’obtenir un accès non autorisé aux ressources sensibles du cluster.
« La vulnérabilité provient d’une faille dans la façon dont Ingress-nginx valide les annotations sur les objets Ingress », a déclaré le chercheur en sécurité Amit Schendel. dit.
« Cette vulnérabilité permet à un attaquant d’injecter du contenu malveillant dans certaines annotations, en contournant les contrôles de validation prévus. Cela peut conduire à une injection de commande arbitraire et à un accès potentiel aux informations d’identification du contrôleur ingress-nginx, qui, dans les configurations par défaut, a accès à tous les secrets du cluster. »
Cela fait également suite à la découverte d’un défaut de conception dans Kubernetes projet git-sync cela pourrait permettre l’injection de commandes dans Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) et Linode.
« Ce défaut de conception peut entraîner soit l’exfiltration de données de n’importe quel fichier du pod (y compris les jetons de compte de service), soit l’exécution de commandes avec les privilèges d’utilisateur git_sync », explique Tomer Peled, chercheur chez Akamai. dit« Pour exploiter la faille, il suffit à un attaquant d’appliquer un fichier YAML sur le cluster, ce qui est une opération à faibles privilèges. »
Aucun correctif n’est prévu pour cette vulnérabilité, il est donc essentiel que les organisations auditent leurs pods git-sync pour déterminer quelles commandes sont exécutées.
« Ces deux vecteurs sont dus à un manque de nettoyage des entrées, ce qui souligne la nécessité d’une défense robuste concernant le nettoyage des entrées utilisateur », a déclaré Peled. « Les membres de l’équipe bleue doivent être attentifs aux comportements inhabituels de l’utilisateur gitsync dans leurs organisations. »