Rapport d’incident et de recouvrement d’Elrond
traduit de l’article original de Andrei Marinica, Jun 11, 2022
Tard dans la nuit du dimanche 5 juin 2022, de nombreuses activités suspectes ont commencé à être signalées sur le réseau principal d’Elrond, notamment d’importants transferts d’EGLD et d’importants échanges sur le DEX Maiar. L’équipe s’est rapidement réunie pour enquêter sur cette activité, dans ce qui allait devenir une nuit longue et cruciale. Maintenant que la poussière est retombée, les vulnérabilités corrigées, la majorité des fonds manquants récupérés et que tous les systèmes fonctionnent, cela vaut la peine de regarder en arrière et de retracer ce qui s’est réellement passé au cours des 5 derniers jours.
Que s’est-il réellement passé ?
Tout commence par le déploiement d’une nouvelle fonction VM sur le réseau principal. Le point de terminaison en question est appelé “execute on destination context by caller”, “executeOnDestContextByCaller” comme le voient les contrats. Il est très similaire au “contexte d’exécution sur destination”, plus courant, que nous utilisons pour les interactions synchrones sur le même fragment entre les contrats, mais avec une mise en garde : l’action se produit comme si elle était directement envoyée par l’appelant d’origine de la transaction.
Décomposons-le étape par étape : disons que l’utilisateur A appelle le contrat B, qui à son tour appelle le contrat C en utilisant “executeOnDestContextByCaller”. Le contrat C reçoit une transaction de B qui semble avoir été envoyée directement par l’utilisateur A. Pourquoi voudrions-nous cette fonctionnalité ? Disons par exemple que l’utilisateur A essaie de créer un NFT pour lui-même en utilisant un contrat de frappeur NFT (contrat B), mais veut être le créateur du NFT. Normalement, le contrat B est le créateur, car il appelle la fonction NFT mint elle-même, mais en utilisant “executeOnDestContextByCaller”, le NFT semble avoir été créé directement par l’utilisateur A.
Jusque là tout va bien. La semaine dernière, un petit groupe de développeurs de la communauté tente de construire un contrat de loterie capable de résister à toutes sortes d’exploits. Le problème est que les utilisateurs de cette loterie peuvent en principe annuler toute transaction où ils ne gagnent pas en utilisant un contrat intelligent, gagnant effectivement 100% du temps (il s’agit d’un défaut plus large dans cette conception de contrat de loterie particulière, mais cette discussion est hors du cadre de cet article). Le contrat est corrigé pour ne pas autoriser les appels provenant d’autres contrats, mais quelqu’un trouve une solution de contournement en utilisant “executeOnDestContextByCaller”. Maintenant, le contrat de loterie peut être amené à croire qu’un portefeuille ordinaire a envoyé une transaction qui provenait vraiment d’un autre contrat.
Une vague d’activités s’ensuit sur la chaîne de développement officielle, alors que la communauté joue avec cette fonction, jusqu’à ce que quelqu’un remarque quelque chose d’inquiétant. Le contrat B peut également transférer des fonds au nom de l’appelant (utilisateur A) en utilisant cette fonction. Un utilisateur pourrait être amené à envoyer une transaction à un contrat malveillant, sans fonds, pour voir son portefeuille vidé par ledit contrat.
Pour s’assurer que nous ne voyons pas une vague d’escroqueries utilisant cet exploit, l’équipe d’Elrond publie rapidement un correctif, interdisant tous les transferts de valeur via “executeOnDestContextByCaller”. La mise à niveau du réseau est un processus complexe et sensible, donc pour le faire correctement, il faut normalement au moins une semaine pour qu’un correctif atteigne le réseau principal. La raison en est qu’il faut 2 à 4 jours pour valider le correctif, plus plusieurs jours pour le proposer et donner aux validateurs suffisamment de temps pour l’adopter et la mettre à niveau. Le patch est censé entrer en vigueur le lundi 8, au changement d’époque. À ce stade, le temps restant est assez court pour qu’un escroc régulier construise et déploie une dApp malveillante, et les utilisateurs pourraient toujours être avertis de rester à l’écart, de sorte que le danger semble minime.
Mais si c’était juste ça nous ne serions pas ici pour discuter de cela.
Le week-end venu, la communauté continue de jouer avec la fonctionnalité et tombe accidentellement sur quelque chose de plus sinistre. Le sharding est sans doute l’aspect le plus complexe concernant Elrond, et pour qu’il puisse prendre vie, vous avez besoin de contrats pour communiquer correctement entre les fragments. Les appels synchrones de type EVM ne suffisent pas pour cela, donc les contrats sur Elrond envoient la plupart du temps des appels dits asynchrones à d’autres contrats et attendent un rappel pour confirmer si les choses se sont bien passées ou non de l’autre côté. Les appels asynchrones fonctionnent de manière similaire dans le meme shard, dans ce cas, le rappel intervient immédiatement après la fin de l’appel asynchrone. La communauté a découvert que vous pouviez appeler “executeOnDestContextByCaller” dans un rappel, auquel cas un contrat malveillant pourrait effectuer des actions non pas au nom de son appelant, mais au nom de tout contrat qu’il est censé appeler.
C’est vrai, en utilisant “executeOnDestContextByCaller” dans un rappel asynchrone, un attaquant est capable de vider EGLD de n’importe quel contrat qu’il veut, et il n’y a rien que le contrat de la victime puisse faire pour éviter cela.
Il y a quelques restrictions : l’attaque ne fonctionne que si le contrat malveillant et la cible se trouvent dans le même fragment, de sorte que tous les EGLD stakés sont hors de portée, car ils résident sur la métachaîne. Les jetons ESDT sont également sûrs, car pour les transférer, le contrat malveillant doit appeler une fonction intégrée, comme “ESDTTransfer”, ce que la VM interdit dans ce cas. Ici ce sont toutes les bonnes nouvelles.
De manière déconcertante, ces découvertes sont discutées assez nonchalamment sur le canal public Elrond Developers pendant le week-end, sans soulever d’alarme aux problèmes de sécurité ou de sûreté. Étant donné qu’un correctif est connu pour arriver sur le réseau en 2 jours, peu d’attention est accordée à la divulgation responsable et à l’action immédiate.
L’Attaque
L’attaquant, encore inconnu, choisit dimanche soir comme heure de l’attaque, moins de 36 heures avant la fermeture de la fenêtre d’opportunité.
Il (ou elle/ils ?) cible probablement le pot de miel EGLD le plus important : le contrat egld-esdt-swap. Il s’agit du contrat qui crée et échange Wrapped EGLD (WEGLD) vers et depuis EGLD. C’est un contrat très simple et sécurisé : tous les utilisateurs qui ont besoin de WEGLD doivent déposer le même montant d’EGLD dans ce contrat, de sorte que le montant d’EGLD stocké ici est égal à tous les WEGLD là-bas.
Il y a un de ces contrats d’échange déployé dans chacun des 3 fragments réguliers, l’attaquant les cible tous. Pour accéder aux fonds, il crée des portefeuilles dans tous les fragments et déploie une copie du contrat malveillant dans chacun.
Un de ces contrats peut être vu ici:
https://explorer.elrond.com/accounts/erd1qqqqqqqqqqqqqpgq8urd3mza45z6th63h52e00zpgvrc5zxll9cshfqmhg
Nous n’avons pas les sources d’origine, mais cela doit ressembler au code suivant:
À ~ 1h EEST du matin (minuit Heure Paris), l’attaque commence. Il envoie les transactions dont les rappels drainent les EGLD des contrats de swap, comme suit :
- Sur le Shard 0: 400k EGLD
- Sur le Shard 1: 800k EGLD
- Sur le Shard 2: 450k EGLD
Maintenant, les choses sont un peu plus compliquées que cela. Si la description technique de l’attaque ne vous intéresse pas, n’hésitez pas à sauter les quelques paragraphes suivants.
En fait, l’attaquant déploie un contrat supplémentaire en plus du contrat malveillant dans chaque fragment, vraisemblablement pour masquer les transactions ou le contrat malveillant. Cela porte le total à 6 contrats déployés. Il utilise également 2 portefeuilles différents dans chaque Shard, un pour lancer l’appel et un pour sortir l’EGLD.
Les petits fonds initiaux pour l'attaque proviennent tous du hot wallet Binance erd16x7le8dpkjsafgwjx0e5kw94evsqw039rwp42m2j9eesd88x8zzs75tzry.
Malheureusement, le transfert intra-shard qui draine les fonds n’est actuellement pas visible dans l’explorateur, mais une nouvelle mise à jour le rendra bientôt disponible. Cela semble avoir conduit à une certaine confusion dans la communauté quant à la manière dont l’attaquant a obtenu les fonds.
Maintenant, l’attaquant essaie d’une manière ou d’une autre de sortir ce trésor de la chaîne Elrond.
Son plan est d’utiliser le Maiar Exchange pour l’échanger contre des tokens transférables sur le réseau Ethereum. Pour ce faire, la première étape consiste à wrapper l’EGLD volé, qui, ironiquement, doit avoir lieu dans les contrats mêmes qu’il vient de pirater. Cette fois, il utilise correctement les fonctions des contrats, comme prévu, en renvoyant l’EGLD volé au contrat et en recevant un nouveau WEGLD à la place. Mais comme il a utilisé un EGLD volé pour ce faire, le WEGLD qu’il reçoit n’est plus correctement “backé” 1:1 avec EGLD dans le pool, nous pouvons donc le considérer comme un “WEGLD piraté” qui se propagera désormais sur le réseau.
Il en convertit ensuite une grande partie en USDC dans le Maiar Exchange, mais le pool de liquidités, bien qu’important, ne fait pas le poids face à une somme aussi gargantuesque. Il fait ainsi plonger à lui seul le prix EGLD dans le pool de liquidités à environ 4 $, vendant son WEGLD piraté à perte énorme. Les robots d’arbitrage fonctionnant sur le LP à cette heure font de sérieux bénéfices, mais n’ont pas le volume nécessaire pour faire remonter le prix avant que l’échange ne soit interrompu par l’équipe.
Il ne centralise pas les fonds volés dans un seul portefeuille, mais continuera à utiliser les deuxièmes portefeuilles de chaque fragment (voir dans le tableau) pour interagir avec le Maiar Exchange en parallèle. Il y a une limite de transaction de 200 000 $ sur le pont et pour une raison quelconque, il ne se contente pas de partager le montant lors de l’utilisation du pont, mais également lors de l’interaction avec l’échange. Il en résulte de très nombreuses interactions avec les pools de liquidités, trop nombreuses pour être énumérées ici, mais les lecteurs curieux peuvent les consulter dans l’explorateur :
Shard 0: https://explorer.elrond.com/accounts/erd16syfkds2faezhqa7pn5n8fyjkst70l5qefpmc0r960467snlgycq4ww0rt
Shard 1: https://explorer.elrond.com/accounts/erd1cura2qq8skel5fsxrpxyysjkaw6durengtkencrezkw78y6y2zhscf854j
Shard 2: https://explorer.elrond.com/accounts/erd1yrf9qeuqkcjeh5c4xn628mags7cse4r9ra2p2ggmlgfqq3l3v6pqxfu950
Voyant qu’il a fait chuter le prix EGLD dans le pool EGLD-USDC et qu’il vend à perte énorme, il convertit également une partie du montant en UTK, dont il transfère également une partie sur le réseau Ethereum.
Note technique : les jetons ETHUSDC et ETHUTK que vous voyez dans les transactions sont des jetons intermédiaires utilisés par le pont. USDC et UTK, respectivement, doivent être convertis avant de pouvoir être pontés.
Le montant total qu’il parvient à envoyer sur Ethereum avant que le pont ne soit temporairement désactivé est d’environ 4 millions USDC et 1 million UTK. Un autre 1,4 million d’USDC sont gelés dans le pont par l’équipe, avant que l’attaquant n’ait la possibilité de le retirer.
Toute cette activité sur l’exchange et sur le pont commence bientôt à déclencher des alarmes, et l’équipe se rassemble rapidement pour enquêter sur l’incident.
L’attaque est circonscrite.
La première priorité est de limiter au maximum les dégâts. L’échange, le swap Wrapped EGLD et le pont sont immédiatement mis en pause. A noter que l’activité sur le pont ne peut être suspendue que dans des circonstances exceptionnelles, de vie ou de mort, et avec l’accord des relais de confiance du pont.
L’API publique est maintenue mais la fonction d’envoi est désactivée, de sorte qu’aucune transaction ne peut passer par elle. Cependant, l’attaquant ne s’appuie pas sur la passerelle publique et cela ne le décourage pas.
Enfin, de nombreux ESDT ont une fonction de gel s’ils sont configurés à la frappe ou à la création. Notez que toutes les pièces stables, par exemple, ont cette fonction activée sur toutes les chaînes, pour des raisons de sécurité évidentes. En l’utilisant, l’équipe est en mesure de geler temporairement tous les transferts USDC et UTK. EGLD(Ndt:natif pas le WEGLD), en revanche, ne peut pas être gelé, l’attaquant est donc libre de le déplacer.
Dans le même temps, l’équipe est également en contact avec tous les Exchanges principaux, faisant circuler une liste noire, pour empêcher l’attaquant d’y extraire l’EGLD. De même, l’équipe est également en pourparlers avec les forces de l’ordre pour lancer plusieurs enquêtes.
Vient ensuite la tâche principale de correction de la vulnérabilité dès que possible. Il est clair qu’attendre l’activation du patch régulier programmé à 18H EEST (ndt:changement d’EPOCH) est inacceptable compte tenu de la gravité de la situation. Un correctif d’urgence est prêt à 7h07 EEST et en quelques minutes, les messages commencent à circuler sur les canaux avec les validateurs.
Étant donné que l’équipe ne contrôle actuellement qu’une minorité des nœuds de validation, la large participation de la communauté des validateurs, via un consensus exigeant et une gouvernance hors chaîne, est nécessaire et importante même pour une telle mise à jour de correctif d’urgence. Cela signifie communiquer le correctif, la proposition et l’adoption. En principe, plus de 66 % des nœuds sont nécessaires pour adopter un changement en toute sécurité, de sorte que la majorité des agences de jalonnement doivent être de la partie.
Il est décidé de réparer les choses sur place et aussitôt pendant l’époque en cours. Pour éviter toute complication lors de la mise à niveau, la communauté doit agir avec la plus grande rapidité. L’équipe a des plans d’urgence pour tout événement possible pendant la mise à niveau, mais c’est plus facile si cela n’arrive pas. Une fois qu’au moins ~67 % des nœuds ont été mis à niveau, tout danger potentiel est écarté.
Par chance, à 7h EEST, une grande partie de la communauté des validateurs est réveillée et prête à l’action. L’équipe effectue les tests finaux pour la construction et 20 minutes plus tard, la mise à niveau commence. Il faut environ une demi-heure pour que la majeure partie du réseau exécute la nouvelle version. Tout se passe bien et sans incident ni temps d’arrêt pour le réseau, au grand soulagement de tous. La réponse des validateurs est irréprochable. Les contrats sont à nouveau en sécurité.
Conséquences immédiates
Lundi matin, aux aurores, la crise immédiate est évitée, mais les fonds manquent toujours et l’équipe ne sait pas si le correctif du matin est une solution complète, ou bien s’il pourrait y avoir plus de vulnérabilités cachées.
Une partie de l’équipe profite de la journée pour tester d’autres scénarios et réfléchir à d’autres exploits potentiels. Bien qu’aucune autre vulnérabilité ne semble se cacher dans le code, l’équipe se sent toujours mal à l’aise quant à l’existence continue de la fonction “executeOnDestContextByCaller”. Pour apaiser d’autres soupçons, il est finalement décidé d’avoir un autre deuxième patch le même jour, dans lequel “executeOnDestContextByCaller” est complètement supprimé. Les avantages de disposer de cette fonction ne l’emportent plus sur les risques. Ce patch arrive lundi soir, et cette fois la mise à jour se fait selon le protocole, et relativement sans souci.
Une autre partie de l’équipe étudie des solutions pour récupérer les fonds. Entre-temps, la plupart des fonds ont été récupérés auprès des agresseurs, mais comme il s’agit toujours d’une enquête ouverte, pour des raisons juridiques, nous ferons un suivi avec un aperçu plus détaillé dès que l’enquête sera close.
Le calme revient
Mardi matin, la plupart des fonds sont récupérés et l’équipe commence à restaurer l’état précédant l’attaque.
Tout d’abord, le pool de liquidités EGLD-USDC est toujours déséquilibré. Afin de récupérer entièrement ce qui a été perdu, c’est l’équipe d’Elrond qui doit racheter l’EGLD qui a été vendu par l’attaquant et le ramener au juste prix du marché.
Il n’y a pas encore de mécanisme de liste blanche dans le DEX, donc l’équipe doit d’abord le mettre en œuvre. C’est le seul moyen pour l’équipe d’effectuer les swaps avant de rouvrir les contrats au public. Aucun raccourci n’est acceptable : la nouvelle version du contrat LP est testée en profondeur pendant plusieurs heures avant le déploiement.
Il en va de même pour la paire EGLD-UTK, l’équipe doit vendre l’UTK volé de la même manière qu’il a été acheté par l’attaquant pour récupérer le WEGLD exploité.
Deuxièmement, le contrat swap Wrapped EGLD doit être rééquilibré. Dans des circonstances normales, il y a toujours un ratio de 1:1 entre EGLD dans le contrat et WEGLD, mais à cause de l’attaque, cet équilibre est rompu. L’excédent de WEGLD doit être brûlé.
C’est plus délicat que prévu. L’attaquant a converti une grande partie de l’EGLD volé en WEGLD, puis en a jeté la majeure partie dans l’échange. Une partie de ce WEGLD a été perdue à cause des frais et des robots d’arbitrage qui fonctionnaient à l’époque, il y a donc encore un excès de WEGLD réparti sur tout le réseau.
L’attaquant accepte d’envoyer les fonds qui n’ont pas été pontés vers Ethereum à l’adresse de récupération suivante :
https://explorer.elrond.com/accounts/erd1pml9k2tsqsnvtmmalglt2su0sn3cguvr8e8jq0gy69zw2ldcej2qapml9a
Ainsi, le processus de récupération peut commencer. L’équipe commence par réparer les dommages causés aux pools de liquidités et aux contrats de swap WEGLD.
En rachetant WEGLD aux pools au prix auquel l’attaquant l’a vendu, une partie de la perte peut être récupérée. L’équipe effectue cela en plusieurs étapes plus petites, jusqu’à ce que le prix EGLD corresponde au prix EGLD actuel sur Binance (68,5 $ à ce moment-là). A noter que ce prix est un peu moins élevé qu’il ne l’était lors de l’attaque.
Tous les « WEGLD exploités » qui se sont propagés sur tout le réseau ne sont pas récupérés par l’équipe. L’équipe ne peut acheter que 728k WEGLD avec l’USDC et l’UTK retournés par l’attaquant.
Vient maintenant le temps des contrats d’échange. L’attaquant a volé 1650k EGLD des contrats, mais n’a converti que 917k EGLD en WEGLD. Une partie de ce WEGLD “double-frappé” a ensuite été vendue par les bots d’arbitrage après avoir réalisé des bénéfices. Cependant, la quantité n’est pas si importante. Ce qui est important, c’est qu’il y a 1650 000 WEGLD de plus que EGLD dans les contrats. (ndt:déséquilibrant le ratio 1:1)
Il y a 2 façons d’éliminer cette différence : brûler WEGLD ou ajouter EGLD manquant aux contrats.
L’équipe opère sur les 2:
a. Les 728k WEGLD achetés à l’échange sont brûlés dans la transaction suivante :
b. Les 922 000 EGLD restants sont directement intégrés aux contrats, sans frapper de WEGLD supplémentaires. Cela se fait via un point de terminaison de “rééquilibrage” écrit spécifiquement pour cette occasion. 200k de l’EGLD utilisé dans cette opération proviennent de la réserve de la Fondation Elrond. Les opérations de rééquilibrage sont les suivantes :
Enfin, après de nombreuses autres séries de vérifications et de tests, l’exchange Maiar n’est plus suspendu et les services reprennent leur fonctionnement normal le mercredi 8 juin.
Erreurs de compréhensions et d’interprétations
Au lendemain de l’attaque, la communauté était en effervescence avec des théories et des suppositions sur ce qui s’était passé. Quelques-uns ont bien compris les événements, mais beaucoup d’autres ont succombé à la confusion et à la désinformation.
Pour dissiper les idées fausses les plus courantes :
- “C’était une attaque DEX”. Ce n’était pas le cas, le DEX a fonctionné comme prévu tout le temps. Deux des pools de liquidités se sont déséquilibrés lors de la vente massive, mais le DEX n’a pas été la cible de cette attaque.
- “C’était un problème de liquidité/quelque chose de similaire à UST/LUNA”. Non, cet exploit n’a rien à voir avec le récent effondrement de l’écosystème Terra. À aucun moment, ce n’était un problème de sous-garantie, c’était du pur vol.
- “C’était une attaque de bridge”. Non, le pont a fonctionné comme prévu. Certains des fonds ont été transférés vers Ethereum, période pendant laquelle le pont a fonctionné comme prévu. Il a ensuite été désactivé exprès, pour empêcher que davantage de fonds ne quittent l’écosystème.
- “C’était une attaque de contrat intelligent”. L’attaquant n’a exploité aucune vulnérabilité de code de contrat intelligent, le problème était dans la machine virtuelle. Il n’y avait pas de bogue dans le contrat egld-esdt-swap lui-même.
- “L’attaquant a réussi à frapper EGLD à partir de rien”. Non, tout l’EGLD a été volé directement du solde du contrat intelligent egld-esdt-swap. l’EGLD volé était déjà là.
- “L’attaquant a réussi à frapper WEGLD à partir de rien”. C’est en partie vrai. Bien que l’attaquant n’ait pas exploité WEGLD directement, en enveloppant l’EGLD volé, le résultat a été qu’il y avait plus de WEGLD en circulation qu’il n’aurait dû , 900 000 WEGLD pour être précis. Cela équivaut à frapper illégalement WEGLD sans support. L’équipe a réussi à récupérer ce WEGLD illégal et l’a brûlé, donc à l’heure actuelle, chaque jeton WEGLD est à nouveau soutenu par 1 EGLD. (ndt: le ratio 1 EGLD : 1 WEGLD est rétabli)
- “La blockchaîne Elrond a été désactivée”. À aucun moment la blockchaîne n’a été désactivée, ni inactive. Des blocs et même certaines transactions ont été ajoutés pendant tout le temps. Seul le point de terminaison de transactions d’envoi de l’API publique a été désactivé.(ndt: les transactions ajoutés ont été faites par des points de terminaison API privés)
- “Il s’agissait d’un « travail de l’intérieur » ”. L’une des informations erronées les plus flagrantes est la théorie selon laquelle quelqu’un de l’équipe l’aurait fait. Il est absurde de croire que quelqu’un travaillant sur un projet pendant des années mettrait ledit projet en péril, tout en risquant sa propre liberté personnelle pour un profit rapide.
- “Le piratage “blackhat(1)” en vaut la peine”. Même si vous réussissez à réussir un piratage, il est très difficile de retirer les fonds. Même les pirates les plus qualifiés laissent des traces partout, tous les CEX ont mis en place des KYC et il est presque impossible d’échapper à la loi. Si vous trouvez une vulnérabilité logicielle, la chose la plus intelligente à faire est de la signaler à l’équipe. Cela vous rapportera une belle prime tout en vous gardant du bon côté de la loi, libre d’explorer le monde en dehors de la prison.
Leçons apprises, étapes suivantes
Le logiciel est difficile. La blockchaîne est difficile. Écrire une machine virtuelle à partir de zéro est également très difficile, mais cela en vaut la peine si vous recherchez vraiment la vitesse, la sécurité et l’évolutivité, ainsi qu’un impact significatif sur le monde.
Parfois, les choses tournent mal. Ce n’est évidemment pas quelque chose que nous devons accepter, c’est quelque chose que nous devons surmonter. La décentralisation est ce que nous recherchons tous, mais elle ne fait pas bon ménage avec les bogues et les vulnérabilités.
Nous ne serions pas en mesure de maintenir le réseau aussi décentralisé qu’il l’est sans une communauté de validateurs aussi réactive et engagée. Ils ont vraiment brillé au moment d’intensité maximale.
Les créateurs de contrats et de jetons ESDT peuvent choisir de s’octroyer le pouvoir d’arrêter temporairement lesdits contrats et jetons ESDT en cas de crise. Dans de tels événements malheureux, l’importance et la nécessité des précautions auxiliaires peuvent être clairement comprises. Au fur et à mesure que la technologie mûrira, nous verrons ce pouvoir être abandonné progressivement et en toute sécurité via différentes formes de gouvernance.
Quant au code lui-même, il y a 3 façons de s’assurer qu’il fonctionne correctement : les tests, le temps et les mathématiques. Les tests ne sont clairement pas suffisants pour les infrastructures complexes et critiques. Le temps finit par révéler et éliminer toutes les vulnérabilités cachées, mais c’est un processus douloureux et plein d’embûches. La meilleure approche est d’y réfléchir profondément, de le modéliser mathématiquement, de le simuler et de l’auditer, et c’est quelque chose dans lequel nous devons investir davantage à l’avenir. Nous avons déjà des modèles partiels de la VM et de nombreux outils pour tester l’exactitude de notre code, nous avons juste besoin d’en tirer le meilleur parti et de les développer davantage. Des événements comme celui-ci sont une évaluation intense de nos normes et méthodologies d’ingénierie.
Hélas, cette semaine commence un nouveau chapitre dans l’histoire d’Elrond. Nous avons décidé de repenser non seulement notre architecture de sécurité, mais toute notre philosophie de création de logiciels.
Cette semaine déjà, nous avons identifié plusieurs fronts sur lesquels la lutte sera menée pour éliminer les vulnérabilités . Il y a déjà plusieurs équipes à la recherche de problèmes dans le protocole, la VM, les services et le frontend. Nous avons également examiné quels outils peuvent apporter les résultats les plus complets le plus rapidement, et avons déjà commencé à développer certains d’entre eux.
Le processus interne consistant à signaler les problèmes de sécurité potentiels, à faire émerger les problèmes et à les traiter avec la plus grande rapidité et minutie a également été réitéré et simplifié. Le processus externe de divulgation responsable de la sécurité, via l’envoi d’un e-mail à security@elrond.com, et la réception d’une grosse prime pour tout bogue valide et significatif, sera constamment porté à l’attention de tous les membres de la communauté, pour aider à renforcer ce comportement constructif.
Dire que ces quelques jours ont été difficiles est un euphémisme. En fin de compte, rien d’important ne peut être construit sans difficultés. Étant donné que les difficultés viendront invariablement, nous ferons de notre mieux pour nous préparer, fortifier notre détermination et renforcer notre réponse face à cela.
Après tout cela, le Maiar DEX, Les API et les échanges sont entièrement live et opérationnels.
Tous les fonds sont en sécurité, tous les utilisateurs sont en sécurité.
Quelle force et quelle joie tenaces ces mots véhiculent !
Avec ces nouvelles leçons apprises, nous allons ouvrir un nouveau chapitre pour Elrond. Venez construire avec nous. Fortifions ce réseau ensemble.
Article original traduit en français :https://elrond.com/blog/incident-and-recovery-report/ par Andrei Marinca
Pour plus d’information, vous pouvez consulter :
- Le Livre économique (🇫🇷economic paper)
- Le Livre Blanc (🇫🇷whitepaper)
- Elrond Github
- Community platform
- Elrond Documentation
