por SeerLight
La construcción de cualquier servicio incluye necesariamente un trabajo constante en materia de seguridad. La seguridad es un proceso continuo que incluye análisis y mejora constante de la seguridad del producto, seguimiento de noticias sobre vulnerabilidades y mucho más. Incluyendo auditorías. Las auditorías se llevan a cabo tanto internamente como por expertos externos, que pueden ayudar radicalmente con la seguridad porque no están inmersos en el proyecto y tienen la mente abierta.
El artículo trata sobre esta visión más sencilla de los 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 “fuerza externa”, MCS eligió a la empresa Digital Security, conocida por su gran experiencia en el ámbito de la seguridad de la información. Y en este artículo analizaremos algunas vulnerabilidades interesantes encontradas como parte de una auditoría externa, para que usted evite el mismo comisión al crear su propio servicio en la nube.
Описание продукта
es una plataforma para construir infraestructura virtual en la nube. Incluye IaaS, PaaS y un mercado de imágenes de aplicaciones listas para usar para desarrolladores. Teniendo en cuenta la arquitectura MCS, fue necesario comprobar la seguridad del producto en las siguientes áreas:
- proteger 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, las redes privadas en SDN;
- OpenStack y sus componentes abiertos;
- S3 de diseño propio;
- IAM: proyectos multiinquilino con un modelo a seguir;
- Visión (visión por computadora): 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 eso sea todo lo que sea esencial para seguir con la historia.
¿Qué tipo de trabajo se llevó a cabo y por qué era necesario?
Una auditoría de seguridad tiene como objetivo identificar vulnerabilidades y errores de configuración que podrían provocar la fuga de datos personales, la modificación de información sensible o la interrupción de la disponibilidad del servicio.
Durante el trabajo, que dura en promedio entre 1 y 2 meses, los auditores repiten las acciones de 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 de MCS, se identificaron los siguientes objetivos:
- Análisis de autenticación en el servicio. Las vulnerabilidades en este componente ayudarían a acceder inmediatamente a las cuentas de otras personas.
- Estudiar el modelo a seguir y el control de acceso entre diferentes cuentas. Para un atacante, la capacidad de obtener acceso a la máquina virtual de otra persona es un objetivo deseable.
- Vulnerabilidades del lado del cliente. XSS/CSRF/CRLF/etc. ¿Es posible atacar a otros usuarios mediante enlaces maliciosos?
- Vulnerabilidades del lado del servidor: RCE y todo tipo de inyecciones (SQL/XXE/SSRF, etc.). Las vulnerabilidades del servidor son generalmente más difíciles de encontrar, pero comprometen a muchos usuarios a la vez.
- Análisis del aislamiento del segmento de usuarios a nivel de red. Para un atacante, la falta de aislamiento aumenta considerablemente la superficie de ataque contra otros usuarios.
- Análisis de lógica de negocios. ¿Es posible engañar a las empresas y crear máquinas virtuales gratis?
En este proyecto, el trabajo se llevó a cabo según 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. Este suele ser el modelo de trabajo más conveniente y, al mismo tiempo, bastante realista: un atacante aún puede recopilar información interna, es solo cuestión de tiempo.
Vulnerabilidades encontradas
Antes de que el auditor comience a enviar varias cargas útiles (la carga útil utilizada para llevar a cabo el ataque) a lugares aleatorios, es necesario comprender cómo funcionan las cosas y qué funcionalidad se proporciona. Puede parecer que este es un ejercicio inútil, porque en la mayoría de los lugares estudiados no habrá vulnerabilidades. Pero sólo comprender 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 que de algún modo sean muy diferentes a otros. Y así se encontró la primera vulnerabilidad peligrosa.
IDOR
Las vulnerabilidades IDOR (Insecure Direct Object Reference) son una de las vulnerabilidades más comunes en la lógica empresarial, que permite a uno u otro acceder a objetos a los que en realidad no se permite el acceso. Las vulnerabilidades de IDOR crean la posibilidad de obtener información sobre un usuario de diversos grados de criticidad.
Una de las opciones de IDOR es realizar acciones con objetos del sistema (usuarios, cuentas bancarias, artículos del carrito de compras) manipulando los identificadores de acceso a estos objetos. Esto lleva a las consecuencias más impredecibles. Por ejemplo, la posibilidad de reemplazar la cuenta del remitente de los fondos, a través de la cual puedes robárselos a otros usuarios.
En el caso de MCS, los auditores acaban de descubrir una vulnerabilidad IDOR asociada con identificadores no seguros. En la cuenta personal del usuario, se utilizaban identificadores UUID para acceder a cualquier objeto que, como dicen los expertos en seguridad, parecía impresionantemente inseguro (es decir, protegido contra ataques de fuerza bruta). Pero para ciertas entidades, se descubrió que se utilizan números predecibles regulares para obtener información sobre los usuarios de la aplicación. Creo que puedes adivinar que fue posible cambiar el ID de usuario por uno, enviar la solicitud nuevamente y así 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 solicitud del lado del servidor (SSRF)
Lo bueno de los productos OpenSource es que tienen una gran cantidad de foros con descripciones técnicas detalladas de los problemas que surgen y, si tienes suerte, una descripción de la solución. Pero esta moneda tiene una otra cara: las vulnerabilidades conocidas también se describen en detalle. Por ejemplo, hay maravillosas descripciones de vulnerabilidades en el foro de OpenStack. и , que por alguna razón nadie tiene prisa por solucionarlo.
Una funcionalidad común de las aplicaciones es la capacidad del usuario de enviar un enlace al servidor, en el que el servidor hace clic (por ejemplo, para descargar una imagen de una fuente específica). Si las herramientas de seguridad no filtran los enlaces en sí o las respuestas devueltas por el servidor a los usuarios, los atacantes pueden utilizar fácilmente dicha funcionalidad.
Las vulnerabilidades de la SSRF pueden hacer avanzar enormemente el desarrollo de un ataque. Un atacante puede obtener:
- acceso limitado a la red local atacada, por ejemplo, solo a través de ciertos segmentos de la red y utilizando un determinado protocolo;
- acceso completo a la red local, si es posible bajar del nivel de aplicación al nivel de transporte y, como resultado, gestión de carga completa a nivel de aplicación;
- acceso para leer archivos locales en el servidor (si se admite el esquema file:///);
- И многое другое.
Se conoce desde hace tiempo una vulnerabilidad SSRF en OpenStack, que es de naturaleza “ciega”: cuando contactas al servidor, no recibes una respuesta de él, pero recibes diferentes tipos de errores/retrasos, dependiendo del resultado de la solicitud. . En base a esto, puede realizar un escaneo de puertos en los hosts de la red interna, con todas las consecuencias consiguientes que no deben subestimarse. Por ejemplo, un producto puede tener una API administrativa a la que solo se puede acceder desde la red corporativa. Con documentación (no se olvide de los internos), un atacante puede usar SSRF para acceder a métodos internos. Por ejemplo, si de alguna manera pudo obtener 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.
Esta no es la primera vez que se descubre una vulnerabilidad SSRF en OpenStack. En el pasado, era posible descargar imágenes ISO de VM desde un enlace directo, lo que también tenía consecuencias similares. Esta característica ahora se ha eliminado de OpenStack. Al parecer, la comunidad consideró que ésta era la solución más sencilla y fiable al problema.
Y en Informe disponible públicamente del servicio HackerOne (h1), la explotación de un SSRF que ya no es ciego con la capacidad de leer metadatos de instancia conduce al acceso raíz a toda la infraestructura de Shopify.
En MCS, se descubrieron vulnerabilidades SSRF en dos lugares con funcionalidad similar, 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 shells
A pesar de cientos de estudios escritos, año tras año el ataque XSS (cross-site scripting) sigue siendo el más vulnerabilidad web (o ?).
La carga de archivos es el lugar favorito de cualquier investigador de seguridad. A menudo resulta que puedes cargar un script arbitrario (asp/jsp/php) y ejecutar comandos del sistema operativo, en la terminología de los pentesters - "cargar shell". Pero la popularidad de este tipo de vulnerabilidades funciona en ambas direcciones: se recuerdan y se desarrollan remedios contra ellas, de modo que recientemente la probabilidad de "cargar un shell" tiende a cero.
El equipo atacante (representado por Digital Security) tuvo suerte. Bien, en MCS del lado del servidor se verificó el contenido de los archivos descargados, solo se permitieron imágenes. Pero SVG también es una imagen. ¿Cómo pueden ser peligrosas las imágenes SVG? ¡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 es posible atacar a otros usuarios de la nube, es decir, a los administradores.
Un ejemplo de un ataque XSS en un formulario de inicio de sesión de phishing
Ejemplos de explotación de ataques XSS:
- ¿Por qué intentar robar una sesión (especialmente porque ahora las cookies solo HTTP están en todas partes, protegidas contra robo mediante scripts js), si el script cargado puede acceder inmediatamente a la API de recursos? En este caso, la carga útil puede utilizar solicitudes XHR para cambiar la configuración del servidor, 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 inyección de JavaScript, un atacante puede arreglárselas sin ella. Usando HTML puro, crea un formulario de inicio de sesión falso para el sitio y roba la contraseña del administrador a través de este phishing avanzado: la página de phishing para el usuario termina en la misma URL y es más difícil para el usuario detectarla.
- Finalmente, el atacante puede organizar — configurar cookies de más de 4 KB. El usuario sólo necesita abrir el enlace una vez, y todo el sitio se vuelve inaccesible hasta que el usuario piensa en limpiar específicamente 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 detectado, esta vez con un exploit más inteligente. El servicio MCS le permite combinar configuraciones de firewall en grupos. El nombre del grupo era donde se detectó el XSS. Su peculiaridad era que el vector no se activaba inmediatamente, no al ver la lista de reglas, sino al eliminar un grupo:
Es decir, el escenario resultó ser el siguiente: un atacante crea una regla de firewall con "carga" en el nombre, el administrador lo nota después de un tiempo e inicia el proceso de eliminación. Y aquí es donde funciona el JS malicioso.
Para que los desarrolladores de MCS se protejan contra XSS en las imágenes SVG cargadas (si no se pueden omitir), el equipo de Seguridad Digital recomendó:
- Coloque los archivos cargados por los usuarios en un dominio separado que no tenga nada que ver con las "cookies". El script se ejecutará en el contexto de un dominio diferente y no representará una amenaza para MCS.
- En la respuesta HTTP del servidor, envíe 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 la explotación XSS:
- utilizando el indicador "Solo HTTP", puede hacer que los encabezados de "Cookies" de la sesión sean inaccesibles para JavaScript malicioso;
- hará que sea mucho más difícil para un atacante explotar XSS;
- Los motores de plantillas modernos, como Angular o React, desinfectan automáticamente los datos del usuario antes de enviarlos al navegador del usuario.
Vulnerabilidades de autenticación de dos factores
Para mejorar 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 eficaz de evitar que un atacante obtenga acceso a un servicio si las credenciales del usuario se han visto comprometidas.
Pero, ¿el uso de un segundo factor de autenticación siempre garantiza la seguridad de la cuenta? Existen los siguientes problemas de seguridad en la implementación de 2FA:
- Búsqueda de fuerza bruta del código OTP (códigos de un solo uso). A pesar de la simplicidad de operación, las grandes empresas también encuentran errores como la falta de protección contra la fuerza bruta de OTP: , .
- Algoritmo de generación débil, por ejemplo, la capacidad de predecir el siguiente código.
- Errores lógicos, como la capacidad de solicitar la OTP de otra persona en su teléfono, como este de Shopify.
En el caso de MCS, 2FA se implementa basado en Google Authenticator y . El protocolo en sí ya ha sido probado, pero vale la pena verificar la implementación de la verificación del código en el lado de la aplicación.
MCS 2FA se utiliza en varios lugares:
- Al autenticar al usuario. Existe protección contra la fuerza bruta: el usuario solo tiene unos pocos intentos de ingresar una contraseña de un solo uso, luego la entrada se bloquea por un tiempo. Esto bloquea la posibilidad de selección de OTP por fuerza bruta.
- Al generar códigos de respaldo sin conexión para realizar 2FA, además de deshabilitarlo. Aquí no se implementó ninguna protección de fuerza bruta, lo que hizo posible, si tenía una contraseña para la cuenta y una sesión activa, regenerar códigos de respaldo o desactivar 2FA por completo.
Teniendo en cuenta que los códigos de respaldo estaban ubicados en el mismo rango de valores de cadena que los generados por la aplicación OTP, la posibilidad de encontrar el código en poco tiempo era mucho mayor.
El proceso de selección de una OTP para desactivar 2FA usando la herramienta “Burp: Intruder”
resultado
En general, la SQM parece ser un producto seguro. Durante la auditoría, el equipo de pentesting no pudo obtener acceso a las máquinas virtuales del cliente y sus datos, y el equipo de MCS corrigió rápidamente las vulnerabilidades encontradas.
Pero aquí es importante señalar que la seguridad es un trabajo continuo. Los servicios no son estáticos, están en constante evolución. Y es imposible desarrollar un producto completamente sin vulnerabilidades. Pero puede encontrarlos a tiempo y minimizar la posibilidad de que vuelvan a ocurrir.
Ahora todas las vulnerabilidades mencionadas en MCS ya han sido solucionadas. Y para mantener la cantidad de nuevos al mínimo y reducir su vida útil, el equipo de la plataforma continúa haciendo esto:
- realizar periódicamente auditorías por parte de empresas externas;
- apoyar y desarrollar la participación;
- dedicarse a la seguridad. 🙂
Fuente: habr.com