Informe de prueba de penetración para intercambio centralizado

Resumen de gestión

El equipo de Centralized Exchange se puso en contacto con Sayfer para realizar una prueba de penetración de caja negra completa en su aplicación web y una revisión de caja blanca para su arquitectura criptográfica en diciembre de 2021.

Antes de evaluar los servicios anteriores, llevamos a cabo una reunión inicial con el equipo técnico de Centralized Exchange y recibimos una descripción general del sistema y los objetivos de esta investigación.

Durante el período de investigación de 4 semanas, descubrimos 10 vulnerabilidades en el sistema. Las vulnerabilidades más peligrosas fueron la inyección SQL y las fallas en la lógica empresarial.

El impacto en el sistema es crítico, ya que un atacante malicioso podría explotar algunas de estas vulnerabilidades para aprovechar el sistema, ya sea cambiando su rol de usuario a "superusuario" a través de la inyección de SQL o abusando del sistema y robando dinero del Intercambio centralizado. utilizando el mecanismo de actualización del sistema 30s.

Metodología de Evaluación de Seguridad

usos sayfer OWASP WSTG como nuestro estándar técnico al revisar aplicaciones web. Después de obtener una comprensión profunda del sistema, decidimos qué pruebas OWASP se requieren para evaluar el sistema.

Conclusiones de la evaluación de seguridad

Guardar claves MPC privadas de forma insegura

Descripción

Los intercambios centralizados sufren de prácticas de gestión de claves de baja calidad. Hay muchos ejemplos de casos en los que las llaves se perdieron o fueron robadas, lo que provocó que el servicio perdiera todos los fondos de la billetera o los bloqueara por completo.

Durante nuestra auditoría de archivos de configuración, revisamos el almacenamiento de administración de claves. Descubrimos que las claves que se utilizan para la billetera fría multi-sig no se almacenan en lugares suficientemente distribuidos.

Hay 3 claves que se utilizan dentro de la firma de claves MPC. 1 se almacena en una máquina física protegida. Los otros 2 se almacenan dentro de la misma máquina dedicada en GCP.

Se toman un par de medidas de seguridad para proteger estas máquinas, pero el problema radica en la distribución, si la máquina implementada en GCP se ve comprometida, un atacante puede firmar cualquier transacción desde la billetera fría.

Este es un lugar sensible y de alto riesgo donde muchos han fallado en el pasado, las mejores prácticas deben seguirse estrictamente.

Mitigación

Utilice el servicio de custodia de terceros para administrar monederos activos y bóvedas. Estaremos encantados de recomendar a uno de nuestros socios.

Estos servicios manejan MPC y la administración de claves por usted, con otras capas de seguridad adicionales que hacen que el uso de dichos servicios sea la mejor opción para los intercambios centralizados.

SQL Injection

Descripción

Un ataque de inyección SQL consiste en insertar o "inyectar" una consulta SQL parcial o completa en la entrada de datos que se transmite desde el cliente a la aplicación web. Un ataque de inyección SQL exitoso puede leer datos confidenciales de la base de datos, modificar los datos de la base de datos (insertar/actualizar/eliminar), realizar operaciones de administración de la base de datos (como apagar el DBMS), recuperar el contenido de un archivo determinado en el sistema de archivos DBMS o escribir archivos en el sistema de archivos y, en algunos casos, emitir comandos al sistema operativo.

Usando el transaction endpoint pudimos abusar del more Parámetro de consulta de URL para inyectar una carga SQL maliciosa:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

El payload que usamos fue:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b – Que en este caso, verifica si la instancia en ejecución de Postgres es la versión 10 o no.

Un atacante que aproveche esta vulnerabilidad podría apoderarse del sistema. Pudimos extraer los esquemas de la tabla, actualizar el rol de nuestro propio usuario o volcar cualquier información guardada en la base de datos e incluso cambiar el saldo de nuestro usuario en la base de datos.

Mitigación

La vulnerabilidad de inyección de SQL es fácil de arreglar pero difícil de mitigar. Se necesita un fuerte linting o implementación de reglas de compilación que impongan cambios futuros.

La mitigación de las vulnerabilidades de inyección SQL generalmente se realiza siguiendo un marco de trabajo elegido, lo que significa que el desarrollador nunca debe concatenar cadenas en una declaración SQL completa.

Cada entrada del usuario debe ser desinfectada en un ejecutor de SQL en lugar de usarse como una simple cadena de consulta de SQL.

Para obtener más información sobre la perfección de la inyección SQL, consulte el SQL IHoja de referencia para la prevención de inyecciones.

Referencias de objetos directos inseguras

Descripción

Las referencias directas a objetos inseguras (IDOR) son un tipo de vulnerabilidad de control de acceso que surge cuando una aplicación utiliza la entrada proporcionada por el usuario para acceder a los objetos directamente. Como resultado de esta vulnerabilidad, los atacantes pueden eludir la autorización y acceder directamente a los recursos del sistema, por ejemplo, registros o archivos de la base de datos.

Descubrimos que la API █████████ le permite a un atacante ver la información del tablero de otros usuarios, incluidos todos los datos financieros de este usuario.
La vulnerabilidad se basa en el parámetro de identificación del tablero, que es un número entero adivinable. Solicitud de ejemplo para un panel único (para un panel que no es propiedad del usuario actual):

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

Eso indica que el /dashboard/DASHBOARD_ID el punto final no verifica la autorización para el recurso solicitado. Un atacante autenticado podría raspar cada panel que contenga información sobre los fondos del usuario y las transacciones pasadas.

Mitigación

Hay varias formas de mitigar las vulnerabilidades de IDOR, para este caso, parece que la solución podría ser verificar la autorización para todas y cada una de las solicitudes.

Esto significa que cada clave de solicitud podrá obtener solo los paneles de su cuenta.

Autenticación más débil en el canal alternativo

Descripción

Incluso si los mecanismos de autenticación primarios no incluyen ninguna vulnerabilidad, es posible que existan vulnerabilidades en canales de usuario de autenticación legítimos alternativos para las mismas cuentas de usuario.

Esta vulnerabilidad es parte de una cadena de 2 vulnerabilidades que nos permitieron controlar cualquier cuenta con solo una dirección de correo electrónico.

Como parte de nuestra fase de reconocimiento en la que tratamos de encontrar un vector de ataque más amplio al enumerar los principales subsistemas objetivo, encontramos una interfaz de administración bajo el subdominio ██████████████████. Es posible iniciar sesión en la interfaz de administración con un usuario normal de la aplicación, pero para casi todas las solicitudes de red que inspeccionamos durante la carga de la página principal, el servidor devuelve un error 401.

[IMAGE_REDACTED]

Hicimos ingeniería inversa del archivo del paquete main.js que tiene el código de front-end para la aplicación y encontramos todos los puntos finales potenciales con los que un administrador puede interactuar.

Podríamos explotar sólo el punto final de api/updateUser. El punto final nos permitió editar cualquier correo electrónico de usuario y, al hacerlo, pudimos restablecer la contraseña de la víctima y tomar el control de la cuenta.

[IMAGE_REDACTED]

Mitigación

Es muy recomendable realizar un mecanismo de autenticación o una VPN para la depuración o para los servicios administrativos del sistema para evitar la presencia de aplicaciones públicas no seguras que puedan ser aprovechadas por un atacante.

Además, existe un mecanismo de autorización en la interfaz de administración, pero esto está fuera del alcance de este proyecto.

Revise los metarchivos del servidor web para detectar fugas de información

Descripción

Como parte de nuestra investigación sobre el objetivo y sus subdominios, encontramos algunos metarchivos que no deberían ser públicos, o al menos no sin el mecanismo de autenticación adecuado.

• ████████████████████████.gitignore
• ██████████████████████████████/docker-compose.yml
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

Encontramos tres tipos de archivos que pueden dañar los servicios de ████████, .gitignore, swagger-ui y del docker-compose.yml archivo Estos tres archivos revelan datos confidenciales

sobre la arquitectura del servicio. Un actor malintencionado puede utilizar esta información para aumentar su vector de ataque sobre el objetivo.

Mitigación

Si es posible, elimine estos archivos del servicio público o implemente un mecanismo de autorización que otorgue acceso solo a usuarios privilegiados.

Falta el encabezado de la política de seguridad de contenido

Descripción

La Política de seguridad de contenido (CSP) es una capa adicional de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques, incluidos Cross-Site Scripting (XSS) y ataques de inyección de datos.

