Contournement de la couche zéro

Depuis le début de L2BEAT, nous avons déployé beaucoup d'efforts pour analyser et comprendre les risques associés aux protocoles L2. Nous faisons de notre mieux pour être un chien de garde impartial et indépendant, agissant dans le meilleur intérêt des utilisateurs et de l'écosystème. Nous ne laissons pas nos préférences personnelles pour le projet ou l'équipe impliquée nous gêner. C'est pourquoi il est courant que nous ayons besoin d'activer des alertes rouges ou de signaler nos préoccupations dans divers protocoles, même si nous apprécions le temps et le travail consacrés par les équipes spécifiques à leurs projets. Avoir des discussions sur la sécurité dès le début permet à l'ensemble de l'écosystème de mieux se préparer aux risques potentiels et de réagir plus tôt à tout comportement suspect.

Aujourd'hui, nous aimerions ouvrir un débat sur les modèles de sécurité partagés des applications inter-chaînes. Actuellement, il existe deux approches : la sécurité partagée et la sécurité par application. La première, la sécurité partagée, est utilisée, par exemple, par tous les rollups. La seconde, la sécurité par application, est utilisée par les projets « omnichain ». Le meilleur exemple d'un tel projet est LayerZero.

Sécurité partagée vs sécurité isolée

Par sécurité partagée, nous entendons que des jetons ou des applications spécifiques exécutés sur une infrastructure donnée ne choisissent pas librement leur modèle de sécurité. Au lieu de cela, ils doivent obéir aux exigences de sécurité imposées par l'infrastructure. Par exemple, les cumuls optimistes imposent généralement une fenêtre de finalité de 7 jours - les applications exécutées sur de tels cumuls ne peuvent pas simplement ignorer ou raccourcir cette période. Cela peut sembler être un obstacle, mais c'est un obstacle mis en place pour une raison. Il permet de fournir aux utilisateurs une garantie de sécurité qu'ils peuvent s'attendre à être détenu par l'application qu'ils utilisent sur ce rollup, quelle que soit la politique de sécurité interne des applications. L'application peut seulement renforcer la politique des cumuls, pas l'affaiblir.

Par sécurité isolée, nous entendons que chaque application est responsable de la définition de sa sécurité, sans être limitée par l'infrastructure en aucune façon. Au début, cela peut sembler être une bonne idée. Après tout, ce sont les développeurs d'applications qui connaissent le mieux les mesures de sécurité dont l'application peut avoir besoin. Mais en même temps, il transfère la responsabilité de l'évaluation des risques associés à la politique de sécurité de chaque application à l'utilisateur final. De plus, si les développeurs d'applications sont libres de choisir leur politique d'application, ils peuvent également choisir de la modifier à tout moment. Il ne suffit donc pas d'évaluer les risques une fois pour chaque application, ils doivent être évalués à chaque fois que la politique des applications change.

Le problème

Nous pensons que le modèle de sécurité isolé où chaque application peut définir librement sa politique de sécurité pose de sérieux problèmes de sécurité. Tout d'abord, cela augmente les risques pour les utilisateurs finaux, car ils doivent valider séparément les risques encourus avec chaque application qu'ils ont l'intention d'utiliser.

Cela augmente également le risque pour les applications utilisant un tel modèle. La sécurité isolée ajoute un risque supplémentaire concernant le changement de politique de sécurité - si l'attaquant parvient à modifier le modèle de sécurité de l'application, il peut tout aussi bien le désactiver, offrant la possibilité de drainer les fonds ou de l'utiliser à mauvais escient de toute autre manière. Il n'y a pas de couche de sécurité supplémentaire au-dessus de l'application qui protégerait contre les abus.

De plus, avec des politiques de sécurité capables de changer instantanément à tout moment, il devient pratiquement impossible de surveiller quotidiennement les applications et d'informer les utilisateurs des risques.

Nous le trouvons similaire à l'évolutivité des contrats intelligents. Nous le mettons déjà en garde chez L2BEAT . Nous informons les utilisateurs des cumuls et des ponts qui ont des mécanismes d'évolutivité dans leurs contrats intelligents, ainsi que du mécanisme exact régissant l'évolutivité dans chaque cas. C'est déjà assez complexe et avec un modèle de sécurité isolé, cela se multiplie pour chaque application, ce qui rend presque impossible un suivi efficace.

C'est pourquoi nous considérons un modèle de sécurité isolé comme un risque de sécurité en soi, et nous postulons de traiter chaque application utilisant un tel modèle comme risquée par défaut jusqu'à preuve du contraire.

Le plan

Nous avons décidé de tester nos hypothèses dans le monde réel, sur le réseau principal. Le framework LayerZero a été choisi pour l'expérience car il s'agit de l'une des solutions les plus populaires utilisant la sécurité isolée en son cœur. Nous avons déployé un jeton omnichain qui était sûr et plus tard, la configuration de sécurité a été mise à jour, ce qui a permis le retrait de jetons malveillants. Le code du jeton est basé sur les exemples fournis par LayerZero et est très similaire ou identique à de nombreux autres jetons et applications omnichain déployés en production.

