¡El exploit de AWS que permite a los hackers tomar el control de tu nube sin que lo sepas!

La seguridad en la nube sigue siendo un desafío en constante evolución, ya que surgen nuevos vectores de ataque que a menudo aprovechan errores de configuración en lugar de vulnerabilidades directas en el software. En agosto de 2024, investigadores de Datadog Security Labs descubrieron un nuevo ataque de confusión de nombres que explota una falla en la manera en que las organizaciones recuperan Imágenes de Máquina de Amazon (AMIs) para crear instancias en AWS.

Este ataque, denominado whoAMI, permite a los atacantes ejecutar código arbitrario dentro de cuentas de AWS al manipular la forma en que los sistemas seleccionan las AMIs. Este informe ofrece un análisis detallado de la explotación de la vulnerabilidad, su impacto, estrategias de mitigación y mejores prácticas para profesionales de ciberseguridad en entornos de nube.

Entendiendo el Ataque whoAMI

El Papel de las AMIs en la Infraestructura de AWS

Las Imágenes de Máquina de Amazon (AMIs) son componentes esenciales en AWS, utilizadas como plantillas preconfiguradas de máquinas virtuales para lanzar instancias EC2. Las organizaciones pueden usar AMIs oficiales, personalizadas o contribuidas por la comunidad.

Para seleccionar una AMI adecuada, los usuarios de AWS suelen utilizar la API DescribeImages, que permite buscar la versión más reciente de una imagen específica (como Ubuntu o Amazon Linux). Sin embargo, el ataque whoAMI explota una configuración errónea en la recuperación de AMIs.

Mecanismo del Ataque: Explotación de la Confusión de Nombres

El ataque whoAMI es una variante de un ataque de confusión de nombres, un subtipo de ataque a la cadena de suministro. Similar a los ataques de confusión de dependencias, esta técnica engaña a los sistemas mal configurados para seleccionar un recurso malicioso en lugar del legítimo. Sin embargo, en este caso, el recurso comprometido no es una dependencia de software, sino una imagen de máquina virtual (AMI).

El ataque se desarrolla de la siguiente manera:

  1. La Vulnerabilidad
    • Muchas organizaciones utilizan herramientas como Terraform o la CLI de AWS para recuperar AMIs dinámicamente.
    • Se usa una búsqueda con patrones de comodín (wildcards), como ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*.
    • A menudo, no se especifica el “propietario” de la AMI, lo que permite incluir tanto imágenes oficiales como maliciosas.
  2. Explotación por Parte del Atacante
    • Un atacante publica una AMI maliciosa con un nombre que coincide con el patrón esperado.
    • La fecha de publicación se manipula para que sea la más reciente, asegurando que cualquier búsqueda de la última AMI seleccione la imagen del atacante.
    • Cuando la infraestructura de la víctima lanza una instancia EC2 con la AMI maliciosa, el atacante obtiene acceso al sistema.
  3. Posibles Consecuencias
    • Ejecución de Código Remota: El atacante puede ejecutar código malicioso en la instancia comprometida.
    • Persistencia en el Sistema: La AMI puede contener puertas traseras para acceso prolongado.
    • Robo de Credenciales: Si hay claves IAM en la instancia, el atacante puede moverse lateralmente en AWS.
    • Compromiso de la Cadena de Suministro: Infraestructuras dependientes de AMIs contaminadas pueden verse afectadas.

Impacto Real: AWS También Fue Vulnerable

Uno de los hallazgos más preocupantes de la investigación de whoAMI fue que los propios sistemas internos de AWS eran vulnerables a este ataque.

Vulnerabilidad en la Infraestructura de AWS

Para probar el alcance de la vulnerabilidad, Datadog:

  • Publicó dos AMIs diseñadas para parecer imágenes oficiales de Amazon Linux.
  • Detectó miles de solicitudes API que obtenían sus imágenes, lo que confirmó que sistemas internos de AWS estaban seleccionando AMIs de manera insegura.

Tras la divulgación, AWS solucionó el problema rápidamente, asegurando que solo los sistemas internos no productivos fueron afectados y que no se comprometieron datos de clientes. Sin embargo, esto demuestra la gravedad de la vulnerabilidad y su potencial de explotación a gran escala.

Extensión del Problema

  • Se estima que alrededor del 1% de las organizaciones que usan AWS son vulnerables.
  • Miles de cuentas AWS podrían estar implementando AMIs comprometidas sin saberlo.

Demostración de la Explotación y Proyectos Afectados

Ejemplo de Código Vulnerable

Una configuración común en Terraform que no especifica el propietario de la AMI se vería así:

hclCopyEditdata "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

Este código obtiene la AMI más reciente sin verificar su fuente, lo que lo hace vulnerable al ataque whoAMI.

Herramientas de Código Abierto Afectadas

Datadog encontró múltiples repositorios públicos con patrones de recuperación de AMIs inseguros. Un ejemplo notable fue awslabs/aws-simple-ec2-cli, un proyecto mantenido por AWS que contenía consultas AMI con comodines sin verificación de propietario.

Cómo Detectar y Mitigar la Vulnerabilidad

Para evitar esta explotación, los equipos de seguridad deben implementar controles estrictos en la selección de AMIs y auditar sus entornos regularmente.

Cómo Identificar Código Vulnerable

  1. Auditorías de Código
    • Utilizar búsquedas en GitHub para encontrar consultas de AMI sin filtro de propietario.
    • Buscar patrones como ec2:DescribeImages sin owners.
  2. Escaneo Automatizado con Semgrep
    • Aplicar reglas de Semgrep para detectar consultas de AMI inseguras.
  3. Monitoreo con AWS CloudTrail y SIEM
    • Configurar reglas de SIEM para alertar sobre recuperaciones sospechosas de AMIs.
    • Revisar logs de AWS CloudTrail para detectar lanzamientos de instancias con AMIs inesperadas.

Estrategias de Mitigación

  1. Habilitar la Función Allowed AMIs en AWS
    • En diciembre de 2024, AWS lanzó Allowed AMIs, permitiendo a los usuarios definir una lista de proveedores de AMIs confiables.
  2. Especificar el Propietario en las Consultas
    • Asegurar que solo se utilicen AMIs verificadas de fuentes confiables.
    • Ejemplo de consulta segura:bashCopyEditaws ec2 describe-images --owners "137112412989"
    • Esto garantiza que solo se obtengan AMIs oficiales de Amazon.
  3. Usar whoAMI-Scanner de Datadog
    • Datadog desarrolló una herramienta de código abierto para detectar AMIs no verificadas.
  4. Implementar Políticas de Seguridad en IaC
    • Aplicar controles con herramientas como AWS Config, OPA y Terraform Sentinel.

Conclusión

El ataque whoAMI es un grave riesgo para la cadena de suministro en la nube, demostrando que una configuración incorrecta puede ser explotada para ejecutar código malicioso en entornos AWS.

A pesar de las nuevas medidas de seguridad de AWS, la responsabilidad de asegurar la infraestructura recae en cada organización. Implementar prácticas seguras de selección de AMIs, auditorías automatizadas y controles de acceso es esencial para proteger los entornos en la nube de ataques de confusión de nombres.

Puntos Clave para Profesionales de Ciberseguridad

✅ Las consultas mal configuradas de AMI pueden llevar a ejecución de código remoto.
✅ AWS era vulnerable pero solucionó el problema rápidamente.
✅ Especificar propietarios en las consultas de AMI es crucial para la seguridad.
✅ Habilitar Allowed AMIs en AWS mejora la protección.
✅ Se recomienda usar herramientas automatizadas para auditorías de seguridad en AWS.