Web3, bonne hygiène et nécessité d'une sécurité de bout en bout

Avoir un audit de contrat intelligent, c'est un peu comme se laver les mains - ne le faites qu'une seule fois et préparez-vous aux conséquences.

Alors que la conversation autour de la sécurité cryptographique s'échauffe en réponse à une année dévastatrice de pertes dues à la cybercriminalité - Le récent rapport de CertiK note que "2022 devrait être l'année la plus chère jamais enregistrée pour le web3" - il est essentiel de revoir certaines bonnes pratiques de sécurité. Le principal d'entre eux est l'importance d'audits de contrats intelligents approfondis et réguliers .

Trop souvent, les nouveaux projets de blockchain traitent leurs contrôles de sécurité comme quelque chose à éviter avant leur lancement, auquel il ne faut plus jamais penser. Cette attitude désordonnée se voit le plus clairement dans les projets qui n'ont eu qu'un seul audit de contrat intelligent. Les projets qui font cela semblent penser que les audits sont plus à des fins de marketing que de sécurité réelle. S'il est vrai que les investisseurs et les utilisateurs doivent éviter les projets qui n'ont fait l'objet d'aucun audit de contrat intelligent, ils doivent également s'assurer que les projets dans lesquels ils investissent adoptent une approche active et de bout en bout de leur Sécurité.

Vous vous demandez peut-être pourquoi un projet devrait-il avoir besoin d'audits réguliers ? Ne devrait-on pas couvrir le projet dans son intégralité ? ». C'est une idée fausse courante (et coûteuse). Alors que tout bon audit de contrat intelligent devrait fournir une évaluation complète du code sous-jacent d'un projet, il ne peut pas évaluer les modifications ou les mises à jour qui se produisent après l'audit, en particulier chaque fois qu'une modification est apportée au code sous-jacent.

Bien sûr, tout projet technologique qui ne se met jamais à jour deviendra bientôt redondant, et cela est particulièrement vrai dans le monde en évolution rapide du Web3. Tout bon investisseur ou utilisateur technologique sait éviter un projet qui refuse de se mettre à jour et de se développer, mais il investit régulièrement son argent dans des projets qui ne mettent jamais (ou rarement) à jour leur sécurité. Pour revenir à la métaphore de la propreté, c'est comme serrer la main de quelqu'un après avoir dit qu'il ne s'est pas lavé les mains depuis un an.

Prendre le Exploit de Deus Finance par exemple, qui a vu un attaquant drainer près de 16 millions de dollars de fonds. Bien que Deus ait fait auditer ses contrats intelligents, un attaquant a pu cibler un nouveau contrat intelligent non audité avec une attaque de prêt flash sophistiquée. Tout au long de l'attaque, le pirate a pu modifier le prix des jetons DEI de Deus et récolter les bénéfices de cette action de prix prévisible. Ils l'ont fait en manipulant un pool de prêt utilisé par l'oracle - un nœud de code qui interprète les données - qui a dicté le prix du jeton.

Désormais, tout contrat intelligent qui en vaut la peine vous avertirait des dangers de l'utilisation d'un oracle qui détermine un prix en utilisant une paire de négociation, car ceux-ci peuvent être facilement manipulés. Cependant, étant donné que le contrat intelligent vulnérable n'entrait pas dans le cadre de l'audit initial, les auditeurs n'ont pas eu la possibilité de mettre en évidence le problème.

Deus devrait servir d'avertissement clair aux projets qu'ils doivent traiter les audits de contrats intelligents comme une fonctionnalité continue dans leur cadre de sécurité et les faire auditer chaque fois qu'un changement important est apporté au projet. Pourtant, tous les audits ne sont pas égaux. À maintes reprises, nous voyons des projets bien planifiés souffrir des défauts d'un mauvais audit.

Prenez le récent Exploits FEG par exemple. Le jeton de gouvernance hyper-déflationniste FEG (Feed Every Gorilla) a récemment été touché par deux attaques de prêt flash qui ont collectivement drainé 3,2 millions de dollars de fonds du protocole en deux jours.

Dans chaque attaque, le pirate (ou les pirates) a ciblé la même vulnérabilité dans le contrat intelligent de FEG. L'analyse de l'exploit par CertiK a révélé que cela était dû à une faille dans le jeton [[Fonction Swap-To-Swap](https://docs.fegtoken.com/fegex/smartswap#:~:text=Swap%2DTo%2DSwap%20(S2S,trouvé%20in%20the%20next%20section) , qui prend directement le "chemin" d'entrée de l'utilisateur en tant que partie de confiance sans aucun assainissement. En termes simples, cette faille permettait au pirate d'appeler à plusieurs reprises des fonctions qui lui permettaient d'obtenir des allocations illimitées et de vider le contrat de ses actifs.

Le plus frustrant pour FEG est peut-être le fait que cette faille aurait dû être détectée par un audit de contrat intelligent. Même si FEG a fait auditer ses contrats intelligents, les auditeurs auraient dû remarquer que le paramètre de "chemin" non fiable de FEG était passé au protocole et approuvé pour dépenser les actifs du contrat. Tout bon audit signalerait alors cela comme une gravité majeure et conseillerait au projet d'agir et de modifier en conséquence.

Il y a une leçon à tirer ici pour l'industrie de la crypto-sécurité : à mesure que les pirates informatiques continuent de trouver de nouvelles façons ingénieuses d'exploiter des projets, il ne suffit plus aux auditeurs de simplement mettre à jour leurs vérifications en réponse à de nouvelles attaques. Au lieu de cela, ils doivent constamment mettre à jour leur technologie afin que lorsqu'une nouvelle attaque se produit, ils soient prêts à y faire face.

Ces deux exploits soulignent non seulement la nécessité d'audits de contrats intelligents rigoureux et réguliers, mais également la nécessité d'une approche proactive, cohérente et de bout en bout de la sécurité Web3. Cela revient à considérer la sécurité comme quelque chose à construire et à entretenir plutôt qu'une simple étiquette à acheter et à vendre. Cela s'applique aux équipes qui doivent mettre à jour la sécurité de leur projet en tandem avec leur technologie, ainsi qu'aux sociétés d'audit qui doivent anticiper les attaques, plutôt que de simplement y répondre.