Mais avant de plonger dans les détails, examinons brièvement à quoi ressemble le modèle de sécurité LayerZero.

Comme l'indique clairement le livre blanc de LayerZero, sa "communication inter-chaîne sans confiance" repose sur deux acteurs indépendants (l'oracle et le relais) agissant ensemble pour assurer la sécurité du protocole.

Comme l'indique LayerZero sur son site Web, son concept de base est qu'il s'agit d'un "point de terminaison en chaîne configurable par application utilisateur qui exécute un ULN (UltraLightNode)". Les composants en chaîne de LayerZero s'appuient sur deux parties externes hors chaîne pour relayer les messages entre les chaînes - l'Oracle et le Relayer.

Chaque fois qu'un message M est envoyé de la chaîne A à la chaîne B, les deux actions suivantes ont lieu :

• d'abord, l'Oracle attend que la transaction envoyant le message M sur la chaîne A soit finalisée, puis écrit sur la chaîne B l'engagement pour le paquet de messages, par exemple, le hachage de l'en-tête du bloc (le format exact peut varier entre différentes chaînes/oracles) à la chaîne A contenant ce message M
• puis le Relayer envoie à la chaîne B une "preuve" (par exemple une Merkle Proof) que l'en-tête stocké contient le message M

LayerZero affirme que "la conception de LayerZero élimine la possibilité de collusion". Mais en fait, cette affirmation n'est pas vraie (ce que nous prouvons dans l'expérience présentée ci-dessous), car chaque application utilisateur peut définir son propre Relayer et Oracle. LayerZero ne garantit pas par conception que ces composants sont indépendants et qu'ils ne peuvent pas s'entendre. C'est à l'application utilisateur de fournir ces garanties. Et si l'application choisit de les casser, rien dans la mécanique de LayerZero ne peut l'empêcher de le faire.

De plus, par défaut, toutes les applications utilisateur peuvent changer de relais et d'Oracle à tout moment, redéfinissant complètement les hypothèses de sécurité. Il ne suffit donc pas de vérifier la sécurité de l'application donnée une fois, car elle peut avoir changé à tout moment après la vérification, comme nous le montrerons dans notre expérience.

L'expérience

Dans notre expérience, nous avons décidé de créer un jeton omnichain simple, CarpetMoon, fonctionnant à la fois sur Ethereum et Optimism, en utilisant ZeroLayer pour communiquer entre les deux chaînes.

Notre jeton utilise initialement le modèle de sécurité par défaut fourni par LayerZero, il ressemble donc à peu près à la plupart (sinon la totalité) des applications LayerZero actuellement déployées. Ainsi, il est généralement aussi sécurisé que tout autre jeton utilisant LayerZero.

Premièrement, nous déployons nos contrats de jetons à la fois sur Ethereum et sur Optimism :
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

Et nous configurons le routage pour que LayerZero sache quel contrat correspond à quel contrat sur les deux chaînes :
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

Ainsi, le jeton est configuré, il ressemble exactement à tous les autres jetons omnichain utilisant LayerZero, avec la configuration par défaut, rien de suspect.

Nous fournissons à notre utilisateur de test, appelons-la Alice, des jetons de test, donc Alice a 1 milliard de jetons CarpetMoon sur Ethereum :
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

Maintenant, Alice relie ces jetons à Optimism en utilisant LayerZero.

Nous verrouillons les jetons dans un séquestre sur Ethereum :
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/

Le message avec la transaction est remis à Optimism via LayerZero :
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/nonce/1

Et des jetons pontés sont frappés sur Optimisme, Alice a maintenant 1 milliard de jetons MoonCarpet sur Optimisme :
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302

Ok, donc tout a fonctionné comme prévu, Alice a ponté ses jetons et a vu qu'il y avait 1 milliard de jetons MoonCarpet dans le séquestre sur Ethereum et 1 milliard de jetons MoonCarpet sur son compte chez Optimism. Mais pour s'assurer que tout fonctionne correctement, elle transfère la moitié des jetons (500M MoonCarpet) à Ethereum.

Nous commençons donc par la transaction en brûlant 500 millions de jetons sur Optimism :
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f

Les informations sur cette transaction sont transmises à Ethereum :
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1

Et, comme prévu, 500 millions de jetons MoonCarpet sont renvoyés à l'adresse d'Alice par le tiers de confiance :
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18

Jusqu'à présent, tout fonctionne bien, exactement comme prévu. Alice avait vérifié qu'elle pouvait transférer des jetons d'Ethereum vers Optimism et inversement, elle n'a aucune raison d'avoir peur de ses jetons MoonCarpet.

Mais disons que quelque chose ne va pas - par exemple, l'équipe derrière notre jeton est compromise et le mauvais acteur Bob accède à la configuration LayerZero pour notre application.

Avec un tel accès, Bob peut remplacer l'Oracle et le Relayer par défaut par ceux sous son contrôle.

