Auditoría de seguridad de la plataforma en la nube MCS

SkyShip Dusk por SeerLight

La construcción de cualquier servicio incluye necesariamente un trabajo constante en seguridad. La seguridad es un proceso continuo que incluye el análisis continuo y la mejora de la seguridad del producto, el monitoreo de noticias sobre vulnerabilidades y mucho más. Incluyendo - auditorías. Las auditorías se llevan a cabo tanto por cuenta propia como por expertos externos que pueden ayudar dramáticamente con la seguridad, ya que no están inmersos en el proyecto y tienen una visión clara.

El artículo trata sobre este aspecto muy impopular de expertos externos que ayudaron al equipo de Mail.ru Cloud Solutions (MCS) a probar el servicio en la nube, y sobre lo que encontraron. Como "fuerzas externas", MCS eligió Digital Security, conocida por su alta experiencia en la comunidad de seguridad. Y en este artículo analizaremos algunas vulnerabilidades interesantes que se encontraron como parte de una auditoría externa, para que obtenga el mismo rastrillo cuando realice su servicio en la nube.

Descripción del producto

Mail.ru Cloud Solutions (MCS) es una plataforma para construir infraestructura virtual en la nube. Incluye IaaSs, PaaSs, un mercado de imágenes de aplicaciones listas para usar para desarrolladores. Teniendo en cuenta la arquitectura de MCS, fue necesario verificar la seguridad del producto en las siguientes áreas:

• protección de la infraestructura del entorno de virtualización: hipervisores, enrutamiento, firewalls;
  
• protección de la infraestructura virtual de los clientes: aislamiento entre sí, incluida la red, redes privadas en SDN;
  
• OpenStack y sus componentes abiertos;
  
• S3 desarrollo propio;
  
• IAM: proyectos multiinquilinos con un modelo a seguir;
  
• Visión (visión artificial): API y vulnerabilidades al trabajar con imágenes;
  
• interfaz web y ataques web clásicos;
  
• vulnerabilidades de los componentes de PaaS;
  
• API de todos los componentes.
  

Quizás, todo lo que es esencial para la historia posterior lo es todo.

¿Qué tipo de trabajo se realizó y por qué se necesitan?

Una auditoría de seguridad tiene como objetivo identificar vulnerabilidades y errores de configuración que pueden conducir a la fuga de datos personales, la modificación de información confidencial o una violación de la disponibilidad de servicios.

Durante el trabajo, que dura 1-2 meses en promedio, los auditores repiten las acciones de los posibles atacantes y buscan vulnerabilidades en las partes cliente y servidor del servicio seleccionado. En el contexto de la auditoría de la plataforma en la nube MCS, se identificaron los siguientes objetivos:

1. Análisis de autenticación en el servicio. Las vulnerabilidades en este componente ayudarían a ingresar de inmediato en las cuentas de otras personas.
   
2. El estudio del modelo a seguir y el control de acceso entre diferentes cuentas. Para un atacante, la capacidad de acceder a la máquina virtual de otra persona es un objetivo bienvenido.
   
3. Vulnerabilidades del lado del cliente. XSS / CSRF / CRLF / etc. ¿Quizás es posible atacar a otros usuarios a través de enlaces maliciosos?
   
4. Vulnerabilidades en el lado del servidor: RCE y todo tipo de inyecciones (SQL / XXE / SSRF, etc.). Las vulnerabilidades del servidor suelen ser más difíciles de encontrar, pero conducen al compromiso de muchos usuarios a la vez.
   
5. Análisis de aislamiento de segmentos de red de segmentos de usuarios. Para un atacante, la falta de aislamiento aumenta significativamente la superficie de ataque de otros usuarios.
   
6. Análisis de lógica de negocios. ¿Es posible engañar a un negocio y crear máquinas virtuales de forma gratuita?
   

En este proyecto, el trabajo se realizó de acuerdo con el modelo Gray-box: los auditores interactuaron con el servicio con los privilegios de los usuarios comunes, pero poseían parcialmente el código fuente de la API y tuvieron la oportunidad de aclarar detalles con los desarrolladores. Por lo general, este es el modelo de trabajo más conveniente y, al mismo tiempo, bastante realista: un atacante puede recopilar información privilegiada, esto es solo cuestión de tiempo.

