Explotación del Servicio de Metadata de AWS: Exponiendo IMDSv1 y Robando

Cómo SSRF y malas configuraciones exponen IMDSv1, dando acceso a credenciales IAM y a todo tu entorno AWS

La revolución en la nube prometió seguridad, escalabilidad y simplicidad. Sin embargo, en la infraestructura de AWS se esconde un servicio aparentemente inocuo que se ha convertido en la llave maestra para innumerables brechas: el Servicio de Metadata de Instancias (IMDS). Cuando se explota mediante ataques de Server-Side Request Forgery (SSRF) y malas configuraciones, IMDSv1 puede entregar a los atacantes las llaves de todo tu entorno AWS—incluyendo credenciales IAM, metadatos de instancias y acceso sin restricciones a recursos sensibles.

¿El ejemplo más famoso? La brecha de Capital One en 2019, donde se expusieron más de 100 millones de registros de clientes, resultando en una multa de 80 millones de dólares y daños reputacionales incalculables. El ataque no fue sofisticado; explotó una vulnerabilidad bien conocida que muchas organizaciones aún pasan por alto hoy.

¿Qué es el Servicio de Metadata de AWS?

El Servicio de Metadata de Instancias es un endpoint API accesible desde las instancias EC2 en AWS en la dirección IP 169.254.169.254. Proporciona información crucial que las aplicaciones y servicios en las instancias EC2 necesitan para funcionar correctamente, incluyendo:

Detalles de la instancia: hostname, ID de la instancia, configuración de red
Credenciales de roles IAM: claves temporales y tokens de sesión
Datos de usuario: scripts personalizados y datos de configuración
Grupos de seguridad: reglas de acceso a la red

Este servicio es esencial para las operaciones en AWS. Las aplicaciones usan IMDS para obtener credenciales temporales asociadas a roles IAM, eliminando la necesidad de codificar claves de acceso en las aplicaciones—una mejora significativa en seguridad cuando se usa correctamente.

IMDSv1 vs. IMDSv2: Una división crítica en seguridad

AWS ofrece dos versiones del Servicio de Metadata de Instancias, y entender la diferencia entre ellas es fundamental:

IMDSv1 (Versión heredada): - Usa un protocolo simple de solicitud-respuesta - Solo requiere solicitudes HTTP GET - Sin autenticación ni gestión de sesiones - Vulnerable a ataques SSRF - Aún habilitado por defecto en muchas instancias

IMDSv2 (Versión segura): - Orientado a sesiones con autenticación basada en tokens - Requiere una solicitud PUT inicial para generar el token de sesión - El token debe incluirse en un encabezado personalizado (X-aws-ec2-metadata-token) - Protección basada en TTL contra ataques en capa de red - Mitiga efectivamente vulnerabilidades SSRF

¿El problema? A pesar de que AWS ha avanzado para hacer de IMDSv2 el valor predeterminado para nuevas instancias desde noviembre de 2023, investigaciones muestran que en 2022 aproximadamente el 93% de las instancias EC2 aún no aplican IMDSv2. Muchas organizaciones siguen operando con IMDSv1, dejando abiertas las mismas vías de ataque que permitieron la brecha de Capital One.

La anatomía de un ataque de explotación de IMDS

Para entender por qué IMDSv1 es tan peligroso, analicemos cómo los atacantes lo explotan mediante vulnerabilidades SSRF.

Paso 1: Reconocimiento

Los atacantes comienzan escaneando aplicaciones vulnerables en la infraestructura de AWS. Buscan: - Aplicaciones web con campos de entrada de usuario - Instancias públicas con servicios expuestos - Aplicaciones que hacen solicitudes HTTP basadas en URLs proporcionadas por el usuario - Firewalls de aplicaciones web mal configurados (WAFs)

Paso 2: Descubrimiento de vulnerabilidades SSRF

Server-Side Request Forgery ocurre cuando una aplicación puede ser engañada para hacer solicitudes HTTP a destinos no deseados. Escenarios vulnerables comunes:

