Los investigadores de ciberseguridad han demostrado una «cadena de escalada 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 lateral, acceder a datos confidenciales y tomar el control del entorno de la nube.
La técnica de ataque ha sido nombrado 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 abusar 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 informe compartido con Hacker News. «Un contenedor malicioso con un rol de IAM (identidad y gestión de acceso) 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, administrar y escalar aplicaciones contenedorizadas, mientras se integran con Amazon Web Services (AWS) para ejecutar cargas de trabajo de contenedores en la nube.
La vulnerabilidad identificada por Sweet Security esencialmente permite una escalada 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 alto en la misma máquina EC2 al robar sus credenciales.
En otras palabras, una aplicación maliciosa en un clúster ECS podría asumir 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 bien 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 pasar por el agente y obtener credenciales para cualquier tarea en el host. Toda la secuencia es la siguiente –
- Obtenga las credenciales de rol de IAM del huésped (rol de instancia de EC2) para hacerse pasar por el agente
- Descubra el punto final del plano de control de la CES con el que el agente habla
- Reúna los identificadores necesarios (nombre de clúster/ARN, ARN de instancia de contenedor, información de la versión del agente, versión de Docker, versión 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 pasar por el agente con el parámetro SendCredentials establecido en «Verdadero»
- Credenciales de cosecha para todas las tareas en ejecución en ese caso
«El canal de agente falsificado también 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 nada parece mal».
«Al hacerse pasar por la conexión aguas arriba del agente, Ecscape colapsa completamente ese modelo de confianza: un contenedor comprometido puede recopilar pasivamente las credenciales de rol de IAM de cualquier otra tarea en la misma instancia de EC2 e inmediatamente actuar 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 escalada de privilegios de tarea cruzada, la exposición a los secretos y la exfiltración de metadatos.
Después de la divulgación responsable, Amazon ha enfatizado la necesidad 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 acceder potencialmente a las credenciales para otras tareas en la misma instancia de contenedores».
Como mitigaciones, se recomienda evitar la implementación de tareas de alto privilegio junto con tareas no confiables o de bajo privilegio en la misma instancia, use AWS Fargate para un verdadero aislamiento, desactive o restringirá el acceso 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 lección principal es que debe tratar cada contenedor como potencialmente comprometible y restringir rigurosamente su radio de explosión», dijo Haziz. «Las convenientes abstracciones de AWS (roles de tareas, servicio de metadatos, etc.) hacen la vida más fácil para los desarrolladores, pero cuando múltiples tareas con diferentes niveles de privilegios comparten un huésped subyacente, su seguridad es tan fuerte como los mecanismos que los aislan, mecanismos que pueden tener debilidades sutiles».
El desarrollo se produce a raíz de varias debilidades de seguridad relacionadas con la nube 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 haber permitido a un atacante evitar la revisión del mantenedor y construir un código no revisado después 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 girar en los servicios de OCI al engañar a una víctima, que ya registró Oracle Cloud, para visitar una página HTML maliciosa alojada en un servidor por medio de un ataque de un ataque
- Una técnica de ataque llamada 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 escalada de privilegios a través de la autenticación federada
- Una vulnerabilidad de escalada de privilegio en el servicio de aprendizaje automático de Azure que permite a un atacante con solo acceso de cuenta de almacenamiento para modificar los scripts de Invoker almacenados en la cuenta de almacenamiento de AML y ejecutar código arbitrario dentro de una tubería AML, lo que les permite extraer secretos de las bóvedas clave de Azure, privilegios de escala y acceso más amplio a la nube de recursos nubes de nubes en la nube de la nube de nubes.
- Una vulnerabilidad de alcance 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 arbitrario
- Una técnica de ataque que abusa de Azure Arc para la escalada de privilegios al aprovechar el papel de administrador de recursos de la máquina conectada Azure y como mecanismo de persistencia al configurar como comando y control (C2)
- Un caso de roles de lector 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 clave para acceder a los activos de la nube 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 resumen 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 abusar de la infraestructura en la nube de Google para obtener acceso no autorizado a IXP LAN internos.
- Una extensión de una vulnerabilidad de escalada de privilegio de Google Cloud llamado Función Confused que se puede adaptar a otras plataformas en la nube como AWS y Azure utilizando funciones de AWS Lambda y Azure, respectivamente, además de extenderlo para realizar una enumeración ambiental.
«La estrategia de mitigación más efectiva para proteger su entorno de un comportamiento similar del actor de amenaza es garantizar que todos los SA (cuenta de servicio) dentro de su entorno en la nube se adhieran al principio de menor 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 nube estén actualizados con los últimos parches de seguridad. Si están presentes Legacy SAS, reemplácelos con SAS de menos privilegios».