Umgehung von Layer Zero

Seit Beginn von L2BEAT haben wir viel Mühe darauf verwendet, die mit L2-Protokollen verbundenen Risiken zu analysieren und zu verstehen. Wir tun unser Bestes, um ein unvoreingenommener, unabhängiger Wächter zu sein, der im besten Interesse der Nutzer und des Ökosystems handelt. Wir lassen uns nicht von unseren persönlichen Vorlieben für das Projekt oder das beteiligte Team in die Quere kommen. Aus diesem Grund ist es üblich, dass wir Alarmstufe Rot aktivieren oder in verschiedenen Protokollen auf unsere Bedenken hinweisen müssen, obwohl wir die Zeit und Arbeit schätzen, die die jeweiligen Teams in ihre Projekte investieren. Durch frühzeitige sicherheitsbezogene Diskussionen kann sich das gesamte Ökosystem besser auf potenzielle Risiken vorbereiten und früher auf verdächtiges Verhalten reagieren.

Heute möchten wir eine Debatte über gemeinsame Sicherheitsmodelle von Cross-Chain-Anwendungen eröffnen. Derzeit gibt es zwei Ansätze: Shared Security vs. Per-Application Security. Die erste, gemeinsame Sicherheit, wird beispielsweise von allen Rollups verwendet. Die zweite, die Sicherheit pro Anwendung, wird von „Omnichain“-Projekten verwendet. Das Paradebeispiel für ein solches Projekt ist LayerZero.

Geteilte Sicherheit vs. isolierte Sicherheit

Mit gemeinsamer Sicherheit meinen wir, dass bestimmte Token oder Apps, die auf einer bestimmten Infrastruktur ausgeführt werden, ihr Sicherheitsmodell nicht frei wählen. Stattdessen müssen sie alle Sicherheitsanforderungen erfüllen, die die Infrastruktur auferlegt. Beispielsweise sehen optimistische Rollups normalerweise ein 7-tägiges Endgültigkeitsfenster vor – Apps, die auf solchen Rollups ausgeführt werden, können diesen Zeitraum nicht einfach ignorieren oder verkürzen. Es mag wie ein Hindernis erscheinen, aber es ist ein Hindernis, das aus einem bestimmten Grund errichtet wurde. Es ermöglicht Benutzern eine Sicherheitsgarantie zu geben, die sie erwarten können, von der App gehalten zu werden, die sie auf diesem Rollup verwenden, unabhängig von der internen Sicherheitsrichtlinie der Apps. Die App könnte die Richtlinie der Rollups nur stärken, nicht schwächen.

Mit isolierter Sicherheit meinen wir, dass jede App für die Definition ihrer Sicherheit verantwortlich ist und in keiner Weise durch die Infrastruktur eingeschränkt wird. Auf den ersten Blick mag es wie eine gute Idee erscheinen. Schließlich wissen die App-Entwickler am besten, welche Sicherheitsmaßnahmen die App möglicherweise benötigt. Aber gleichzeitig überträgt es die Verantwortung für die Bewertung von Risiken, die mit der Sicherheitsrichtlinie jeder App verbunden sind, auf den Endbenutzer. Wenn die App-Entwickler ihre App-Richtlinie frei wählen können, können sie sie außerdem jederzeit ändern. Es reicht also nicht aus, die Risiken einmal für jede App zu bewerten, sie sollten jedes Mal bewertet werden, wenn sich die Richtlinien der Apps ändern.

Die Angelegenheit

Wir glauben, dass das isolierte Sicherheitsmodell, bei dem jede App ihre Sicherheitsrichtlinien frei definieren kann, ernsthafte Sicherheitsbedenken aufwirft. Erstens erhöht es die Risiken für die Endbenutzer, da sie die Risiken für jede App, die sie verwenden möchten, separat validieren müssen.

Es erhöht auch das Risiko für die Apps, die ein solches Modell verwenden. Isolierte Sicherheit fügt ein zusätzliches Risiko in Bezug auf die Änderung der Sicherheitsrichtlinien hinzu – wenn der Angreifer das Sicherheitsmodell für die Anwendung ändern kann, kann er es genauso gut einfach deaktivieren und so die Möglichkeit schaffen, das Geld abzuschöpfen oder es auf andere Weise zu missbrauchen. Es gibt keine zusätzliche Sicherheitsebene über der Anwendung, die vor Missbrauch schützen würde.