Parámetros URL: aplicaciones que obtienen contenido de URLs suministradas por el usuario
Procesadores de imágenes: servicios que descargan y procesan imágenes externas
Implementaciones de Webhook: sistemas que llaman a endpoints definidos por el usuario
Generadores de PDF: herramientas que renderizan contenido web a PDF
Funciones de carga de archivos: aplicaciones que procesan archivos subidos con referencias externas

Paso 3: Acceso al Servicio de Metadata

Una vez identificada una vulnerabilidad SSRF, los atacantes la explotan para acceder al endpoint de metadata:

# Acceso directo a IMDS (solo desde dentro de la instancia EC2)
curl http://169.254.169.254/latest/meta-data/

# A través de vulnerabilidad SSRF en la aplicación vulnerable
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Paso 4: Extracción de credenciales IAM

La verdadera recompensa son las credenciales del rol IAM:

# Listar roles IAM disponibles
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Obtener credenciales de un rol específico
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[nombre-del-rol]

Esto devuelve datos en JSON con: - AccessKeyId: clave de acceso de AWS - SecretAccessKey: clave secreta de AWS - Token: token de sesión - Expiration: cuándo expiran las credenciales

Paso 5: Uso de credenciales robadas

Con estas credenciales, los atacantes pueden: - Listar y acceder a buckets S3 con datos sensibles - Lanzar nuevas instancias EC2 para minería de criptomonedas u otros ataques - Modificar grupos de seguridad y configuraciones de red - Acceder a bases de datos y otros servicios de AWS - Exfiltrar datos a destinos externos - Establecer mecanismos de persistencia

Impacto real: La brecha de Capital One

La brecha de Capital One en 2019 ejemplifica el potencial devastador de la explotación de IMDS. Esto fue lo que ocurrió:

Cronología del ataque: - 22-23 de marzo de 2019: Paige Thompson, ex empleada de AWS, explotó una vulnerabilidad SSRF en el WAF de Capital One - Vulnerabilidad explotada: Un componente mal configurado del WAF permitió ataques SSRF hacia el servicio de metadata - Credenciales robadas: Thompson obtuvo credenciales temporales de AWS desde el rol IAM de la instancia EC2 - Datos accedidos: Usando las credenciales robadas, listó más de 700 buckets S3 y descargó aproximadamente 30GB de datos - 19 de julio de 2019: Se descubrió la brecha tras que Thompson lo presumiera en GitHub y canales IRC

El daño: - 106 millones de registros de clientes expuestos (100 millones en EE.UU., 6 millones en Canadá) - 140,000 números de Seguro Social comprometidos - 80,000 números de cuenta bancaria filtrados - 1 millón de números de Seguro Social canadienses expuestos - Información personal incluyendo nombres, direcciones, puntajes de crédito y datos de transacciones - Multa de 80 millones de dólares por autoridades regulatorias - Costos totales superiores a 150 millones de dólares incluyendo remediación y pérdida de confianza - Daño reputacional severo y caída en el precio de las acciones

Causas raíz: 1. Vulnerabilidad SSRF en la aplicación WAF 2. Uso de IMDSv1 en lugar de IMDSv2, más seguro 3. Roles IAM demasiado permisivos con acceso amplio a S3 4. Datos sin cifrar almacenados en buckets S3 5. Monitoreo insuficiente que retrasó la detección en cuatro meses

¿Lo más preocupante? Este ataque no requirió técnicas sofisticadas; solo explotó vulnerabilidades bien conocidas que debieron haberse mitigado.

Campañas recientes de explotación y amenazas emergentes

La explotación de IMDS no es cosa del pasado. Continúan campañas activas dirigidas a infraestructuras vulnerables en AWS:

Campaña de marzo 2025

Investigadores de seguridad detectaron una campaña novedosa dirigida a sitios web alojados en instancias EC2 mediante vulnerabilidades SSRF. La campaña explotó principalmente:

