Finance décentralisée sécurité: vulnérabilités de sécurité courantes et mesures préventives

Récemment, un expert en sécurité a partagé des contenus liés à la sécurité de la Finance décentralisée, a passé en revue les événements de sécurité majeurs dans l'industrie Web3 au cours de l'année passée, a exploré les raisons de ces événements et comment les éviter, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures préventives, et a donné quelques conseils de sécurité aux projets et aux utilisateurs.

Les types de vulnérabilités DeFi courants incluent généralement les prêts flash, la manipulation des prix, les problèmes d'autorisation des fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités de logique métier, les fuites de clés privées et les attaques par réinjection. Cet article se concentre sur ces trois types : les prêts flash, la manipulation des prix et les attaques par réinjection.

Prêt flash

Les prêts flash sont une innovation de la Finance décentralisée, mais lorsqu'ils sont exploités par des hackers, ils peuvent emprunter de l'argent sans aucun coût, rembourser après avoir exécuté l'ensemble du processus d'arbitrage, et le reste constitue le profit d'arbitrage. Ils n'ont besoin de payer qu'un faible montant de frais de Gas pour réaliser d'énormes bénéfices.

Les attaques courantes sont souvent accompagnées de prêts flash. Les attaquants aiment emprunter d'énormes sommes d'argent via des prêts flash pour manipuler les prix et attaquer la logique commerciale, etc. Les développeurs doivent considérer si les fonctions du contrat peuvent être anormales en raison de l'énorme montant de fonds ou si de grosses sommes peuvent interagir avec plusieurs fonctions du contrat en une seule transaction pour obtenir des récompenses dans ces scénarios.

On peut souvent voir que certaines valeurs de quantité de Token dans les contrats sont utilisées pour calculer des récompenses, ou que la quantité de Token dans les paires de trading DEX participe à divers calculs. Étant donné que les développeurs n'ont pas pris en compte que des attaquants peuvent manipuler ces variables en utilisant des prêts instantanés, cela a conduit au vol de fonds dans les contrats.

Au cours des deux dernières années, les prêts flash ont rencontré de nombreux problèmes. De nombreux projets de Finance décentralisée semblent offrir des rendements très élevés, mais en réalité, le niveau des équipes est inégal. Par exemple, le code peut être acheté, et même si le code lui-même n'a pas de vulnérabilités, il peut toujours y avoir des problèmes logiques. Par exemple, un projet a été rencontré, qui distribuait des récompenses à des moments fixes en fonction du nombre de jetons détenus par les détenteurs. Cependant, des attaquants ont profité des prêts flash pour acheter un grand nombre de jetons, et au moment de la distribution des récompenses, la majorité des récompenses allaient aux attaquants. De plus, certains projets qui calculent les prix via des jetons peuvent influencer les prix grâce aux prêts flash. En tant qu'équipe de projet, il est important d'être vigilant face à ces problèmes.

Manipulation des prix

Le problème de manipulation des prix est étroitement lié aux prêts flash. Ce problème est principalement dû au fait que certains paramètres peuvent être contrôlés par les utilisateurs lors du calcul des prix. Il existe deux types de problèmes qui surviennent fréquemment.

• L'une consiste à utiliser des données de tiers lors du calcul des prix, mais une utilisation incorrecte ou un manque de vérification peut entraîner une manipulation malveillante des prix.
• Une autre raison est due à l'utilisation du nombre de tokens de certaines adresses comme variable de calcul, alors que le solde des tokens de ces adresses peut être temporairement augmenté ou diminué.

Attaque par réinjection

L'un des principaux dangers de l'appel de contrats externes est qu'ils peuvent prendre le contrôle du flux et apporter des modifications inattendues aux données en appelant des fonctions.

Comme le solde de l'utilisateur n'est défini à 0 qu'à la fin de la fonction, le deuxième appel à ( et aux suivants réussira toujours, et le solde sera extrait encore et encore.