Veuillez garder à l'esprit qu'il s'agit d'un mécanisme fourni à chaque application utilisant LayerZero, enraciné dans l'architecture de LayerZero, ce n'est pas une sorte de porte dérobée mais plutôt un mécanisme standard.

Alors Bob change l'Oracle en un EOA sous son contrôle :
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/

Et fait de même avec le Relayer :
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/

Et maintenant, des choses étranges se produisent. Avec Oracle et Relayer maintenant sous le contrôle total de Bob, il est capable de voler les jetons d'Alice. Même si aucune action n'a lieu sur l'Optimism (les jetons MoonCarpet sont toujours dans le portefeuille d'Alice là-bas), Bob est capable de convaincre le contrat intelligent MoonCarpet sur Ethereum (en utilisant des mécanismes LayerZero) qu'il a brûlé des jetons sur une autre chaîne et il est capable de retirer les jetons MoonCarpet sur Etherum.

Tout d'abord, il met à jour le blockhash chez Ethereum à l'aide d'Oracle voyou :
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/

Et maintenant, il peut retirer les jetons restants du séquestre :
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/

Le résultat

Alice ne saura même pas pourquoi et quand quelque chose de mal s'est produit. Soudain, ses jetons MoonCarpet chez Optimism ne sont plus soutenus par des jetons sur Ethereum.

Les contrats intelligents ne peuvent pas être mis à niveau et agissent comme prévu. La seule activité suspecte est le changement d'Oracle et de Relayer, mais il s'agit d'un mécanisme régulier intégré à LayerZero, donc Alice ne peut même pas savoir si ce changement était intentionnel ou non. Et même si Alice apprenait ce changement, il serait déjà trop tard – l'attaquant est capable de drainer les fonds avant même qu'elle ne puisse réagir.

Et LayerZero ne pouvait pas aider ici non plus – il s'agissait de toutes les exécutions valides de leurs mécanismes, qu'ils ne peuvent plus contrôler. Théoriquement, l'application elle-même peut s'empêcher de changer l'Oracle et le Relayer, mais pour autant que nous sachions, aucune des applications déjà déployées ne l'a fait.

Nous avons fait cette expérience pour vérifier si quelqu'un le remarque, mais comme nous nous y attendions, personne ne l'a fait. Il est pratiquement impossible de surveiller efficacement toutes les applications construites avec LayerZero pour vérifier si leur politique de sécurité n'a pas changé et pour avertir les utilisateurs si cela se produit.

Même si l'on a pu rattraper qu'Oracle et Relayer avaient changé d'une manière qui pose des risques de sécurité, quand cela arrive, il est déjà trop tard. Comme les nouveaux Oracle et Relayer peuvent désormais librement choisir de censurer ou simplement de désactiver la communication entre les chaînes, les utilisateurs ne peuvent généralement rien y faire. Ceci est clairement montré dans notre expérience, car même si Alice remarque le changement dans la configuration de l'application, elle ne peut pas faire grand-chose avec ses jetons pontés — les nouveaux Oracle et Relayer n'écoutent plus sur la chaîne d'origine donc ils ne relaient pas le messages vers Ethereum.

Conclusions et CTA

Comme nous avons pu le voir ci-dessus, même si notre jeton a été construit à l'aide de LayerZero et a utilisé ses mécanismes comme prévu, nous avons pu voler des fonds du séquestre des jetons. Bien sûr, c'était une faute de l'application (jeton CarpetMoon dans notre cas) et non du LayerZero lui-même, mais cela prouve que LayerZero en lui-même n'apporte aucune garantie de sécurité .

Lorsque LayerZero décrit leur modèle de sécurité concernant Oracle et Relayer, ils supposent que les propriétaires d'applications (ou quelqu'un en possession de leurs clés privées) ne feront rien d'irrationnel. Mais cette hypothèse est incorrecte dans un environnement contradictoire. De plus, cela oblige les utilisateurs à faire confiance aux propriétaires de l'application en tant que tiers de confiance.

En pratique, à la suite de cela, on ne peut faire aucune hypothèse sur la sécurité des applications construites à l'aide de LayerZero - chaque application doit être considérée comme risquée jusqu'à preuve du contraire.

En fait, toute l'histoire a commencé pour nous avec un PR avec lequel nous avions prévu d'inclure tous les jetons omnichain sur le site L2BEAT - nous avons eu du mal à comprendre comment évaluer leurs risques. C'est en analysant les vecteurs de risque que nous avons eu l'idée de notre expérience.

Pour L2BEAT, les conséquences sont que nous devons mettre des alertes au-dessus de chaque application construite à l'aide de LayerZero, avertissant des risques de sécurité possibles. Mais nous aimerions ouvrir une discussion plus large sur les modèles de sécurité, car nous pensons que la sécurité isolée est un anti-modèle qui devrait être évité, en particulier dans notre espace.

Nous sommes convaincus qu'à mesure que les modèles de sécurité isolés tels que LayerZero deviennent de plus en plus populaires, il y aura de plus en plus de projets qui en abuseront, causant beaucoup de dégâts et augmentant l'incertitude sur l'ensemble de l'industrie.