¿Hasta qué punto es seguro un entorno en la nube conforme con CIS/AWS?

Blogpost 29 abril 2021 por Roy Stultiens, analista de seguridad de Bureau Veritas Cybersecurity

En Bureau Veritas Cybersecurity vemos que los clientes desean cumplir las normas del sector o las líneas de base de seguridad para asegurarse de que su entorno de nube está debidamente protegido. En los entornos de nube, una de las líneas de base comunes es la del CIS (Centro para la Seguridad en Internet [1]). Estas líneas de base aportan valor y seguridad básica a un entorno, sin embargo, en realidad aún podría estar en riesgo de sufrir un ataque, como muestra nuestra investigación.

Uno de nuestros analistas de seguridad ha llevado a cabo una investigación para averiguar cómo de seguro es un entorno en la nube de AWS totalmente conforme con CIS y si eso protegería contra las vulnerabilidades y las configuraciones erróneas más comunes. Los resultados son que con tres líneas de base de uso común todavía se pueden llevar a cabo 4 de cada 6 ataques habituales. En este artículo compartimos los detalles de esta investigación y proporcionamos consejos sobre errores de configuración o fallos de seguridad comunes para ayudarle a proteger su nube.

Cloud compliance image 1

Puntos de referencia/bases de referencia de seguridad de uso común

En primer lugar, se recopilaron los marcos de seguridad de AWS más populares, utilizados habitualmente por nuestros clientes y por nuestra experiencia en evaluaciones de nubes. Para AWS, se identificaron tres marcos de seguridad, a saber

  • CIS Amazon Web Services Foundations benchmark v1.2 (2018) [2]
    Este punto de referencia es, con diferencia, el más popular y ofrece 49 recomendaciones de seguridad sobre IAM, registro, monitorización y redes. La recomendación es de nivel 1 o de nivel 2, donde el nivel 2 son medidas de defensa en profundidad que podrían afectar al rendimiento de un servicio. Las recomendaciones son genéricas y pueden aplicarse en todos los entornos de AWS.
  • CIS AWS Three-tier Web Architecture benchmark v1.0 (2016) [3]
    El benchmark Three-tier consta de 96 recomendaciones, especificadas para servicios concretos, como EC2 (Elastic Computing) y bases de datos. El documento está orientado al uso de la arquitectura de tres niveles. Para implementar este benchmark en otras arquitecturas se requieren conocimientos profundos por parte del usuario.
  • Norma AWS Foundational Security Best Practices [4]
    Este estándar ha sido publicado por AWS y está en constante desarrollo. En el momento de redactar este documento cuenta con 70 recomendaciones de seguridad, mientras que durante la investigación constaba de 31 reglas. Todas las reglas son específicas del servicio y están totalmente integradas con el AWS Security Hub.
Adobe Stock 280704717

Errores de configuración y/o vulnerabilidades comunes en la nube/AWS

Aunque Bureau Veritas Cybersecurity utiliza puntos de referencia y líneas de base de seguridad en sus evaluaciones de la nube, nuestros expertos tienden a adoptar un enfoque holístico en lugar de comprobar únicamente estas líneas de base. En las evaluaciones de la nube realizadas en la vida real, se encontraron muchas configuraciones erróneas y vulnerabilidades diferentes. Una selección de las más comunes son

  1. Falsificación de solicitud del lado del servidor (SSRF) en EC2 [5]
    En este escenario, se lanza una instancia de computación de AWS (EC2) con permisos para leer los buckets de S3. Sin embargo, el servicio web que se ejecuta en la instancia contiene una vulnerabilidad que permite a un atacante dejar que el servidor ejecute peticiones en su nombre. Un atacante puede abusar de esto para consultar el servicio de metadatos de instancia de AWS y extraer las credenciales que la máquina utiliza para acceder a los buckets de S3. Encontrará más detalles en este vídeo.
  2. Secretos almacenados en datos de usuario en instancias EC2 [6]
    Los datos de usuario en las instancias EC2 se utilizan a menudo para los scripts de configuración del primer arranque. Puede resultar tentador almacenar secretos como la API o las claves de acceso en los datos de usuario, de forma que puedan transferirse a la máquina durante la instalación. Sin embargo, estos datos no están cifrados y pueden extraerse mediante el servicio de metadatos de instancia o utilizando la consola de AWS. Almacenar secretos en los datos de usuario no es sólo un riesgo para los atacantes externos, también los internos podrían extraer información valiosa. Encontrará más detalles en este vídeo.
  3. Instantáneas públicas de volúmenes EBS [7]
    Los volúmenes Elastic Block Store (EBS) son los discos duros de las instancias EC2. Utilizar instantáneas para poder devolver la máquina a un estado anterior es una práctica común y buena. AWS permite a los usuarios compartir sus instantáneas, ya sea con una cuenta específica de AWS o con todas las cuentas (públicas). Las instantáneas públicas pueden ser clonadas por cualquiera, los datos que residen en la instantánea no están seguros y pueden ser fácilmente extraídos y escaneados en busca de cualquier secreto. Consulte la investigación de Bishopfox.
  4. Permisos públicos de lectura/escritura en cubos S3
    Quizá la causa más conocida de filtraciones de datos sean los buckets S3 mal configurados. Estos cubos permiten un almacenamiento casi ilimitado y pueden configurarse para permitir el acceso público. Si se realiza esta configuración, basta con tener el nombre del bucket para extraer todos los datos.
  5. Vulnerabilidades de inyección de código en funciones Lambda [8]
    Pueden utilizarse para todo tipo de tareas, como el etiquetado de objetos, el procesamiento de imágenes y las notificaciones. Para realizar con éxito estas tareas, las funciones suelen recibir permisos a través de roles IAM en otros servicios de AWS, como S3 o EC2. Cuando se dispara el evento, la función Lambda se dispara y ejecuta el código programado. Si este código contiene una vulnerabilidad de inyección, un atacante podría ser capaz de extraer las variables del sistema de la función. Esto incluye las credenciales de AWS que se utilizan para acceder a otros servicios de AWS. Encontrará más detalles en este vídeo.
  6. Secretos almacenados en variables de entorno en funciones Lambda
    Las funciones Lambda son servicios de computación sin servidor que monitorizan el entorno. Al crear una función Lambda, es posible asignar variables de entorno, que pueden ser utilizadas por el código dentro de la función. A menudo estas variables incluyen secretos, como claves API o incluso credenciales de acceso. Las variables de entorno pueden ser extraídas por un atacante si existe una vulnerabilidad de inyección de código en el código. Además, los atacantes internos pueden leer las variables de entorno configuradas en texto plano.
