La société de sécurité V12 Security a révélé avoir découvert fin avril dernier une vulnérabilité critique dans le protocole d'échange (échanges) THORChain qui a permis à un seul opérateur de nœud de validation de voler des fonds dans les pools de liquidités du protocole. La découverte, même si elle n'implique pas le même échec, a eu lieu quelques semaines avant le piratage de 10 millions de dollars subi par la plateforme le 15 mai.
THORChain aurait appliqué le patch en silencesans communication publique, et a informé l'entreprise que son programme de récompense pour les rapports de vulnérabilité (connu sous le nom de prime aux bogues) était « définitivement à la retraite », comme l’expliquaient les chercheurs de V12 Security le 1er juin.
ZachXBT, le chercheur en chaîne qui avait mis en garde contre le piratage de May, a réagi par une critique directe du protocole : « On pourrait espérer qu'après tous les exploits qu'ils ont eu, la sécurité sera prise plus au sérieux. Cependant, THORChain continue de baisser la barre.
THORChain a arrêté le réseau pendant deux semaines à la suite du piratage du 15 mai, qui impliquait une vulnérabilité différente de celle signalée par V12 Security. L'échec, comme l'explique CriptoNoticias, s'est produit au niveau du GG20 TSS, le schéma cryptographique qui permet aux nœuds du protocole de signer des transactions ensemble.
THORChain a signalé le 27 mai que la version du logiciel nécessaire à la reprise des opérations (v3.19.0) doit terminer les tests avant d'accéder au réseau principal, pas de date confirmée.
Comment le bug a-t-il fonctionné et que pourrait perdre un utilisateur ?
THORChain fonctionne avec des actifs de différents réseaux (bitcoin, ether, entre autres) que les utilisateurs déposent pour effectuer des échanges. Avant d'exécuter un échangerle protocole s'attend à ce que la transaction d'origine atteigne un nombre minimum de confirmations dans sa chaîne : pour le bitcoin, par exemple, 10 blocs. Cette exigence existe pour garantir que le dépôt est irréversible avant de débloquer les fonds du côté de THORChain.
Le bug signalé par V12 Security a permis d'éviter cette exigence. Chaque validateur THORChain signe cryptographiquement son observation d'une transaction externe (une signature d'attestation certifiant que le dépôt a été consulté), mais cette signature ne couvre que les données de base de la transaction, telles que les montants et les adresses. Les champs qui enregistrent si la transaction a atteint les confirmations nécessaires étaient en dehors de la signature et pouvaient être librement modifiés.
Comment s’est déroulée l’attaque ?
Selon le rapport V12 Security, dans THORChain, les validateurs proposent à tour de rôle des blocs avec une rotation prévisible et déterministe.
Dans le cadre de la vulnérabilité trouvée par les chercheurs, un validateur malveillant pourrait, lorsque ce sera son tour, reprendre les observations signées par d'autres nœuds honnêtes sur une transaction non encore confirmée, modifiez les champs d'objectif pour indiquer que la transaction était déjà terminée et injectez-la dans le bloc.
Selon le même rapport, l'étape de validation en bloc ne permettrait pas de vérifier cet objectif, car Je voudrais juste vérifier que les transactions peuvent être lues correctement. Les signatures des validateurs honnêtes seraient toujours valables car les champs modifiés n'en seraient jamais couverts.
Le résultat, selon V12 Security, serait que THORChain exécuterait l'échange immédiatement et libérerait les fonds du pool au profit de l'attaquant, avant que le dépôt initial n'ait atteint les confirmations requises. L’attaquant pourrait alors annuler ce dépôt et prendre les deux côtés de l’échange.
Sécurité V12 a démontré l'attaque dans un environnement de test contrôlé avec quatre validateurs actifs. Dans cette preuve de concept (une démonstration technique vérifiant que la vulnérabilité est réelle et exploitable), une transaction Bitcoin avec une seule confirmation, alors que dix étaient requises, a été traitée comme si elle était complète. Le pool simulé a perdu l'équivalent de plus de 82 milliards d'unités de RUNE (le jeton natif de THORChain).
Selon V12 Security, l'attaque nécessitait de contrôler un seul nœud de validation actif, sans avoir besoin d'accéder aux clés d'autres validateurs ni d'occuper une position particulière dans le réseau.
Un historique de rapports impayés
La société de sécurité QED Audit a informé THORChain en janvier dernier de deux vulnérabilités du protocole alors que le prime aux bogues était toujours actif : un qui aurait permis le vol d'actifs d'une valeur de plus de 40 millions de dollars et un autre qui aurait permis de vider tous les bonus RUNE des validateurs, comme ils l'ont expliqué.
Selon QED Audit, les deux bugs ont été corrigés avant la version 3.15.0, publiée le 29 janvier. mais l'entreprise n'a pas non plus reçu la récompense. « Nous n'allons pas plaider en faveur d'une divulgation ouverte parce que nous pensons que la divulgation responsable doit être séparée des litiges en matière d'indemnisation », a déclaré le cabinet, qui a également publié les détails techniques des décisions.
THORChain n'a publié aucune déclaration publique concernant ces vulnérabilités ou la suppression de son programme de bug bounty. La version du 27 mai rapportait que la bibliothèque cryptographique principale du protocole, tss-lib, avait été temporairement mise en source fermée pour que l'équipe de sécurité interne de THORSec puisse effectuer un audit sans exposer les travaux de correction en cours.
Après avoir subi mi-mai l'exploit qui s'est soldé par une perte de 10 millions de dollars, le protocole d'échange promet une réouverture « sûre et stable » sans date confirmée.