Pour différents contrats, il existe de nombreuses manières de réentrer, ce qui peut combiner différentes fonctions de contrat ou les fonctions de plusieurs contrats différents pour réaliser une attaque par réentrance. Par conséquent, lorsque nous traitons le problème de la réentrance, nous devons faire attention aux points suivants :

1. Pas seulement pour prévenir le problème de réentrance d'une fonction unique;
2. Suivre le modèle Checks-Effects-Interactions lors du codage ;
3. Utiliser un modificateur anti-reentrance éprouvé par le temps.

En fait, ce que je crains le plus, c'est de réinventer la roue. Il n'est pas nécessaire d'écrire soi-même tout ce dont on a besoin. Dans ce domaine, il existe de nombreuses meilleures pratiques de sécurité que nous pouvons utiliser, il n'est donc pas du tout nécessaire de réinventer la roue. Lorsque vous créez une roue, elle n'a pas été suffisamment vérifiée, et à ce moment-là, la probabilité d'avoir des problèmes est clairement beaucoup plus élevée que celle d'utiliser une solution très mature et éprouvée.

) L'histoire derrière la faille du protocole Omni --- La lutte entre quatre hackers

La mempool d'Ethereum est constamment surveillée par de nombreux hackers qui analysent en permanence les transactions et exécutent des transactions d'arbitrage sur celles qui sont rentables pour réaliser des bénéfices. Les transactions d'attaque soumises par le découvreur de la vulnérabilité d'Omni Protocol ont été capturées par deux hackers, qui ont utilisé des bots d'arbitrage pour soumettre des transactions d'arbitrage sur flashbot et ont ainsi volé 1200 ETH dans le protocole Omni. En revanche, l'attaquant ayant découvert la vulnérabilité n'a obtenu que 480 ETH. Pendant ce temps, un autre hacker a découvert les transactions d'attaque soumises par les hackers d'arbitrage sur flashbot et a profité des caractéristiques de la transaction d'attaque nécessitant l'achat de jetons Doodle ERC20 pour réaliser une attaque sandwich, obtenant ainsi un profit de 151 ETH.

Les personnes qui découvrent des vulnérabilités ne sont pas celles qui réalisent le plus de bénéfices, ce sont plutôt d'autres chasseurs dans la forêt sombre. Dans cet écosystème, il y a des chasseurs partout, et les chasseurs peuvent être la proie les uns des autres. Même l'initiateur d'une attaque, s'il est débutant, pourrait ne pas être en mesure de prendre la majorité de l'argent du projet, sauf s'il réussit à tout prendre d'un coup. Beaucoup de gens utilisent également des frais de Gas plus élevés pour exécuter les transactions en premier. Si, dans le processus de cette course, il y a des achats et des ventes de jetons sur un DEX, cela peut entraîner des attaques de sandwich, ce qui est très chaotique.

Conseils de sécurité

Enfin, voici des conseils de sécurité pour les porteurs de projet et les utilisateurs ordinaires.

Conseils de sécurité pour les projets

1. Le développement de contrats suit les meilleures pratiques de sécurité.

Deux, contrats pouvant être mis à niveau et suspendus : Beaucoup d'attaques ne consistent pas à transférer tous les fonds en une seule fois, mais à exécuter plusieurs transactions. S'il existe un mécanisme de surveillance relativement solide, cela peut être détecté. Après détection, si le contrat peut être suspendu, cela peut efficacement réduire les pertes.

Trois, utilisation d'un verrouillage temporel : Comme dans certains cas, s'il y a un verrouillage temporel, supposons qu'il doit être complété dans les 48 heures, à ce moment-là, beaucoup de gens peuvent découvrir que le créateur a mis à jour une méthode de mint, et que tout le monde peut l'utiliser. Les personnes qui surveillent sauront que le projet a probablement été piraté et pourront informer l'équipe du projet pour qu'elle prenne des mesures. Même si l'on suppose qu'ils sont informés et que personne ne s'en occupe, au moins, ils peuvent retirer leur part d'argent pour garantir que leurs bénéfices ne soient pas affectés. Par conséquent, si un projet n'a pas de verrouillage temporel, théoriquement, cela augmente la probabilité de rencontrer des problèmes.

