Les hackers reviennent aux "premiers principes", la crise de Curve n'est pas une attaque ordinaire

Auteur original : Jaleel, BlockBeats

Éditeur original : Jack, BlockBeats

L'industrie DeFi a été plongée dans le chaos à la suite d'un incident d'exploitation de vulnérabilité. Curve Finance, un géant de l'industrie DeFi, est devenu la cible d'une "attaque" sérieuse, et plusieurs pools de pièces stables tels que alETH/msETH/pETH sont menacés. Selon des statistiques incomplètes, l'événement d'exploit de vulnérabilité a causé une perte totale de 52 millions de dollars américains dans les pools Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis et CRV/ETH, et la confiance de l'ensemble du marché a été sérieusement ébranlée.

Les verrous de rentrée des versions 0.2.15, 0.2.16 et 0.3.0 de Vyper ne sont pas valides et l'interface d'installation du document officiel de Vyper recommande une mauvaise version. D'autres parties du projet utilisant le compilateur Vyper se sont également précipitées pour procéder à un auto-examen, essayant de s'assurer qu'elles ne deviendront pas la prochaine victime. Au fur et à mesure que la source de l'incident d'exploitation de vulnérabilité est révélée, le marché réalise progressivement que cette crise ne signifie pas seulement un incident d'exploitation de pirate informatique ordinaire, mais révèle également le risque potentiel énorme de l'ensemble de la pile sous-jacente pour l'ensemble de l'industrie DeFi.

Par rapport au passé, le nombre d'incidents de piratage au cours de la période précédente est devenu de moins en moins important, ce qui est indissociable de la prospérité du marché. Au cours de l'été DeFi et de l'été NFT, de nouveaux accords d'un milliard de dollars ont été lancés chaque semaine, par rapport au marché actuel qui se rétrécit beaucoup. Dans le même temps, les opportunités de marché pour les pirates de trouver des exploits ou de créer des attaques à grande échelle se réduisent progressivement, ce qui signifie que les pirates ont besoin de nouveaux points d'entrée inexploités à explorer.

Les pirates qui reviennent aux "premiers principes" ont trouvé un point d'entrée parfait sur le compilateur de niveau inférieur pour manger l'énorme et délicieux "gâteau" du marché DeFi. Le compilateur de niveau inférieur est devenu un pirate plus "intelligent". Choix. BlockBeats a interviewé le développeur de contrats intelligents Box (@BoxMrChen) et le chercheur BTX Derek (@begas_btxcap) à propos de cet incident et des problèmes connexes qu'il a révélés.

Comment l'événement Curve se produit-il ?

Stani (@StaniKulechov), le fondateur d'Aave et de Lens, a exprimé son point de vue sur l'incident sur les réseaux sociaux : "C'est un revers malheureux pour Curve et DeFi. Bien que DeFi soit un espace ouvert qui peut contribuer, il doit être absolument correct. "C'est difficile et les enjeux sont élevés. Dans le cas de Curve, ils ont réussi au niveau du protocole. "

L'exploit subi par Curve est l'une des formes d'attaque les plus anciennes et peut-être la plus courante contre les contrats intelligents Ethereum, l'attaque par réentrance. Les attaques de réentrance permettent à un attaquant d'appeler à plusieurs reprises une fonction d'un contrat intelligent sans attendre la fin de l'appel précédent à cette fonction. De cette façon, ils peuvent continuer à utiliser l'échappatoire pour retirer des fonds jusqu'à ce que le contrat de la victime soit à court de fonds.

Serrure rentrante et principe CEI

Donnez un exemple simple pour illustrer les attaques de rentrée : une banque dispose d'un total de 100 000 espèces. Mais cette banque a une grosse faille, chaque fois que les gens retirent de l'argent, le personnel de la banque ne met pas à jour le solde du compte immédiatement, mais attend jusqu'à la fin de la journée pour vérifier et mettre à jour. À ce moment-là, quelqu'un a découvert cette lacune. Il a ouvert un compte à la banque, a d'abord déposé 1 000 yuans, puis a retiré 1 000 yuans, puis a retiré 1 000 yuans après 5 minutes. Étant donné que la banque ne met pas à jour le solde en temps réel, le système pensera que son compte a encore 1 000 yuans avant de vérifier et de mettre à jour. Grâce à des opérations répétées, l'utilisateur a finalement retiré tout l'argent comptant de 100 000 $ US à la banque. Ce n'est qu'en fin de compte que la banque a découvert que la faille avait été exploitée.

