Audit de sécurité des contrats du mixnet Nym et de vesting

Audit de sécurité du mixnet et des contrats de vesting de Nym

10 min Lire

Introduction

En décembre 2022, Nym a fait l'objet d'un audit de sécurité indépendant mené par [Oak Security] (https://www.oaksecurity.io/), une firme allemande de conseil en cybersécurité spécialisée dans l’audit des blockchains de troisième génération et des protocoles décentralisés. Avec une vaste expérience dans des écosystèmes tels que Cosmos, Terra, Polkadot et Flow, Oak Security a été chargé d'évaluer deux composants critiques de l'écosystème Nym : (1) le mixnet Nym et les contrats de vesting (voir rapport complet) et (2) le portefeuille Nym (voir rapport complet). L'audit visait à évaluer la robustesse de ces composants, à identifier les vulnérabilités potentielles et à garantir le respect des meilleures pratiques en matière de développement de code. Pour rendre les choses plus faciles à suivre, nous avons décomposé les résultats pour chaque composant. Vous pouvez consulter le résumé de l'audit du portefeuille Nym ici.

Résumé de l'audit des contrats Nym Mixnet et Vesting par Oak Security

Sur une période de 2 semaines, la vérification a impliqué une équipe de 4 experts. L’équipe Nym a fourni à Oak Security un accès complet au code de base du projet, aux spécifications détaillées du projet et à la documentation d’appui. La portée de l'audit couvrait les contrats/mixnet, les contrats/dépôts d'acquisition et les importations pertinentes de ces contrats pour les contrats de mixnet et d'acquisition de Nym.

Oak Security a examiné le code en profondeur en combinant le code source automatisé et l'analyse des dépendances avec une inspection manuelle ligne par ligne pour découvrir les vulnérabilités de sécurité, évaluer la qualité du code et évaluer la conformité avec les principes de codage sécurisés. Cette approche globale comprenait une analyse approfondie des domaines critiques tels que les vulnérabilités liées à la condition de race, les problèmes de débordement et de débordement. pratiques de gestion des clés, robustesse de la cryptographie, risques de fuite de données, gestion des mots de passe et contrôles d'accès et d'autorisation.

L'objectif de l'audit était d'assurer le bon fonctionnement des protocoles, d'identifier les vulnérabilités exploitables ou les bogues des contrats intelligents, et de recommander des améliorations pour la sécurité et la lisibilité du code.

Vue d'ensemble des constatations

Les contrats mixnet Nym et vesting étaient caractérisés par une grande lisibilité et clarté, avec une couverture de test robuste soutenant leur fiabilité. Dans leur évaluation, les auditeurs ont identifié 19 conclusions, y compris 9 vulnérabilités de sécurité – comprenant des problèmes critiques et de gravité majeure – et 10 faiblesses générales classées comme mineures ou informatives.

L'équipe Nym a rapidement résolu tous les problèmes critiques et majeurs. L'équipe de sécurité Oak a vérifié et approuvé nos corrections.

NYM-MIX-VEST-CONTRACT-1 : L'exécution d'un événement d'époque ou d'intervalle échouée bloque définitivement l'avancement de l'époque (Critique)

L'audit a identifié une vulnérabilité dans le traitement des messages AdvanceCurrentEpoch dans les contracts/mixnet/src/interval/transactions.rs. Une boucle séquentielle traite tous les événements en attente directement dans le contexte de la transaction, ce qui signifie qu'un seul événement échoué pourrait annuler toute la transaction, empêchant effectivement l'avancement de l'époque et de l'intervalle et faisant en sorte que le protocole se bloque.

Pour y remédier, les auditeurs ont recommandé d'emballer l'exécution des événements dans des sous-messages avec une politique de réponse. Cette approche permettrait au système de gérer les pannes de manière élégante sans revenir sur l'ensemble de la transaction. Cependant, nous avons délibérément choisi de ne pas suivre cette recommandation. Une défaillance lors de l'exécution de l'événement indique un défaut logique significatif qui pourrait compromettre le mécanisme de récompense, il est donc préférable d'arrêter l'avancement de l'époque pour une inspection manuelle plutôt que de risquer d'opérer dans un état corrompu. Au lieu de cela, nous avons implémenté une surveillance améliorée dans l'API Nym pour détecter et nous alerter des avancements échoués. Cette approche garantit que de tels échecs sont rapidement signalés, permettant une intervention rapide pour résoudre les problèmes.

NYM-MIX-VEST-CONTRACT-2 : Les attaquants peuvent forcer des nœuds de mélange orphelins à rejoindre une famille sans leur consentement pour agréger une grande quantité d'entre eux dans la même couche (Critique)

Une vulnérabilité a été identifiée dans le message JoinFamilyOnBehalf, ce qui pourrait permettre à un attaquant d'ajouter un nœud mix à une famille sans son consentement. En créant une famille malveillante et en utilisant la clé d'identité du nœud de mélange de la victime signée avec sa clé privée comme signature, l'attaquant pourrait piéger le nœud de mélange dans la famille. Cela pourrait potentiellement permettre à un attaquant de regrouper des nœuds de mix orphelins en une seule famille, perturbant le réseau en concentrant les nœuds dans la même couche et en augmentant les chances de l'attaquant d'influencer le routage.

Pour remédier à la vulnérabilité dans le message JoinFamilyOnBehalf, le mécanisme de signature du contrat a été redesigné. Au lieu de simplement signer l'identité du nœud de mélange, les signatures ont été mises à jour pour inclure un message avec une intention claire et un nonce unique. Ce changement garantit que les signatures ne peuvent pas être réutilisées ou rejouées.

NYM-MIX-VEST-CONTRACT-3 : Une itération illimitée dans le traitement du message TrackUndelegation pourrait empêcher l'utilisateur de déléguer, ce qui inhibe également de manière permanente l'avancement de l'époque (Critique)

L'itération illimitée du message TrackUndelegation pourrait causer une exhaustion du gas lors du traitement de comptes avec de nombreuses délégations, empêchant les utilisateurs de ne plus déléguer. Cet échec mettrait également fin à l’avancement de l’époque, laissant le protocole coincé dans son état actuel.

Pour résoudre le problème, nous avons mis en place une limite de 25 délégations de droits par compte. Cette solution était fondée sur le plus grand nombre de délégations en période d’acquisition observé à ce moment-là.

Mise à jour : À partir de 2024, l'option de faire des délégations de droits est complètement désactivée.

NYM-MIX-VEST-CONTRACT-4 : Un attaquant peut devancer les messages BondMixnodeOnBehalf et CreateFamilyOnBehalf et modifier leur charge utile (Critique)

Cette vulnérabilité permettrait à un attaquant de devancer les messages BondMixNodeOnBehalf et CreateFamilyOnBehalf, d'extraire la signature et de modifier la charge utile. Dans le cas de BondMixNodeOnBehalf, l'attaquant pourrait également se faire passer pour le proxy, obtenant ainsi un contrôle total sur le lien enregistré.

Pour remédier à la vulnérabilité, nous avons mis en œuvre une solution à deux volets. Tout d'abord, nous avons appliqué les modifications de création de signature décrites dans NYM-MIX-VEST-CONTRACT-2, ce qui a ajouté une intention claire et un nonce unique. Deuxièmement, nous avons restreint l'adresse du proxy légal au compte de vesting, garantissant que les attaquants ne peuvent pas se désigner comme proxy et obtenir un contrôle non autorisé sur les obligations enregistrées.

Mise à jour : À partir de 2024, toutes les opérations de proxy sont désactivées, rendant l'attaque inapplicable.

NYM-MIX-VEST-CONTRACT-5 : les signatures peuvent être rejouées dans les transactions « en nom» pour usurper l'identité des utilisateurs (Critique)

Cette vulnérabilité permet aux signatures d'être rejouées dans les transactions « au nom de », permettant aux attaquants d'usurper l'identité des utilisateurs. Puisque les signatures n'incluent que des données brutes sans métadonnées supplémentaires comme des nonces ou des identifiants de message, un attaquant pourrait réutiliser une signature d'un message pour un autre afin de retirer de force des membres de la famille. De plus, les attaquants peuvent réutiliser des signatures pour le même type de message, permettant à un membre de rejoindre une famille plusieurs fois en utilisant la même signature.

La solution à ce problème reflète celle mise en œuvre dans NYM-MIX-VEST-CONTRACT-4.

NYM-MIX-VEST-CONTRACT-6 : La génération de clés pour les paires (propriétaire, proxy) pourrait entraîner des collisions (Critique)

Cette vulnérabilité permettrait à deux paires d'adresses différentes (propriétaire, proxy) de générer le même résultat XOR dans la fonction generate_owner_storage_subkey, ce qui pourrait entraîner des collisions de clés et des écrasements de données.

La solution de restreindre le proxy légal uniquement à l'adresse du contrat de consolidation, qui a été appliquée dans le NYM-MIX-VEST-CONTRACT-4, résout également cette vulnérabilité. En veillant à ce que l'opération XOR soit toujours effectuée contre une chaîne constante, ce changement élimine effectivement le risque de collisions.

NYM-MIX-VEST-CONTRACT-7 : track_delegation peut écraser la délégation existante si plus d'une est traitée dans le même bloc (Critique)

Ce problème permettrait des collisions clés si plusieurs délégations sont faites dans le même bloc, provoquant potentiellement la substitution de la fonction save_delegation par une délégation existante, entraînant la perte de la délégation précédente.

Pour résoudre le problème, nous avons modifié la logique de la fonction save_delegation pour d'abord lire le montant de delegation existant avant de sauvegarder le nouveau. Si une délégation existe déjà pour la même clé, nous récupérons le montant actuel, ajoutons la nouvelle délégation, puis enregistrons le total mis à jour, en veillant à ce qu'aucune délégation existante ne soit écrasée.

NYM-MIX-VEST-CONTRACT-8 : Le propriétaire d’obligations n’est pas en mesure d’effectuer des opérations si le cautionnement est créé « pour le compte » par un mandataire (major)

Ce problème empêcherait le propriétaire de l'obligation d'effectuer des opérations sur son obligation si l'obligation a été créée "au nom de" et que la transaction actuelle est initiée par le propriétaire au lieu de l'agent. Étant donné que le proxy pourrait être compromis ou perdu, et qu'il n'y a aucun moyen pour le propriétaire de le modifier, ceci pourrait entraîner la perte du contrôle du propriétaire sur son obligation.

Nous ne considérons pas cela comme un problème, car c'est un comportement intentionnel par conception. Lorsque qu'un nœud de mixage est lié (ou des délégations sont effectuées) par le biais du contrat de vesting, toutes les interactions ultérieures avec la caution ou la délégation doivent se faire uniquement via le contrat de vesting.

Mise à jour: À partir de 2024, le contrat d’acquisition est supprimé.

NYM-MIX-VEST-CONTRACT-9 : L'exécution des messages de la famille LeaveFamilyOnBehalf pourrait échouer si une quantité significative de nœuds de mélange sont membres d'une famille (Major)

Ce problème entraînerait l'échec des messages de LeaveFamily et LeaveFamilyOnBehalf en raison de l'épuisement de gaz lors de l'itération d'un grand nombre de membres de la famille sur la carte MEMBERS. Cela empêcherait les nœuds mixtes de quitter une famille, les verrouillant ainsi dans leur famille actuelle.

Solution : La solution impliquait de retravailler la logique pour accéder directement à la carte des MEMBRES et vérifier l'appartenance d'un nœud mixte. Ce changement a supprimé le besoin d'itération, ce qui pourrait entraîner des erreurs de manque de gaz, et a assuré que les membres peuvent quitter une famille avec succès, même lorsqu'il y a de nombreux membres dans la famille.

Mise à jour : À partir de 2024, les familles de nœuds sont supprimées.

Derniers mots.

Nous tenons à remercier l'équipe d'Oak Security 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.

Partager