Quatre, augmenter l'investissement en sécurité et établir un système de sécurité complet : La sécurité n'est pas un point, ni une ligne, la sécurité est systémique. Ne pensez pas qu'en tant que porteur de projet, avoir le contrat audité par plusieurs sociétés signifie qu'il n'y a pas de problème, car un hacker peut voler la clé privée, même avec un multi-signature, en volant toutes les clés privées. Ou encore, il peut y avoir des problèmes avec le modèle économique, des problèmes avec le modèle commercial... Il existe des milliers de façons de perdre de l'argent, il s'agit de savoir si l'on peut éviter tous les risques de sécurité à l'avance. Il faut essayer de faire une modélisation des risques, puis progressivement réduire la plupart des risques, les risques restants étant des risques acceptables, dans une plage tolérable. La sécurité et l'efficacité ne peuvent pas être obtenues simultanément, il faut faire des choix. Mais si l'on ne se préoccupe pas de la sécurité et qu'il n'y a pas d'investissement dans ce domaine, être attaqué est tout à fait normal.

Cinq, sensibiliser tous les employés à la sécurité : Sensibiliser à la sécurité ne nécessite pas beaucoup de technologie. Sur Twitter, nous voyons souvent des gens perdre des NFT à cause de phishing, en fait, les méthodes de phishing exploitent les faiblesses humaines. En prêtant un peu plus d'attention, on pourrait éviter de tomber dans le piège. Dans cet environnement Web3, il suffit de poser un peu plus de questions sur le pourquoi et de réfléchir un peu plus pour éviter de nombreux problèmes.

Six, prévenir les malversations internes tout en améliorant l'efficacité et en renforçant le contrôle des risques : Prenons encore quelques exemples. Premièrement, le propriétaire du contrat est une clé unique et non une clé multiple, si la clé privée est perdue, l'ensemble du projet est contrôlé ; deuxièmement, il n'y a pas de verrouillage temporel, certaines mises à jour d'opérations clés sont mises à jour immédiatement, personne ne le sait, ce qui est très injuste pour tous les participants au protocole ; enfin, il y a des malversations internes, les mécanismes de sécurité internes n'ont eu aucun effet.

Comment les protocoles sur la blockchain peuvent-ils garantir l'efficacité tout en améliorant également la sécurité ? Certains outils de sécurité peuvent désigner une personne pour effectuer une certaine opération, par exemple un multi-signature à trois sur cinq ; il est possible de désigner une adresse spécifique pour effectuer une opération particulière, comme confier la surveillance des risques de sécurité à un nœud de confiance. Supposons que nous découvrions que le protocole est en train d'être attaqué et que des fonds sont progressivement transférés vers une adresse de hacker. Si ce contrat possède une fonctionnalité de pause, et que nous avons accordé cette fonctionnalité de pause à une personne, alors cette personne peut effectuer cette opération.

Par exemple, pour les teneurs de marché de DEX, s'il n'y a pas de restriction sur les droits de l'Owner, l'Owner peut transférer de l'argent vers une autre adresse, limiter les adresses de transfert de jetons, restreindre les paires de devises sur lesquelles il peut opérer, et définir que l'argent ne peut être retiré qu'à une certaine adresse. Cela améliore l'efficacité tout en garantissant un certain niveau de sécurité.

VII. Sécurité de l'introduction des tiers : En tant qu'élément de l'écosystème, chaque projet a ses propres parties prenantes. Il existe un principe selon lequel "par défaut, les parties prenantes sont considérées comme non sécurisées". Que ce soit pour les parties prenantes en amont ou en aval, des vérifications doivent être effectuées. En ce qui concerne les tiers, il est très difficile de contrôler, l'exposition au risque de sécurité est en fait particulièrement grande, donc il faut faire très attention à l'introduction des tiers. Le contrat est open source, il peut être introduit ou appelé ; si le contrat n'est pas open source, il ne doit absolument pas être référencé. Parce que nous ne savons pas quelle est la logique interne ou si l'introduction de ce contrat est en elle-même un contrat évolutif, son utilisation normale peut ne pas poser de problème, mais nous ne pouvons pas prédire si un jour il sera soudainement mis à jour pour devenir un contrat malveillant, ce qui est incontrôlable.

