Réponse de Nym à l'audit de sécurité de Cure53 (juillet 2024)

Introduction

NymVPN est conçu pour assurer une protection privée, sécurisée et fiable de vos communications en ligne. Chez Nym, la transparence et la confiance des utilisateurs sont primordiales, c’est pourquoi le code de Nym est open-source et fait régulièrement l’objet d’audits indépendants pour assurer les plus hauts standards de sécurité et de confidentialité.

En juillet 2024, Nym a fait l'objet d'un audit indépendant par Cure53 une société de cybersécurité basée à Berlin avec plus de 15 ans d'expérience dans la conduite de tests de logiciels et d'audits de code. L'évaluation portait sur les composants clés, y compris les applications mobiles et de bureau, l'infrastructure VPN, les implémentations de cryptographie et l'architecture globale du système.

Toutes les vulnérabilités critiques et à haute gravité identifiées ont été traitées. Nous attendons actuellement les commentaires de Cure53 sur notre rapport et les correctifs.

Le cure53 complet signalé est publié ici. Vous pouvez également regarder [Dr. Le discours de Nadim Kobeissi] (https://youtu.be/gTP4_cnoRlE?si=cwuTV2jQN-99jKUS) pour OSTIF, où il discute de l'audit de Nym et apporte une grande profondeur technique à certains des problèmes découverts.

Résumé de l'audit Nym par Cure53

Cure53 a effectué une évaluation complète de la sécurité de l'écosystème Nym, y compris des tests de pénétration, des audits de code source et des examens de code. L’audit s’est concentré sur l’évaluation de la position de sécurité des applications mobiles et de bureau de Nym, de l’API backend, du logiciel et de l’infrastructure VPN et de la cryptographie. L’équipe de Nym a soutenu en permanence l’équipe de Cure53 tout au long de l’audit, assurant une collaboration harmonieuse et un processus transparent.

Cure53 a utilisé une stratégie de boîte à cristal, en profitant du plein accès au code source, des builds, de la documentation, des environnements de test et des supports scientifiques. Sur une période de 56 jours ouvrables, la vérification a impliqué une équipe de six experts en cybersécurité. Le travail a été divisé en cinq lots de travaux :

• WP1 : Applications mobiles Nym
• WP2 : Applications de bureau Nym
• WP3 : Nym backend API
• Logiciel et infrastructure VPN Nym
• WP5 : cryptographie Nym

L'audit a atteint une couverture étendue dans le périmètre défini, identifiant 43 constatations, y compris 7 vulnérabilités de sécurité - comprenant des problèmes critiques et de haute gravité - et 24 faiblesses générales, classées comme ayant un potentiel d'exploitation moyen ou faible et représentant des opportunités pour renforcer davantage le système.

Notamment, le logiciel et l'infrastructure NymVPN ont été trouvés en excellent état du point de vue de la sécurité, sans aucun problème découvert. Cure53 a conclu que tous les composants examinés avaient de solides bases de sécurité, démontrant une posture globale robuste. Les applications de bureau ont été jugées en bon état du point de vue de la sécurité, sans défauts de sécurité significatifs identifiés. L'équipe d'audit a souligné que la mise en œuvre globale était solide. De même, le backend de Nym et l'API ont été évalués comme étant dans un état modéré du point de vue de la sécurité. Notamment, le rapport a reconnu que plusieurs vulnérabilités critiques avaient été efficacement atténuées et évitées, soulignant notre approche proactive en matière de sécurité et de mise en œuvre soignée.

Constatations clés

WP1 : Tests d’intrusion en environnement transparent “crystal-box” et audits de code source des applications mobiles Nym

En WP1, Cure53 a effectué des analyses statiques et dynamiques combinées à des tests en boîte blanche sur les applications mobiles NymVPN pour Android et iOS. L'objectif était d'identifier les faiblesses, les erreurs de configuration ou les risques de sécurité dans les applications. Dans l'ensemble, les conclusions étaient de moindre gravité, sans aucune vulnérabilité critique ou à haut risque. Les problèmes identifiés étaient principalement moyens, bas, ou d'information de gravité et peut être efficacement traitée dans le cadre d'un effort plus large de durcissement des demandes. L'analyse statique visait à trouver des paramètres sous-optimaux ou des mauvaises configurations dans les applications qui pourraient conduire à des faiblesses. Cependant, l'analyse a révélé aucune préoccupation à haut risque.

En outre, Cure53 a mené une enquête approfondie sur les vecteurs d'attaque communs pour Android, y compris l'accès potentiel aux composants non exportés, les contournements d'authentification, les récepteurs de diffusion défectueux et la validation insuffisante des extras d'intention. Aucune vulnérabilité n'a été identifiée dans aucun de ces domaines, reflétant la force des mesures de sécurité de la plateforme.

Cure53 a également confirmé que ni les applications Android ni iOS ne contenaient des informations ou des secrets sensibles codés en dur, ce qui est une considération de sécurité clé.

Dans l'ensemble, les applications mobiles ont démontré une bonne position de sécurité avec une surface d'attaque minimale. Mis à part quelques petits domaines d'amélioration, tels que l'utilisation inappropriée du stockage sécurisé natif de l'application iOS (NYM-01-024), aucune faille de sécurité significative n'a été identifiée dans les applications.

WP2 : Tests d’intrusion en environnement transparent “crystal-box” et audits de code source contre les applications de bureau Nym

WP2 s'est concentré sur les applications de bureau NymVPN pour Windows, Linux et macOS. L'équipe de test a effectué un examen approfondi des composants frontend pour les problèmes côté client et de la couche de communication Rust backend. Dans l'ensemble, les applications de bureau ont fait preuve de bonnes pratiques de sécurité.

Les principales conclusions positives incluent l'utilisation du framework React pour les composants frontend, qui réduit considérablement la surface d'attaque. L'équipe n'a identifié aucune vulnérabilité majeure du côté du client, mis à part un scénario très spécifique où une URL de référentiel malveillante pourrait déclencher l'exécution arbitraire de JavaScript (XSS) si elle est cliquée sous certaines conditions. Ce problème a été catégorisé comme un risque faible, sans données sensibles ni vulnérabilités critiques. Du côté de l'arrière-plan, la communication avec le démon sur le socket Unix (Linux) et le pipe (Windows) a été soigneusement examinée, et aucun défaut majeur ou risque de sécurité n'a été identifié.

Bien que quelques problèmes mineurs aient été notés, ces conclusions ont été centrées sur le renforcement de la sécurité plutôt que sur la résolution des défauts critiques.

WP3 : Tests d’intrusion en environnement transparent “crystal-box” & audits de code source contre l'API backend de Nym

WP3 s'est concentré sur l'API des composants backend de Nym, y compris les passerelles et les mix nodes, tout en excluant les validateurs. Le processus de test a examiné minutieusement la sérialisation/désérialisation, l'injection SQL, les mécanismes d'authentification et d'autorisation, les vulnérabilités SSRF, les attaques de timing et les puits d'exécution de code. Positivement, le backend de Nym a démontré une sécurité modérée, sans vulnérabilités d'exécution directe de code, sans risques SQLi ou problèmes de SSRF exploitables à haut risque identifiés. Les mécanismes d'authentification et d'autorisation de notre réseau sont mis en œuvre selon des normes sécurisées, atténuant ainsi efficacement les contournements potentiels. Tandis que les composants backend affichaient une grande sécurité dans l'ensemble, quelques problèmes notables ont été identifiés. Parmi celles-ci, deux conclusions ont été catégorisées comme une sévérité élevée ou critique (NYM-01-027, NYM-01-030 et NYM-01-032), que nous abordons ci-dessous.

NYM-01-027 WP3 : Réutilisation sans clé dans AES-CTR dans les passerelles Nym (Critique)

Lors d'une révision du code source du référentiel Nym, il a été identifié que la communication entre la passerelle et les clients souffre d'une faille cryptographique majeure. Plus précisément, on a découvert que l'agencement entre les passerelles Nym et les clients avait les données chiffrées de communication suivantes en utilisant AES-CTR et un unique clé non pivotante, avec une nonce zéro constante. En retour, cela met toute communication en danger si un seul texte fuit vers un agresseur, car il permet à l'attaquant de casser le cryptage en place en appliquant des opérations XOR simples entre les textes chiffrés et le texte brut fuit.

Bien que la confidentialité des données transférées entre le client et la passerelle ne soit en danger qu'en cas de fuite en clair nous reconnaissons pleinement la sévérité de cette question. L'équipe Nym a réagi rapidement en remplaçant le cryptage AES-CTR par le système AES-GCM-SIV recommandé, améliorant de manière significative la sécurité de la communication dans la [version 2024.12-aer] (https://github.com/nymtech/nym/blob/nym-binaries-v2024.12-aero/CHANGELOG.md).

NYM-01-030 WP3 : La passerelle ignore la vérification du numéro de série des identifiants (Critique)

L'absence de vérification du numéro de série des identifiants au niveau de la passerelle ne compromet pas la sécurité du système parce que le [protocole zk-nym] (https://nym.com/blog/zk-nyms-are-here-a-major-milestone-towards-a-market-ready-mixnet) est basé sur un [modèle e-cash hors ligne] (https://arxiv.org/abs/2303.08221), qui est conçu de manière à détecter et à prévenir les doubles dépenses. Dans les systèmes de monnaie électronique en ligne, les fournisseurs entretiennent une connexion constante avec une autorité centrale (e. ., une banque ou une blockchain) et vérifiez les numéros de série en temps réel avant d'accepter un paiement. Si elle est appliquée à NymVPN, cela signifie que les passerelles vérifieront activement les numéros de série des identifiants au fur et à mesure que des transactions se produisent. En revanche, l'e-cash hors ligne élimine la nécessité d'une connexion continue : les fournisseurs peuvent accepter des paiements et les déposer plus tard, avec l'assurance cryptographique que toute tentative de double dépense sera identifiée lors de la vérification de la transaction. Le protocole zk-nyms suit ce modèle e-cash hors ligne, assurant que même sans vérification locale du numéro de série à la passerelle, Les validateurs nym-API peuvent toujours détecter et prévenir les doubles dépenses lorsque les tickets sont vérifiés. Cela signifie que la vérification du numéro de série à la passerelle n'est pas nécessaire pour la sécurité. Cependant, les contrôles locaux à la passerelle pourraient fournir une couche supplémentaire de détection précoce, améliorant la vitesse d'identification des tentatives de double dépense au sein de la même passerelle. Bien que ces contrôles puissent améliorer l'efficacité, ils ne sont pas essentiels à la sécurité fondamentale du protocole. Les garanties cryptographiques contenues dans le protocole zk-nyms garantissent une détection fiable de la double dépense à un stade ultérieur. permettant d'identifier et de mettre en liste noire tous les acteurs malveillants. Par conséquent, les contrôles de double dépense à la porte d'entrée devraient être considérés comme une amélioration facultative de l'efficacité plutôt que comme une exigence de sécurité fondamentale.

De plus, dans notre système, chaque accréditation zk-nym a une date d'expiration fixe, actuellement fixée à un week. Après cette période, les identifiants expirés ne sont plus acceptés par les nœuds d’entrée du réseau. Ce mécanisme d'expiration limite également l'impact de toute tentative de double dépense en veillant à ce que le système reste sécurisé même sans vérification de numéro de série au niveau de la passerelle.

NYM-01-032 WP3: Les paramètres du filtre Bloom donnent de faux positifs (High)

Nous notons que cette partie du code était en cours de développement actif et n'était pas utilisée dans l'application NymVPN au moment de l'audit. Les paramètres fournis étaient uniquement destinés à des fins de test. Comme expliqué dans le NYM-01-030 WP3, les filtres Bloom ont été ajoutés en tant que vérification supplémentaire des dépenses doubles. Cependant, notre protocole gérant par conception gère différemment les dépenses doubles, et les filtres Bloom ont généré trop de surcharge (comme nous avons dû les synchroniser entre les passerelles et les nym-api), nous avons décidé de les supprimer.

Au-delà de ces questions hautement prioritaires, l'audit a également mis en évidence plusieurs vulnérabilités de moyenne gravité, spécifiquement liées aux vecteurs d'attaque potentiels de déni de service (DoS). Ces conclusions soulignent les domaines dans lesquels le backend NymVPN peut améliorer sa résilience face aux perturbations du service. Nous prévoyons de les aborder dans le cadre de notre feuille de route 2025.

Dans l'ensemble, les composants API et backend présentaient un niveau de sécurité louable, avec des vulnérabilités qui se limitaient en grande partie à des cas spécifiques ou à des possibilités de durcissement.

WP4 : Pentests Crystal-box et audits de code source contre les logiciels et infrastructures Nym VPN

WP4 a impliqué une évaluation complète de la sécurité du logiciel NymVPN, en se concentrant sur:

• Fonctionnalité de base : gestion des protocoles, chiffrement, gestion du réseau, résolution des DNS et implémentation du routage IP, tunneling, et intégration globale de la pile de réseau.
• Intégration en frontend : L'interface utilisateur basée sur Tauri a été évaluée pour sa conception, son utilisation, et une intégration efficace avec le noyau Rust via FFI, ainsi que des performances spécifiques à la plate-forme sur Windows, macOS et Linux.
• Mesures clés de sécurité : stockage sécurisé des identifiants, prévention des fuites, gestion des clés et atténuation des vulnérabilités VPN connues.

L'implémentation de la gestion des protocoles, du chiffrement, du routage IP, du tunnel et de l'intégration de la pile réseau a été confirmée comme fiable, sans aucune vulnérabilité identifiée. Les caractéristiques de sécurité clés, telles que le stockage des identifiants, la prévention des fuites et la gestion des clés de chiffrement, ont été jugées pour répondre à des normes de sécurité élevées et atténuer efficacement les risques.

L'interface de bureau a été trouvée pour combiner avec succès la facilité d'utilisation avec une intégration efficace dans le noyau de Rust Core. Les mécanismes de gestion des erreurs et de journalisation ont été confirmés comme étant complets et mis en œuvre de manière réfléchie, fournissant des informations précieuses sur le dépannage sans révéler de données sensibles.

Aucune vulnérabilité n'a été identifiée lors de l'analyse WP4, et le logiciel NymVPN a été affirmé pour démontrer une excellente position de sécurité.

WP5 : Tests d’intrusion en environnement transparent (“crystal-box”) et audits du code source appliqués à la cryptographie de Nym

WP5 s'est concentré sur une évaluation approfondie de la cryptographie utilisée sur la plate-forme Nym. Cela incluait des composants clés tels que la caisse Coconut, la caisse zk-nyms (ecash), le protocole Sphinx, le protocole Outfox et d'autres primitives cryptographiques couramment utilisées. Le code source pour tous les systèmes de cryptographie, entièrement écrit en Rust, a été loué pour son excellente organisation, permettant aux auditeurs de se familiariser rapidement avec l'implémentation.

Le protocole Coconut et e-cash a été longuement examiné et a démontré l'utilisation efficace de mécanismes aveugles pour protéger les informations sensibles, sans fuites d'informations non intentionnelles identifiées. Les deux NIZKPs utilisés dans le protocole ne montraient aucune vulnérabilité exploitable qui pourrait permettre de contourner ou de tromper le vérificateur. De plus, la sélection des bibliothèques cryptographiques sous-jacentes, en particulier bls12_381, a assuré des vérifications de membre strictes, empêchant les attaques utilisant des points de courbe invalides ou des sous-groupes incorrects. En outre, la génération aléatoire de clés et de nonces cryptographiques a été confirmée pour utiliser des méthodes solides et cryptographiquement sécurisées, soutenant l'intégrité de la génération de clés sur toute la plateforme.

En dépit de ces atouts, la vérification a également identifié plusieurs questions qui ont été classées comme importantes ou à haut risque. Nous nous adressons à chacun d'eux individuellement ci-dessous.

NYM-01-009 WP5 : Bypass de signature BLS12-381 EC dans la bibliothèque Coconut (Critique)

Cure53 a observé que la fonction verify_partial_blind_signature, destinée à vérifier les signatures aveugles partielles pendant la phase d'émission, n'inclut pas toutes les vérifications nécessaires pour la signature fournie, permettant potentiellement à un attaquant de contourner la validation de la signature en utilisant des points infinis sur la courbe elliptique. Toutefois, nous voulons clarifier cela dans le cadre du protocole sur la noix de coco, la fonction vérifiant les dépenses des identifiants inclut les vérifications nécessaires et rejette de manière fiable les identifiants invalides. Par conséquent, étant donné la conception du protocole, toute tentative d'attaque serait infructueuse, car les faux identifiants sont détectés et rejetés à un stade ultérieur. Cela garantit que la sécurité et l'intégrité du système ne sont pas compromises dans la pratique.

Cela dit, Nous reconnaissons que les vérifications supplémentaires suggérées par Cure53 pourraient améliorer la robustesse de ces fonctions si elles devaient être utilisées en dehors du contexte spécifique de Coconut. Puisque notre code est open source et que nous visons à fournir des composants réutilisables pour la communauté en général, nous avons implémenté les vérifications de signatures recommandées pour les points d'infini en tant que précaution supplémentaire dans le 2024. Libération de 3-magura. Cela garantit que les fonctions peuvent être utilisées de manière fiable dans d'autres contextes tout en maintenant les normes de sécurité les plus élevées.

NYM-01-014 WP5 : Bypass de signature partielle en eCash hors ligne (Critique)

Cette question est similaire à celle décrite ci-dessus, mais s'applique au système de monnaie électronique au lieu de Coconut. Comme pour l'implémentation de Coconut, tous les contrôles nécessaires ont été déjà implémentés pendant la phase de dépense du protocole, veiller à ce que toute tentative d'attaque soit rendue infructueuse. Cela signifie que, dans la pratique, la sécurité et l'intégrité du système n'ont jamais été mises en danger, bien que la question soit considérée comme critique.

Néanmoins, comme dans le cas de Coconut, nous avons proactivement mis en œuvre les contrôles de signature supplémentaires recommandés par Cure53 dans toutes les fonctions pertinentes dans le 2024. Libération de 3-magura. Bien que ces vérifications n'aient pas été requises pour sécuriser le flux de protocole existant, ils ont amélioré la robustesse du code et ont fait en sorte que ces fonctions puissent être réutilisées de manière fiable dans d'autres contextes. Cette approche souligne notre engagement à maintenir des normes de sécurité élevées, tant pour notre système que pour la communauté open source au sens large.

NYM-01-033 WP5 : falsification de la signature du système Pointcheval-Sanders (Critique)

Cure53 a identifié une vulnérabilité dans notre implémentation de la fonction de signe dans le schéma de signature de Pointcheval-Sanders. Plus précisément, la vulnérabilité se produit parce que, dans notre implémentation, la valeur aléatoire h dans le tuple de signature (h) n'est pas sélectionnée aléatoirement. En conséquence, si nous ne signions que des attributs publics, la signature serait susceptible d'être falsifiée.

Cependant, il est important de souligner que cette vulnérabilité de contrefaçon de signature ne présente aucun risque dans le contexte des protocoles Coconut ou e-cash. Ces deux protocoles reposent sur des attributs privés par conception, utilisant ainsi le processus d'émission aveugle pour le calcul des signatures. Dans le protocole d'émission aveugle, l'utilisation d'un engagement envers les messages comme entrée dans la fonction de hachage garantit que différents tuples de messages génèrent des valeurs uniques pour h. En conséquence, la vulnérabilité ne se manifesterait que si les protocoles Coconut ou e-cash étaient utilisés avec seulement des attributs publics, ce qui n'est pas le cas dans le réseau Nym. Par conséquent, le risque identifié par Cure53 ne s'applique pas à notre système, étant donné que les protocoles utilisés atténuent intrinsèquement cette question.

NYM-01-042 WP5 : Agrégation par défaut à des signatures eCash hors ligne invalides (Critical)

Ce problème est similaire aux numéros NYM-01-009 et NYM-01-014, où la fonction d'agrégation autonome des signatures pourrait produire une signature non valide si l'adversaire peut manipuler les signatures partielles pour aboutir au point d'infini. Cependant, dans les protocoles Coconut et e-cash, le processus de vérification rejette explicitement toute signature qui aboutit au point d'infini. donc cette question ne compromet pas la sécurité ou l'intégrité de l'un ou l'autre protocole. Néanmoins, conformément aux mesures prises pour les émissions NYM-01-009 et NYM-01-014, nous avons [implémenté des vérifications supplémentaires] (https://github.com/nymtech/nym/blob/8e05386a0b6f803cca526d12d462db93ac1204cf/common/nym_offline_compact_ecash/src/scheme/aggregation.rs#L121) dans la fonction d'agrégation pour renforcer notre base de code et prévenir tout abus potentiel dans d'autres contextes (https://github. om/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md).

NYM-01-005 WP5 : Pas de vérification de point à débordement révèle le texte en clair pour ElGamal (High)

La mise en œuvre actuelle de Coconut et d'e-cash n'utilise pas le cryptage ElGamal (pas plus qu'il n'a été utilisé lors de la vérification). Au lieu de cela, nous utilisons des engagements de Pedersen plus efficaces, qui ne présentent pas les mêmes risques. Par conséquent, la question liée à ElGamal ne posait aucun risque pour la sécurité dans notre système existant. Nous retirons également la caisse de la noix de coco, et donc le schéma ElGamal.

Derniers mots

Nous tenons à remercier l'équipe de Cure53 pour son expertise et son engagement tout au long de ce processus d'audit. Nous apprécions également la collaboration et le professionnalisme démontrés pendant les phases de planification et d'exécution de l'audit. Notre engagement continu envers la sécurité demeure une priorité absolue, et nous attendons avec impatience de poursuivre nos partenariats avec des experts en sécurité pour maintenir les normes les plus élevées pour notre écosystème.