Technicien Rétro: Vulnérabilité des contrats de vote MakerDAO


En partenariat avec Zeppelin Solutions, les équipes de sécurité Coinbase et Coinbase Custody ont découvert une vulnérabilité critique dans les contrats de vote de MKR. Dans le prochain article, nous analysons les étapes que nous suivons pour identifier le problème et comment nous travaillons en étroite collaboration avec nos partenaires et l'équipe de MKR pour remédier à la vulnérabilité, ce qui entraîne une perte de fonds des clients.

Il s’agit d’un élément complémentaire de l’audit technique de Zeppelin Solutions.

Coinbase effectue régulièrement des audits de sécurité des contrats intelligents que nous écrivons ou des actifs que nous répertorions ou que nous évaluons en vue de leur inclusion. La plupart du temps, nous nous entendons avec des préoccupations mineures, le cas échéant. De temps en temps, nous trouvons quelque chose qui, à notre avis, devrait être divulgué directement au projet mais dont la gravité est relativement faible. Très, très rarement, nous découvrirons un problème qui, à notre avis, représente un risque critique pour un actif. Notre examen récent des contrats de vote MakerDAO en est un exemple.

Ensuite, nous partageons le processus que nous avons suivi pour identifier et résoudre le problème et nous assurer que tous les participants de cet écosystème sont protégés. Nous avons également extrait des éléments spécifiques qui, selon nous, valent la peine d'être appris par quiconque construit un actif basé sur la blockchain. Il convient de noter que nous ne sommes pas la seule organisation à déployer ce type d’efforts. Il existe un certain nombre d'exemples d'audits d'actifs et de divulgation responsable dans l'ensemble du secteur, avec des résultats variables.

Cette histoire commence par des contrats intelligents. Historiquement, nous avons évité les contrats intelligents dans le cadre de notre infrastructure, car nous pensons que l'écosystème de contrats intelligents est encore assez jeune. Bien qu'il existe des innovations surprenantes dans le domaine de la vérification formelle et des outils de sécurité pour les contrats intelligents, nous ne voyons pas le même niveau de maturité de la chaîne d'outils que ce à quoi nous nous attendions dans un langage de programmation traditionnel. Cependant, avec l’effort de Coinbase Custody de fournir des services gouvernementaux à ses clients, ainsi que notre taux d’inventaire accéléré des actifs basé sur des contrats intelligents, l’expérience en matière de sécurité des contrats intelligents est devenue quelque chose que nous avons dû développer, et nous en avons fait une combinaison d'associations externes et d'expérience interne.

Dans notre processus de liste des actifs et avant toute utilisation interne de contrats intelligents, nous mettons en œuvre une série de mesures de sécurité, dont l'une nécessite un examen de la sécurité de tous les contrats de production intelligents. Dans le cadre de notre projet visant à intégrer le vote MakerDAO directement à notre système d’entreposage frigorifique, nous avons créé un contrat Smart VoteProxy personnalisé. Une fois que nous avons obtenu ce que nous pensions être une bonne version, nous l’avons présentée à l'un de nos partenaires d'audit externe, Zeppelin, et nous nous sommes assurés que la portée de l'examen incluait les interactions entre les contrats de l'écosystème de vote MakerDAO (principalement , les interactions entre notre contrat et le contrat DS-Chief). Nous nous attendions à recevoir des suggestions et à travailler avec l'équipe de Zeppelin pour mettre en œuvre les corrections et aller de l'avant. Cette fois, cependant, nous avons eu une touche plus que prévu. Un point essentiel à cet égard est qu’il est vivement recommandé à quiconque rédige un code de contrat de production intelligent de faire de la révision complète de la sécurité par des tiers une partie intégrante de son cycle de vie de développement. Si vous créez un actif, nous vous recommandons d'aller plus loin et de rendre ces révisions publiques. L’un des éléments clés que nous recherchons lors de l’évaluation des actifs à inclure dans Coinbase est la cadence régulière des audits de tiers effectués par des sociétés fiables.

Nous savions qu'il se passait quelque chose d'inhabituel lorsque Zeppelin avait programmé un enregistrement non planifié. À ce stade, ils nous ont informés brièvement qu'ils avaient trouvé une erreur critique dans le vote MakerDAO. Nous avons contacté l'équipe MakerDAO et nous nous sommes tous retrouvés dans un appel quelques heures après les premiers résultats. Ici, et une suggestion pour d'autres sociétés dans des situations similaires, Zeppelin n'a pas divulgué les détails de la vulnérabilité jusqu'à ce que nous ayons coordonné un appel et que l'équipe MakerDAO soit en ligne. Cela garantissait que toutes les parties avaient un accès égal à l'information et que les intérêts de toutes les parties étaient protégés.

