Cours de sécurité DeFi Cobo (2/2) : Vulnérabilités courantes dans DeFi et mesures préventives
TechFlow SélectionTechFlow Sélection
Cours de sécurité DeFi Cobo (2/2) : Vulnérabilités courantes dans DeFi et mesures préventives
Analyse des raisons des principaux incidents de sécurité survenus dans l'industrie Web3 au cours de la dernière année et mesures pour les éviter.
Dédié à des analyses Web3 approfondiesAuteur : Max Cobo, Directeur de la sécurité
Cet article est le 24e publié par Cobo Global.
Invité par Moledao, Max, directeur de la sécurité chez Cobo, a récemment dispensé en ligne un cours sur la sécurité DeFi à destination des membres de la communauté. Max a passé en revue les principaux incidents de sécurité survenus dans l'industrie Web3 au cours de l'année écoulée, analysant particulièrement leurs causes et la manière de les éviter. Il a également résumé les vulnérabilités courantes des contrats intelligents ainsi que les mesures préventives associées, tout en prodiguant des conseils de sécurité aux développeurs de projets comme aux utilisateurs ordinaires. Nous publions ici le contenu de cette présentation en deux parties, afin d'être utile aux passionnés de DeFi.
Première partie : « Cours de sécurité DeFi par Cobo (1/2) : Analyse des grands incidents de sécurité DeFi en 2022 »
Les types courants de vulnérabilités DeFi incluent généralement : les prêts flash, la manipulation des prix, les problèmes de permissions des fonctions, les appels externes non contrôlés, les failles liées à la fonction fallback, les vulnérabilités logicielles, les fuites de clés privées et les attaques de réentrance.
Statistiques des incidents de sécurité - Novembre à Décembre 2022
Principalement trois types seront abordés ici : les prêts flash, la manipulation des prix et les attaques de réentrance.
Prêts Flash
-
De nombreuses attaques exploitent fréquemment les prêts flash : les attaquants empruntent de grosses sommes pour manipuler les prix ou exploiter des failles logicielles ;
-
Les développeurs doivent s’interroger sur la robustesse de leurs contrats face à des montants importants : un attaquant pourrait-il interagir avec plusieurs fonctions du contrat dans une seule transaction afin d’obtenir indûment des récompenses ?
-
On observe souvent que certaines valeurs de jetons dans les contrats sont utilisées pour calculer des récompenses ou participer à divers calculs via des paires de DEX. Or, si les développeurs n’ont pas anticipé la possibilité qu’un attaquant manipule ces variables grâce à un prêt flash, cela peut entraîner un vol de fonds.
Le prêt flash est en soi une innovation DeFi, mais lorsqu’il est détourné par des pirates, ceux-ci peuvent emprunter sans mise initiale, exécuter une stratégie d’arbitrage complète puis rembourser le prêt, ne conservant que les bénéfices générés. Le coût se limite alors aux frais de gaz, permettant potentiellement des gains considérables.
Au cours des deux dernières années, les prêts flash ont été à l’origine de nombreux incidents. De nombreux projets DeFi affichent des rendements élevés, mais la qualité des équipes projet varie fortement. Parfois, le code est acheté, et même s’il ne contient pas de vulnérabilités techniques, il peut présenter des failles logicielles. Par exemple, nous avons vu un projet distribuant des récompenses selon les soldes détenus à un instant donné, qui a été exploité par un attaquant utilisant un prêt flash pour accumuler massivement des jetons juste avant la distribution. De même, certains projets basant leurs calculs de prix sur des quantités de jetons sont exposés à des manipulations via prêt flash. Les équipes projet doivent rester vigilantes face à ces risques.
Manipulation des prix
Ce problème est étroitement lié aux prêts flash. Il survient principalement lorsque certains paramètres utilisés dans le calcul des prix peuvent être contrôlés par l’utilisateur. On distingue deux cas fréquents :
-
L'utilisation de données tierces pour le calcul des prix, mais de manière incorrecte ou sans vérification adéquate, permettant une manipulation malveillante.
-
L'utilisation du solde en jetons d'adresses spécifiques comme variable de calcul, alors que ces soldes peuvent être temporairement augmentés ou réduits.
Attaque de réentrance
L'un des principaux dangers lors de l'appel à un contrat externe est qu'il puisse reprendre le contrôle du flux d'exécution et modifier vos données de façon imprévue.
```
mapping (address => uint) private userBalances;
function withdrawBalance() public {
uint amountToWithdraw = userBalances[msg.sender];
(bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // Si msg.sender est un contrat, son code fallback sera exécuté et pourra rappeler withdrawBalance, réalisant ainsi une attaque de réentrance
require(success);
userBalances[msg.sender] = 0;
}
```
Comme le solde utilisateur n’est mis à zéro qu’à la fin de la fonction, les appels suivants continueront de réussir, permettant de retirer plusieurs fois le solde.
Les attaques de réentrance peuvent prendre de nombreuses formes selon les contrats, combinant différentes fonctions d’un même contrat ou de plusieurs contrats. Pour les prévenir, gardez à l’esprit les points suivants :
1. Ne vous contentez pas de prévenir la réentrance sur une seule fonction ;
2. Appliquez le modèle « Checks-Effects-Interactions » lors du codage ;
3. Utilisez un modificateur anti-réentrance éprouvé.
Ce qu’il faut surtout éviter, c’est de réinventer la roue. De nombreuses bonnes pratiques de sécurité existent déjà ; autant les utiliser plutôt que tout recréer soi-même. Quand on conçoit une nouvelle solution, elle n’a pas fait ses preuves, donc la probabilité d’y trouver des failles est bien plus élevée que lorsqu’on utilise une solution mature et largement testée.
Omni Protocol a été victime d'une attaque par réentrance, mais il y a derrière cette histoire un autre épisode fascinant :
L’histoire cachée du bug d’Omni Protocol — Un duel entre quatre hackers
Le mempool d'Ethereum est constamment surveillé par de nombreux hackers qui analysent les transactions en temps réel pour réaliser des attaques de front-running et en tirer profit. Lorsque le découvreur du bug d’Omni Protocol a soumis sa transaction d’attaque, deux hackers l’ont repérée. Grâce à des bots spécialisés, ils ont devancé l’attaquant via Flashbots et ont vidé le protocole Omni Protocol de 1 200 ETH, tandis que l’initiateur de l’attaque n’a récupéré que 480 ETH. Pendant ce temps, un troisième hacker a repéré la transaction des deux premiers dans Flashbots. Profitant du fait que leur attaque nécessitait l’achat du jeton ERC20 Doodle, il a lancé une attaque en sandwich contre eux, engrangeant 151 ETH supplémentaires.
Celui qui découvre la vulnérabilité n’est pas nécessairement celui qui gagne le plus. Ce sont souvent les autres chasseurs de la « forêt obscure » qui profitent le plus. Dans cet écosystème, tous sont des prédateurs, et parfois même les uns des autres. Même l’initiateur d’une attaque, s’il est inexpérimenté, risque de ne pas pouvoir extraire la majorité des fonds, sauf s’il agit en une seule transaction. Beaucoup utilisent des frais de gaz plus élevés pour exécuter leurs transactions en priorité. Et si cette course implique des achats/ventes sur un DEX, une attaque en sandwich peut survenir, créant un chaos total.
Conseils de sécurité
Voici enfin quelques recommandations de sécurité destinées aux équipes projet et aux utilisateurs ordinaires.
Conseils de sécurité pour les équipes projet
1. Suivre les meilleures pratiques de sécurité lors du développement des contrats.
2. Prévoir la mise à jour et la suspension du contrat : De nombreuses attaques ne transfèrent pas tous les fonds en une seule fois, mais en plusieurs transactions. Avec un système de surveillance efficace, on peut détecter ces activités anormales. Si le contrat dispose d'une fonction de suspension, cela permet de limiter considérablement les pertes.
3. Mettre en place un verrou temporel (time lock) : Prenons l’exemple d’Ankr. S’il avait utilisé un time lock de 48 heures, les utilisateurs auraient pu remarquer que le créateur avait redéfini une fonction mint accessible à tous. Les personnes surveillant le projet auraient alors pu alerter l’équipe ou sauver leurs propres fonds. Sans time lock, le risque d’incident augmente théoriquement.
4. Renforcer l’investissement en sécurité et construire un système complet : La sécurité n’est ni un point ni une ligne, c’est un système. Ne pensez pas qu’un audit par plusieurs sociétés suffit à garantir la sécurité. Des pirates nord-coréens ont pu voler des clés privées, même dans un schéma multi-signatures. Des failles économiques ou logicielles peuvent aussi provoquer des pertes. Il existe mille façons de perdre des fonds. Essayez de modéliser les risques, éliminez ceux que vous pouvez, et assurez-vous que les risques résiduels restent acceptables. Sécurité et efficacité ne vont pas toujours de pair : il faut faire des compromis. Mais ignorer totalement la sécurité rend les attaques presque inévitables.
5. Sensibiliser tous les employés à la sécurité : Cette sensibilisation ne requiert pas forcément de compétences techniques. Sur Twitter, on voit souvent des gens perdre leurs NFT suite à des attaques de phishing, qui exploitent simplement les faiblesses humaines. Un peu d’attention suffit souvent à éviter le piège. Dans l’univers Web3, poser une question de plus ou réfléchir davantage permet d’éviter beaucoup d’erreurs.
6. Prévenir les malversations internes, renforcer le contrôle des risques tout en maintenant l’efficacité : Reprenons l’exemple d’Ankr. Premièrement, le propriétaire (Owner) du contrat était une signature unique, et la perte de la clé privée a compromis tout le projet. Deuxièmement, l’absence de time lock a permis une mise à jour immédiate et invisible de fonctionnalités critiques, ce qui est injuste pour les participants. Troisièmement, aucune mesure n’a empêché une éventuelle malversation interne. Les mécanismes de sécurité interne n’ont joué aucun rôle.
Comment un protocole blockchain peut-il améliorer sa sécurité sans sacrifier l’efficacité ? Voici un petit mot sur Cobo Safe. Si un projet utilise un schéma multi-signatures, l’efficacité peut légèrement en pâtir. Avec Cobo Safe, on peut autoriser une personne à effectuer une action spécifique (par exemple, 3 signatures sur 5). On peut aussi donner à un nœud de confiance le droit de surveiller les risques. Si une attaque est détectée et que des fonds sont transférés vers une adresse suspecte, cette personne peut activer la fonction de suspension, si celle-ci est disponible.
Autre exemple : pour un market maker fournissant des liquidités sur un DEX, si les permissions du Owner ne sont pas limitées, il pourrait transférer les fonds ailleurs. Avec Cobo Safe, on peut restreindre les adresses de destination, limiter les paires concernées, ou définir une adresse de retrait autorisée. Ainsi, Cobo Safe améliore à la fois l’efficacité et la sécurité.
7. Sécurité dans l’intégration des tiers : En tant qu’acteur d’un écosystème, un projet a nécessairement des partenaires en amont et en aval. En matière de sécurité, il faut partir du principe que « tous les tiers sont potentiellement non sécurisés ». Il convient donc de valider chaque interaction, qu’elle vienne de l’amont ou de l’aval. Comme on ne peut pas contrôler les tiers, l’exposition aux risques est grande. Soyez donc très vigilant lors de l’intégration de composants externes. Si un contrat est open source, vous pouvez l’étudier avant de l’appeler. Mais s’il ne l’est pas, abstenez-vous absolument de l’utiliser, car vous ignorez sa logique interne. Encore pire, s’il s’agit d’un contrat mis à jour dynamiquement, une mise à jour future pourrait le transformer en outil malveillant, ce qui serait hors de votre contrôle.
Comment un utilisateur ou un fournisseur de liquidités (LP) peut-il juger de la sécurité d’un contrat intelligent ?
Pour un utilisateur ordinaire, voici six critères principaux pour évaluer la sécurité d’un projet :
1. Le contrat est-il open source ? Tout projet dont le code n’est pas public doit être évité, car on ne peut pas savoir ce qu’il contient.
2. Le propriétaire utilise-t-il un multi-sig, et est-il décentralisé ? L’absence de multi-sig rend impossible de distinguer une attaque d’un retrait légitime. Même avec un multi-sig, vérifiez qu’il soit suffisamment décentralisé.
3. Historique des transactions du contrat : De nombreux projets frauduleux imitent des contrats légitimes. Examinez la date de déploiement, le nombre d’interactions, etc., autant d’indicateurs utiles.
4. S’agit-il d’un contrat proxy ? Est-il mis à jour ? Y a-t-il un time lock ? Un contrat non mis à jour est trop rigide. Il vaut mieux qu’il puisse l’être, mais avec méthode : toute mise à jour ou changement critique doit être soumise à un time lock, offrant un délai de réaction aux utilisateurs. C’est aussi une marque de transparence.
5. Le contrat a-t-il été audité par plusieurs entités (ne faites pas aveuglément confiance à un seul auditeur), et les pouvoirs du propriétaire sont-ils excessifs ? Ne vous fiez pas à un seul cabinet d’audit : chaque équipe a des angles d’analyse différents. Un projet ayant subi plusieurs audits, dont les vulnérabilités ont été corrigées, inspire plus confiance. Une équipe sérieuse fait auditer son projet par plusieurs organismes.
Vérifiez aussi que les droits du propriétaire ne soient pas trop étendus. Certains projets « rug pull » permettent au propriétaire de bloquer complètement les transactions si un utilisateur achète trop de jetons. Idem pour certains projets NFT. Un projet sain doit limiter les pouvoirs de son propriétaire, notamment via des time locks, afin d’informer les utilisateurs des modifications. En période de marché baissier, les projets escrocs fleurissent : soyez vigilant sur les permissions du Owner.
6. Attention aux oracles : Si le projet utilise un oracle majeur reconnu, le risque est faible. En revanche, si l’oracle est maison ou permet à n’importe qui de soumettre des prix en mettant en gage quelques jetons, méfiez-vous. Dès qu’un oracle semble vulnérable ou manipulable, abstenez-vous, quel que soit le rendement promis.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Cobo