Darüber hinaus wird es mit Sicherheitsrichtlinien, die sich jederzeit sofort ändern können, praktisch unmöglich, Apps täglich zu überwachen und Benutzer über die Risiken zu informieren.

Wir finden es ähnlich wie die Upgradefähigkeit von Smart Contracts. Davor warnen wir bei L2BEAT schon jetzt . Wir informieren Benutzer über Rollups und Bridges, die Upgrade-Mechanismen in ihren Smart Contracts haben, sowie über den genauen Mechanismus, der die Upgrade-Fähigkeit in jedem Fall regelt. Dies ist bereits ziemlich komplex und mit einem isolierten Sicherheitsmodell vervielfacht sich dies für jede App, wodurch es fast unmöglich ist, effektiv nachzuverfolgen.

Aus diesem Grund betrachten wir ein isoliertes Sicherheitsmodell an sich als Sicherheitsrisiko und postulieren, dass jede App, die ein solches Modell verwendet, standardmäßig als riskant behandelt wird, bis das Gegenteil bewiesen ist.

Der Plan

Wir beschlossen, unsere Annahmen in der realen Welt im Mainnet zu testen. Das LayerZero-Framework wurde für das Experiment ausgewählt, weil es eine der beliebtesten Lösungen ist, die im Kern isolierte Sicherheit verwendet. Wir haben ein Omnichain-Token bereitgestellt, das sicher war, und später wurde die Sicherheitskonfiguration aktualisiert, die das Abziehen von böswilligen Token ermöglichte. Der Code des Tokens basiert auf den von LayerZero bereitgestellten Beispielen und ist vielen anderen in der Produktion eingesetzten Omnichain-Tokens und Apps sehr ähnlich oder identisch.

Aber bevor wir tief in die Details eintauchen, werfen wir einen kurzen Blick darauf, wie das LayerZero-Sicherheitsmodell aussieht.

Wie das Whitepaper von LayerZero klar feststellt, beruht seine „vertrauenswürdige Inter-Chain-Kommunikation“ auf zwei unabhängigen Akteuren (dem Orakel und dem Relayer), die zusammenarbeiten, um die Sicherheit des Protokolls zu gewährleisten.

Wie LayerZero auf seiner Website feststellt, besteht sein Kernkonzept darin, dass es sich um einen „benutzeranwendungskonfigurierbaren On-Chain-Endpunkt handelt, der einen ULN (UltraLightNode) ausführt“. Die On-Chain-Komponenten von LayerZero verlassen sich auf zwei externe Off-Chain-Parteien, um Nachrichten zwischen Chains weiterzuleiten – dem Oracle und dem Relayer.

Immer wenn eine Nachricht M von Kette A an Kette B gesendet wird, finden die folgenden zwei Aktionen statt:

• Zuerst wartet das Orakel, bis die Transaktion, die die Nachricht M auf Kette A sendet, abgeschlossen ist, und schreibt dann auf Kette B die Verpflichtung für das Nachrichtenbündel, z. B. den Hash des Blockheaders (das genaue Format kann zwischen verschiedenen Ketten / Orakeln variieren). bei Kette A, die diese Nachricht M enthält
• dann sendet der Relayer an Kette B einen „Beweis“ (zum Beispiel einen Merkle Proof), dass der gespeicherte Header die Nachricht M enthält

LayerZero behauptet, dass „das Design von LayerZero die Möglichkeit von geheimen Absprachen ausschließt“. Tatsächlich ist diese Aussage jedoch nicht wahr (was wir in dem unten gezeigten Experiment beweisen), da jede Benutzeranwendung ihren eigenen Relayer und Oracle definieren kann. LayerZero garantiert nicht, dass diese Komponenten unabhängig sind und keine Absprachen treffen können. Es liegt an der Benutzeranwendung, diese Garantien bereitzustellen. Und wenn die Anwendung sich dafür entscheidet, sie zu brechen, gibt es nichts in der LayerZero-Mechanik, das sie daran hindern kann.

Darüber hinaus sind standardmäßig alle Benutzeranwendungen jederzeit in der Lage, den Relayer und Oracle zu ändern, wodurch Sicherheitsannahmen vollständig neu definiert werden. Es reicht also nicht aus, die Sicherheit der jeweiligen App einmal zu überprüfen, da sie sich jederzeit nach der Überprüfung geändert haben kann, wie wir in unserem Experiment zeigen werden.

