Cómo la nube de una startup fue comprometida por un simple formulario de envío de correos electrónicos

Prevención de la toma de control total de la nube mediante ataques SSRF

Esta es la historia de un atacante que obtuvo acceso a los buckets de Amazon S3, variables de entorno y varios secretos internos de API de una startup, todo ello a través de un simple formulario que envía un correo electrónico. Aunque esta es una historia real, mantendré en secreto el nombre de la startup.

Cómo accedieron

Todo comienza con una aplicación PHP que envía un correo electrónico. Para cargar algunas de las imágenes sofisticadas al correo electrónico como archivos adjuntos, la aplicación necesita descargarlas. En PHP esto es fácil. Se utiliza la función file_get_contents y ahí es donde empieza el problema.

Por supuesto, parte de la entrada del usuario para este correo electrónico no fue completamente verificada o codificada en HTML, y, por lo tanto, un usuario podría incluir una imagen como <img src=’evil.com’/>.  Ahora, en teoría, esto no es tan grave, pero lamentablemente esta función de PHP es muy potente y puede hacer mucho más que cargar imágenes a través de internet. También puede leer archivos locales y, lo que es más importante: archivos a través de la red local en lugar de internet.

En lugar de evil.com, el atacante introdujo una URL local especial.  Se puede usar esta URL para obtener las credenciales IAM vinculadas al rol del servidor AWS EC2 que se está ejecutando con una simple solicitud GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

El resultado fue que el atacante recibió un correo electrónico que incluía las credenciales IAM del servidor EC2 en un archivo adjunto en el buzón. Esas claves otorgan al atacante la capacidad de suplantar la identidad de ese servidor al comunicarse con varios servicios de AWS. A partir de ahí, todo empeora...

¿Por qué es esto posible en primer lugar?

El sistema que carga estas claves IAM se llama IMDSv1 y Amazon lanzó una nueva versión en 2019 llamada IMDSv2. Con IMDSv2, es necesario enviar una solicitud PUT con una cabecera especial para obtener las credenciales IAM. Esto significa que una función simple de carga de URL basada en GET como file_get_contents ya no puede causar tanto daño.

No está claro cuál es la adopción de IMDSv2 a partir de 2023, pero está claro que Amazon sigue tomando medidas para aumentar su adopción y estamos viendo que IMDSv1 todavía se utiliza en entornos reales.

El compromiso de las claves IAM conduce a compromisos adicionales: los buckets S3 podrían listarse y su contenido leerse. Para empeorar las cosas, uno de los buckets S3 contenía una plantilla de CloudFormation, que a su vez contenía variables de entorno sensibles (por ejemplo, claves API de Sendgrid).

¿Cómo defiendo mi infraestructura cloud contra esto?

Ahora bien, ¿qué se podría hacer para evitar esta pérdida total de datos? Tus desarrolladores podrían ser extremadamente cuidadosos y asegurarse de usar una lista de permitidos (allowlist) para las URL que pasan a file_get_contents. Incluso podrían verificar que el contenido que reciben es una imagen si esperan una imagen. Sin embargo, la realidad es que este tipo de errores son difíciles de evitar para un desarrollador.

Sería mucho mejor asegurar que su infraestructura cuenta con defensas adicionales contra estos ataques. Nuestra nueva integración con AWS dentro de Aikido Security le alertará si su nube no toma activamente ninguna de las siguientes medidas. Cada una de estas medidas por sí sola habría detenido este ataque en particular, pero recomendamos implementarlas todas. Utilice nuestra cuenta de prueba gratuita para ver si su nube ya está defendida contra estas amenazas. Vea cómo Aikido protege su aplicación contra vulnerabilidades aquí.

Pasos a seguir:

1. Migra tus nodos EC2 IMDSv1 existentes para usar IMDSv2
2. No almacenes ningún secreto en el entorno de tus servidores web ni en plantillas de CloudFormation. Utiliza una herramienta como AWS Secrets Manager para cargar los secretos en tiempo de ejecución.
3. Al asignar roles IAM a tus servidores EC2, asegúrate de que tengan condiciones adicionales, como restringir su uso únicamente desde tu red AWS local (tu VPC). El ejemplo siguiente permite a tu servidor leer de S3, pero solo si el servidor EC2 se comunica a través de un endpoint de VPC específico. Esto solo es posible desde tu red, por lo que el atacante no habría podido acceder a los buckets S3 desde su máquina local.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

Acerca de «The Kill Chain»

The Kill Chain es una serie de historias reales de atacantes que acceden a los activos más valiosos de empresas de software encadenando múltiples vulnerabilidades. Escrito por Willem Delbare, aprovechando sus diez años de experiencia en la creación y soporte de startups SaaS como CTO. Las historias provienen directamente de la red de Willem y todas ocurrieron realmente.