Seguridad

La identidad del metadato EC2 169.254.169.254 - Dirección link-local y diseño de IMDSv2

Explicamos por qué el endpoint del servicio de metadatos de instancias EC2 169.254.169.254 es una dirección link-local, la historia de su explotación en ataques SSRF, y las circunstancias que llevaron a la creación de la autenticación basada en tokens de IMDSv2.

約 7 分で読めます

¿Dónde está 169.254.169.254?

Al acceder a http://169.254.169.254/latest/meta-data/ desde dentro de una instancia EC2, se devuelven metadatos sobre la instancia como ID de instancia, AMI ID, credenciales temporales del rol IAM y configuración de red. Esta dirección 169.254.169.254 no es un servidor en Internet, sino un servicio local proporcionado por el hipervisor del Nitro System. 169.254.0.0/16 es una dirección link-local definida en RFC 3927, un rango de direcciones especial que no se reenvía a través de routers. Es decir, las solicitudes a esta dirección no salen de la instancia y el hipervisor responde directamente. Este diseño hace que el servicio de metadatos no se vea afectado por fallos de red ni dependa de la configuración de enrutamiento de la VPC. Desde el momento en que la instancia se inicia, incluso antes de que se complete la configuración de red, se puede acceder al servicio de metadatos. La razón por la que cloud-init obtiene primero los datos de usuario y la configuración de red del servicio de metadatos al realizar la configuración inicial de la instancia es esta alta confiabilidad.

El incidente de Capital One - El día que los metadatos se filtraron por SSRF

En julio de 2019, ocurrió un incidente en Capital One (un importante banco estadounidense) donde se filtraron datos personales de aproximadamente 100 millones de personas. El atacante explotó una vulnerabilidad SSRF (Server-Side Request Forgery) existente en la aplicación web de Capital One para obtener credenciales temporales del rol IAM del servicio de metadatos de la instancia EC2. SSRF es un ataque que hace que una aplicación del lado del servidor ejecute solicitudes a URLs arbitrarias. El atacante hizo que la aplicación web enviara una solicitud a http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name, obteniendo la clave de acceso, clave secreta y token de sesión del rol IAM. Con estas credenciales accedió a buckets S3 y descargó grandes cantidades de datos personales. Este incidente expuso la debilidad de diseño de IMDSv1 (Instance Metadata Service Version 1). IMDSv1 devuelve metadatos con simples solicitudes HTTP GET, haciéndolo fácilmente accesible mediante ataques SSRF.

IMDSv2 - Defensa mediante autenticación basada en tokens

En respuesta al incidente de Capital One, AWS lanzó IMDSv2 (Instance Metadata Service Version 2) en noviembre de 2019. IMDSv2 es un método de autenticación basado en tokens que requiere un token de sesión para acceder a los metadatos. Para obtener metadatos con IMDSv2, primero se debe obtener un token de sesión con una solicitud PUT, y luego enviar una solicitud GET incluyendo ese token en el encabezado HTTP. La razón por la que esta autenticación de 2 pasos previene ataques SSRF es que la mayoría de las vulnerabilidades SSRF solo pueden ejecutar solicitudes GET. Las vulnerabilidades SSRF que pueden ejecutar solicitudes PUT son raras, y además se requiere la operación compleja de extraer el token del encabezado de respuesta e incluirlo en la siguiente solicitud. Adicionalmente, la solicitud de obtención de token de IMDSv2 requiere el encabezado X-aws-ec2-metadata-token-ttl-seconds, y las solicitudes reenviadas por IP (ya que el TTL se establece en 1, no pueden cruzar saltos de red) también se bloquean. Desde 2024, AWS ha cambiado el valor predeterminado para nuevas instancias a solo IMDSv2, recomendando encarecidamente deshabilitar IMDSv1.

Panorama completo de la información obtenible mediante metadatos

La información obtenible del servicio de metadatos es amplia. Incluye información básica de la instancia (instance-id, instance-type, ami-id, hostname), información de red (local-ipv4, public-ipv4, mac, network/interfaces), credenciales temporales del rol IAM (iam/security-credentials/role-name), datos de usuario (user-data) y mapeo de dispositivos de bloque (block-device-mapping). Particularmente importantes son las credenciales temporales del rol IAM. Al adjuntar un rol IAM a una instancia EC2, se pueden obtener claves de acceso temporales, claves secretas y tokens de sesión desde el servicio de metadatos. Los AWS SDK utilizan este mecanismo internamente de forma automática, eliminando la necesidad de que los desarrolladores codifiquen claves de acceso en el código. Las credenciales temporales se rotan automáticamente con una validez típica de 6 horas. El servicio de metadatos también incluye los datos de usuario de la instancia. Los datos de usuario son scripts o datos especificados al lanzar la instancia que cloud-init usa para la configuración inicial. Incluir contraseñas o secretos en los datos de usuario es peligroso ya que cualquiera puede leerlos a través del servicio de metadatos.

Medidas de fortalecimiento de seguridad del servicio de metadatos