Adobe Stock 221015223

Un entorno conforme vulnerable

Para probar si los entornos en la nube que cumplen las normas reales corren el riesgo de sufrir los ataques mencionados, creamos un entorno de prueba de AWS. Todas estas vulnerabilidades se desarrollaron en escenarios desplegables con el uso de Terraform. Terraform es una herramienta de software infra-as-code, que permite a los usuarios definir el código de la infraestructura. Esto garantiza que cada vez que se despliegan los escenarios, son exactamente iguales y no requieren configuraciones manuales.

El entorno de pruebas de AWS se configuró para que cumpliera los diferentes puntos de referencia y normas de seguridad. A continuación, se desplegaron los recursos utilizando Terraform. Tras el despliegue, se escaneó el entorno para garantizar que seguía cumpliendo las normas de seguridad.

Resultados

Cada ataque se ejecutó en el entorno de prueba. Los resultados pueden consultarse en la tabla siguiente, donde X indica no protegido y en caso contrario se muestra el control correspondiente:

Table cloud compliance blog

Los resultados indican que la referencia de seguridad más común, la referencia CIS AWS Foundations, ¡no protege contra ninguno de los ataques implementados! El marco de trabajo proporciona un entorno más seguro, pero carece de defensas en profundidad para servicios de AWS populares y de uso común como EC2, S3 y Lambda.

El marco de trabajo de tres niveles evita tener instantáneas públicas de EBS debido a los controles 1.5 y 1.6., pero otros ataques o configuraciones erróneas siguen siendo posibles. Los controles 1.5 y 1.6 garantizan que los volúmenes de EBS estén cifrados. Esto impide que las instantáneas se compartan públicamente, ya que la clave de descifrado no es de acceso público. Este marco se ve con menos frecuencia, ya que es más difícil de aplicar a arquitecturas de nube genéricas.

El estándar AWS Foundational Security Best Practices proporciona una mejor protección, especialmente contra los buckets S3 expuestos públicamente. Los controles S3.1 - S3.3 controlan explícitamente que los cubos no puedan leerse ni escribirse públicamente. Esto evita la razón número uno de las filtraciones de datos relacionadas con la nube. También el control EC2.1 impide las instantáneas EBS, sin embargo, ¡incluso con esta línea de base implementada el entorno sigue siendo susceptible para 4 de los 6 ataques!

Adobe Stock 167813129

Conclusión

Esta investigación da una pista de por qué vemos con frecuencia que los ataques mencionados tienen éxito durante nuestras investigaciones sobre la nube en los clientes. Cumplir con uno o más marcos de seguridad en la nube ayuda a tener un entorno seguro, pero no es suficiente. Nuestra investigación identificó varios ataques comunes y los comparó con las líneas de base de seguridad conocidas para entornos AWS. Los resultados muestran que los marcos de seguridad existentes no ofrecen una protección adecuada contra estos ataques comunes. Ser conforme no basta para tener un entorno seguro: es necesario realizar comprobaciones adicionales.

Esto no significa que los marcos investigados no deban utilizarse o que ofrezcan recomendaciones erróneas. Al contrario, estos marcos proporcionan un nivel base de seguridad necesario antes de aplicar medidas más profundas. Para nuestros expertos, las líneas de base proporcionan una buena comprobación de la fruta que cuelga baja, mientras que su creatividad pone a prueba su defensa en profundidad. Le sugerimos que eche un vistazo a su entorno de nube más allá de estas líneas de base para asegurarse de que está a salvo de estos ataques comunes.

Acerca de Secura

Escrito por Roy Stultiens. Roy es uno de los expertos en nube de Bureau Veritas Cybersecurity. Con una gran pasión por la seguridad en la nube, es un miembro activo en el grupo de conocimiento de la nube. Junto con este grupo realiza regularmente pentests de nube y comparte experiencias con colegas y clientes en este campo de rápido desarrollo.

Notas a pie de página:

[1] Centro para la Seguridad en Internet: https://www.cisecurity.org
[2] Libro blanco sobre los fundamentos de Amazon Web Services del CIS: https://d0.awsstatic.com/white...
[3] Documento técnico sobrela web de tres niveles de Amazon Web Services del CIS: https://d0.awsstatic.com/white...
[4] AWS Foundational Security Best Practices estándar: https://docs.aws.amazon.com/se...
[5] Falsificación de solicitudes del lado del servidor (SSRF) en EC2: https: //youtu.be/6U-DpyEoVRs
[6] Secretos almacenados en datos de usuario en instancias EC2: https: //youtu.be/-p5yCrrsTFA
[7] Dufflebag: Descubriendo secretos en volúmenes EBS expuestos: https: //labs.bishopfox.com/tec...
[8] Vulnerabilidades de inyección de código en funciones Lambda: https: //youtu.be/gl2hEmN67ms