Vulnerabilidades encontradas

Antes de que el auditor comience a enviar varias cargas útiles (carga útil, que se usa para atacar) a lugares aleatorios, debe comprender cómo funciona, qué funcionalidad se presenta. Puede parecer que este es un ejercicio inútil, porque en la mayoría de los lugares estudiados no habrá vulnerabilidades. Pero solo una comprensión de la estructura de la aplicación y la lógica de su funcionamiento permitirá encontrar los vectores de ataque más complejos.

Es importante encontrar lugares que parezcan sospechosos o algo muy diferente de los demás. Y la primera vulnerabilidad peligrosa se encontró de esta manera.

IDOR

Las vulnerabilidades de IDOR (Referencia directa insegura de objetos, enlaces directos inseguros a objetos) son una de las vulnerabilidades más comunes en la lógica empresarial que permite que de una forma u otra accedan a objetos a los que el acceso no está permitido. Las vulnerabilidades de IDOR crean la posibilidad de obtener información del usuario de diversos grados de criticidad.

Una de las opciones de IDOR es realizar acciones con objetos del sistema (usuarios, cuentas bancarias, bienes en la cesta) manipulando identificadores de acceso para estos objetos. Esto lleva a las consecuencias más impredecibles. Por ejemplo, la posibilidad de sustitución de la cuenta del remitente, por lo que puede robarlos de otros usuarios.

En el caso de MCS, los auditores acaban de descubrir la vulnerabilidad IDOR asociada con identificadores que no son del sistema. En la cuenta personal del usuario, para acceder a cualquier objeto, se usaron UUID, que parecían, como dicen los hombres de seguridad, impresionantemente no brutos (es decir, protegidos del ataque de fuerza bruta). Pero para ciertas entidades, se descubrió que se utilizan números predecibles ordinarios para obtener información sobre los usuarios de la aplicación. Creo que se da cuenta de que puede cambiar la ID de usuario por uno, enviar la solicitud nuevamente y, por lo tanto, obtener información sin pasar por la ACL (lista de control de acceso, reglas de acceso a datos para procesos y usuarios).

Falsificación de solicitudes del lado del servidor (SSRF)

Los productos OpenSource son buenos porque tienen una gran cantidad de foros con una descripción técnica detallada de los problemas que surgen y, si tiene suerte, con una descripción de la solución. Pero esta moneda tiene otro lado: también se detallan vulnerabilidades conocidas. Por ejemplo, el foro OpenStack tiene descripciones maravillosas de las vulnerabilidades [XSS] y [SSRF] , que por alguna razón nadie tiene prisa por arreglar.

La funcionalidad frecuente de la aplicación es la capacidad para que el usuario envíe un enlace al servidor en el que el servidor hace clic (por ejemplo, para descargar una imagen de una fuente específica). Con un filtrado de seguridad insuficiente de los enlaces o las respuestas que el servidor devuelve a los usuarios, los atacantes utilizan fácilmente dicha funcionalidad.

Las vulnerabilidades SSRF pueden avanzar mucho en el desarrollo de ataques. Un atacante puede obtener:

• acceso limitado a la red local atacada, por ejemplo, solo en ciertos segmentos de red y en cierto protocolo;
  
• acceso completo a la red local, si es posible una degradación desde el nivel de aplicación al nivel de transporte y, como resultado, la gestión de carga completa a nivel de aplicación;
  