Das Experiment

In unserem Experiment haben wir uns entschieden, ein einfaches Omnichain-Token, CarpetMoon, zu erstellen, das sowohl auf Ethereum als auch auf Optimismus funktioniert und ZeroLayer verwendet, um zwischen beiden Ketten zu kommunizieren.

Unser Token verwendet zunächst das von LayerZero bereitgestellte Standardsicherheitsmodell, sodass es ziemlich genauso aussieht wie die meisten (wenn nicht alle) derzeit bereitgestellten LayerZero-Anwendungen. Daher ist es im Allgemeinen so sicher wie jedes andere Token, das LayerZero verwendet.

Zunächst setzen wir unsere Token-Verträge sowohl auf Ethereum als auch auf Optimism ein:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

Und wir richten das Routing so ein, dass LayerZero weiß, welcher Vertrag welchem ​​in beiden Ketten entspricht:
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

Das Token ist also eingerichtet, es sieht genauso aus wie alle anderen Omnichain-Token, die LayerZero verwenden, mit Standardkonfiguration, nichts Verdächtiges.

Wir stellen unserer Testbenutzerin, nennen wir sie Alice, Test-Token zur Verfügung, sodass Alice 1 Mrd. CarpetMoon-Token auf Ethereum hat:
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

Jetzt überbrückt Alice diese Token mit LayerZero zu Optimism.

Wir sperren die Token in einem Treuhandkonto auf Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/

Die Nachricht mit der Transaktion wird über LayerZero an Optimism übermittelt:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/nonce/1

Und Bridged Tokens werden auf Optimism geprägt, Alice hat jetzt 1B MoonCarpet Tokens auf Optimism:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302

Ok, also hat alles wie erwartet funktioniert, Alice hat ihre Token überbrückt und gesehen, dass sich 1B MoonCarpet-Token auf dem Treuhandkonto auf Ethereum und 1B MoonCarpet-Token auf ihrem Konto bei Optimism befinden. Aber um sicherzustellen, dass alles richtig funktioniert, überweist sie die Hälfte der Token (500 Millionen MoonCarpet) zurück an Ethereum.

Wir beginnen also mit der Transaktion, bei der 500 Millionen Token auf Optimism verbrannt werden:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f

Informationen über diese Transaktion werden an Ethereum weitergegeben:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1

Und wie erwartet werden 500 Millionen MoonCarpet-Token vom Treuhandkonto an Alices Adresse zurückgeliefert:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18

Bis jetzt funktioniert alles einwandfrei, genau wie angenommen. Alice hat überprüft, dass sie Token von Ethereum zu Optimism und wieder zurück übertragen kann, sie hat keinen Grund, sich um ihre MoonCarpet-Token zu fürchten.

Aber nehmen wir an, dass etwas schief geht – zum Beispiel wird das Team hinter unserem Token kompromittiert und der schlechte Schauspieler Bob erhält Zugriff auf die LayerZero-Konfiguration für unsere App.

Mit einem solchen Zugriff kann Bob das Oracle und den Relayer von den Standardeinstellungen zu denen unter seiner Kontrolle ändern.

Bitte denken Sie daran, dass dies ein Mechanismus ist, der jeder App, die LayerZero verwendet, zur Verfügung gestellt wird, der in der Architektur von LayerZero verankert ist, es ist keine Art von Hintertür, sondern eher ein Standardmechanismus.

Also ändert Bob das Orakel in ein EOA unter seiner Kontrolle:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/

Und macht dasselbe mit dem Relayer:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/

Und jetzt passieren seltsame Dinge. Da Oracle und Relayer jetzt unter Bobs vollständiger Kontrolle sind, kann er Alices Token stehlen. Obwohl auf dem Optimismus keine Aktion stattfindet (die MoonCarpet-Token befinden sich dort immer noch in Alices Brieftasche), kann Bob den MoonCarpet-Smart-Vertrag auf Ethereum (unter Verwendung von LayerZero-Mechanismen) davon überzeugen, dass er Token in einer anderen Kette verbrannt hat, und er kann MoonCarpet-Token abheben auf Ethereum.

Zuerst aktualisiert er den Blockhash bei Ethereum mit dem Schurken Oracle:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/

Und jetzt kann er die restlichen Token aus dem Treuhandkonto abheben:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/

Das Ergebnis