CVE-2017-9841: Ejecución remota de código en PHPUnit (15 veces más activa que la segunda CVE)
CVE-2024-4577: Tendencias de actividad en aumento sostenido
CVE-2019-9082: Incremento constante en intentos de explotación

La campaña se originó desde IPs pertenecientes a ASN 34534 (FBW NETWORKS SAS), con infraestructura en Francia y Rumania. Los atacantes usaron técnicas sencillas de SSRF para consultar endpoints de IMDSv1 y extraer credenciales.

Explotación de CVE-2025-51591 en Pandoc

En septiembre de 2025, la firma de seguridad Wiz descubrió que atacantes explotaron una vulnerabilidad en Pandoc (un convertidor de documentos popular) para atacar IMDS en AWS. La vulnerabilidad permitía incluir elementos iframe con atributos src apuntando al servicio de metadata.

El ataque no tuvo éxito final debido a la implementación de IMDSv2, demostrando la importancia de actualizar desde la versión heredada. Sin embargo, los esfuerzos continúan, y los atacantes buscan nuevos vectores SSRF para explotar vulnerabilidades en IMDS.

Actor de amenaza UNC2903

En junio de 2021, el grupo de amenazas UNC2903 explotó una vulnerabilidad en la herramienta de gestión de bases de datos Adminer usando una técnica de redirección inteligente. Configuraron relays con scripts de redirección 301 para engañar a servidores víctimas y que siguieran redirecciones que devolvían errores con credenciales API de AWS. Las credenciales obtenidas permitieron acceso a las cuentas AWS de las víctimas.

Por qué IMDSv1 sigue siendo un riesgo crítico

A pesar de la disponibilidad de IMDSv2 desde 2019, IMDSv1 continúa representando riesgos importantes:

Vulnerabilidades técnicas

Sin autenticación requerida: IMDSv1 usa solicitudes GET sin autenticación, por lo que es trivial acceder si se encuentra una vulnerabilidad SSRF.

Protocolo simple de solicitud-respuesta: Hace que sea un objetivo perfecto para ataques SSRF, ya que los atacantes solo necesitan forzar al servidor a hacer solicitudes HTTP GET.

Sin requisitos de encabezados: A diferencia de IMDSv2, no requiere encabezados personalizados, facilitando la explotación mediante vulnerabilidades SSRF básicas.

Desafíos organizacionales

Sistemas heredados: Instancias de larga duración pueden tener aplicaciones que solo soportan IMDSv1, dificultando la migración.

Falta de conciencia: Muchas organizaciones no comprenden las implicaciones de seguridad de usar IMDSv1 frente a IMDSv2.

Configuraciones por defecto: Aunque AWS cambió los valores predeterminados para nuevas instancias, muchas infraestructuras existentes mantienen compatibilidad con IMDSv1.

Entornos complejos: Grandes despliegues en AWS pueden tener miles de instancias, haciendo la migración completa un reto.

Detección e identificación

Antes de solucionar, necesitas identificar dónde aún se usa IMDSv1:

Usando la consola de AWS

Ve al panel de EC2 y revisa la columna “IMDSv2” en cada instancia. Las que muestran “Opcional” tienen IMDSv1 habilitado.

Reglas de AWS Config

Implementa la regla ec2-imdsv2-check en AWS Config, que marca como NO CUMPLIENTE si HttpTokens está en “opcional”.

Métricas de CloudWatch

Monitorea la métrica MetadataNoToken en CloudWatch, que rastrea llamadas a IMDSv1. Valores cero indican que la instancia está lista para requerir IMDSv2 exclusivamente.

Security Hub de AWS

Configura Security Hub con agregación entre regiones y cuentas para identificar instancias con IMDSv1 en toda tu organización AWS.

Analizador de paquetes IMDS

Utiliza la herramienta de análisis de paquetes IMDS de AWS para identificar qué componentes hacen llamadas a IMDSv1, priorizando actualizaciones.

Estrategias de mitigación integrales

Protegerse contra la explotación de IMDS requiere un enfoque en múltiples capas:

