Des chercheurs en cybers\u00e9curit\u00e9 ont r\u00e9v\u00e9l\u00e9 une faille de s\u00e9curit\u00e9 affectant les services Microsoft Azure Kubernetes qui, si elle \u00e9tait exploit\u00e9e avec succ\u00e8s, pourrait permettre \u00e0 un attaquant d’\u00e9lever ses privil\u00e8ges et d’acc\u00e9der aux informations d’identification des services utilis\u00e9s par le cluster.<\/p>\n
\u00ab Un attaquant avec ex\u00e9cution de commande dans un pod ex\u00e9cut\u00e9 dans un cluster Azure Kubernetes Services affect\u00e9 pourrait t\u00e9l\u00e9charger la configuration utilis\u00e9e pour provisionner le n\u0153ud du cluster, extraire les jetons d’amor\u00e7age de s\u00e9curit\u00e9 de la couche de transport (TLS) et effectuer une attaque d’amor\u00e7age TLS pour lire tous les secrets au sein du cluster \u00bb, a d\u00e9clar\u00e9 Mandiant, propri\u00e9t\u00e9 de Google. dit<\/a>.<\/p>\n Les clusters utilisant \u00ab Azure CNI \u00bb pour la \u00ab Configuration r\u00e9seau \u00bb et \u00ab Azure \u00bb pour la \u00ab Strat\u00e9gie r\u00e9seau \u00bb ont \u00e9t\u00e9 identifi\u00e9s comme \u00e9tant affect\u00e9s par le bogue d’escalade des privil\u00e8ges. Microsoft a depuis r\u00e9solu le probl\u00e8me suite \u00e0 une divulgation responsable.<\/p>\n La technique d’attaque con\u00e7ue par la soci\u00e9t\u00e9 de renseignement sur les menaces repose sur l’acc\u00e8s \u00e0 un composant peu connu appel\u00e9 Azure WireServer pour demander une cl\u00e9 utilis\u00e9e pour crypter les valeurs des param\u00e8tres prot\u00e9g\u00e9s (\u00ab wireserver.key \u00bb) et l’utiliser pour d\u00e9coder un script de provisionnement qui comprend plusieurs secrets tels que les suivants –<\/p>\n \u00ab KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT et KUBELET_CA_CRT peuvent \u00eatre d\u00e9cod\u00e9s en Base64 et \u00e9crits sur le disque pour \u00eatre utilis\u00e9s avec l’outil de ligne de commande Kubernetes kubectl pour s’authentifier aupr\u00e8s du cluster \u00bb, ont d\u00e9clar\u00e9 les chercheurs Nick McClendon, Daniel McNamara et Jacob Paullus.<\/p>\n \u00ab Ce compte dispose d’autorisations Kubernetes minimales dans les clusters Azure Kubernetes Service (AKS) r\u00e9cemment d\u00e9ploy\u00e9s, mais il peut notamment r\u00e9pertorier les n\u0153uds du cluster. \u00bb<\/p>\n TLS_BOOTSTRAP_TOKEN, d’autre part, pourrait \u00eatre utilis\u00e9 pour activer un Attaque d’amor\u00e7age TLS<\/a> et finalement acc\u00e9der \u00e0 tous les secrets utilis\u00e9s par les charges de travail en cours d’ex\u00e9cution. L’attaque ne n\u00e9cessite pas que le pod soit ex\u00e9cut\u00e9 en tant que root.<\/p>\n \u00ab L’adoption d’un processus de cr\u00e9ation de politiques r\u00e9seau restrictives autorisant l’acc\u00e8s uniquement aux services requis permet d’\u00e9viter toute cette classe d’attaques \u00bb, a d\u00e9clar\u00e9 Mandiant. \u00ab L’escalade des privil\u00e8ges via un service non document\u00e9 est emp\u00each\u00e9e lorsque le service n’est pas accessible du tout. \u00bb<\/p>\n Cette r\u00e9v\u00e9lation intervient alors que la plateforme de s\u00e9curit\u00e9 Kubernetes ARMO a mis en \u00e9vidence une nouvelle faille Kubernetes de haute gravit\u00e9 (CVE-2024-7646<\/a>Score CVSS\u00a0: 8,8) qui affecte le contr\u00f4leur ingress-nginx et pourrait permettre \u00e0 un acteur malveillant d’obtenir un acc\u00e8s non autoris\u00e9 aux ressources sensibles du cluster.<\/p>\n \u00ab La vuln\u00e9rabilit\u00e9 provient d’une faille dans la fa\u00e7on dont Ingress-nginx valide les annotations sur les objets Ingress \u00bb, a d\u00e9clar\u00e9 le chercheur en s\u00e9curit\u00e9 Amit Schendel. dit<\/a>.<\/p>\n \u00ab Cette vuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant d’injecter du contenu malveillant dans certaines annotations, en contournant les contr\u00f4les de validation pr\u00e9vus. Cela peut conduire \u00e0 une injection de commande arbitraire et \u00e0 un acc\u00e8s potentiel aux informations d’identification du contr\u00f4leur ingress-nginx, qui, dans les configurations par d\u00e9faut, a acc\u00e8s \u00e0 tous les secrets du cluster. \u00bb<\/p>\n Cela fait \u00e9galement suite \u00e0 la d\u00e9couverte d’un d\u00e9faut de conception dans Kubernetes projet git-sync<\/a> cela pourrait permettre l’injection de commandes dans Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) et Linode.<\/p>\n \u00ab Ce d\u00e9faut de conception peut entra\u00eener soit l’exfiltration de donn\u00e9es de n’importe quel fichier du pod (y compris les jetons de compte de service), soit l’ex\u00e9cution de commandes avec les privil\u00e8ges d’utilisateur git_sync \u00bb, explique Tomer Peled, chercheur chez Akamai. dit<\/a>\u00ab Pour exploiter la faille, il suffit \u00e0 un attaquant d’appliquer un fichier YAML sur le cluster, ce qui est une op\u00e9ration \u00e0 faibles privil\u00e8ges. \u00bb<\/p>\n Aucun correctif n’est pr\u00e9vu pour cette vuln\u00e9rabilit\u00e9, il est donc essentiel que les organisations auditent leurs pods git-sync pour d\u00e9terminer quelles commandes sont ex\u00e9cut\u00e9es.<\/p>\n \u00ab Ces deux vecteurs sont dus \u00e0 un manque de nettoyage des entr\u00e9es, ce qui souligne la n\u00e9cessit\u00e9 d’une d\u00e9fense robuste concernant le nettoyage des entr\u00e9es utilisateur \u00bb, a d\u00e9clar\u00e9 Peled. \u00ab Les membres de l’\u00e9quipe bleue doivent \u00eatre attentifs aux comportements inhabituels de l’utilisateur gitsync dans leurs organisations. \u00bb<\/p>\n <\/p>\n![\"Cybers\u00e9curit\u00e9\"](\"https:\/\/teknomers.com\/fr\/wp-content\/uploads\/2024\/08\/Des-chercheurs-decouvrent-une-attaque-Bootstrap-TLS-sur-les-clusters.png\")
<\/a><\/center><\/div>\n\n
<\/a><\/center><\/section>\n