Los datos corporativos suelen ser un secreto comercial. Filtrarlos puede provocar un golpe a la reputación, pérdidas económicas o incluso la quiebra. Por lo tanto, los requisitos de seguridad para un producto B2B deben ser muy altos. Al crear un nuevo producto, Corporate Mail Mail.ru, prestamos especial atención al problema de su seguridad.
Corporate Mail Mail.ru es una versión local del conocido correo B2C Mail.ru. Comparado con él, contiene una serie de modificaciones para trabajar en un nuevo entorno: el circuito del cliente.
Para que nuestros clientes confíen en la seguridad, decidimos someternos a una auditoría en una empresa tercera y solucionar todas las deficiencias que encontramos antes de ofrecer el producto al mercado. Para ello, recurrieron a una de las empresas más reputadas en el campo de la seguridad de la información: la seguridad digital.
Los resultados de la auditoría están por debajo del corte.
Ejecución remota de código en uWSGI
Existen diferentes marcos para crear aplicaciones web Python. Normalmente, la interfaz de puerta de enlace del servidor web de Python (WSGI) se utiliza para comunicarse entre la aplicación web y el servidor web. Además, el uso de WSGI le permite implementar componentes de middleware.
Para estandarizar la comunicación entre una aplicación web Python y un servidor web como Apache o Nginx, se desarrolló PEP 0333, seguido de PEP 3333, que describe la interfaz WSGI. No nos detendremos en cómo funciona WSGI, pero le informaremos sobre un servidor popular que admite la interfaz WSGI: uWSGI.
El servidor uWSGI puede funcionar tanto en el modo de servidor web normal como en el "modo WSGI", intercambiando datos con otro servidor web, como Nginx. Al mismo tiempo, Nginx usa el protocolo binario del mismo nombreuwsgi , que es interesante para los ciberdelincuentes debido a su rica funcionalidad. Al analizar el "interior" de la solución, se encontró un servidor uWSGI, al que tenían acceso todos los componentes internos del producto.
El problema era que el protocolo uwsgi puede usar las llamadas variables mágicas que le permiten configurar dinámicamente el servidor uWSGI. Entre estas variables hay
UWSGI_FILEuna que te permite cargar una nueva aplicación dinámica si especificas la ruta al archivo en la variable. Al final resultó que, uWSGI-servidor puede manejar diferentes circuitos de esta manera, por ejemplo section, fd, call, o más interesante - exec. Por lo tanto, puede pasar la variable como un valorexec://<cmmand>para ejecutar un comando bash arbitrario. Se ha escrito un exploit para analizar este problema y está disponible en github .
Un ejemplo de una consulta que ejecuta un comando.
Esta vulnerabilidad solo podría aprovecharse si el atacante:
- Ya está en la red interna del producto, por ejemplo, uno de los componentes se ha visto comprometido. Esto podría permitirle secuestrar un nuevo componente, obtener acceso a nuevos datos y continuar con el ataque.
- Tiene SSRF con la capacidad de enviar datos arbitrarios a través de TCP (por ejemplo, usando
gopher://). En este escenario, un atacante puede obtener acceso al interior del producto.
Cabe señalar que las implementaciones de interfaces CGI para otros lenguajes de programación o marcos también pueden ser vulnerables, por ejemplo, un exploit del mismo repositorio para FastCGI. Esto no quiere decir que se trate de una vulnerabilidad en el sentido habitual, sino más bien una característica de los servidores CGI, por lo que debe limitar el acceso a dichos servidores tanto como sea posible.
Evitando la protección CSRF
Con la introducción de varios mecanismos de seguridad en los navegadores, los ataques del lado del cliente en la web moderna están desapareciendo gradualmente. Esto también se aplica a CSRF: los navegadores ya han implementado el soporte para la cookie SameSite, aunque si se configura incorrectamente, aún puede haber lagunas. Además, muchos marcos populares permiten a los desarrolladores configurar fácilmente la protección CSRF, pero algunos errores o vulnerabilidades no críticas pueden provocar un ataque CSRF. Dichos errores se encontraron en la aplicación de calendario incluida con nuestro producto.
La aplicación cuenta con una API que te permite realizar acciones sobre los eventos y calendarios del usuario, por ejemplo: editarlos, visualizarlos o borrarlos. Para hacer referencia al objeto, el parámetro UID se pasa en la ruta URL, que es responsable del ID del calendario o evento. Se parece a esto:
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
De forma predeterminada, el UID se genera aleatoriamente y el usuario no puede influir en él. Pero en la aplicación se encontraron dos lugares en los que el usuario puede cambiar el UID.
La primera es para importar archivos en formato ICS (un formato especial para calendarios y eventos), tienen un campo UID especial que el usuario controla al momento de importar. En este caso, después de importar eventos, sus UID seguirán siendo los mismos que se transfirieron en el archivo. Además, este parámetro no tiene filtrado. Por lo tanto, el usuario podría crear un evento con un UID arbitrario.
El segundo es la capacidad de cambiar el calendario UID al editarlo. Esto se puede hacer interceptando la solicitud para editar el calendario y simplemente cambiando el campo UID. Aquí tampoco hubo filtrado.
Otra característica importante: esta API implementa protección CSRF; para ello, se pasa un parámetro especial en los parámetros GET, que desempeña el papel de clave para la API y token CSRF. Se agrega a través de JavaScript a todas las solicitudes de API. Es una mala práctica pasar tokens CSRF en los parámetros GET; en este caso, los tokens pueden filtrarse a través del referente, los registros de la aplicación o el historial del navegador.
Poniendolo todo junto. Un atacante puede controlar los UID de los objetos en una aplicación y compartir el acceso tanto a eventos como a calendarios con otros usuarios. En este caso, los usuarios verán el mismo UID, y cuando comiencen a trabajar con dicho objeto, las solicitudes se ejecutarán con el UID controlado por el atacante. Con esto, un atacante puede crear un objeto con un UID como este:
../../../AnyPathTo?anyparam=value&
Ahora, cuando el usuario realiza una acción sobre el objeto, se generará una solicitud:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
Luego, también se le agregará un token, que desempeña el papel de un token CSRF:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
Y finalmente, al realizar la solicitud, el navegador normaliza la secuencia "
../", como resultado, la solicitud se enviará a
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
Ahora, un atacante puede obligar a un usuario a enviar una solicitud a la aplicación a lo largo de una ruta arbitraria con parámetros arbitrarios y con el token CSRF correcto. Queda por entender qué métodos de solicitud podemos ejecutar.
Resultó simple: al editar, se envía PUT, al eliminar, DELETE, al visualizar, GET (POST se usa para crear y no podemos obligar a la víctima a usarlo). Al usar DELETE, un atacante puede obligar al navegador del usuario a ejecutar una solicitud para eliminar un objeto del usuario. Una ventaja adicional para un atacante es que cuando un usuario edita un objeto, se envía una solicitud PUT con el cuerpo de la solicitud. Al editar un calendario, el cuerpo de la solicitud contendrá JSON, que contiene todos los parámetros del calendario actual. Es decir, el atacante que creó el calendario "malicioso" controla estos parámetros. Si el atacante logra redirigir una solicitud de edición del calendario malicioso al calendario privado del usuario, todas las propiedades del calendario malicioso se aplicarán a las propiedades del calendario de la víctima.Esto puede sobrescribir el acceso al calendario porque es una de las propiedades del calendario especificadas en JSON.
Capacidad de ataque MITM
La penetración de un intruso en la red interna de la empresa es una situación peligrosa que está plagada de graves consecuencias. Por lo tanto, durante la auditoría del producto, una de nuestras tareas fue encontrar fallas en la arquitectura del sistema que pudieran ayudar a un atacante a avanzar en el dominio o mejorar los ataques externos.
Una de las principales características del producto es la integración con Active Directory. Está implementado para la autenticación vía LDAP y la recolección de mensajes del servidor Exchange, en este ejemplo nos centraremos en ActiveSync. Para un atacante, este es un objetivo muy interesante porque las cuentas de usuario y las contraseñas se pasan entre el producto y Active Directory durante la conexión. Al obtener acceso a las conexiones, un atacante podrá secuestrar cuentas y estará un paso más cerca de comprometer el dominio.
En las soluciones internas y en los servidores de las empresas, a menudo existe un problema con el uso incorrecto de TLS o su ausencia, mientras que no es difícil implementar TLS para un servicio. Esto suele ser una consecuencia del hecho de que la red interna de la empresa se considera más segura y los administradores de la empresa no pierden tiempo creando la infraestructura PKI correcta y emitiendo certificados para todos los servidores.
El ataque más común dentro de las redes corporativas es MITM. Este tipo de ataque suele permitir el acceso dentro del Active Directory de una empresa. Al mismo tiempo, no siempre es posible que un atacante ataque la interacción servidor a servidor dentro de la red de la empresa; la mayoría de las veces, durante las pruebas de penetración, él o su modelo cae en un segmento de red de usuarios en el que no hay un servidor Exchange o controlador de dominio. Además, en nuestro caso, el producto no utiliza protocolos de resolución de nombres de difusión como NBNS, LLMNR, mDNS, por lo que la suplantación de estos protocolos no permitirá que se implemente MITM. Por lo tanto, para un MITM exitoso entre la solución y otros servidores, es necesario que el atacante tenga acceso a la red donde está instalado uno de estos componentes. A veces es posible lograr este objetivo: hay enrutadores o servidores vulnerables,que en última instancia le permiten acceder a una red en particular.
En nuestro caso, durante el análisis, resultó que la integración con Active Directory es vulnerable a los ataques MITM.
Cuando el usuario ingresa un nombre de usuario y una contraseña, el sistema envía dos solicitudes LDAP al controlador de dominio. La primera solicitud devuelve una lista de direcciones de correo y, si el inicio de sesión del usuario está presente en esta lista, se envía la segunda solicitud, que es Autenticación LDAP simple. Los datos se transmiten en texto sin cifrar sin utilizar SSL / TLS, o mejor dicho, no se utiliza LDAPS (LDAP sobre SSL). Esto permite a un atacante, incluso en el caso de un ataque MITM pasivo, obtener cuentas de usuario que están actualmente autorizadas en el producto.
El segundo problema: al conectarse al servidor de Exchange utilizando el protocolo ActiveSync para recopilar mensajes entrantes, el sistema no verificó la autenticidad del certificado TLS del servidor. En este caso, un atacante podría implementar un ataque MITM activo, al recibir una conexión, podría entregar un certificado autofirmado, establecer una conexión y enviar los datos al servidor Exchange; entonces MITM será invisible y un atacante podrá obtener las credenciales de usuario, que se transmiten en el protocolo ActiveSync.
Al explotar estas vulnerabilidades, un atacante podría, en teoría, obtener cuentas de usuario y luego utilizarlas en un ataque a un dominio de Active Directory. Por otra parte, cabe destacar que el uso correcto de TLS es una tarea necesaria para la empresa que implementa la solución.
Resultado
Nos enfrentamos constantemente a ataques de piratas informáticos y hemos adquirido una sólida experiencia en cómo combatirlos. Creemos que los productos que colocamos dentro del perímetro del cliente deben ser lo más seguros posible, incluso en función de los resultados de controles independientes. Corporate Mail Mail.ru es uno de esos productos.
Nos enfrentábamos a una tarea que requería mucho tiempo: transferir una gran base de código con muchos microservicios a la infraestructura del cliente para que el correo funcionara por sí solo la mayor parte del tiempo, sin fallas ni intervenciones del administrador.
Les pedimos a los auditores que presten la mayor atención a la autorización modificada (Corporate Mail usa el AD del cliente) y la API de correo principal; el código fuente de estos componentes se analizó en detalle. Como resultado, las deficiencias encontradas se relacionaron principalmente con la topología de red cambiada y las modificaciones específicas de la solución local.
Para el resto de los componentes (calendario, Mail.ru para la interfaz de administración de empresas), se utilizó un modelo de caja gris: los auditores interactuaban con el servicio con los privilegios de los usuarios normales, pero podían conectarse al contenedor con la aplicación en ejecución, poseían parcialmente el código fuente de la API y podían aclarar los detalles con los desarrolladores.
La auditoría fue muy útil para nosotros. Encontramos una serie de deficiencias en algunos de los componentes, que corregimos rápidamente para llevar un producto seguro al mercado. Al mismo tiempo, estábamos convencidos del alto nivel de protección de la mayoría de los demás componentes. Planeamos realizar tales auditorías de manera regular; queremos que nuestro producto esté siempre en la cima de las soluciones domésticas más seguras, no solo en nuestra opinión, sino también en la opinión de auditores independientes.
La seguridad del correo corporativo es la combinación de la seguridad del producto en sí y la infraestructura del cliente. Es decir, la responsabilidad de la seguridad de los datos corporativos recae en nosotros, el desarrollador y el propio cliente. Además, hemos formulado recomendaciones sobre prácticas probadas para proteger la infraestructura de fallas y siempre asesorar a los clientes durante la instalación de nuestro producto.