1. Aplicar IMDSv2 de inmediato

Para nuevas instancias:

# Lanzar instancia con IMDSv2 obligatorio
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1

Para instancias existentes:

# Requerir IMDSv2 en instancia existente
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

Usando Terraform:

resource "aws_instance" "ejemplo" {
  ami           = "ami-xxxxx"
  instance_type = "t3.micro"
  
  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

2. Implementar el menor privilegio en roles IAM

Nunca asignes roles IAM con permisos amplios. Sigue estos principios:

Otorga solo los permisos mínimos necesarios para la función de la instancia
Usa ARNs específicos en lugar de comodines
Implementa claves de condición en IAM para restringir el uso de credenciales
Audita y reduce permisos periódicamente usando Access Advisor

Usa claves de condición en IAM:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sensitive-bucket/*",
    "Condition": {
      "StringEquals": {
        "ec2:RoleDelivery": "2.0"
      }
    }
  }]
}

Esta política asegura que solo las credenciales obtenidas vía IMDSv2 puedan acceder al bucket S3.

3. Desactivar IMDS cuando no sea necesario

Para instancias que no requieren acceso a IMDS:

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-endpoint disabled

4. Implementar protecciones a nivel de red

Configuración WAF: - Desplegar AWS WAF con reglas para detectar y bloquear intentos SSRF - Implementar validación estricta de entradas - Monitorear patrones sospechosos dirigidos a endpoints de metadata

Seguridad en VPC: - Usar Grupos de Seguridad para restringir tráfico saliente - Implementar segmentación de red - Desplegar endpoints VPC para servicios AWS y evitar rutas por internet

5. Asegurar el código de la aplicación

Validación de entrada: - Nunca confiar en datos de usuario al hacer solicitudes HTTP - Implementar listas blancas de dominios permitidos - Rechazar solicitudes a rangos IP privados (incluyendo 169.254.x.x) - Validar y sanitizar todos los parámetros URL

Análisis de URLs:

from urllib.parse import urlparse

def es_url_segura(url):
    parsed = urlparse(url)
    
    # Bloquear IPs privadas y servicio de metadata
    ips_bloqueadas = ['169.254.169.254', '127.0.0.1', 'localhost']
    if parsed.hostname in ips_bloqueadas:
        return False
    
    # Solo permitir dominios específicos
    dominios_permitidos = ['trusted-domain.com']
    if parsed.hostname not in dominios_permitidos:
        return False
    
    return True

6. Habilitar monitoreo integral

AWS GuardDuty: Habilitar GuardDuty para detectar patrones inusuales en uso de credenciales y posibles robos de credenciales IMDS.

CloudTrail: Monitorear: - llamadas API inusuales desde instancias EC2 - uso de credenciales desde ubicaciones inesperadas - transferencias grandes de datos a destinos externos - modificaciones en roles y políticas IAM

Security Hub: Agregar hallazgos en varias cuentas y regiones para mantener visibilidad.

7. Implementar políticas de control de servicios

Para AWS Organizations, aplicar IMDSv2 a nivel organizacional:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {
        "ec2:MetadataHttpTokens": "required"
      }
    }
  }]
}

Esta política evita lanzar instancias sin la aplicación de IMDSv2 en toda la organización.

El camino a seguir: mejores prácticas de migración

Pasar de IMDSv1 a IMDSv2 requiere planificación cuidadosa:

Fase 1: Evaluación (Semanas 1-2)

Inventariar todas las instancias EC2 en regiones y cuentas
Identificar las que usan IMDSv1
Documentar aplicaciones y servicios en cada instancia
Evaluar compatibilidad de software con IMDSv2

Fase 2: Pruebas (Semanas 3-4)

Actualizar SDKs, CLI y herramientas a versiones que soporten IMDSv2
Probar en entornos no productivos con IMDSv2 habilitado
Monitorear métricas MetadataNoToken durante las pruebas
Actualizar scripts personalizados que hagan llamadas a IMDSv1

Fase 3: Migración gradual (Semanas 5-8)

Comenzar con cargas de trabajo no críticas
Habilitar IMDSv2 manteniendo IMDSv1 opcional
Monitorear problemas durante varios días
Pasar a cargas productivas con compatibilidad comprobada

Fase 4: Enforzamiento (Semana 9+)

Requerir IMDSv2 en instancias migradas
Implementar SCPs que bloqueen IMDSv1
Establecer monitoreo continuo
Documentar lecciones aprendidas y actualizar manuales

Compatibilidad de software

Las herramientas modernas de AWS soportan IMDSv2: - SDKs de AWS (todos los lenguajes principales) - AWS CLI v2 - Agente de AWS Systems Manager - Agente de Amazon ECS - Amazon Linux 2023 (solo IMDSv2 por defecto)

Para aplicaciones heredadas, considera contenerización o actualización a versiones compatibles antes de aplicar IMDSv2.

Más allá de AWS: perspectiva multicloud

Aunque este artículo se centra en AWS, servicios similares existen en otros proveedores de nube:

Google Cloud Platform: - Servicio de metadata en 169.254.169.254 - Requiere encabezado Metadata-Flavor: Google - Este requisito de encabezado ofrece protección SSRF similar a IMDSv2

Microsoft Azure: - Servicio de metadata en 169.254.169.254 - Requiere encabezado Metadata: true - La versión API debe especificarse en la URL

Oracle Cloud Infrastructure: - Servicio de metadata con autenticación mejorada - Controles de acceso en múltiples capas

Estos proveedores implementaron protecciones basadas en encabezados antes que AWS, resaltando la importancia de enfoques de defensa en profundidad.

Conclusión: Es momento de actuar

El Servicio de Metadata de Instancias de AWS sigue siendo una superficie de ataque crítica que las organizaciones no pueden permitirse ignorar. Aunque IMDSv1 sentó las bases para operaciones seguras en la nube en 2012, el panorama de amenazas en evolución lo ha vuelto obsoleto y peligroso.

La brecha de Capital One demostró que vulnerabilidades SSRF combinadas con IMDSv1 crean una tormenta perfecta para los atacantes—que resultó en más de 150 millones de dólares en daños y la exposición de 106 millones de registros de clientes. Las campañas recientes muestran que los atacantes siguen buscando activamente vulnerabilidades SSRF para explotar IMDS, con nuevos vectores emergiendo regularmente.

La buena noticia: AWS ofrece herramientas robustas de mitigación mediante IMDSv2, y controles de seguridad integrales para proteger tu infraestructura en la nube.

La mala noticia: La mayoría de las organizaciones no han implementado estas protecciones, dejando abiertas las mismas vulnerabilidades que han devastado a otras.

El imperativo: Cada día que usas IMDSv1 es un día que entregas a los atacantes una llave maestra para tu entorno en la nube. La brecha de Capital One ocurrió en 2019—seis años después, no hay excusa para no migrar a IMDSv2.

Acciones inmediatas para implementar ya

Esta semana: Inventariar todas las instancias EC2 y detectar uso de IMDSv1
Este mes: Implementar reglas de AWS Config y Security Hub para monitoreo continuo
Este trimestre: Completar migración a IMDSv2 en todas las instancias
De forma continua: Aplicar IMDSv2 en todas las nuevas instancias mediante SCPs
De forma permanente: Monitorear, auditar y mejorar permisos en roles IAM

La llave maestra de tu entorno en AWS está a simple vista. ¿La asegurarás antes de que los atacantes la encuentren, o tu organización se convertirá en la próxima advertencia?

Recursos adicionales

Palabras clave: AWS IMDS, IMDSv1, IMDSv2, ataques SSRF, seguridad EC2, servicio de metadata de AWS, brecha Capital One, seguridad en la nube, credenciales IAM, servicio de metadatos de instancias, mejores prácticas de seguridad en AWS, server-side request forgery, explotación en la nube, vulnerabilidad en AWS, robo de credenciales EC2