whoAMI: Nuevo Ataque a AWS

Investigadores de ciberseguridad han descubierto un nuevo ataque de confusión de nombres denominado whoAMI, que permite a los atacantes ejecutar código en cuentas de Amazon Web Services (AWS) mediante la publicación de una Amazon Machine Image (AMI) maliciosa con un nombre específico.

Según Seth Art, investigador de Datadog Security Labs, esta vulnerabilidad podría escalarse para comprometer miles de cuentas AWS.

"El patrón vulnerable se encuentra en muchos repositorios de código, tanto privados como públicos", explicó Art en un informe compartido con The Hacker News.

El ataque whoAMI se clasifica como un ataque a la cadena de suministro, en el que un atacante publica un recurso malicioso y engaña al software mal configurado para que lo use en lugar de la versión legítima.

¿Cómo Funciona el Ataque whoAMI en AWS?

El ataque whoAMI explota la forma en que los desarrolladores buscan Amazon Machine Images (AMI) dentro de AWS. Este tipo de imagen es fundamental para iniciar instancias en Elastic Compute Cloud (EC2).

El problema ocurre cuando los desarrolladores omiten el atributo --owners al buscar una AMI a través de la API ec2:DescribeImages. Esto genera una vulnerabilidad cuando se cumplen estas tres condiciones:

🔹 Uso de filtros de nombre en la búsqueda de AMI.
🔹 No especificar los parámetros "owner", "owner-alias" o "owner-id" en la consulta.
🔹 Seleccionar la imagen más reciente (most_recent=true) de la lista devuelta.

Bajo estas circunstancias, un atacante puede publicar una AMI maliciosa con un nombre coincidente con el de la búsqueda. Como resultado, la víctima puede crear una instancia EC2 con una AMI controlada por el atacante, otorgándole ejecución remota de código (RCE).

Este acceso permite a los actores de amenazas realizar movimientos laterales, exfiltración de datos y ataques posteriores dentro de la cuenta AWS comprometida.

Comparación con Ataques de Confusión de Dependencias

Seth Art comparó whoAMI con los ataques de confusión de dependencias, pero en este caso, el recurso malicioso no es un paquete de software (como un paquete pip), sino una imagen de máquina virtual (AMI).

La diferencia clave es que, mientras los ataques de confusión de dependencias afectan cadenas de suministro de software, el ataque whoAMI afecta infraestructura en la nube dentro de AWS.

Impacto del Ataque whoAMI y Medidas de Seguridad en AWS

Según Datadog, aproximadamente el 1% de las organizaciones monitoreadas por la empresa fueron afectadas por este ataque. Se encontraron ejemplos de código vulnerable escrito en:

✅ Python
✅ Go
✅ Java
✅ Terraform
✅ Pulumi
✅ Bash shell

Respuesta de AWS y Solución Implementada

Tras la divulgación responsable del ataque el 16 de septiembre de 2024, Amazon Web Services abordó el problema tres días después.

AWS declaró que, tras un análisis exhaustivo, no se encontró evidencia de explotación en entornos reales, más allá de los experimentos realizados por los investigadores de seguridad.

En respuesta a esta vulnerabilidad, AWS introdujo en diciembre de 2024 una nueva configuración de seguridad llamada "AMI Permitidas", la cual permite a los clientes restringir la detección y el uso de AMI dentro de sus cuentas.

Recomendaciones para Protegerse del Ataque whoAMI

Para mitigar el riesgo de explotación, se recomienda a los usuarios de AWS:

🔹 Especificar el parámetro "--owners" al buscar AMIs en la API ec2:DescribeImages.
🔹 Utilizar la configuración "AMI Permitidas" para restringir imágenes a fuentes de confianza.
🔹 Evitar la selección automática de la imagen más reciente (most_recent=true) sin filtrar por propietario.
🔹 Monitorear activamente logs de instancias EC2 para detectar actividades sospechosas.

Además, HashiCorp Terraform, a partir de la versión 5.77.0, ha comenzado a emitir advertencias cuando se usa "most_recent = true" sin un filtro de propietario. En la futura versión 6.0.0, esta advertencia se convertirá en un error.

La Seguridad en AWS Depende de una Configuración Correcta

El ataque whoAMI en AWS es un claro ejemplo de cómo configuraciones erróneas pueden exponer infraestructuras en la nube a ataques de ejecución de código remoto (RCE).

Para prevenir riesgos, es fundamental que los equipos de seguridad auditen sus configuraciones de AWS, implementen los controles recomendados por Amazon y se mantengan actualizados con las últimas mejoras de seguridad en herramientas como Terraform y Pulumi.

La seguridad en la nube requiere configuraciones precisas y buenas prácticas para evitar que actores de amenazas exploten vulnerabilidades en plataformas como Amazon Web Services (AWS).

Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta