Respuesta de Nym a la auditoría de seguridad de Cure53 (julio de 2024)

Introducción

NymVPN está diseñado para garantizar una protección privada, segura y confiable para tus comunicaciones en línea. En Nym, la transparencia y la confianza del usuario son primordiales, por eso el código de Nym es de código abierto y se somete a auditorías independientes periódicas para garantizar los más altos estándares de seguridad y privacidad.

En julio de 2024, Nym se sometió a una auditoría independiente por parte de Cure53, una empresa de ciberseguridad con sede en Berlín y más de 15 años de experiencia en la realización de pruebas de software y auditorías de código. Su exhaustiva revisión cubrió componentes clave de la infraestructura de Nym, incluyendo aplicaciones móviles y de escritorio, infraestructura VPN, implementaciones de criptografía y la arquitectura general del sistema.

Todas las vulnerabilidades críticas y de alta gravedad identificadas fueron abordadas. Actualmente estamos esperando la retroalimentación de Cure53 sobre nuestro informe y las correcciones.

El reporte completo de Cure53 está publicado aquí. También puedes ver la charla del Dr. Nadim Kobeissi’s talk para OSTIF, donde habla sobre la auditoría de Nym y ofrece un excelente análisis técnico detallado de algunos de los problemas descubiertos.

Resumen de la Auditoría de Nym por Cure53.

Cure53 llevó a cabo una evaluación de seguridad exhaustiva del ecosistema de Nym, que incluyó pruebas de penetración, auditorías de código fuente y revisiones de código. La auditoría se centró en evaluar la postura de seguridad de las aplicaciones móviles y de escritorio de Nym, la API del backend, el software e infraestructura de la VPN y la criptografía. El equipo de Nym brindó apoyo continuo al equipo de Cure53 durante toda la auditoría, asegurando una colaboración fluida y un proceso transparente.

Cure53 empleó una estrategia de caja de cristal, aprovechando el acceso completo al código fuente, compilaciones, documentación, entornos de prueba y documentos científicos de respaldo. A lo largo de 56 días hábiles, la auditoría involucró a un equipo de seis expertos sénior en ciberseguridad. El trabajo se dividió en cinco paquetes de trabajo (PT):

• WP1: Apps móviles de Nym
• WP2: Apps de escritorio de Nym
• WP3: API backend de Nym
• WP4: Software Nym VPN e infraestructura
• WP5: Criptografía de Nym

La auditoría logró una amplia cobertura en todo el alcance definido, identificando 43 hallazgos, incluyendo 7 vulnerabilidades de seguridad —que comprendían problemas críticos y de alta gravedad— y 24 debilidades generales, clasificadas con potencial de explotación medio o bajo y que representan oportunidades para fortalecer aún más el sistema.

El software e infraestructura de NymVPN se encontraron en un excelente estado desde una perspectiva de seguridad, sin que se descubrieran problemas durante la auditoría. Cure53 concluyó que todos los componentes investigados tenían bases de seguridad sólidas, demostrando una postura robusta en general. Las aplicaciones de escritorio se evaluaron como en buen estado desde una perspectiva de seguridad, sin que se identificaran fallas de seguridad significativas. El equipo de auditoría destacó que la implementación general fue sólida. De manera similar, el backend y la API de Nym se evaluaron como en un estado moderado desde una perspectiva de seguridad. Notablemente, el informe reconoció que varias vulnerabilidades críticas habían sido mitigadas y prevenidas eficazmente, lo que subraya nuestro enfoque proactivo hacia la seguridad y nuestra cuidadosa implementación.

Hallazgos clave

WP1: Pruebas de penetración de caja de cristal y auditorías de código fuente de las aplicaciones móviles de Nym.

En el WP1, Cure53 llevó a cabo análisis estáticos y dinámicos combinados con pruebas de caja blanca en las aplicaciones móviles NymVPN para Android e iOS. El objetivo era identificar cualquier debilidad, configuración incorrecta o riesgo de seguridad en las aplicaciones. En general, los hallazgos fueron de menor gravedad, sin que se identificaran vulnerabilidades críticas o de alto riesgo. Los problemas identificados fueron principalmente de gravedad media, baja o informativa y pueden abordarse eficazmente como parte de un esfuerzo más amplio para reforzar las aplicaciones. El análisis estático tuvo como objetivo encontrar configuraciones subóptimas o incorrectas en las aplicaciones que pudieran generar debilidades. Sin embargo, el análisis no reveló preocupaciones de alto riesgo.

Además, Cure53 llevó a cabo una investigación exhaustiva de los vectores de ataque comunes para Android, incluyendo el acceso potencial a componentes no exportados, omisiones de autenticación, receptores de difusión defectuosos y validación insuficiente de intentos extras. No se identificaron vulnerabilidades en ninguna de estas áreas, lo que refleja la solidez de las medidas de seguridad de la plataforma.

Cure53 también confirmó que ni la aplicación de Android ni la de iOS contenían información sensible o secretos codificados de forma rígida, lo cual es una consideración de seguridad clave.

En general, las aplicaciones móviles demostraron una buena postura de seguridad con una superficie de ataque mínima. Aparte de algunas áreas menores de mejora, como el uso inadecuado del almacenamiento seguro nativo de la aplicación iOS (NYM-01-024), no se identificaron fallas de seguridad significativas en las aplicaciones.

WP2: Pruebas de penetración de caja de cristal y auditorías de código fuente de las aplicaciones de escritorio de Nym.

El WP2 se centró en las aplicaciones de escritorio NymVPN para Windows, Linux y macOS. El equipo de pruebas llevó a cabo una revisión exhaustiva tanto de los componentes frontend para problemas del lado del cliente como de la capa de comunicación backend de Rust. En general, las aplicaciones de escritorio demostraron sólidas prácticas de seguridad.

Entre los hallazgos positivos clave se incluye el uso del framework React para los componentes frontend, lo que reduce significativamente la superficie de ataque. El equipo no identificó ninguna vulnerabilidad importante del lado del cliente, aparte de un escenario muy específico en el que una URL de repositorio maliciosa podría desencadenar la ejecución arbitraria de JavaScript (XSS) si se hacía clic en ciertas condiciones. Este problema se clasificó como de bajo riesgo, sin que se identificaran datos sensibles ni vulnerabilidades críticas. En el lado del backend, la comunicación con el demonio a través de socket Unix (Linux) y pipe (Windows) se examinó cuidadosamente, y no se identificaron fallas importantes ni riesgos de seguridad.

Si bien se observaron algunos problemas menores, estos hallazgos se centraron en mejorar aún más la seguridad en lugar de abordar fallas críticas.

WP3: Pruebas de penetración de caja de cristal y auditorías de código fuente de la API del backend de Nym.

El WP3 se centró en la API de los componentes del backend de Nym, incluyendo las gateways y los nodos de mezcla, excluyendo los validadores. El proceso de prueba examinó minuciosamente la serialización/deserialización, la inyección SQL, los mecanismos de autenticación y autorización, las vulnerabilidades SSRF, los ataques de temporización y los puntos de ejecución de código. Positivamente, el backend de Nym demostró una seguridad moderada, sin que se identificaran vulnerabilidades directas de ejecución de código, riesgos de inyección SQL o problemas de SSRF explotables de alto riesgo. Los mecanismos de autenticación y autorización en nuestra red están implementados siguiendo estándares seguros, mitigando eficazmente posibles omisiones. Si bien los componentes del backend mostraron una seguridad sólida en general, se identificaron algunos problemas notables. Entre estos, dos hallazgos se clasificaron como de gravedad alta o crítica (NYM-01-027, NYM-01-030 y NYM-01-032), los cuales abordamos a continuación.

NYM-01-027 PT3: Reutilización de clave nonce en AES-CTR en las gateways de Nym (Crítico)

Durante una revisión del código fuente del repositorio de Nym, se identificó que la comunicación entre la gateway y los clientes sufre de una falla criptográfica importante. Específicamente, se descubrió que el handshake entre las gateways de Nym y los clientes tenía la siguiente comunicación para cifrar datos usando AES-CTR y una clave única no rotatoria, junto con un nonce cero constante. Esto, a su vez, pone en riesgo toda la comunicación si una sola parte del texto plano se filtra a un atacante, ya que le permite romper el cifrado existente aplicando simples operaciones XOR entre los textos cifrados y el texto plano filtrado.

Aunque la confidencialidad de los datos transferidos entre el cliente y la gateway solo está en riesgo en caso de una fuga de texto plano, reconocemos plenamente la gravedad de este problema. El equipo de Nym respondió rápidamente reemplazando el cifrado AES-CTR con el esquema recomendado AES-GCM-SIV, mejorando significativamente la seguridad de la comunicación en la 2024.12-aero release.

NYM-01-030 WP3: El gateway omite la verificación del número de serie de las credenciales (Crítico)

La ausencia de verificaciones del número de serie de las credenciales a nivel del gateway no compromete la seguridad del sistema porque el protocolo zk-nyms protocol](https://nym.com/blog/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet) is based on an offline e-cash model, se basa en un modelo de dinero electrónico fuera de línea, que está inherentemente diseñado para detectar y prevenir el doble gasto. En los esquemas de dinero electrónico en línea, los proveedores mantienen una conexión constante con una autoridad central (por ejemplo, un banco o una cadena de bloques) y verifican los números de serie en tiempo real antes de aceptar un pago. Si se aplicara a NymVPN, esto significaría que las gateways verificarían activamente los números de serie de las credenciales a medida que ocurren las transacciones. En contraste, el dinero electrónico fuera de línea elimina la necesidad de una conexión continua; los proveedores pueden aceptar pagos y depositarlos más tarde, con la garantía criptográfica de que cualquier intento de doble gasto se identificará durante la verificación de la transacción. El protocolo zk-nyms sigue este modelo de dinero electrónico fuera de línea, asegurando que incluso sin verificaciones locales de números de serie en el gateway, los validadores de la nym-API aún puedan detectar y prevenir el doble gasto cuando se verifican los tickets. Esto significa que la verificación del número de serie en el gateway no es necesaria para la seguridad. Sin embargo, las verificaciones locales en el gateway podrían proporcionar una capa adicional de detección temprana, mejorando la velocidad de identificación de intentos de doble gasto dentro del mismo gateway. Si bien dichas verificaciones pueden mejorar la eficiencia, no son esenciales para la seguridad central del protocolo. Las garantías criptográficas integradas en el protocolo zk-nyms aseguran que el doble gasto se detecte de manera confiable en una etapa posterior, lo que permite identificar y poner en una lista negra a cualquier actor malicioso. Como resultado, las verificaciones de doble gasto en el gateway deberían considerarse una mejora de eficiencia opcional en lugar de un requisito de seguridad fundamental.

Además, en nuestro sistema, cada credencial zk-nym tiene una fecha de caducidad fija, actualmente establecida en una [semana] (https://github.com/nymtech/nym/blob/dd3dcfa7fe0ffe9f98cc62ab3377e42365fd8b21/common/nym_offline_compact_ecash/src/scheme/mod.rs#L269). Después de este período, las credenciales caducadas ya no son aceptadas por los nodos de entrada de la red. Este mecanismo de caducidad limita aún más el impacto de cualquier intento de doble gasto, asegurando que el sistema permanezca seguro incluso sin verificaciones de número de serie a nivel de gateway.

NYM-01-032 WP3: Los parámetros del filtro Bloom producen falsos positivos (Alto)

Observamos que esta parte del código estaba en desarrollo activo y no estaba en uso dentro de la aplicación NymVPN en el momento de la auditoría. Los parámetros proporcionados eran puramente para fines de prueba. Como se explicó en NYM-01-030 WP3, los filtros Bloom se agregaron como una verificación adicional para el doble gasto. Sin embargo, dado que nuestro protocolo maneja el doble gasto de forma diferente por diseño, y los filtros Bloom generaban demasiada sobrecarga (ya que teníamos que sincronizarlos entre los gateways y la nym-api), decidimos eliminarlos.

Además de estos problemas de alta prioridad, la auditoría también destacó varias vulnerabilidades de gravedad media, específicamente relacionadas con posibles vectores de ataque de Denegación de Servicio (DoS). Estos hallazgos subrayan áreas donde el backend de NymVPN puede mejorar su resistencia contra las interrupciones del servicio. Planeamos abordar estos temas como parte de nuestra hoja de ruta para 2025.

En general, la API y los componentes del backend mostraron un nivel de seguridad encomiable, con vulnerabilidades confinadas en gran medida a casos específicos u oportunidades de fortalecimiento.

WP4: Pruebas de penetración de caja de cristal y auditorías de código fuente del software e infraestructura de Nym VPN.

El WP4 implicó una evaluación de seguridad exhaustiva del software NymVPN, centrándose en:

• Funcionalidad principal: Manejo de protocolos, cifrado, gestión de red, resolución DNS e implementación de enrutamiento IP, utilización
• Integración del frontend: Se evaluó la interfaz de usuario basada en Tauri en cuanto a diseño, usabilidad e integración eficiente con el núcleo de Rust a través de FFI, así como el rendimiento específico de la plataforma en Windows, macOS y Linux.
• Medidas de seguridad clave: Almacenamiento seguro de credenciales, prevención de fugas, gestión de claves y mitigación de vulnerabilidades conocidas de VPN.

Se confirmó que la implementación basada en Rust del manejo de protocolos, el cifrado, el enrutamiento IP, la tunelización y la integración de la pila de red era confiable, sin que se identificaran vulnerabilidades. Las características de seguridad clave, como el almacenamiento de credenciales, la prevención de fugas y la gestión de claves de cifrado, se consideraron que cumplían con altos estándares de seguridad y mitigaban los riesgos de manera efectiva.

Se descubrió que el frontend de escritorio combina con éxito la usabilidad con una integración eficiente en el núcleo de Rust. Se confirmó que los mecanismos de manejo de errores y registro eran exhaustivos e implementados cuidadosamente, proporcionando información valiosa para la resolución de problemas sin exponer ningún dato sensible.

No se identificaron vulnerabilidades durante el análisis del PT4, y se confirmó que el software NymVPN demuestra una excelente postura de seguridad.

WP5: Pruebas de penetración de caja de cristal y auditorías de código fuente de la criptografía de Nym.

El WP5 se centró en una evaluación exhaustiva de la criptografía utilizada en la plataforma Nym. Esto incluyó componentes clave como la crate Coconut, la crate zk-nyms (e-cash), el protocolo Sphinx, el protocolo Outfox y otras primitivas criptográficas de uso común. El código fuente de todos los esquemas criptográficos, escrito íntegramente en Rust, fue elogiado por su excelente organización, lo que permitió a los auditores familiarizarse rápidamente con la implementación.

El protocolo Coconut y de dinero electrónico fue revisado exhaustivamente y demostró el uso eficaz de mecanismos de ofuscación para proteger la información sensible, sin que se identificaran fugas de información no intencionales. Los dos NIZKPs utilizados en el protocolo no mostraron vulnerabilidades explotables que pudieran permitir la omisión o el engaño del verificador. Además, la selección de las bibliotecas criptográficas subyacentes, en particular bls12_381, garantizó estrictas comprobaciones de pertenencia, previniendo ataques que utilizaran puntos de curva inválidos o subgrupos incorrectos. Además, se confirmó que la generación de aleatoriedad para las claves criptográficas y los nonces utilizaba métodos fuertes y criptográficamente seguros, lo que respalda la integridad de la generación de claves en toda la plataforma.

A pesar de estas fortalezas, la auditoría también identificó varios problemas que se clasificaron como de riesgo crítico o alto. Abordamos cada uno de ellos individualmente a continuación.

NYM-01-009 WP5: BLS12-381 EC omisiones de firma en la biblioteca Coconut (Crítico)

Cure53 observó que la función verify_partial_blind_signature, destinada a verificar firmas ciegas parciales durante la fase de emisión, no incluye todas las comprobaciones necesarias para la firma proporcionada, lo que podría permitir a un atacante omitir la validación de la firma utilizando puntos infinitos en la curva elíptica. Sin embargo, queremos aclarar que dentro del protocolo Coconut, la función que verifica el gasto de credenciales [incluye las comprobaciones necesarias y rechaza de manera confiable las credenciales inválidas].(https://github.com/nymtech/nym/blob/8e05386a0b6f803cca526d12d462db93ac1204cf/common/nymcoconut/src/scheme/verification.rs#L287). Como resultado, dado el diseño del protocolo, cualquier intento de ataque no tendría éxito, ya que las credenciales falsificadas se detectan y rechazan en una etapa posterior. Esto asegura que la seguridad e integridad del sistema no se vean comprometidas en la práctica.

Dicho esto, reconocemos que las comprobaciones adicionales sugeridas por Cure53 podrían mejorar la solidez de estas funciones si se utilizaran fuera del contexto específico de Coconut. Dado que nuestro código es de código abierto y nuestro objetivo es proporcionar componentes reutilizables para la comunidad en general, hemos implementado las comprobaciones de firma recomendadas para puntos infinitos como una precaución adicional en la [versión 2024.13-magura] (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md). Esto garantiza que las funciones se puedan utilizar de manera confiable en otros contextos, manteniendo al mismo tiempo los más altos estándares de seguridad.

NYM-01-014 WP5: Omisión de firma parcial en e-Cash fuera de línea (Crítico)

Este problema es similar al descrito anteriormente, pero se aplica al esquema de e-cash en lugar de Coconut. Al igual que con la implementación de Coconut, todas las verificaciones necesarias [ya estaban implementadas durante la fase de gasto del protocolo] (https://github.com/nymtech/nym/blob/8e05386a0b6f803cca526d12d462db93ac1204cf/common/nym_offline_compact_ecash/src/scheme/mod.rs#L718), asegurando que cualquier intento de ataque sería inútil. Esto significa que, en la práctica, la seguridad e integridad del sistema nunca estuvieron en peligro, a pesar de que el problema se clasificó como crítico.

Sin embargo, al igual que en el caso de Coconut, hemos implementado proactivamente las comprobaciones de firma adicionales recomendadas por Cure53 en todas las funciones relevantes en la [versión 2024.13-magura] (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md). Si bien estas comprobaciones no eran necesarias para asegurar el flujo del protocolo existente, mejoraron la solidez del código y aseguraron que estas funciones pudieran reutilizarse de manera confiable en otros contextos. Este enfoque subraya nuestro compromiso de mantener altos estándares de seguridad, tanto para nuestro sistema como para la comunidad de código abierto en general.

NYM-01-033 WP5: Falsificación de firma del esquema Pointcheval-Sanders (Crítico)

Cure53 identificó una vulnerabilidad en nuestra implementación de la función de firma dentro del esquema de firma Pointcheval-Sanders. Específicamente, la vulnerabilidad surge porque, en nuestra implementación, el valor aleatorio h en la tupla de firma (h, s) no se selecciona aleatoriamente. Como resultado, si solo firmáramos atributos públicos, la firma sería susceptible de falsificación.

Sin embargo, es importante enfatizar que esta vulnerabilidad de falsificación de firma no presenta ningún riesgo en el contexto de los protocolos Coconut o de e-cash. Ambos protocolos se basan en atributos privados por diseño, utilizando así el proceso de emisión ciega para el cálculo de la firma. En el protocolo de emisión ciega, el uso de un compromiso con los mensajes como entrada a la función hash garantiza que diferentes tuplas de mensajes generarán valores únicos para h. Como resultado, la vulnerabilidad solo se manifestaría si los protocolos Coconut o de dinero electrónico se utilizaran únicamente con atributos públicos, lo cual no es el caso en la red Nym. Por lo tanto, el riesgo identificado por Cure53 no se aplica a nuestro sistema, ya que los protocolos en uso mitigan inherentemente este problema.

NYM-01-042 WP5: Agregación defectuosa a firmas de e-cash fuera de línea inválidas (Crítico)

Este problema es similar a los problemas NYM-01-009 y NYM-01-014, donde la función de agregación independiente de firmas podría producir una firma inválida si el adversario puede manipular las firmas parciales para que den como resultado el punto infinito. Sin embargo, tanto en el protocolo Coconut como en el de dinero electrónico, el proceso de verificación rechaza explícitamente cualquier firma que dé como resultado el punto infinito, por lo que este problema no compromete la seguridad ni la integridad de ninguno de los dos protocolos. Sin embargo, en línea con las acciones tomadas para los problemas NYM-01-009 y NYM-01-014, hemos [implementado comprobaciones adicionales] (https://github.com/nymtech/nym/blob/8e05386a0b6f803cca526d12d462db93ac1204cf/common/nym_offline_compact_ecash/src/scheme/aggregation.rs#L121) en la función de agregación para fortalecer aún más nuestra base de código y evitar cualquier posible uso indebido en otros contextos (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md).

NYM-01-005 WP5: La falta de comprobación del punto infinito revela texto plano para ElGamal (Alto).

La implementación actual de Coconut y dinero electrónico no utiliza el cifrado ElGamal (ni se utilizó durante la auditoría). En cambio, utilizamos compromisos de Pedersen más eficientes, que no presentan los mismos riesgos. Por lo tanto, el problema relacionado con ElGamal no representó ningún riesgo de seguridad dentro de nuestro sistema existente. También eliminamos ahora la crate Coconut y, por lo tanto, el esquema ElGamal.

Últimas palabras

Nos gustaría agradecer al equipo de Cure53 por su experiencia y dedicación durante todo este proceso de auditoría. También apreciamos la colaboración y la profesionalidad demostradas durante las etapas de planificación y ejecución de la auditoría. Nuestro compromiso continuo con la seguridad sigue siendo una prioridad máxima, y esperamos mantener colaboraciones continuas con expertos en seguridad para defender los más altos estándares para nuestro ecosistema.