La découverte de Naor Haziz montre comment un conteneur compromis sur les tâches ECS soutenues par EC2 peut se faire passer pour l’agent ECS et voler des informations d’identification IAM à d’autres tâches – sans accès hôte.
Chez Black Hat USA 2025, Naor Haziz de Sweet Security a révélé un défaut d’escalade de privilège significatif dans Amazon ECS qui permet à un conteneur à faible primerie fonctionnant sur une tâche soutenue par EC2 de détourner les rôles IAM plus privés d’IAM à partir d’autres conteneurs sur le même hôte.
Surnommée ECSCAPE, la faille découle de la distribution des informations d’identification internes des ECS. Le plan de contrôle ECS fournit des informations d’identification IAM TASK via un protocole WebSocket interne sans papiers, Agent Communication Service (ACS), dans lequel un attaquant de conteneurs peut exploiter s’il obtient d’abord les informations d’identification de rôle d’instance EC2 à partir du service de métadonnées d’instance (IMD).
« Dans la pratique, cela signifie qu’une application compromise dans votre cluster ECS pourrait assumer le rôle d’une tâche plus privilégiée en volant ses informations d’identification – tant qu’elles fonctionnent sur la même instance », a déclaré Haziz dans un article de blog, ajoutant que le défaut expose également des rôles d’exécution de tâche qui, lorsqu’ils sont compromis, peuvent être abusés pour extraire des secrets ou des artefacts.
Haziz a initialement décidé de construire un outil de surveillance en temps réel basé sur EBPF pour les charges de travail ECS. Ce faisant, il a intercepté la communication entre l’agent ECS et le backend AWS dans le cadre de son processus de débogage, c’est-à-dire qu’il a remarqué le canal Websocket sans papiers.
Des tâches modestes aux rôles IAM privilégiés
Grâce à la disponibilité par défaut des IMD, tout conteneur (avec un accès de bas niveau) sur une instance ECS basée sur EC2 peut lire les informations d’identification des rôles d’instance destinées à l’agent ECS.
« Aucune rupture de conteneur (pas d’accès Hostroot) n’était requise – mais l’accès IMDS a été requis via un réseau intelligent et une ruse du système à l’intérieur de l’espace de noms du conteneur », a noté Haziz, ajoutant que l’accès aux IMD permet à tout conteneur d’imposser un agent ECS. AWS a une documentation sur la façon d’empêcher ou de limiter l’accès aux IMD.
Armé de ces informations d’identification de rôle d’instance, l’attaquant peut forger la communication sur ACS WebSocket. Cela leur permet d’intercepter ou de demander des informations d’identification IAM d’autres tâches de course, même si ces tâches sont censées être isolées par des rôles IAM. Essentiellement, le conteneur compromis dégénère en se faisant passer pour l’agent d’orchestrateur ECS responsable de la gestion et de l’orchestration des tâches.
« Les Keys volés (IAM Creasatings) fonctionnent exactement comme les clés de la tâche réelle », a déclaré Haziz. «AWS Cloudtrail attribuera les appels d’API au rôle de la tâche de victime, donc la détection initiale est difficile – il semble que la tâche de la victime exécute les actions.» Cela permet aux attaquants d’être invisibles dans les journaux parce qu’Aws pense que la victime fait tout.
Fargate est relativement sûr
Sweet Security a recommandé des atténuations qui incluent la désactivation ou la restriction de l’accès des IMD à partir de tâches moins fiduciaires afin qu’ils ne puissent pas obtenir d’identification d’instance, en évitant de co-héberger des tâches faibles et à grande privilège sur la même instance EC2, et le passage à AWS Fargate, qui fournit une meilleure isolation des tâches.
« Les tâches AWS Fargate ne partagent pas un hôte sous-jacent avec d’autres tâches – chaque tâche Fargate s’exécute dans sa propre micro-machine virtuelle avec son propre agent IMDS et ECS isolés », a expliqué Haziz. « ECSCAPE ne s’applique pas à Fargate car il n’y a pas de tenue de l’instance. »
Un ID CVE a été demandé pour ECSCape, et Sweet Security a publié un code de preuve de concept (POC) pour la vulnérabilité sur GitHub. Haziz a également partagé une démo en direct d’ECScape, ajoutant que les instances non atténuées ne nécessitent aucune erreur de configuration de la part de l’utilisateur. « Tous les comportements et paramètres par défaut d’ECS sur EC2 sont suffisants pour que l’attaque fonctionne », a-t-il ajouté.