Además de habilitar IMDSv2, hay varias formas de fortalecer la seguridad del servicio de metadatos. Primero, establecer HttpPutResponseHopLimit en 1. Esto bloquea el acceso a metadatos desde dentro de contenedores. Si las aplicaciones dentro de contenedores ECS o Docker no necesitan acceder al servicio de metadatos, establecer el límite de saltos en 1 previene ataques SSRF desde contenedores. Segundo, deshabilitar el servicio de metadatos por completo. Estableciendo HttpEndpoint en disabled, se bloquea completamente el acceso al servicio de metadatos. Para instancias que no necesitan credenciales del rol IAM (cuando se usan credenciales fijas), deshabilitar el servicio de metadatos es lo más seguro. Tercero, minimizar los permisos del rol IAM. Incluso si las credenciales se filtran del servicio de metadatos, si los permisos del rol son mínimos, el daño se puede limitar. En el incidente de Capital One, el hecho de que el rol filtrado tuviera amplios permisos de acceso a buckets S3 amplificó el daño. Para aprender sistemáticamente sobre diseño de seguridad de EC2, pueden ser útiles libros especializados (Amazon).

Servicios relacionados

Amazon EC2Un servicio de cómputo que proporciona servidores virtuales en la nubeAWS IAMServicio de autenticación y autorización para gestionar de forma segura el acceso a los recursos de AWS

Artículos relacionados

La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.Lógica de evaluación de políticas IAM explicada - Cómo la denegación implícita pierde ante la autorización explícitaUna explicación paso a paso de cómo IAM evalúa las solicitudes para permitirlas o denegarlas, cubriendo la prioridad de denegación implícita, autorización explícita y denegación explícita, así como la lógica de intersección para SCPs, límites de permisos y políticas de sesión.Cómo elegir instancias Amazon EC2 - Optimización de familias de instancias y opciones de compraOrganizamos las características de las familias de instancias y la ventaja de rendimiento de los procesadores Graviton, y presentamos directrices para diferenciar las opciones de compra On-Demand, Reserved y Spot.

Más sobre este tema

Detección de permisos excesivos con IAM Access Analyzer - Análisis de acceso externo y permisos no utilizadosDetecta permisos no utilizados en roles IAM mediante análisis basado en CloudTrail y genera automáticamente políticas de mínimo privilegio. Cubre la detección de acceso externo y la integración de verificaciones de políticas personalizadas en pipelines CI/CD.Automatización de la gestión de certificados SSL/TLS con AWS Certificate Manager - Desde la emisión hasta la rotaciónExplicamos la emisión gratuita de certificados públicos con ACM, la validación DNS, la renovación automática y el despliegue en ALB y CloudFront.Obtención de informes de cumplimiento con AWS Artifact - Respuesta a auditorías y gestión de contratosPresenta cómo obtener informes de auditoría SOC, PCI DSS e ISO bajo demanda, y aplicar BAA y GDPR DPA de forma masiva a toda la organización con Organizations.Automatización de auditorías - Recopilación continua de evidencias de cumplimiento con AWS Audit ManagerExplica la recopilación automática de evidencias de auditoría con AWS Audit Manager. Presenta la evaluación automática basada en frameworks (SOC 2, PCI DSS, GDPR, etc.), gestión centralizada de evidencias y generación de informes de auditoría.La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.Por qué el usuario root de una cuenta AWS es peligroso - Filosofía de diseño de separación de privilegios y práctica de selladoExplicamos por qué el usuario root de AWS tiene privilegios que IAM no puede restringir, la lista de operaciones que solo el usuario root puede realizar, cómo configurar MFA y la estrategia de sellado mediante la gestión de acceso root de Organizations.Gestión de certificados y HTTPS - Operaciones automatizadas de certificados TLS con AWS Certificate ManagerAprenda sobre la emisión de certificados TLS/SSL, renovación automática y despliegue usando AWS Certificate Manager (ACM). Cubre la integración con CloudFront, ALB y API Gateway, validación DNS y uso de Private CA.Gestión dedicada de claves con AWS CloudHSM - Cifrado compatible con FIPS 140-2 Level 3Logre gestión de claves compatible con FIPS 140-2 Level 3 con instancias HSM dedicadas. Aprenda cuándo elegir CloudHSM sobre KMS y cómo integrar ambos mediante almacenes de claves personalizados de KMS.

Artículos y servicios similares

La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.AWS IAMServicio de autenticación y autorización para controlar de forma segura el acceso a recursos AWS, proporcionando gestión de acceso granular mediante usuarios, grupos, roles y políticasAmazon EC2 Instance ConnectUn servicio para conectarse de forma segura a instancias EC2 sin distribuir previamente claves SSHAmazon CognitoServicio completamente administrado que añade funcionalidad de autenticación y autorización a aplicaciones web y móviles, compatible con login social y federación SAMLDiseño de gestión de identidad y acceso - Lograr seguridad Zero Trust con IAMAprende técnicas de diseño de gestión de acceso con AWS IAM, incluyendo el principio de mínimo privilegio, diseño de políticas y lograr seguridad Zero Trust mediante integración con Cognito.