原文标题：《Obcházení Layer Zero: Proč izolované zabezpečení není žádné zabezpečení》

Autor: Krzysztof Urbański, člen týmu L2BEAT

Sestavil: Babywhale, Foresight News

L2BEAT od svého vzniku investoval značné úsilí do analýzy a pochopení rizik spojených s protokoly vrstvy 2. Vždy jednáme v nejlepším zájmu našich uživatelů a ekosystému a děláme vše, co je v našich silách, abychom byli nestranným, nezávislým dozorcem, aniž bychom dovolili našim osobním preferencím pro projekty nebo související týmy ovlivňovat fakta. Proto, i když respektujeme čas a úsilí, které projektový tým vkládá do projektu, můžeme „bít na poplach“ nebo upozornit na naše obavy z potenciálních rizik určitých protokolů. Včasné diskuse o bezpečnosti umožňuje celému ekosystému lépe se připravit na potenciální rizika a reagovat dříve na jakékoli podezřelé chování.

Dnes bychom rádi probrali sdílený bezpečnostní model pro cross-chain aplikace. V současnosti existují dva modely zabezpečení: sdílené zabezpečení a nezávislé zabezpečení aplikací. Sdílené zabezpečení je jako všechny souhrny. Zabezpečení samostatných aplikací využívají především „omnichain“ projekty, které využívají především LayerZero.

Sdílené zabezpečení vs. nezávislé zabezpečení

Sdílené zabezpečení se týká konkrétního tokenu nebo aplikace běžící na dané infrastruktuře a namísto svobodného výběru modelu zabezpečení musí dodržovat jakékoli požadavky na zabezpečení uložené infrastrukturou. Například optimistická kumulativní období obvykle ukládají 7denní konečné okno – aplikace běžící na takových kumulacích nemůže toto období jednoduše ignorovat nebo zkrátit. I když se to může zdát jako překážka, má to svůj důvod. Tato doba poskytuje uživatelům bezpečnostní záruku, že bez ohledu na vnitřní bezpečnostní politiku aplikace, kterou je nutné dodržovat, může aplikace bezpečnost Rollupů pouze posílit, nikoli oslabit.

Nezávislé zabezpečení znamená, že každá aplikace je zodpovědná za definování své bezpečnosti a není nijak omezena infrastrukturou. Zpočátku se to může zdát jako dobrý nápad, koneckonců vývojář aplikace ví nejlépe, jaká bezpečnostní opatření může aplikace potřebovat. Zároveň ale přesouvá odpovědnost za posouzení rizik spojených s každou bezpečnostní politikou aplikace na koncového uživatele. Kromě toho, pokud si vývojáři aplikací mohou svobodně zvolit své zásady zabezpečení, mohou je také kdykoli změnit. Proto nestačí vyhodnotit riziko jednou pro každou aplikaci, mělo by být vyhodnoceno pokaždé, když se změní zásady aplikace.

Problémy

Jsme přesvědčeni, že nezávislý bezpečnostní model, ve kterém si každá aplikace může svobodně definovat svou bezpečnostní politiku, vytváří vážné bezpečnostní problémy. Za prvé, zvyšuje riziko pro koncové uživatele, protože musí ověřit riziko pro každou aplikaci, kterou hodlají používat.

Samostatné zabezpečení také zvyšuje rizika pro aplikace, které používají tento model, například přidává další rizika týkající se změn bezpečnostních zásad – pokud by útočník změnil model zabezpečení aplikace, mohl by ji také jednoduše deaktivovat, čímž by došly peníze nebo riskoval jakýmkoli způsobem. Nad aplikací nejsou žádné další vrstvy zabezpečení, které by zabránily útokům.

Navíc, protože bezpečnostní zásady se mohou kdykoli a za běhu měnit, je téměř nemožné monitorovat aplikace v reálném čase a informovat uživatele o rizicích.

Přišlo nám to podobné jako upgradovatelnost chytrých kontraktů, na kterou jsme upozorňovali na L2BEAT. Informujeme uživatele o Rollup a cross-chain bridges, které mají ve svých chytrých smlouvách mechanismy upgradovatelnosti, a přesné mechanismy pro správu upgradovatelnosti v každém případě. To je již poměrně složité a použití samostatného bezpečnostního modelu toto číslo znásobuje, takže je téměř nemožné efektivně sledovat.

Proto považujeme samostatný bezpečnostní model za bezpečnostní riziko sám o sobě a předpokládáme, že každá aplikace, která bude tento model standardně používat, by měla být považována za rizikovou, dokud se neprokáže opak.

Dokažte, že existují slabá místa zabezpečení

Rozhodli jsme se otestovat naši hypotézu na mainnetu. Rámec LayerZero byl vybrán pro experimentování, protože je jedním z nejpopulárnějších samostatných řešení zaměřených na zabezpečení. Nasadili jsme bezpečný omnichain token a později aktualizovali konfiguraci zabezpečení, aby bylo možné token se zlomyslným výběrem. Kód pro token je založen na příkladech poskytnutých LayerZero a je velmi podobný nebo totožný s mnoha dalšími omnichain tokeny a aplikacemi nasazenými v reálném životě.

Než se ale dostaneme k detailům, pojďme se krátce podívat, jak vypadá bezpečnostní model LayerZero.

Jak LayerZero zdůrazňuje ve své bílé knize, její „nedůvěryhodná meziřetězcová komunikace“ se opírá o dva nezávislé aktéry (věštci a převaděči), kteří spolupracují, aby zajistili bezpečnost protokolu.

LayerZero na svém webu uvádí, že jeho základním konceptem jsou „uživatelské aplikace provozující ULN (UltraLightNode), konfigurovatelné on-chain terminály.“ On-chain komponenta LayerZero spoléhá na dvě externí off-chain komponenty pro předávání zpráv mezi řetězci – věštci a relé.

Kdykoli je odeslána jakákoli zpráva M z řetězce A do řetězce B, proběhnou následující dvě operace:

  • Nejprve orákulum počká, dokud není dokončena transakce zasílání zprávy M v řetězci A, a poté zapíše relevantní informace o řetězci B, jako je hash hodnota hlavičky bloku řetězce A obsahujícího zprávu M (přesná hodnota mezi různými řetězci/věštci Formát se může lišit).

  • Relé pak odešle „důkaz“ (například Merkle Proof) do řetězce B, který prokáže, že uložená hlavička bloku obsahuje zprávu M.

LayerZero předpokládá, že štafety a orákula jsou nezávislí, čestní účastníci. LayerZero však v bílé knize také uvedlo, že pokud tento předpoklad není splněn, dojde například ke shodě mezi přenosem a věštcem, což má za následek, že „záhlaví bloku poskytnuté věštcem i důkaz transakce poskytnutý předáním jsou neplatné, ale stále odpovídá."

LayerZero tvrdí, že "design LayerZero eliminuje možnost tajné dohody." Ale ve skutečnosti je toto tvrzení nesprávné (to dokazujeme v níže uvedených experimentech), protože každá uživatelská aplikace může definovat svá vlastní relé a orákula. LayerZero ze své podstaty nezaručuje, že tyto komponenty jsou nezávislé a nemohou se vzájemně tajit, je na uživatelské aplikaci, aby tyto záruky poskytla. LayerZero nemá žádný mechanismus k zastavení aplikací, pokud se je rozhodnou přerušit.

Navíc ve výchozím nastavení mohou všechny uživatelské aplikace kdykoli změnit relé a věštce, čímž zcela předefinují předpoklady zabezpečení. Proto nestačí zkontrolovat zabezpečení dané aplikace pouze jednou, protože se může po kontrole kdykoli změnit, jak si ukážeme na našich experimentech.

experimentální design

Pro naše experimenty jsme se rozhodli vytvořit jednoduchý omnichain token, CarpetMoon, který běží na Ethereu i Optimism a používá LayerZero ke komunikaci mezi těmito dvěma řetězci.

Náš token zpočátku používá výchozí model zabezpečení poskytovaný LayerZero, takže je identický s velkými (možná ne všemi) aktuálně nasazenými aplikacemi LayerZero. Proto je obecně stejně bezpečný jako jakýkoli jiný coin využívající LayerZero.

Nejprve nasadíme naši tokenovou smlouvu na Ethereum a Optimismus:

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

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

Poté nastavíme směrování tak, aby LayerZero vědělo, která smlouva odpovídá které na obou řetězcích.

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

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

Token byl nasazen a vypadá přesně jako každý jiný omnichain token používající LayerZero, používá výchozí konfiguraci a není na tom nic špatného.

Našemu „testovacímu uživateli“ Alici jsme poskytli 1 miliardu tokenů CarpetMoon na Ethereu.

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

Nyní Alice používá LayerZero k propojení těchto tokenů do Optimismu.

Tokeny zamykáme v escrow smlouvě na Ethereum:

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

Zpráva obsahující transakci je předána Optimismu přes LayerZero:

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

Cross-chain tokeny jsou raženy na Optimism a Alice nyní vlastní 1 miliardu tokenů MoonCarpet na Optimism:

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

Vše funguje podle očekávání, Alice zkříží tokeny a vidí, že na jejím účtu u Optimism je 1 miliarda tokenů MoonCarpet v escrow smlouvě na Ethereum a 1 miliarda tokenů MoonCarpet. Aby se ale ujistila, že je vše v pořádku, převedla polovinu svých tokenů zpět do Etherea.

Začínáme s transakcí na Optimism, která spálila 500 milionů tokenů:

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

Informace o transakci jsou předány do Etherea:

https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903bnoncec/nonceffd。8484

Jak se očekávalo, 500 milionů tokenů MoonCarpet se vrací ze smlouvy o úschově na Alicinu adresu:

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

Zatím vše funguje dobře a přesně podle předpokladů. Alice zkontrolovala, že může křížit tokeny z Etherea do Optimismu a zpět, nemá důvod se o své tokeny MoonCarpet obávat.

Ale hypotetické věci mají své vlastní problémy – například tým, který stojí za naším tokenem, narazí na problémy a padouch Bob získá přístup ke konfiguraci LayerZero naší aplikace.

Tímto způsobem může Bob změnit věštce a relé z výchozích komponent na komponenty, které ovládá.

Je třeba poznamenat, že se jedná o mechanismus poskytovaný pro každou aplikaci využívající LayerZero a je zakořeněn v architektuře LayerZero. Nejedná se o žádná zadní vrátka, ale o standardní mechanismus.

Bob tedy změní orákulum na EOA pod jeho kontrolou:

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

Změnil se také opakovač:

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

Nyní se stane něco zvláštního. Protože věštec a relé jsou nyní pod plnou kontrolou Boba, je schopen ukrást Aliciiny žetony. I když proti Optimismu nebyly podniknuty žádné kroky (žetony MoonCarpet byly stále v Alicině peněžence), Bob dokázal přesvědčit chytrý kontrakt MoonCarpet na Ethereum (pomocí mechanismu LayerZero), že zničil tokeny na druhém řetězci a byl schopen stáhněte si tokeny na tokenu MoonCarpet na Ethereum.

Nejprve aktualizuje blokový hash Etherea pomocí věštce, kterou ovládá:

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

Nyní může vybrat zbývající tokeny ze smlouvy o úschově:

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

Experimentální výsledky

Alice ani neví, proč a kdy k chybě došlo. Najednou její token MoonCarpet na Optimism přestal být podporován tokeny na Ethereu.

Smart kontrakt nelze upgradovat a funguje podle očekávání. Jedinou podezřelou aktivitou jsou změny orákula a relé, ale to je běžný mechanismus zabudovaný do LayerZero, takže Alice ani neví, jestli je tato změna záměrná. I když se Alice o změně dozví, je příliš pozdě - útočník může vyčerpat prostředky, než stihne zareagovat.

LayerZero nemůže nic dělat – všechno jsou to efektivní implementace jejich mechanismů, nad kterými nemají žádnou kontrolu. Teoreticky by si samotné aplikace mohly zabránit ve změně věštců a relé, ale pokud je nám známo, žádná nasazená aplikace tak neučinila.

Tento experiment jsme provedli, abychom otestovali, zda si toho někdo všiml, ale jak jsme očekávali, nikdo to neudělal. Je téměř nemožné efektivně monitorovat všechny aplikace vytvořené pomocí LayerZero a zkontrolovat, zda se jejich bezpečnostní zásady změnily, a upozornit uživatele, když k tomu dojde.

I když někdo dokáže včas zjistit, že se věštci a relé změnili a vytvořili bezpečnostní riziko, bude pozdě. Vzhledem k tomu, že nová věštci a přenosová zařízení si nyní mohou svobodně vybrat, které zprávy doručit, nebo jednoduše zakázat meziřetězcovou komunikaci, uživatelé s tím obecně nemohou mnoho dělat. Naše experimenty jasně ukazují, že i když si Alice všimne změny konfigurace aplikace, nemůže se svými cross-chain tokeny mnoho udělat – nová orákula a relé již nejsou přijímána v původní zprávě komunikačního řetězce, takže zpráva nebude vrácena do Etherea. .

na závěr

Jak vidíme, i když byl náš token postaven pomocí LayerZero a používal jeho mechaniku tak, jak bylo zamýšleno, byli jsme schopni ukrást finanční prostředky z úschovy tokenu. To je samozřejmě chyba aplikace (v našem případě tokenu CarpetMoon) a ne LayerZero samotné, ale dokazuje to, že LayerZero samo o sobě neposkytuje žádné záruky zabezpečení.

Když LayerZero popisuje svůj bezpečnostní model týkající se věštců a relé, předpokládají, že vlastník aplikace (nebo kdokoli, kdo má soukromý klíč) neudělá nic nepřiměřeného. Ale v nepřátelském prostředí je tento předpoklad nesprávný. Kromě toho vyžaduje, aby uživatelé důvěřovali vývojáři aplikace jako důvěryhodné třetí straně.

V praxi tedy nelze dělat žádné předpoklady o bezpečnosti aplikací vytvořených pomocí LayerZero – každá aplikace by měla být považována za rizikovou, dokud se neprokáže opak.

Vlastně celý příběh začal PR, že jsme plánovali zahrnout všechny omnichain tokeny na web L2BEAT – těžko jsme přišli na to, jak vyhodnotit jejich riziko. Při analýze rizik jsme přišli s myšlenkou experimentování.

Pokud by byl L2BEAT spuštěn, důsledkem by bylo, že bychom museli umístit upozornění na každou aplikaci vytvořenou pomocí LayerZero, abychom varovali před možnými bezpečnostními riziky. Chtěli jsme však vést širší diskusi o bezpečnostních modelech, protože věříme, že samostatné zabezpečení je model, kterému bychom se měli vyhnout, zejména v našem oboru.

Věříme, že jak se nezávislé modely zabezpečení, jako je LayerZero, stávají stále populárnějšími, stále více projektů je bude zneužívat, což způsobí obrovské škody a zvýší nejistotu v celém odvětví.