La complexité de l'attaque par réentrance réside dans le fait qu'elle tire parti de l'appel mutuel entre les contrats et des failles logiques du contrat lui-même, et réalise un comportement frauduleux en déclenchant délibérément des exceptions et des fonctions de restauration. Les attaquants peuvent exploiter à plusieurs reprises les failles logiques du contrat pour voler des fonds. La solution pour empêcher les attaques de rentrée est également très courante.Un contenu de code spécial ciblé est défini à l'avance pour la protection, et un tel mécanisme de protection est utilisé pour assurer la sécurité des fonds.C'est ce qu'on appelle un verrou de rentrée.

Solidity définit un "principe CEI" (Check Effects Interactions) pour la programmation de contrats intelligents, qui peut bien protéger les fonctions contre les attaques de réentrance. Le contenu des principes CEI comprend :

1. L'ordre d'invocation des composants fonctionnels doit être : premièrement, l'inspection, deuxièmement, l'impact sur les variables d'état et enfin, l'interaction avec des entités externes.

2. Avant d'interagir avec des entités externes, toutes les variables d'état doivent être mises à jour. C'est ce qu'on appelle la "comptabilité optimiste", où les effets sont écrits avant que l'interaction ne se produise réellement.

3. Des vérifications doivent être effectuées au début de la fonction pour s'assurer que l'entité appelante a l'autorisation d'appeler la fonction.

4. Les variables d'état doivent être mises à jour avant tout appel externe pour empêcher les attaques de réentrance.

5. Même les entités externes de confiance doivent suivre le modèle CEI car elles peuvent transférer le flux de contrôle à des tiers malveillants.

Selon la documentation, les principes CEI permettent de limiter la surface d'attaque d'un contrat, notamment en prévenant les attaques par réentrance. Les principes CEI peuvent être facilement appliqués, principalement dans l'ordre des codes de fonction, sans changer aucune logique. L'exploit bien connu de The DAO, qui a conduit au fork d'Ethereum, a également ignoré le "principe CEI", et l'attaquant a réalisé une attaque de rentrée, provoquant des conséquences dévastatrices.

Mais le pool Curve qui a été attaqué n'a pas suivi ce principe CEI car Curve a utilisé le compilateur Vyper. En tant que vulnérabilité du code Vyper du compilateur, le verrou de réentrance échoue, ce qui permet à l'attaque de réentrance du pirate de se réaliser avec succès.

La plupart des gens connaissent Solidity, mais Solidity n'est pas le seul langage pour créer des contrats intelligents.L'alternative populaire à Solidity est Vyper. Bien que Vyper ne soit pas aussi puissant et populaire que Solidity, il est idéal pour les développeurs familiarisés avec Python, car Vyper peut traduire du code de type Python dans le langage de programmation de contrat intelligent Ethereum.

Selon les informations de github, le développeur qui contribue le premier à la base de code github de Vyper est également le développeur de Curve. Il n'est pas difficile d'expliquer pourquoi Curve utilise Vyper au lieu de Solidity.

