por SeerLight
La construcción de cualquier servicio siempre implica un trabajo constante sobre la seguridad. La seguridad es un proceso continuo que incluye un análisis y mejora constantes de la protección del producto, el monitoreo de noticias sobre vulnerabilidades y mucho más. También se incluyen las auditorías. Las auditorías se realizan tanto con recursos internos como con la ayuda de expertos externos, quienes pueden ayudar significativamente con la seguridad, ya que no están inmersos en el proyecto y tienen una visión clara.
Este artículo trata sobre esa visión clara de los expertos externos, quienes 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ó a la empresa Digital Security, conocida por su alta experiencia en el ámbito de la seguridad informática. En este artículo analizaremos algunas vulnerabilidades interesantes encontradas durante la auditoría externa, para que usted no tropiece con las mismas piedras al crear su propio servicio en la nube.
Descripción del producto
es una plataforma para construir infraestructura virtual en la nube. Incluye IaaS, PaaS, un mercado de imágenes de aplicaciones listas para desarrolladores. Dada la arquitectura de MCS, era necesario verificar la seguridad del producto en las siguientes áreas:
- protección de la infraestructura del entorno de virtualización: hipervisores, enrutamiento, cortafuegos;
- protección de la infraestructura virtual de los clientes: aislamiento entre ellos, incluidas las redes, redes privadas en SDN;
- OpenStack y sus componentes abiertos;
- S3 de desarrollo propio;
- IAM: proyectos multitenencia con un modelo de roles;
- Vision (visión por computadora): API y vulnerabilidades al trabajar con imágenes;
- interfaz web y ataques web clásicos;
- vulnerabilidades de componentes PaaS;
- API de todos los componentes.
Quizás, lo más relevante para la historia futura es todo.
¿Qué trabajos se realizaron y por qué son necesarios?
La auditoría de seguridad está dirigida a identificar vulnerabilidades y errores de configuración que pueden llevar a la filtración de datos personales, a la modificación de información sensible o a la interrupción de la disponibilidad de los servicios.
Durante el trabajo, que dura en promedio de 1 a 2 meses, los auditores repiten las acciones de posibles atacantes y buscan vulnerabilidades en la parte del cliente y del servidor del servicio seleccionado. En el contexto de la auditoría de la plataforma en la nube MCS, se han establecido los siguientes objetivos:
- Análisis de la autenticación en el servicio. Las vulnerabilidades en este componente permitirían acceder de inmediato a cuentas ajenas.
- Estudio del modelo de roles y la diferenciación del acceso entre diferentes cuentas. Para un atacante, la posibilidad de acceder a una máquina virtual ajena es un objetivo deseado.
- Vulnerabilidades de la parte del cliente. XSS/CSRF/CRLF/etc. ¿Puede existir la posibilidad de atacar a otros usuarios a través de enlaces maliciosos?
- Vulnerabilidades de la parte del servidor: RCE y diversas inyecciones (SQL/XXE/SSRF, etc.). Las vulnerabilidades del servidor suelen ser más difíciles de encontrar, pero comprometen de inmediato a muchos usuarios.
- Análisis de la aislamiento de segmentos de usuarios a nivel de red. Para un atacante, la falta de aislamiento aumenta significativamente la superficie de ataque sobre otros usuarios.
- Análisis de la lógica de negocio. ¿Se puede engañar al sistema y crear máquinas virtuales de forma gratuita?
En este proyecto, el trabajo se realizó bajo el modelo de "Gray-box": los auditores interactuaron con el servicio con privilegios de usuarios normales, pero contaban parcialmente con los códigos fuente de la API y tenían la posibilidad de aclarar detalles con los desarrolladores. Normalmente, este es el modelo de trabajo más conveniente y, al mismo tiempo, bastante realista: la información interna puede ser recopilada por un atacante, solo es cuestión de tiempo.
Vulnerabilidades encontradas
Antes de que el auditor comience a enviar diversos payloads (cargas útiles utilizadas para realizar ataques) a lugares aleatorios, es necesario comprender cómo funciona todo, qué funcionalidad está presente. Puede parecer que esto es una actividad inútil, ya que en la mayoría de los lugares estudiados no habrá vulnerabilidades. Pero solo entendiendo la estructura de la aplicación y la lógica de su funcionamiento se podrá encontrar los vectores de ataque más complejos.
Es importante encontrar lugares que parezcan sospechosos o que difieran significativamente de otros. Y la primera vulnerabilidad peligrosa fue encontrada precisamente de esta manera.
IDOR
Las vulnerabilidades IDOR (Insecure Direct Object Reference, referencias directas inseguras a objetos) son uno de los tipos de vulnerabilidades más comunes en la lógica empresarial, que permiten de alguna manera acceder a objetos a los que en realidad no se tiene permiso. Las vulnerabilidades IDOR crean la posibilidad de obtener información sobre el usuario con diversos niveles de criticidad.
Una forma de IDOR es realizar acciones con objetos del sistema (usuarios, cuentas bancarias, productos en el carrito) mediante manipulaciones de los identificadores de acceso a esos objetos. Esto puede conducir a consecuencias impredecibles. Por ejemplo, se puede sustituir la cuenta del remitente de fondos, permitiendo robar a otros usuarios.
En el caso de MCS, los auditores descubrieron una vulnerabilidad IDOR relacionada con identificadores inseguros. En el panel de usuario, se usaban identificadores UUID para acceder a cualquier objeto, que parecían, como dicen los expertos en seguridad, bastante invulnerables (es decir, protegidos contra ataques de fuerza bruta). Sin embargo, se descubrió que, para ciertas entidades, se utilizaban números predecibles para obtener información sobre los usuarios de la aplicación. Supongo que ya pueden imaginar que era posible cambiar el ID de usuario por uno más uno, enviar la solicitud de nuevo y, de esta manera, obtener información evitando la ACL (lista de control de acceso, reglas de acceso a los datos para procesos y usuarios).
Server Side Request Forgery (SSRF)
Los productos OpenSource son buenos porque hay una cantidad enorme de foros con descripciones técnicas detalladas de los problemas que surgen y, si tienes suerte, con descripciones de las soluciones. Pero esta medalla tiene un reverso: también se detallan las vulnerabilidades conocidas. Por ejemplo, en el foro de OpenStack hay descripciones excelentes de vulnerabilidades y , que, por alguna razón, nadie se apresura a corregir.
Una funcionalidad común de las aplicaciones es la posibilidad de que el usuario envíe al servidor un enlace al que el servidor accede (por ejemplo, para cargar una imagen desde la fuente especificada). Cuando la filtración de la seguridad de los mismos enlaces o las respuestas devueltas del servidor a los usuarios es insuficiente, los delincuentes pueden aprovechar fácilmente tal funcionalidad.
Las vulnerabilidades SSRF pueden avanzar considerablemente en el desarrollo de un ataque. Un atacante puede acceder a:
- acceso limitado a la red local atacada, por ejemplo, solo a ciertos segmentos de la red y a través de un protocolo específico;
- acceso completo a la red local, si es posible una degradación del nivel de aplicaciones al nivel de transporte y, como resultado, un control total de la carga a nivel de aplicaciones;
- acceso para leer archivos locales en el servidor (si se soporta el esquema file:///);
- y mucho más.
En OpenStack, existe desde hace tiempo una vulnerabilidad SSRF de carácter 'ciego': al solicitar al servidor no obtienes respuesta, pero recibes diferentes tipos de errores/demoras, dependiendo del resultado de la solicitud. A partir de esto, se puede realizar un escaneo de puertos en hosts dentro de la red interna, con todas las consecuencias que no deben subestimarse. Por ejemplo, un producto puede tener una API para el back office, accesible solo desde la red corporativa. Con la documentación (no olvidemos a los informantes), un atacante puede utilizar SSRF para acceder a métodos internos. Por ejemplo, si se logra de alguna manera obtener una lista aproximada de URL útiles, se puede utilizar SSRF para interactuar con ellas y realizar una solicitud: en términos simples, transferir dinero de una cuenta a otra o cambiar límites.
Este no es el primer caso de descubrimiento de una vulnerabilidad SSRF en OpenStack. En el pasado, existía la posibilidad de cargar imágenes ISO de VM a través de un enlace directo, lo que también conducía a consecuencias similares. Actualmente, esta función ha sido eliminada de OpenStack. Al parecer, la comunidad consideró que era la solución más sencilla y confiable al problema.
Y en En un informe públicamente accesible del servicio HackerOne (h1), la explotación ya no ciega de SSRF con la posibilidad de acceder a metadatos de la instancia conduce a obtener acceso Root a toda la infraestructura de Shopify.
En MCS, se encontraron vulnerabilidades SSRF en dos lugares con funcionalidad similar, pero eran prácticamente imposibles de explotar debido a firewalls y otras protecciones. De todos modos, el equipo de MCS solucionó este problema, sin esperar a la comunidad.
XSS en lugar de cargar 'shells'
A pesar de los cientos de investigaciones escritas, año tras año, XSS (ataque de scripting entre sitios) sigue siendo el más una vulnerabilidad web (o ?).
La carga de archivos es un lugar favorito para cualquier investigador de seguridad. A menudo se puede cargar un script arbitrario (asp/jsp/php) y ejecutar comandos del sistema operativo, en la jerga de los pentesters, se dice que se puede "subir un shell". Pero la popularidad de estas vulnerabilidades funciona en ambos sentidos: se recuerdan y se desarrollan medidas en su contra, por lo que en los últimos tiempos la probabilidad de "subir un shell" tiende a cero.
Al equipo atacante (representado por Digital Security) le tocó la suerte. Ok, en MCS, en el lado del servidor, se verificaba el contenido de los archivos cargados, solo se permitían imágenes. Pero un SVG también es una imagen. ¿Y qué peligros pueden presentar las imágenes SVG? Que se pueden incrustar fragmentos de JavaScript en ellas.
Resultó que los archivos cargados son accesibles para todos los usuarios del servicio MCS, lo que significa que se puede atacar a otros usuarios de la nube, específicamente a los administradores.
Ejemplo de explotación mediante un ataque XSS de un formulario de inicio de sesión de phishing
Ejemplos de explotación de ataques XSS:
- ¿Por qué intentar robar la sesión (especialmente, dado que ahora hay cookies HTTP-Only, protegidas contra el robo mediante scripts js), si el script cargado puede acceder directamente a la API del recurso? 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 abierta del atacante y obtener acceso SSH al servidor.
- Si la política CSP (política de protección de contenido) impide la inclusión de JavaScript, el atacante puede prescindir de él. Puede diseñar un formulario falso de inicio de sesión en puro HTML y robar la contraseña del administrador mediante un phishing avanzado: la página de phishing para el usuario aparece en la misma URL, y es más difícil para el usuario detectarla.
- Finalmente, el atacante puede organizar — enviando Cookies de más de 4 Kbytes. Al usuario le basta con abrir el enlace una vez, y todo el sitio se vuelve inaccesible, hasta que adivine limpiar el navegador: en la gran mayoría de los casos, el servidor web se negará a aceptar a tal cliente.
Veamos el ejemplo de otra XSS identificada, esta vez con una explotación más astuta. El servicio MCS permite agrupar las configuraciones del firewall. La XSS se encontró en el nombre del grupo. Su particularidad era que el vector no se activaba de inmediato, no al ver la lista de reglas, sino al eliminar el grupo:
Es decir, el escenario era el siguiente: un atacante crea una regla de firewall con un «carga» en el nombre, el administrador la nota después de un tiempo y comienza el proceso de eliminación. Y justo en ese momento, el JS malicioso se activa.
Para proteger a los desarrolladores de MCS contra XSS en las imágenes SVG cargadas (si no se pueden evitar), el equipo de Seguridad Digital recomendó:
- Almacenar los archivos cargados por los usuarios en un dominio separado, que no esté relacionado con el «de cookies». El script se ejecutará en el contexto de otro dominio y no representará una amenaza para MCS.
- En la respuesta HTTP del servidor, devolver el encabezado «Content-disposition: attachment». Así, los archivos serán descargados por el navegador en lugar de ejecutarse.
Además, actualmente hay muchas maneras para que los desarrolladores mitigen los riesgos de explotación de XSS:
- mediante el flag «HTTP Only», se pueden hacer que los encabezados de sesión «Cookies» no sean accesibles para JavaScript malicioso;
- complicará significativamente la explotación de XSS para el atacante;
- los modernos compiladores de plantillas, como Angular o React, limpian automáticamente los datos del usuario antes de mostrarlos en el navegador del usuario.
Vulnerabilidades de la autenticación de dos factores
Para aumentar la seguridad de las cuentas, se recomienda siempre a los usuarios activar la 2FA (autenticación de dos factores). De hecho, es una forma efectiva de impedir que un atacante acceda al servicio si las credenciales del usuario han sido comprometidas.
Pero, ¿siempre el uso de un segundo factor de autenticación garantiza la seguridad de la cuenta? En la implementación de la 2FA, existen problemas de seguridad como:
- Fuerza bruta del código OTP (códigos de un solo uso). A pesar de la simplicidad de explotación, errores como la falta de protección contra la fuerza bruta de OTP se encuentran incluso en grandes empresas: , .
- Algoritmo débil de generación, como la posibilidad de predecir el siguiente código.
- Errores lógicos, como la posibilidad de solicitar el OTP de otra persona en su propio teléfono, como lo hace Shopify.
En el caso de MCS, la 2FA se implementa sobre la base de Google Authenticator y . El protocolo ya ha estado comprobado por el tiempo, pero vale la pena verificar la implementación de la verificación de código del lado de la aplicación.
En MCS, la 2FA se utiliza en varios lugares:
- En la autenticación del usuario. Aquí hay protección contra ataques de fuerza bruta: el usuario tiene solo unos pocos intentos para ingresar el código de un solo uso, luego se bloquea la entrada por un tiempo. Esto impide la posibilidad de adivinar el OTP mediante la fuerza bruta.
- Al generar códigos de respaldo fuera de línea para realizar 2FA, así como al desactivarlo. Aquí no se implementó protección contra ataques de fuerza bruta, lo que permitía, con la contraseña de la cuenta y una sesión activa, regenerar los códigos de respaldo o desactivar 2FA por completo.
Teniendo en cuenta que los códigos de respaldo estaban en el mismo rango de valores de cadena que los OTP generados por la aplicación, la probabilidad de adivinar un código en poco tiempo era significativamente mayor.
El proceso de adivinar el OTP para desactivar 2FA utilizando la herramienta 'Burp: Intruder'.
Resultado
En general, MCS como producto resultó ser seguro. Durante la auditoría, el equipo de pentesters no pudo acceder a las VM de los clientes y sus datos, y las vulnerabilidades encontradas fueron rápidamente corregidas por el equipo de MCS.
Pero es importante señalar que la seguridad es un trabajo continuo. Los servicios no son estáticos, están en constante evolución. Y desarrollar un producto completamente libre de vulnerabilidades es imposible. Pero se pueden encontrar a tiempo y minimizar la posibilidad de su repetición.
Ahora todas las vulnerabilidades mencionadas en MCS ya han sido corregidas. Y para hacer que el número de nuevas vulnerabilidades sea mínimo y reducir su tiempo de existencia, el equipo de la plataforma continúa haciendo lo siguiente:
- realizar auditorías regularmente con empresas externas;
- mantener y desarrollar la participación;
- ocuparnos de la seguridad. 🙂
Fuente: habr.com