• acceso a la lectura de archivos locales en el servidor (si el archivo: /// esquema es compatible);
  
• y mucho mas
  

OpenStack es conocido desde hace mucho tiempo por su vulnerabilidad SSRF "ciega": cuando accede al servidor no obtiene una respuesta, pero obtiene diferentes tipos de errores / retrasos, según el resultado de la solicitud. En base a esto, puede escanear puertos en hosts en la red interna, con todas las consecuencias resultantes, que no deben subestimarse. Por ejemplo, un producto puede tener una API para back office, disponible solo desde la red corporativa. Al poseer documentación (no se olvide de los iniciados), un atacante puede utilizar métodos internos utilizando SSRF. Por ejemplo, si logró obtener de alguna manera una lista aproximada de URL útiles, entonces, utilizando SSRF, puede revisarlas y ejecutar una solicitud, en términos relativos, transferir dinero de una cuenta a otra o cambiar los límites.

Este no es el primer caso de detección de vulnerabilidades SSRF en OpenStack. En el pasado, era posible descargar imágenes ISO VM a través de un enlace directo, lo que también tenía consecuencias similares. Esta característica se elimina actualmente de OpenStack. Aparentemente, la comunidad consideró que esta es la solución más fácil y confiable para el problema.

Y en este informe disponible públicamente del servicio HackerOne (h1), la explotación de un SSRF no ciego con la capacidad de leer metadatos de instancia conduce al acceso Root a toda la infraestructura de Shopify.

En MCS, en dos lugares con una funcionalidad similar, se descubrieron vulnerabilidades SSRF, pero eran casi imposibles de explotar debido a los firewalls y otras protecciones. De una forma u otra, el equipo de MCS solucionó este problema de todos modos, sin esperar a la comunidad.

XSS en lugar de cargar proyectiles

A pesar de cientos de estudios escritos, de año en año XSS (ataque de secuencias de comandos entre sitios) sigue siendo la vulnerabilidad web más común (¿o ataque ?).

La descarga de archivos es un lugar favorito para cualquier investigador de seguridad. A menudo resulta que puede cargar una secuencia de comandos arbitraria (asp / jsp / php) y ejecutar comandos del sistema operativo, en la terminología de los pentesters: "shell de carga". Pero la popularidad de tales vulnerabilidades funciona en ambas direcciones: son herramientas recordadas y desarrolladas contra ellas, por lo que recientemente la probabilidad de "cargar el shell" ha estado tendiendo a cero.

El equipo atacante (representado por Digital Security) tuvo suerte. OK, en MCS, en el lado del servidor, se verificó el contenido de los archivos descargados, solo se permitieron imágenes. Pero SVG también es una imagen. ¿Y qué pueden ser imágenes SVG peligrosas? ¡Porque puedes incrustar fragmentos de JavaScript en ellos!

Resultó que los archivos descargados están disponibles para todos los usuarios del servicio MCS, lo que significa que puede atacar a otros usuarios de la nube, a saber, los administradores.


Un ejemplo de uso de un formulario de inicio de sesión de phishing mediante un ataque XSS

Ejemplos de explotación de un ataque XSS:

• ¿Por qué intentar robar una sesión (especialmente porque ahora todas las cookies HTTP-Only están protegidas contra el robo usando scripts js) si el script descargado puede acceder de inmediato a la API de recursos? En este caso, la carga útil puede cambiar la configuración del servidor a través de solicitudes XHR, por ejemplo, agregar la clave SSH pública del atacante y obtener acceso SSH al servidor.
  
• Si la política CSP (política de protección de contenido) prohíbe la implementación de JavaScript, un atacante podría prescindir de ella. En HTML puro, cree el formulario de inicio de sesión falso del sitio y robe la contraseña del administrador a través de un phishing tan avanzado: la página de phishing para el usuario se encuentra en la misma URL, y es más difícil para el usuario detectarla.
  
• Finalmente, un atacante puede organizar un DoS del cliente : establecer cookies de más de 4 KB. Es suficiente para que el usuario abra el enlace una vez y todo el sitio quede inaccesible hasta que adivine especialmente para limpiar el navegador: en la gran mayoría de los casos, el servidor web se negará a aceptar dicho cliente.
  

Veamos un ejemplo de otro XSS revelado, esta vez con una operación más complicada. El servicio MCS le permite combinar la configuración del firewall en grupos. XSS fue descubierto en el nombre del grupo. Su peculiaridad era que el vector no funcionaba de inmediato, no cuando se visualizaba la lista de reglas, sino cuando se borraba el grupo:



Es decir, el escenario era el siguiente: un atacante crea una regla de firewall con una "carga" en el nombre, el administrador lo nota después de un tiempo e inicia el proceso de eliminación. Y aquí también cumple el JS malicioso.

Para los desarrolladores de MCS, para protegerse contra XSS en imágenes SVG descargables (si no pueden abandonarse), el equipo de Seguridad Digital recomendó:

• Aloje los archivos cargados por los usuarios en un dominio separado que no tiene nada que ver con "cookie". El script se ejecutará en el contexto de otro dominio y no representará una amenaza para MCS.
  
• En la respuesta HTTP del servidor, escriba el encabezado "Disposición de contenido: archivo adjunto". Luego, el navegador descargará los archivos y no los ejecutará.
  

Además, ahora hay muchas formas disponibles para que los desarrolladores mitiguen los riesgos de operar XSS:

• utilizando el indicador "Solo HTTP", puede hacer que los encabezados de sesión de las cookies sean inaccesibles para JavaScript malicioso;
  
• una política CSP implementada correctamente complicará significativamente la operación de XSS para un atacante;
  
• Los motores de plantillas modernos, como Angular o React, borran automáticamente los datos del usuario antes de mostrarlos en el navegador del usuario.
  

Vulnerabilidades de autenticación de dos factores

Para aumentar la seguridad de la cuenta, siempre se recomienda a los usuarios que habiliten 2FA (autenticación de dos factores). De hecho, esta es una forma efectiva de evitar que un atacante obtenga acceso al servicio si las credenciales del usuario se han visto comprometidas.

Pero, ¿el uso del segundo factor de autenticación siempre garantiza la seguridad de la cuenta? En una implementación de 2FA, existen tales problemas de seguridad:

• Búsqueda aproximada de código OTP (códigos únicos). A pesar de la simplicidad de la operación, las grandes compañías también encuentran errores como la falta de protección contra el bruto OTP: el caso de Slack , el caso de Facebook .
  
• Algoritmo de generación débil, por ejemplo, la capacidad de predecir el siguiente código.
  
• Errores lógicos, por ejemplo, la capacidad de solicitar el OTP de otra persona en su teléfono, como ocurrió con Shopify.
  

En el caso de MCS, 2FA se implementa en base a Google Authenticator y Duo . El protocolo en sí ya ha sido probado por el tiempo, pero vale la pena verificar la implementación de la verificación del código en el lado de la aplicación.

El MCS 2FA se usa en varios lugares:

• En la autenticación del usuario. Aquí hay protección contra la fuerza bruta: el usuario solo tiene unos pocos intentos para ingresar una contraseña de un solo uso, luego la entrada se bloquea por un tiempo. Esto bloquea la capacidad de realizar la eliminación de OTP.
  
• Al generar códigos de copia de seguridad fuera de línea para ejecutar 2FA, así como desactivarlo. Aquí, la protección contra la fuerza bruta no se implementó, lo que permitió regenerar los códigos de respaldo o desactivar 2FA por completo si había una contraseña para la cuenta y una sesión activa.
  

Teniendo en cuenta que los códigos de respaldo se ubicaron en el mismo rango de valores de línea que los generados por la aplicación OTP, la posibilidad de recoger el código en poco tiempo fue mucho mayor.


El proceso de seleccionar OTP para deshabilitar 2FA usando la herramienta Burp: Intruder

Resultado

En general, MCS como producto resultó ser seguro. Durante la auditoría, el equipo de Pentester no pudo acceder a las máquinas virtuales del cliente y sus datos, y las vulnerabilidades encontradas fueron reparadas rápidamente por el equipo de MCS.

Pero aquí es importante tener en cuenta que la seguridad es un trabajo continuo. Los servicios no son estáticos, están en constante evolución. Y desarrollar un producto completamente sin vulnerabilidades es imposible. Pero puede encontrarlos a tiempo y minimizar la posibilidad de que se repitan.

Ahora todas las vulnerabilidades mencionadas en MCS ya están reparadas. Y para minimizar el número de nuevos y acortar su vida útil, el equipo de la plataforma continúa haciendo esto:

• realizar auditorías periódicas por empresas externas;
  
• para apoyar y desarrollar la participación en el programa Bug Bounty-Group Mail.ru ;
  
• hacer seguridad :)