No encontramos un encabezado CSP en ninguna de las respuestas del servidor.

[IMAGE_REDACTED]

Al usar los administradores de sitios web de CSP, agregue otra línea de defensa contra XSS o ataques de clickjacking, al hacerlo, el sistema estará seguro incluso si se realizan cambios no seguros en el código fuente en el futuro.

Una política de CSP básica debe al menos describir los dominios incluidos en la lista blanca predeterminados para archivos estáticos (como secuencias de comandos, imágenes y CSS). Y frame-ancestors para evitar ataques de click-jacking.

Más información:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

Mitigación

Añadiendo el Content-Security-Policy: [policy] en cada respuesta donde la carga de recursos externos podría ser peligrosa

Recomendamos encarecidamente usarlo y probarlo primero con la variación "Solo informe" para probar su política antes de lanzarla a producción:

Content-Security-Policy-Report-Only: [policy]

Prueba de encabezados de seguridad

Descripción

1. Los navegadores admiten muchos encabezados HTTP que pueden mejorar la seguridad de las aplicaciones para proteger contra una variedad de ataques comunes, los encabezados se intercambian entre un cliente web (generalmente un navegador) y un servidor para especificar los detalles relacionados con la seguridad de la comunicación HTTP.

Al mirar los encabezados de seguridad ████████, falta lo siguiente:

• Opciones de tipo de contenido X

Establecer este encabezado evitará que el navegador interprete los archivos como algo diferente a lo declarado por el tipo de contenido en los encabezados HTTP.

• Estricto-Transporte-Seguridad

HSTS es un mecanismo de política de seguridad web que ayuda a proteger los sitios web contra ataques de degradación de protocolo y secuestro de cookies. Permite que los servidores web declaren que los navegadores web solo deben interactuar con él mediante conexiones HTTPS seguras, y nunca a través del protocolo HTTP inseguro.

• Política de referencia

El encabezado Referer es un encabezado de solicitud que indica el sitio desde el que se originó el tráfico. Si no existe una prevención adecuada, la propia URL e incluso la información confidencial contenida en la URL se filtrarán al sitio de origen cruzado.

• Acceso-Control-Permitir-Origen

El encabezado tiene el valor de "*" que expone la API para cada sitio web, este podría no ser el resultado deseado.

Mitigación

Agregar los encabezados mencionados anteriormente a todos los servicios de back-end.

Revise los metarchivos del servidor web para detectar fugas de información

Descripción

Mientras investigamos el objetivo con DevTool, pudimos ver el código fuente de la interfaz sin ofuscación. Esta vulnerabilidad se produce porque los paquetes de JS se envían con mapas de código fuente a producción, lo que permite leer el código fuente original con comentarios que pueden revelar información, por ejemplo, el siguiente archivo paths.ts:

█████████████████████/paths.ts [IMAGEN_ELIMINADA]

Al tener el mapa fuente, un atacante puede obtener información sobre el código base, leer comentarios y encontrar partes de código en desuso que luego se pueden usar para encontrar vulnerabilidades.

Mitigación

No envíe los mapas de origen a la producción, la mayoría de los sistemas de registro y seguimiento de errores tienen la opinión de cargar los mapas de origen en un sistema de back-ofice. Otro enfoque sería servir los mapas de origen solo a usuarios autenticados a través de VPN u otros mecanismos.

Servidor web de huellas dactilares

Descripción

Si bien la información del servidor expuesta en sí misma no es necesariamente una vulnerabilidad, es información que puede ayudar a los atacantes a explotar otras vulnerabilidades que puedan existir. La mayoría de los puntos finales no revelan ninguna información sobre el servidor a través de encabezados HTTP o páginas de error.
Usando la siguiente solicitud HTTP mal formada, pudimos identificar un servidor Nginx a través de una respuesta 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

El cuerpo de la respuesta es:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

Mitigación

Hay diferentes formas de ocultar los encabezados del servidor web, los métodos más utilizados son:

1. Servidores proxy inversos que se interponen entre la Internet global y la interna
2. Configure cada servidor web para eliminar estos encabezados.

Apéndice A: correcciones de evaluación de seguridad

Será actualizado por el equipo de Sayfer después de la primera revisión.