22 de marzo de 2022
Por Thyaga Vasudevan - VP de Gestión de Productos, Skyhigh Security
Pasar a una arquitectura nativa en la nube para las aplicaciones de su empresa puede aportar un enorme valor empresarial, ya que añade escala y agilidad al tiempo que descarga de tareas onerosas como la aplicación de parches y la actualización de la infraestructura de servidores.
Sin embargo, en cada entorno de nube, ya sea Amazon Web Services (AWS), Azure o Google Cloud, existe una nueva categoría de riesgo. Las amenazas nativas de la nube se derivan del nuevo contexto y de los requisitos de configuración que se tienen en un entorno de nube. Históricamente, las configuraciones por defecto, como el acceso público a los objetos de almacenamiento, han dejado los datos sensibles a la intemperie, 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 añaden nuevas capacidades. La configuración de su entorno en la nube es siempre su responsabilidad. AWS y otros no tienen ningún control sobre cómo utiliza usted sus servicios. Son una plantilla para que usted construya a partir de ella.
No comprender el resultado de sus configuraciones y cómo construye aplicaciones nativas de la nube puede tener consecuencias catastróficas. E incluso los clientes más avispados de la nube pueden sufrir estas consecuencias.
Un ejemplo es la brecha que sufrió Capital One hace casi tres años, en la que un atacante tuvo acceso a los números de la seguridad social de 100 millones de individuos estadounidenses y a los números de la seguridad social de 6 millones de individuos canadienses. El atacante utilizó varias técnicas para acceder a los datos, pero un aprendizaje clave del ataque fue que una característica de seguridad diseñada para proteger el acceso a máquinas virtuales - instancias de Elastic Compute Cloud o EC - añadió el atacante. La característica se denomina servicio de metadatos de instancias o IMDS.
Ataques a los metadatos de instancia
La versión 1 de IMDS (IMDSv1) se lanzó en 2012 para permitir una forma más segura de que las instancias EC2 interactuaran con otros servicios de AWS. En lugar de dejar las claves de AWS en la instancia, ahora los clientes podían hacer que la instancia EC2 consultara el servicio de metadatos para obtener credenciales y realizar llamadas a la API de AWS a otros servicios de AWS. Por ejemplo, si una instancia EC2 obtenía algunos datos de un cliente, podía utilizar IMDSv1 para almacenar esos datos en un bucket de Amazon Simple Storage Service (S3). Fue exactamente esta capacidad la que utilizó el atacante para extraer información sensible de un bucket S3 utilizado para almacenar información sobre clientes de Capital One.
En nuestras propias pruebas pudimos duplicar cómo podría funcionar esta extracción de datos en cualquier aplicación. En nuestro ejemplo, un equipo de epidemiólogos construyó una aplicación nativa en la nube en AWS con un panel de control público para representar visualmente los datos que mostraban su progreso analizando el genoma de un virus.
Durante la fase de desarrollo de esta aplicación, el equipo se encontró con un reto. Se suponía que la mayoría de los recursos de su Nube Privada Virtual (VPC) debían estar ocultos a Internet. El único recurso de su VPC destinado a la vista pública era el cuadro de mandos.
El bucket de S3 que alojaba sus datos debía permanecer privado. Para extraer datos de S3 al tablero público, añadieron un proxy inverso, que actuaba como intermediario. Todo lo que necesitaron fue una rápida búsqueda en Google, y unas pocas líneas de código para añadir 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 de que les preparaba para una brecha masiva.
A la instancia de cálculo que ejecutaba el proxy inverso se le había asignado un rol IAM con permiso para acceder a su bucket S3 privado. Las credenciales para que el proxy inverso accediera a S3 se obtuvieron de los metadatos de la instancia.
Un atacante que visitaba el sitio y estaba interesado en sus datos se dio cuenta de que el equipo había hecho referencia a la dirección IP del proxy inverso en el panel de control. El atacante comprobó entonces si podía conectarse a él. Tras confirmar su conectividad, el atacante comprobó entonces si podía acceder a los metadatos de 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 cubo de almacenamiento S3 privado del equipo.
Ahora, con acceso al bucket de S3, el atacante podía robar datos altamente sensibles que el equipo había almacenado para su aplicación. El atacante simplemente sincronizó el bucket S3 de destino con su propio bucket S3 en otra cuenta de AWS, y los datos eran suyos.
Este tipo de ataque es sólo 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 mitiga AWS los ataques a los metadatos de las instancias
Para mejorar la seguridad de este servicio, AWS lanzó IMDSv2, que añade varias capas nuevas de protección.
En IMDSv2, se bloquea a los usuarios externos la recepción de credenciales, permitiendo que sólo los recursos de la aplicación las reciban. Lea más sobre esta capa de protección y el IMDSv2 aquí: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
Sin embargo, el desafío sigue siendo que IMDSv1 sigue vivo. No hay nada en AWS que impida a los clientes utilizar IMDSv1, y puede seguir utilizándolo por defecto para todas sus instancias EC2. Como hemos mencionado antes, no es responsabilidad de AWS asegurarse de que está utilizando la nube de forma segura. Esa responsabilidad recae únicamente en el cliente.
En el ataque que acabamos de describir, el proxy inverso estaba mal configurado para permitir que las solicitudes externas llegaran a los recursos internos. Si el equipo hubiera configurado su instancia de computación para utilizar IMDSv2, se habría bloqueado el acceso no autorizado del actor externo de la amenaza.
Cómo puede ayudar la protección de aplicaciones nativas en la nube de Skyhigh
En Skyhigh Security, tenemos varios enfoques que pueden ayudarle a detectar y prevenir ataques como este. Skyhigh Cloud Native Application Protection Platform (CNAPP) es nuestra plataforma de seguridad nativa de la nube que le permite monitorizar y actualizar configuraciones en AWS, Azure, GCP junto con una amplia gama de medidas de seguridad adicionales sobre las que puede leer aquí.
Mediante una integración directa de API con AWS, Skyhigh CNAPP monitoriza continuamente Amazon CloudWatch -un servicio de monitorización de aplicaciones e infraestructuras- para indicar qué versión de IMDS está utilizando en cada instancia EC2.
Cuando CloudWatch registra una instancia que utiliza activamente IMDSv1, Skyhigh CNAPP genera un incidente de seguridad, notificándole que actualice su configuración a IMDSv2, lo que impedirá el acceso no autorizado a sus credenciales por parte de usuarios externos.
Incidentes en la política de Skyhigh CNAPP para la configuración de la versión de IMDS
Es la mejor práctica para hacer cumplir IMDSv2 en sus instancias EC2 para todo el código local y los usuarios. Una vez que especifique que debe utilizarse IMDSv2, IMDSv1 dejará de funcionar. AWS tiene instrucciones paso a paso sobre cómo configurar sus instancias para utilizar IMDSv2 aquí.
Más allá de este ejemplo de ataque, Skyhigh CNAPP le permite aplicar una serie de buenas prácticas para proteger sus aplicaciones nativas de la nube:
- Audite continuamente sus configuraciones. Con Skyhigh CNAPP puede escanear las plantillas de AWS CloudFormation antes de que entren en producción y, a continuación, detectar cualquier "deriva" en sus configuraciones a lo largo del tiempo. Esto le permite detectar configuraciones erróneas e imponer un modelo de mínimos privilegios para el permiso de recursos.
- Imponga la confianza cero. Utilice la confianza cero como metodología, en la que sólo se permite que determinados recursos se ejecuten y se comuniquen entre sí. Todo lo demás se bloquea.
- Escanee en busca de vulnerabilidades de código. Especialmente con modelos de distribución de software abierto como Docker, es importante supervisar los recursos de su aplicación en busca de vulnerabilidades de forma continua.
- Detecte anomalías y amenazas. Con el análisis del comportamiento de usuarios y entidades (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 los 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 data loss prevention para detener los intentos de exfiltración.
Póngase en contacto con nosotros para hablar sobre la aplicación de estas medidas en su propia organización.
Volver a Blogs