Analyse des vulnérabilités de sécurité courantes dans la Finance décentralisée : prévention des Prêts Flash, manipulation des prix et attaques par réinjection.
Récemment, un expert en sécurité a partagé avec les membres de la communauté une leçon sur la sécurité DeFi. Il a passé en revue les événements de sécurité majeurs auxquels l'industrie Web3 a été confrontée au cours de l'année écoulé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 également donné quelques conseils de sécurité aux projets et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants incluent les prêts flash, la manipulation des prix, les problèmes de permissions de fonction, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités logiques commerciales, les fuites de clés privées, les attaques par réentrées, etc. Ci-dessous, nous mettons l'accent sur les prêts flash, la manipulation des prix et les attaques par réentrées.
Prêt flash
Le prêt flash est en soi une innovation de la Finance décentralisée, mais lorsqu'il est exploité par des hackers, ils peuvent emprunter d'énormes sommes d'argent sans coût, rembourser après avoir effectué l'arbitrage, et obtenir des bénéfices énormes en ne payant qu'une faible commission de Gas.
Au cours des deux dernières années, les problèmes de prêts éclair ont été fréquents. Certains projets semblent offrir des rendements très élevés, mais en réalité, le niveau des équipes de projet varie considérablement. Même si le code lui-même n'a pas de vulnérabilités, des problèmes logiques peuvent toujours exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction du nombre de jetons détenus par les utilisateurs, mais peuvent être exploités par des attaquants utilisant des prêts éclair pour acheter une grande quantité de jetons, obtenant ainsi la majorité des récompenses au moment de la distribution. D'autres projets, qui calculent les prix en fonction des jetons, peuvent également voir leur prix influencé par des prêts éclair. Les équipes de projet devraient être plus vigilantes face à ces problèmes.
Manipulation des prix
Le problème de manipulation des prix est étroitement lié aux prêts instantanés, il existe principalement deux types :
Lors du calcul des prix, des données tierces sont utilisées, mais une mauvaise utilisation ou un manque de vérification entraînent une manipulation malveillante des prix.
Utiliser le nombre de jetons d'adresses spécifiques comme variable de calcul, alors que le solde des jetons de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux dangers d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux d'exécution et apporter des modifications inattendues aux données en appelant des fonctions.
Pour différents contrats, il existe de nombreuses manières de réentrer, ce qui peut être réalisé en combinant différentes fonctions de contrat ou les fonctions de plusieurs contrats différents pour mener une attaque par réentrées. Ainsi, lors de la résolution du problème de réentrées, il est nécessaire de prêter attention à :
Pas seulement pour prévenir les problèmes de réentrance d'une seule fonction.
Suivre le modèle Checks-Effects-Interactions lors du codage
Utiliser un modificateur anti-reentrance éprouvé par le temps
Ce que je crains le plus, c'est de réinventer la roue, 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é de rencontrer un problème est clairement beaucoup plus grande que celle d'utiliser une roue très mature et éprouvée.
Conseils de sécurité
Conseils de sécurité pour les projets
Le développement de contrats respecte les meilleures pratiques en matière de sécurité.
Les contrats peuvent être mis à niveau et suspendus : de nombreuses 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é. Si le contrat peut être suspendu après cela, cela peut réduire efficacement les pertes.
Utilisation d'un verrouillage temporel : s'il y a un verrouillage temporel, supposons qu'il faille 48 heures pour le compléter, à ce moment-là, pendant la période de verrouillage, de nombreuses personnes peuvent découvrir que le créateur a mis à jour une méthode de mint que tout le monde peut utiliser. Les personnes qui surveillent le projet sauront que celui-ci pourrait être piraté et pourront informer l'équipe du projet d'apporter des modifications. Même si elles sont informées, personne ne s'en occupe ; au moins, elles peuvent retirer leur part d'argent pour garantir que leurs bénéfices ne soient pas affectés. Ainsi, on peut dire que si un projet n'a pas de verrouillage temporel, cela augmente théoriquement la probabilité de rencontrer des problèmes.
Augmenter les investissements 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 un système. Ne pensez pas qu'en tant que partie du projet, le fait que le contrat ait été audité par plusieurs entreprises signifie qu'il n'y a pas de problème, il faut considérer tous les risques pouvant entraîner des pertes de fonds. Il est nécessaire de faire une modélisation des risques autant que possible, puis d'éliminer progressivement la plupart des risques, les risques restants étant des risques acceptables et dans une plage supportable. Sécurité et efficacité ne peuvent pas être obtenues en même temps, il faut faire certains compromis. Mais si l'on ne tient absolument pas compte de la sécurité et qu'il n'y a pas d'investissement dans la sécurité, être attaqué est tout à fait normal.
Élever la conscience de la sécurité de tous les employés : Élever la conscience de la sécurité ne nécessite pas beaucoup de technologie. Dans ce grand environnement, 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.
Prévenir les abus internes, tout en améliorant l'efficacité et en renforçant le contrôle des risques : par exemple, il faut considérer si le propriétaire du contrat est une signature unique ou multiple, s'il utilise un verrouillage temporel, etc.
Sécurité de l'introduction de tiers : En tant qu'élément de l'écosystème, chaque projet a ses propres partenaires en amont et en aval. Il existe un principe selon lequel "par défaut, les partenaires en amont et en aval sont considérés comme non sûrs". Il est nécessaire de faire des vérifications tant pour les partenaires en amont que pour ceux en aval. Pour les tiers, il est très difficile de contrôler, et l'exposition au risque de sécurité est en réalité particulièrement grande, donc il faut être très attentif à l'introduction des tiers. Les contrats sont open source et peuvent être introduits ou appelés ; si le contrat n'est pas open source, il ne doit absolument pas être référencé.
Comment les utilisateurs/LP peuvent-ils déterminer si un contrat intelligent est sûr ?
Pour les utilisateurs ordinaires, juger si un projet est sécurisé repose principalement sur les six points suivants :
Le contrat est-il open source : Nous ne touchons absolument pas aux projets dont le contrat n'est pas open source, car nous ne pouvons pas savoir ce que contient le contrat.
Le propriétaire utilise-t-il des signatures multiples, et ces signatures multiples sont-elles décentralisées : si les signatures multiples ne sont pas utilisées, nous ne pouvons pas juger de la logique et du contenu des affaires du projet. En cas d'incident de sécurité, nous ne pouvons pas déterminer s'il s'agit d'un acte de piratage. Même si des signatures multiples sont utilisées, il est également nécessaire de vérifier si ces signatures sont décentralisées.
État des transactions existantes du contrat : en particulier, il existe de nombreux projets de phishing sur le marché qui peuvent créer un contrat assez similaire. Dans ce cas, nous devons examiner le temps de déploiement du contrat, le nombre d'interactions, etc. Tous ces éléments sont des critères de mesure pour évaluer la sécurité du contrat.
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel : si le contrat ne peut pas du tout être mis à jour, il est trop rigide, il est donc recommandé que le contrat du projet soit évolutif. Cependant, la mise à jour doit être soigneusement réfléchie, lorsque la mise à jour contient du contenu de mise à jour ou des modifications d'importants paramètres, il doit y avoir un verrouillage temporel, afin de donner à tout le monde une fenêtre de temps pour juger si la mise à jour réelle est nuisible ou bénéfique pour les utilisateurs, c'est aussi une forme de transparence.
Le contrat a-t-il été audité par plusieurs institutions ( ne faites pas aveuglément confiance aux sociétés d'audit ), Les droits du propriétaire sont-ils trop importants : d'abord, ne croyez pas uniquement en une seule société d'audit, car différentes sociétés d'audit, différents auditeurs, ont des angles de vue différents. Ensuite, il faut vérifier si les droits du propriétaire sont trop importants. Dans un projet normal, les droits du propriétaire doivent être contrôlables, ce qui évite les opérations à haut risque, et les opérations doivent également être effectuées par des moyens de verrouillage temporel, afin que les utilisateurs sachent ce qui est en train d'être opéré.
Attention aux oracles : Si le projet utilise un oracle de premier plan sur le marché, il ne devrait pas y avoir de gros problèmes. Cependant, s'il utilise un oracle auto-construit, ou un oracle où il suffit de garantir quelques tokens pour alimenter les prix, alors il faut faire attention. Lorsqu'on découvre que l'oracle pourrait avoir des problèmes, ou qu'il existe un risque de manipulation, même si les rendements du projet sont élevés, il ne faut pas y participer.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
9 J'aime
Récompense
9
5
Partager
Commentaire
0/400
BrokeBeans
· 07-22 12:06
Mince, ce Prêts Flash rapporte gros, dommage que je ne sache pas...
Voir l'originalRépondre0
LayerZeroHero
· 07-22 06:59
Encore des Prêts Flash ciblés ? Pas surprise.
Voir l'originalRépondre0
P2ENotWorking
· 07-19 19:46
Pour gagner de l'argent, il faut savoir comment se protéger des failles.
Voir l'originalRépondre0
ConsensusBot
· 07-19 19:42
Portefeuille d'abord, puis Trading des cryptomonnaies.
Voir l'originalRépondre0
LiquidityWizard
· 07-19 19:27
Vieux chien de l'industrie Professionnel du chapeau blanc
Analyse des vulnérabilités de sécurité courantes dans la Finance décentralisée : prévention des Prêts Flash, manipulation des prix et attaques par réinjection.
Finance décentralisée 常见安全漏洞及预防措施
Récemment, un expert en sécurité a partagé avec les membres de la communauté une leçon sur la sécurité DeFi. Il a passé en revue les événements de sécurité majeurs auxquels l'industrie Web3 a été confrontée au cours de l'année écoulé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 également donné quelques conseils de sécurité aux projets et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants incluent les prêts flash, la manipulation des prix, les problèmes de permissions de fonction, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités logiques commerciales, les fuites de clés privées, les attaques par réentrées, etc. Ci-dessous, nous mettons l'accent sur les prêts flash, la manipulation des prix et les attaques par réentrées.
Prêt flash
Le prêt flash est en soi une innovation de la Finance décentralisée, mais lorsqu'il est exploité par des hackers, ils peuvent emprunter d'énormes sommes d'argent sans coût, rembourser après avoir effectué l'arbitrage, et obtenir des bénéfices énormes en ne payant qu'une faible commission de Gas.
Au cours des deux dernières années, les problèmes de prêts éclair ont été fréquents. Certains projets semblent offrir des rendements très élevés, mais en réalité, le niveau des équipes de projet varie considérablement. Même si le code lui-même n'a pas de vulnérabilités, des problèmes logiques peuvent toujours exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction du nombre de jetons détenus par les utilisateurs, mais peuvent être exploités par des attaquants utilisant des prêts éclair pour acheter une grande quantité de jetons, obtenant ainsi la majorité des récompenses au moment de la distribution. D'autres projets, qui calculent les prix en fonction des jetons, peuvent également voir leur prix influencé par des prêts éclair. Les équipes de projet devraient être plus vigilantes face à ces problèmes.
Manipulation des prix
Le problème de manipulation des prix est étroitement lié aux prêts instantanés, il existe principalement deux types :
Lors du calcul des prix, des données tierces sont utilisées, mais une mauvaise utilisation ou un manque de vérification entraînent une manipulation malveillante des prix.
Utiliser le nombre de jetons d'adresses spécifiques comme variable de calcul, alors que le solde des jetons de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux dangers d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux d'exécution et apporter des modifications inattendues aux données en appelant des fonctions.
Pour différents contrats, il existe de nombreuses manières de réentrer, ce qui peut être réalisé en combinant différentes fonctions de contrat ou les fonctions de plusieurs contrats différents pour mener une attaque par réentrées. Ainsi, lors de la résolution du problème de réentrées, il est nécessaire de prêter attention à :
Pas seulement pour prévenir les problèmes de réentrance d'une seule fonction.
Suivre le modèle Checks-Effects-Interactions lors du codage
Utiliser un modificateur anti-reentrance éprouvé par le temps
Ce que je crains le plus, c'est de réinventer la roue, 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é de rencontrer un problème est clairement beaucoup plus grande que celle d'utiliser une roue très mature et éprouvée.
Conseils de sécurité
Conseils de sécurité pour les projets
Le développement de contrats respecte les meilleures pratiques en matière de sécurité.
Les contrats peuvent être mis à niveau et suspendus : de nombreuses 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é. Si le contrat peut être suspendu après cela, cela peut réduire efficacement les pertes.
Utilisation d'un verrouillage temporel : s'il y a un verrouillage temporel, supposons qu'il faille 48 heures pour le compléter, à ce moment-là, pendant la période de verrouillage, de nombreuses personnes peuvent découvrir que le créateur a mis à jour une méthode de mint que tout le monde peut utiliser. Les personnes qui surveillent le projet sauront que celui-ci pourrait être piraté et pourront informer l'équipe du projet d'apporter des modifications. Même si elles sont informées, personne ne s'en occupe ; au moins, elles peuvent retirer leur part d'argent pour garantir que leurs bénéfices ne soient pas affectés. Ainsi, on peut dire que si un projet n'a pas de verrouillage temporel, cela augmente théoriquement la probabilité de rencontrer des problèmes.
Augmenter les investissements 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 un système. Ne pensez pas qu'en tant que partie du projet, le fait que le contrat ait été audité par plusieurs entreprises signifie qu'il n'y a pas de problème, il faut considérer tous les risques pouvant entraîner des pertes de fonds. Il est nécessaire de faire une modélisation des risques autant que possible, puis d'éliminer progressivement la plupart des risques, les risques restants étant des risques acceptables et dans une plage supportable. Sécurité et efficacité ne peuvent pas être obtenues en même temps, il faut faire certains compromis. Mais si l'on ne tient absolument pas compte de la sécurité et qu'il n'y a pas d'investissement dans la sécurité, être attaqué est tout à fait normal.
Élever la conscience de la sécurité de tous les employés : Élever la conscience de la sécurité ne nécessite pas beaucoup de technologie. Dans ce grand environnement, 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.
Prévenir les abus internes, tout en améliorant l'efficacité et en renforçant le contrôle des risques : par exemple, il faut considérer si le propriétaire du contrat est une signature unique ou multiple, s'il utilise un verrouillage temporel, etc.
Sécurité de l'introduction de tiers : En tant qu'élément de l'écosystème, chaque projet a ses propres partenaires en amont et en aval. Il existe un principe selon lequel "par défaut, les partenaires en amont et en aval sont considérés comme non sûrs". Il est nécessaire de faire des vérifications tant pour les partenaires en amont que pour ceux en aval. Pour les tiers, il est très difficile de contrôler, et l'exposition au risque de sécurité est en réalité particulièrement grande, donc il faut être très attentif à l'introduction des tiers. Les contrats sont open source et peuvent être introduits ou appelés ; si le contrat n'est pas open source, il ne doit absolument pas être référencé.
Comment les utilisateurs/LP peuvent-ils déterminer si un contrat intelligent est sûr ?
Pour les utilisateurs ordinaires, juger si un projet est sécurisé repose principalement sur les six points suivants :
Le contrat est-il open source : Nous ne touchons absolument pas aux projets dont le contrat n'est pas open source, car nous ne pouvons pas savoir ce que contient le contrat.
Le propriétaire utilise-t-il des signatures multiples, et ces signatures multiples sont-elles décentralisées : si les signatures multiples ne sont pas utilisées, nous ne pouvons pas juger de la logique et du contenu des affaires du projet. En cas d'incident de sécurité, nous ne pouvons pas déterminer s'il s'agit d'un acte de piratage. Même si des signatures multiples sont utilisées, il est également nécessaire de vérifier si ces signatures sont décentralisées.
État des transactions existantes du contrat : en particulier, il existe de nombreux projets de phishing sur le marché qui peuvent créer un contrat assez similaire. Dans ce cas, nous devons examiner le temps de déploiement du contrat, le nombre d'interactions, etc. Tous ces éléments sont des critères de mesure pour évaluer la sécurité du contrat.
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel : si le contrat ne peut pas du tout être mis à jour, il est trop rigide, il est donc recommandé que le contrat du projet soit évolutif. Cependant, la mise à jour doit être soigneusement réfléchie, lorsque la mise à jour contient du contenu de mise à jour ou des modifications d'importants paramètres, il doit y avoir un verrouillage temporel, afin de donner à tout le monde une fenêtre de temps pour juger si la mise à jour réelle est nuisible ou bénéfique pour les utilisateurs, c'est aussi une forme de transparence.
Le contrat a-t-il été audité par plusieurs institutions ( ne faites pas aveuglément confiance aux sociétés d'audit ), Les droits du propriétaire sont-ils trop importants : d'abord, ne croyez pas uniquement en une seule société d'audit, car différentes sociétés d'audit, différents auditeurs, ont des angles de vue différents. Ensuite, il faut vérifier si les droits du propriétaire sont trop importants. Dans un projet normal, les droits du propriétaire doivent être contrôlables, ce qui évite les opérations à haut risque, et les opérations doivent également être effectuées par des moyens de verrouillage temporel, afin que les utilisateurs sachent ce qui est en train d'être opéré.
Attention aux oracles : Si le projet utilise un oracle de premier plan sur le marché, il ne devrait pas y avoir de gros problèmes. Cependant, s'il utilise un oracle auto-construit, ou un oracle où il suffit de garantir quelques tokens pour alimenter les prix, alors il faut faire attention. Lorsqu'on découvre que l'oracle pourrait avoir des problèmes, ou qu'il existe un risque de manipulation, même si les rendements du projet sont élevés, il ne faut pas y participer.