Chronologie et réflexions du hack Vyper

« Faire confiance mais vérifier » (faire confiance, mais vérifier), ne faites pas « après coup ». Le bug le plus grave est le noir sous les lumières.

En raison de l'immuabilité du contrat, le projet s'appuiera implicitement sur le code écrit il y a de nombreuses années.Lorsque nous corrigeons des bugs, nous devons faire plus attention à son impact potentiel.

Cette fois, ça s'est passé comme ça.

calendrier

Dans cet article, j'utiliserai "nous" pour désigner tous ceux qui ont travaillé dur sur cet événement. J'ai l'impression que même si j'ai initialement contribué un peu à trouver le bogue, d'innombrables personnes ont beaucoup aidé tout au long du processus.

13:10 UTC pETH/ETH 11 millions de dollars [1] drain.

13:19 UTC Michal publie sur ETHSecurity la chute soudaine du prix du pETH.

Igor a été le premier à remarquer que quelque chose n'allait pas. Grâce à lui, nous avons commencé à enquêter plus avant.

Mais comment le robot ressaisit-il add_liquidity() dans l'appel remove_liquidity() ?

14:01 UTC Formation d'une équipe d'urgence sur le problème.

14:07 UTC Nous utilisons notre décompilateur préféré [2] Décompilé le contrat JPEGd et remarqué que les slots de protection de réentrance sont un peu différents.

// Entrée de la table de répartition pour add_liquidity(uint256 [2] ,uint256) label_0057 : si (stockage [0x00] ) { revenir(mémoire[0x00:0x00]); } stockage [0x00] = 0x01 ; // Entrée de table de répartition pour remove_liquidity(uint256,uint256 [2] ) label_1AF3 : si (stockage [0x02] ) { revenir(mémoire[0x00:0x00]); } stockage [0x02] = 0x01 ;

14:27 UTC Nous avons confirmé ce problème avec un simple contrat de test local.

@externe @nonreentrant("verrouiller") def test(adr : adresse) -> bool : retourner Vrai @externe @nonreentrant("verrouiller") def test2(adresse : adresse) -> booléen : retourner Faux

Ce n'est pas juste un autre bogue de réentrance.

À ce stade, nous avons réalisé à quel point cela allait avoir un impact. Bloquer les messages, nous avons supprimé les messages publics concernant cette vulnérabilité.

14:37 UTC Wavey a aidé à identifier le commit vulnérable et la version affectée. Charles et moi avons également confirmé cela en inspectant manuellement la sortie du compilateur Vyper.

C'est une course contre les hackers.

Heureusement, les gens le confondent également avec la réentrance en lecture seule. Extrait du canal d'alerte de sécurité Web3 - Alchemix et Metronome DAO également piratés en raison d'un bogue de réentrance en lecture seule [3]

Michael a découvert des vulnérabilités potentielles dans les pools alETH et msETH exécutant également la version 0.2.15.

14:50 UTC msETH/ETH épuisé [4] 。

15:34 UTC alETH/ETH est épuisé [5] 。

15:43 UTC Nous avons trouvé une vulnérabilité dans CRV/ETH compilé avec Vyper version 0.3.0 [6] . Il est essentiel que nous gardions les contrats concernés confidentiels aussi longtemps que possible.

16:11 UTC Nous commençons à travailler sur les vulnérabilités du chapeau blanc.

Malheureusement, trop d'organisations mènent des recherches indépendantes en même temps et les rumeurs abondent. À 16h44 UTC, nous avons décidé de publier une déclaration publique concernant la version concernée [7] 。

À 18h32 UTC, nous avions un exploit de preuve de concept qui pourrait être utilisé pour un sauvetage potentiel de chapeau blanc. Le bpak de Chainlight travaille également sur une vulnérabilité en même temps et l'a partagée à 19h06 UTC.

Cinq minutes plus tard, à 19h11 UTC, quelqu'un a volé les fonds [8] 。

La structure d'attaque est très différente de notre preuve de concept et il est peu probable qu'il s'agisse d'une fuite de notre équipe. En tout cas, c'est très frustrant.

Pourtant, il y a beaucoup à faire.

21:26 UTC Addison a proposé un plan ambitieux pour sauver les actifs restants du pool CRVETH.

Si vous envoyez 30k crv au pool crv/eth, Vous pouvez mettre à jour les frais d'administration puis fixez le taux crv/eth autour de 0,15 eth par crv Fondamentalement, toutes les centaines de K crv du pool peuvent être extraites

21:52 UTC bpak a fait une preuve de concept qui pourrait économiser 3100 ETH.

Dix minutes plus tard, à 22h02 UTC, nous avons de nouveau été vaincus. Étonnamment, CRV gère des robots de dépenses [9] Les fonds ont été pris et la piscine est vidée [10] 。

blâmer

blâmer (Balme) est un mot fort. Pointer du doigt ne sert à rien. Je pense qu'il est utile de réfléchir à ce qui pourrait être amélioré.

Concours

Les efforts de White Hat ont tous été vaincus en moins d'une demi-heure. Parfois, chaque seconde compte.

Peut-être que ces attaques auraient pu être menées avec une meilleure préparation et des ressources. En même temps, cela semble être une épée à double tranchant. Est-ce vraiment une bonne idée de rassembler des informations sur la façon d'effectuer un hack ? À qui devons-nous faire confiance ?

D'un autre côté, je pense que l'ensemble du processus est très efficace. Nous sommes passés de la suspicion initiale à la confirmation de qui était vulnérable en 2 heures et 4 minutes.

Divulgation d'information

Je suis à la fois auditeur et pirate informatique.

L'industrie de l'audit a une culture éditoriale unique. Nous sommes payés pour notre leadership éclairé technique et notre compréhension approfondie des vulnérabilités. Une façon de démontrer leur leadership et leur profondeur est de publier [11] Le "scoop" sur le piratage. Les chercheurs coûtent cher et le retour sur investissement est de la publicité.

D'autre part, il existe un argument convaincant selon lequel une divulgation précoce d'une version affectée aurait un impact significatif sur un sauvetage whitehat.

Si cela avait été une demi-heure supplémentaire, 18 millions de dollars auraient pu être économisés.

Les auditeurs ne paient pas pour l'impact de leurs rapports. Au lieu de cela, ils obtiennent des likes, des retweets et une couverture. Cela semble être un problème.

L'étape suivante

Je ne suis pas d'accord avec "nous avons besoin d'une vérification formelle pour résoudre ce problème" et autres. Cette erreur peut être détectée par les tests unitaires. La vérification formelle est très utile pour de nombreux types d'erreurs, mais je ne pense pas qu'elle soit également utile pour les compilateurs relativement simples et non optimisés.

Notez que ce bug a été corrigé en novembre 2021 [12] 。

Je pense que cette vulnérabilité Vyper n'est pas un problème avec la technologie ou le langage de l'équipe Vyper elle-même, mais plutôt un problème de processus. Ce bogue a été corrigé il y a longtemps sans se rendre compte de son impact potentiel au moment du correctif.

Malheureusement, les biens publics sont facilement négligés. En raison de l'immuabilité des contrats, les projets reposent implicitement sur du code écrit il y a de nombreuses années. Les développeurs de protocoles et les experts en sécurité doivent être au courant des derniers développements en matière de sécurité dans la pile d'exécution.