Cómo un atacante podría usar metadatos de instancia para violar su aplicación en AWS


Pasar a una arquitectura nativa de la nube para las aplicaciones de su empresa puede ofrecer un gran valor comercial, agregando escala y agilidad mientras descarga tareas onerosas como parchar y actualizar la infraestructura del servidor.

Sin embargo, en cada entorno de nube, ya sea AWS, Azure, GCP u otros, existe una nueva categoría de riesgo. Las amenazas nativas de la nube provienen del nuevo contexto y los requisitos de configuración que tiene en un entorno de nube. Históricamente, la configuración predeterminada, como el acceso público a los objetos de almacenamiento, ha dejado a la vista datos confidenciales, fáciles de robar por cualquiera que rastree estas debilidades.

Es fácil cometer errores en un nuevo entorno, con nuevas configuraciones introducidas continuamente a medida que los proveedores de la nube agregan nuevas capacidades. La configuración de su entorno de nube es siempre su responsabilidad. AWS y otros no tienen control sobre cómo utiliza sus servicios. Son una plantilla a partir de la cual puedes construir.

No comprender el resultado de sus configuraciones y cómo crear aplicaciones nativas de la nube puede tener consecuencias catastróficas.

En la conferencia de RSA este año, mi colega y CTO de McAfee Steve Grobman demostró cómo una característica particular de AWS, Instance Metadata, podría aprovecharse para robar datos confidenciales. Analicemos este escenario para resaltar algunos aprendizajes clave, luego analicemos cómo evitar su propia exposición a un ataque como este.

Ataques de metadatos de instancia

Todos los proveedores de la nube tienen capacidades para administrar credenciales de recursos en sus aplicaciones nativas de la nube. Cuando se usa correctamente, estas capacidades le permiten evitar el almacenamiento de credenciales en claro o en un repositorio de código fuente. En AWS, el Servicio de metadatos de instancias (IMDS) pone a disposición información sobre una instancia de cómputo, su red y almacenamiento para el software que se ejecuta en la instancia. IMDS también pone a disposición credenciales temporales, frecuentemente rotadas, para cualquier rol de IAM asociado a la instancia. Los roles de IAM adjuntos a una instancia pueden, por ejemplo, definir que la instancia y el software que se ejecuta en ella pueden acceder a los datos en los depósitos de almacenamiento S3.

Veamos un escenario común.

Un equipo de epidemiólogos construyó una aplicación nativa de la nube en AWS con un tablero público para representar visualmente los datos que muestran su progreso al analizar un genoma de virus.

Durante la fase de desarrollo de esta aplicación, el equipo se encontró con un desafío. Se suponía que la mayoría de los recursos en su Virtual Private Cloud (VPC) estaban ocultos de Internet. El único recurso en su VPC destinado a la vista pública fue el panel de control.

El cubo S3 que aloja sus datos necesitaba mantenerse privado. Para extraer datos de S3 al tablero público, agregaron un proxy inverso, actuando como intermediario. Todo lo que se necesitó fue una búsqueda rápida en Google y algunas líneas de código para agregar esto a su aplicación.

Para el equipo de epidemiólogos, el proxy inverso era una solución básica y elegante que funcionaba perfectamente para su caso de uso. De lo que no se dieron cuenta es que los preparó para una violación masiva.

A la instancia de cómputo que ejecuta el proxy inverso se le había asignado un rol de IAM con permiso para acceder a su depósito S3 privado. Las credenciales para el proxy inverso para acceder a S3 se obtuvieron de los metadatos de instancia.

Un atacante que visitó el sitio e interesado en sus datos notó que el equipo había hecho referencia a la dirección IP del proxy inverso en el tablero. El atacante luego verificó si podían conectarse a él. Después de confirmar su conectividad, el atacante verificó si podían acceder a los metadatos de la instancia a través del proxy inverso. Éxito.

A través del proxy inverso y de los metadatos de la instancia, el atacante descubrió las credenciales del depósito de almacenamiento S3 privado del equipo.

