CertiK dissèque l’incident d’Axion Network et la chute des prix qui s’en est suivie

CertiK dissèque l’incident d’Axion Network et la chute des prix qui s’en est suivie

Eos avis crypto

Le 2 novembre, le réseau Axion a lancé son nouveau token, appelé AXN. Le projet a présenté l’actif comme un nouveau véhicule d’investissement, affirmant qu’il serait la blockchain la plus rentable du genre à ce jour. Au cours de la période précédant le largage aérien d’AXN, cinq équipes distinctes auraient examiné le code du jeton; Les chouchous de l’industrie comme CertiK et Hacken étaient parmi ceux qui ont mené les audits.

Quelques heures après l’événement de gratuité du protocole, cependant, il est devenu clair que quelque chose avait mal tourné. Un acteur non autorisé a frappé de manière inattendue 79 milliards d’AXN et les a déchargés sur le marché. Le prix s’est effondré de plus de 99%, rapportant aux attaquants un cool 1300 ETH – d’une valeur estimée à 500K $ au moment de la publication.

Dans les heures qui ont suivi, l’équipe derrière le projet Axion a encouragé les participants à ne pas négocier ou interagir avec l’actif, en déclarant via le canal de télégramme officiel de la plateforme:

“N’achetez pas AXN pour le moment, n’interagissez pas avec le tableau de bord,”

Le compte Twitter du réseau Axion a continué à publier des mises à jour, notamment:

Malgré ces assurances, CertiK fait un pas en avant pour offrir à la communauté une explication plus claire de ce qu’elle estime avoir mal tourné, et un aperçu de la manière dont des attaques similaires pourraient être évitées à l’avenir. Crypto a contacté par e-mail «Jack Durden» qui nous a été décrit comme le PDG du réseau Axion, mais n’a reçu aucune réponse immédiate. Aucun membre de l’équipe n’est répertorié dans le livre blanc du projet ou sur le site Web, et le nom «Jack Durden» est partagé avec le narrateur invisible du film Club de combat.

Notez que le reste de cet article est reproduit mot à mot, avec l’aimable autorisation de CertiK, en tant que service public pour informer les lecteurs sur la compréhension de l’équipe d’audit de ce qui s’est passé. Crypto n’a pas audité le code et les opinions exposées ci-après sont donc exclusivement celles de CertiK.

Rapport du personnel du CertiK sur la chute des prix d’Axion

Le 2 novembre 2020, à environ 11 h 00 + UTC, un pirate informatique a réussi à frapper environ 80 milliards de jetons AXN en utilisant la fonction de mise hors jeu du contrat Axion Staking.

Le pirate a ensuite vidé les jetons sur l’échange AXN Uniswap pour Ether, répétant ce processus jusqu’à ce que l’échange Uniswap soit épuisé et que le prix du jeton soit ramené à 0.

Nous avons été informés de l’incident quelques minutes après l’attaque et nos analystes de sécurité ont commencé à évaluer la situation immédiatement.

Nous avons conclu que l’attaque était probablement planifiée de l’intérieur, impliquant une injection de code malveillant au moment du déploiement du code en modifiant le code des dépendances d’OpenZeppelin.

La fonction exploitée ne faisait pas partie de l’audit que nous avons effectué car elle a été ajoutée après avoir fusionné le code d’Axion avec le code d’OpenZeppelin par «aplatissement» et l’injection dans le code d’OpenZeppelin avant le déploiement.

Planification

Le pirate a utilisé des fonds anonymes obtenus auprès de tornado.cash la veille du piratage, faisant allusion à une attaque pré-méditée. Vraisemblablement pour économiser des fonds en cas d’échec de l’attaque, 2,1 Ether ont été remis en circulation dans tornado.cash juste après que le compte ait reçu les fonds.

Pour finaliser la configuration de l’attaque, le pirate a acheté environ 700000 jetons HEX2T à l’échange Uniswap. Cependant, ces fonds ne faisaient finalement pas partie de l’attaque et ont servi d’écran de fumée sur la façon dont l’attaque s’est déroulée.

Installer

Le pirate a commencé son chemin vers l’activation de son attaque en créant une mise «vide» sur le contrat de Staking du réseau Axion en invoquant la fonction de mise avec un montant de 0 et une durée de mise de 1 jour à environ 09h00 + UTC. Cela a créé une entrée de session pour l’attaquant avec un montant de 0 et une valeur de 0 part à l’ID de session 6.

Ensuite, l’attaquant a pré-approuvé une quantité illimitée d’AXN à l’échange Uniswap en prévision de la réussite de son attaque. En conséquence, ils ont approuvé le contrat NativeSwap d’Axion pour le montant des fonds qu’ils avaient l’intention de convertir en tokens AXN.

Ils ont invoqué la fonction de dépôt du contrat NativeSwap vers 10h00 + UTC, mais le pirate n’a jamais appelé la fonction de retrait du contrat pour réclamer son AXN échangé, comme en témoigne la fonction swapTokenBalanceOf du contrat NativeSwap. Ensuite, ils ont fait un autre appel de fonction de dépôt échoué avant d’exécuter l’attaque.

Exécution

Ces transactions n’étaient que des écrans de fumée sur la manière dont l’attaque de non-participation a été effectivement menée. Les transactions effectuées par l’attaquant n’ayant entraîné aucune modification du mappage sessionDataOf, nous avons conclu qu’il s’agissait d’une attaque multi-adresse.

Nous avons étudié le code source du contrat dans le référentiel GitHub qui avait été partagé avec nous pour identifier une faille susceptible d’affecter le mappage sessionDataOf.

Nous n’avons pas été en mesure de détecter des affectations à lui ou à des membres en dehors des fonctions de pieu, ce qui nous a amenés à nous demander si le déploiement des contrats s’est déroulé correctement.

Vecteur d’attaque

Après avoir analysé le code source du contrat de Staking déployé, nous avons identifié une injection de code dans la bibliothèque AccessControl OpenZeppelin entre L665-L671 du code source déployé du contrat de Staking. La fonction checkRole liée ne fait pas partie de l’implémentation d’OpenZeppelin v3.0.1, qui a été répertoriée comme dépendance dans le référentiel GitHub du projet.

Dans la fonction checkRole, le bloc d’assemblage suivant existe:

Cette fonction particulière permet à une adresse spécifique d’effectuer une écriture arbitraire dans le contrat en fonction des variables d’entrée qu’elle complète via des appels de bas niveau. Annoté, le bloc d’assemblage ressemblerait à ceci:

Cette fonction a été injecté lors du déploiement car il n’existe pas dans l’implémentation OpenZeppelin AccessControl, ce qui signifie que les membres du réseau Axion qui étaient impliqués dans le déploiement du jeton ont agi de manière malveillante.

Conclusion

L’attaque a utilisé du code qui a été délibérément injecté avant le déploiement du protocole. Cet incident n’a aucun rapport avec les audits menés par CertiK et la partie responsable de l’attaque était une personne qui semblait être impliquée dans le déploiement des contrats Axion Network.

Pour un degré supplémentaire de sécurité, les rapports d’audit doivent être normalisés pour inclure les adresses de contrat intelligent déployées dont le code source a été vérifié comme étant le même que celui qui a été audité.

L’Oracle de sécurité sert de relais en chaîne des renseignements de sécurité, effectuant des contrôles de sécurité qui incluent la vérification des contrats intelligents déployés pour correspondre aux versions auditées.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *