L2BEAT hat LayerZero mit einem Experiment „geknackt“: Warum ist „Standalone-Sicherheit“ unsicher?

Autor: „Umgehung von Layer Zero: Warum isolierte Sicherheit keine Sicherheit ist.“

Autor: Krzysztof Urbański, L2BEAT-Teammitglied

Zusammengestellt von: Babywhale, Foresight News

L2BEAT hat seit seiner Gründung erhebliche Anstrengungen unternommen, um die mit Layer-2-Protokollen verbundenen Risiken zu analysieren und zu verstehen. Wir handeln stets im besten Interesse unserer Nutzer und unseres Ökosystems und tun unser Bestes, um ein unparteiischer und unabhängiger Aufseher zu sein, ohne dass unsere persönlichen Vorlieben für Projekte oder verwandte Teams die Fakten beeinflussen. Deshalb können wir, auch wenn wir die Zeit und Mühe respektieren, die das Projektteam in das Projekt investiert, „Alarm schlagen“ oder unsere Bedenken hinsichtlich der potenziellen Risiken bestimmter Protokolle zum Ausdruck bringen. Durch frühzeitige sicherheitsrelevante Diskussionen kann das gesamte Ökosystem besser auf potenzielle Risiken vorbereitet sein und früher auf verdächtiges Verhalten reagieren.

Heute möchten wir das gemeinsame Sicherheitsmodell für kettenübergreifende Anwendungen diskutieren. Derzeit gibt es zwei Sicherheitsmodelle: gemeinsame Sicherheit und unabhängige Anwendungssicherheit. Gemeinsame Sicherheit ist wie bei allen Rollups. Standalone-Anwendungssicherheit wird hauptsächlich von „Omnichain“-Projekten verwendet, die hauptsächlich LayerZero verwenden.

Gemeinsame Sicherheit vs. unabhängige Sicherheit

Gemeinsame Sicherheit bezieht sich auf ein bestimmtes Token oder eine bestimmte Anwendung, die auf einer bestimmten Infrastruktur ausgeführt wird, und anstatt ein Sicherheitsmodell frei zu wählen, müssen sie alle von der Infrastruktur auferlegten Sicherheitsanforderungen einhalten. Beispielsweise legen optimistische Rollups in der Regel ein letztes Zeitfenster von 7 Tagen fest – eine Anwendung, die auf solchen Rollups ausgeführt wird, kann diesen Zeitraum nicht einfach ignorieren oder verkürzen. Obwohl dies wie ein Hindernis erscheinen mag, gibt es einen Grund dafür. Dieser Zeitraum bietet Benutzern eine Sicherheitsgarantie, dass die Anwendung unabhängig von der internen Sicherheitsrichtlinie der Anwendung, die eingehalten werden muss, die Sicherheit von Rollups nur stärken und nicht schwächen darf.

Unabhängige Sicherheit bedeutet, dass jede Anwendung für die Definition ihrer Sicherheit verantwortlich ist und in keiner Weise durch die Infrastruktur eingeschränkt wird. Dies mag auf den ersten Blick wie eine gute Idee erscheinen, schließlich weiß der Entwickler der App am besten, welche Sicherheitsmaßnahmen die App möglicherweise benötigt. Gleichzeitig wird jedoch die Verantwortung für die Bewertung der mit jeder Anwendungssicherheitsrichtlinie verbundenen Risiken auf den Endbenutzer verlagert. Wenn App-Entwickler darüber hinaus ihre Sicherheitsrichtlinien frei wählen können, können sie diese auch jederzeit ändern. Daher reicht es nicht aus, das Risiko einmal für jede Anwendung zu bewerten; es sollte jedes Mal bewertet werden, wenn sich die Richtlinien einer Anwendung ändern.

Probleme

Wir glauben, dass ein unabhängiges Sicherheitsmodell, bei dem jede Anwendung ihre Sicherheitsrichtlinien frei definieren kann, ernsthafte Sicherheitsprobleme schafft. Erstens erhöht es das Risiko für Endbenutzer, da sie das Risiko für jede Anwendung, die sie verwenden möchten, überprüfen müssen.

Standalone-Sicherheit erhöht auch die Risiken für Apps, die dieses Modell verwenden, indem sie beispielsweise zusätzliche Risiken in Bezug auf Änderungen der Sicherheitsrichtlinien mit sich bringen. Wenn ein Angreifer das Sicherheitsmodell der App ändern würde, könnte er sie genauso gut einfach deaktivieren, wodurch ihm das Geld ausgeht oder er riskiert, dass die App inaktiviert wird Auf andere Weise angreifen. Es gibt keine zusätzlichen Sicherheitsebenen über der Anwendung, um Angriffe zu verhindern.

Da sich Sicherheitsrichtlinien außerdem jederzeit und spontan ändern können, ist es nahezu unmöglich, Anwendungen in Echtzeit zu überwachen und Benutzer über Risiken zu informieren.

Wir haben festgestellt, dass es mit der Aufrüstbarkeit von Smart Contracts vergleichbar ist, vor denen wir bei L2BEAT gewarnt haben. Wir informieren Benutzer über Rollup- und Cross-Chain-Bridges, deren Smart Contracts Upgrade-Mechanismen enthalten, und über die genauen Mechanismen zur Verwaltung der Upgrade-Fähigkeit in jedem Fall. Dies ist bereits recht komplex und die Verwendung eines separaten Sicherheitsmodells vervielfacht die Zahl, sodass eine effektive Nachverfolgung nahezu unmöglich ist.

Aus diesem Grund betrachten wir ein eigenständiges Sicherheitsmodell als Sicherheitsrisiko an sich und gehen davon aus, dass jede Anwendung, die dieses Modell standardmäßig verwendet, bis zum Beweis des Gegenteils als riskant angesehen werden sollte.

Beweisen Sie, dass Sicherheitslücken bestehen

Wir haben beschlossen, unsere Hypothese im Mainnet zu testen. Für die Experimente wurde das LayerZero-Framework ausgewählt, da es eine der beliebtesten eigenständigen, sicherheitsorientierten Lösungen ist. Wir haben ein sicheres Omnichain-Token bereitgestellt und später die Sicherheitskonfiguration aktualisiert, um böswillige Abhebungen des Tokens zu ermöglichen. Der Code für den Token basiert auf den von LayerZero bereitgestellten Beispielen und ist vielen anderen im realen Leben eingesetzten Omnichain-Tokens und -Anwendungen sehr ähnlich oder identisch.

Doch bevor wir ins Detail gehen, werfen wir einen kurzen Blick darauf, wie das LayerZero-Sicherheitsmodell aussieht.

Wie LayerZero in seinem Whitepaper betont, beruht seine „vertrauenswürdige Inter-Chain-Kommunikation“ auf zwei unabhängigen Akteuren (Orakeln und Relayern), die zusammenarbeiten, um die Sicherheit des Protokolls zu gewährleisten.

LayerZero gibt auf seiner Website an, dass sein Kernkonzept „Benutzeranwendungen, die ULN (UltraLightNode) ausführen, konfigurierbare On-Chain-Terminals“ sind. Die On-Chain-Komponente von LayerZero basiert auf zwei externen Off-Chain-Komponenten, um Nachrichten zwischen Ketten weiterzuleiten – Oracles und Relays.

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

• Zuerst wartet das Orakel, bis die Transaktion, die die Nachricht M auf Kette A sendet, abgeschlossen ist, und schreibt dann relevante Informationen auf Kette B, wie zum Beispiel den Hash-Wert des Blockheaders von Kette A, der die Nachricht M enthält (der genaue Wert zwischen verschiedenen Ketten/Orakeln). Format kann variieren).

• Das Relay sendet dann einen „Beweis“ (z. B. Merkle Proof) an Kette B und beweist damit, dass der gespeicherte Blockheader die Nachricht M enthält.

LayerZero geht davon aus, dass Relais und Orakel unabhängige, ehrliche Teilnehmer sind. Allerdings erklärte LayerZero in dem Whitepaper auch, dass, wenn diese Annahme nicht erfüllt sei, beispielsweise das Relay und das Oracle zusammenarbeiten würden, was dazu führen würde, dass „sowohl der vom Oracle bereitgestellte Blockheader als auch der vom Relay bereitgestellte Transaktionsnachweis ungültig sind, aber.“ immer noch passend.

LayerZero behauptet, dass „das Design von LayerZero die Möglichkeit einer Absprache ausschließt.“ Tatsächlich ist diese Aussage jedoch falsch (wir beweisen dies in den unten gezeigten Experimenten), da jede Benutzeranwendung ihre eigenen Relays und Oracles definieren kann. LayerZero garantiert nicht konstruktionsbedingt, dass diese Komponenten unabhängig sind und nicht kooperieren; es liegt vielmehr in der Verantwortung der Benutzeranwendung, diese Garantien bereitzustellen. LayerZero verfügt über keinen Mechanismus, um Apps zu stoppen, wenn sie sie beschädigen möchten.

Darüber hinaus können alle Benutzeranwendungen standardmäßig jederzeit Relays und Oracles ändern, wodurch die Sicherheitsannahmen völlig neu definiert werden. Daher reicht es nicht aus, die Sicherheit einer bestimmten Anwendung nur einmal zu überprüfen, da sie sich nach der Überprüfung jederzeit ändern kann, wie wir in unseren Experimenten zeigen werden.

experimentelles Design

Für unsere Experimente haben wir beschlossen, einen einfachen Omnichain-Token, CarpetMoon, zu erstellen, der sowohl auf Ethereum als auch auf Optimism läuft und LayerZero für die Kommunikation zwischen den beiden Ketten verwendet.

Unser Token verwendet zunächst das von LayerZero bereitgestellte Standardsicherheitsmodell, wodurch es mit großen (vielleicht nicht allen) derzeit bereitgestellten LayerZero-Anwendungen identisch ist. Daher ist es im Allgemeinen genauso sicher wie jede andere Münze, die LayerZero verwendet.

Zuerst stellen wir unseren Token-Vertrag auf Ethereum und Optimism bereit:

https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/

https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

Anschließend richten wir 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

Der Token wurde bereitgestellt und sieht genauso aus wie jeder andere Omnichain-Token, der LayerZero verwendet, mit der Standardkonfiguration und nichts Verdächtiges daran.

Wir haben unserer „Testbenutzerin“ Alice 1 Milliarde CarpetMoon-Tokens auf Ethereum zur Verfügung gestellt.

https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

Jetzt verwendet Alice LayerZero, um diese Token mit Optimism zu verketten.

Wir sperren die Token in einem Treuhandvertrag auf Ethereum:

https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。

Die Nachricht mit der Transaktion wird über LayerZero an Optimism weitergeleitet:

https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7nonced10d/。

Auf Optimism werden kettenübergreifende Token geprägt, und Alice besitzt jetzt 1 Milliarde MoonCarpet-Token auf Optimism:

https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302。

Alles funktioniert wie erwartet, Alice verkettet die Token und sieht, dass sich 1 Milliarde MoonCarpet-Token im Treuhandvertrag auf Ethereum und 1 Milliarde MoonCarpet-Tokens auf ihrem Konto bei Optimism befinden. Aber nur um sicherzustellen, dass alles in Ordnung war, übertrug sie die Hälfte ihrer Token zurück an Ethereum.

Wir beginnen mit einer Transaktion auf Optimism, die 500 Millionen Token verbrannt hat:

https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f。

Informationen über die Transaktion werden an Ethereum weitergegeben:

https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1。

Wie erwartet werden 500 Millionen MoonCarpet-Token aus dem Treuhandvertrag an Alices Adresse zurückgegeben:

https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。

Bisher funktioniert alles einwandfrei und genau wie erwartet. Alice hat überprüft, dass sie Tokens von Ethereum zu Optimism und wieder zurück verketten kann. Sie hat keinen Grund, sich um ihre MoonCarpet-Tokens Sorgen zu machen.

Aber Hypothesen haben ihre eigenen Probleme – zum Beispiel stößt das Team hinter unserem Token auf Probleme und der Bösewicht Bob erhält Zugriff auf die LayerZero-Konfiguration unserer App.

Auf diese Weise kann Bob die Oracles und Relays von den Standardkomponenten in von ihm kontrollierte Komponenten ändern.

Es ist zu beachten, dass dies ein Mechanismus ist, der für jede Anwendung, die LayerZero verwendet, bereitgestellt wird und in der Architektur von LayerZero verwurzelt ist. Es handelt sich nicht um irgendeine Hintertür, sondern um einen Standardmechanismus.

Also ändert Bob das Orakel in ein EOA unter seiner Kontrolle:

https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。

Auch der Repeater wird geändert:

https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。

Jetzt passiert etwas Seltsames. Da das Orakel und das Relais nun unter Bobs vollständiger Kontrolle stehen, ist er in der Lage, Alices Token zu stehlen. Obwohl keine Maßnahmen gegen Optimism ergriffen wurden (die MoonCarpet-Token befanden sich noch in Alices Wallet), konnte Bob den MoonCarpet-Smart-Vertrag auf Ethereum (unter Verwendung des LayerZero-Mechanismus) davon überzeugen, dass er die Token auf der anderen Kette zerstört hatte, und das gelang ihm auch Ziehen Sie die Token auf dem MoonCarpet-Token auf Ethereum ab.

Zuerst aktualisiert er den Block-Hash von Ethereum mithilfe eines von ihm kontrollierten Orakels:

https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。

Jetzt kann er die restlichen Token aus dem Treuhandvertrag abheben:

https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。

Experimentelle Ergebnisse

Alice weiß nicht einmal, warum und wann der Fehler aufgetreten ist. Plötzlich war ihr MoonCarpet-Token auf Optimism nicht mehr durch Token auf Ethereum gedeckt.

Intelligente Verträge sind nicht aktualisierbar und funktionieren wie erwartet. Die einzige verdächtige Aktivität sind die Oracle- und Relay-Änderungen, aber das ist ein regulärer Mechanismus, der in LayerZero integriert ist, sodass Alice nicht einmal weiß, ob diese Änderung beabsichtigt ist. Selbst wenn Alice von der Änderung erfährt, ist es zu spät – der Angreifer kann das Geld abziehen, bevor sie reagieren kann.

LayerZero kann nichts – das sind alles effiziente Implementierungen ihrer Mechanismen, über die sie keine Kontrolle haben. Theoretisch könnten Anwendungen selbst verhindern, dass Oracles und Relays geändert werden. Unseres Wissens nach haben jedoch noch keine bereitgestellten Anwendungen dies getan.

Wir haben dieses Experiment durchgeführt, um zu testen, ob es jemandem aufgefallen ist, aber wie erwartet hat es niemand bemerkt. Eine effektive Überwachung aller mit LayerZero erstellten Anwendungen, um zu überprüfen, ob sich ihre Sicherheitsrichtlinien geändert haben, und um Benutzer zu benachrichtigen, wenn dies geschieht, ist nahezu unmöglich.

Selbst wenn es jemandem gelingt, rechtzeitig zu entdecken, dass sich die Orakel und Relais verändert haben und ein Sicherheitsrisiko darstellen, wird es zu spät sein. Da neue Orakel und Relays nun frei wählen können, welche Nachrichten sie übermitteln möchten, oder einfach die Kommunikation zwischen den Ketten deaktivieren können, können Benutzer im Allgemeinen nicht viel dagegen tun. Unsere Experimente zeigen deutlich, dass Alice, selbst wenn sie die Änderung der Anwendungskonfiguration bemerkt, mit ihren Cross-Chain-Tokens nicht viel anfangen kann – die neuen Oracles und Relayer werden in der ursprünglichen Kommunikationskettennachricht nicht mehr akzeptiert, sodass die Nachricht nicht an Ethereum zurückgegeben wird .

abschließend

Wie wir sehen können, konnten wir Geld aus dem Treuhandkonto des Tokens stehlen, obwohl unser Token mit LayerZero erstellt wurde und dessen Mechanik wie vorgesehen nutzte. Dies liegt natürlich an der Anwendung (in unserem Fall am CarpetMoon-Token) und nicht an LayerZero selbst, aber es beweist, dass LayerZero selbst keine Sicherheitsgarantien bietet.

Wenn LayerZero sein Sicherheitsmodell in Bezug auf Orakel und Relayer beschreibt, gehen sie davon aus, dass der Anwendungseigentümer (oder wer auch immer den privaten Schlüssel hat) nichts Unvernünftiges tun wird. In einem kontroversen Umfeld ist diese Annahme jedoch falsch. Darüber hinaus müssen Benutzer dem App-Entwickler als vertrauenswürdigem Dritten vertrauen.

Daher kann man in der Praxis keine Annahmen über die Sicherheit von mit LayerZero erstellten Anwendungen treffen – jede Anwendung sollte als riskant betrachtet werden, bis das Gegenteil bewiesen ist.

Eigentlich begann die ganze Geschichte mit einer PR, dass wir alle Omnichain-Tokens auf der L2BEAT-Website einbinden wollten – es fiel uns schwer herauszufinden, wie wir ihr Risiko einschätzen sollten. Bei der Risikoanalyse kam uns die Idee des Experimentierens.

Wenn L2BEAT live gehen würde, wäre die Konsequenz, dass wir bei jeder mit LayerZero erstellten Anwendung Warnungen platzieren müssten, um vor möglichen Sicherheitsrisiken zu warnen. Wir wollten jedoch eine breitere Diskussion über Sicherheitsmodelle führen, da wir der Meinung sind, dass eigenständige Sicherheit ein Modell ist, das insbesondere in unserem Bereich vermieden werden sollte.

Wir glauben, dass unabhängige Sicherheitsmodelle wie LayerZero mit zunehmender Beliebtheit von immer mehr Projekten missbraucht werden, was massiven Schaden anrichtet und die Unsicherheit in der gesamten Branche erhöht.