![Les hackers reviennent aux "premiers principes", la crise de Curve n'est pas une attaque ordinaire] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-a62a0336fd-dd1a6f-1c6801)

Pourquoi le verrou de réentrance Vyper échoue-t-il ?

Alors dans cette attaque, quel est le problème avec Vyper ? Pourquoi le verrou de rentrée échoue-t-il ? Est-ce parce qu'il n'y a pas de tests ? BlockBeats a interviewé le développeur de contrats intelligents Box 826.eth (@BoxMrChen), selon lui, le verrou réentrant Vyper a été testé avec des cas d'utilisation. Mais la raison de l'échec est que le cas de test est orienté résultat, c'est-à-dire que le cas de test est également erroné.

En bref, la principale raison pour laquelle le verrou de réentrance Vyper échoue est que la personne qui a écrit le cas de test a écrit le cas de test en fonction du résultat, sans se demander pourquoi l'emplacement sauterait 1 inexplicablement.

![Les hackers reviennent aux "premiers principes", la crise de Curve n'est pas une attaque ordinaire] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-bc03f536dd-dd1a6f-1c6801)

Dans les paragraphes suivants du code Vyper partagé par Box, le problème est clairement visible. Lorsque le nom du verrou apparaît pour la deuxième fois, le numéro de storage_slot sera écrasé, c'est-à-dire qu'en ret, le slot pour la première acquisition du verrou est 0, mais après qu'une fonction utilise à nouveau le verrou, le emplacement pour la serrure est ajouté un. Après la compilation, le mauvais emplacement est utilisé, ce qui empêche le verrou réentrant de prendre effet.

![Les hackers reviennent aux "premiers principes", la crise de Curve n'est pas une attaque ordinaire] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-dfdeb7079d-dd1a6f-1c6801)

La gauche est le code attaqué, et la droite est le code réparé

"Des résultats de test erronés sont attendus, et bien sûr aucune erreur ne peut être vérifiée. Pour donner un exemple simple, nous faisons maintenant un problème de calcul, 1+ 1 = 2, mais la réponse standard donnée est fausse, en disant 1+ 1 = 3 Et ceci Le camarade de classe qui posait la question a donné la mauvaise réponse et a répondu 1 + 1 = 3, mais c'était la même chose que la réponse standard donnée à l'avance, donc le programme n'avait naturellement aucun moyen de déterminer que le résultat du test était faux", a déclaré Box dans une interview avec BlockBeats.

Pendaison pendant deux ans "Épée de Damoclès"

Dans le premier incident d'attaque de réentrance enregistré dans l'histoire, les attaquants de WETH Attack sont exactement les pirates blancs qui créent intentionnellement des attaques afin que les développeurs prêtent attention aux attaques de réentrance, dans le but de rendre plus de projets immunisés contre la possibilité d'attaques de réentrance. Dans le contexte des contrats intelligents, les développeurs doivent utiliser différents mécanismes de déclenchement, tels que l'appel d'une fonction de changement d'état pour obtenir une protection. Cela oblige les développeurs à tenir pleinement compte des scénarios d'attaque possibles lors de la conception des contrats et à prendre les précautions appropriées.

Afin d'acquérir une compréhension approfondie de l'éditeur Vyper, BlockBeats a interviewé le chercheur BTX Derek (@begas_btxcap), il a déclaré que pour les développeurs familiers avec Python, Vyper est un choix plus idéal que Solidity, avec une interface utilisateur plus confortable. et un apprentissage plus rapide. Mais apparemment, certaines versions du code de l'éditeur Vyper n'ont pas été auditées par un tiers fiable. Même certains travaux d'audit peuvent être effectués par les développeurs eux-mêmes. "Ce genre de chose ne se produira pas dans l'industrie informatique traditionnelle, car après la sortie d'un nouveau langage, il y aura d'innombrables sociétés d'audit à la recherche de vos failles."

Sans oublier, permettant à un bogue d'exister ouvertement pendant deux ans.

Fubuloubu, contributeur de Vyper, a également déclaré : Le compilateur n'est pas aussi révisé ou audité que tout le monde le pense. La plupart des compilateurs ont des changements importants et fréquents, ce qui fait de l'audit un inconvénient. Même avec un audit complet de la base de code, il deviendra obsolète au fur et à mesure que de nouvelles versions seront ajoutées. L'audit du compilateur n'est pas une bonne idée, car il est plus logique d'auditer le produit final (c'est-à-dire le code EVM brut) produit par l'utilisateur final à l'aide de l'outil.

Tout cela pointe vers un dernier problème : la motivation. Cela dit, personne n'est incité à trouver des bogues critiques dans les compilateurs, en particulier les anciennes versions. fubuloubu avait précédemment fait une proposition qui aiderait à améliorer Vyper en ajoutant un programme de primes coparrainé par les utilisateurs, mais cela n'a pas abouti.

Les hackers reviennent aux "premiers principes"

Il s'agit d'un autre exemple vivant de pratiques de développement sécurisées pour les développeurs de protocoles et de projets. Mais surtout, l'incident de Curve nous a tous avertis que la sécurité du compilateur sous-jacent a été sérieusement ignorée, et les pirates qui sont revenus aux "principes premiers" en ont trouvé un parfait sur le compilateur inférieur coupé à l'entrée.

Par la suite, Stani (@StaniKulechov), le fondateur d'Aave et de Lens, a également posté un long article sur les réseaux sociaux pour exprimer son ressenti : L'attaque de Curve signifie que le risque de DeFi a toujours impliqué toute la pile sous-jacente, langage de programmation, EVM , etc. Cela nous avertit d'être plus prudents et sensibles, en particulier lors de l'utilisation future d'EVM et de chaînes d'applications personnalisées.

![Les hackers reviennent aux "premiers principes", la crise de Curve n'est pas une attaque ordinaire] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-f4018e7eac-dd1a6f-1c6801)

Attaques d'un niveau inférieur

Pour les vulnérabilités du compilateur, il est difficile de le découvrir uniquement en auditant la logique du code source du contrat. Le simple fait de rechercher les différences entre les versions et les versions est également un gros projet. Il est nécessaire de combiner des versions spécifiques du compilateur avec des modèles de code spécifiques pour déterminer si les contrats intelligents sont affectés par les vulnérabilités du compilateur.

"Actuellement, seuls deux compilateurs sont les meilleurs, la base de code de Vyper est plus petite, plus facile à lire et a moins de changements pour analyser son historique, ce qui explique probablement pourquoi les pirates commencent ici, la base de code de Solidity est un peu plus grande "fubuloubu soupçonne même cet état- des pirates informatiques soutenus peuvent être impliqués dans cette attaque Curve : "Il faudra des semaines, voire des mois, pour trouver la vulnérabilité, et compte tenu des ressources investies, elle peut être réalisée par un petit groupe ou une équipe."

En tant que langage de compilation le plus utilisé dans l'industrie du cryptage, la sécurité de Solidity est encore plus préoccupante pour les utilisateurs.Après tout, si le compilateur Solidity a le problème de l'échec du verrouillage de rentrée cette fois, alors l'histoire de toute l'industrie DeFi peut avoir à réécrire.

Selon les alertes de sécurité émises régulièrement par l'équipe de développement de Solidity, il y a eu des failles de sécurité dans de nombreuses versions différentes du compilateur Solidity.

Le bogue du compilateur le plus récent enregistré remonte au 26 juin, lors d'une enquête sur un rapport de sécurité lié à l'utilisation d'abi. L'ancien générateur de code n'évaluait pas les expressions complexes telles que les affectations, les appels de fonction ou les conditions dont .selector était en cours d'accès. Cela provoque des effets secondaires lorsque ces expressions ne sont pas exécutées, de sorte que les contrats compilés avec l'ancien pipeline peuvent se comporter de manière incorrecte.

Nous pouvons également voir un fichier dans le référentiel Github de Solidity qui répertorie certains bogues connus liés à la sécurité sur le compilateur Solidity. La liste remonte à la version 0.3.0, les bugs qui n'existaient qu'avant cette version ne sont pas listés. Ici, il y a un autre fichier bugs_by_version.json. Ce fichier peut être utilisé pour interroger les bogues par lesquels une version particulière du compilateur est affectée.

Heureusement, c'est précisément à cause de la large application du langage Solidity et de l'assistance de la Fondation Ethereum que de nombreux problèmes existants ont été signalés par des projets et des protocoles au cours du processus de déploiement. Par conséquent, Solidity a terminé la modification et l'amélioration quelques étapes plus rapidement que Vyper. De ce point de vue, c'est l'une des raisons pour lesquelles Solidity est plus standardisé et plus sûr.

Pour aider les développeurs de Solidity à mieux tester et éviter que la même chose ne se produise. Le co-fondateur d'UnitasProtocol, SunSec (@ 1 nf 0 s 3 cpt) a publié un guide de test de sécurité DeFiVulnLabs Solidity après l'attaque Curve, prenant en charge 47 types de vulnérabilités, y compris les descriptions de vulnérabilité, les scénarios, les défenses, les codes de vulnérabilité et les mesures d'atténuation et comment tester .

Comment éviter au maximum les attaques de bas niveau ?

Dans cet incident Curve, Box estime que l'illumination pour tous les développeurs est la suivante : n'essayez pas de suivre la tendance technologique et de choisir des solutions immatures ; n'approuvez pas votre propre code sans écrire des cas de test (plusieurs versions de Vyper qui ont des problèmes Même le les cas de test sont faux ); n'approuvez jamais votre propre code vous-même ; certaines fortunes peuvent prendre des années à être découvertes ; la non-évolutivité est de l'arrogance envers vous-même et du mépris envers les autres.

Habituellement, les développeurs ne pensent à aucun piège ici et choisissent une version à compiler à volonté, ce qui peut ignorer les risques induits par les différences entre les versions. Même des mises à niveau de version mineures peuvent introduire des changements de rupture, ce qui est particulièrement important lors du développement d'applications décentralisées.

Les avertissements aux développeurs de cet événement Curve sont : utilisez une version plus récente du langage du compilateur. Il est important de maintenir à jour votre base de code, vos applications et votre système d'exploitation, et de construire vos propres défenses de sécurité dans tous les aspects. Il y a généralement moins de problèmes de sécurité connus que les anciennes versions, bien que les versions plus récentes puissent introduire de nouveaux problèmes de sécurité. Bien sûr, nous devons également prêter attention aux annonces de mise à jour de la communauté et de la version officielle à temps. Comprenez les changements apportés par chaque version et mettez à jour votre propre base de code et votre environnement d'exploitation si nécessaire. Prendre ces mesures peut réduire considérablement les incidents de sécurité causés par les bogues du compilateur.

De plus, des cas de tests unitaires pour compléter le code. La plupart des erreurs au niveau du compilateur entraîneront des résultats d'exécution de code incohérents, qui sont difficiles à trouver uniquement par le biais de la révision du code, mais peuvent être exposés lors des tests. L'amélioration de la couverture du code peut aider à éviter de tels problèmes. Et essayez d'éviter d'utiliser des fonctionnalités de langage complexes telles que l'assemblage en ligne et l'encodage et le décodage de tableaux multidimensionnels, sauf en cas de besoin évident. La plupart des vulnérabilités du langage Solidity ont historiquement été liées à ces fonctionnalités avancées. Les développeurs doivent éviter d'utiliser des fonctionnalités de langage expérimentales dans le but de se montrer sans besoin spécifique.

Pour la couche de protocole et le personnel de sécurité, les risques possibles de la version du compilateur ne peuvent être ignorés lors de la réalisation d'audits de code. Il est prévisible que les pirates ont ouvert de nouvelles idées, et à l'avenir, il y aura de plus en plus d'incidents d'exploitation de vulnérabilités de niveau inférieur. Dans le même temps, l'infrastructure sous-jacente, la pile sous-jacente, le langage de programmation, l'EVM, etc. doivent être audités. À l'avenir, le marché des sociétés d'audit deviendra de plus en plus grand, et le marché des primes d'invités blancs deviendra également de plus en plus grand. L'équipe Vyper prévoit également de commencer à revoir le programme de primes de bogues une fois que l'affaire sera officiellement réglée.

Bien sûr, nous n'avons pas besoin de paniquer trop sur les risques de l'infrastructure sous-jacente. À l'heure actuelle, la plupart des bogues du compilateur ne sont déclenchés que dans des modèles de code spécifiques, et l'impact réel doit être évalué en fonction de la situation du projet. La mise à jour régulière de la version du compilateur et des tests unitaires adéquats peuvent aider à prévenir les risques.

Contenu de référence :