Comment juger si un soi-disant « HACK » qui est arrivé à un projet de crypto ou de blockchain est légitime ou s'il s'agit simplement d'un mécanisme pour cacher un RUG ?

Republié par Platon

Suiveurs: 0

De toute évidence, après ce qui s'est passé avec MtGox ou QuadrigaCX ou des cas similaires où les fondateurs ont affirmé avoir perdu les clés privées détenant la majorité des actifs numériques de leurs échanges en disparaissant ou retrouvés morts plus tard, les gens de la sphère crypto sont de plus en plus méfiants lorsqu'ils entendent parler d'un pirater un projet, et la première pensée qui vient à l'esprit est que les fondateurs ont pratiquement vidé le fonds et se sont enfuis avec, c'est ce qu'on appelle communément un RUG.

Cela a probablement été le cas dans de nombreux projets, mais pas nécessairement dans tous, donc aujourd'hui, nous examinons un cas que nous pensons être un véritable hack en raison de la nature de la situation.

Nous pensons que c'est un cas intéressant à analyser car il aidera à mieux comprendre l'importance de la sécurité et des audits dans les projets liés aux contrats intelligents ou à la blockchain en général.

Nous analyserons objectivement le drame qui est arrivé au projet RING Financial, un token lancé sur la BSC (Binance Blockchain).

Avant d'en venir au hack, nous allons d'abord résumer le projet et sa situation devant lui :

RING Financial avant le piratage

RING Financial était un projet DeFi dans le but de rendre le DeFi plus accessible à la communauté DeFi et crypto. Un projet ambitieux qui voulait créer un protocole de production de nœuds qui serait régi par les détenteurs de nœuds et allouer des liquidités dans plus de 300 protocoles à la fois. L'objectif était d'avoir accès à tous les protocoles via un nœud RING et via le RING Dapp.

Ces protocoles ont été vérifiés par l'équipe, puis la communauté voterait sur eux où allouer. Le même concept de vote que vous auriez dans un DAO qui rendait RING assez attrayant.

RING Financial a également simplifié une grande partie du processus de recherche et du processus de déploiement pour un seul détenteur de nœud. Un Dapp pour accéder à tous les autres Dapps, vous n'aurez donc besoin que d'une seule interface au lieu de 300 différentes avec leurs propres accès et leurs propres nœuds.

Enfin, l'objectif de RING Financial était de réduire les frais de déploiement sur différents protocoles, le volume entraînant une baisse des frais de transaction pour les détenteurs individuels, ce qui était l'un des principaux arguments de vente du projet. Un projet avec du flair et de l'ambition pour rendre les choses plus faciles pour la communauté et encore plus grand public pour ceux qui ne connaissent pas Defi.

Cependant, le flair et l'ambition ne suffisent pas toujours et vous avez besoin d'expertise et de connaissances qui, sur les marchés nouveaux et immatures, sont une perle rare et c'est pourquoi RING Financial n'a pas pu tenir entièrement sa promesse.

Que s'est-il vraiment passé avec RING Financial ? Et pourquoi a-t-il été piraté ? Grâce à la blockchain, nous avons toutes les preuves médico-légales nécessaires pour approfondir cela et voir où se trouvaient les vulnérabilités et pourquoi RING Financial n'était pas une arnaque.

Le RING Financial HACK a eu lieu le 5 décembre 2021 entre 2h01 et 2h06 UTC.

Oui, tout s'est passé littéralement en 5 minutes seulement ! Grâce au scanner blockchain pour ces détails, d'ailleurs, nous vous fournissons juste en dessous les liens des transactions liées au HACK ainsi que l'adresse du contrat pour ceux qui voudront chercher plus en détail.

Voici le résumé expliquant la faille que l'attaquant a exploitée :

Il faut comprendre que le smart-contract de RING Financial était composé de plusieurs parties, une pour le token et toutes les données qui s'y rapportent et une autre pour tout ce qui concerne la comptabilisation des nodes et des récompenses. La partie du jeton avait une sécurité pour que seul l'administrateur du contrat puisse modifier les données importantes de celui-ci, pour vous montrer du code, voici un en-tête d'une fonction du contrat qui est protégé via l'attribut "onlyOwner" qui stipule que la fonction ne peut être exécutée que par l'administrateur :