Comment les utilisateurs/LP peuvent-ils déterminer si un contrat intelligent est sécurisé ?

Pour les utilisateurs ordinaires, nous jugeons si un projet est sûr principalement en regardant les six points suivants :

1. Le contrat est-il open source : Aucun projet dont le contrat n'est pas open source ne doit être touché, car nous ne pouvons pas savoir ce qui est écrit dans le contrat.

Deux, le propriétaire utilise-t-il des signatures multiples et ces signatures sont-elles décentralisées : Si nous n'utilisons pas de signatures multiples, nous ne pouvons pas juger de la logique et du contenu des affaires du projet. En cas d'incident de sécurité, il est impossible de déterminer s'il s'agit d'un acte de piratage. Même en utilisant des signatures multiples, il est nécessaire de vérifier si ces signatures sont décentralisées.

Trois, la situation des transactions du contrat existant: En particulier, il existe de nombreux projets de phishing sur le marché qui peuvent créer un contrat relativement similaire. À ce moment-là, nous devons examiner le temps de déploiement du contrat, le nombre d'interactions, etc. Tous ces éléments sont des critères d'évaluation pour déterminer si le contrat est sécurisé.

Quatre, le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel : Si le contrat ne peut absolument pas être mis à jour, cela devient trop rigide, il est donc préférable que les contrats des projets soient évolutifs. Cependant, la mise à jour doit se faire de manière appropriée, lorsque la mise à jour comporte des contenus de mise à jour ou des modifications importantes des paramètres, il doit y avoir un verrouillage temporel, et il doit y avoir une fenêtre de temps pour que tout le monde puisse juger si la mise à jour réelle est nuisible ou bénéfique pour les utilisateurs, c'est aussi une forme de transparence publique.

Cinq, le contrat a-t-il été audité par plusieurs institutions### ne faites pas confiance aveuglément aux sociétés d'audit(, les droits du propriétaire ne sont-ils pas trop importants : Tout d'abord, ne faites pas confiance à une seule société d'audit, car différentes sociétés d'audit et différents auditeurs ont des perspectives différentes sur les problèmes. Si un projet a des résultats d'audit de plusieurs institutions qui ont révélé des problèmes différents, et que l'équipe du projet a effectué des corrections, cela est plus sûr que si seul un cabinet d'audit l'avait examiné. Une équipe de projet responsable cherchera à faire auditer par plusieurs institutions pour réaliser des audits croisés.

Ensuite, il faut voir si les droits du propriétaire sont trop étendus. Par exemple, il existe certains projets de Pi Xie Pan où le propriétaire peut contrôler complètement les fonds des utilisateurs. Si le montant de jetons achetés est faible, les transactions peuvent se faire normalement, mais si le montant est énorme, le propriétaire peut immédiatement verrouiller les fonds, rendant les transactions impossibles. Il en va de même pour certains projets NFT. Dans un projet normal, les droits du propriétaire doivent être contrôlables, de cette manière, il n'y aura pas trop d'opérations à haut risque, et les opérations seront effectuées avec un verrouillage temporel, permettant aux utilisateurs de savoir ce qui est en cours. Surtout en période de marché difficile, il existe divers types d'escroqueries, donc il est essentiel de prêter attention aux droits du propriétaire.

Six, attention aux oracles : Si le projet utilise un oracle leader sur le marché, il ne devrait pas y avoir de gros problèmes, mais s'il utilise un oracle construit en interne, ou s'il utilise des jetons qui peuvent être facilement mis en garantie, cela peut poser des soucis.