Lors d'une vidéoconférence avec les équipes de sécurité de Coinbase et MakerDao, Zeppelin a examiné les détails de la vulnérabilité, a partagé l'exemple de code d'exploitation, clarifié plusieurs hypothèses et proposé des mesures d'atténuation. L'équipe MakerDAO avait les bonnes personnes sur la ligne pour évaluer le rapport et commencer à fouiller dans les détails techniques. Nous avons mis en place un canal de communication commun et mis en place une prochaine vérification à temps. L’équipe MakerDAO a exploré le rapport en détail. Une fois que l'équipe MakerDAO était prête à proposer une voie à suivre, nous nous sommes réunis à nouveau et avons fourni des commentaires. C’est un bon exemple de réponse positive et engagée à une divulgation de vulnérabilité. Si vous écrivez un code qui touche de l'argent dans un environnement aussi nouveau qu'un langage contractuel intelligent, vous devez vous attendre à recevoir des rapports de vulnérabilité critiques. Construire une politique et un plan Conduire les tables. Publiez votre plan Assurez-vous de disposer d'un mécanisme de signalement des vulnérabilités simple et sécurisé. Conduire plus de tables.

Avec un plan de match partagé en place, les équipes ont entrepris de développer une solution. Du côté de Coinbase Custody, cela incluait de s’assurer que les communications étaient prêtes pour tous nos clients, que nous aurions ajouté la détection de cette activité à notre outil de surveillance de la chaîne de blocs (le même outil que celui qui a détecté l’attaque ETC du système). 51%) et que nous évitons de causer des dommages au client en inscrivant sur la liste noire les adresses des contrats précédents et en retardant le déploiement de notre fonction de vote MakerDAO.

Cependant, il y a eu quelques captures.

Premièrement, dès que MakerDAO a annoncé qu'une vulnérabilité critique avait été détectée et signalé le nouveau contrat DS-Chief aux utilisateurs, il ne serait plus qu'une question de temps avant que les utilisateurs n'aient décompilé le nouveau contrat et procédé à une ingénierie inverse de la vulnérabilité. Dans le même temps, MakerDAO n'a pas pu forcer les participants du réseau existant à retirer leur MKR de l'ancien contrat intelligent vulnérable. Les participants au réseau risquaient donc de perdre si un attaquant avait commencé à attaquer le contrat précédent avant que tous les participants au réseau aient retiré leur MKR. Cependant, l'équipe MakerDAO a été en mesure de concevoir une série de mesures d'atténuation qui réduiraient considérablement l'impact de toute exploitation active. Nous pensons qu'il s'agit d'un cas très intéressant dans la gestion des vulnérabilités dans ce type d'environnement. Dans la blockchain, tout le code (du moins, tout le bytecode) est public et, contrairement au monde du développement logiciel traditionnel (par exemple, lorsque Microsoft envoie des correctifs), les correctifs de contrat intelligents ont tendance à être plus petit et moins obscurcissant. Nous devons supposer que le fossé entre le correctif et la découverte de la vulnérabilité générale sera très court et que nous élaborerons nos plans de réponse à la vulnérabilité en tenant compte de cela.

Deuxièmement, MakerDAO avait lancé le contrat d'intelligence vulnérable en tant que source ouverte. Si d'autres projets avaient repris et utilisaient ce contrat intelligent, ils pourraient également être vulnérables au même problème. Malheureusement, il s’agit d’un problème courant dans le développement de logiciels open source sans solution globale complexe. Nous voyons des solutions ponctuelles dans des écosystèmes spécifiques, par exemple, l’audit des packages Ruby, où il existe des systèmes de bibliothèque plus robustes. D'autre part, les logiciels open source peuvent être exploités de manière sécurisée en intégrant des bibliothèques largement utilisées et testées au combat, telles que OpenZeppelin. Nous espérons que, au fil de la maturation de l'écosystème de contrat intelligent, nous verrons évoluer des systèmes de bibliothèques plus matures, ce qui permettra un contrôle efficace des alertes de dépendance et de sécurité.

En fin de compte, MakerDAO a pu envoyer un nouveau contrat, faire bouger les participants du réseau et éviter toute perte. Cela n'a été possible que grâce à l'excellent travail réalisé pour découvrir la vulnérabilité de Zeppelin et à la rapide participation collaborative des trois parties à l'examen et au traitement du problème. Cela devrait servir d'exemple pour savoir comment gérer la divulgation d'une vulnérabilité critique dans n'importe quel secteur. Si vous êtes impliqué dans la rédaction d'un code de contrat de production intelligent, je vous invite à réfléchir au scénario précédent dans le contexte de votre projet et à vous demander comment votre équipe réagirait. Explorez des cas critiques, des scénarios à la pointe de la technologie et voyez où votre plan pourrait utiliser certains ajustements. Vous n'avez pas de plan? Il n'y a pas de meilleur moment pour commencer à en écrire un que maintenant.