Les correctifs destinés à protéger les conteneurs Amazon Web Services (AWS) contre le dangereux bogue Log4Shell présentaient des vulnérabilités critiques qui pouvaient permettre à des conteneurs malveillants de compromettre l’hôte sous-jacent.
En raison de la gravité de Log4Shell, AWS a publié des services de « correctifs à chaud » qui s’exécutent sur des serveurs et repèrent et corrigent à la volée les applications et conteneurs Java non corrigés.
Les correctifs à chaud s’appliquent aux serveurs autonomes, aux clusters Kubernetes et aux clusters Elastic Container Service (ECS). Outre AWS, ces correctifs peuvent également être installés dans d’autres environnements cloud ou serveurs autonomes.
Sortir du conteneur
Chercheurs à Palo Alto Networks Unité 42 découvert la vulnérabilitéqui pourrait être exploitée pour prendre le contrôle du serveur ou du cluster exécutant le service de correctif.
Selon leurs découvertes, chaque conteneur d’un cluster peut exploiter la vulnérabilité d’échappement de conteneur et d’élévation de privilèges. Outre les conteneurs, les processus non privilégiés peuvent également exploiter le service de correctifs pour élever les privilèges et obtenir l’exécution du code racine.
« Nous avons découvert cette vulnérabilité peu de temps après la sortie de l’outil car nous étions curieux de savoir comment il corrigeait les conteneurs », a déclaré Yuval Avrahami, chercheur principal en sécurité chez Palo Alto Networks. La gorgée quotidienne.
« Nous avons rapidement signalé le problème à l’équipe de sécurité d’AWS et travaillé en étroite collaboration avec l’équipe d’ingénieurs d’AWS pendant qu’ils développaient des correctifs. »
Le hot patch recherche les binaires ‘java’ dans les conteneurs et les invoque avec ses propres privilèges au niveau du serveur et sans les conteneuriser. Cela signifie que le processus s’exécute sans les limitations normalement appliquées aux processus de conteneur.
Un conteneur malveillant peut inclure un binaire Java pour inciter le correctif à l’invoquer avec des privilèges élevés, échapper au conteneur et prendre le contrôle de l’hôte sous-jacent.
Les chercheurs ont publié une preuve de concept qui exploite la vulnérabilité pour échapper aux limites du conteneur, obtenir l’exécution du code racine sur l’hôte sous-jacent et envoyer un shell inversé à un serveur contrôlé par l’attaquant.
Ramifications possibles
Avrahami a déclaré qu’il était préoccupé par deux principaux scénarios d’attaque. Premièrement, si un conteneur exposé publiquement est compromis par un certain type d’attaque réseau, l’auteur de la menace peut exploiter la vulnérabilité pour prendre le contrôle de l’hôte sous-jacent, de tous les conteneurs voisins et éventuellement du cluster Kubernetes d’hébergement.
« Malheureusement, il n’est pas rare qu’une fuite de conteneur soit suffisante pour prendre le contrôle d’un cluster Kubernetes entier », a déclaré Avrahami.
« La vulnérabilité augmente considérablement les possibilités de mouvement latéral d’un seul conteneur compromis à des dizaines, voire des centaines. »
LIRE LA SUITE VMware Horizon sous attaque alors qu’un groupe de rançongiciels basé en Chine cible la vulnérabilité Log4j
Une deuxième menace possible est un attaquant infiltrant un registre d’images de conteneurs pour organiser une attaque de la chaîne d’approvisionnement.
« L’attaquant injecte l’exploit dans une image de conteneur, facilitant la compromission de tout environnement qui exécute l’image et sur lequel le correctif à chaud est installé », a déclaré Avrahami.
AWS a corrigé le hot patch et publié de nouvelles versions.
« Les organisations qui gèrent des environnements de conteneurs doivent agir le plus rapidement possible pour confirmer si elles utilisent cet outil et corriger rapidement si elles le font », a déclaré Avrahami.
Les enjeux de la sécurité des conteneurs
Les correctifs à chaud sont des solutions de fortune conçues comme des correctifs à court terme jusqu’à ce qu’un correctif permanent soit installé.
Compte tenu de l’urgence entourant Log4Shell, de nombreux utilisateurs ont peut-être installé le correctif à grande échelle, mettant en danger les environnements de conteneurs, prévient Avrahami. Même après avoir corrigé leurs applications Java, ils ont peut-être maintenu le correctif actif pour plus de sécurité.
« L’isolation des conteneurs est difficile et il y a toujours des risques lors du développement de solutions qui interagissent avec les conteneurs », a déclaré Avrahami.
« Cela nous rappelle également que la sécurité du cloud exige plusieurs couches de protection et que les organisations doivent investir en profondeur dans la sécurité alors qu’elles transfèrent de plus en plus de charges de travail vers le cloud.