Alice wird nicht einmal wissen, warum und wann etwas passiert ist. Plötzlich sind ihre MoonCarpet-Token bei Optimism nicht mehr durch Token auf Ethereum gedeckt.

Die Smart Contracts sind nicht aktualisierbar und funktionieren wie vorgesehen. Die einzige verdächtige Aktivität ist die Änderung von Oracle und Relayer, aber dies ist ein normaler Mechanismus, der in LayerZero eingebaut ist, sodass Alice nicht einmal wissen kann, ob diese Änderung beabsichtigt war oder nicht. Und selbst wenn Alice von dieser Änderung erfuhr, wäre es bereits zu spät – der Angreifer kann die Gelder abschöpfen, bevor sie überhaupt reagieren kann.

Und LayerZero konnte auch hier nicht helfen – das waren alles gültige Ausführungen ihrer Mechanismen, die sie nicht mehr kontrollieren können. Theoretisch kann sich die Anwendung selbst daran hindern, Oracle und Relayer zu ändern, aber soweit wir wissen, hat dies keine der bereits bereitgestellten Anwendungen getan.

Wir haben dieses Experiment durchgeführt, um zu überprüfen, ob es jemandem auffällt, aber erwartungsgemäß tat es niemand. Es ist praktisch unmöglich, alle mit LayerZero erstellten Anwendungen effektiv zu überwachen, um zu überprüfen, ob sich ihre Sicherheitsrichtlinien nicht geändert haben, und die Benutzer zu warnen, wenn dies passiert.

Selbst wenn man nachholen könnte, dass sich Oracle und Relayer sicherheitsgefährdend verändert haben, ist es dann schon zu spät. Da das neue Oracle und Relayer nun frei wählen können, ob die Kommunikation zwischen Ketten zensiert oder einfach deaktiviert wird, können Benutzer normalerweise nichts dagegen tun. Dies wird in unserem Experiment deutlich, denn selbst wenn Alice die Änderung in der Anwendungskonfiguration bemerkt, kann sie mit ihren überbrückten Token nicht viel anfangen – das neue Oracle und der Relayer hören nicht mehr auf die ursprüngliche Kette, sodass sie die nicht weiterleiten Nachrichten zurück an Ethereum.

Schlussfolgerungen und CTA

Wie wir oben sehen konnten, konnten wir, obwohl unser Token mit LayerZero erstellt wurde und seine Mechanik wie beabsichtigt verwendete, Gelder aus dem Treuhandkonto der Token stehlen. Natürlich war es ein Fehler der Anwendung (CarpetMoon-Token in unserem Fall) und nicht des LayerZero selbst, aber das beweist, dass LayerZero selbst keine Sicherheitsgarantien bietet .

Wenn LayerZero ihr Sicherheitsmodell in Bezug auf Oracle und Relayer beschreibt, gehen sie davon aus, dass App-Besitzer (oder jemand, der im Besitz ihrer privaten Schlüssel ist) nichts Unvernünftiges tun werden. Aber diese Annahme ist in einem gegnerischen Umfeld falsch. Darüber hinaus müssen die Benutzer den Anwendungsbesitzern als vertrauenswürdigen Dritten vertrauen.

In der Praxis kann man daher keine Annahmen über die Sicherheit der mit LayerZero erstellten Anwendungen treffen – jede App sollte als riskant angesehen werden, bis das Gegenteil bewiesen ist.

Eigentlich begann die ganze Geschichte für uns mit einer PR, mit der wir planten, alle Omnichain-Token auf der L2BEAT-Site einzubinden – wir hatten Schwierigkeiten, herauszufinden, wie wir ihre Risiken einschätzen sollten. Bei der Analyse der Risikovektoren kam uns die Idee für unser Experiment.

Für L2BEAT sind die Konsequenzen, dass wir Warnungen über jede mit LayerZero erstellte App legen müssen, um vor möglichen Sicherheitsrisiken zu warnen. Wir möchten jedoch eine breitere Diskussion über Sicherheitsmodelle eröffnen, da wir glauben, dass isolierte Sicherheit ein Anti-Muster ist, das vermieden werden sollte, insbesondere in unserem Bereich.

Wir sind zuversichtlich, dass, da isolierte Sicherheitsmodelle wie in LayerZero immer beliebter werden, es immer mehr Projekte geben wird, die sie missbrauchen, viel Schaden anrichten und die gesamte Branche verunsichern.