Los investigadores de ciberseguridad han demostrado una «dependencia de subida de privilegios de extremo a extremo» en el Servicio de Contenedores elásticos de Amazon (ECS) que podría ser explotado por un atacante para realizar movimiento anexo, aceptar a datos confidenciales y tomar el control del entorno de la nimbo.
La técnica de ataque ha sido reputado ECSCAPE por parte de Sweet Security, el investigador de seguridad Naor Haziz, quien presentó los hallazgos hoy en la Conferencia de Seguridad Black Hat USA que se celebra en Las Vegas.
«Identificamos una forma de aprovecharse de un protocolo interno de ECS indocumentado para obtener credenciales de AWS que pertenecen a otras tareas de ECS en la misma instancia de EC2», dijo Haziz en un referencia compartido con Hacker News. «Un contenedor malvado con un rol de IAM (identidad y mandato de acercamiento) bajo privilegiado puede obtener los permisos de un contenedor privilegiado que se ejecuta en el mismo host».
Amazon ECS es un servicio de orquestación de contenedores totalmente administrado que permite a los usuarios implementar, regir y progresar aplicaciones contenedorizadas, mientras se integran con Amazon Web Services (AWS) para ejecutar cargas de trabajo de contenedores en la nimbo.
La vulnerabilidad identificada por Sweet Security esencialmente permite una subida de privilegios al permitir una tarea de bajo privilegio que se ejecuta en una instancia de ECS para secuestrar los privilegios IAM de un contenedor privilegiado más stop en la misma máquina EC2 al robar sus credenciales.
En otras palabras, una aplicación maliciosa en un clúster ECS podría admitir el papel de una tarea más privilegiada. Esto se facilita aprovechando un servicio de metadatos que se ejecuta en 169.254.170 (.) 2 que expone las credenciales temporales asociadas con el papel de IAM de la tarea.
Si acertadamente este enfoque asegura que cada tarea obtenga credenciales para su papel de IAM y se entregan en tiempo de ejecución, una filtración de la identidad del agente de la CES podría permitir que un atacante se haga acaecer por el agente y obtener credenciales para cualquier tarea en el host. Toda la secuencia es la venidero –
- Obtenga las credenciales de rol de IAM del huésped (rol de instancia de EC2) para hacerse acaecer por el agente
- Descubra el punto final del plano de control de la CES con el que el agente acento
- Reúna los identificadores necesarios (nombre de clúster/ARN, ARN de instancia de contenedor, información de la lectura del agente, lectura de Docker, lectura de protocolo ACS y número de secuencia) para autenticarse como el agente utilizando el punto final de metadatos de tarea y la API de introspección ECS
- Forge y firme la solicitud de WebSocket del Servicio de Comunicación del Agente (ACS) que se hace acaecer por el agente con el parámetro SendCredentials establecido en «Real»
- Credenciales de cosecha para todas las tareas en ejecución en ese caso
«El canal de agente falsificado asimismo sigue siendo sigiloso», dijo Haziz. «Nuestra sesión maliciosa imita el comportamiento esperado del agente, reconociendo mensajes, incrementando los números de secuencia, enviando latidos del corazón, por lo que cero parece mal».
«Al hacerse acaecer por la conexión aguas en lo alto del agente, Ecscape colapsa completamente ese maniquí de confianza: un contenedor comprometido puede compilar pasivamente las credenciales de rol de IAM de cualquier otra tarea en la misma instancia de EC2 e inmediatamente desempeñarse con esos privilegios».
ECSCAPE puede tener graves consecuencias al ejecutar tareas de ECS en hosts de EC2 compartidos, ya que abre la puerta a la subida de privilegios de tarea cruzada, la exposición a los secretos y la exfiltración de metadatos.
A posteriori de la divulgación responsable, Amazon ha enfatizado la carestia de que los clientes adopten modelos de aislamiento más fuertes cuando corresponda, y deje en claro en su documentación que no hay un aislamiento de tareas en EC2 y que «los contenedores pueden aceptar potencialmente a las credenciales para otras tareas en la misma instancia de contenedores».
Como mitigaciones, se recomienda evitar la implementación de tareas de stop privilegio pegado con tareas no confiables o de bajo privilegio en la misma instancia, use AWS Fargate para un efectivo aislamiento, desactive o restringirá el acercamiento a los metadatos de instancia (IMD) para tareas, limite las permisiones de agentes ECS y configure las alertas de CloudTrail para detectar el uso inusual de los roles IAM.
«La enseñanza principal es que debe tratar cada contenedor como potencialmente comprometible y restringir rigurosamente su radiodifusión de ataque», dijo Haziz. «Las convenientes abstracciones de AWS (roles de tareas, servicio de metadatos, etc.) hacen la vida más sencillo para los desarrolladores, pero cuando múltiples tareas con diferentes niveles de privilegios comparten un huésped subyacente, su seguridad es tan válido como los mecanismos que los aislan, mecanismos que pueden tener debilidades sutiles».
El explicación se produce a raíz de varias debilidades de seguridad relacionadas con la nimbo que se han informado en las últimas semanas.
- Una condición de carrera en la integración GitHub de Google Cloud Build que podría ocurrir permitido a un atacante evitar la revisión del mantenedor y construir un código no revisado a posteriori de que el mantenedor emite un comando «/GCBRUN».
- Una vulnerabilidad de ejecución de código remoto en Oracle Cloud Infrastructure (OCI) Editor de código que un atacante podría usar para secuestrar el entorno de shell de una víctima y potencialmente rodar en los servicios de OCI al engañar a una víctima, que ya registró Oracle Cloud, para revistar una página HTML maliciosa alojada en un servidor por medio de un ataque de un ataque
- Una técnica de ataque emplazamiento I Spy que explota un director de servicio (SP) de la aplicación de primera parte de Microsoft en Entrra Id para la persistencia y la subida de privilegios a través de la autenticación federada
- Una vulnerabilidad de subida de privilegio en el servicio de estudios forzoso de Azure que permite a un atacante con solo acercamiento de cuenta de almacenamiento para modificar los scripts de Invoker almacenados en la cuenta de almacenamiento de AML y ejecutar código caprichoso adentro de una tubería AML, lo que les permite extraer secretos de las bóvedas esencia de Azure, privilegios de escalera y acercamiento más amplio a la nimbo de bienes nubes de nubes en la nimbo de la nimbo de nubes.
- Una vulnerabilidad de trascendencia en la política administrada de AWS Legacy AmazonGuardDutyfulLaccess que podría permitir una adquisición organizativa completa de una cuenta de miembro comprometido al registrar un administrador delegado caprichoso
- Una técnica de ataque que abusa de Azure Arc para la subida de privilegios al servirse el papel de administrador de bienes de la máquina conectada Azure y como mecanismo de persistencia al configurar como comando y control (C2)
- Un caso de roles de leedor incorporados excesivamente privilegiados y una vulnerabilidad en la API de Azure que podría ser encadenado por un atacante para filtrar las claves VPN y luego usar la esencia para aceptar a los activos de la nimbo interna y las redes locales
- A supply chain compromise vulnerability in Google Gerrit called GerriScary that enabled unauthorized code submissions to at least 18 Google projects, including ChromiumOS (CVE-2025-1568, CVSS score: 8.8), Chromium, Dart, and Bazel, by exploiting misconfigurations in the default «addPatchSet» permission, the voting system’s label handling, and a race condition with bot Tiempos de breviario de código durante el proceso de combinación de código
- Una configuración errónea de Google Cloud Platform que expuso las subredes utilizadas para los intercambios de miembros en los puntos de intercambio de Internet (IXP), lo que permite a los atacantes aprovecharse de la infraestructura en la nimbo de Google para obtener acercamiento no competente a IXP LAN internos.
- Una extensión de una vulnerabilidad de subida de privilegio de Google Cloud llamado Función Confused que se puede adaptar a otras plataformas en la nimbo como AWS y Azure utilizando funciones de AWS Lambda y Azure, respectivamente, por otra parte de extenderlo para realizar una enumeración ambiental.
«La táctica de mitigación más efectiva para proteger su entorno de un comportamiento similar del actor de amenaza es asegurar que todos los SA (cuenta de servicio) adentro de su entorno en la nimbo se adhieran al principio de último privilegio y que no hay SAS de nubes heredadas aún en uso», dijo Talos. «Asegúrese de que todos los servicios y dependencias en la nimbo estén actualizados con los últimos parches de seguridad. Si están presentes Legacy SAS, reemplácelos con SAS de menos privilegios».