Une fonction qui n'a pas de seul propriétaire (ou un attribut équivalent pour protéger l'accès de la fonction) peut être exécuté par n'importe qui.

Maintenant, devinez quoi ? Les fonctions de la partie Nœuds et Récompenses n'avaient pas cet attribut, comme vous pouvez le voir en regardant les noms des fonctions ci-dessous (le seul propriétaire l'attribut est manquant) :

Et comme vous pouvez l'imaginer, un pirate a exploité et arnaqué cette faille pour obtenir un nombre exponentiel de récompenses dans RING, puis les a jetées dans le pool de liquidités et l'a vidé presque violemment en quelques minutes. Ainsi, il a perpétré ses escroqueries.

Maintenant, vous vous posez probablement deux questions :

Comment les développeurs ont-ils pu laisser une telle échappatoire ?

Après avoir discuté avec les développeurs de Solidity (langage utilisé pour coder les smart-contracts sur Ethereum), il s'agit d'une erreur liée à l'héritage de rôle entre deux smart-contracts, l'héritage est une notion de langage de programmation et pour ne pas vous causer de maux de tête, nous resterons dans des mots simples : A la base, il est très probable que la personne qui a codé le contrat pensait que les fonctions de la partie Node héritaient des rôles de sécurité des fonctions de la partie Token, mais ce n'est malheureusement pas le cas dans Solidity, et il faut redéfinir les rôles de chaque fonction de chaque contrat, quel que soit leur lien. Donc notre conclusion sur ce point est que le développeur n'était pas un expert et qu'il a probablement publié le contrat SANS prendre le temps de le relire, probablement dans la précipitation.

Comment savez-vous que ce n'est pas le développeur lui-même qui a laissé cette faille exprès et que ce n'était pas une arnaque ?

Très bonne objection et il est facile de supposer une arnaque lorsque vous n'êtes pas sûr de la façon dont contrats intelligents mais il est en fait très facile de présumer de l'innocence du développeur, car il a publié et vérifié publiquement l'intégralité du code du smart-contract sur BSCSCAN.COM (le scanner le plus populaire de la Blockchain Binance), le 19 novembre 2021, qui c'est-à-dire plus de deux semaines avant que le RING Financial HACK ne se produise. Et comme expliqué précédemment, la faille était écrite en NOIR SUR BLANC dans le contrat, et n'importe quel développeur expérimenté l'aurait remarqué et aurait réagi, mais malheureusement, le premier à n'avoir eu aucune pitié. Il est donc évident que le développeur n'était pas au courant de cette faille car il n'aurait pas pris le risque de laisser quiconque tuer le projet RING Financial à tout moment.

Pour en revenir à la suite du RING Financial HACK, le développeur s'est rendu compte de sa gaffe et a simplement gelé le contrat pour arrêter toute distribution de récompenses afin que l'attaquant ne vide pas complètement la cagnotte. Il a ensuite redéployé un contrat Node, cette fois avec l'attribut de sécurité « onlyOwner ». Ce nouveau contrat Node a pu gérer correctement la nouvelle distribution des récompenses, sauf qu'il était trop tard, car à la suite du HACK, toute confiance avait été perdue dans le projet et l'équipe, et la pression de vente a tué et mis fin au jeton et le projet.

Pour conclure, nous avons choisi cette histoire car elle montre deux choses importantes sur les smart-contracts et les projets crypto, ne jamais coder un contrat à la hâte et toujours contacter les cabinets d'audit, car une fois le piratage fait, il est trop tard pour sauver la barque, et Le projet RING Financial en est un bon exemple, ils ont d'ailleurs, selon leur communication, contacté des cabinets d'audit pour ce deuxième contrat Node et ne l'ont pas posté publiquement sur BSCSCAN tant qu'ils n'étaient pas certains de sa sécurité. Mais comme dit précédemment, il était trop tard pour RING Financial, et les dégâts étaient irréversibles.