Ahora, con acceso al bucket S3, el atacante podría robar datos altamente confidenciales que el equipo había almacenado para su aplicación. El atacante simplemente sincronizó el depósito S3 objetivo con su propio depósito S3 en otra cuenta de AWS, y los datos fueron suyos.

Este tipo de ataque es solo una de las 43 técnicas descritas por MITRE en su marco ATT & CK para entornos de nube: https://attack.mitre.org/matrices/enterprise/cloud/

Cómo AWS mitiga los ataques de metadatos de instancia

El servicio de metadatos de instancia (IMDS) AWS simplifica el acceso entre recursos en una aplicación nativa de la nube. Para mejorar la seguridad de este servicio, AWS lanzó IMDSv2, que agrega varias capas nuevas de protección.

En IMDSv2, los usuarios externos no pueden recibir credenciales, lo que permite que solo los reciban los recursos de la aplicación. Lea más sobre esta capa de protección e IMDSv2 aquí: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

En el ataque que acabamos de describir, el proxy inverso estaba mal configurado para permitir que las solicitudes externas lleguen a los recursos internos. Si el equipo hubiera configurado su instancia de cómputo para usar IMDSv2, el acceso no autorizado por parte del actor externo de la amenaza se habría bloqueado.

Cómo puede ayudar MVISION Cloud

En McAfee tenemos varios enfoques que pueden ayudarlo a detectar y prevenir ataques como este. MVISION Cloud es nuestra plataforma de seguridad nativa de la nube que le permite monitorear y actualizar configuraciones en AWS, Azure, GCP junto con un amplia gama de medidas de seguridad adicionales sobre las que puede leer aquí.

Mediante una integración directa de API con AWS, MVISION Cloud supervisa continuamente las métricas de CloudWatch que le indican la versión de IMDS que está utilizando en cada instancia de EC2.

Cuando AWS CloudWatch registra una instancia utilizando IMDSv1 activamente, MVISION Cloud genera un incidente de seguridad, notificándole que actualice su configuración a IMDSv2, lo que evitará el acceso no autorizado a sus credenciales por parte de usuarios externos.

Incidentes de política de MVISION Cloud para la configuración de la versión IMDS

Es una práctica recomendada aplicar IMDSv2 en sus instancias de AWS para todos los códigos y usuarios locales. Una vez que especifique que se debe usar IMDSv2, IMDSv1 ya no funcionará. AWS tiene instrucciones paso a paso sobre cómo configurar sus instancias para usar IMDSv2 aquí.

Más allá de este ejemplo de ataque, MVISION Cloud le permite implementar una serie de mejores prácticas para proteger sus aplicaciones nativas de la nube:

  • Audita continuamente tus configuraciones. Con MVISION Cloud puede escanear plantillas de CloudFormation antes de que entren en producción y luego detectar cualquier "deriva" en sus configuraciones con el tiempo. Esto le permite detectar configuraciones erróneas y aplicar un modelo de privilegios mínimos para permisos de recursos.
  • Hacer cumplir la confianza cero. Utilice la confianza cero como metodología, donde solo los recursos específicos pueden ejecutarse y comunicarse entre sí. Todo lo demás está bloqueado.
  • Escanee en busca de vulnerabilidades de código. Particularmente con los modelos de distribución de software abiertos como Docker, es importante monitorear los recursos de su aplicación para detectar vulnerabilidades de manera continua.
  • Detectar anomalías y amenazas.. Con User and Entity Behavior Analytics (UEBA), puede evaluar millones de eventos en la nube para descubrir actividades anómalas y amenazas reales como el robo de credenciales.
  • Ejecute DLP en objetos de almacenamiento. Al igual que cualquier otro servicio en la nube que sancione, su red o puntos finales, dentro de AWS puede y debe clasificar sus datos dentro de S3 y ejecutar la prevención de pérdida de datos para detener los intentos de exfiltración.

Póngase en contacto con nosotros para hablar sobre la implementación de estas medidas en su propia organización.

Consulte también la nota clave de Steve en RSA para este escenario de ataque en sus propias palabras:





Enlace a la noticia original